Threshold ECDSA Signatures

Roadmap
160

oh damn he’s here too, calling you guys morons… can we ban him from the blockchain?

3 Likes
161

Just ignore him. Eventually, he will get tired when he gets no reaction from anyone here.

1 Like
162

Progress update

The implementation has further progressed and we think that this or next week we may be ready for a first deployment of the feature on an IC subnet. This deployment will likely not contain the Xnet re-sharing yet, but the core signing algorithm. The purpose of this first deployment is to observe the behaviour of the feature on mainnet and to get operational experience with it before we will release the feature on the NNS and a large dedicated threshold ECDSA subnet.

As of last week, the major open issues to be implemented for a first deployment have been the following:

  • Payload validation to be finished. This is a prerequisite for the protocol to be secure and we won’t release on mainnet even for any form of testing purposes before this has been done.
  • Fixing some issues with Xnet communication for signing requests. Currently, Xnet routing of signing requests and responses still has some glitches.

A further major item that we do not necessarily need for a first deployment, but that is crucial for the overall feature is the following:

  • Xnet re-sharing requires to be end-to-end tested and validated. The protocol itself is implemented (crypto and consensus), but we have not been able to end-to-end validate its correctness.

There are multiple further items that still need to be done, but we are slowly getting there.

11 Likes
163

Threshold ECDSA System Integration

As promised long time ago, I wanted to give you an overview of the system integration of threshold ECDSA and particularly how we intend to deploy the feature.

New and Updated NNS Proposals for Managing Threshold ECDSA Keys

We needed to define or extend multiple NNS proposals to realize the threshold ECDSA key management functionality required for the intended deployment scenarios.

  • do_update_subnet: Updated proposal that allows for defining that a specific subnet should generate a new threshold ECDSA key with a given key id.
  • create_subnet: Updated proposal that allows for creating a new subnet with a threshold ECDSA key being re-shared from a specified subnet (actually, multiple keys from different subnets could be re-shared to this subnet in the future, the proposal is already generalized to such scenarios). Re-sharing works by the key source subnet computing initial threshold ECDSA dealings encrypted towards the replicas of the target subnet (Phase 1 of the cryptograpihc re-sharing protocol), which are then stored in the CUP for the to-be-created subnet in the Registry. This is all orchestrated by the NNS canisters when executing the create_subnet proposal. Once the new subnet bootstraps, its replicas pick up the initial dealings from the Registry and compute their threshold ECDSA key shares from those initial dealings (Phase 2 of the cryptographic re-sharing protocol).
  • update_ecdsa_signing_subnets: New proposal for enabling / disabling the signing functionality for a subnet for a key id.
  • set_recovery_cup: New proposal for setting the recovery cup with the initial threshold ECDSA dealings of the intended key from the given subnet.
  • A proposal for deleting a given threshold ECDSA key from a subnet.

Note that key ids are pairs comprising the cryptographic group (as variant) and a key identifier (as byte array). Example: (secp256k1, prod_key_1)

Deployment Architecture

Our intended deployment architecture is as follows:

  • We initially want one production threshold ECDSA key (and probably a test key, however, this discussion is about the production key) replicated on two subnets for reasons of key availability.
  • The NNS will hold the production threshold ECDSA key passively, i.e., the NNS will not accept signing requests with this key.
  • A new 34-node subnet will hold the same production threshold ECDSA key and accept signing requests.

Provisioning Flow

