ECDSA signatures are widely used in the blockchain industry. This feature will enable Canisters to have an ECDSA public key and to sign with regard to it. The corresponding secret key is threshold-shared among the nodes of the subnet holding the Canister. This is a prerequisite for the integration of the Internet Computer with Bitcoin and Ethereum.
What you can do to help
- Ask questions
- Propose ideas
Key people involved
- 1-pager posted on the forum for review: September 10, 2021
- Community Conversation with Victor Shoup: September 16 2021
- NNS Motion Proposal (to approve design + project) submission: September 20, 202115:00 UTC
- NNS Motion Proposal (to approve design + project) expiration: September 22,2021, 15:00 UTC
- If NNS Motion Proposal passes, implementation + deploy would take months: Q4 2021.
ECDSA signatures are widely used and will be a feature of the Internet Computer. The most important use case is the integration of the Internet Computer with the Bitcoin and Ethereum blockchains. On those blockchains transactions are ECDSA signed with respect to a public key that represents the assets holder. In order to fully integrate with those external blockchains, canisters on the Internet Computer should be able to have Bitcoin or Ethereum public keys and create ECDSA signatures to authorize transactions.
It is clearly not acceptable that any node on the Internet Computer holds and thus learns a private signing key, because the trust model of the Internet Computer is defined such that up to a third of the node machines hosting a canister may be arbitrarily faulty. The solution is to have private keys secret shared among all node machines running a canister and create the signature through threshold cryptography. That is, if a threshold of the nodes participates in and completes the signing protocol correctly, the output of this protocol is a valid signature. On the other hand, a few nodes that do not meet the threshold cannot sign an unauthorized message by themselves.
The main challenges in this feature are to define and implement a secure multi-party computation protocol to realize the threshold ECDSA signature scheme and to integrate it with the Internet Computer protocol stack. Further challenges around the core protocol are the secure distributed key generation protocol as well as a secure key backup and recovery scheme for the private signing keys.
Goal: canisters and users can ask the IC to create ECDSA keys and signatures
To reach scoped status: we need an MVP spec giving assurance the goal is achievable and on which we can estimate engineering steps and effort
Draft plan: ECDSA calls will be IC Management canister calls
- Story (Execution and Bitcoin integration): write spec for ECDSA methods offered by IC Management canister, they will only be available on dedicated subnets
- Story (Execution): decide on ECDSA cycle cost and billing
- Epic (Message Routing): store ECDSA requests in an appropriate place for Consensus-ECDSA module to read them + store deterministic replicated state for ECDSA protocols
- Epic (Consensus): poll MR (Message Routing Layer, the layer between Consensus and Execution) for new and state of existing ECDSA operations
- Epic (Consensus): return responses to ECDSA requests to MR + agree on any intermediate state that is replicated across all participating nodes and return it to MR
- Epic (Consensus/P2P/Crypto?): store state that is individual to nodes and not replicated