Subnet Management - e66qm (Application)

Governance NNS proposal discussions
, ,
1

This topic is intended to capture Subnet Management activities over time for the e66qm 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": 44311,
  "records": [
    {
      "key": "subnet_record_e66qm-3cydn-nkf4i-ml4rb-4ro6o-srm5s-x5hwq-hnprz-3meqp-s7vks-5qe",
      "version": 44311,
      "value": {
        "membership": [
          "inlh6-ii3uy-bpasa-uzngo-xle3x-d2p2a-ylu3h-neikw-tnmwv-wep5x-nae",
          "sbjj4-mggba-56ihm-lf4hg-mjzad-sg6up-lv4os-56vvp-vagid-ieawy-iae",
          "qicnz-k4irc-lorep-ymp33-kx5l4-hnh6u-scxtx-rlwdu-remff-ubqb3-gae",
          "zbzin-kgyio-vai3o-ghyz4-36boi-4tjvv-7fis2-d2mlq-xk7fx-d4udt-xae",
          "fr3jr-74qz3-jzmga-mpt7c-eipd7-numir-hpczg-egnrw-lrrrh-2f7ws-qqe",
          "pzdyu-3fz4j-jukm5-pimui-aqzjl-dlqxo-mpe42-ihxtg-rjzxt-ibdb6-aae",
          "5i7he-lt457-b3ov6-fsi2c-pufn7-4i2mp-zkacf-4yysn-7fhr6-zfxg2-4qe",
          "6ssdj-55z6j-7q72p-vn255-utr5r-r2lgq-iitti-wnchn-rpwos-hjgrt-lqe",
          "lt3wc-g6uvu-v3jcj-qaxlz-nuoen-oof5g-neahy-44h6g-4uqxy-mlri6-iae",
          "txxda-ewevl-saa7x-hj43c-24xcm-i3hjs-j4xxn-2yujg-ptuif-q2ja6-fqe",
          "kjzcx-5a22v-gcxvx-ilfil-mp54w-hlcsh-r4k6n-t36ia-vzoy4-pvedu-cae",
          "joich-t5ted-j3ibc-n7ytv-bomzl-jqimt-7gc72-xujql-xahtn-grunf-dqe",
          "6xfo2-g6moa-wiadg-3nyup-47m5k-ee7rf-wjxij-lv3q5-kqivn-hsmgp-jqe"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 2097152,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 1000,
        "initial_notary_delay_millis": 600,
        "replica_version_id": "a3831c87440df4821b435050c8a8fcb3745d86f6",
        "dkg_interval_length": 499,
        "start_as_nns": false,
        "subnet_type": "application",
        "features": {
          "canister_sandboxing": false,
          "http_requests": true,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [],
        "ssh_backup_access": [],
        "ecdsa_config": null,
        "chain_key_config": null
      }
    }
  ]
}
2

There’s an open proposal for changing subnet membership - https://dashboard.internetcomputer.org/proposal/131428. This information is presented below:

  • red marker represents a removed node
  • green marker represents an added node
  • highlighted patches represent the country a node sits within

image
image1033×503 70.3 KB

Table
Country Data Center Owner Node Provider Node
--- Germany Munich (mu1) q.beyond Staking Facilities txxda-ewevl-saa7x-hj43c-24xcm-i3hjs-j4xxn-2yujg-ptuif-q2ja6-fqe
+++ India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS wdg4t-afemy-nttou-sdh2u-b6lik-2cuxv-frfoy-wjige-z4qy5-wheg6-kae
Belgium Antwerp (an1) Datacenter United Allusion lt3wc-g6uvu-v3jcj-qaxlz-nuoen-oof5g-neahy-44h6g-4uqxy-mlri6-iae
Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs inlh6-ii3uy-bpasa-uzngo-xle3x-d2p2a-ylu3h-neikw-tnmwv-wep5x-nae
Switzerland Zurich 6 (zh6) Green.ch Sygnum Bank joich-t5ted-j3ibc-n7ytv-bomzl-jqimt-7gc72-xujql-xahtn-grunf-dqe
China HongKong 1 (hk1) Unicom Pindar Technology Limited sbjj4-mggba-56ihm-lf4hg-mjzad-sg6up-lv4os-56vvp-vagid-ieawy-iae
Georgia Vilnius 2 (vl2) Data Inn George Bassadone zbzin-kgyio-vai3o-ghyz4-36boi-4tjvv-7fis2-d2mlq-xk7fx-d4udt-xae
Japan Tokyo 2 (ty2) Equinix Starbase 6xfo2-g6moa-wiadg-3nyup-47m5k-ee7rf-wjxij-lv3q5-kqivn-hsmgp-jqe
Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital kjzcx-5a22v-gcxvx-ilfil-mp54w-hlcsh-r4k6n-t36ia-vzoy4-pvedu-cae
Slovenia Ljubljana 2 (lj2) Anonstake Anonstake fr3jr-74qz3-jzmga-mpt7c-eipd7-numir-hpczg-egnrw-lrrrh-2f7ws-qqe
Slovenia Maribor (mb1) Posita.si Fractal Labs AG 6ssdj-55z6j-7q72p-vn255-utr5r-r2lgq-iitti-wnchn-rpwos-hjgrt-lqe
Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA pzdyu-3fz4j-jukm5-pimui-aqzjl-dlqxo-mpe42-ihxtg-rjzxt-ibdb6-aae
United States of America (the) Atlanta 2 (at2) Datasite BLP22, LLC 5i7he-lt457-b3ov6-fsi2c-pufn7-4i2mp-zkacf-4yysn-7fhr6-zfxg2-4qe
South Africa Gauteng 3 (jb3) Xneelo Wolkboer (Pty) Ltd qicnz-k4irc-lorep-ymp33-kx5l4-hnh6u-scxtx-rlwdu-remff-ubqb3-gae

The removed node is replaced with a node based in India. I’ve verified that this node is currently unassigned.

The proposal mentions that his change is needed due to the Munich (mu1) data centre being due for decommissioning. See here for more discussion and references.

3

DFINITY will submit a proposal to reduce the notarization delay on subnet e66qm, similar to what has happened on other subnets in the recent weeks (you can find all details in this forum thread).

Note that e66qm is currently under high load from bob.fun, so this proposal could help increase the subnet’s throughput. DFINITY has done tests with the lower notarization delays and high load, so this combination should not cause issues.

5 Likes
4

This proposal is now submitted: https://dashboard.internetcomputer.org/proposal/132368

5 Likes
5

Thanks for this announcement @Manu. Looks good and I’ve voted to adopt. It’ll be interesting to see the updated metrics once this proposal executes :+1:

Screenshot_20240906_001558_Chrome
Screenshot_20240906_001558_Chrome1007×1678 119 KB

Screenshot_20240906_001304_Telegram
Screenshot_20240906_001304_Telegram1030×1698 156 KB

2 Likes
6

There appear to be confounding variables. More commentary here →

7

It did roughly double the computation rate of the subnet (jumping from ~11B to ~22B instructions per second)

image
image1974×1194 210 KB

1 Like
8

Maybe to add a bit of context to my post: When I wrote the post, we had observed messages between subnets that were enqueued for multiple hours. Coincidentally, those messages were all delivered while we were still analyzing the situation (without us doing anything actively). The delays seem to be related to the large number of DTS executions outstanding on the e66qm subnet, caused by the large number of bob miners that all want to run heavy computation. We will analyze this further and provide a more detailed update.

3 Likes
9

so what was the problem with the high load from bob? problematic subnet?

10

Proposal 133445

2 removed nodes replaced with nodes in South Korea and Switzerland. 1 because it’s down (hence the proposal), and the other to improve decentralisation. Looks great, I’ve voted to adopt.

Decentralisation Stats

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

Smallest Distance Average Distance Largest Distance
EXISTING 0 km 7144.537 km 15453.375 km
PROPOSED 489.837 km 7472.928 km (+4.6%) 15453.375 km

This proposal increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience). :+1:

Subnet characteristic counts →

Continents Countries Data Centers Owners Node Providers
EXISTING 4 12 13 13 13
PROPOSED 4 13 (+7.7%) 13 13 13

This proposal improves 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 6 2 1 1 1
PROPOSED 5 (-16.67%) 1 (-50%) 1 1 1
:star_struck: :point_up:

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)

image
image939×416 77 KB

Table
Continent Country Data Center Owner Node Provider Node Status
--- Europe Switzerland Zurich 6 (zh6) Green.ch Sygnum Bank joich-t5ted-j3ibc-n7ytv-bomzl-jqimt-7gc72-xujql-xahtn-grunf-dqe DOWN
--- Europe Slovenia Ljubljana 2 (lj2) Anonstake Anonstake fr3jr-74qz3-jzmga-mpt7c-eipd7-numir-hpczg-egnrw-lrrrh-2f7ws-qqe UP
+++ Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc 5oe2d-on34f-iyvla-5ejfo-34n5u-yllm4-zxdgu-scaji-uleio-yeszd-yqe UNASSIGNED
+++ Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game l2bzb-vpnu6-jlsae-poddg-5hpnz-bx54x-3khc2-aazpn-bop4m-zforf-uqe UNASSIGNED
Europe Belgium Antwerp (an1) Datacenter United Allusion lt3wc-g6uvu-v3jcj-qaxlz-nuoen-oof5g-neahy-44h6g-4uqxy-mlri6-iae UP
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs inlh6-ii3uy-bpasa-uzngo-xle3x-d2p2a-ylu3h-neikw-tnmwv-wep5x-nae UP
Asia China HongKong 1 (hk1) Unicom Pindar Technology Limited sbjj4-mggba-56ihm-lf4hg-mjzad-sg6up-lv4os-56vvp-vagid-ieawy-iae UP
Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS wdg4t-afemy-nttou-sdh2u-b6lik-2cuxv-frfoy-wjige-z4qy5-wheg6-kae UP
Asia Japan Tokyo 2 (ty2) Equinix Starbase 6xfo2-g6moa-wiadg-3nyup-47m5k-ee7rf-wjxij-lv3q5-kqivn-hsmgp-jqe UP
Europe Lithuania Vilnius 2 (vl2) Data Inn George Bassadone zbzin-kgyio-vai3o-ghyz4-36boi-4tjvv-7fis2-d2mlq-xk7fx-d4udt-xae UP
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital kjzcx-5a22v-gcxvx-ilfil-mp54w-hlcsh-r4k6n-t36ia-vzoy4-pvedu-cae UP
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG 6ssdj-55z6j-7q72p-vn255-utr5r-r2lgq-iitti-wnchn-rpwos-hjgrt-lqe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA pzdyu-3fz4j-jukm5-pimui-aqzjl-dlqxo-mpe42-ihxtg-rjzxt-ibdb6-aae UP
Americas United States of America (the) Atlanta 2 (at2) Datasite BLP22, LLC 5i7he-lt457-b3ov6-fsi2c-pufn7-4i2mp-zkacf-4yysn-7fhr6-zfxg2-4qe UP
Africa South Africa Gauteng 3 (jb3) Xneelo Wolkboer (Pty) Ltd qicnz-k4irc-lorep-ymp33-kx5l4-hnh6u-scxtx-rlwdu-remff-ubqb3-gae 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)

