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