Chain-key Signing Performance Improvements

Developers
1

TL;DR: DFINITY is happy to announce significant throughput improvements for threshold signing, and would like to hear more about your use-cases.

Background

The Internet Computer Protocol currently implements a threshold signing service with four different schemes:

This service allows canisters to:

  • obtain their own public keys (wallet addresses),
  • compute signatures on arbitrary messages,
  • derive (encrypted) keys.

Each threshold scheme relies on a master private key, which is securely secret-shared among all nodes of a subnet such that it is never fully revealed to anyone. Two sets of master keys are currently deployed this way:

  • test_key1 on signing test subnet fuqsr (13 nodes)
  • key1 on fiduciary signing subnet pzp6e (34 nodes)

Previous Throughput Limits

Until recently, the signature throughput of the fiduciary signing subnet was limited to at most:

  • 0.5 sig/s for tECDSA
  • 1.1 sig/s for tSchnorr
  • 5 sig/s for vetKeys

While these numbers were sufficient for existing usage, they made the implementation of certain use-cases more challenging. This especially applied to DeFi applications where activity often occurs in bursts, and single transactions may result in many signature requests. For example, a single Bitcoin transaction may involve signing multiple inputs or coordinating multi-signatures approvals.

Improvements

Over the last couple months, the community adopted many different changes across multiple layers of the replica code, with the goal to improve the throughput of the IC’s threshold signing service. Among others, these changes included:

  • Implementing “hashes-in-blocks” for IDKG dealings (39c83f)
  • In-memory canister secret key store (9349c4)
  • Multi-threading for cryptographic operations (2fa6f1)
  • Moving expensive computation out of critical paths (2e94a7)
  • Many smaller optimizations in inter-process communication and cryptographic primitives

Additionally, pre-signature artifacts that are required to serve signatures requests, are now stored in the subnet’s replicated state (76a5fa). In contrast to storing these artifacts as part of consensus blocks, where space is limited, this change enables the subnet to generate significantly more pre-signatures in advance (in the order of thousands).

Creating pre-signatures is the main performance bottleneck of the threshold signing protocol. Therefore, generating more of them in advance during times of lower load, allows the subnet to be better prepared when handling large bursts of signature requests.

New Throughput Limits

Thanks to these changes, the sustained throughput limit of subnets with a configuration optimized for high signature load has increased by a factor of 10x and more. This improvement applies to an ongoing stream of signature requests when no pre-signatures are available.

While there are pre-signatures available, such a subnet can additionally handle load spikes in excess of 100 signatures per second (maximum throughput), until all available pre-signatures are consumed.

As usual, these limits apply per subnet, meaning they may be scaled horizontally by adding more signing subnets.

480Ă—480 16.5 KB

Fig 1. Signature throughput before improvements (first bar), sustained signature throughput after improvements (second bar), maximum burst throughput after improvements (third bar), for all schemes. There is no third bar for VetKeys, as it doesn’t use pre-signatures.

Changes to Mainnet Parameters

As a consequence of the new limits, the community adopted proposal 140289, which represents a conservative parameter increase for the fiduciary signing subnet pzp6e. By increasing the number of pre-signatures to be created in advance from 5 to 100, canisters may expect to see an improved maximum signature throughput of around:

  • 3.5 sig/s for tECDSA,
  • 6.5 sig/s for tSchnorr,
  • 18 sig/s for vetKeys.

Next Steps

DFINITY will continue to monitor the usage and throughput of the signing service, and propose further parameter increases as demand rises and new use-cases appear. If necessary, these parameter changes could bring the subnet even closer to the new maximum throughput limits summarized in the graphic above.

Finally, if your application is expected to require a signature throughput that is higher than currently configured, please feel welcomed to use this thread as a platform to describe your use-case, which may then serve as a basis for further parameter increases.

16 Likes
2

Compounding UTXOS.

ELI5 How to compound UTXOS well.

ELI5 limitations/strengths of ICP threshold key sig. :smiling_face_with_sunglasses: .

3

This is great news! Well done everyone, thank you for this was much needed!

1 Like
4

Will the price of threshold signature increase due to mission70?

5

This is currently not in scope for Mission 70. Although future revisions cannot be entirely excluded, current utilization levels suggest that any impact on inflation would be minimal. So I would not expect this to be a priority.

Separate from Mission 70, we are assessing the resource utilization of the various threshold signing protocols. This could result in proposals to differentiate costs in line with measured resource usage, to ensure a fair and proportionate allocation of costs. However, this is very much work in progress.

1 Like
6

If there is an future price changes depending on usage, would really appreciate it if we can have an idea before hand to plan and to inform people testing and who will be using our infra primarily because we are using both signing services for a lot of things. The plan is to get as much builders in a lot of ecosystems to use it.

7

Queue size definition changes

The registry’s chain-key config contains a max_queue_size parameter for each key deployed on a subnet. This field is currently set to:

  • 20, for key ecdsa:secp256k1:key_1,
  • 30, for key schnorr:bip340secp256k1:key_1,
  • 30, for key schnorr:ed25519:key_1.

Until recently, this queue size determined the maximum number of concurrent requests accepted by the subnet. Additional requests exceeding this queue size were rejected.

As of commit 627635 (adopted for all subnets), the maximum number of concurrent requests instead increases dynamically with the number of available pre-signatures (up to a current maximum of 100).

This means, if enough pre-signatures are available, up to 100 requests will be handled by the subnet concurrently. If no pre-signatures are available, the signature requests will instead enter the request queue, which will grow up to the maximum length configured by the registry, until new pre-signatures are produced (as before).

Subnets can now store significantly more pre-signatures thanks to the improvements described in the original post. Therefore, a dynamic request queue allows canisters to consume these pre-signatures at a higher rate than before. This is beneficial when processing larger throughput spikes.

6 Likes