This proposal replaces node pxyu4 which appears in the dashboard as “Status: Active” for the stated reason “offboarding TY2 DC after 48 months”. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Vote: Adopted Reason:
The proposal replaces cordoned healthy Active status node pxyu4 from Tokyo2, with
unassigned healthy Awaiting status node xmg5b from Tokyo1, with no change to the decentralization of the subnet.
The motivation makes sense and the provided Forum link included in the summary provides further info.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Replaces cordoned node pxyu4 with node xmg5b on subnet k44fs.
The reason for this proposal is to offboard the TY2 DC consistent with forum posts made on the forum thread used for posts regarding the renovation/sell of Gen-1 node machines by NPs.
Both the NP and DC stated in the forum post match the ones from the node being removed in the proposal.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
This proposal replaces 1 node in subnet k44fs, appearing in the decentralization tool as “DOWN”. As shown in the proposal and verified using the DRE tool, decentralisation parameters are unchanged and remain within the requirements of the target topology.
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.
TLDR: One offline node replaced with an unassigned node. IC Target Topology metrics remain unchanged, but the average distance between nodes increases slightly.
Country Discrepancies (2)
There a relatively large country discrepancy (in terms of distance). Given that ipinfo.io uses a probe network for geolocation, I’m surprised to see such a large discrepancy. Something to revisit (given that the node in question isn’t directly affected by this proposal).
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
468.191 km
8407.958 km
16616.573 km
PROPOSED
491.749 km (+5%)
8548.634 km (+1.7%)
16616.573 km
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
5
13
13
13
13
13
PROPOSED
5
13
13
13
13
13
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.
Current Nakamoto Coefficients and Topology, avg = 5.00
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
5
1
2
13
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 = 5.00
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
5
1
2
13
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:
The proposal replaces offline nodes in Allentown (North America).
The decentralization stats remain the same.
Warning
The last few proposals that address the outage of DC is offloading all nodes to one Node provider. @DRE-Team Is there a way we can address this issue in the future to offload nodes into multiple Node providers. I will vote to Adopt to recover this issue in hopes that this feature will be addressed.
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: Adopted Reason:
The proposal replaces dead Offline status node 6uxsy from the AW1 DC in Pennsylvania, with unassigned healthy Awaiting status node kc5j4 from Dallas without any change 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.
The proposal replaces a dead nodes on subnet k44fs:
dead node 6uxsyDashboard Status: Offline with node kc5j4Dashboard Status: Awaiting
There is no impact in the overall decentralization across all features.
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.
Calculated potential impact on subnet decentralization if replacing:
1 additional node would result in: equal decentralization across all features
2 additional nodes would result in: equal decentralization across all features
Based on the calculated potential impact, replacing 1 additional nodes to improve optimization
Note: the heuristic for node replacement relies not only on the Nakamoto coefficient but also on other factors that iteratively optimize network topology.
Due to this, Nakamoto coefficients may not directly increase in every node replacement proposal.
Code for comparing decentralization of two candidate subnet topologies is at: dre/rs/decentralization/src/nakamoto/mod.rs at 79066127f58c852eaf4adda11610e815a426878c · dfinity/dre · GitHub
The proposal replaces 1 node on subnet k44fs:
node q3sjiDashboard Status: Active with node 2w5beDashboard Status: Awaiting.
The reason for the proposal is that the node being removed is controlled by NP vegae that is part of a Node provider cluster with NPs 6sq7t and eatbv. Since NP 6sq7t has a node in this subnet and per the IC Target Topology we have a limit of 1 node per NP in a subnet (two NPs part of a cluster of NPs count as 1) the node is removed.
There is no impact in the overall decentralization across all features.
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.
TLDR: George Bassadone is an NP but is also represented by the GeoNodes NP (both NPs currently have a node in this subnet). This proposal removes the George Bassadone node in order to more rigorously comply with the IC Target Topology (specify one node per independent NP, per subnet).
Decentralisation is also improved in terms of the average distance between nodes.
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
491.749 km
8548.634 km
16616.573 km
PROPOSED
491.749 km
8841.978 km (+3.4%)
16616.573 km
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
5
13
13
13
13
13
PROPOSED
5
13
13
13
13
13
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 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.
Current Nakamoto Coefficients and Topology, avg = 5.00
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
5
3
13
City
5
1
13
Data Center
5
1
13
Data Center Owner
5
1
13
Node Provider ID
5
1
13
Proposed Nakamoto Coefficients and Topology, avg = 5.00
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
5
3
13
City
5
1
13
Data Center
5
1
13
Data Center Owner
5
1
13
Node Provider ID
5
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.
This proposal replaces 1 node in subnet k44fs, appearing in the decentralization tool as “UP”, for the presumed reason of preventing a self-declared node provider cluster from having more than 1 node in the subnet.. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.
@DRE-Team@sat@alexu This has now been clarified in earlier forum discussions, but if you could, please remember to include a reason under “Motivation:” and a forum link for context in NP cluster-related proposals.
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.
TLDR:
The proposal replaces active node in Tbilisi (Asia). Similarly as per previous proposal this is to remove active node which is owned by same NP as a new business cluster rule mentioned in the proposal.
Node provider cluster 1 (6sq7t, vegae, eatbv) has 2 nodes in the subnet
No issues were found in the nodes or locations proposed and decentralization stats remain the same. I vote to adopt
Node q3sji…: Remove from Subnet check passed. Node 2w5be…: 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.
Reason: Without providing any MOTIVATION the proposal replaces a healthy Online node q3sji from Tbilisi Georgia with unassigned healthy Awaiting status node 2w5be from Hong Kong without any change to decentralization. Pretty sure nobody reads all the summary down to the Business rules check on the bottom so the Node provider cluster 1 should be on the top as motivation.
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.
Warning