1 Like
11

Voted to adopt proposal 133445.

Again Sygnum Bank 's joich node is offline and needs to be replaced.
Adding Tomahawk.vc 's 5oe2d node improves decentralization.

12

Voted to adopt proposal 133445.

This proposal replaces 2 nodes in subnet e66qm including joich, which appears as “Status: Offline” in the dashboard. As shown in the proposal and verified using the DRE tool, decentralisation is improved with respect to country and all parameters remain within the requirements of the target topology.

13

Voted to adopt proposal 133445. The proposal replaces two nodes on the e66qm subnet: dead node joich (Offline) and node fr3jr (Active) with nodes l2bzb and 5oe2d. The node joich is healthy and only replaced in order to improve the Nakamoto Coefficient for the Country metric as verified with the Dre tool.

14

Voted to adopt proposal 134039, as the reasoning is sound and the proposal description matches the payload.

This proposal is intended to replace a dead node, l2bzb, which node appears as “Status: Offline” on the dashboard. As seen in the proposal (which I verified using the DRE tool), the proposed change leaves the target topology parameters unchanged and within the requirements.

2 Likes
15

Proposal 134039

TLDR: 1 offline node in South Korea replaced with an unassigned node in Australia. This proposal also slightly increases decentralisation in terms of geographic distance and also continent diversity. Looks good, I’ve adopted.

