NiDKG Performance Improvements

Developers
1

TL;DR: DFINITY is happy to announce significant latency reductions of the protocol used to create and recover subnets (cloud engines), and proposes small configuration changes for two subnets.

Background

ICP subnets make use of a non-interactive distributed key generation protocol to generate key material for themselves and other subnets. This allows nodes of one subnet to generate a master key which is securely secret-shared among nodes of a different subnet without ever fully revealing it to anyone.

This is especially relevant during subnet creation and recovery, where this protocol is used to perform the initial bootstrapping of the new or recovered subnet’s key.

Improvements

Previously, the NiDKG protocol could only be started and completed at a subnet’s DKG interval boundaries (i.e. every 500 blocks). Consequently, this implied a worst case latency of up to two intervals (~8 minutes) before a subnet creation/recovery may be completed.

Over the last couple of weeks, the community adopted changes to the replica code (cf. d9008a, 3af058), allowing this protocol to run without being constraint by interval boundaries. This in turn reduces the latency of subnet and cloud engine creations down to the order of seconds, with the goal of enabling fast, on-demand provisioning.

Proposed Configuration Changes

As part of the NiDKG protocol, nodes include cryptographic dealings in consensus block payloads. The key generation is completed once enough dealings are collected on the block chain this way. Currently, the number of dealings per block is limited to 1 on all subnets. In order to reduce the latency of subnet and cloud engine creations even further, DFINITY proposes to:

  1. Increase the number of dealings per block on subnet fuqsr to 5 (Proposal 141775).
  2. Similarly increase the number of dealings per block on subnet uzr34, once testing with the new configuration on fuqsr has completed.
2

Thanks for the announcement, sounds like a positive upgrade.

Would this be achieved by reducing dkg_interval_length?

3

The proposal has been submitted: Network Nervous System
This increases the number of dealings per block by setting the dkg_dealings_per_block parameter to 5.

4

Is there are reason that all subnets can’t have the number of dealings per block set to 5 instead of 1?

Previously the IC has run into issues due to unnecessary inconsistencies between subnet config (making testing harder and/or less representative under specific scenarios).

5

Presumably this will make consensus artifacts heavier, which would slow down the finalisation rate particularly on larger subnets?

Given that fuqsr is the test backup key subnet the proposal sounds good. Will be interesting to see how the various metrics are affected once this executes.

Personally I really think there should be a designated test subnet (that users wouldn’t accidentally find their production canisters on) so that the community can observe these sorts of things before production deployments, rather than this being a privilege just for those within DFINITY (who have local access to the necessary testing infrastructure).

fuqsr is one of the get_default_subnets so will contain arbitrary production canisters

6

We could indeed make the same change to all subnets. However, after successful testing on fuqsr, most subnet & cloud engine creations should be handled by uzr34 due to the added security of it being a large system subnet. Therefore, there is no real benefit of speeding up subnet creations on other subnets as well.

Increasing the number of dealings per block will make some blocks at the beginning of the interval a bit heavier, but this should not have a significant effect. In turn, it will also make blocks later on in the interval a bit lighter.

7

Update: The testing period on fuqsr has concluded. Multiple cloud engines were created successfully, with the remote DKG protocol typically completing in less than 10 seconds.

As announced above, DFINITY now proposes to transition the responsibility of subnet and cloud engine creations to the larger system subnet uzr34.

This transition begins by increasing the number of dealings per block on subnet uzr34 to 5, as previously tested on fuqsr. A proposal to update the subnet’s configuration accordingly has been submitted here: Network Nervous System.

8

Proposal 142253 Review | aligatorr - CO.DELTA △

VOTE: YES

TLDR: dkg_dealings_per_block increased from 1 → 5

Current config

