This topic is intended to capture Subnet Management activities over time for the c4isl subnet, providing a place to ask questions and make observations about the management of this subnet.
TLDR: Replaces 4 nodes (2 unnecessarily), even though the failure domain is 5. This means the subnet will be in a precarious position during the node sync process (1 additional node failure and the subnet stalls).
2 nodes are offline, and this proposal swaps them for online nodes, however it also swaps 2 other nodes with no explanation (most likely in an attempt to optimise decentralisation coefficients). In total 4 nodes would be removed, and replaced with nodes that will not be productive immediately (it takes time for new nodes to assimilate with the subnet).
@DRE-Team, can you confirm if you accounted for this risk, and provide some additional commentary. Without this I will plan to reject within the next 2 days. Thanks.
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
224.22 km
6626.101 km
16395.058 km
PROPOSED
447.373 km (+99.5%)
7228.489 km (+9.1%)
16379.519 km (-0.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
13 (+15.4%)
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 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.
This proposes to replace 4 nodes in subnet c4isl. Two of these are dead nodes but no explanation is given for the other 2 nodes. Presumably the intention is to improve network decentralisation, but this should be stated in the proposal summary as it has been for previous similar proposals. The instructions for verifying the changes have also been removed. These should really be kept in place for the benefit of any new reviewers who may come onboard as well as for anyone else who wishes to verify the details before voting. I am also concerned about having only 9 of the 13 nodes online during the transition, as pointed out in the previous review.
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, API Boundary API Boundary Node 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: This proposal is intended to supercede the prior proposal (see previous review). My tooling has flagged this as a warning (multiple open proposals affecting the same nodes). To err on the side of caution (avoiding potential for unspecified behaviour), I’ll hold of adopting this proposal until the prior one has been rejected by the NNS (Update: DONE).
Decentralisation stats are unchanged by this proposal, and the dead nodes are replaced by healthy ones.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
224.22 km
6626.101 km
16395.058 km
PROPOSED
224.22 km
6828.855 km (+3.1%)
16379.519 km (-0.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
11
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.
Yes, the other two replacements were done by the DRE tool to improve the Nakamoto coefficients in the ‘country’ parameter, from 4.67 to 5 overall. But you are also right that replacing 4 nodes simultaneously in a 13 node subnet doesn’t leave any room for error during the swap. I’ll reject this proposal and submit a new one that only replaces dead nodes.
Thanks @alexu ! What about those extra details though - decentralisation comments (although not really needed for the new proposal) and verification instructions?
Current Nakamoto Coefficients and Topology, avg = 4.60
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
3
2
11
City
5
NA
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
2
13
City
5
NA
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.
Current Nakamoto Coefficients and Topology, avg = 4.60
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
3
2
11
City
5
NA
13
Data Center
5
1
13
Data Center Owner
5
1
13
Node Provider ID
5
1
13
Proposed Nakamoto Coefficients and Topology, avg = 4.60
Attribute
Nakamoto Coefficient
Identical attribute values
Max allowed identical values
Unique Counts
Country
3
2
11
City
5
NA
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.
Reason:
The first proposal aimed to replace 2 dead nodes and additional 2 healthy nodes in order to increase the country parameter, Dfinity resubmitted the modified 137682 and plans to reject this first one.
The second proposal only replaces the 2 dead nodes iqnlc from Africa and mwrqx from Hong Kong with healthy unassigned nodes c6vcy from Singapore and u7xea from Africa without any change to decentralization.
As mentioned by @timk11 the missing details from the proposal is a step back from the agreed upon direction.
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.
This proposal replaces 2 nodes which appear in the dashboard as “Offline”. The replacement nodes appear in the dashboard as “Healthy”. As shown in the proposal and verified using the DRE tool, decentralisation parameters are unchanged and remain outside the requirements of the target topology given that there are 2 countries that each have 2 nodes in the subnet. However, fixing this at the same time would put the subnet into a vulnerable state, as noted in the responses to proposal 137677.
I note again that verification instructions are missing from this 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, API Boundary API Boundary Node 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.
Summary:
The proposal aims to replace 4 nodes on subnet c4isl two of which are currently dead. The unspecified reason implied by the replacement of 2 more nodes is that this will improve the decentralization of the subnet (currently there are two countries with two nodes each on the subnet, which the proposal would reduce to 1 by replacing nodes with others which the countries are not on the subnet).
The problem with this replacement is that this is an Application Subnet, which means it has 13 nodes. By removing 4 nodes before adding 4 again, the subnet will temporarily have a total of 9 nodes. For a subnet to fail 1/3 of it’s nodes need to fail or misbehave. 13 * 1/3 = 4.3, which means that with 4 being removed (becoming unavailable), 1 more node would halt the subnet.
Added Nodes: nodes 2katp, Dashboard Status: Healthy and Not assigned to a subnet, f3t2w, Dashboard Status: Healthy and Not assigned to a subnet, pgjz5, Dashboard Status: Healthy and Not assigned to a subnet and u7xea, Dashboard Status: Healthy and Not assigned to a subnet
Improves decentralization by increasing the Nakamoto Coefficient of the country metric from 3 to 5 (+67%)
Added Nodes: nodes c6vcy, Dashboard Status: Healthy and Not assigned to a subnet and u7xea, Dashboard Status: Healthy and Not assigned to a subnet
The decentralization remains unchanged 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:
This proposal removes 4 node(s) from Atlanta 2, Zurich 6, Gauteng 1, HongKong 1 and adds 4 replacement node(s) in Panvel 2, Seoul 3, Singapore 3, Gauteng 3.
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 removes 2 node(s) from Gauteng 1, HongKong 1 and adds 2 replacement node(s) in Singapore 3, Gauteng 3.
This proposal is a proper version of replacing dead nodes in the previous proposal 137677. No issues found vote to adopt considering the previous proposal will be rejected.
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.
No discrepancies found. All parameters for the proposed node, node operator and data center are correct.
Context: This proposal is part of the offboarding process of Bohatyrov Volodymyr and subsequent pass of nodes to Vladyslav Popov. Volodymyr announced the sale here. Vladyslav is already a NP with 7 nodes in his name, of which 5 are currently active in subnets across Europe.
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: This proposal replaces a node that is due to be transferred to another NP. Even though both NPs own nodes in the same rack, formal procedure still needs carrying out which requires removing the node from the subnet and also the registry. Thanks to @MalithHatananchchige for talking me through the process of transferring nodes.
As a side effect, the replacement node improves decentralisation stats (see below).
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
224.22 km
6828.855 km
16379.519 km
PROPOSED
224.22 km
7476.286 km (+9.5%)
16379.519 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
4
11
13
13
13
13
PROPOSED
4
11
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.
This proposal replaces node 3beeq which appears in the dashboard as
xxx nodes which appear in the dashboard as “Healthy”, in preparation for transfer to another node provider as per the announcement here by the current node provider Bohatyrov Volodymyr. The replacement node appears in the dashboard as “Healthy”. 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, API Boundary API Boundary Node 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.