Decentralisation Stats

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

Smallest Distance Average Distance Largest Distance
EXISTING 489.837 km 7472.928 km 15453.375 km
PROPOSED 489.837 km 8303.16 km (+11.1%) 16759.085 km (+8.4%)

This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience). :+1:

Subnet characteristic counts →

Continents Countries Data Centers Owners Node Providers Node Operator
EXISTING 4 13 13 13 13 13
PROPOSED 5 (+20%) 13 13 13 13 13

This proposal slightly improves 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 Node Operator
EXISTING 5 1 1 1 1 1
PROPOSED 5 1 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)

image
image923×410 76.8 KB

Table
Continent Country Data Center Owner Node Provider Node Operator Node Status Performance
--- Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game 5dwhe l2bzb-vpnu6-jlsae-poddg-5hpnz-bx54x-3khc2-aazpn-bop4m-zforf-uqe DOWN :bar_chart:
+++ Oceania Australia Melbourne 2 (mn2) NEXTDC Icaria Systems Pty Ltd l5lhp o2q5i-kszma-radgr-fdzu5-iqfps-w6xfc-aka7m-fftq4-2lpar-wj6xc-mqe UNASSIGNED :bar_chart:
Europe Belgium Antwerp (an1) Datacenter United Allusion pgunx lt3wc-g6uvu-v3jcj-qaxlz-nuoen-oof5g-neahy-44h6g-4uqxy-mlri6-iae UP :bar_chart:
Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 4lp6i inlh6-ii3uy-bpasa-uzngo-xle3x-d2p2a-ylu3h-neikw-tnmwv-wep5x-nae UP :bar_chart:
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc paxme 5oe2d-on34f-iyvla-5ejfo-34n5u-yllm4-zxdgu-scaji-uleio-yeszd-yqe UP :bar_chart:
Asia China HongKong 1 (hk1) Unicom Pindar Technology Limited vzsx4 sbjj4-mggba-56ihm-lf4hg-mjzad-sg6up-lv4os-56vvp-vagid-ieawy-iae UP :bar_chart:
Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS slaxf wdg4t-afemy-nttou-sdh2u-b6lik-2cuxv-frfoy-wjige-z4qy5-wheg6-kae UP :bar_chart:
Asia Japan Tokyo 2 (ty2) Equinix Starbase dpt4y 6xfo2-g6moa-wiadg-3nyup-47m5k-ee7rf-wjxij-lv3q5-kqivn-hsmgp-jqe UP :bar_chart:
Europe Lithuania Vilnius 2 (vl2) Data Inn George Bassadone inluf zbzin-kgyio-vai3o-ghyz4-36boi-4tjvv-7fis2-d2mlq-xk7fx-d4udt-xae UP :bar_chart:
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital d4bin kjzcx-5a22v-gcxvx-ilfil-mp54w-hlcsh-r4k6n-t36ia-vzoy4-pvedu-cae UP :bar_chart:
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG 3xiew 6ssdj-55z6j-7q72p-vn255-utr5r-r2lgq-iitti-wnchn-rpwos-hjgrt-lqe UP :bar_chart:
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA lgp6d pzdyu-3fz4j-jukm5-pimui-aqzjl-dlqxo-mpe42-ihxtg-rjzxt-ibdb6-aae UP :bar_chart:
Americas United States of America (the) Atlanta 2 (at2) Datasite BLP22, LLC 5syyj 5i7he-lt457-b3ov6-fsi2c-pufn7-4i2mp-zkacf-4yysn-7fhr6-zfxg2-4qe UP :bar_chart:
Africa South Africa Gauteng 3 (jb3) Xneelo Wolkboer (Pty) Ltd ymenq qicnz-k4irc-lorep-ymp33-kx5l4-hnh6u-scxtx-rlwdu-remff-ubqb3-gae UP :bar_chart:
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.

