Subnet Management - uzr34 (II)

[Lorimer]

This topic is intended to capture Subnet Management activities over time for the uzr34 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:

Expand

{
  "version": 44580,
  "records": [
    {
      "key": "subnet_record_uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe",
      "version": 44580,
      "value": {
        "membership": [
          "mswad-oq7wj-5r4yy-b5qoy-cmv7z-wzfb3-ktn6l-rcnrz-mni2f-lsys6-wqe",
          "xu2zg-nns7x-z67l6-foa5w-yc4ek-addku-g2hqg-c3jdg-wabdu-5ouaw-yae",
          "v27at-hedf7-4a2my-tboq6-escdm-77krt-2qfuq-zjptf-z2sbk-vd7zs-xae",
          "vgfnl-4phvh-44pk3-yshmp-ckwz3-qnzob-l5wnj-pqn2j-vv5jh-3oewk-xqe",
          "xav3a-kdo3a-2rgbg-o6vnk-clat5-bcc7w-vmnej-z55rx-mfx26-7xugo-tqe",
          "67t6p-i4h3c-msv6p-kmbmm-rr6gj-z3nix-d6lo2-mq3q4-3h6rb-lwkbc-lae",
          "gtfa3-saq3t-ymlel-lsf6d-ans7b-cr45x-xg5np-xbxyt-nxfrt-iynyy-5qe",
          "zjiki-pzvnv-m4rnn-fodt3-poon4-uldx7-d3wkq-gptsu-g2mjs-boi35-3qe",
          "aajth-ndp7x-ro5ok-yikyd-4i7xn-5k5ki-e3d37-hh4gn-s4opz-bnzxf-4qe",
          "ysjs7-fe67q-k7pxe-g4puk-d5z7p-xrtg2-xqcmy-pmpoa-7bcfu-pmlqy-rae",
          "y7bml-csbq7-euzyf-njmvm-qfftp-iy7lc-wisaq-jlmul-sdo7p-7lkx4-3ae",
          "v2pkj-vpsow-fp24q-zqwfj-p3nek-m52xz-oz6ra-blmra-73voj-jvwb5-gae",
          "qp3lh-25yxy-dlk4t-ay73d-frr4t-3kmi5-35kqg-3vvbq-26qhh-6xrdr-oqe",
          "x3cey-uerdd-53a7n-d45e2-gjsnd-airg5-nrs5i-4xujk-c5ynl-4pie6-yqe",
          "6adxp-p7u63-xsdtk-lo6oc-vpqmi-44hgt-yv652-cbm5p-mssge-wsrz6-oqe",
          "xetvj-ysqpy-wnnd4-fbytw-n6arq-w7f5e-fhsuo-7xd67-lwpt2-novnx-iae",
          "w4ri3-ytfnq-jg3z3-qseka-se4xe-b2fl2-km766-ruzwd-riw72-6bifs-4ae",
          "wjwzb-q3ogf-fi3po-kf6y6-wzuuj-3ac3m-kjvab-fufsm-z2skq-kthkx-xae",
          "zgeaf-fcq4e-fcnht-g7mpg-sb7ff-r6awk-zvkwp-gkloc-rr6jl-ghsse-mqe",
          "ylm4h-mc2vy-vmwvf-g2qhn-36rbw-5cunq-wpj2j-ttofo-xc27c-vfdh7-aae",
          "z5a4h-43szy-vvp4j-xorii-l6yma-4iyzt-7o3ry-frvqe-azkit-5iag2-rqe",
          "yi6r6-u4kax-jphcr-jcqr5-t3zpm-gmp3b-2hiew-iinpf-sgjos-eabha-aqe",
          "uouxk-c246i-dgxzd-ql3a5-koofn-mclrv-toplo-bg76d-l4dzk-ngb3c-nae",
          "z4jw5-v4ee6-aa7gr-5axkc-4ocjy-v5vv5-inwc6-ma4hw-mb7jv-3skxy-eqe",
          "zgtrt-4vlgr-pbytl-t2yqq-qf4nk-wyoos-vrfpu-hxqcw-tcnfu-73kjb-pae",
          "go5zz-xs6yg-mylwl-v7uob-7bg4b-wjzhe-vmrwe-uy7mz-ckaz2-idm33-rqe",
          "ham46-r7u4j-yoyrk-mrnxu-utzq3-c37he-vcns2-gc5yg-jxyv5-mvlhc-gae",
          "v6caw-kf4b4-j22f5-pqsvj-hg7dj-wx4xx-y7urh-eixmh-hnvz7-hoe2v-jae"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 3670016,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 3000,
        "initial_notary_delay_millis": 1000,
        "replica_version_id": "3d0b3f10417fc6708e8b5d844a0bac5e86f3e17d",
        "dkg_interval_length": 499,
        "start_as_nns": false,
        "subnet_type": "system",
        "features": {
          "canister_sandboxing": false,
          "http_requests": true,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [
          ""
        ],
        "ssh_backup_access": [
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEVcbYyW9CASaIa8wh07Dvm5dCeh0P/YgRP9Kwr38gB5 consensus@10.31.0.141",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICsO2IEV96tOVfjoOj450TZr4MD8PauHqhcLYvrmRRue pfops@sf1-spm12",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMz75Tyjsl6gxOJz0zHIvcQcMquIm7DHBB62ReJbRkk9 op@pyr07"
        ],
        "ecdsa_config": {
          "quadruples_to_create_in_advance": 1,
          "key_ids": [
            {
              "curve": "secp256k1",
              "name": "key_1"
            }
          ],
          "max_queue_size": 20,
          "signature_request_timeout_ns": 1800000000000,
          "idkg_key_rotation_period_ms": 1209600000
        },
        "chain_key_config": {
          "key_configs": [
            {
              "key_id": {
                "Ecdsa": {
                  "curve": "secp256k1",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 1,
              "max_queue_size": 20
            },
            {
              "key_id": {
                "Schnorr": {
                  "algorithm": "bip340secp256k1",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 1,
              "max_queue_size": 20
            },
            {
              "key_id": {
                "Schnorr": {
                  "algorithm": "ed25519",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 1,
              "max_queue_size": 20
            }
          ],
          "signature_request_timeout_ns": 1800000000000,
          "idkg_key_rotation_period_ms": 1209600000
        }
      }
    }
  ]
}

[Lorimer]

@andrea kindly provided a reference for the recent urz34 (II system subnet) proposals here → Subnet Management - pzp6e (Fiduciary) - Developers - Internet Computer Developer Forum (dfinity.org)

@andrea

For the Schnorr keys, we are proposing to back them up on subnet uzr34, which has the same size as the fiduciary subnet and serves as backup subnet of the ECDSA production key. Note that the key backup process requires the backup subnet to pause while the key is being reshared. Since the proposed backup subnet hosts the II canister smart contract, this will not process new messages while the backup is in progress.

As this process is not yet fully automated, it requires 3 NNS proposals to be submitted, voted on, and executed in sequence. The result is downtime for the II subnet, estimated to be between 6-10 minutes

1. Proposal: 131506 - ICP Dashboard (internetcomputer.org)

   • “Halt subnet uzr34 at the next CUP height and update ssh readonly access. This is the first proposal (out of three) for resharing the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 from subnet pzp6e to subnet uzr34.”

2. Proposal: 131510 - ICP Dashboard (internetcomputer.org)

   • “Reshare the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 to subnet uzr34 by updating its recovery CUP. This is the second proposal (out of three) for resharing the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 from subnet pzp6e to subnet uzr34”

3. Proposal: 131511 - ICP Dashboard (internetcomputer.org)

   • “Unhalt subnet uzr34 and remove ssh readonly access. This is the third and last proposal for resharing the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 from subnet pzp6e to subnet uzr34”

I adopted the 1st and 3rd proposals, but rejected the update recovery CUP proposal, as discussed here. Nevertheless, I’m super excited to see these signature schemes used outside the context of the test key subnets

[timk11]

A proposed change to IC target topology that will affect this subnet has been announced in this post.

[Lorimer]

There’s an open proposal for removing a node from this subnet (along with 2 other subnets - 5kdm2 (Application) and tdb26 (NNS))

• Proposal 132102

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)

Table

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	ylm4h-mc2vy-vmwvf-g2qhn-36rbw-5cunq-wpj2j-ttofo-xc27c-vfdh7-aae	DOWN
	Americas	Argentina	CABA 1 (ar1)	SyT - Servicios y Telecomunicaciones S.A.	Mariano Stoll	v27at-hedf7-4a2my-tboq6-escdm-77krt-2qfuq-zjptf-z2sbk-vd7zs-xae	UP
	Oceania	Australia	Queensland 1 (sc1)	NEXTDC	ANYPOINT PTY LTD	zjiki-pzvnv-m4rnn-fodt3-poon4-uldx7-d3wkq-gptsu-g2mjs-boi35-3qe	UP
	Europe	Belgium	Antwerp (an1)	Datacenter United	Allusion	xu2zg-nns7x-z67l6-foa5w-yc4ek-addku-g2hqg-c3jdg-wabdu-5ouaw-yae	UP
	Americas	Canada	Toronto (to1)	Cyxtera	Blockchain Development Labs	x3cey-uerdd-53a7n-d45e2-gjsnd-airg5-nrs5i-4xujk-c5ynl-4pie6-yqe	UP
	Europe	Switzerland	Zurich 3 (zh3)	Nine.Ch	Tomahawk.vc	v2pkj-vpsow-fp24q-zqwfj-p3nek-m52xz-oz6ra-blmra-73voj-jvwb5-gae	UP
	Asia	China	HongKong 1 (hk1)	Unicom	Pindar Technology Limited	w4ri3-ytfnq-jg3z3-qseka-se4xe-b2fl2-km766-ruzwd-riw72-6bifs-4ae	UP
	Americas	Costa Rica	Bogota 1 (bg1)	EdgeUno	Geeta Kalwani	aajth-ndp7x-ro5ok-yikyd-4i7xn-5k5ki-e3d37-hh4gn-s4opz-bnzxf-4qe	UP
	Europe	Czechia	South Moravian Region 1 (bn1)	Master Internet	Maksym Ishchenko	zgtrt-4vlgr-pbytl-t2yqq-qf4nk-wyoos-vrfpu-hxqcw-tcnfu-73kjb-pae	UP
	Europe	Germany	Frankfurt 2 (fr2)	Equinix	Virtual Hive Ltd	ysjs7-fe67q-k7pxe-g4puk-d5z7p-xrtg2-xqcmy-pmpoa-7bcfu-pmlqy-rae	UP
	Europe	Spain	Madrid 1 (ma1)	Ginernet	Ivanov Oleksandr	yi6r6-u4kax-jphcr-jcqr5-t3zpm-gmp3b-2hiew-iinpf-sgjos-eabha-aqe	UP
	Europe	Estonia	Tallinn 2 (ta2)	Telia DC	Artem Horodyskyi	zgeaf-fcq4e-fcnht-g7mpg-sb7ff-r6awk-zvkwp-gkloc-rr6jl-ghsse-mqe	UP
	Asia	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	uouxk-c246i-dgxzd-ql3a5-koofn-mclrv-toplo-bg76d-l4dzk-ngb3c-nae	UP
	Asia	India	New Delhi 1 (nd1)	Marvelous Web3 DC	Marvelous Web3	67t6p-i4h3c-msv6p-kmbmm-rr6gj-z3nix-d6lo2-mq3q4-3h6rb-lwkbc-lae	UP
	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	xetvj-ysqpy-wnnd4-fbytw-n6arq-w7f5e-fhsuo-7xd67-lwpt2-novnx-iae	UP
	Asia	Japan	Tokyo (ty1)	Equinix	Starbase	go5zz-xs6yg-mylwl-v7uob-7bg4b-wjzhe-vmrwe-uy7mz-ckaz2-idm33-rqe	UP
	Asia	Korea (the Republic of)	Seoul 2 (kr2)	Gasan	Web3game	wjwzb-q3ogf-fi3po-kf6y6-wzuuj-3ac3m-kjvab-fufsm-z2skq-kthkx-xae	UP
	Europe	Poland	Warszawa 2 (wa2)	Central Tower DC	Bohatyrov Volodymyr	mswad-oq7wj-5r4yy-b5qoy-cmv7z-wzfb3-ktn6l-rcnrz-mni2f-lsys6-wqe	UP
	Asia	Singapore	Singapore 2 (sg2)	Telin	OneSixtyTwo Digital Capital	qp3lh-25yxy-dlk4t-ay73d-frr4t-3kmi5-35kqg-3vvbq-26qhh-6xrdr-oqe	UP
	Europe	Slovenia	Ljubljana (lj1)	Posita.si	Fractal Labs AG	6adxp-p7u63-xsdtk-lo6oc-vpqmi-44hgt-yv652-cbm5p-mssge-wsrz6-oqe	UP
	Europe	Sweden	Stockholm 1 (sh1)	Digital Realty	DFINITY Operations SA	vgfnl-4phvh-44pk3-yshmp-ckwz3-qnzob-l5wnj-pqn2j-vv5jh-3oewk-xqe	UP
	Americas	United States of America (the)	Atlanta (at1)	Flexential	BLP22, LLC	v6caw-kf4b4-j22f5-pqsvj-hg7dj-wx4xx-y7urh-eixmh-hnvz7-hoe2v-jae	UP
	Americas	United States of America (the)	Chicago 3 (ch3)	CyrusOne	MI Servers	gtfa3-saq3t-ymlel-lsf6d-ans7b-cr45x-xg5np-xbxyt-nxfrt-iynyy-5qe	UP
	Americas	United States of America (the)	Fremont (fm1)	Hurricane Electric	Boolean Bit, LLC	z4jw5-v4ee6-aa7gr-5axkc-4ocjy-v5vv5-inwc6-ma4hw-mb7jv-3skxy-eqe	UP
	Americas	United States of America (the)	Houston (hu1)	TRG	43rd Big Idea Films	ham46-r7u4j-yoyrk-mrnxu-utzq3-c37he-vcns2-gc5yg-jxyv5-mvlhc-gae	UP
	Americas	United States of America (the)	Orlando (or1)	Datasite	Giant Leaf, LLC	z5a4h-43szy-vvp4j-xorii-l6yma-4iyzt-7o3ry-frvqe-azkit-5iag2-rqe	UP
	Americas	United States of America (the)	Panama City 1 (pc1)	Navegalo	Bianca-Martina Rohner	y7bml-csbq7-euzyf-njmvm-qfftp-iy7lc-wisaq-jlmul-sdo7p-7lkx4-3ae	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Karel Frank	xav3a-kdo3a-2rgbg-o6vnk-clat5-bcc7w-vmnej-z55rx-mfx26-7xugo-tqe	UP

[Lorimer]

@Lorimer

I intend to take a closer look later today after work

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)

@SvenF

• 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)

[MalithHatananchchige]

Hi @Lorimer
As per our discussion here, the reason is highlighted

Subnet Management - tdb26 (NNS)

Hi @Lorimer My apologies for the very bad miscommunication and bad summary of the reason why these nodes were taken offline for IPv6 Migration. I was not aware of the independent review and will fix our communication on the forum better. I only have communicated my intent on Element Matrix Channel [Screenshot 2024-08-23 at 9.36.19 AM] A few weeks back. Reason for removing from subnet : The ISP has assigned us IP addresses that are not recognized as local, even though the latency remains t…

I think this is the first time NP ongoing maintenance is happening. There might be future reasons where hardware failure, or network device failure for the redeployment of nodes.

Thus NP wiki is getting improved with these learnings. Right now it is at its basically level of info for ongoing node maintenance
https://wiki.internetcomputer.org/wiki/Changing_IPv6_addresses_of_nodes

[Lorimer]

Thanks @MalithHatananchchige, I really appreciate your reaching out and providing some clarity. This really helps, and I’m glad to see that you’re open to improving processes in the future .

Regarding the removal of the nodes from the subnet, can I ask why this was not a proposal to swap in a good node (so that the subnet topology, in terms of cardinality, is not formally modified)? I’m still of the impression that this proposal should be rejected, and replaced with a ‘Change Subnet Membership’ proposal (as highlighted there are plenty of spare nodes to swap into the network). This would then free up your CM1 nodes so that they can be removed from the wider network and redeployed with IPv4 and IPv6 addresses.

[MalithHatananchchige]

@Lorimer

Change Subnet Membership’ proposal

I wasn’t aware that this was the correct procedure. The Dfinity team had initially suggested following the guidelines outlined here: Changing IPv6 addresses of nodes.

However, after reviewing your input, it makes more sense to change the subnet membership rather than removing the node from the subnet entirely. This highlights a significant knowledge gap, as well as the need for clearer documentation regarding which proposals to use in different situations.

I fully agree that taking nodes offline isn’t the best approach, especially when we have plenty of spare nodes that can be swapped in. In fact, the migration process itself takes less than an hour, so minimizing downtime is entirely feasible.

That said, wouldn’t introducing another NNS proposal potentially increase the downtime even further while waiting for approval? If the current proposal is adopted, I could redeploy all nodes back online within an hour. Just a suggestion to consider.

[Lorimer]

@MalithHatananchchige

That said, wouldn’t introducing another NNS proposal potentially increase the downtime even further while waiting for approval? If the current proposal is adopted, I could redeploy all nodes back online within an hour. Just a suggestion to consider.

You could submit a proposal to add or swap a replacement node into the subnet now (you don’t need to wait). Just inform voters that they should reject the prior proposal in your proposal summary. At least, this is my understanding.

I agree that documentation is lacking. I’m basing my opinion and voting decision-making off of my own critical thinking, and formally voted in IC target subnet topology that should not be violated without good reason (in my opinion).

Busy day at work now for me, so I won’t be able to respond until later, FYI

[SvenF]

Hi @MalithHatananchchige @Lorimer thanks for this discussion and allow me to join in as well. Agree that the wiki documentation can be improved on this, but indeed the common approach for node maintenance (and I think that is usually agreed in the Element channel as well) is to

1. swap the node that needs to be upgraded (or nodes that are unhealthy or dead and require and upgrade) for another node that is healthy.
2. now that the node to be upgraded is “not active in a subnet”, to remove that node from the IC so it can be upgraded.

The reason is that removing an active node from a subnet would reduce that subnet size to 12 (for a 13 node subnet) and 33 (for a 34 node subnet) which we want to avoid as this effectively creates a subnet with fewer nodes and this would reduce the thresholds on the subnet.

I also agree that before submitting a proposal it would be good to announce it on the forum, so that it can be discussed and will avoid unncessary rejects on the proposal and the loss of ICP of course due to that.

@MalithHatananchchige for the above reason the Foundation will reject proposal 131977 and proposal 132102. Can I suggest you to align with me and @sat on the Element channel so we can help with submitting the node swap proposals first? After these proposals are adopted, you can then proceed with remove the nodes from the IC to upgrade the network config.

[Lorimer]

There’s currently a new open ‘Change Subnet Membership’ proposal for this subnet.

---

Proposal 132142

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 xetvj 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 node (the only node in Germany) is proposed to be replaced with one node in Latvia. This brings the owner coefficient into the acceptable range (the subnet was previously violating it), however, this proposal still leaves the subnet in a state that is heavily in violation of the formally voted in IC Target Topology. There is supposed to be no more than 3 nodes in the same country (not 6 nodes in one country).

My suggestion would be to reject this proposal and resubmit one that solves the offline node problem, and gets this critical subnet back into a state that conforms to the IC target topology (else clearly explain in the proposal summary why this latter point is not feasible).

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	304.39 km	8096.623 km	19442.91 km
PROPOSED	285.152 km (-6.3%)	8095.772 km	19442.91 km

This proposal slightly decreases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical decrease in localised disaster resilience).

Subnet characteristic counts →

	Continents	Countries	Data Centers	Owners	Node Providers
EXISTING	5	22	28	27	28
PROPOSED	5	22	28	28 (+3.6%)	28

This proposal significantly improves decentralisation in terms of data center ownership diversity.

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

	Continent	Country	Data Center	Owner	Node Provider
EXISTING	9	6	1	2	1
PROPOSED	9	6	1	1 (-50%)	1

See here for acceptable limits → Motion 125549 (note that these are due for a slight revision)

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)

Table

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Europe	Germany	Frankfurt 2 (fr2)	Equinix	Virtual Hive Ltd	ysjs7-fe67q-k7pxe-g4puk-d5z7p-xrtg2-xqcmy-pmpoa-7bcfu-pmlqy-rae	UP
---	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	xetvj-ysqpy-wnnd4-fbytw-n6arq-w7f5e-fhsuo-7xd67-lwpt2-novnx-iae	DOWN
+++	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	xetvj-ysqpy-wnnd4-fbytw-n6arq-w7f5e-fhsuo-7xd67-lwpt2-novnx-iae	DOWN
+++	Europe	Latvia	Riga 1 (rg1)	DEAC	MB Patrankos šūvis	yf2ct-a2auf-nofdz-acf6v-ugwyb-k5f6j-5sr3y-7h3xi-svcdg-mhpgg-aae	UNASSIGNED
	Americas	Argentina	CABA 1 (ar1)	SyT - Servicios y Telecomunicaciones S.A.	Mariano Stoll	v27at-hedf7-4a2my-tboq6-escdm-77krt-2qfuq-zjptf-z2sbk-vd7zs-xae	UP
	Oceania	Australia	Queensland 1 (sc1)	NEXTDC	ANYPOINT PTY LTD	zjiki-pzvnv-m4rnn-fodt3-poon4-uldx7-d3wkq-gptsu-g2mjs-boi35-3qe	UP
	Europe	Belgium	Antwerp (an1)	Datacenter United	Allusion	xu2zg-nns7x-z67l6-foa5w-yc4ek-addku-g2hqg-c3jdg-wabdu-5ouaw-yae	UP
	Americas	Canada	Toronto (to1)	Cyxtera	Blockchain Development Labs	x3cey-uerdd-53a7n-d45e2-gjsnd-airg5-nrs5i-4xujk-c5ynl-4pie6-yqe	UP
	Europe	Switzerland	Zurich 3 (zh3)	Nine.Ch	Tomahawk.vc	v2pkj-vpsow-fp24q-zqwfj-p3nek-m52xz-oz6ra-blmra-73voj-jvwb5-gae	UP
	Asia	China	HongKong 1 (hk1)	Unicom	Pindar Technology Limited	w4ri3-ytfnq-jg3z3-qseka-se4xe-b2fl2-km766-ruzwd-riw72-6bifs-4ae	UP
	Americas	Costa Rica	Bogota 1 (bg1)	EdgeUno	Geeta Kalwani	aajth-ndp7x-ro5ok-yikyd-4i7xn-5k5ki-e3d37-hh4gn-s4opz-bnzxf-4qe	UP
	Europe	Czechia	South Moravian Region 1 (bn1)	Master Internet	Maksym Ishchenko	zgtrt-4vlgr-pbytl-t2yqq-qf4nk-wyoos-vrfpu-hxqcw-tcnfu-73kjb-pae	UP
	Europe	Spain	Madrid 1 (ma1)	Ginernet	Ivanov Oleksandr	yi6r6-u4kax-jphcr-jcqr5-t3zpm-gmp3b-2hiew-iinpf-sgjos-eabha-aqe	UP
	Europe	Estonia	Tallinn 2 (ta2)	Telia DC	Artem Horodyskyi	zgeaf-fcq4e-fcnht-g7mpg-sb7ff-r6awk-zvkwp-gkloc-rr6jl-ghsse-mqe	UP
	Asia	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	uouxk-c246i-dgxzd-ql3a5-koofn-mclrv-toplo-bg76d-l4dzk-ngb3c-nae	UP
	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	ylm4h-mc2vy-vmwvf-g2qhn-36rbw-5cunq-wpj2j-ttofo-xc27c-vfdh7-aae	UP
	Asia	India	New Delhi 1 (nd1)	Marvelous Web3 DC	Marvelous Web3	67t6p-i4h3c-msv6p-kmbmm-rr6gj-z3nix-d6lo2-mq3q4-3h6rb-lwkbc-lae	UP
	Asia	Japan	Tokyo (ty1)	Equinix	Starbase	go5zz-xs6yg-mylwl-v7uob-7bg4b-wjzhe-vmrwe-uy7mz-ckaz2-idm33-rqe	UP
	Asia	Korea (the Republic of)	Seoul 2 (kr2)	Gasan	Web3game	wjwzb-q3ogf-fi3po-kf6y6-wzuuj-3ac3m-kjvab-fufsm-z2skq-kthkx-xae	UP
	Europe	Poland	Warszawa 2 (wa2)	Central Tower DC	Bohatyrov Volodymyr	mswad-oq7wj-5r4yy-b5qoy-cmv7z-wzfb3-ktn6l-rcnrz-mni2f-lsys6-wqe	UP
	Asia	Singapore	Singapore 2 (sg2)	Telin	OneSixtyTwo Digital Capital	qp3lh-25yxy-dlk4t-ay73d-frr4t-3kmi5-35kqg-3vvbq-26qhh-6xrdr-oqe	UP
	Europe	Slovenia	Ljubljana (lj1)	Posita.si	Fractal Labs AG	6adxp-p7u63-xsdtk-lo6oc-vpqmi-44hgt-yv652-cbm5p-mssge-wsrz6-oqe	UP
	Europe	Sweden	Stockholm 1 (sh1)	Digital Realty	DFINITY Operations SA	vgfnl-4phvh-44pk3-yshmp-ckwz3-qnzob-l5wnj-pqn2j-vv5jh-3oewk-xqe	UP
	Americas	United States of America (the)	Atlanta (at1)	Flexential	BLP22, LLC	v6caw-kf4b4-j22f5-pqsvj-hg7dj-wx4xx-y7urh-eixmh-hnvz7-hoe2v-jae	UP
	Americas	United States of America (the)	Chicago 3 (ch3)	CyrusOne	MI Servers	gtfa3-saq3t-ymlel-lsf6d-ans7b-cr45x-xg5np-xbxyt-nxfrt-iynyy-5qe	UP
	Americas	United States of America (the)	Fremont (fm1)	Hurricane Electric	Boolean Bit, LLC	z4jw5-v4ee6-aa7gr-5axkc-4ocjy-v5vv5-inwc6-ma4hw-mb7jv-3skxy-eqe	UP
	Americas	United States of America (the)	Houston (hu1)	TRG	43rd Big Idea Films	ham46-r7u4j-yoyrk-mrnxu-utzq3-c37he-vcns2-gc5yg-jxyv5-mvlhc-gae	UP
	Americas	United States of America (the)	Orlando (or1)	Datasite	Giant Leaf, LLC	z5a4h-43szy-vvp4j-xorii-l6yma-4iyzt-7o3ry-frvqe-azkit-5iag2-rqe	UP
	Americas	United States of America (the)	Panama City 1 (pc1)	Navegalo	Bianca-Martina Rohner	y7bml-csbq7-euzyf-njmvm-qfftp-iy7lc-wisaq-jlmul-sdo7p-7lkx4-3ae	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Karel Frank	xav3a-kdo3a-2rgbg-o6vnk-clat5-bcc7w-vmnej-z55rx-mfx26-7xugo-tqe	UP

---

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)

[sat]

I just submitted a new proposal https://dashboard.internetcomputer.org/proposal/132186 that replaces 2 dead nodes and provides more details (compared to previous proposals) on why we didn’t replace more nodes to optimize decentralization.
I also added some details on the “business rules” calculations, which includes the penalties for the distance from the target topology.
I hope this helps analyze and reason about the value that the replacement has.

[Lorimer]

Thanks @Sat, I really appreciate the work you’ve put in to adding more transparency and clarity to the proposal summaries. It’s good that this summary is making it clear to voters that no solution could be found that improves decentralisation. The only solution that could be found is one that decreases decentralisation, and takes this subnet further away from the target topology.

I’m planning to take a closer look tomorrow, but in the meantime, would you be able to provide some clarity on why the following nodes were not considered as viable replacement nodes?

Country	Data Center	Owner	Node Provider	Node	Status
France	Paris 1 (pr1)	Celeste	Carbon Twelve	atjbz-kcjz7-y4mgn-t5wqp-3emfk-6mtlx-ln5i7-4pixf-ocjgh-hfu77-bqe	UNASSIGNED
France	Paris 1 (pr1)	Celeste	Carbon Twelve	if2wa-juqxh-ii2v2-kzwry-3sgof-lqya5-j7o3s-ukvl6-ad4lz-ihrls-7qe	UNASSIGNED
France	Paris 1 (pr1)	Celeste	Carbon Twelve	oobdg-4ugoj-vv6lz-ytrmu-ckcnh-3d654-rlds3-jdabb-pr2e2-z4bfx-zqe	UNASSIGNED
France	Paris 1 (pr1)	Celeste	Carbon Twelve	tgbmf-2jayg-jhoty-cgdle-jezqv-vxaly-pom4f-vnhzr-jvxdd-3yoyo-zqe	UNASSIGNED
Croatia	Zagreb 1 (zg1)	Anonstake	Anonstake	myguv-fs4u6-jl53y-vk4pf-6xojw-4umwc-r55jy-jyy7q-f4gmu-wvliw-2qe	UNASSIGNED
Croatia	Zagreb 1 (zg1)	Anonstake	Anonstake	q3vac-kcwo2-ruiht-nflb7-ifoev-vkjcw-quybi-ugvgn-pqfwp-jntxi-dqe	UNASSIGNED
Lithuania	Vilnius 1 (bt1)	Baltneta	MB Patrankos šūvis	zi64g-qzbnp-3eu7w-mcz3p-2jb7a-he5lk-aru4t-goyi6-p2gtf-i4yqh-2ae	UNASSIGNED
Latvia	Riga 1 (rg1)	DEAC	MB Patrankos šūvis	qlk52-xi45d-fpbsj-epcof-uoghd-xkmb2-woudx-aci7c-tpglx-rq5mj-vqe	UNASSIGNED
Latvia	Riga 1 (rg1)	DEAC	MB Patrankos šūvis	yf2ct-a2auf-nofdz-acf6v-ugwyb-k5f6j-5sr3y-7h3xi-svcdg-mhpgg-aae	UNASSIGNED
Latvia	Riga 1 (rg1)	DEAC	Vladyslav Popov	poyg5-cbmcm-a372x-j72lt-zm4rz-4sf5v-ajtle-hyqkt-rdgaz-eqzmi-5qe	UNASSIGNED
Portugal	Barreiro 1 (ba1)	Online	Bitmoon	g765q-rteh7-xio4e-vtyea-ww46p-beylc-3e3s3-yhvuy-in6jd-hj5qo-3qe	UNASSIGNED
Romania	Bucharest (bu1)	M247	Iancu Aurel	g4avo-ecrmg-ki3ol-dxah7-zksar-suefa-26fco-fudva-ajioq-xvhmq-4ae	UNASSIGNED
Romania	Bucharest (bu1)	M247	Iancu Aurel	jyh32-azcnn-mwosu-urewl-m3pyx-6pmlq-lu5fu-vqjyl-gwx3j-zqrjr-gae	UNASSIGNED
Romania	Bucharest (bu1)	M247	Iancu Aurel	r7few-pljgn-iynmr-iprtj-p66dg-qpc5m-2tx4m-245oc-6dzgk-pu2wy-dae	UNASSIGNED

Based on a quick initial analysis, all 14 of these nodes appear to be valid candidates for swapping into this subnet while improving decentralisation, rather than making it worse (none of these nodes belong to the same country, data center, owner, nor node provider as any other node already in this subnet).

I expect I’m missing something. Thanks in advance

[sat]

I’d encourage you to try out What-If Analysis of Subnet Decentralization - DRE team docs – built for this purpose.

For instance:

❯ dre subnet whatif uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe --remove-nodes xetvj-ysqpy-wnnd4-fbytw-n6arq-w7f5e-fhsuo-7xd67-lwpt2-novnx-iae ylm4h-mc2vy-vmwvf-g2qhn-36rbw-5cunq-wpj2j-ttofo-xc27c-vfdh7-aae --add-nodes os2wv-dchv6-fjwdg-nichf-3cra6-wccb3-57glq-xqgen-zwobp-aonve-lqe atjbz-kcjz7-y4mgn-t5wqp-3emfk-6mtlx-ln5i7-4pixf-ocjgh-hfu77-bqe
2024-08-28T10:43:26.439Z INFO dre > Running version 0.5.2-c1615636-dirty
WARNING: Failed to connect to [2a0b:21c0:4003:2:5000:55ff:feb8:5f89]:443: Os { code: 113, kind: HostUnreachable, message: “No route to host” }
2024-08-28T10:43:28.007Z INFO dre::ic_admin > Checking if there is a new version of ic-admin
2024-08-28T10:43:28.177Z INFO dre::ic_admin > Using ic-admin: /home/sat/bin/ic-admin.revisions/a0207146be211cdff83321c99e9e70baa62733c7/ic-admin
2024-08-28T10:43:33.498Z INFO ic_management_backend::registry > Registry version local 44970 < remote 44973
2024-08-28T10:43:35.021Z INFO dre::ctx > Using local registry path for network mainnet: /home/sat/.cache/ic-registry-cache/mainnet/local_registry
Decentralization Nakamoto coefficient changes for subnet uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe:

  node_provider: 10.00 -> 10.00    (+0%)
    data_center: 10.00 -> 10.00    (+0%)
data_center_owner: 9.00 -> 8.00   (-11%)
           city: 10.00 -> 10.00    (+0%)
          country: 6.00 -> 6.00    (+0%)
        continent: 2.00 -> 1.00   (-50%)

Mean Nakamoto comparison: 7.83 → 7.50 (-4%)

Overall replacement impact: (gets worse) the minimum Nakamoto coefficient across all features decreases from 2 to 1

Details

Nodes removed:

• xetvj-ysqpy-wnnd4-fbytw-n6arq-w7f5e-fhsuo-7xd67-lwpt2-novnx-iae [health: dead, impact on decentralization: (gets worse) the number of different NP actors decreases from 28 to 27]
• ylm4h-mc2vy-vmwvf-g2qhn-36rbw-5cunq-wpj2j-ttofo-xc27c-vfdh7-aae [health: dead, impact on decentralization: (gets worse) the minimum Nakamoto coefficient across all features decreases from 2 to 1]

Nodes added:

• os2wv-dchv6-fjwdg-nichf-3cra6-wccb3-57glq-xqgen-zwobp-aonve-lqe [health: healthy, impact on decentralization: (gets better) the minimum Nakamoto coefficient across all features increases from 1 to 2]
• atjbz-kcjz7-y4mgn-t5wqp-3emfk-6mtlx-ln5i7-4pixf-ocjgh-hfu77-bqe [health: healthy, impact on decentralization: (gets worse) the minimum Nakamoto coefficient across all features decreases from 2 to 1]

    node_provider                                                              data_center            data_center_owner                                    city                             country            continent             
    -------------                                                              -----------            -----------------                                    ----                             -------            ---------             
    4r6qy-tljxg-slziw-zoteo-pboxh-vlctz-hkv2d-7zior-u3pxm-mmuxb-cae       1    an1               1    Africa Data Centres                             1    Bogota                      1    AR            1    Africa               1
    64xe5-tx2s3-4gjmj-pnozr-fejw2-77y5y-rhcjk-glnmx-62brf-qin5q-pqe       1    ar1               1    Celeste                                    0 -> 1    CABA                        1    AU            1    Asia            8 -> 6
    6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe       1    at1               1    Central Tower DC                                1    California                  1    BE            1    Europe         9 -> 10
    6sq7t-knkul-fko6h-xzvnf-ktbvr-jhx7r-hapzr-kjlek-whugy-zt6ip-xqe       1    bg1               1    Cloud9                                          1    Colombo                1 -> 0    CA            1    North America   7 -> 8
    7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae       1    bn1               1    CyrusOne                                        1    Flanders                    1    CH            1    Oceania              1
    7uioy-xitfw-yqcko-5gpya-3lpsw-dw7zt-dyyyf-wfqif-jvi76-fdbkg-cqe       1    ch3               1    Cyxtera                                         1    Florida                     1    CO            1    South America        2
    bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe       1    cm1          1 -> 0    Datacenter United                               1    Gauteng                     1    CR       0 -> 1                          
    dhywe-eouw6-hstpj-ahsnw-xnjxq-cmqks-47mrg-nnncb-3sr5d-rac6m-nae       1    cr1          0 -> 1    Datasite                                        1    Georgia                     1    CZ            1                          
    diyay-s4rfq-xnx23-zczwi-nptra-5254n-e4zn6-p7tqe-vqhzr-sd4gd-bqe       1    fm1               1    Digital Realty                                  1    Hesse                       1    DE            1                          
    eatbv-nlydd-n655c-g7j7p-gnmpz-pszdg-6e6et-veobv-ftz2y-4m752-vqe       1    fr2               1    EdgeUno                                         1    HongKong                    1    EE            1                          
    eybf4-6t6bb-unfb2-h2hhn-rrfi2-cd2vs-phksn-jdmbn-i463m-4lzds-vqe  1 -> 0    hk1               1    Equinix                                         2    Illinois                    1    ES            1                          
    fwnmn-zn7yt-5jaia-fkxlr-dzwyu-keguq-npfxq-mc72w-exeae-n5thj-oae       1    hu1               1    Flexential                                      1    Ljubljana                   1    FR       0 -> 1                          
    ivf2y-crxj4-y6ewo-un35q-a7pum-wqmbw-pkepy-d6uew-bfmff-g5yxe-eae       1    jb2               1    Gasan                                           1    Madrid                      1    GE            1                          
    izmhk-lpjum-uo4oy-lviba-yctpc-arg4b-2ywim-vgoiu-gqaj2-gskmw-2qe       1    kr2               1    Ginernet                                        1    New Delhi                   1    HK            1                          
    otzuu-dldzs-avvu2-qwowd-hdj73-aocy7-lacgi-carzj-m6f2r-ffluy-fae       1    lj1               1    Hurricane Electric                              1    Ontario                     1    IL       1 -> 0                          
    qdj4d-76lh3-w2q5i-kwjcd-643pq-pk42d-cziag-4hkau-35gib-m7s33-6qe       1    ma1               1    Interhost                                  1 -> 0    Panama City                 1    IN            1                          
    qsdw4-ao5ye-6rtq4-y3zhm-icjbj-lutd2-sbejz-4ajqz-pcflr-xrhsg-jae  0 -> 1    nd1               1    Marvelous Web3 DC                               1    Paris                  0 -> 1    JP            1                          
    r3yjn-kthmg-pfgmb-2fngg-5c7d7-t6kqg-wi37r-j7gy6-iee64-kjdja-jae       1    or1               1    Master Internet                                 1    Queensland                  1    KR            1                          
    rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae       1    pc1               1    NEXTDC                                          1    San Jose               0 -> 1    LK       1 -> 0                          
    s5nvr-ipdxf-xg6wd-ofacm-7tl4i-nwjzx-uulum-cugwb-kbpsa-wrsgs-cae       1    pr1          0 -> 1    Navegalo                                   1 -> 2    Seoul                       1    PA            1                          
    sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae       1    sc1               1    Nine.Ch                                         1    Singapore                   1    PL            1                          
    sma3p-ivkif-hz7nu-ngmvq-ibnjg-nubke-zf6gh-wbnfc-2dlng-l3die-zqe       1    sg2               1    OrionStellar                               1 -> 0    South Moravian Region       1    SE            1                          
    sqhxa-h6ili-qkwup-ohzwn-yofnm-vvnp5-kxdhg-saabw-rvua3-xp325-zqe       1    sh1               1    Posita.si                                       1    Stockholm                   1    SG            1                          
    ucjqj-jmbj3-rs4aq-ekzpw-ltjs3-zrcma-t6r3t-m5wxc-j5yrj-unwoj-mae       1    ta2               1    SyT - Servicios y Telecomunicaciones S.A.       1    Tallinn                     1    SI            1                          
    unqqg-no4b2-vbyad-ytik2-t3vly-3e57q-aje2t-sjb5l-bd4ke-chggn-uqe       1    tb1               1    TRG                                             1    Tbilisi                     1    US            5                          
    vegae-c4chr-aetfj-7gzuh-c23sx-u2paz-vmvbn-bcage-pu7lu-mptnn-eqe       1    to1               1    Telia DC                                        1    Tel Aviv               1 -> 0    ZA            1                          
    wdjjk-blh44-lxm74-ojj43-rvgf4-j5rie-nm6xs-xvnuv-j3ptn-25t4v-6ae       1    tv1          1 -> 0    Telin                                           1    Texas                       1                                             
    wdnqm-clqti-im5yf-iapio-avjom-kyppl-xuiza-oaz6z-smmts-52wyg-5ae       1    ty1               1    Unicom                                          1    Tokyo                       1                                             
    wwdbq-xuqhf-eydzu-oyl7p-ga565-zm7s7-yrive-ozgsy-zzgh3-qwb3j-cae       1    wa2               1                                                         Warszawa                    1                                             
                                                                               zh3               1                                                         Zurich                      1                                             

So a Paris node would have made the Continent decentralization worse. And all other nodes you have in the list are also in Europe. So they would have given the same result(s).

[Lorimer]

Hi @Sat, thanks for your response. Continent isn’t a feature of the previous nor current IC Target Topology (diversity in this dimension is a nice to have as long as the formal target topology coefficients have been met first). This is what the IC Target Topology specifies.

In your example above os2wv was not one of the nodes that I proposed, and therefore the effect on the data center nakamoto coefficient would not occur with the suggested replacements.

My understanding so far is that this proposal is unjustified in taking this subnet even further away from the target topology than it already is. There are solutions that bring it closer to the IC target topology, and I’m still unclear on why these solutions are not being prioritised.

Can we agree that it would be best to reject this proposal, and resubmit one that protects the IC Target Topology from even further deviation?

[sat]

Sorry but no. In contrast to whatever that single proposal (for target topology) says, I personally do care about all dimensions of decentralization. Making one significantly worse in order to make another one potentially a bit better is from my point of view not a good tradeoff. You are welcome to submit another proposal though and let the community decide on it.

[sat]

Also, this proposal was submitted so that the NP can run some management ops on the nodes. Once the nodes are back to operational, the decentralization will improve once again. I see no benefit in rejecting the proposal.

[Lorimer]

Motion proposals are clearly important, and represent a stringent and meaningful deliberation process that has involved a large number of people. This shouldn’t be overturned on personal whim (do you represent DFINITY with your stance on this?).

@sat

In contrast to whatever that single proposal (for target topology) says, I personally do care about all dimensions of decentralization

There are many more dimensions that aren’t considered, ones that are far more important than continent (which is worth noting when talking about all dimensions). The IC target topology motion could very easily have contained a column for continent limits per subnet, but it didn’t because it’s not important enough (the other dimensions are). In fact I brought up the lack of continent in the official coefficients before the most recent IC Target Topology was announced, but the response was that this would require more discussion (and this didn’t make it into the announcement nor motion proposal).

1. I think it’s worth noting that the majority of subnets have a Nakamoto coefficient of 1 for continent, and this is perfectly acceptable and allowed by the IC target topology.

2. This proposal reduces the country Nakamoto coefficient from 6 to 5, and reduces the data center Nakamoto coefficient from 9 to 8. There’s no way that’s justified. There should be no more than 3 nodes per country, and no more than 1 node per data center. This subnet already has 5 in the same country, and 2 with the same data center, and this proposal takes the subnet further away from resolving this problem.

3. Most importantly, there’s no need to sacrifice on continent coefficient as you suggest. If this is your concern why don’t you submit a pair of proposals to free up a non-European node for this subnet (while swapping an available European node into the other subnet)?

@sat

Also, this proposal was submitted so that the NP can run some management ops on the nodes. Once the nodes are back to operational, the decentralization will improve once again. I see no benefit in rejecting the proposal.

I think this is flawed logic, and an appeal to consequences fallacy. The proposal in and of itself is bad, but don’t worry because I’ll plan to undo it afterwards. There’s no guarantee this will be possible (as it depends on nodes that are available later, and their affinity for this subnet, which is unpredictable). I expect this sort of situation is why so many important subnets are so far away from their target topology (including the NNS).

I understand you have your stance on this. I hope I’ve justified mine, and clearly explained why I’ve rejected this proposal, and believe it would be prudent for others to too.

---

As a side note, tone is a difficult thing to convey in text form, but I hope it’s clear there’s no animosity in this post. I take my responsibility as a known neuron (and potential followee) seriously

[sat]

Hi @Lorimer ,

I very much appreciate your thorough feedback. This is what decentralization is all about, and I’m very happy that you have such a critical view. To be clear, I’m not acting or overturning anything “based on a personal whim”. This proposal was prepared and submitted by the same tooling we have been using over the previous 2+ years. I’ll try to explain below the reasoning behind my earlier comment.

The continent coefficient isn’t a primary focus of our IC Target Topology, but IMHO it’s worth examining its implications more closely.

1. Importance of Continent Coefficient: In cases where subnets are predominantly located in one continent, like Europe, the continent coefficient could play a significant role in overall decentralization. Continent diversity can help mitigate risks tied to geopolitical or regulatory factors.
2. Evaluating Trade-offs: This particular proposal reduces the Nakamoto Coefficient (NC) from 6 to 5, meaning that it reduces the country NC for 16.6%. However, it a) addresses immediate operational issues and b) does not change the continent NC. The reduction of the continent NC would be 50%, and any critical event in Europe would either stop the II subnet, or even risk the threshold keys that sit on this subnet. I find that potentially much worse than expecting that 5 countries would collude vs previous 6 countries to collude. Both 5 and 6 are fairly high numbers and both are similarly unlikely.
3. Future Considerations: We have had the requirement of the continent diversity in our tooling for over 2 years now, and the proposals submitted by the tooling have been internally scrutinized all that time. The motion proposal that you refer to has been scrutinized over much shorter time (albeit by more people), and I also see no discussion in the forum about the continent aspect. So it might have been an accidental omission. In most cases the continent factor is not extremely important - I agree. But in certain cases, like the EU, it may be. We will need to discuss whether something needs to be changed in the decentralization strategy and the target topology and we may need to submit another motion proposal. Either way – thank you for pointing out this discrepancy!

