Subnet Management - jtdsg (Application)

This topic is intended to capture Subnet Management activities over time for the jtdsg 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": 44492,
  "records": [
    {
      "key": "subnet_record_jtdsg-3h6gi-hs7o5-z2soi-43w3z-soyl3-ajnp3-ekni5-sw553-5kw67-nqe",
      "version": 44492,
      "value": {
        "membership": [
          "4y5k6-auywv-zpovi-teeu2-bqfdx-spyxc-b76oo-ug55w-o4vrq-6z2jt-tae",
          "rphlf-rfstt-sg5fi-ytcie-gnuwt-osv5d-fg32b-stlgf-5ajgi-tiw2i-eae",
          "c4xi6-jnokz-uhpvd-lpwoe-hra3h-ph7ia-77clm-xfxf3-lskj2-4fohp-tqe",
          "3beeq-bvtv4-mxeff-2ypcm-jnw74-envji-bflpz-sipbb-e6gnt-kfptx-5qe",
          "4c63m-yfsxg-sy4dc-qhhvt-nwkgn-ib5fj-3qewz-svezz-2og3i-tlxll-eae",
          "dsnjt-rnuu4-vcgrm-wacun-da4y5-emipr-6bw7s-rxogu-7o2f3-a6zwb-yqe",
          "63wdw-l6myo-hzrps-cfj7d-p7fqi-snpzk-richg-7dvag-qn5el-r4li2-tae",
          "nioyi-lxtpk-fnexd-5ib4d-3x523-uu4ve-ro2tv-z5yuq-sf3dk-fdhrf-4qe",
          "gtc2a-34z6k-mld77-aucld-n6l4v-yv5hz-mon2d-narwo-b2z2k-thpyk-uae",
          "637ii-3bf4g-arp6y-a64q2-memci-bszoe-vqykw-4smuy-pew4q-bkg4j-oae",
          "i5kts-s424n-xg4np-i2wnx-lbb24-d7imi-veczd-l5dwq-4bvi6-ltdpg-7qe",
          "5i7qw-wbpwu-3kibh-m3lsc-rkjg2-feb44-rtlhn-mvjki-w3vzi-fc45x-iqe",
          "pym4f-y6zlv-feua6-7y7ao-cbvlp-hkwfn-hqzjd-5sdiu-rsv33-y7245-nqe"
        ],
        "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": "2c0b76cfc7e596d5c4304cff5222a2619294c8c1",
        "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
      }
    }
  ]
}

There’s an open proposal for changing subnet membership - https://dashboard.internetcomputer.org/proposal/131423. 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

Table
Country Data Center Owner Node Provider Node
--- Germany Munich (mu1) q.beyond Staking Facilities 5i7qw-wbpwu-3kibh-m3lsc-rkjg2-feb44-rtlhn-mvjki-w3vzi-fc45x-iqe
+++ China HongKong 1 (hk1) Unicom Wancloud limited oe52f-su776-yflut-ihohm-rm7gp-47fvy-alweq-ndg3i-g5uci-qzcvo-jqe
Australia Queensland 1 (sc1) NEXTDC Karel Frank 4y5k6-auywv-zpovi-teeu2-bqfdx-spyxc-b76oo-ug55w-o4vrq-6z2jt-tae
Belgium Brussels (br1) Digital Realty Allusion rphlf-rfstt-sg5fi-ytcie-gnuwt-osv5d-fg32b-stlgf-5ajgi-tiw2i-eae
Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs dsnjt-rnuu4-vcgrm-wacun-da4y5-emipr-6bw7s-rxogu-7o2f3-a6zwb-yqe
Switzerland Zurich 2 (zh2) Everyware DFINITY Operations SA gtc2a-34z6k-mld77-aucld-n6l4v-yv5hz-mon2d-narwo-b2z2k-thpyk-uae
Croatia Zagreb 1 (zg1) Anonstake Anonstake c4xi6-jnokz-uhpvd-lpwoe-hra3h-ph7ia-77clm-xfxf3-lskj2-4fohp-tqe
Japan Tokyo 3 (ty3) Equinix Starbase nioyi-lxtpk-fnexd-5ib4d-3x523-uu4ve-ro2tv-z5yuq-sf3dk-fdhrf-4qe
Latvia Riga 3 (rg3) Nano Bohatyrov Volodymyr 3beeq-bvtv4-mxeff-2ypcm-jnw74-envji-bflpz-sipbb-e6gnt-kfptx-5qe
Romania Bucharest (bu1) M247 Iancu Aurel pym4f-y6zlv-feua6-7y7ao-cbvlp-hkwfn-hqzjd-5sdiu-rsv33-y7245-nqe
Singapore Singapore 3 (sg3) Racks Central OneSixtyTwo Digital Capital 63wdw-l6myo-hzrps-cfj7d-p7fqi-snpzk-richg-7dvag-qn5el-r4li2-tae
Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG i5kts-s424n-xg4np-i2wnx-lbb24-d7imi-veczd-l5dwq-4bvi6-ltdpg-7qe
United States of America (the) Portland (pl1) Flexential 87m Neuron, LLC 637ii-3bf4g-arp6y-a64q2-memci-bszoe-vqykw-4smuy-pew4q-bkg4j-oae
South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd 4c63m-yfsxg-sy4dc-qhhvt-nwkgn-ib5fj-3qewz-svezz-2og3i-tlxll-eae