Another good neuron to follow is 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)

1 Like
16

Voted to adopt proposal 134039. The proposal replaces one nodes from subnet e66qm:
Removed Node: l2bzb, Dashboard Status Offline
Added Node: o2q5i.
The proposal was verified using the DRE tool to verify the metrics stated and there was no impact on decentralization.

1 Like
17

Voted to adopt proposal #134039.

The proposal is correct in that it replaces offline dead node from Seul2 l2bzb , with Melbourne2 node o2q5i while improving decentralization.

1 Like
18

A new proposal with id 134544 has been submitted, please take a look.

Click here to open proposal details

Replace nodes in subnet e66qm

Motivation:
The following nodes in subnet e66qm have been cordoned and need to be removed from the subnet:

Decentralization Nakamoto coefficient changes for subnet e66qm-3cydn-nkf4i-ml4rb-4ro6o-srm5s-x5hwq-hnprz-3meqp-s7vks-5qe:

    node_provider: 5.00 -> 5.00    (+0%)
      data_center: 5.00 -> 5.00    (+0%)
data_center_owner: 5.00 -> 5.00    (+0%)
             area: 5.00 -> 5.00    (+0%)
          country: 5.00 -> 5.00    (+0%)

Mean Nakamoto comparison: 5.00 → 5.00 (+0%)

Overall replacement impact: equal decentralization across all features

Details

Nodes removed:

  • 6xfo2-g6moa-wiadg-3nyup-47m5k-ee7rf-wjxij-lv3q5-kqivn-hsmgp-jqe [health: healthy]
  • lt3wc-g6uvu-v3jcj-qaxlz-nuoen-oof5g-neahy-44h6g-4uqxy-mlri6-iae [health: healthy]

Nodes added:

  • pfmqh-xphm4-h4wkn-nafsx-aix6u-h4gbl-owfhy-wnm4y-vkqyu-nmlhl-aqe [health: healthy]
  • ftgel-apwfx-aqphw-6itlw-as5il-53hfx-mtpy5-djn6y-7a6fa-3nqrs-5ae [health: healthy]
    node_provider                                                              data_center            data_center_owner            area                     country        
    -------------                                                              -----------            -----------------            ----                     -------        
    64xe5-tx2s3-4gjmj-pnozr-fejw2-77y5y-rhcjk-glnmx-62brf-qin5q-pqe  0 -> 1    an1          1 -> 0    Cyxtera                 1    Flanders       1 -> 0    AU            1
    6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe       1    at2               1    Data Inn                1    Gauteng             1    BE       1 -> 0
    7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae       1    gn1               1    Datacenter United  1 -> 0    Georgia             1    CA            1
    bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe       1    hk1               1    Datasite                1    Greater Noida       1    CH            1
    cp5ib-twnmx-h4dvd-isef2-tu44u-kb2ka-fise5-m4hta-hnxoq-k45mm-hqe       1    jb3               1    Digital Realty          1    HongKong            1    HK            1
    ihbuj-erwnc-tkjux-tqtnv-zkoar-uniy2-sk2go-xfpkc-znbb4-seukm-wqe       1    kr2          0 -> 1    Equinix                 1    Maribor             1    IN            1
    mme7u-zxs3z-jq3un-fbaly-nllcz-toct2-l2kp3-larrb-gti4r-u2bmo-dae       1    mb1               1    Gasan              0 -> 1    Melbourne           1    JP            1
    r3yjn-kthmg-pfgmb-2fngg-5c7d7-t6kqg-wi37r-j7gy6-iee64-kjdja-jae       1    mn2               1    NEXTDC                  1    Ontario             1    KR       0 -> 1
    rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae  1 -> 0    sg1               1    Nine.Ch                 1    Seoul          0 -> 1    LT            1
    sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae       1    sh1               1    Posita.si               1    Singapore           1    SE            1
    sma3p-ivkif-hz7nu-ngmvq-ibnjg-nubke-zf6gh-wbnfc-2dlng-l3die-zqe       1    to2               1    Telin                   1    Stockholm           1    SG            1
    ucjqj-jmbj3-rs4aq-ekzpw-ltjs3-zrcma-t6r3t-m5wxc-j5yrj-unwoj-mae       1    ty1          0 -> 1    Unicom                  1    Tokyo               1    SI            1
    vegae-c4chr-aetfj-7gzuh-c23sx-u2paz-vmvbn-bcage-pu7lu-mptnn-eqe       1    ty2          1 -> 0    Xneelo                  1    Vilnius             1    US            1
    wdjjk-blh44-lxm74-ojj43-rvgf4-j5rie-nm6xs-xvnuv-j3ptn-25t4v-6ae       1    vl2               1    Yotta                   1    Zurich              1    ZA            1
                                                                               zh4               1