Provisioning flow with abstract API calls (the used key name is an example and not defined yet):

  • do_update_subnet(subnet_id=NNS, ... , ECDSA_keys={ (secp256k1, prod_key_1) })
    • The NNS is instructed to create a new threshold ECDSA key with id (secp256k1, prod_key_1) locally.
  • do_create_subnet(nodes={X, Y, Z, ...}, ..., ECDSA_key_source={ (NNS, (secp256k1, prod_key_1) }, ...)
    • Computes ECDSA dealings for nodes X, Y, Z, ... from the existing key (secp256k1, prod_key_1) and stores them in the Registry as part of the genesis CUP (Catch Up Package) for the new subnet to be created, then creates a new 34-node subnet with nodes X, Y, Z, ..., the nodes of which pull the ECDSA dealings from the Registry and finalize the re-sharing protocol to obtain the threshold ECDSA key (secp256k1, prod_key_1) in secret-shared form.
  • update_ecdsa_signing_subnets(A, true, key_id_1)
    • Enables the new 34-node subnet to accept signing requests for the key (secp256k1, prod_key_1).

In case one of the subnets holding the threshold ECDSA key (secp256k1, prod_key_1) is destroyed such the key cannot be reconstructed from the available shares any more and thus needs recovery, we use the set_recovery_cup proposal to create a recovery CUP (Catch Up Package) with ECDSA dealings of the key from which the key shares are computed.

Further Notes

Currently, each subnet can hold a single threshold ECDSA key, future extensions may lift this constraint, e.g., once we need a key in another group or would want multiple keys in the same group. The further may happen sooner than later in order to be able to realize a decentralized CA, which would require one of the secp256r1 groups.

There will be a talk on May 24th in which we will present more details about this topic.

See the attached figure for an overview of the rollout and related key management process.

Threshold_ECDSA_System_Integration_Process
Threshold_ECDSA_System_Integration_Process1574×822 157 KB

12 Likes
164

Join Community Conversation - Threshold ECDSA - (@andrea & @dieter.sommer) on May 24, 2022: Webinar Registration - Zoom

3 Likes
165

BTW, if you want to start developing a project using the ECDSA feature today, you may want to check out this project GitHub - ninegua/ecdsa_example: An example of using the ECDSA signature feature on IC

It provides a mock implementation to allow deployment both locally and on IC. You can simply change the canister id back to aaaaa-aa after this feature is rolled out on main net.

Both Rust and Motoko examples are provided.

12 Likes
166

Update

Implementation has been progressing pretty well recently and important work items have been completed, including the following:

  • Open issues with Xnet message routing of signing requests
  • Xnet re-sharing of threshold ECDSA keys is now covered with end-to-end tests (this is a huge achievement of the engineering team)
  • Key deletion (needed during the initial testing phase to gain some operational experience with the feature on IC mainnet)
  • All required NNS proposals
  • System tests

Considering the current state of the implementation, we can expect a first deployment on IC mainnet with a test key by end of the month or in early July. We plan to perform internal testing of the API to test its stability and performance characteristics and, once we have sufficient assurance of this, we open it up for public consumption. We already have a subnet on IC mainnet reserved for this purpose.

Meanwhile, you can program against a mock API in a canister as explained here: Threshold ECDSA Signatures - #165 by PaulLiu

You will hear on this and other channels once we deploy on IC mainnet! Stay tuned!

7 Likes
167

Progress update

We are nearing completion of the feature for a Beta launch. I would assess that we are currently around 90% - 95% complete for the Chromium / Beta launch.

The plan for the release of the Bitcoin integration feature incl. t-ECDSA is as follows:

  • Chromium (Beta) release in some weeks, target is late June: functionally complete implementation
    • API for Bitcoin testnet Integration available on IC mainnet for public consumption
    • Threshold ECDSA deployment with a test key that will be deleted after a Beta phase available on IC mainnet for public consumption
    • Documentation, videos, and a sample project on how to use the feature
  • GA (general availability) release targeted at ~1-2+ months after Chromium: production-ready implementation
    • API for Bitcoin mainnet Integration available on IC mainnet for public consumption
    • Threshold ECDSA deployment with the production key that will be hosted on two large subnets on IC mainnet for public consumption
    • ckBTC canister

The Chromium (Beta) release will allow the community to build canisters based on the Bitcoin and threshold ECDSA APIs, i.e., create fully-functional integrations with Bitcoin. The GA release provides fixes towards production readiness, e.g., in the areas of performance, and enables Bitcoin mainnet and the final production threshold ECDSA key.

There are some items still to be implemented for the Chromium / Beta release for t-ECDSA, but some of those are too technical to be self explaining without the full context and are not given here. We estimate those to be doable in the coming few weeks. Examples include:

  • Performance & latency benchmarks on realistically-sized subnet
  • Turn feature on by default in the SDK
  • Supporting key id (only 1 for now in consensus)
  • Addressing some security findings from the external code review
  • Signed initial dealings (from xnet resharing)
  • ic-admin commands for re-sharing to be defined based on tests
  • Writing a documentation Web page
  • Recording tutorial videos

For the GA release, the following items are currently on the table:

  • Further benchmarking
  • Performance improvements (if necessary)
  • Further testing
  • Another code review
6 Likes
168

Thanks for the update. Will there not be a ckBTC canister available for testing in the Beta release?

1 Like
169

Indeed, the ckBTC canister is just not ready for Beta.
The actual ckBTC canister work still needs to start, the involved teams are busy with the other features currently. One engineer and one researcher are, however, currently working on a library that the ckBTC canister will use to very reliably implement the UTXO and Bitcoin transaction handling, which will be one key part of the canister.
Also, there’s a dependency on the ledger / token standard that is currently being discussed: The ckBTC canister needs to already implement this standard that is not there yet.

4 Likes
170

I know you know but sometimes reading it from someone else helps: It is urgent not to rush. The impact of being “late” will be ln(1) compared to a faulty implementation…

2 Likes
171

Update

The implementation of the feature for the Beta / Chromium release scope is nearing completion. Next to wrapping up the feature implementation, we still need to work on example code that shows how to use the feature as well as documentation. Launching the feature with a test key within 1-2 weeks can be very realistic.

13 Likes
172

Update

The feature is code complete now and we are finishing up the documentation and still need to perform some stress testing in order to make sure everything works as intended when being run on IC Mainnet as well as some benchmarking on Mainnet to get an understanding of the performance of the feature on a 13-node subnet on Mainnet.

We are very close to making the feature available for the general public with a threshold ECDSA test key to be used only for testing purposes.

13 Likes
173

Excuse me, Can you explain how threshold ECDSA works in solving the problem of on decentralized DNS and decentralized certificate authority?

1 Like
174

Thank @bjoerntm very much for your patient and detailed help in your busy schedule!

175

Threshold ECDSA Beta released! :rocket:

The threshold ECDSA Beta release, being a key part of the Bitcoin Testnet release, has been officially announced!

You can now use threshold ECDSA on the IC with a test key. Please note that the test key may be deleted at some point, so it is not advisable to store any value with this key. The test key of the current deployment is intended solely for development and testing purposes, e.g., to hold bitcoin on Bitcoin Testnet.

Documentation:

Sample dApp:

The team is now working mainly on further performance improvements and another security review as there have been quite some changes since the first one.

Have fun!

13 Likes
176

For the non-technical like me, came across this list so folks can see what the IC can easily integrate with using ECDSA.

http://ethanfast.com/top-crypto.html

5 Likes
177

Nice list, thanks for sharing! Shows there’s huge potential of this feature and a huge amount of work if we want to unleash all of that. :wink:

Update

There’s a couple of things that need to be done now to be ready for a mainnet release. The below ones are the main open areas where we will spend most of the engineering time. We can expect 2-3 months until we can release, but this is a rough indication, please do not use this as a firm release date.

Assurance
One of the big items here is to increase our assurance of correctness of the implementation. We have already done one external round of code reviews with a world-leading code audit company. We are planning to do another round when the changes that we still want to implement are complete. This will be again with a top-notch external review firm. Review reports will most likely be published. And of course we will be doing lots of testing on our own. For a feature like threshold ECDSA, which will protect large amounts of value, such efforts for quality assurance are crucial to ensure that the chance of security issues and thus the risk of value being lost is reduced to an acceptably tiny value.

Performance
In addition to these assurance-related efforts, we still need to work on improving the performance of the implementation. We are currently running the system with the test key on a 13-node subnet. For the production key, we decided to start with a 34-node subnet for the security / decentralization we want to have. This has a major implication on performance, i.e., it will be quite a bit slower there. In order to reach, what we think is an acceptable level of performance, we need to put some more thinking and engineering effort into getting good-enough performance on such larger subnet.

We will keep you posted on the progress!

B.t.w., user @flyq from our community has (against all warnings) already taken the risk to perform a Bitcoin mainnet transaction with the threshold ECDSA test key. After manually crafting a bitcoin transaction to transfer the funds his canister has received back out of the IC again, no Bitcoin was lost and this was the first successful threshold ECDSA-based Bitcoin Mainnet transaction roundtrip on the IC ever! Congratulations! :slight_smile:

The warning still applies to not attach any value to the current t-ECDSA test key. Any experiments are at your own risk if you choose to ignore this warning.

22 Likes
178

So we’re looking at around November 2022 now? This is a big change in timeline compared to what we’ve all been told so far, is the 2-3 month timeline based on a new assessment?

10 Likes
179

Do I need to enable something in the local replica to use this feature? I’m getting “No route to canister aaaaa-aa” when calling ecdsa_public_key