Subnet Management - csyj4 (Application)

This topic is intended to capture Subnet Management activities over time for the csyj4 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": 44965,
  "records": [
    {
      "key": "subnet_record_csyj4-zmann-ys6ge-3kzi6-onexi-obayx-2fvak-zersm-euci4-6pslt-lae",
      "version": 44965,
      "value": {
        "membership": [
          "i4zve-soi3o-vqbql-gklv5-dbklt-g43ha-k3ju6-vdlrf-5t6lu-pyl3j-xqe",
          "k4ecc-uo6mt-3jzeo-axsrf-fm4s4-2v2fo-f2hai-nhbm7-ktblp-aixvz-iae",
          "cupz3-ehtqa-su3yl-2shoq-7yxw5-25uhz-g5kew-73dpi-w4gpu-hsmoi-vqe",
          "5az5s-5xxrd-ip5m2-6ps3s-uptc2-mz5gh-5ntqe-bmu7p-bhdyu-x4hu3-dae",
          "g3ug2-wz6kb-unyk6-6mj4f-halk3-kkfvi-k33iz-fftob-qipom-t4kzr-qqe",
          "kno7y-tdoxx-da524-svbxm-wt7xn-nyit3-vtsd4-nimle-vahxa-q65e6-oqe",
          "5s6r2-75ps5-mkxnk-litjj-szhkg-wanvq-jwuly-drl6j-ldie7-2ols7-yae",
          "wbqzc-cvi3c-gnuak-ztcqs-j4ga3-6m64f-w2fmy-qjqve-lzvja-rfir7-kae",
          "elons-ke2ex-4ykad-warsf-bi7zm-oskxc-un44b-phznq-sovqe-ko6u3-nqe",
          "3smci-63tqe-6q5xc-wpdmj-pnhan-own4t-6km2r-77mfh-c2h7d-xzunk-cqe",
          "6t3hc-abwek-snx4i-s57g2-w7u2g-beaec-jsjgx-g47s7-zjeb2-cb5pu-yqe",
          "zcxej-wovzy-rxnvs-bcz3a-ruh4s-a3blo-24ej7-izr7h-toic5-ix5gu-qqe",
          "pptbq-moz46-a4j7y-njscm-t3d3o-wj2pz-3vbak-4fqnt-trxz6-f4fg7-eae"
        ],
        "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": "b0ade55f7e8999e2842fe3f49df163ba224b71a2",
        "dkg_interval_length": 499,
        "start_as_nns": false,
        "subnet_type": "verified_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
      }
    }
  ]
}

Proposal 132218

This proposal sets the notarisation delay of the subnet to 300ms, down from 600ms. The change will increase the block rate of the subnet, aimed to reduce latency of update calls.

This is the same subnet config update that was applied to the canary subnet last week, which has held a steady and impressive block rate since. More context is available here → Reducing End to End latencies on the Internet Computer

Here are the current metrics for this subnet. A question I’ll be asking on the Subnet Management General thread (see reference below this post) is why this update is being rolled out to so many subnets at once, each with different finalisation rate and transaction profiles (e.g. peaks and troughs, whereas the canary subnet was always steady, even prior to the update). I’m wondering if this limits the representativeness of the results on that canary subnet.

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

Click here to open proposal details

Replace a node in subnet csyj4

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

Decentralization Nakamoto coefficient changes for subnet csyj4-zmann-ys6ge-3kzi6-onexi-obayx-2fvak-zersm-euci4-6pslt-lae:

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

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

Overall replacement impact: equal decentralization across all features

Impact on business rules penalties: 10 → 10

Details

Nodes removed:

  • pptbq-moz46-a4j7y-njscm-t3d3o-wj2pz-3vbak-4fqnt-trxz6-f4fg7-eae [health: healthy]

Nodes added:

  • 5hvab-67ek5-c7j2t-se7xt-zd3df-xjp6a-bnz76-kjx6e-bbx7e-rnwhz-nqe [health: healthy]
    node_provider                                                              data_center            data_center_owner            area                        country        
    -------------                                                              -----------            -----------------            ----                        -------        
    64xe5-tx2s3-4gjmj-pnozr-fejw2-77y5y-rhcjk-glnmx-62brf-qin5q-pqe  0 -> 1    aw1               1    Anonstake               1    Brussels Capital       1    AU            1
    6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe       1    br1               1    Digital Realty          2    Florida                1    BE            1
    6r5lw-l7db7-uwixn-iw5en-yy55y-ilbtq-e6gcv-g22r2-j3g6q-y37jk-jqe       1    fr2               1    Equinix            2 -> 1    Geneva                 1    CH            2
    7a4u2-gevsy-5c5fs-hsgri-n2kdz-dxxwf-btcfp-jykro-l4y7c-7xky2-aqe       1    ge1               1    Gasan              0 -> 1    Hesse                  1    DE            1
    7ryes-jnj73-bsyu4-lo6h7-lbxk5-x4ien-lylws-5qwzl-hxd5f-xjh3w-mqe       1    hk1               1    Green.ch                1    HongKong               1    HK            1
    bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe       1    jv1               1    HighDC                  1    Ljubljana              1    IN            1
    fwnmn-zn7yt-5jaia-fkxlr-dzwyu-keguq-npfxq-mc72w-exeae-n5thj-oae       1    kr2          0 -> 1    NEXTDC                  1    Panvel                 1    JP       1 -> 0
    kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae       1    lj2               1    Telin                   1    Pennsylvania           1    KR       0 -> 1
    r3yjn-kthmg-pfgmb-2fngg-5c7d7-t6kqg-wi37r-j7gy6-iee64-kjdja-jae       1    pl2               1    Tierpoint               2    Queensland             1    SE            1
    rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae       1    sc1               1    Unicom                  1    Seoul             0 -> 1    SG            1
    sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae  1 -> 0    sg1               1    Yotta                   1    Singapore              1    SI            1
    spp3m-vawt7-3gyh6-pjz5d-6zidf-up3qb-yte62-otexv-vfpqg-n6awf-lqe       1    sh1               1                                 Stockholm              1    US            2
    wdnqm-clqti-im5yf-iapio-avjom-kyppl-xuiza-oaz6z-smmts-52wyg-5ae       1    ty2          1 -> 0                                 Tokyo             1 -> 0                   
    zy4m7-z5mhs-zfkpl-zlsjl-blrbx-mvvmq-5z4zu-mf7eq-hhv7o-ezfro-3ae       1    zh6               1                                 Zurich                 1                   

Business rules check results before the membership change:

  • data_center_owner Digital Realty controls 2 of nodes, which is higher than target of 1 for the subnet. Applying penalty of 10.

Business rules check results after the membership change:

  • data_center_owner Digital Realty controls 2 of nodes, which is higher than target of 1 for the subnet. Applying penalty of 10.

Voted to reject proposal 134567 as this is part of a large batch of non-critical proposals timed such that the voting period clashes with national holidays, thereby allowing insufficient time for an appropriately detailed review to take place.

1 Like

Rejected proposal 134567. There’s no time to review this and the 18 other proposals in the same batch properly over Xmas eve, Xmas and Boxing Day. This is a non-critical proposal.

More information and discussion on this thread.

Proposal 134567

Vote: ADOPT

Replaces cordoned node pptbq with node 5hvab on subnet csyj4.
The reason for this proposal is to offboard TY2 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.

1 Like

Voted to adopt proposal #134567.

The proposal replaces cordoned healthy Active status node pptbq from the TY2 Data Center in Tokio, with unassigned healthy Awaiting status node 5hvab 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.