1 Like
19

Proposal 134544

TLDR: I’ll adopt. The proposal links directly to what appears to be discussion with the NP about the proposal. Decentralisation stats look good.

Decentralisation Stats

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

Smallest Distance Average Distance Largest Distance
EXISTING 489.837 km 8303.16 km 16759.085 km
PROPOSED 549.609 km (+12.2%) 8394.684 km (+1.1%) 16672.927 km (-0.5%)

This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience). :+1:

Subnet characteristic counts →

Continents Countries Data Centers Owners Node Providers Node Operator
EXISTING 5 13 13 13 13 13
PROPOSED 5 13 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 Node Operator
EXISTING 5 1 1 1 1 1
PROPOSED 5 1 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)

image
image909×412 86.9 KB

Node Changes
Action Node Status Continent Country Data Center Owner Node Provider Node Operator
Remove lt3wc UP :bar_chart: Europe Belgium Antwerp (an1) Datacenter United Allusion pgunx
Remove 6xfo2 UP :bar_chart: Asia Japan Tokyo 2 (ty2) Equinix Starbase dpt4y
Add pfmqh UNASSIGNED :bar_chart: Asia Japan Tokyo (ty1) Equinix Starbase cqjev
Add ftgel UNASSIGNED :bar_chart: Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game 5dwhe
Other Nodes
Node Status Continent Country Data Center Owner Node Provider Node Operator
o2q5i UP :bar_chart: Oceania Australia Melbourne 2 (mn2) NEXTDC Icaria Systems Pty Ltd l5lhp
inlh6 UP :bar_chart: Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 4lp6i
5oe2d UP :bar_chart: Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc paxme
sbjj4 UP :bar_chart: Asia China HongKong 1 (hk1) Unicom Pindar Technology Limited vzsx4
wdg4t UP :bar_chart: Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS slaxf
zbzin UP :bar_chart: Europe Lithuania Vilnius 2 (vl2) Data Inn George Bassadone inluf
kjzcx UP :bar_chart: Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital d4bin
6ssdj UP :bar_chart: Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG 3xiew
pzdyu UP :bar_chart: Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Stiftung lgp6d
5i7he UP :bar_chart: Americas United States of America (the) Atlanta 2 (at2) Datasite BLP22, LLC 5syyj
qicnz UP :bar_chart: Africa South Africa Gauteng 3 (jb3) Xneelo Wolkboer (Pty) Ltd ymenq

*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).

You may wish to follow D-QUORUM if you found this analysis helpful.

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.

Additional good neurons to follow:

  • D-QUORUM (a highly decentralized neuron that follows neurons that have been elected by the NNS)
  • Synapse (currently 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)

Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.

20

Voted to adopt proposal #134544.

The proposal replaces two cordoned healthy Active status node 6xfo2 from the TY2 Data Center in Tokyo 2, and cordoned healthy Active status node lt3wc from the AN1 Data Center in Belgium, with unassigned healthy Awaiting status node pfmqh from Tokyo 1 and with unassigned healthy Awaiting status node ftgel from Korea, without any change to the decentralization of the subnet.
The motivation makes sense and the provided Forum link included in the summary provides further info, also it can be checked here.