The removed node is replaced with a node based in China. 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.

Subnet jtdsg is being made public by → Expanding the list of Public Subnets on the Internet Computer - Governance / NNS proposal discussions - Internet Computer Developer Forum (dfinity.org)

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

2 Likes

Voted to adopt proposal 133065. The initial_notary_delay_millis is set to 300 and the subnet_id is correct.

1 Like
1 Like

Voted to adopt proposal 134407.

This proposal replaces node 637ii which appears in the dashboard as “Status: Active”. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.

The stated purpose of this change is to remove nodes in the PL1 data centre as the node provider “is selling the PL1 DC after 48 months”. It’s not clear from the information linked whether the node provider is selling the entire data centre or just the node machines, but removal of the nodes for one or other of these purposes is consistent with this post from the node provider, the processes described in the same forum thread and the information in 87m Neuron’s node provider record in the IC dashboard. Additionally, the self-declaration documents provided match the provided hashes.

2 Likes

Proposal 134407

Vote: ADOPT

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.

1 Like

I’ve voted to reject proposal 134407. It makes claims that I see no clear way of verifying. This sort of verifiability issue was brought up months ago, where it was indicated that NPs would provide explicit confirmation of their alignment with specific proposals that are based on an understanding between the NP and the proposer. The proposal doesn’t link to such a post. Note that there are issues with that approach as well (given the ease with which such posts could be forged by the proposer), but this would at least be a start.

I’m currently thinking about starting a discussion, and an associated motion proposal, about how to make this sort of thing more verifiable.

1 Like

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

Click here to open proposal details

Replace a node in subnet jtdsg

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

Decentralization Nakamoto coefficient changes for subnet jtdsg-3h6gi-hs7o5-z2soi-43w3z-soyl3-ajnp3-ekni5-sw553-5kw67-nqe:

    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:

  • 63wdw-l6myo-hzrps-cfj7d-p7fqi-snpzk-richg-7dvag-qn5el-r4li2-tae [health: healthy]

