This topic is intended to capture Subnet Management activities over time for the 5kdm2 subnet, providing a place to ask questions and make observations about the management of this subnet.
At the time of creating this topic the current subnet configuration is as follows:
The removed node is replaced with a node based in South Korea. This looks positive for decentralisation. I’ve verified that this node is currently unassigned.
I intend to take a closer look later today after work. But for now here’s some contextual info for interested voters.
Map Description
Red marker represents a removed node (transparent center for overlap visibility)
Blue marker represents an unchanged node
Highlighted patches represent the country the above nodes sit within
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 - plenty of nodes that the removed node could have been swapped with if this were a ‘Change Subnet Membership’ proposal)
I’ve rejected this proposal for numerous reasons. TLDR: It doesn’t actually fix anything, and is unjustified in violating the target IC topology, even if it’s temporary (there’s insufficient information provided in the summary to explain why they’ve proposed this removal in this way):
Expand for more details
This proposal doesn’t fix the problem of an offline node. Instead it’s removing it from the subnet for some unexplained / unjustified reason (unjustified because it’s not transactionally replacing the node with a good one)
‘Remove node from subnet’ proposals are for shrinking subnets (this isn’t and shouldn’t be the intention here). ‘Change Subnet Membership’ proposals are for fixing bad nodes in a subnet (by transactionally swapping them out for good nodes) - which is the proposal type that should have been proposed, and that this proposal should (in my opinion) be superseded by (after rejecting).
This proposal has a very poor summary (historically these types of proposals have provided much more information in the summary, such as the affected subnets, and the precise set of steps are are planned to follow the proposal). Ever since the ‘Change Subnet Membership’ proposal type was implemented, ‘Remove node from subnet’ proposals have become more or less a thing of the past (at least in this sort of scenario).
The proposal does not clearly state what the next steps would be (which IPv6 and IPv4 enabled nodes would be deployed as a next step?)
Why isn’t this being done transactionally under one proposal per subnet (why is it justifiable to ask the community to vote the subnet into a state that violates the formal target topology?)
Accepting this proposal would leave the 3 affected subnets in a state that is in violation of the formally voted in target IC topology (and in even further violation of the topology that is likely to soon be proposed - 34 nodes instead of 28 on the II subnet)
There’s only one other Subnet Management proposal proposed by this neuron historically, and it was also worthy of rejection in my opinion (currently that proposal is still open).
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.
Other good neurons to follow:
CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
TLDR: I’ve rejected this proposal as it does not solve the offline node issue, and the payload parameters appear to contains errors.
Note that node vwsvq is included in both the nodes removed and nodes added parameters of the payload. Swapping nodes is supposed to be a transactional operation (I wouldn’t be surprised if this would fail to execute).
The other node swap in this proposal is taking the opportunity to improve subnet decentralisation (given there’s already a need for a proposal). 1 of the two nodes in the USA is proposed to be replaced with one node in Singapore. This increases the country coefficient (… but it was already within the acceptable range, and other subnets are in much more need of decentralisation).
My suggestion would be to reject this proposal and resubmit one that solves the offline node problem, and raise other proposals to address the subnets that are currently violating the target IC topology before looking to improve the topology of subnets that are not formally in need of it (unless it’s a strategic move to help free up nodes that are needed by other subnets - but this should be clearly explained).
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
3.534 km
7115.008 km
16955.201 km
PROPOSED
3.534 km
6874.501 km (-3.4%)
16955.201 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
EXISTING
4
10
13
13
13
PROPOSED
4
11 (+9.1%)
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)
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.
Other good neurons to follow:
CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
TLDR: I’ve adopted this proposal. Two dead nodes replaced with two up nodes This also has the side-effect of a slight increase in decentralisation in terms of average geographic distance between nodes and country diversity
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
3.534 km
7115.008 km
16955.201 km
PROPOSED
3.534 km
7231.464 km (+1.6%)
16955.201 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
EXISTING
4
10
13
13
13
PROPOSED
4
11 (+9.1%)
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)
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.
Other good neurons to follow:
CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
DFINITY will submit an NNS proposal today to reduce the notarization delay on the subnet, 5kdm2, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread).
Voted to adopt proposal 134038, as the reasoning is sound and the proposal description matches the payload.
This proposal is intended to replace a dead node, pzv3b, which node appears as “Status: Offline” on the dashboard. As seen in the proposal (which I verified using the DRE tool), the proposed change leaves the target topology within the requirements and improves decentralisation with respect to country.
TLDR: I’ve adopted this proposal. An offline node in South Korea and a US node that’s currently up replaced with unassigned nodes in Singapore and Belgium. Note that although the US node is currently up, the proposal replaces it to improve decentralisation metrics.
Initially it appeared to me that the country coefficient is not improved as suggested by the proposal. The map and stats below are based on IP address geolocation that I now release is inconsistent with what the IC has on record for this node. The node appeared to me to be in Canada, but on further investigation just now I see that the true location is more likely to be the US.
Assuming the node is located in the US (and not Canada), then I agree that decentralisation is improved by this proposal in terms of country limits. I’ll look into improving my tooling when I get a chance.
@sat, @SvenF, are you aware of any plans to implement a means of IC protocol + device level geolocation, to help verify the current location of a node (rather than trusting a third party service)?
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
0 km
7116.246 km
14698.952 km
PROPOSED
0 km
6519.78 km (-8.4%)
15062.77 km (+2.5%)
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
4
12
13
13
13
13
PROPOSED
4
12
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)
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.
Another good neuron to follow is Synapse (follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
Sounds like you already have some specific approach in mind @Lorimer ?
There is an ongoing activity to start showing geoip info, but we first have to make sure geoip info is actually reliable.
Hey @Lorimer I also see different geo locations using different ip lookup tools, will ask the networking people have a look at it. The node is indeed in the US, and like @sat indicates, there is an ongoing activity for a geo-lookup using triangulation.
ugqji, Dashboard Status Online, replacement improves decentralization on the Country metric (reduces number of nodes in the US from 2 to 1)
Added Nodes: ihoip and ttjeo.
The proposal was verified using the DRE tool to verify the metrics stated and that they were in line with the target topology requirements.
The proposal is correct in that it replaces offline dead node from Seoul2 pzv3b , and healthy Dallas node ugqji to improve decentralization.
The added nodes are from Singapore ihoip along with ttjeo from Seoul3.
Hi @Lorimer not yet, this topic was actually discussed in the Technical Working Group for Node Providers and is being started up. Will make sure that a thread is added shortly on this.
Hi @Lorimer the networking team has taken a look into it, and from what they can see, the IPs are part of the 2001:470::/32AS6939, which is registered in ARIN in US.
On the other hand, ip2location.io appears to have Canada in its database which might be an old registration. Maybe before the prefix 2001:470:1::/48 was actually in Canada. We dropped a note to the provider. IPv6 data coverage is typically less mature than IPv4 data so geolocation providers may lack complete accuracy here. All the more reason to work on triangulation as discussed above!
Thanks a lot for following up on this @SvenF, and for the extra info. I’m looking forward to hearing more about the planned path forward. Sounds promising
