Subnet Management - 4zbus (Application)

^ This proposal was rejected (DFINITY noticed that one of the proposed nodes was due to be decommissioned - the proposal for that decommissioning is now out → Proposal: 131758).


There’s now a revised open proposal for this subnet → Proposal 131789. Thanks again @sat, the proposal summary is now super informative! :raised_hands:

I’ve independently verified the proposal claims below. As before, one node is down and is replaced by an up node by the same node provider in Japan. The other node change is intended to optimise subnet decentralisation coefficients. This optimisation appears to be mostly positive.

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

Smallest Distance Average Distance Largest Distance
EXISTING 71.122 km 6513.222 km 16469.974 km
PROPOSED 71.122 km 6215.817 km (-4.6%) 16469.974 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). :-1:

Subnet characteristic counts →

Continents Countries Data Centers Owners Node Providers
EXISTING 3 9 13 13 13
PROPOSED 3 10 (+10%) 13 13 13

This proposal slightly increases the number of countries that constitute this subnet, improving decentralisation in terms of jurisdiction diversity. :+1:

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

Continent Country Data Center Owner Node Provider
EXISTING 7 4 1 1 1
PROPOSED 7 3 (-25%) 1 1 1

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

As far as I gather, this subnet is already in violation of the predefined maximum number of nodes within the same country, which is supposed to be 2 for a 13 node subnet.

This proposal brings this number closer to the acceptable limit :+1: (though I believe the outcome will still be in violation of the acceptable limit, 3 instead of 2).

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
Continent Country Data Center Owner Node Provider Node Status
--- Asia Japan Tokyo 3 (ty3) Equinix Starbase nxayg-zna42-zpngn-tg6hw-heplm-xvfsb-bxyov-3qiix-aaavl-5pdev-uqe DOWN
--- Americas United States of America (the) Fremont (fm1) Hurricane Electric Mostly Wholesome, Inc. 75run-c7fya-7uoor-jzgtx-pwjc4-lfhyp-62p2w-2pnyv-amqh6-tdhji-rae UP
+++ Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 2h6dm-k5h3n-nmqek-m5gty-yy3xq-a3atf-54its-biy25-ijh3c-xvit4-mae UNASSIGNED
+++ Asia Japan Tokyo (ty1) Equinix Starbase ktqjk-r6yho-cqgxd-qaqqn-yhxvl-ez6ax-jk3n4-bfa2f-vprkh-eigf5-5qe UNASSIGNED
Europe Belgium Brussels 2 (br2) AtlasEdge Allusion najnj-to3ju-pl6pl-5yjlc-6vdqi-f7tht-qd7tt-fenyr-f3tjc-tfj37-uae UP
Europe Switzerland Geneva 2 (ge2) SafeHost Archery Blockchain SCSp uvyny-tt2f2-rb743-fk6ia-qn6ut-c3qyb-ob3aw-6qcvm-qbktr-pco7n-2ae UP
Europe Switzerland Zurich 5 (zh5) Green.ch Sygnum Bank c2vrr-ynjrh-xturt-s77ah-a5efo-b726x-dgq4a-m7zdc-wvsa5-7ogz5-mqe UP
Europe Spain Madrid 3 (ma3) IPCore Vladyslav Popov oiso5-hxkkc-elqlo-iyoqg-7oux4-5mscl-zkvoh-b2432-ohrir-b5fcm-gae UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel 7agd5-pfc4g-rdozn-zajij-aax72-7jft2-rzw36-y3flc-xwt77-pjg5w-7qe UP
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital jvqnq-6jnty-tr3ml-izvma-e5w6e-s3rfx-w4wir-mwcsf-x5yok-nc4uz-6ae UP
Europe Slovenia Ljubljana 2 (lj2) Anonstake Anonstake 5zqhj-66qn7-he3p5-76gnj-hlsvl-ajlt5-k356i-fgm4m-5it4c-6m5ag-7qe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA ozim4-dez5l-gk24c-m7phw-e6i32-c7vxe-m6you-mkprj-moxq2-fhtyw-uae UP
Americas United States of America (the) Atlanta 2 (at2) Datasite BLP22, LLC cvic3-6mmjj-2zszr-mr727-im4l5-skwod-gzrg2-avd4i-bahw3-xyx3l-2ae UP
Americas United States of America (the) Jacksonville (jv1) Tierpoint 9Yards Capital 7ak5q-ev3ur-nmmup-rocyw-z2kxo-bqppk-vkj22-gicfw-6h37b-cpvmc-uae UP
Americas United States of America (the) Portland (pl1) Flexential 87m Neuron, LLC v7xli-jnnol-am5py-5stvp-ucmul-5y4kn-yy4tu-34xee-mgfnu-y3hfg-xae UP

I’m planning to adopt this proposal as the improvements to subnet decentralisation (in terms of jurisdiction diversity) are more important than the slight increase in average node proximity. I do have some questions though. @SvenF would you be able to answer any of these? :pray:

  • Am I correct in observing that the subnet is currently in violation of the predefined decentralisation coefficient relating to the maximum number of nodes that should belong to the same country? (and that the subnet will still be in violation of this even once this proposal passes, though it will be in a better position than it is now) :face_with_monocle:

  • There are plenty of viable nodes located in South Africa and Australia (illustrated on the map). Any of these would have improved the country coefficient, as well as increasing the average geographic distance between subnet nodes, as well as increasing the number of continents that the subnet is composed of. Am I missing something, or would one of these have potentially been a better choice of node to add to the subnet? :thinking:

  • When selecting nodes to add to a subnet to optimise decentralisation, is this done in a greedy fashion (considering just the subnet in question), or are redundancy requirements for other subnets also taken into account? :nerd_face:

As a side note, there are two nodes (in Switzerland) in this subnet that are very close to one another, roughly an hours drive apart :red_car: (but of course these belong to different node providers and data centre owners, otherwise this would also be a violation of the decentralisation coefficients).

2 Likes