Nodes added:

  • tjg3r-ffr6q-hu7rb-4wevn-e4tlr-brdq3-zvobk-t4aof-5zix7-qfi2w-vqe [health: healthy]
    node_provider                                                         data_center            data_center_owner            area                   country   
    -------------                                                         -----------            -----------------            ----                   -------   
    6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe  1    br1               1    Anonstake               1    Brussels Capital  1    AU       1
    7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae  1    bu1               1    Cyxtera                 1    Bucuresti         1    BE       1
    bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe  1    ct2               1    Datasite                1    Cape Town         1    CA       1
    dhywe-eouw6-hstpj-ahsnw-xnjxq-cmqks-47mrg-nnncb-3sr5d-rac6m-nae  1    hk1               1    Digital Realty          1    Florida           1    CH       1
    g2ax6-jrkmb-3zuh3-jibtb-q5xoq-njrgo-5utbc-j2o7g-zfq2w-yyhky-dqe  1    lj1               1    Equinix                 1    HongKong          1    HK       1
    i7dto-bgkj2-xo5dx-cyrb7-zkk5y-q46eh-gz6iq-qkgyc-w4qte-scgtb-6ae  1    or1               1    Everyware               1    Ljubljana         1    HR       1
    kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae  1    rg3               1    M247                    1    Ontario           1    JP       1
    py2kr-ipr2p-ryh66-x3a3v-5ts6u-7rfhf-alkna-ueffh-hz5ox-lt6du-qqe  1    sc1               1    NEXTDC                  1    Queensland        1    LV       1
    rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae  1    sg1          0 -> 1    Nano                    1    Riga              1    RO       1
    sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae  1    sg3          1 -> 0    Posita.si               1    Singapore         1    SG       1
    unqqg-no4b2-vbyad-ytik2-t3vly-3e57q-aje2t-sjb5l-bd4ke-chggn-uqe  1    to2               1    Racks Central      1 -> 0    Tokyo             1    SI       1
    wdjjk-blh44-lxm74-ojj43-rvgf4-j5rie-nm6xs-xvnuv-j3ptn-25t4v-6ae  1    ty3               1    Telin              0 -> 1    Zagreb            1    US       1
    wwdbq-xuqhf-eydzu-oyl7p-ga565-zm7s7-yrive-ozgsy-zzgh3-qwb3j-cae  1    zg1               1    Teraco                  1    Zurich            1    ZA       1
                                                                          zh2               1    Unicom                  1                                     
1 Like

Proposal 134549

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 117.012 km 8088.339 km 16748.078 km
PROPOSED 117.012 km 8088.339 km 16748.078 km

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 6 1 1 1 1 1
PROPOSED 6 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)

Node Changes
Action Node Status Continent Country Data Center Owner Node Provider Node Operator
Remove 63wdw UP :bar_chart: Asia Singapore Singapore 3 (sg3) Racks Central OneSixtyTwo Digital Capital 5mhxl
Add tjg3r UNASSIGNED :bar_chart: Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital d4bin
Other Nodes
Node Status Continent Country Data Center Owner Node Provider Node Operator
4y5k6 UP :bar_chart: Oceania Australia Queensland 1 (sc1) NEXTDC Karel Frank f3toa
rphlf UP :bar_chart: Europe Belgium Brussels (br1) Digital Realty Allusion mjeqs
dsnjt UP :bar_chart: Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 4lp6i
gtc2a UP :bar_chart: Europe Switzerland Zurich 2 (zh2) Everyware DFINITY Stiftung vqe65
oe52f UP :bar_chart: Asia China HongKong 1 (hk1) Unicom Wancloud limited z6cfb
c4xi6 UP :bar_chart: Europe Croatia Zagreb 1 (zg1) Anonstake Anonstake 3sm7v
nioyi UP :bar_chart: Asia Japan Tokyo 3 (ty3) Equinix Starbase a5glg
3beeq UP :bar_chart: Europe Latvia Riga 3 (rg3) Nano Bohatyrov Volodymyr 6igux
pym4f UP :bar_chart: Europe Romania Bucharest (bu1) M247 Iancu Aurel c5ssg
i5kts UP :bar_chart: Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG gl27f
46qvk UP :bar_chart: Americas United States of America (the) Orlando (or1) Datasite Giant Leaf, LLC redpf
4c63m UP :bar_chart: Africa South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd x7fjr

*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.

Voted to adopt proposal #134549.

The proposal replaces cordoned healthy Active status node 63wdw from the SG3 Data Center in Singapore 3 with unassigned healthy Awaiting status node tjg3r from Singapore 1, 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.

Voted to adopt proposal 134549.