{
      "key": "subnet_record_uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe",
      "version": 59145,
      "value": {
        "membership": [
          "rukdg-aswl7-rj4ll-qpnza-vhmtw-qooxv-zf5kk-zhvnu-o5bxa-ftekj-dae",
          "kgo2t-vidyw-yw2g5-pqwrt-nr227-rbq2o-pog27-zarc2-dfrlw-vvjge-4qe",
          "mhs2c-5e3dp-kbnsk-uhnuq-rvrnh-l4pht-a4dvg-a32bm-do25r-jy7xv-kqe",
          "c5w2g-uilsl-icq36-vonoi-4k42z-hiutx-4wdrr-3u5mq-pvb42-j5om6-zae",
          "rjalf-ppjgo-d2dt7-u2dia-2ygna-ufawa-2v6ul-dsmke-lqeow-grno7-rae",
          "x34do-riu6i-7pn3y-5pl7d-zs532-xduns-xaadp-4e34h-casgh-qywuj-7ae",
          "s4nii-ep5vi-2fps5-3gs6i-3twfu-pbreo-kalps-k26wy-ivkau-5u2qf-uqe",
          "lm2xj-taqth-26gdl-2jdjh-gkmwx-souof-xhx6x-bqooh-rz53c-3smdz-kqe",
          "zdblq-fbhrm-xnuf6-gohq4-g3y3m-mk3mm-hnkbr-5e7gw-lv6qj-vjsyc-jae",
          "q3ums-xaeuo-t73ww-ojrns-lcpa4-2hf37-re7ho-zjspe-zrggb-2el6z-jae",
          "tpz2t-27cno-fbljl-lczc6-qjxrc-6fiby-naauq-3o6q3-fsxdf-yqg2v-yae",
          "74qsa-j6jno-nmxmb-7jpf5-u6nig-g7hgo-thvjm-6f6zu-c2ugp-krple-qae",
          "lilkb-wf7hu-iv6gp-gbbv6-f6bpj-amtp5-v2jyi-3s7jw-6dysi-yzm4g-hae",
          "7m3y7-s24j3-i5oji-6h64r-2ah6w-2z236-rh7ro-b3plo-rrdwn-xwhc2-aqe",
          "3hibk-2fnod-r7pab-hb3im-blyqv-lyvdx-v273s-psxjn-yfsue-iakax-yae",
          "j4et3-lkqhr-32t4q-3o57n-nm7u3-hvgsd-7v574-3z7mj-eyks5-twtxo-zae",
          "km5ur-yacty-d2nvm-sitx7-zvnw4-bdjuf-lm3qv-vtftj-fv4vz-3d5y7-kae",
          "qlvmn-xucv5-o6qp6-nmhaa-mfm2g-x42bb-6sisq-wrytb-wpxkm-fser2-dqe",
          "3jol6-6a6dv-ysedb-5qlxc-baclw-ub23p-d324m-7sfus-bkbnk-jlh6b-jqe",
          "g4avo-ecrmg-ki3ol-dxah7-zksar-suefa-26fco-fudva-ajioq-xvhmq-4ae",
          "fhg3q-muslh-pp7ur-hcivl-q3kof-mju7a-kjyyf-hjifg-nsa35-nqjv3-7qe",
          "kwryq-ezysk-c4ono-aet7a-hh6h5-4o3bb-a33et-ef4g5-42tot-zaek6-fae",
          "ecxbl-3dp33-mpskv-yvs6f-674ct-tpr4d-dhzdg-jfgf4-gzhny-n6zzx-lqe",
          "rfkza-27bii-6jan4-u4zll-lkvmz-snmao-irmlj-arpdd-kyxrg-xnq3a-7ae",
          "q3vac-kcwo2-ruiht-nflb7-ifoev-vkjcw-quybi-ugvgn-pqfwp-jntxi-dqe",
          "dyycg-wc45f-jwks2-abddo-m3n5r-o5kxy-g5xhm-7ve4u-3tlk7-i7xec-oae",
          "67t6p-i4h3c-msv6p-kmbmm-rr6gj-z3nix-d6lo2-mq3q4-3h6rb-lwkbc-lae",
          "zjiki-pzvnv-m4rnn-fodt3-poon4-uldx7-d3wkq-gptsu-g2mjs-boi35-3qe",
          "aajth-ndp7x-ro5ok-yikyd-4i7xn-5k5ki-e3d37-hh4gn-s4opz-bnzxf-4qe",
          "qp3lh-25yxy-dlk4t-ay73d-frr4t-3kmi5-35kqg-3vvbq-26qhh-6xrdr-oqe",
          "6adxp-p7u63-xsdtk-lo6oc-vpqmi-44hgt-yv652-cbm5p-mssge-wsrz6-oqe",
          "w4ri3-ytfnq-jg3z3-qseka-se4xe-b2fl2-km766-ruzwd-riw72-6bifs-4ae",
          "go5zz-xs6yg-mylwl-v7uob-7bg4b-wjzhe-vmrwe-uy7mz-ckaz2-idm33-rqe",
          "mpahq-sgzev-nifu4-uhshl-5kybe-j6cur-q7cii-2vzkb-epkyz-zqawc-nqe"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 3670016,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 3000,
        "initial_notary_delay_millis": 300,
        "replica_version_id": "6c2b4d16024482f6e9ff794652ab506e603aacc9",
        "dkg_interval_length": 499,
        "dkg_dealings_per_block": 1,
        "start_as_nns": false,
        "subnet_type": "system",
        "features": {
          "canister_sandboxing": false,
          "http_requests": true,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [
          ""
        ],
        "ssh_backup_access": [
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEVcbYyW9CASaIa8wh07Dvm5dCeh0P/YgRP9Kwr38gB5 consensus@10.31.0.141",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICsO2IEV96tOVfjoOj450TZr4MD8PauHqhcLYvrmRRue pfops@sf1-spm12",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMz75Tyjsl6gxOJz0zHIvcQcMquIm7DHBB62ReJbRkk9 op@pyr07"
        ],
        "chain_key_config": {
          "key_configs": [
            {
              "key_id": {
                "Ecdsa": {
                  "curve": "secp256k1",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 1,
              "max_queue_size": 20
            },
            {
              "key_id": {
                "Schnorr": {
                  "algorithm": "bip340secp256k1",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 1,
              "max_queue_size": 20
            },
            {
              "key_id": {
                "Schnorr": {
                  "algorithm": "ed25519",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": 1,
              "max_queue_size": 20
            },
            {
              "key_id": {
                "VetKd": {
                  "curve": "bls12_381_g2",
                  "name": "key_1"
                }
              },
              "pre_signatures_to_create_in_advance": null,
              "max_queue_size": 10
            }
          ],
          "signature_request_timeout_ns": 1800000000000,
          "idkg_key_rotation_period_ms": 1209600000,
          "max_parallel_pre_signature_transcripts_in_creation": null
        }
      }
    }
0 Warnings
1 Improvement
  • DKG dealings dkg_dealings_per_block has been increased to 5.

You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.

CO.DELTA

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

  • Look: We observe the details and context of NNS proposals.
  • Test: We test and verify the claims made by those proposals.
  • Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

9

A new proposal has been submitted, to declare the system subnet uzr34 as the default initial DKG subnet responsible for future subnet and cloud engine creations. By adopting this proposal, new subnet and cloud engine creation requests will be routed to uzr34, unless explicitly specified otherwise by the creation request.

Previously, such requests were routed to the NNS subnet by default, while cloud engine creations were tested on the smaller application subnet fuqsr. As a larger system subnet (that isn’t the NNS), uzr34 represents a suitable middle ground between these two options.