I’ve vote to adopt proposal 134401. The decentralisation coefficients were unchanged by the proposal. As can be observed using the IC-API, the nhr3z node operator has 3 nodes (as stated in the proposal summary). Now that this proposal has executed, one of those nodes is assigned (ct3c3).
Note that the IC-API is not open source. Since learning this, I’m in the process of switching over verifiable sources of this sort of information (rejecting because I’ve not had time to do this yet would be too harsh - even for me ).
A new proposal with id 134563 has been submitted, please take a look.
Click here to open proposal details
Replace nodes in subnet x33ed
Motivation:
replacing dead node hsctm-i3ioa-wqjxe-kiofl-x2knb-za5os-w5bi7-frpay-wjf5q-yh72k-mae
replacing node m22uy-ch26x-ymd7q-n3stg-kyoel-t3zdn-4uwqf-zu6sb-pezk4-swax5-yqe to optimize network topology
Calculated potential impact on subnet decentralization if replacing:
1 additional node would result in: (gets better) the number of nodes controlled by dominant Country actors decreases from 13 to 12
2 additional nodes would result in: equal decentralization across all features
3 additional nodes would result in: equal decentralization across all features
4 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
This proposal replaces node hsctm which is described in the proposal text as a dead node, along with an additional node in order to improve overall topology. However, node hsctm appears in the dashboard as “Status: Active” and in the Node Provider Rewards tool as having a block failure rate of less than 0.1% on most days and less than 0.3% on the last day recorded. ( @sat Am I missing something?) Nonetheless and as shown in the proposal, decentralisation parameters are improved with respect to country, so for this reason I have voted to adopt.
Replaces two nodes on subnet x33ed. The node machine hsctm is claimed to be dead but looking at the dashboard it as a status of Active and Node Provider Rewards tells us a similar story with 0% Average Failure Rate.
However, the proposal improves the decentralization coefficients with the regards to the country metric and for that reason I’ve adopted the proposal.
Yeah, the node was offline for a bit of time during the proposal submissions, when the tooling picked it up while it was in this state. The node came back online later during the day. These race conditions will be unavoidable, sadly.
replacing dead node hsctm-i3ioa-wqjxe-kiofl-x2knb-za5os-w5bi7-frpay-wjf5q-yh72k-mae
replacing node m22uy-ch26x-ymd7q-n3stg-kyoel-t3zdn-4uwqf-zu6sb-pezk4-swax5-yqe to optimize network topology
While the ‘dead node’ wasn’t dead at the time of reviewing this proposal, the node rewards dashboard shows that this node has been failing blocks fairly consistently recently, and can be considered intermittently degraded.
Decentralisation Stats on the whole are also improved by this proposal. I’ve adopted.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
0 km
7536.007 km
18505.029 km
PROPOSED
0 km
7294.297 km (-3.2%)
18505.029 km
This proposal slightly reduces decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical reduction in localised disaster resilience).
Subnet characteristic counts →
Continents
Countries
Data Centers
Owners
Node Providers
Node Operator
EXISTING
5
25
34
34
34
34
PROPOSED
5
26 (+3.8%)
34
34
34
34
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)
*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.
The proposal replaces two nodes, one healthy Active status node hsctm that was caught Offline at the time the proposal was made, from Africa, and healthy Active status node m22uy from Georgia,US, in order to optimize the network topology.
Both unassigned healthy Awaiting status node 2xph2 from Panama and unassigned healthy Awaiting status node 6hqi5 from Portugal, check out and the change improves the decentralization of the subnet.
Hey, Zack. Just to follow on from our OC DMs, where you highlighted the potential inaccuracy of the 2xph2 location in my review above. The location I use is based on the IP address, and cross-referencing with a bunch of providers.
So yeah using just the IPv6 it is not accurate. Also we are checking the correctness of the submitted proposal and not the data that was originally registered and it is used and shown in the dashboard. That is another subject for discussion trusting the Dashboard info or not.
Going deeper Data Center Owner Navegalo has a listing of a DC in Florida,US but none in NY.
So I tend to believe the location is Panama, as are the other nodes from the same Node Provider Panama node machines.
@Lorimer yes this is another case that we need to bring up with the networking team. The node is indeed in Panama city, so the IP address lookup information does seem to be incorrect. I will let them now. The sooner we have this triangulation monitoring up and running, the better!
Thanks @SvenF, I appreciate you taking a look. Can I ask how it can be considered known that this node is in Panama? How does this get determined (other than taking the NP’s word for it during onboarding)?
@Lorimer apart from IP-administration and triangulation, another way to review this would be to require to share the non-confidential information of the invoices for ordering and transfering the node machines. Either the machines have been ordered in Panama City, or shipped to Panama City. This could also be added as an extra step in the onboarding process, if everybody agrees to it.
Thanks @SvenF. If I understand you correctly the only evidence that can currently be used is IP-address-based? You’re suggesting taking into account more documentation for future onboarding? I expect such documentation could be easily forged, but nevertheless it sounds like it could be useful to include (not as something to solely depend on though).
Given that IP address geolocation is really the only source of truth with any substance, what makes you confident that this node is in Panama? All evidence I can see points to the US.
@Lorimer this is a very reliable and active node provider in the community. I will let the networking team and the node provider check the IP administration.
Hi @Lorimerthe node is part of prefix 2606:f180:9::/48 Originated by AS28110 AS Name: NAVEGALO S.A.. The upstream provider is AS52468UFINET PANAMA S.A. . It may be showing NY as the less specific prefix is 2606:f180::/32 LogicWeb Inc. which is registered there.
).
