Subnet Management - k44fs (Application)

This topic is intended to capture Subnet Management activities over time for the k44fs 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": 44478,
  "records": [
    {
      "key": "subnet_record_k44fs-gm4pv-afozh-rs7zw-cg32n-u7xov-xqyx3-2pw5q-eucnu-cosd4-uqe",
      "version": 44478,
      "value": {
        "membership": [
          "pxyu4-nrrqd-w3vmd-egofs-gpia5-tljnw-gtnuv-rueu6-2sxij-24x3x-gqe",
          "nbela-otrcc-dakmr-4ljx7-igd2t-3ge3b-xskv7-cnj65-co4r7-cjxyd-vqe",
          "gs6io-zywbn-ax37l-3sijy-b72cq-ljqnf-dhz6e-x5qqz-7v6va-xterb-qae",
          "ltav6-3lsov-3cp5a-lswi6-dwyes-nyery-l3in3-tqcj2-6o4cc-pnqit-jqe",
          "q3sji-7croe-uqcsz-rva4e-orlkf-c4y44-b2sl4-shnns-l57fz-fn2wa-xqe",
          "ztrgw-a7sec-ynzfd-utn5y-lnjjs-eb3w5-3yc6s-rygch-tizry-xvjwr-uae",
          "lfque-cnxjq-mq7nk-tcmti-tm2bn-sgwin-uclrl-kdkmt-y6epr-ltweh-zqe",
          "gd2vp-cewud-bap4i-b3vb4-jbxhf-3ojbk-d2n6l-wg46d-vcovk-bjwyz-tqe",
          "amjrq-m7xgs-bacs7-g54xa-t72h6-dszrv-7mj3i-6vcbx-3zzb2-6eean-xqe",
          "2o33b-cheo6-ozp6n-sjrqc-cbro3-bslrm-kuhqz-wpncp-vlhji-jzeoj-6ae",
          "yh3a6-fzjir-23ow3-cnsz4-w56dj-veho7-qvu6c-psj3h-uscb5-4ikej-pae",
          "dvywh-wfuga-x6hes-4hrar-nomdt-d7tzv-x463j-ufb3c-cestw-rgxkh-kae",
          "d7dyc-slisa-nrkkz-hrpee-2xbpi-xjido-shkjk-vrtob-cmfxd-6sevt-5qe"
        ],
        "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/131427. 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 dvywh-wfuga-x6hes-4hrar-nomdt-d7tzv-x463j-ufb3c-cestw-rgxkh-kae
+++ Slovenia Maribor (mb1) Posita.si Fractal Labs AG wjidr-63mpn-3nnhd-knwl2-hiq65-to2lf-4zlii-o4tab-big3p-cbfpz-jae
Australia Melbourne 2 (mn2) NEXTDC Icaria Systems Pty Ltd ztrgw-a7sec-ynzfd-utn5y-lnjjs-eb3w5-3yc6s-rygch-tizry-xvjwr-uae
Belgium Brussels (br1) Digital Realty Allusion yh3a6-fzjir-23ow3-cnsz4-w56dj-veho7-qvu6c-psj3h-uscb5-4ikej-pae
Canada Toronto (to1) Cyxtera Blockchain Development Labs gs6io-zywbn-ax37l-3sijy-b72cq-ljqnf-dhz6e-x5qqz-7v6va-xterb-qae
Switzerland Zurich 2 (zh2) Everyware DFINITY Operations SA gd2vp-cewud-bap4i-b3vb4-jbxhf-3ojbk-d2n6l-wg46d-vcovk-bjwyz-tqe
Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC nbela-otrcc-dakmr-4ljx7-igd2t-3ge3b-xskv7-cnj65-co4r7-cjxyd-vqe
Georgia Tbilisi 1 (tb1) Cloud9 George Bassadone q3sji-7croe-uqcsz-rva4e-orlkf-c4y44-b2sl4-shnns-l57fz-fn2wa-xqe
India Greater Noida 1 (gn1) Yotta ACCUSET SOLUTIONS ltav6-3lsov-3cp5a-lswi6-dwyes-nyery-l3in3-tqcj2-6o4cc-pnqit-jqe
Japan Tokyo 2 (ty2) Equinix Starbase pxyu4-nrrqd-w3vmd-egofs-gpia5-tljnw-gtnuv-rueu6-2sxij-24x3x-gqe
Romania Bucharest (bu1) M247 Iancu Aurel d7dyc-slisa-nrkkz-hrpee-2xbpi-xjido-shkjk-vrtob-cmfxd-6sevt-5qe
Singapore Singapore 3 (sg3) Racks Central OneSixtyTwo Digital Capital amjrq-m7xgs-bacs7-g54xa-t72h6-dszrv-7mj3i-6vcbx-3zzb2-6eean-xqe
United States of America (the) San Jose (sj1) INAP Mary Ren 2o33b-cheo6-ozp6n-sjrqc-cbro3-bslrm-kuhqz-wpncp-vlhji-jzeoj-6ae
South Africa Gauteng 2 (jb2) Africa Data Centres Karel Frank lfque-cnxjq-mq7nk-tcmti-tm2bn-sgwin-uclrl-kdkmt-y6epr-ltweh-zqe

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

1 Like

I love the maps but struggle a bit to make out the unchanged nodes. Maybe they could be shown in a neutral colour such as blue?

2 Likes

Thanks @bitdivine, I’ll try making them blue on the next one :slight_smile:

2 Likes

This subnet is being made private 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, k44fs, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread).

4 Likes

Voted to adopt Proposal 133141. This proposal is intended to reduce network latency by reducing the notarization delay from 600ms to 300ms for subnet k44fs, as has now happened for the majority of application subnets.

4 Likes

Voted to adopt, the id is a match and it’s the same reduction as we are all aware of on majority of subnets by now.

2 Likes

Voted to adopt proposal 133141. Similar to recent proposals that have been made targeting application subnets like k44fs to reduce the notarization delay from 600ms to 300ms according to roadmaps established.

1 Like

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

I’ve voted to reject proposal 134277. 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.

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