What is the Direct Integration of Internet Computer and Bitcoin Network？

On September 15, 2021, Proposal №20586 of the Internet Computer governance system, NNS, was passed. DFINITY foundation will continue to research the cryptography part to directly integrate the Internet Computer network with the BTC network. This integration allows the software container of Internet Computer (Canisters) to directly hold and send the BTC of the Bitcoin main net, and also bring smart contracts to the Bitcoin network.

Threshold ECDSA Signatures

Direct Integration with Bitcoin

More importantly, the cryptography innovation of Internet Computer creates signatures for contracts without the need for private keys. Therefore, in addition to bringing the smart-contract capability to the bitcoin main net, it is also the basis for the Canisters of Internet Computer to interact directly with the Ethereum main net. Instead of relying on the highly centralized asset bridge, it will rely on the network consensus of IC to realize the end-to-end integration of direct multi-chain nodes.

What is Direct Integration?

• Let Canisters receive and hold bitcoin directly on the bitcoin network;
• Let Canisters trace and query their own UTXO in Bitcoin network;
• Let Canisters create bitcoin transactions, accept bitcoin transactions in other Canisters, and forward the transactions to the bitcoin network.

After canisters can directly hold Bitcoin, because Canisters is Turing-Complete, they can design services to decide when to trade with other bitcoin users, including bitcoin transactions with other Canisters using Bitcoin network, and the services run in IC network. Therefore, the liquidity on the Bitcoin network can be used to make smart contracts on Internet Computer without involving any intermediaries and bridges. After completing the direct integration of Bitcoin, the next step will be to try to enable the Canisters to hold ETH, let the Canisters send the transaction of Ethereum main net, and let the canisters of IC interact with the smart contract of Ethereum main net.

ECDSA Signature is Required

ECDSA signature is widely used in Bitcoin and Ethereum networks. Therefore, canisters on Internet Computer should be able to own Bitcoin or Ethereum public keys and create ECDSA signatures before sending transactions in other public chain networks. Obviously, the key corresponding to the Bitcoin public key should not be saved in the state of Canister. Even if Canisters can set Private to encapsulate data, the key may still be exposed in front of all nodes. Because the internal state of Canisters will be shared among the nodes of subnets, like all blockchains, there may be malicious nodes under the trust model of Internet Computer, and the malicious nodes may get the signature key through attacks to steal assets. To do this, the first is to complete the threshold ECDSA signature, that is, share the private key among all nodes in the subnet where Canisters are running, and create the signature through threshold encryption, which is if the threshold of the node participates in and completes the signature protocol correctly, the output of the protocol is a valid signature. On the other hand, some nodes that do not meet the threshold cannot sign unauthorized information by themselves, which is the prerequisite for the integration of Internet Computer with Bitcoin and Ethereum.

Risks and Challenges

The main challenge here is to define and implement a secure multi-party computing protocol to implement the threshold ECDSA signature scheme and integrate it with the Internet Computer protocol. The further challenges around the threshold ECDSA signature protocol are the secure distributed key generation protocol and the secure key backup and recovery scheme for private signature keys. At the same time, the subnet cannot tolerate more than 1/3 of malicious nodes. The threshold ECDSA function is also based on the assumption that if there are too many collusive malicious parties in the subnet, they can create signatures on behalf of the Canister without the approval of the Canister.

Solutions

Let’s have a review of the above three requirements:

• Let Canisters receive and hold Bitcoin directly on the Bitcoin network;
• Let Canisters trace and query their own UTXO in the Bitcoin network;
• Let Canisterscreate Bitcoin transactions, accept Bitcoin transactions in other canisters, and forward the transactions to the bitcoin network.

For function (1), Canisters need to have a threshold ECDSA public key, and its bitcoin address is derived based on this;

For function (2), bitcoin blocks need to be extracted into the Internet Computer to verify and track the bitcoin blockchain. Once there is enough workload in the subsequent blocks on the blockchain, the transaction and its UTXO can be extracted and provided to Canisters as required;

For function (3), the Internet computer must establish an outbound communication channel. Based on this, the outbound transaction from the Bitcoin smart contract container can be reliably sent to the Bitcoin network.

