Yeah the tricky thing is that ic-admin seems to display null features like this which is misleading
1 Like
Looks like commit fix(registry): Ensure subnet features can be changed for subnets with… · dfinity/ic@c2e11ca · GitHub will fix this and the registry update proposal is already live. Great job.
Proposal #134441 is live.
2 Likes
Thanks for highlighting this @ZackDS. The proposal has a much better summary. However it still falls short of what I consider to be an absolute foundational requirement. It doesn’t link to any place where voters can go to see critical discussion about the proposal.
Proposal 134441
If this proposal executes, then all subnets except for the NNS and SNS subnets will have HTTP outcalls enabled. This looks good, however as mentioned above, the context provided with the proposal is significantly lacking (no forum link). This is a recurring issue with no reasonable explanation. I’ve rejected this proposal, for reasons previously described and referenced below. I’d be happy to adopt a replacement proposal that follows the prescribed procedure.
2 Likes
Voted to adopt proposal #134441.
Motivation is explained and I adopted the Fix for the Registry as well, prior to this. The missing link is not a “deal-breaker” for me in this case, and resubmitting this again with just the added link would only increase the time for the same result.
2 Likes
Proposal 134441
Vote: ADOPT
Previously rejected the proposal not only due to lack of explanation in the forum but in the proposal aswell. This has improved in this proposal.
The proposal was previously adopted but it failed due to a bug that has received a fix in Proposal 134437. I have reviewed and adopted this proposal here, with the relevant information regarding the fix being:
The following line caused the problem if let Some(old_features) = subnet_record.features where if the old_features was None the condition would evaluate to false triggering the panic Proposal attempts to change sev_enabled for Subnet '{}', but sev_enabled can only be set during subnet creation. which isn’t true. Now this if condition is replaced with if let Some(sev_enabled) = features.sev_enabled that makes sure that only sev features are not changed since this can only be set during subnet creation.
2 Likes
Voted to adopt proposal 134441.
The proposal is to enable the HTTPS outcalls features on this subnet, following fixing of the bug that prevented this from succeeding on the previous attempt. The description given in the proposal gives appropriate reasoning and context for this change. @Manu I do agree with other reviewers that ideally there should be a link in the proposal to a forum post for discussion, but a clearer approach for this has only just been agreed on in another thread so I gather this will be communicated to relevant parties over time for future reference.
3 Likes
A new proposal with id 134540 has been submitted, please take a look.
Click here to open proposal details
Replace a node in subnet 4zbus
Motivation:
The following nodes in subnet 4zbus have been cordoned and need to be removed from the subnet:
- c2vrr: offboarding ZH5 DC after 48 months; Proposal: Update Interim Gen-1 Node Provider Remuneration After 48 months - #27 by Sygnum
Decentralization Nakamoto coefficient changes for subnet 4zbus-z2bmt-ilreg-xakz4-6tyre-hsqj4-slb4g-zjwqo-snjcc-iqphi-3qe:
node_provider: 5.00 -> 5.00 (+0%)
data_center: 5.00 -> 5.00 (+0%)
data_center_owner: 5.00 -> 5.00 (+0%)
area: 5.00 -> 5.00 (+0%)
country: 4.00 -> 4.00 (+0%)
Mean Nakamoto comparison: 4.80 → 4.80 (+0%)
Overall replacement impact: equal decentralization across all features
Details
Nodes removed:
c2vrr-ynjrh-xturt-s77ah-a5efo-b726x-dgq4a-m7zdc-wvsa5-7ogz5-mqe[health: healthy]
Nodes added:
kdowl-chtwc-lkojq-lfb2l-p4w77-35pmk-3ixsh-hqhj3-uxi4k-jh7ge-mqe[health: healthy]
node_provider data_center data_center_owner area country
------------- ----------- ----------------- ---- -------
3oqw6-vmpk2-mlwlx-52z5x-e3p7u-fjlcw-yxc34-lf2zq-6ub2f-v63hk-lae 1 at2 1 Anonstake 1 Brussels Capital 1 BE 1
6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe 1 bn1 1 AtlasEdge 1 Bucuresti 1 CA 1
6r5lw-l7db7-uwixn-iw5en-yy55y-ilbtq-e6gcv-g22r2-j3g6q-y37jk-jqe 1 br2 1 Cyxtera 1 Florida 1 CH 1
7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae 1 bu1 1 DataHouse 1 Georgia 1 CZ 1
bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe 1 jv1 1 Datasite 1 Ljubljana 1 ES 1
dhywe-eouw6-hstpj-ahsnw-xnjxq-cmqks-47mrg-nnncb-3sr5d-rac6m-nae 1 lj2 1 Digital Realty 1 Madrid 1 JP 1
diyay-s4rfq-xnx23-zczwi-nptra-5254n-e4zn6-p7tqe-vqhzr-sd4gd-bqe 1 ma3 1 Equinix 1 Ontario 1 PL 1
i7dto-bgkj2-xo5dx-cyrb7-zkk5y-q46eh-gz6iq-qkgyc-w4qte-scgtb-6ae 1 sg1 1 Green.ch 1 Singapore 1 RO 1
kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae 1 sh1 1 IPCore 1 South Moravian Region 1 SE 1
rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae 1 to2 1 M247 1 Stockholm 1 SG 1
sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae 1 ty1 1 Master Internet 1 Tokyo 1 SI 1
sma3p-ivkif-hz7nu-ngmvq-ibnjg-nubke-zf6gh-wbnfc-2dlng-l3die-zqe 1 wa3 1 Telin 1 Warszawa 1 US 2
spp3m-vawt7-3gyh6-pjz5d-6zidf-up3qb-yte62-otexv-vfpqg-n6awf-lqe 1 zh5 1 -> 0 Tierpoint 1 Zurich 1
zh6 0 -> 1
1 Like
Proposal 134540
TLDR: I’ll adopt. The proposal links directly to what appears to be discussion with the NP about the proposal. Decentralisation stats look good.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 449.292 km | 5894.874 km | 16464.988 km |
| PROPOSED | 449.292 km | 5894.874 km | 16464.988 km |
Subnet characteristic counts →
| Continents | Countries | Data Centers | Owners | Node Providers | Node Operator | |
|---|---|---|---|---|---|---|
| EXISTING | 3 | 12 | 13 | 13 | 13 | 13 |
| PROPOSED | 3 | 12 | 13 | 13 | 13 | 13 |
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
| Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|
| EXISTING | 8 | 2 | 1 | 1 | 1 | 1 |
| PROPOSED | 8 | 2 | 1 | 1 | 1 | 1 |
See here for acceptable limits → Motion 132136
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)
Node Changes
| Action | Node | Status | Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|---|---|---|
| Remove |  |
||||||||
| Add | kdowl | UNASSIGNED | |
Europe | Switzerland | Zurich 6 (zh6) | Green.ch | Sygnum Bank | ciprs |
Other Nodes
| Node | Status | Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|---|---|
| najnj | UP | |
Europe | Belgium | Brussels 2 (br2) | AtlasEdge | Allusion | oorkg |
| 2h6dm | UP | |
Americas | Canada | Toronto 2 (to2) | Cyxtera | Blockchain Development Labs | 4lp6i |
| kwict | UP | |
Europe | Czechia | South Moravian Region 1 (bn1) | Master Internet | Bohatyrov Volodymyr | sjstt |
| oiso5 | UP | |
Europe | Spain | Madrid 3 (ma3) | IPCore | Vladyslav Popov | f4rto |
| ktqjk | UP | |
Asia | Japan | Tokyo (ty1) | Equinix | Starbase | cqjev |
| qzvif | UP | |
Europe | Poland | Warszawa 3 (wa3) | DataHouse | Artem Horodyskyi | ngpk7 |
| 7agd5 | UP | |
Europe | Romania | Bucharest (bu1) | M247 | Iancu Aurel | c5ssg |
| jvqnq | UP | |
Asia | Singapore | Singapore (sg1) | Telin | OneSixtyTwo Digital Capital | d4bin |
| 5zqhj | UP | |
Europe | Slovenia | Ljubljana 2 (lj2) | Anonstake | Anonstake | eu5wc |
| ozim4 | UP | |
Europe | Sweden | Stockholm 1 (sh1) | Digital Realty | DFINITY Stiftung | lgp6d |
| cvic3 | UP | |
Americas | United States of America (the) | Atlanta 2 (at2) | Datasite | BLP22, LLC | 5syyj |
| 7ak5q | UP | |
Americas | United States of America (the) | Jacksonville (jv1) | Tierpoint | Rivonia Holdings LLC | wmrev |
*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).
You may wish to follow D-QUORUM if you found this analysis helpful.
Known Neurons to follow if you're too busy to keep on top of things like this
If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.
Additional good neurons to follow:
- D-QUORUM (a highly decentralized neuron that follows neurons that have been elected by the NNS)
- Synapse (currently follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
- CodeGov (actively reviews and votes on Subnet Management proposals, and is well informed on numerous other technical topics)
- WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
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.
Voted to adopt proposal #134540.
The proposal replaces cordoned healthy Active status node c2vrr from the ZH5 Data Center in Zurich 5, Switzerland with unassigned healthy Awaiting status node kdowl from Zurich 6, Switzerland, without any change to the decentralization of the subnet.
The motivation makes sense and the provided Forum link included in the summary provides further info, also it can be checked here.
Voted to adopt proposal 134540.
This proposal replaces 2 nodes, due to offboarding ZH5 data centre. Decentralisation parameters are unchanged and remain within the requirements of the target topology. Data centre details are consistent with the links provided in the proposal.
Proposal 134540
Vote: ADOPT
Replaces cordoned node c2vrr with node kdowl on subnet 4zbus.
The reason for this proposal is to offboard ZH5 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.
A new proposal with ID 135425 has been submitted, please take a look.
Click here to open proposal details
Replace a node in subnet 4zbus
Motivation:
- replacing dead node 7ak5q
Calculated potential impact on subnet decentralization if replacing:
- 1 additional node would result in: equal decentralization across all features
Based on the calculated potential impact, not replacing additional nodes to improve optimization.
Note: the information below is provided for your convenience. Please independently verify the decentralization changes rather than relying solely on this summary.
Here is an explaination of how decentralization is currently calculated,
and there are also instructions for performing what-if analysis if you are wondering if another node would have improved decentralization more.
Decentralization Nakamoto coefficient changes for subnet 4zbus-z2bmt-ilreg-xakz4-6tyre-hsqj4-slb4g-zjwqo-snjcc-iqphi-3qe:
node_provider: 5.00 -> 5.00 (+0%)
data_center: 5.00 -> 5.00 (+0%)
data_center_owner: 5.00 -> 5.00 (+0%)
area: 5.00 -> 5.00 (+0%)
country: 4.00 -> 5.00 (+25%)
Mean Nakamoto comparison: 4.83 → 5.00 (+3%)
Overall replacement impact: (gets better) the average log2 of Nakamoto Coefficients across all features increases from 2.2683 to 2.3219
Details
Nodes removed:
7ak5q-ev3ur-nmmup-rocyw-z2kxo-bqppk-vkj22-gicfw-6h37b-cpvmc-uae[health: dead]
Nodes added:
4nkoi-tdk2r-bfboy-5dokf-zc2tp-sokpx-hqfr5-6znc4-vqnxe-kr7ro-iqe[health: healthy]
node_provider data_center data_center_owner area country
------------- ----------- ----------------- ---- -------
3oqw6-vmpk2-mlwlx-52z5x-e3p7u-fjlcw-yxc34-lf2zq-6ub2f-v63hk-lae 1 at2 1 Anonstake 1 Brussels Capital 1 BE 1
4dibr-2alzr-h6kva-bvwn2-yqgsl-o577t-od46o-v275p-a2zov-tcw4f-eae 0 -> 1 bn1 1 AtlasEdge 1 Bucuresti 1 CA 1
6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe 1 br2 1 Cyxtera 1 Florida 1 -> 0 CH 1
6r5lw-l7db7-uwixn-iw5en-yy55y-ilbtq-e6gcv-g22r2-j3g6q-y37jk-jqe 1 bu1 1 DataHouse 1 Georgia 1 CZ 1
7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae 1 jv1 1 -> 0 Datasite 1 Ljubljana 1 ES 1
bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe 1 lj2 1 Digital Realty 1 Madrid 1 JP 1
dhywe-eouw6-hstpj-ahsnw-xnjxq-cmqks-47mrg-nnncb-3sr5d-rac6m-nae 1 ma3 1 Equinix 1 Ontario 1 KR 0 -> 1
diyay-s4rfq-xnx23-zczwi-nptra-5254n-e4zn6-p7tqe-vqhzr-sd4gd-bqe 1 sg1 1 Green.ch 1 Seoul 0 -> 1 PL 1
i7dto-bgkj2-xo5dx-cyrb7-zkk5y-q46eh-gz6iq-qkgyc-w4qte-scgtb-6ae 1 sh1 1 IPCore 1 Singapore 1 RO 1
kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae 1 sl1 0 -> 1 M247 1 South Moravian Region 1 SE 1
rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae 1 to2 1 Master Internet 1 Stockholm 1 SG 1
sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae 1 ty1 1 Megazone Cloud 0 -> 1 Tokyo 1 SI 1
sma3p-ivkif-hz7nu-ngmvq-ibnjg-nubke-zf6gh-wbnfc-2dlng-l3die-zqe 1 wa3 1 Telin 1 Warszawa 1 US 2 -> 1
spp3m-vawt7-3gyh6-pjz5d-6zidf-up3qb-yte62-otexv-vfpqg-n6awf-lqe 1 -> 0 zh6 1 Tierpoint 1 -> 0 Zurich 1
Proposal 135425 | Tim - CodeGov
Vote: Adopt
This proposal replaces 1 node in subnet 4zbus, appearing in the decentralization tool as “DOWN”. As shown in the proposal, decentralisation parameters are improved with respect to country 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.
Proposal 135425 Review | Lorimer - CO.DELTA △
VOTE: YES
TLDR: 1 offline node replaced with an unassigned node, which also improves decentralisation in terms of the country IC Target Topology metric (once this proposal executes there will be 1 node per country, instead of a max of 2).
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).
| Node | Data Center | Claimed Country | According to ipinfo.io |
|---|---|---|---|
| 2h6dm | Toronto 2 | Canada | United States of America (the) |
| najnj | Brussels 2 | Belgium | United Kingdom of Great Britain and Northern Ireland (the) |
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 382.312 km | 5833.193 km | 16458.534 km |
| PROPOSED | 382.312 km | 5867.807 km (+0.6%) | 16024.773 km (-2.6%) |
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 | 3 | 12 | 13 | 13 | 13 | 13 |
| PROPOSED | 3 | 13 (+7.7%) | 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.) →
| Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|
| EXISTING | 8 | 2 | 1 | 1 | 1 | 1 |
| PROPOSED | 8 | 1 (-50%) | 1 | 1 | 1 | 1 |
See here for acceptable limits → Motion 132136
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.
Node Changes
| Action | Node | Status | Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|---|---|---|
| Remove | |
||||||||
| Add | 4nkoi | UNASSIGNED | |
Asia | Korea (the Republic of) | Seoul 1 (sl1) | Megazone Cloud | Neptune Partners | ukji3 |
Other Nodes
| Node | Status | Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|---|---|
| najnj | UP | |
Europe | Belgium | Brussels 2 (br2) | AtlasEdge | Allusion | oorkg |
| 2h6dm | UP | |
North America | Canada | Toronto 2 (to2) | Cyxtera | Blockchain Development Labs | 4lp6i |
| kdowl | UP | |
Europe | Switzerland | Zurich 6 (zh6) | Green.ch | Sygnum Bank | ciprs |
| kwict | UP | |
Europe | Czechia | South Moravian Region 1 (bn1) | Master Internet | Bohatyrov Volodymyr | sjstt |
| oiso5 | UP | |
Europe | Spain | Madrid 3 (ma3) | IPCore | Vladyslav Popov | f4rto |
| ktqjk | UP | |
Asia | Japan | Tokyo (ty1) | Equinix | Starbase | cqjev |
| qzvif | UP | |
Europe | Poland | Warszawa 3 (wa3) | DataHouse | Artem Horodyskyi | ngpk7 |
| 7agd5 | UP | |
Europe | Romania | Bucharest (bu1) | M247 | Iancu Aurel | c5ssg |
| ozim4 | UP | |
Europe | Sweden | Stockholm 1 (sh1) | Digital Realty | DFINITY Stiftung | lgp6d |
| jvqnq | UP | |
Asia | Singapore | Singapore (sg1) | Telin | OneSixtyTwo Digital Capital | d4bin |
| 5zqhj | UP | |
Europe | Slovenia | Ljubljana 2 (lj2) | Anonstake | Anonstake | eu5wc |
| cvic3 | UP | |
North America | United States of America (the) | Atlanta 2 (at2) | Datasite | BLP22, LLC | 5syyj |
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.
1 Like
Proposal 135425 Review | aligatorr - CO.DELTA △
VOTE: YES
TLDR: Replaces unhealthy node.
- Proposed topology Nakamoto Coefficient is better than current.
Node Changes 1 removed, 1 added
| Node ID | Status | Country | City | Node Provider | Data Center | Data Center Owner |
|---|---|---|---|---|---|---|
7ak5q-ev3ur-nmmup-rocyw-z2kxo-bqppk-vkj22-gicfw-6h37b-cpvmc-uae4nkoi-tdk2r-bfboy-5dokf-zc2tp-sokpx-hqfr5-6znc4-vqnxe-kr7ro-iqe |
DOWN → UNASSIGNED |
Current Nakamoto Coefficients and Topology, avg = 4.80
| Attribute | Nakamoto Coefficient | Identical attribute values | Max allowed identical values | Unique Counts |
|---|---|---|---|---|
| Country | 4 | 2, US | 2 | 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 |
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.
1 Like
Proposal 135425 Review | Malith H - CO.DELTA △
VOTE: YES 
TLDR:
The proposal replaces offline nodes in Jacksonville (North America).
As decentralization increased and there were found in the nodes or locations proposed. I vote to adopt.
Provider Changes
| Removed | Added |
|---|---|
| Rivonia Holdings LLC | Neptune Partners |
Location Changes
| Removed | Added |
|---|---|
| North America, Jacksonville | Asia, Seoul 1 |
Nodes Removed 1
| Node ID | Status | Provider | Data Center | Location |
|---|---|---|---|---|
| 7ak5q… | DOWN | Rivonia Holdings LLC | jv1 | Jacksonville |
Nodes Added 1
| Node ID | Status | Provider | Data Center | Location |
|---|---|---|---|---|
| 4nkoi… | UNASSIGNED | Neptune Partners | sl1 | Seoul 1 |
Passes:
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.
1 Like
Proposal #135425 — Zack | CodeGov
Vote: Adopted
Reason:
The proposal replaces dead Offline status node 7ak5q from the JV1 DC in Florida, with unassigned healthy Awaiting status node 4nkoi from Seoul 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.
Proposal 135425 – LaCosta | CodeGov
Vote: ADOPT
The proposal replaces a dead nodes on subnet 4zbus:
dead node 7ak5q Dashboard Status: Offline with node 4nkoi Dashboard 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.
A new proposal with ID 135992 has been submitted, please take a look.
Click here to open proposal details
Replace a node in subnet 4zbus
Motivation:
- replacing dead node kwict
Calculated potential impact on subnet decentralization if replacing:
- 1 additional node would result in: equal decentralization across all features
Based on the calculated potential impact, not replacing additional nodes to improve optimization.
Note: the information below is provided for your convenience. Please independently verify the decentralization changes rather than relying solely on this summary.
Here is an explaination of how decentralization is currently calculated,
and there are also instructions for performing what-if analysis if you are wondering if another node would have improved decentralization more.
Decentralization Nakamoto coefficient changes for subnet 4zbus-z2bmt-ilreg-xakz4-6tyre-hsqj4-slb4g-zjwqo-snjcc-iqphi-3qe:
node_provider: 5.00 -> 5.00 (+0%)
data_center: 5.00 -> 5.00 (+0%)
data_center_owner: 5.00 -> 5.00 (+0%)
area: 5.00 -> 5.00 (+0%)
country: 5.00 -> 5.00 (+0%)
Mean Nakamoto comparison: 5.00 → 5.00 (+0%)
Overall replacement impact: equal decentralization across all features
Details
Nodes removed:
kwict-ujiu6-u4ss3-nlwqq-dchsd-2h5lh-nzkke-24ij3-3otqq-rswre-vqe[health: dead]
Nodes added:
bqplp-iejs2-2awcz-oiy6u-62jzx-rzp66-z4eba-m6nan-dtljh-bb4pn-rae[health: healthy]
node_provider data_center data_center_owner area country
------------- ----------- ----------------- ---- -------
3oqw6-vmpk2-mlwlx-52z5x-e3p7u-fjlcw-yxc34-lf2zq-6ub2f-v63hk-lae 1 at2 1 Anonstake 1 Brussels Capital 1 BE 1
4dibr-2alzr-h6kva-bvwn2-yqgsl-o577t-od46o-v275p-a2zov-tcw4f-eae 1 bn1 1 -> 0 AtlasEdge 1 Bucuresti 1 CA 1
6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe 1 br2 1 Cyxtera 1 Georgia 1 CH 1
6r5lw-l7db7-uwixn-iw5en-yy55y-ilbtq-e6gcv-g22r2-j3g6q-y37jk-jqe 1 bu1 1 DataHouse 1 HongKong 0 -> 1 CZ 1 -> 0
7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae 1 hk1 0 -> 1 Datasite 1 Ljubljana 1 ES 1
bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe 1 lj2 1 Digital Realty 1 Madrid 1 HK 0 -> 1
dhywe-eouw6-hstpj-ahsnw-xnjxq-cmqks-47mrg-nnncb-3sr5d-rac6m-nae 1 -> 0 ma3 1 Equinix 1 Ontario 1 JP 1
diyay-s4rfq-xnx23-zczwi-nptra-5254n-e4zn6-p7tqe-vqhzr-sd4gd-bqe 1 sg1 1 Green.ch 1 Seoul 1 KR 1
g2ax6-jrkmb-3zuh3-jibtb-q5xoq-njrgo-5utbc-j2o7g-zfq2w-yyhky-dqe 0 -> 1 sh1 1 IPCore 1 Singapore 1 PL 1
i7dto-bgkj2-xo5dx-cyrb7-zkk5y-q46eh-gz6iq-qkgyc-w4qte-scgtb-6ae 1 sl1 1 M247 1 South Moravian Region 1 -> 0 RO 1
kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae 1 to2 1 Master Internet 1 -> 0 Stockholm 1 SE 1
rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae 1 ty1 1 Megazone Cloud 1 Tokyo 1 SG 1
sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae 1 wa3 1 Telin 1 Warszawa 1 SI 1
sma3p-ivkif-hz7nu-ngmvq-ibnjg-nubke-zf6gh-wbnfc-2dlng-l3die-zqe 1 zh6 1 Unicom 0 -> 1 Zurich 1 US 1
1 Like
Proposal 135992 Review | aligatorr - CO.DELTA △
VOTE: YES
TLDR: Replaces node that has had a high failure rate recently NodeLink
- Proposed topology Nakamoto Coefficient stayed the same as on current topology.
Node Changes 1 removed, 1 added
| Node ID | Status | Country | City | Node Provider | Data Center | Data Center Owner |
|---|---|---|---|---|---|---|
kwict-ujiu6-u4ss3-nlwqq-dchsd-2h5lh-nzkke-24ij3-3otqq-rswre-vqebqplp-iejs2-2awcz-oiy6u-62jzx-rzp66-z4eba-m6nan-dtljh-bb4pn-rae |
UP → UNASSIGNED |
Current 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 | 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 | 2 | 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.
2 Likes