Subnet Management - 2fq7c (Application)

Governance NNS proposal discussions
, ,
1

This topic is intended to capture Subnet Management activities over time for the 2fq7c 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": 44273,
  "records": [
    {
      "key": "subnet_record_2fq7c-slacv-26cgz-vzbx2-2jrcs-5edph-i5s2j-tck77-c3rlz-iobzx-mqe",
      "version": 44273,
      "value": {
        "membership": [
          "33aap-jupxw-h3tb3-nohh2-dphn4-z6mfh-22pqt-if4yr-dmkd4-ekp7q-wae",
          "fh6lp-xtfi2-7aa22-dsx64-hs42f-hc2a2-wfqsu-5rvnk-7wcf7-yu6cm-kae",
          "6wnv3-oxkmg-rtcgq-slqsn-5xlwu-7a27t-524pa-st7b3-epsck-tixsa-uqe",
          "jys4w-lodfn-h5325-xters-z3hf2-v7imc-ow7dh-py22m-epjvt-aldwt-oqe",
          "jux3z-ivwyz-ury64-jth4b-rrbfi-sx5af-ci72l-j4ot3-nl5jk-z4ilu-6qe",
          "ptzzn-jphjl-476ql-lgyrk-37oa6-zxhat-ynn4f-fm2ry-r3cmf-lx7e6-uae",
          "buqsd-72zlu-hbgr2-hzjnr-mgvyj-6ldtg-2hdsd-igtpb-q7p2l-4j43v-5ae",
          "b7ldm-xgdir-7eraz-sws5m-tzstj-clkrl-hs444-ty5nj-qnkrx-nofhs-hae",
          "asad5-qg3gv-p5hrf-7liwa-zkoia-t2imf-sztmb-okb3k-gc6ei-xzp77-5qe",
          "uznxh-cff3i-uso5i-u27p7-ardz7-4vihf-vkme6-i76b5-oejzx-2xewb-lqe",
          "n74se-c345d-2jd4b-leuu6-jyvim-vcllk-aahj2-vjpvn-pbpks-xtgy2-4qe",
          "jq33i-hlo5d-hyou6-wsgu4-vi7o6-upgg3-pzawk-les4l-gn3fg-eplfx-eae",
          "ux7wu-iidyv-r5cth-tz6n5-4xryn-av37c-24lrk-ozfaq-7sjax-ohkd2-6ae"
        ],
        "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": false,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [
          ""
        ],
        "ssh_backup_access": [],
        "ecdsa_config": {
          "quadruples_to_create_in_advance": 7,
          "key_ids": [
            {
              "curve": "secp256k1",
              "name": "test_key_1"
            }
          ],
          "max_queue_size": 20,
          "signature_request_timeout_ns": null,
          "idkg_key_rotation_period_ms": 604800000
        },
        "chain_key_config": {
          "key_configs": [
            {
              "key_id": {
                "Ecdsa": {
                  "curve": "secp256k1",
                  "name": "test_key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 7,
              "max_queue_size": 20
            },
            {
              "key_id": {
                "Schnorr": {
                  "algorithm": "bip340secp256k1",
                  "name": "test_key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 7,
              "max_queue_size": 20
            }
          ],
          "signature_request_timeout_ns": 1800000000000,
          "idkg_key_rotation_period_ms": 604800000
        }
      }
    }
  ]
}
2 Likes
2

There are currently two open Subnet Management proposals for this subnet (131391 and 131392), both of which update subnet config. These proposals appear to be consistent with the published roadmap and IC-OS work that’s been taking place recently to generalize support for different signature schemes. 2fq7c is also already the test key signing subnet for Secp256k1 and Bip340Secp256K1.

The first proposal generates a Ed25519 test key, and the second one enables it (so there’s a clear order in which these proposals need to be executed). @DRE-TEAM, out of interest, can I ask why generating and enabling need to be broken into two separate stages? Presumably if voters weren’t careful about the order in which they vote, the wrong proposal could end up executing first?

1 Like
3

I’ve asked a question here about a further current proposal for this subnet.

2 Likes
4

The first proposal generates a Ed25519 test key, and the second one enables it (so there’s a clear order in which these proposals need to be executed). @DRE-TEAM, out of interest, can I ask why generating and enabling need to be broken into two separate stages? Presumably if voters weren’t careful about the order in which they vote, the wrong proposal could end up executing first?

I think it is not currently possible to make a subnet management proposal that affects two subnets. But this could be changes in the future. The proposals can be voted in any order, if disabling 2fq7c is voted in first, there will be no signing subnet until the other proposal is voted in. If enabling fuqsr is voted in first, the signature requests are still going to be routed to 2fq7c until the other proposal is voted in. The advantage of the latter is that there will be no downtime for signing.

2 Likes
5

Thanks @andrea. In the case of the 131391 and 131392 proposals, the actions are generating a key and then enabling that key for signing (rather than disabling one subnet for signing and enabling another). Is it possible to enable a key for signing before it’s been generated?

1 Like
6

For reference regarding Proposal: 131449 - ICP Dashboard (internetcomputer.org)

1 Like
7

Ah, my bad. I confused the proposal numbers. What I was referring to was about 131449 and 131450.

Is it possible to enable a key for signing before it’s been generated?

No that’s not possible AFAIK. So if approved in the wrong order, one proposal would fail.

2 Likes
8

Thanks @andrea. Do you know if there are plans to make this more robust? At the moment it seems it depends on a voter with overwhelming VP accepting the proposals in the correct order.

1 Like
9

I have heard discussions about making one proposal dependent on another, so even if the one is passed first, it won’t be executed until another is completed successfully. But that was just coffee talk. I don’t think anyone has made a proposal to the community or that any team has reserved time to make it happen. I could be wrong though!

2 Likes
10

Thanks @bitdivine! @andrea, what would you think about handling these types of proposals one by one in the future (proposing a contingent one only after the other one has executed)? If it becomes a pain point, then maybe a proper solution could be fast-tracked? Otherwise it becomes a gap in functionality that’s probably too easy to ignore (just thinking out loud)

1 Like
11

Do you know if there are plans to make this more robust?

I don’t see why they couldn’t be part of the same proposal tbh, apart maybe being easier to test. But yes, I agree that we should be a bit more careful and submit them one at the time. I think this was on oversight from us.

2 Likes
12

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

1 Like
13

I just submitted a proposal to replace an unhealthy node and optimize subnet a bit:

4 Likes
14

Voted to reject proposal 133079.

This proposal is intended to replace a dead node, b7ldm. However, this node appears as “Status: Active” on the dashboard), and “status: UP” using the decentralization tool. Presumably its health has recovered or it may have been incorrectly identified as needing replacement.

2 Likes
15

Proposal 133079

I’ve voted to adopt :+1:

1 removed node replaced with a node in Costa Rica. Although the node that’s being removed happens to currently be ‘up’, it’s not been looking too healthy. Replacing it seems sensible.

image
image1173×427 30.4 KB

Additionally this proposal improves decentralisation in terms of average geographic distance between nodes, as well as max nodes-per-country (goes down to 1 instead of 2).

Decentralisation Stats

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

Smallest Distance Average Distance Largest Distance
EXISTING 472.378 km 8608.713 km 16262.926 km
PROPOSED 472.378 km 8901.492 km (+3.4%) 18505.029 km (+13.8%)

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
EXISTING 5 12 13 13 13
PROPOSED 5 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 4 2 1 1 1
PROPOSED 4 1 (-50%) 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
image922×406 75.5 KB

Table
Continent Country Data Center Owner Node Provider Node Status
--- Americas United States of America (the) Tampa (tp1) Flexential Rishi Sachdev b7ldm-xgdir-7eraz-sws5m-tzstj-clkrl-hs444-ty5nj-qnkrx-nofhs-hae UP
+++ Americas Costa Rica San José 1 (cr1) Navegalo GeoNodes LLC aqbno-vejst-3kuee-ksrrr-bo5p3-6nhht-z2coe-dg6he-ptywi-pzubm-bqe UNASSIGNED
Oceania Australia Queensland 1 (sc1) NEXTDC ANYPOINT PTY LTD 6wnv3-oxkmg-rtcgq-slqsn-5xlwu-7a27t-524pa-st7b3-epsck-tixsa-uqe UP
Europe Belgium Antwerp (an1) Datacenter United Allusion jq33i-hlo5d-hyou6-wsgu4-vi7o6-upgg3-pzawk-les4l-gn3fg-eplfx-eae UP
Americas Canada Toronto (to1) Cyxtera Blockchain Development Labs 33aap-jupxw-h3tb3-nohh2-dphn4-z6mfh-22pqt-if4yr-dmkd4-ekp7q-wae UP
Europe Switzerland Zurich 5 (zh5) Green.ch Sygnum Bank uznxh-cff3i-uso5i-u27p7-ardz7-4vihf-vkme6-i76b5-oejzx-2xewb-lqe UP
Asia China HongKong 4 (hk4) hkntt Web3game jux3z-ivwyz-ury64-jth4b-rrbfi-sx5af-ci72l-j4ot3-nl5jk-z4ilu-6qe UP
Asia India Panvel 2 (pl2) Yotta Krishna Enterprises fh6lp-xtfi2-7aa22-dsx64-hs42f-hc2a2-wfqsu-5rvnk-7wcf7-yu6cm-kae UP
Asia Japan Tokyo (ty1) Equinix Starbase asad5-qg3gv-p5hrf-7liwa-zkoia-t2imf-sztmb-okb3k-gc6ei-xzp77-5qe UP
Asia Singapore Singapore 2 (sg2) Telin OneSixtyTwo Digital Capital ux7wu-iidyv-r5cth-tz6n5-4xryn-av37c-24lrk-ozfaq-7sjax-ohkd2-6ae UP
Europe Slovenia Maribor (mb1) Posita.si Fractal Labs AG n74se-c345d-2jd4b-leuu6-jyvim-vcllk-aahj2-vjpvn-pbpks-xtgy2-4qe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA ptzzn-jphjl-476ql-lgyrk-37oa6-zxhat-ynn4f-fm2ry-r3cmf-lx7e6-uae UP
Americas United States of America (the) Sterling (st1) CyrusOne MI Servers buqsd-72zlu-hbgr2-hzjnr-mgvyj-6ldtg-2hdsd-igtpb-q7p2l-4j43v-5ae UP
Africa South Africa Gauteng 3 (jb3) Xneelo Wolkboer (Pty) Ltd jys4w-lodfn-h5325-xters-z3hf2-v7imc-ow7dh-py22m-epjvt-aldwt-oqe 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)

2 Likes
16

Although I’ve already cast a “reject” vote, I would now endorse a vote to adopt, given the information from the Node Provider Rewards tool showing a high failure rate for this node, as shown graphically in @Lorimer 's reply above. I wasn’t aware of this tool until @sat mentioned it in another thread, and it does indeed show some very helpful metrics.

3 Likes
17

Voted to adopt proposal 133079.

The proposal replaces the unhealthy node b7ldm in subnet 2fq7c with node aqbno.

Although the node has an Active status on the dashboard,using the Node Provider Rewards tool on this node shows that the node is not operating very well.

Also using the Dre tool, this replacement will also increase the Nakamoto Coefficient of the country metric, reducing the number of nodes in the US from 2 to 1.

3 Likes
18

Voted to adopt proposal 133079. Motivation and Node details are correct including the improved decentralization.

1 Like
19

Proposal #134383 to enable the HTTPS outcalls feature is live.

1 Like
20

Voted to adopt proposal #134383.

image
image914×569 14.6 KB

The proposal is set to enable the HTTPS outcalls feature by setting http_request to true, as we can see it is currently disabled.