Author: icp league
On September 15, 2021, the Internet computer governance system NNSProposition 20586Through the adoption, the DFINITY Foundation will continue to develop the cryptography part, allowing the Internet computer network to directly integrate with the BTC network. This integration allows the software containers (Canisters) of Internet computers to directly hold and send the BTC of the Bitcoin main network, and also brings smart contracts to the Bitcoin network.
first level title
▍What is direct integration
Let Canister receive and hold Bitcoin directly on the Bitcoin network;
Let Canisters trace and query their own UTXO in the Bitcoin network;
Canisters can create Bitcoin transactions, accept Bitcoin transactions from other Canisters, and forward transactions to the Bitcoin network.
After Canisters can hold Bitcoin directly, because Canisters are Turing complete, they can write business and decide when to trade with other Bitcoin users, including Bitcoin transactions with other Canisters using the Bitcoin network, and the business runs on the IC in the network.
Therefore, it is possible to use the liquidity on the Bitcoin network to conduct smart contracts on Internet computers without involving any intermediaries and bridges.
first level title
▍Threshold ECDSA signature required
ECDSA signatures are widely used in Bitcoin and Ethereum networks, so Canisters on Internet computers should be able to have Bitcoin or Ethereum public keys and create ECDSA signatures to send transactions in other public chain networks.
Obviously, the key corresponding to the Bitcoin public key should not be stored in the container state. Even if Canister can set pirvate to encapsulate data, the key may still be exposed to all nodes. Because the state in Canister will be shared among the nodes of the subnet, like all blockchains, under the trust model of Internet computers, there may be malicious nodes, and malicious nodes may obtain signature keys through attacks to steal assets.
first level title
▍Risks and challenges
The main challenge here is to define and implement a secure multi-party computation protocol for a threshold ECDSA signature scheme and integrate it with the Internet Computer Protocol.
Further challenges surrounding the threshold ECDSA signature protocol are secure distributed key generation protocols, and secure key backup and recovery schemes for private signing keys.
first level title
▍Solution
Let’s review the three requirements above:
Let Canister receive and hold Bitcoin directly on the Bitcoin network;
Let Canisters trace and query their own UTXO in the Bitcoin network;
Canisters can create Bitcoin transactions, accept Bitcoin transactions from other Canisters, and forward transactions to the Bitcoin network.
For function (1), Canisters need to have a threshold ECDSA public key from which their Bitcoin address is derived.
For function (2), Bitcoin blocks need to be extracted to an Internet computer to verify and track the Bitcoin blockchain. Once there is sufficient work in subsequent blocks on the blockchain, the transaction and its UTXO can be extracted and made available to Canisters upon request;
For function (3), the Internet computer must establish an outbound communication channel (outbound communication channel), based on which outbound transactions from the Bitcoin smart contract container can be reliably sent to the Bitcoin network.
Threshold ECDSA is functionally completely separated from Bitcoin, built on IC as a separate function, through which Canisters obtain public keys and APIs for signing transactions, allowing smart contracts that support Bitcoin.
first level title
▍How to check the status of Bitcoin network
Internet computers will introduce blocks from other networks and verify that they are correct (format, difficulty, etc.), and process transactions after a certain number of confirmations to ensure finality. Security depends onInternet computer and bitcoin networknormal functioning, and not other factors. The state of Bitcoin is primarily used to track the current balance of each Canister that holds Bitcoin.
However, the nodes of Bitcoin and Ethereum will not be run on the copy, and only special adapters will be configured on the copy to obtain blocks from the Bitcoin and Ethereum P2P networks. The adapter will be under the same consensus as its main network, so the replicas will have the same state, and the system will maintain the desired security properties.
The relay between the Internet computer and the Bitcoin network is implemented on the IC node in a decentralized manner as much as possible: each node in the IC subnet that supports Bitcoin integration will be randomly connected to the Bitcoin A group of nodes of the currency network. This approach also allows for the rapid distribution of transactions to multiple nodes of the Bitcoin network in a highly decentralized manner.
Regarding related security concerns, DFINITY plans to sandbox code that performs dangerous tasks, such as parsing untrusted content in a highly restricted sandbox, so that even if someone responds by serving a malicious network (for example, we connect to The attacker's Bitcoin node) successfully launched a remote code execution attack, and they were unable to break out of the sandbox to cause any actual harm.
first level title
▍After integrating Bitcoin
The adapter network architecture mentioned above is built in a very general way.All of these functions are provided by a single, unified architecture that is part of the IC protocol stack.So besides Bitcoin integration, it can be used for several purposes:
Another key use here is future Ethereum integration;
Allows the container to make http calls or make arbitrary network connections.
The different protocols (BTC, ETH, http, TCP…) will share most of the architectural components, e.g. at the network level, and each protocol receives its own protocol adapter. This way, we can keep the architecture highly modular yet powerful, with as little coupling to the IC protocol as possible.
The current plan is to do a Bitcoin integration first, followed by an Ethereum integration. We introduce specific code for these blockchains, such as dedicated adapters to connect to Bitcoin or Ethereum P2P networks. Support will only be added for these two blockchains at the moment. If the integration is a huge success and the community asks to integrate Litecoin, Dogecoin and other networks, we can of course vote on it.
Integration with Bitcoin will lay the groundwork for the ability to make external HTTP calls, DFINITY mayfirst level title。
secondary title
Update September 15:
secondary title
Update September 22:
Updated October 4th
Implementation of Threshold ECDSA functionality: A good portion of the "base" has been implemented such as data types, threshold ECDSA artifacts for the artifact pool, for creating and validating transactions, etc. So far, the above implementations have all been carried out in a simulated state. Some cryptographic primitives have been implemented in parallel, but so far have not been integrated with consensus.
secondary title
Update October 19:
secondary title
Update October 31:
After setting the November 20th milestone, we realized that the feature will likely only be finally released next year. It's hard to give a good estimate right now, the plan will be in the first quarter.
secondary title
Update November 4th:
A final decision on key management for threshold ECDSA is still up for debate;
All Canister keys on a single subnet will come from this one master key;
When the same master key is deployed on different subnets, the security of this key will depend on the security weaknesses of the subnet where the key is deployed. This means we need to use a sufficiently secure subnet to host a given master key;
secondary title
Update November 6:
The community suggested that the official provide an option for Canister to choose whether he wants to use the Bitcoin mainnet or test. This makes it easier to test container code without executing transactions on the Bitcoin mainnet.
Threshold ECDSA functionality is likely to carry over to 2022, which would also delay the rollout of Bitcoin integration. The community suggested that if Bitcoin functions are completed ahead of schedule, we should allow them to access Bitcoin functions without a threshold ECDSA, and simulate ECDSA function development during implementation, which will help shorten the rollout time of Bitcoin-related functions.
secondary title
Update November 12:
Threshold ECDSA: The cryptographic and consensus mechanism engineering teams are currently working on the first integration between the consensus mechanism and ECDSA signatures, a major milestone where we will verify the minimum four-node subnetwork required for a threshold ECDSA signature. We've set a deadline for this milestone, which is next weekend. We've made good progress so far.
Protocol Integration of Bitcoin Adapter with Bitcoin System Components: The engineering team made significant progress this week, with the protocol between the Bitcoin Adapter at the network layer and the Bitcoin System Component at the execution layer starting to work. That is, Bitcoin system components can fetch blocks from the adapter, the adapter matches the request with its prefetched blocks, and if there is a match, provides a new Bitcoin block, which is processed by the system component. A block request from a Bitcoin system component includes all block hashes in the view of the Bitcoin blockchain that the system component has. The adapter responds with a bitcoin block in case its block matches the system component's local view of the block "on top". This protocol-level integration is done through a single adapter that connects "directly" to Bitcoin system components, rather than through the IC stack. This means that core parts of Bitcoin-related functionality are now working in these two main components, but new communication mechanisms will continue to be developed.
secondary title
Update November 19th:
secondary title
Update on November 20th:
secondary title
Update November 26:
The integration of the consensus functions and cryptographic primitives of the pre-signed protocol has been completed, and we have also added cryptographic functions. Among them, the pre-signature is the most complex part of the most threshold ECDSA function implementation, and now we are still working end-to-end with shortcuts that still need to be "solved". For these shortcuts, we will be fully functional after the signing protocol is implemented.
To make pre-signing more concrete, we visualized the functionality through the Grafana dashboard. The details are as follows:
secondary title
text
secondary title
Update on November 29th:
Taproot and threshold Schnorr signatures may be the next step after threshold ECDSA, but no firm decisions have been made yet. When implementing Threshold Schnorr, we can fully leverage the synergies of the Threshold ECDSA work, however, we still need to define the protocol specification, including the key derivation scheme, prove its security, create a system design (exploiting the synergies), and implement it.
first level title
▍Resources
https://forum.dfinity.org/t/threshold-ecdsa-signatures/6152
https://forum.dfinity.org/t/direct-integration-with-bitcoin/6147