This proposal replaces 1 node, due to offboarding SG3 data centre. Decentralisation parameters are unchanged and remain within the requirements of the target topology. Data centre details are consistent with the links provided in the proposal.

Proposal 134549

Vote: ADOPT

Replaces cordoned node 63wdw with node tjg3r on subnet jtdsg.
The reason for this proposal is to offboard SG3 DC consistent with forum posts made on the forum thread used for posts regarding the renovation/sell of Gen-1 node machines by NPs.
Both the NP and DC stated in the forum post match the ones from the node being removed in the proposal.

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

Click here to open proposal details

Replace a node in subnet jtdsg

Motivation:
The node operator 3sm7v (under NP kos24) has 4 nodes in total and currently has all nodes assigned to subnets. We propose to remove one of the operator’s nodes from subnet jtdsg to allow optimization of the overall network topology. The removal of the node from the subnet does not worsen subnet decentralization, and may allow the node to be assigned to subnet where it would improve decentralization.

Decentralization Nakamoto coefficient changes for subnet jtdsg-3h6gi-hs7o5-z2soi-43w3z-soyl3-ajnp3-ekni5-sw553-5kw67-nqe:

    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:

  • c4xi6-jnokz-uhpvd-lpwoe-hra3h-ph7ia-77clm-xfxf3-lskj2-4fohp-tqe [health: healthy]

Nodes added:

  • vt5q3-2bev5-yhmxc-uxp3l-j26fn-tnlfb-sdstt-yoqf4-bio44-yyycs-vae [health: healthy]
    node_provider                                                              data_center            data_center_owner            area                        country        
    -------------                                                              -----------            -----------------            ----                        -------        
    4dibr-2alzr-h6kva-bvwn2-yqgsl-o577t-od46o-v275p-a2zov-tcw4f-eae  0 -> 1    br1               1    Anonstake          1 -> 0    Brussels Capital       1    AU            1
    6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe       1    bu1               1    Cyxtera                 1    Bucuresti              1    BE            1
    7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae       1    ct2               1    Datasite                1    Cape Town              1    CA            1
    bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe       1    hk1               1    Digital Realty          1    Florida                1    CH            1
    dhywe-eouw6-hstpj-ahsnw-xnjxq-cmqks-47mrg-nnncb-3sr5d-rac6m-nae       1    lj1               1    Equinix                 1    HongKong               1    HK            1
    g2ax6-jrkmb-3zuh3-jibtb-q5xoq-njrgo-5utbc-j2o7g-zfq2w-yyhky-dqe       1    or1               1    Everyware               1    Ljubljana              1    HR       1 -> 0
    i7dto-bgkj2-xo5dx-cyrb7-zkk5y-q46eh-gz6iq-qkgyc-w4qte-scgtb-6ae       1    rg3               1    M247                    1    Ontario                1    JP            1
    kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae  1 -> 0    sc1               1    Megazone Cloud     0 -> 1    Queensland             1    KR       0 -> 1
    py2kr-ipr2p-ryh66-x3a3v-5ts6u-7rfhf-alkna-ueffh-hz5ox-lt6du-qqe       1    sg1               1    NEXTDC                  1    Riga                   1    LV            1
    rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae       1    sl1          0 -> 1    Nano                    1    Seoul             0 -> 1    RO            1
    sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae       1    to2               1    Posita.si               1    Singapore              1    SG            1
    unqqg-no4b2-vbyad-ytik2-t3vly-3e57q-aje2t-sjb5l-bd4ke-chggn-uqe       1    ty3               1    Telin                   1    Tokyo                  1    SI            1
    wdjjk-blh44-lxm74-ojj43-rvgf4-j5rie-nm6xs-xvnuv-j3ptn-25t4v-6ae       1    zg1          1 -> 0    Teraco                  1    Zagreb            1 -> 0    US            1
    wwdbq-xuqhf-eydzu-oyl7p-ga565-zm7s7-yrive-ozgsy-zzgh3-qwb3j-cae       1    zh2               1    Unicom                  1    Zurich                 1    ZA            1

