Looks good. Thanks for the announcement, I’ve voted to adopt.
Voted to adopt proposal 133395. Reduces the notarization delay for the subnet pzp6e from 1000ms to 300ms.
Proposal 133444
TLDR: Rejected due to erroneous proposal that would leave the subnet with fewer nodes
3 nodes replaced with nodes in Croatia, Switzerland and Estonia. The Switzerland node is down, hence the need for the proposal. The other nodes are swapped in an attempt to improve decentralisation (a modest improvement in country diversity is achieved, at the slight expense continent decentralisation).
The only problem I see with this proposal is that it pretends to replace 5 nodes, but it’s actually only replacing 3 (the other 2 are removed and added within the same proposal).
- wr22o-nmso7-rmkqr-vzkv5-eg2cd-kxx3o-jbjnc-e5tjy-ety5p-rz4vf-uqe
- zzuq4-xiygt-ypkox-2tgdr-yvpzp-optye-xazeq-vnpw5-pata3-4jlle-wqe
This is normally something that I’d reject. I guess I should ask first, what would the affect actually be of adding and removing nodes within the same proposal? Would this cause the proposal to fail, would it execute and take these 2 nodes out and then bring them in again, or is the behaviour unspecified and therefore not certain? @sat and/or @SvenF, I’d value your opinion on this (I’m not sure who submitted the proposal - it wasn’t announced on the forum).
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 7972.045 km | 18505.029 km |
| PROPOSED | 0 km | 7528.823 km (-5.6%) | 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 | |
|---|---|---|---|---|---|
| EXISTING | 5 | 23 | 34 | 34 | 34 |
| PROPOSED | 5 | 25 (+8%) | 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.) →
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 13 | 3 | 1 | 1 | 1 |
| PROPOSED | 15 (+15.38%) | 3 | 1 | 1 | 1 |
This proposal does lead to a worse situation regarding continents (15 in the same continent in stead of 13). However continent isn’t currently al focus of the IC Target Topology.
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)
Table
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:
-
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)
-
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)
1 Like
UPDATE: Voted to reject proposal 133444 .
While Sygnum Bank 's yzi7p node is clearly down and needs to be replaced.
Unless a valid reason for wr22o and zzuq4 to be added and removed in the same proposal is given will vote to reject on Monday morning.
2 Likes
Voted to adopt proposal 133444.
This proposal is stated to replace 5 nodes in subnet pzp6e but in fact it only replaces 3 nodes as 2 of the nodes listed for removal are also listed as being added. This is presumably due to a quirk of the tool used for selection of nodes for removal and replacement. One of the nodes being removed, yzi7p, is indeed shown as “Status: Offline” in the IC dashboard. I checked the outcome of replacing just the 3 nodes using the DRE tool and the result was the same as shown in the proposal, in that decentralisation is improved with respect to country and all parameters remain within the requirements of the target topology.
1 Like
Hey @timk11. Have you reviewed the NNS function and followed the logic? One of my concerns is that if nodes are added before nodes are removed, the execution of this proposal could result in 2 nodes being removed from the subnet (and 3 nodes replaced), reducing the size of the subnet.
1 Like
Just had a look now and I think this is it:
It looks like your concerns are probably correct. This helpful explanation from ChatGPT also backs this up.
That’s my bad for not checking more thoroughly, and potentially a flaw in both the DRE tool and the NNS code. I had assumed that either (1) the code would remove nodes first and then add the new ones, giving the same result as if the duplicated nodes had not been included in the proposal, or (2) the proposal would fail with no harm being done.
I would now recommend that the proposal be rejected.
3 Likes
Thanks for checking @timk11, given that you agree I’ll plan to reject this proposal shortly.
3 Likes
Voted to reject proposal 133444. It aims to replace a dead node yzi7p (Dashboard Status: Offline) and in order to further improve the decentralization of the pzp6e subnet it proposes 4 more node replacements with two of those nodes being both in the list of nodes to remove and to add. As @Lorimer really well picked up, looking at the logic of Change Subnet Membership specially when setting subnet_membership_after_change the list of nodes_to_add is appended to current_subnet_nodes which is then filtered by node_ids_remove which makes any node in both lists to b removed from the subnet. The nodes in question are wr22o and zzuq4 which are prefectly healthy nodes which would be left without a replacement reducing the number of nodes on the subnet.
2 Likes
Thanks @Lorimer @timk11 @ZackDS @LaCosta for the review, the foundation chose to reject this proposal and resubmit.
The algorithm for replacing nodes selects a set of candidate node machines from which to chose a replacement node, but somehow in this situation it chose to replace nodes by itself. This was something we spotted before and thought it was corrected, but apparently the code is still not working correctly. DRE team is looking into this.
3 Likes