Balancing operational needs with decentralization goals is complex, and your suggestions provide valuable insights – thank you once more!

[Lorimer]

Thanks @sat, I’m just about to start a busy day at work so can’t commit much to this response at the moment, but wanted to share a few quick comments.

I really appreciate your response, and I agree that the motion proposal would need re-submitting with the parameters that are actually deemed important (before then though, this proposal needs rejecting, as it violates the motion that currently stands). I would also suggest that the premise for any new motion proposal should be reworded to make it clear that current tooling only allows for an ‘estimation’ that there are currently enough nodes (this isn’t known for sure). ← This is a separate issue, but worth noting.

@sat

This proposal was prepared and submitted by the same tooling we have been using over the previous 2+ years.

…and this is the same tooling and business processes that have led to subnets such as the NNS drifting into far away topology states that are clearly more dangerous than is tolerable →

@Lorimer

It really must be emphasised that the NNS subnet (the most security-critical one) currently has:

• 8 nodes in the same country (instead of the achievable target of 3)
• 2 nodes in the same data center (instead of the achievable target of 1)
• 3 nodes with the same owner (instead of the achievable target of 1)
• 2 nodes from the same node provider (instead of the achievable target of 1)

Just to reiterate, if it’s really important to you, there are viable approaches to move forward that do not require your continent coefficient to be violated, nor the rules of the standing motion proposal. It would require the community to reject this proposal, and for a pair of proposals to be submitted next.

• One that swaps a European node into another subnet, while swapping an appropriate non-European node out
• A second proposal that swaps that non-European node into this subnet

I think it’s clear that this is what should be considered best practise. In the context of a decentralised, trustless system such as the IC NNS, the community needs to rely on best practises being adhered to, and less so on trust and/or authoritative pushback on the forum.

---

At the end of the day, there’s no reason to violate the IC target topology. Can you agree that violating the IC target topology (in the way that this proposal does) is unnecessary? Would you therefore also open up to the idea that this proposal needs rejecting to help set a best practice standard for the future?