Proposal 134634

TLDR: I’ll adopt. This proposal improves decentralisation stats (see below), while also increasing the odds that other subnets can be improved using unassigned nodes.

The node operator 3sm7v (under NP kos24) has 4 nodes in total and currently has all nodes assigned to subnets

:point_up: This claim can be inspected by running a text search on the full list of node details and state.

1 removed Croatian node replaced with a node in South Korea.

Decentralisation Stats

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

Smallest Distance Average Distance Largest Distance
EXISTING 117.012 km 8088.339 km 16748.078 km
PROPOSED 477.324 km (+307.9%) 8327.655 km (+3%) 16748.078 km

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 6 1 1 1 1 1
PROPOSED 5 (-16.67%) 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)

Node Changes
Action Node Status Continent Country Data Center Owner Node Provider Node Operator
Remove c4xi6 UP :bar_chart: Europe Croatia Zagreb 1 (zg1) Anonstake Anonstake 3sm7v
Add vt5q3 UNASSIGNED :bar_chart: Asia Korea (the Republic of) Seoul 1 (sl1) Megazone Cloud Neptune Partners ukji3
Other Nodes
Node Status Continent Country Data Center Owner Node Provider Node Operator
4y5k6 UP :bar_chart: Oceania Australia Queensland 1 (sc1) NEXTDC Karel Frank f3toa
rphlf UP :bar_chart: Europe Belgium Brussels (br1) Digital Realty Allusion mjeqs
dsnjt UP :bar_chart: Americas Canada Toronto 2 (to2) Cyxtera Blockchain Development Labs 4lp6i
gtc2a UP :bar_chart: Europe Switzerland Zurich 2 (zh2) Everyware DFINITY Stiftung vqe65
oe52f UP :bar_chart: Asia China HongKong 1 (hk1) Unicom Wancloud limited z6cfb
nioyi UP :bar_chart: Asia Japan Tokyo 3 (ty3) Equinix Starbase a5glg
3beeq UP :bar_chart: Europe Latvia Riga 3 (rg3) Nano Bohatyrov Volodymyr 6igux
pym4f UP :bar_chart: Europe Romania Bucharest (bu1) M247 Iancu Aurel c5ssg
tjg3r UP :bar_chart: Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital d4bin
i5kts UP :bar_chart: Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG gl27f
46qvk UP :bar_chart: Americas United States of America (the) Orlando (or1) Datasite Giant Leaf, LLC redpf
4c63m UP :bar_chart: Africa South Africa Cape Town 2 (ct2) Teraco Kontrapunt (Pty) Ltd x7fjr

*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.

Voted to adopt proposal 134634.

This proposal replaces node c4xi6 which appears in the dashboard as “Status: Active”, for the purpose of making it available to other subnets in order to improve overall network topology. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.

1 Like

Proposal 134634 – LaCosta | CodeGov

Vote: ADOPT

The proposal replaces two nodes on subnet jtdsg.
Removed Nodes: c4xi6, Dashboard Status Active
Added Nodes: vt5q3, Dashboard Status Awaiting
The proposal removes a node from the NO 3sm7v under NP Anonstake that currently has 4 nodes assigned in order to make it available to another subnet in order to improve the overall network topology as verified with the ic-api (This tool is not open-source). There is not impact in the decentralization parameters.

About CodeGov...

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.

1 Like

Proposal #134634 — Zack | CodeGov

Vote: Adopted

Reason:
The proposal replaces one healthy Active status node c4xi6 from Zagreb,Croatia ,
with unassigned healthy Awaiting status node vt5q3 from Seoul, Korea without any change to the decentralization of the subnet, leaving node operator 3sm7v-xy7wb-u52om-cq3td-wboo7-aj4fi-dqnam-jahlz-swqib-ynipm-mqe of Node Provider Anonstake kos24 with 3 out of 4 nodes assigned, and thus allowing one node to be assigned in the future to any subnet where it would help improve decentralization.

About CodeGov (...click to expand...).

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.

1 Like