Subnet Management - 3hhby (Application)

Governance NNS proposal discussions
, ,
1

This topic is intended to capture Subnet Management activities over time for the 3hhby 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": 44324,
  "records": [
    {
      "key": "subnet_record_3hhby-wmtmw-umt4t-7ieyg-bbiig-xiylg-sblrt-voxgt-bqckd-a75bf-rqe",
      "version": 44324,
      "value": {
        "membership": [
          "ocony-vhzun-3ygcw-3mck2-2knqd-d47bv-hi7jq-kbfc5-xf6ui-ou5c4-bqe",
          "zjcl6-i6eie-fllmg-27ohu-lm4cy-4dax2-7ppcd-4mgig-rtfpz-typl6-yqe",
          "tav5h-wv4rc-ty5vk-jgfh2-vm4uv-rtcm6-vasc2-acr5w-vop75-sjvut-gqe",
          "hgbum-72ne6-onsua-rjul3-siwu5-da4zu-wkqro-rm4el-52osh-bhkgi-dqe",
          "va53e-afslx-vabwe-whjns-r66hd-coh34-aeb7w-omrcv-3so2u-esow7-aae",
          "fpr2v-bm77g-drpwg-jjsb2-hsqtt-62nci-e37d3-qsi33-gs72f-txmoz-gqe",
          "a6t2w-sxcps-qmgvc-vlitk-kvrsv-pqpl7-hylkb-urlhs-gove6-ehq7x-iae",
          "plofy-xgqcd-j5rdn-uby5b-pxymt-w5yzc-jumzd-rhosg-33xha-krwao-sae",
          "ega5w-ekfo7-lejfc-fve6j-vnml3-2nmxj-flw2p-564o4-rhier-bz73x-aae",
          "eyn4b-3u2bj-osfyg-3evgx-ycrbg-agyjv-zfre3-qmfc4-u7jwh-w2qap-fqe",
          "3ppfv-vqufk-yrg2j-nos4h-6fxos-iucst-jsf7h-be4fn-im63d-fnbir-jae",
          "7h3aw-y3ygk-37mdb-cbuj7-ric2q-b7pgf-xwspg-bxzq5-cxid3-lqqwi-nae",
          "aicg2-docau-ham5w-5yl6j-k5jj5-tc5yu-eicbx-2plu3-ta6ey-ixhun-xqe"
        ],
        "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 Likes
2

Thereā€™s an open proposal for changing subnet membership - Proposal: 131406 - ICP Dashboard (internetcomputer.org). 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
image939Ɨ429 50.6 KB

Table
Country Data Center Owner Node Provider Node
--- Germany Munich (mu1) q.beyond Staking Facilities eyn4b-3u2bj-osfyg-3evgx-ycrbg-agyjv-zfre3-qmfc4-u7jwh-w2qap-fqe
+++ India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS vte5d-zw5lg-axpbi-yrc6s-nm3mj-knu44-piwp3-ukrtj-xb4s5-mleiq-lae
Australia Melbourne 2 (mn2) NEXTDC Icaria Systems Pty Ltd zjcl6-i6eie-fllmg-27ohu-lm4cy-4dax2-7ppcd-4mgig-rtfpz-typl6-yqe
Belgium Antwerp (an1) Datacenter United Allusion plofy-xgqcd-j5rdn-uby5b-pxymt-w5yzc-jumzd-rhosg-33xha-krwao-sae
Switzerland Geneva 2 (ge2) SafeHost Archery Blockchain SCSp ega5w-ekfo7-lejfc-fve6j-vnml3-2nmxj-flw2p-564o4-rhier-bz73x-aae
Switzerland Zurich 2 (zh2) Everyware DFINITY Operations SA hgbum-72ne6-onsua-rjul3-siwu5-da4zu-wkqro-rm4el-52osh-bhkgi-dqe
Germany Frankfurt 2 (fr2) Equinix Virtual Hive Ltd a6t2w-sxcps-qmgvc-vlitk-kvrsv-pqpl7-hylkb-urlhs-gove6-ehq7x-iae
Japan Tokyo 2 (ty2) Equinix Starbase aicg2-docau-ham5w-5yl6j-k5jj5-tc5yu-eicbx-2plu3-ta6ey-ixhun-xqe
Romania Bucharest (bu1) M247 Iancu Aurel 7h3aw-y3ygk-37mdb-cbuj7-ric2q-b7pgf-xwspg-bxzq5-cxid3-lqqwi-nae
Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital 3ppfv-vqufk-yrg2j-nos4h-6fxos-iucst-jsf7h-be4fn-im63d-fnbir-jae
Slovenia Ljubljana 2 (lj2) Anonstake Anonstake ocony-vhzun-3ygcw-3mck2-2knqd-d47bv-hi7jq-kbfc5-xf6ui-ou5c4-bqe
United States of America (the) Allentown (aw1) Tierpoint Bigger Capital va53e-afslx-vabwe-whjns-r66hd-coh34-aeb7w-omrcv-3so2u-esow7-aae
United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers tav5h-wv4rc-ty5vk-jgfh2-vm4uv-rtcm6-vasc2-acr5w-vop75-sjvut-gqe
United States of America (the) Tampa (tp1) Flexential Richard Ma fpr2v-bm77g-drpwg-jjsb2-hsqtt-62nci-e37d3-qsi33-gs72f-txmoz-gqe

The removed node is replaced with a node based in India. This certainly seems positive for decentralisation (many existing nodes are clustered in central Europe). 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. I have some questions about this which Iā€™ve asked on another topic.

1 Like
3

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

2 Likes
4

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

1 Like
5

Voted to adopt proposal 134177, as the reasoning is sound and the description matches the payload. This proposal replaces 2 healthy nodes, both of which appear as ā€œActiveā€ on the IC dashboard. The proposed change improves decentralisation with respect to data centre owner and country and brings the target topology parameters to within the requirements.

2 Likes
6

Proposal 134177

TLDR: Another great proposal, Iā€™m planning to adopt. This brings the subnet inline with the IC Target Topology, by reducing the max number of nodes per country to 2, and the max number of nodes per operator from 2 to 1 (see ā€˜Decentralisation Statsā€™ below for more detail).

Note that decentralisation in terms of max number of nodes per continent is negatively effected, but continents are not part of the formal IC Target Topology.

Motivation:

  • replacing node va53e-afslx-vabwe-whjns-r66hd-coh34-aeb7w-omrcv-3so2u-esow7-aae to optimize network topology
  • replacing node aicg2-docau-ham5w-5yl6j-k5jj5-tc5yu-eicbx-2plu3-ta6ey-ixhun-xqe to optimize network topology

2 removed node in the US and Japan, replaced with nodes in Lithuania and Latvia.

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) ā†’

Smallest Distance Average Distance Largest Distance
EXISTING 242.077 km 7665.692 km 16759.085 km
PROPOSED 242.077 km 6554.725 km (-14.5%) 16759.085 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 Node Operator
EXISTING 4 10 13 12 13 13
PROPOSED 4 11 (+9.1%) 13 13 (+7.7%) 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 6 3 1 2 1 1
PROPOSED 8 (+33.34%) 2 (-33.34%) 1 1 (-50%) 1 1
:star_struck: :point_up: :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
image988Ɨ415 79 KB

Table
Continent Country Data Center Owner Node Provider Node Operator Node Status Performance
--- Asia Japan Tokyo 2 (ty2) Equinix Starbase dpt4y aicg2-docau-ham5w-5yl6j-k5jj5-tc5yu-eicbx-2plu3-ta6ey-ixhun-xqe UP :bar_chart:
--- Americas United States of America (the) Allentown (aw1) Tierpoint Bigger Capital codio va53e-afslx-vabwe-whjns-r66hd-coh34-aeb7w-omrcv-3so2u-esow7-aae UP :bar_chart:
+++ Europe Lithuania Vilnius 1 (bt1) Baltneta Artem Horodyskyi cn25n lsew2-tmjjw-ytiyx-st6sx-qo2wi-cxu3e-sgidd-i34jd-okjsn-rtli5-cqe UNASSIGNED :bar_chart:
+++ Europe Latvia Riga 1 (rg1) DEAC Maksym Ishchenko lh42a lmfy6-g2wta-3pp67-cjv5u-qws2j-kf3ci-tkze3-iqucl-mscsw-3u7bx-jae UNASSIGNED :bar_chart:
Oceania Australia Melbourne 2 (mn2) NEXTDC Icaria Systems Pty Ltd l5lhp zjcl6-i6eie-fllmg-27ohu-lm4cy-4dax2-7ppcd-4mgig-rtfpz-typl6-yqe UP :bar_chart:
Europe Belgium Antwerp (an1) Datacenter United Allusion pgunx plofy-xgqcd-j5rdn-uby5b-pxymt-w5yzc-jumzd-rhosg-33xha-krwao-sae UP :bar_chart:
Europe Switzerland Zurich 2 (zh2) Everyware DFINITY Operations SA pi3wm hgbum-72ne6-onsua-rjul3-siwu5-da4zu-wkqro-rm4el-52osh-bhkgi-dqe UP :bar_chart:
Europe Germany Frankfurt 2 (fr2) Equinix Virtual Hive Ltd 3nu7r a6t2w-sxcps-qmgvc-vlitk-kvrsv-pqpl7-hylkb-urlhs-gove6-ehq7x-iae UP :bar_chart:
Europe Germany Geneva 2 (ge2) SafeHost Archery Blockchain SCSp 5atxd ega5w-ekfo7-lejfc-fve6j-vnml3-2nmxj-flw2p-564o4-rhier-bz73x-aae UP :bar_chart:
Asia India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS slaxf vte5d-zw5lg-axpbi-yrc6s-nm3mj-knu44-piwp3-ukrtj-xb4s5-mleiq-lae UP :bar_chart:
Europe Romania Bucharest (bu1) M247 Iancu Aurel c5ssg 7h3aw-y3ygk-37mdb-cbuj7-ric2q-b7pgf-xwspg-bxzq5-cxid3-lqqwi-nae UP :bar_chart:
Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital d4bin 3ppfv-vqufk-yrg2j-nos4h-6fxos-iucst-jsf7h-be4fn-im63d-fnbir-jae UP :bar_chart:
Europe Slovenia Ljubljana 2 (lj2) Anonstake Anonstake eu5wc ocony-vhzun-3ygcw-3mck2-2knqd-d47bv-hi7jq-kbfc5-xf6ui-ou5c4-bqe UP :bar_chart:
Americas United States of America (the) Chicago 3 (ch3) CyrusOne MI Servers t37p3 tav5h-wv4rc-ty5vk-jgfh2-vm4uv-rtcm6-vasc2-acr5w-vop75-sjvut-gqe UP :bar_chart:
Americas United States of America (the) Tampa (tp1) Flexential Richard Ma z6nmn fpr2v-bm77g-drpwg-jjsb2-hsqtt-62nci-e37d3-qsi33-gs72f-txmoz-gqe 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)

2 Likes
7

Voted to adopt proposal #134177.

The proposal replaces 2 healthy Active status nodes form Allentown, US and Tokyo2, JP in order to optimize network topology.

2 Likes
8

Voted to adopt proposal 134177. The proposal replaces two nodes from subnet 3hhby:
Removed Nodes: va53e, aicg2.
Added Nodes: lsew2 and lmfy6.
The proposal was verified using the DRE tool to verify the metrics stated. All nodes replaced are healthy but this replacements improve the network topology on the data_center_owner and country metrics.

1 Like
9
10

Voted to adopt proposal 134270. The proposal seeks to remove a cordoned node from the subnet and specifies that the associated data centre is being offboarded ā€œafter 48 monthsā€. Decentralisation parameters are improved with respect to country. The necessary context is provided by this forum post and associated discussion. For future proposals of this type I recommend that the background context be included in the proposal text for ease of verification.

2 Likes
11

Iā€™ve voted to reject proposal 134270. It makes claims that I see no clear way of verifying, and supporting statements regarding the ownership of the data centre are inconsistent with records held in the IC registry. The proposal was announced here.

12

Voted to adopt proposal 134270. 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.

13

This public subnet has now been made private.

14

Voted to adopt proposal 134406.

This proposal replaces node ega5w which appears in the dashboard as ā€œStatus: Activeā€, for the purpose of examining the stability of another node operatorā€™s nodes. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.

15

Iā€™ve vote to adopt proposal 134406. The decentralisation coefficients were unchanged by the proposal. As can be observed using the IC-API, the eikix node operator has 26 nodes (as stated in the proposal summary). Now that this proposal has executed, one of those nodes is assigned (5u6dm).

Note that the IC-API is not open source. Since learning this, Iā€™m in the process of switching over verifiable sources of this sort of information (rejecting because Iā€™ve not had time to do this yet would be too harsh - even for me :wink:).

16

Proposal 134406

Vote: ADOPT

The proposal replaces one node from subnet 3hhby:
Removed Node: ega5w
Added Node: 5u6dm
The proposal was verified using the DRE tool to verify the metrics stated. The NP that controlls the node removed as at least one node active and isnā€™t affected by this replacement.