Threshold ECDSA is completely separated from Bitcoin in function. It is built on the IC as a separate function. Canisters obtain the public key and sign the transaction API through it, so as to allow the smart contract supporting Bitcoin.

In terms of the usability of IC network, according to the current plan, all API calls using the Bitcoin network are asynchronous. It is worth noting that the asynchronous call is very fast under this setting because the transaction sending Bitcoin functionally runs in the same subnet as the Canisters, and there is no cross-subnet delay.

How to Check Bitcoin Network Status?

Internet Computer will introduce blocks of other networks and verify whether they are correct (format, difficulty, etc.), and process transactions after obtaining a certain amount of confirmation to ensure finality. Since the replica on the Internet Computer is directly introduced into the block from the Bitcoin network, the security depends on the normal operation of the Internet Computer and the Bitcoin network, not other factors. The status of bitcoin is mainly used to track the current balance of each Canister with bitcoin.

However, Bitcoin and Ethereum nodes will not run on the replica, and only special adapters will be configured on the replica to obtain blocks from Bitcoin and Ethereum P2P networks. The adapter will be in the same consensus with its primary network, so the replica will have the same state, and the system can maintain the desired security properties.

The relay between the Internet Computer and the Bitcoin network is realized on the IC node in a decentralized way as far as possible: each node in the IC subnet supporting Bitcoin integration will be randomly connected to a group of nodes of the Bitcoin network. This approach also allows rapid decentralized transactions to multiple nodes of the bitcoin network in a highly decentralized way. With regard to related security issues, DFINITY plans to sandbox the code performing dangerous tasks, such as analyzing untrusted content in a highly restricted sandbox, so that even if someone successfully launches a remote code execution attack by providing an malicious network response (for example, we are connected to the attacker’s Bitcoin node), they cannot break through the sandbox. In this way, no actual damage will be caused. The finality of Bitcoin is explained in the API of the adapter’s get_UTXO_set. For the Bitcoin address returned by the API, the total amount confirmed in the UTXO set can be used as the metadata of UTXO, and the finality of Bitcoin will be further abstracted as the balance under the account model.

After Bitcoin Integration

The network architecture of the adapter mentioned above is built in a very general way. All these functions are provided with a single and unified architecture, which is part of the IC protocol stack. Therefore, in addition to bitcoin integration, it can also be used for a variety of purposes:

• Another key use here is Ethereum integration in the future;
• Allow the container to make http calls or any network connections.

Different protocols (BTC, ETH, http, TCP…) will share most of the architecture components, for example, at the network level, and each protocol receives its own protocol adapter. In this way, we can keep the architecture highly modular but with powerful functions, and the coupling with IC protocol as small as possible.

The current plan is to carry out Bitcoin integration first and then Ethereum integration. We will introduce specific codes for these blockchains, such as dedicated adapters connecting Bitcoin or Ethereum P2P networks. At present, only support for these two blockchains will be increased. If the integration is a great success and the community requires the integration of Litecoin, Dogecoin, and other networks, we can certainly vote for them. Integration with bitcoin will lay the foundation for realizing the function of external HTTP calls. DFINITY may start the development of this part next year.

Latest Progress

Updated on September 15:

• In the research paper on encryption protocol, an internal security review is also required before the results can be released to the community.

Updated on September 22:

• ECDSA community conversations, click Back: https://www.youtube.com/watch?v=MulbKPwv6_s

Updated on October 04:

• Implementation of threshold ECDSA function: a good part of the “foundation” has been realized, such as data type, threshold ECDSA artifacts of artifact pool, which are used to create and verify transactions, etc. So far, the above implementation has been carried out in the simulation state. Some encryption primitives have been implemented in parallel, but so far they have not been integrated with consensus.
• The next major milestone is to achieve the consensus of the smallest subnet (4 nodes) and the integration of ECDSA encryption around November 20.

Updated on October 19:

• Excellent progress has been made in the functional implementation of Bitcoin network adapter and Bitcoin system components. For example, Bitcoin system components can already build UTXO sets from bitcoin blocks and handle bifurcation well.

Updated on October 31:

