As announced already here in the forum, this feature with the goal of directly integrating with Bitcoin is going through a community-wide voting process. In this post, we present the feature design.
NNS Proposal: Direct Integration with Bitcoin
Main authors: Dieter Sommer, @THLO
Background
Bitcoin is a decentralized digital currency based on an open-source P2P protocol. Bitcoin uses the unspent transaction output (UTXO) accounting model, i.e., transactions create outputs which are used as inputs to other transactions that create new transaction outputs.
Bitcoin is a payment network without support for smart contracts. Smart contract support for Bitcoin would add tremendous value: Smart contracts for Bitcoin would leverage the combined strength of the Bitcoin network as the world’s digital gold reserve and the Internet Computer as a platform for securely and efficiently executing smart contracts. An example class of applications that will become possible with this integration are decentralized finance (DeFi) applications, which can currently be implemented only with wrapped Bitcoin and additional trusted entities on blockchains such as Ethereum. Moreover, Bitcoin could be used for paying for any kind of services on the Internet Computer, which opens up a sheer endless number of application scenarios.
Goals and Requirements
The goal for this feature is a direct integration with the Bitcoin network with the following functionalities:
- Canisters can directly hold Bitcoin, i.e., the balances of canisters are captured on the real Bitcoin network. These Bitcoin smart contract canisters can run Turing-complete logic and, based on this, decide when to make Bitcoin transactions to other entities such as regular Bitcoin users or other canisters implementing Bitcoin smart contracts.
- Canisters can create Bitcoin transactions and submit them to be reliably relayed to the Bitcoin network.
A direct integration implies not only that canisters can hold Bitcoin themselves, but also that there are no intermediaries such as bridges introduced into the design.
The intended integration requires the Internet Computer offering the following functionalities to canisters:
- Enabling canisters to receive and hold Bitcoin on the Bitcoin network;
- Tracking the UTXO set belonging to canisters and enabling canisters to query their respective UTXO set;
- Enabling canisters to create Bitcoin transactions and accepting such transactions from canisters to be relayed to the Bitcoin network.
In order to achieve Functionality (1), canisters must be able to have a Threshold ECDSA public key from which their Bitcoin addresses are derived. Threshold ECDSA is a separate feature going through community voting concurrently with this feature. Functionality (2) requires that we ingest Bitcoin blocks into the Internet Computer, validate them, and track the Bitcoin blockchain. Once blocks have a sufficient amount of work in successor blocks on the blockchain, transactions and their UTXOs can be extracted and served to canisters upon request. Functionality (3) depends on the aforementioned Threshold ECDSA feature, which makes it possible for canisters to consume UTXOs. Furthermore, the Internet Computer must establish an outbound communication channel over which an outgoing transaction from a Bitcoin smart contract canister can be reliably relayed to the Bitcoin network.
Design
A high-level overview of the technical design is outlined next. The figure below further illustrates the high-level design.
In the Execution layer of the Internet Computer, we implement a BTC system component that offers the following APIs to query the UTXO set associated with the requesting canister’s public key and submit transactions to the Bitcoin network, respectively:
-
get_utxo_set(canister_id: PrincipalId, num_confirmations: u32) -> Vec<UTXO>
The function returns the UTXO set corresponding to the given canister_id, where num_confirmations specifies the minimum number of confirmations the UTXO must have. If the number of confirmations isk, then the transaction hask-1successor Bitcoin blocks. -
put_transaction(transaction: BtcTransaction) -> BtcSystemResponse
Requests to submit the given transaction to the Bitcoin network. The response indicates whether the BTC system component has received the transaction, which will then be transmitted to the Bitcoin network asynchronously.
We plan to further provide a library that provides the following convenience functions to developers:
-
get_balance(num_confirmations) -> BtcBalance
The function returns the Bitcoin balance of the canister for the given number of confirmations. -
send_bitcoin(amount, recipient) -> BtcSystemResponse
The function sends the specified Bitcoin amount to the provided recipient address.
In the Networking layer, we implement multiple components required for this feature. Notably, the Bitcoin Adapter implements the Bitcoin-specific functionality in this layer: It connects to the Bitcoin network and maintains a recent view of the Bitcoin network and provides blocks to the Consensus layer on request. Adapters perform a first validation of Bitcoin blocks to prevent dishonest Bitcoin nodes from spamming the BTC system component.
The BTC system component receives Bitcoin blocks that are provided by the Bitcoin Adapter at the Networking layer via Consensus and Message Routing. A protocol between the Bitcoin Adapter and the BTC system component enables the Bitcoin Adapter to decide which block to provide next. The BTC system component further makes outgoing Bitcoin transactions available at the Networking layer, where they are transmitted to the connected Bitcoin nodes.
High-level architecture
Alternative Designs
The proposed design has emerged from an evaluation of multiple possible designs and has been found to be the most suitable design for the Internet Computer in terms of architectural cleanliness, decentralization, and scalability.
An alternative design that was considered is the introduction of an oracle canister, which is a regular canister that offers the functionality of serving UTXO sets to canisters and accepting Bitcoin transactions. This design has several shortcomings. First, relays would be required to send Bitcoin blocks to this canister, which would entail that trust assumptions related to these relays must be introduced. This design is not in line with the goal of having a direct integration. Additionally, the design suffers from scalability limitations as all Bitcoin smart contract canisters would be interacting with the oracle canister.
Another design we investigated was to introduce an oracle canister on all subnets where Bitcoin functionality is made available. This design would require these canisters to be “special” in multiple ways: They would have to run without consuming cycles and be instantiated when the subnet starts up. There would be numerous additional technical challenges, for example with respect to routing, which led us to abandon the design.
Roadmap
The feature affects all four layers of the IC protocol stack and requires engineering work by all affected teams. Most engineering effort is expected in the Networking layer and the Execution layer as all the Bitcoin-related functionality is implemented in those layers. The efforts for the integration with Consensus and Message Routing are comparably small.
The implementation work will be carried out on the different layers in parallel as much as possible. While there is no detailed timeline for the development effort, the goal is to have all pieces implemented and tested by the end of 2021.
Naturally, there is a strong dependency on the threshold ECDSA feature in that it is a hard prerequisite for the Bitcoin integration.
It is important to mention the crucial role of quality assurance for both the Bitcoin integration feature and the Threshold ECDSA feature for the reason that once value in the form of Bitcoin has been transferred to canisters, the feature deployment cannot be reasonably rolled back any more.