Subnet Management - 6pbhf (Application)

Thanks for this proposal @Sat, and great question @timk11 regarding the status of that node flip-flopping. I’d been intending on setting up an app that frequently polls node state in order to provide an easy way of visualising node status history. I wasn’t actually aware that we already have this sort of report (and more) with the Node Provider Rewards dashboard that Sat has highlight. This is great! :star_struck:

I’d be interested to learn more about who maintains this dashboard (I see it’s controlled by principal - 32kwa-eibir-hat2o-kyhfc-u5msq-xr4w4-newoz-qpzxj-ohovv-u7zgt-qqe). @Sat can I ask who this controller is, or what team this principal represents?


The circumstances around this proposal are actually super interesting :eyes:

Here are the block rate metrics for a randomly selected node in this subnet (as an exemplar point of reference) - jj7si

image

Note the 100% success rate, and that the block rate significantly increased at the start of September, as a direct result of this prior proposal (reducing notarization delay) → Subnet Management - 6pbhf (Application) - Governance / NNS proposal discussions - Internet Computer Developer Forum (dfinity.org)


Here are the block rate metrics for the node that keeps falling into a degraded state

image

We can see that it was already failing to keep up 100% with the existing block rate (prior to September). Interestingly the performance of this node in absolute terms has actually improved since the start of September (on average). However, in relative terms (relative to the increased total number of block), this node’s performance now borders on being considered degraded.

It might be worth looking out for nodes like this when decreasing the notarization delay on critical system subnets (which I suspect will happen soon).

@Sat, out of interest, can I ask what the exact criteria are for when a node status is considered to switch from UP to DEGRADED? Presumably the proportion of failed blocks needs to cross some limit?


Proposal 133080

Now that the preamble is out of the way, the ‘degraded’ node in Korea is being replaced with an ‘up’ node in Israel :+1: I’ve voted to adopt

There’s a slight reduction in the average distance between nodes if this proposal passes, but that seems fine (particularly given that it’s not a metric directly considered by the IC target topology). All other decentralisation metrics appear unaltered by this proposal.

Decentralisation Stats

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

Smallest Distance Average Distance Largest Distance
EXISTING 117.012 km 6915.788 km 17244.636 km
PROPOSED 117.012 km 6591.406 km (-4.7%) 17244.636 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 4 13 13 13 13
PROPOSED 4 13 13 13 13

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

Continent Country Data Center Owner Node Provider
EXISTING 7 1 1 1 1
PROPOSED 7 1 1 1 1

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
Continent Country Data Center Owner Node Provider Node Status
--- Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game l2bzb-vpnu6-jlsae-poddg-5hpnz-bx54x-3khc2-aazpn-bop4m-zforf-uqe DEGRADED
+++ Asia Israel Tel Aviv 1 (tv1) Interhost GeoNodes LLC vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae UNASSIGNED
Oceania Australia Queensland 1 (sc1) NEXTDC ANYPOINT PTY LTD r4dbq-jplty-hxb2n-yx4pt-dm2vf-m73ro-sqgq7-onnzn-zenvp-dleaz-mae UP
Europe Belgium Antwerp (an1) Datacenter United Allusion mehhn-b5swd-urm2r-cltwk-c5tns-2s2bf-skz74-hv63o-3qdad-ubbfn-iae UP
Europe Germany Geneva 2 (ge2) SafeHost Archery Blockchain SCSp 4mm7j-dmeng-7ib4h-yvt3c-g5ed6-i5yar-rrc6w-rp7tk-ej3by-gilvv-kae UP
Europe Spain Madrid 1 (ma1) Ginernet Artem Horodyskyi jj7si-b7rs7-nq7sv-npame-aec3y-2anip-ol5s6-gxbh7-kjbg2-a5u6j-rae UP
Asia Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone xqhoe-c5pck-wcytx-owvyr-mntbp-u22ct-nvcqi-bri5w-sjow2-rs4gp-sae UP
Europe Croatia Zagreb 1 (zg1) Anonstake Anonstake rzm7j-37ied-ynlvt-zma7n-r4bjg-wxg2d-kr4me-ss4yr-3p5se-n4sry-wqe UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase w53hu-bdzuz-h7h75-weodb-getvj-rr766-m2rtb-bigdq-l62cj-7atxw-2ae UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel vuizy-nfm5v-rapnc-rijer-hijfx-bvjrz-ccxdd-kte3v-awbnq-bdm6m-6qe UP
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital l4mrq-cmo2o-ydidi-v2zit-pemyc-itm4j-qw2u3-kwzso-yz5dv-geium-pqe UP
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG efdju-ef2ce-a5jdn-obybl-x6ema-h5lwv-nc2sy-v4hvc-7nltm-aldtv-6ae UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA tgmtp-wy3f4-hqron-bnvc3-scclx-b7fgg-gdnc2-dwvks-dn6ao-gbqso-5ae UP
Americas United States of America (the) San Jose (sj1) INAP Shelburne Ventures, LLC 7v72g-sof5q-riabw-dzefk-7p74b-wxwzs-dgvbv-rlrxx-2jpjy-zli4s-cqe 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:

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

2 Likes