• After setting the milestone on November 20, we realized that the feature is likely to be finally released only next year. It is difficult to give a good estimate now. It is planned to be released in the first quarter.
• Yesterday, we held the first “Bitcoin Community Developer Workshop”. Core developers from DFINITY are researching on the integration of threshold ECDSA and Bitcoin.

Updated on November 4:

• The final decision on key management of threshold ECDSA remains to be discussed;
• The keys of all Canisters on a single subnet will come from this master key;
• When the same master key is deployed on different subnets, the security of the key will depend on the shortcomings of the subnet security where the key is deployed. This means that we need to use a sufficiently secure subnet to carry the given master key;
• The current strategy is to deploy the master key on multiple subnets to ensure that we have a backup.

Updated on November 6:

• The community suggested that the official provide an option to let Canisters choose whether to use Bitcoin main network or test network. This makes it easier to test the Container code without performing transactions on the bitcoin main network.
• The threshold ECDSA function is likely to continue until 2022, which will also delay the launch of Bitcoin integration function. The community suggests that if the bitcoin function is completed in advance, we should let them access the Bitcoin function without threshold ECDSA, and simulate the development of ECDSA function during implementation, which will help to shorten the launch time of Bitcoin-related functions.
• EVM on Internet computers: the community emphasizes the importance of being able to run EVM code on IC, so that the smart contract written in solidity can run on IC without re-implementation.

Updated on November 12:

• Threshold ECDSA: The engineering team of encryption and consensus mechanism is stepping up the first integration between consensus mechanism and ECDSA signature, which is a major milestone. We will verify the minimum four-node subnet required for a threshold ECDSA signature. We have set a deadline for this milestone, which is the next weekend. So far, we have made good progress.
• Protocol integration of bitcoin adapter and bitcoin system components: this week, the engineering team made significant progress, and the protocol between Bitcoin adapter in the network layer and Bitcoin system components in the execution layer began to work. That is, the Bitcoin system component can obtain blocks from the adapter. The adapter matches the request with its prefetched blocks and provides new bitcoin blocks in case of matching. The new blocks are processed by the system component. The block request of the bitcoin system component includes all block hashes in the bitcoin blockchain view that the system component has. The adapter responds with a bitcoin block to prevent its block from matching the “top” of the block of the system component in its local view. This protocol level integration is accomplished through a single adapter, which is “directly” connected to bitcoin system components rather than through the IC protocol stack. This means that the core part of Bitcoin-related functions now works in these two main components, but new communication mechanisms will continue to be developed in the future.
• The next step is to solve the integration problem of the protocol stack, such as the extension of the IC consensus layer to integrate the request and response with the IC protocol stack and allow the submission of outgoing transactions.

Updated on November 19:

• The official plans to release the “Developer Preview” of Bitcoin function without supporting threshold ECDSA, so that people can start pre-implementing Bitcoin-related business logic on canisters.

Updated on November 20:

• A milestone will be reached next week, suggesting the integration of a minimum of four sub-networks in an internal presentation.

Updated on November 26:

• The integration of the consensus function of the presign protocol and the encryption primitive has been completed. Among them, presign is the most complex part of the implementation of ECDSA function. Now we are still using the shortcut that still needs to be “solved” for end-to-end work. For these shortcuts, we will complete all functions after the implementation of the signature protocol.
• In order to make the presign more specific, we visualized the function through the Grafana dashboard. The details are shown below:

• The next milestone is the implementation of the signature protocol, which uses four times the presign protocol for each threshold ECDSA signature. It is simpler than the presign protocol and is currently being researched.

Updated on November 27:

• We may release the Developer Preview at the end of December or January so that our community can start using Bitcoin to build smart contracts. It is expected to be fully released in the late first quarter of 2022.

Updated on November 29:

• Taproot and threshold Schnorr Signature may be the next step after threshold ECDSA, but there is no definite decision at present. When implementing threshold Schnorr, we can fully take advantage of the synergy of threshold ECDSA. However, we still need to define protocol specifications, including key derivation scheme, prove its security, create system design (using synergy) and implement it.
• Therefore, our plan is to introduce the threshold ECDSA, and then consider taproot and threshold Schnorr.

Website: https://icpleague.com

Discord: https://discord.gg/TUvFXfK9Dv

Telegram: https://t.me/joinchat/qNiiCG5GAB9mZjc1