Current Nakamoto Coefficients and Topology, avg = 4.60
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
3
2, CH
3
11
City
5
1
1
13
Data Center
5
1
1
13
Data Center Owner
5
1
1
13
Node Provider ID
5
1
1
13
Proposed Nakamoto Coefficients and Topology, avg = 4.80
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
4
2, SI
3
12
City
5
1
1
13
Data Center
5
1
1
13
Data Center Owner
5
1
1
13
Node Provider ID
5
1
1
13
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals.
Test: We test and verify the claims made by those proposals.
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
TLDR: A side-effect of this proposal is that some decentralisation metrics are improved which is nice. However, the proposal claims there’s a need to remove an HSM-secured node, in order to redeploy without the legacy HSM approach. However there’s no forum post from the Node Provider to put this proposal into context. This is something which has been agreed as a requirement in the past for these sorts of proposals.
@Sat, sorry to be a pain, but is there a public announcement about this from the Node Provider that can be pointed to?
Country Discrepancies (1)
This is a very large discrepancy in terms of distance, which I’m surprised to see given than ipinfo.io uses a probe network for increased geolocation accuracy. However the node in question is not the subject of this proposal, so just something to revisit at some point I think.
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
104.032 km
6528.134 km
15362.693 km
PROPOSED
104.032 km
7058.792 km (+8.1%)
16458.534 km (+7.1%)
This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience).
Subnet characteristic counts →
Continents
Countries
Data Centers
Owners
Node Providers
Node Operator
EXISTING
4
11
13
13
13
13
PROPOSED
4
12 (+8.3%)
13
13
13
13
This proposal slightly improves decentralisation in terms of jurisdiction diversity.
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
The above subnet information is illustrated below, followed by a node reference table:
Map Description
Red marker represents a removed node (transparent center for overlap visibility)
Green marker represents an added node
Blue marker represents an unchanged node
Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)
Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)
Black dotted line connects to a small black marker that shows where the IP address indicates the node is located (according to ipinfo.io). This is only displayed if it conflicts with where IC records indicate the node is located. See Country Discrepancies section above for more info.
You may wish to follow the CO.DELTA known neuron (coming soon) if you found this analysis helpful.
CO.DELTA △
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.
TLDR:
The proposal is to redploy to HSM less nodes for 1.1 reward structure link. However this is not communicated on the proposal link for clear visibility. Decentralization stats increases as it claims to be.
Node lmsfp…: Remove from Subnet check passed. Node wbz2k…: Remove from Subnet check passed. Node ohtm4…: Replacement Status check passed. Node 5jqmb…: Replacement Status check passed.
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
This proposal replaces nodes in subnet fuqsr, appearing in the decentralization tool as “UP” for the given reason “freeing up nodes from AW1 node operator for an HSM-less redeployment”, along with an additional node in order to improve overall topology. As shown in the proposal, decentralisation parameters are improved with respect to country and brought to within the requirements of the target topology. Unfortunately there is nothing within the proposal text or within any of the provided links to support the given reason for this change. However, I have voted to adopt given the improvement in decentralisation parameters.
About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neurons’ Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Replaces cordoned node lmsfpDashboard Status: Active and node wbz2kDashboard Status: Active with nodes ohtm4Dashboard Status: Awaiting and 5jqmbDashboard Status: Awaiting on subnet fuqsr.
The proposal makes a necessary replacement by removing a cordoned node that needs to be reployed for HSM-less migration and also improves decentralization by reducing the countryCH aka Switzerland from 2 to 1 which is an improvement of 33% in this coefficient.
About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Vote: Adopted Reason:
The proposal replaces 2 healthy nodes motivated by “freeing up nodes from AW1 node operator for an HSM-less redeployment” with slight improvement to decentralization.
About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Hello everyone! With the execution of proposal 136589, the test key for the vetKeys feature was generated on subnet 2fq7c. As announced in this post, the DFINITY Foundation plans to submit follow-up proposals to reshare the key on subnet fuqsr, which also hosts the other threshold keys.
The key resharing process involves pausing the subnet, resharing the key in a CUP (Catch-Up Package), and restarting the subnet from the CUP with the new key. See this post for details on a previous instance of a similar operation.
To minimize downtime for subnet fuqsr, the DFINITY Foundation intends to submit and vote on the required three proposals in quick succession, skipping the usual three-day waiting period. The key resharing is scheduled for 15 May at 11:30 AM (UTC).
Proposal 136637 is the first one (out of three) for the resharing of the vetkeys test key to subnet fuqsr. As announced above, DFINITY plans to vote on this proposal on 15 May at 11:30 AM (UTC).
TLDR: Following 136589, this will halt subnet fuqsr to allow Vet key resharing from subnet 2fq7c using Catch-Up Package message.
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals.
Test: We test and verify the claims made by those proposals.
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
TLDR: This proposal will halt the subnet at the next catch up package after it executes. This is intentional, and has been announced above.
I’ve adopted early given that it will take significantly more VP to push this over the execution threshold (scheduled for tomorrow). I plan to reject the follow up proposal which will supply the reshared key material in a CUP, for which there will be no way for the community to verify correctness of the state that is being applied to the subnet. More discussion about this type of process can be found here.
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA △
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
VOTE: YES TLDR:
The following proposal will pause subnet fuqsr for Vet key resharing from the previous proposal : subnet 2fq7c as mentioned on the forum post. Quickly adopting efforts to minimize downtime. One of three incoming proposals
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
TLDR: There is no clear way for the community to verify correctness of the state that is being applied to this subnet. I mentioned in advance that I planed to reject this proposal.
In addition to applying a catch up package to the subnet, this proposal also adds the bls12_381_g2 key config (the same that was applied to the backup subnet under Proposal: 136589).
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA △
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
TLDR: This proposal simply unhalts the subnet (we have to assume the key material has been shared in the CUP applied by the prior proposal).
@andrea, thanks for being proactive and available to communicate these proposals. Would you be able to share (or point me in the right direction) regarding the process that DFINITY goes through when preparing a CUP of this sort (particularly modifying the state to include arbitrary information)? If you could also highlight privileged access that’s required during this process that would be useful. My thinking is that if a community member could attempt to go through the same process, they could build the same catch up package and verify the hash.
This state obviously needs storing in the registry so that it can be retrieved by the orchestrator and applied to the subnet when it starts up. That state is observable as a hash in the payload of Proposal: 136653, but where is the actual state relative to that proposal (how does the registry get hold of it)?
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA △
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
VOTE: YES TLDR:
This proposal (step 2 of 3) paused subnet fuqsr, injected a recovery Catch-Up Package that adds the new vetKD master test key at height 141,320,000, and was fast-tracked and adopted by DFINITY to finish a key-reshare test;
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
