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
Voted to adopt proposal 134283. The proposal seeks to remove a cordoned node from the subnet and specifies that the associated data centre is being offboarded “after 48 months”. Decentralisation parameters are improved with respect to country. The necessary context is provided by this forum post and associated discussion. For future proposals of this type I recommend that the background context be included in the proposal text for ease of verification.
I’ve voted to reject proposal 134283. It makes claims that I see no clear way of verifying, and supporting statements regarding the ownership of the data centre are inconsistent with records held in the IC registry. The proposal was announced here.
Voted to adopt proposal 134283. This proposal is part of a sequence of steps to remove cordoned nodes from subnets as the associated data centeres are being offboarded after 48 months of their respective DC contracts that are still private and were signed up before the Genesis. There is a great and detailed explanation of this changes in this forum post and the forum thread it is in. In the wiki there is a series of Steps for Gen-1 Node onboarding after 48 months that need to be followed in order for the nodes to continue earning rewards which starts by making a forum post in the following thread. As we can verify no one as come forward with nodes from the DCs in this proposals so I don’t see any issues with the removal of this nodes.
Voted to adopt proposal 134403.
This proposal replaces node jlifv which appears in the dashboard as “Status: Active”, for the purpose of examining the stability of another node operator’s nodes. As shown in the proposal, community-approved decentralisation parameters are unchanged and remain within the requirements of the target topology.
I’ve vote to adopt proposal 134403. The decentralisation coefficients relevant to the IC Target Topology were unchanged by the proposal. As can be observed using the IC-API, the u4f3y node operator has 13 nodes (as stated in the proposal summary). Now that this proposal has executed, one of those nodes is assigned (rzmf2).
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 
).
Proposal 134403
Vote: ADOPT
The proposal replaces one node from subnet pzp6e:
Removed Node: jlifv
Added Node: rzmf2
The proposal was verified using the DRE tool to verify the metrics stated. The NP that controlls the node removed as at least one node active and isn’t affected by this replacement.