Ahoy ICP folks,
I want to talk to you about an important next step in the governance of the Internet Computer: The active promotion of “Blessing replica binary” proposals.
I will first describe the world as it currently is and then discusses the next steps.
A “replica binary” is literally what it sounds: the binary that runs in every node of the Internet Computer. Most colloquially, when folks say that “there is a new update to the IC” what they mean is “there is a new replica binary that is running on every node of the IC.”
Under the hood, it is the binary that is derived from the Rust code here: IC Replica code
These replica binaries typically have lots of updates and features as one would expect from any software development branch ready to hit production.
To “bless the binary” means that there is an NNS proposal for neuron holders to vote that the binary is the one that should be the next version of the IC. Blessing is not enough to have a full update. There are then subsequent NNS proposals to update each subnet with the latest blessed replica binary.
In short, every week or so, there are lots of code updates to fix bugs or add features. They are all tested and rolled into a binary which is voted on.
We are asking the community to actively look at proposals to bless new replica versions. Have a look look at the release notes, vote, decide to follow the foundation, ask questions, or point out something. We aim for a weekly release cycle. For every new release that we propose to bless we are going to create a new thread.
Here is this week’s release (which is analogous to a “release candidate” in some places):
If a binary is adopted, the following then happens:
- NNS proposals to update subnets to the newly blessed version are published and voted on.
- The code in IC Replica code is updated (as a downstream consequence)
We want to encourage more participation in voting in the direction of the Internet Computer as we continue improving transparency.
Pretty much from the beginning. It has always been there, though the transparency has clearly improved as the dashboards improved, but we want to shine a spotlight on it:
Past replica binary proposals:
There are a few areas we want to hang a lantern on and point them out because we are aware they are not great but aim to improve as part of this constant iterative process:
Length of voting - these proposals have 48 hours before they expire. In the past, the DFINITY foundation has deliberately not voted in
Motion Proposalsuntil the very end to let early voters get their opinions in and the foundation can take it into consideration. Our current thinking for these binary blessing proposals is that the DFINITY foundation (and by extension its followers) will abstain for 12 hours before voting. Could this be 6 hours? 24 hours? Yes, of course. We believe these binaries do not require the large ceremony and deep thinking that designs in motion proposals do. We of course can iterate if find otherwise. Right now it is 12 hours as a starting number to gauge the balance between “moving fast” and "letting people express their votes." Of course, if people do not like how the foundation works, they can stop following the foundation. I expect we will all learn as a community as patterns emerge.
Viewing of the code - Right now, the binaries are just that (binaries). The code is visible after it is voted on. This is not ideal so stay tuned for updates on our plan to address this (under the hood: we have a plan we are prepping for the community). Soon, people will be able to see the code, not just the binary, but this is the next step in the current process (giving this NNS proposal more attention).
Feature promotion - We will continue to improve the release notes and how features within binaries are verbally promoted so people know when their awaited feature is out. For example, the feature to increase canister smart contracts from 4 GB to 8 GB recently went out in a binary.
Making features and NNS proposals tighter - right now there is so much progress to the IC, that a binary has many different features you vote on “all or nothing.” In the future, we have ideas on how we can have more granular voting per feature (using feature flags would be a potential start, for example).