The main application of chain-key signatures is to enable direct interoperability with other blockchains as part of Chain Fusion. Using chain-key signatures, canister smart contracts obtain control over cryptographic keys: They have a public key, from which a blockchain address on another blockchain like Bitcoin or Ethereum can be derived, and they can sign transactions relative to that address. One major application of chain-key signatures is creating chain-key tokens, which are twins of tokens from other blockchains that exist on ICP. Two major examples of these are ckBTC and ckETH, representations of BTC and ETH on the Internet Computer, in which a canister smart contract cryptographically controls the bitcoin and ether that backs the ckBTC and ckETH tokens 1:1. Indeed, using chain-key signatures is the strongest, most decentralized way of integrating blockchains as no additional trust assumptions besides that of the two blockchains are required. In particular, there are no additional parties that manage signature keys or their shares.
A key component of chain-key signatures is threshold cryptography. The threshold signature scheme used to implement certified communication for ICP is based on BLS signatures. While BLS signatures have distinct advantages, they are not used on many other blockchains. In order to work with other blockchains, the Internet Computer must use threshold signatures that are compatible with the digital signature schemes of those other blockchains. By far the most commonly used signature scheme (including Bitcoin and Ethereum) is the ECDSA signature scheme. Because of this, threshold ECDSA signatures have been the first ones to be supported on the IC. Subsequently, support for Schnorr signatures as used by Bitcoin has been added, enabling full use of Bitcoin features that depend on Taproot, such as Ordinals. The recently added support for EdDSA signatures unlocks integration with blockchains like Solana, TON, or Cardano.
Threshold ECDSA
Implementing a secure and efficient threshold signing protocol for ECDSA is much more challenging than for BLS signatures. While there has been a flurry of research on threshold ECDSA in recent years, none of these protocols meet the demanding requirements of the Internet Computer: they all either assume a synchronous network (meaning that the protocols will fail or become insecure if messages are unexpectedly delayed) or provide no robustness (meaning that the ability to produce signatures is completely lost if a single node should crash) or both. Neither of these assumptions are acceptable on the IC: security and liveness must hold even in an asynchronous network with many faulty nodes.
The DFINITY R&D team has designed, analyzed, and implemented a new threshold ECDSA signing protocol that works over an asynchronous network and is quite robust (it will still produce signatures if up to a third of the nodes in a subnet are crashed or corrupt) while still delivering acceptable performance. This signing protocol has been published in two research papers that describe the protocol in detail and prove the key elements of its security. The NNS DAO decided to adopt threshold ECDSA on the Internet Computer and to roll it out, such that canister smart contracts are able to have an ECDSA public key.
Threshold Schnorr and EdDSA
The Schnorr signature scheme, of which EdDSA is a variant, is more amenable to being adapted to a threshold protocol than the ECDSA signature scheme. Consequently, the threshold signing protocols for Schnorr and EdDSA implemented in ICP are simplified variants of the ECDSA signing protocol, and inherit the property of robustness in an asynchronous network.