The Internet Computer’s Bitcoin Integration Nears Completion
A progress update on the Internet Computer blockchain’s direct integration with Bitcoin and implementation of threshold ECDSA signatures.
The Internet Computer’s direct integration with Bitcoin is bringing advanced smart contracts to the world’s largest cryptocurrency without an intermediary or bridge, providing a trustless foundation for DeFi projects using Bitcoin. The development of the Bitcoin integration and threshold ECDSA signatures, which will enable Internet Computer smart contracts to securely hold and spend BTC and other cryptocurrencies, is highly exploratory in nature, therefore the DFINITY R&D team has had to overcome a variety of difficulties in working toward full implementation.
The team has made excellent progress on this front. We recently deployed the replica on a testnet, enabled the Bitcoin integration, and synced the entire Bitcoin testnet. The metrics on the testnet, such as finalization rate and checkpointing time, all look healthy. Here is a snippet of the logs from the testnet:
This week, we will deploy a new Internet Computer subnet on which we will enable the Bitcoin integration. We will then start syncing the Bitcoin testnet on that subnet. Once the system has been confirmed to work as intended, we will enable the Bitcoin API and make it publicly available for testing and development. The Bitcoin API will support only the Bitcoin testnet for now. Some of the features will be missing, but they will be quickly and incrementally introduced from then on.
The Chromium (aka Satoshi Release) milestone is targeting a release by the end of May 2022. The Bitcoin integration and the threshold ECDSA feature are the essential parts of this milestone. Teams are working diligently on both features to meet this timeline, but they are not as plannable as regular “commodity” software development owing to their complexity. If everything proceeds smoothly, we may meet this timeline, but there is a possibility of it slipping by some weeks.
One of the key challenges that needed to be overcome to arrive at this point was determining how to efficiently store the Bitcoin state. Using a simple Rust standard collection would make it part of the replica’s runtime, which presents considerable difficulties owing to the replica’s checkpointing, where every few minutes it takes the contents of its memory and persists it to disk. Memory consumption presents an additional issue. Representing the Bitcoin state in this manner would require tens of gigabytes of RAM to store the state.
We introduced a solution for storing the Bitcoin state called a StableBTreeMap: a BTreeMap that has a very similar interface to the Rust standard BTreeMap, but with the key difference that it manages its own memory. This allows us to have a key value store that is being persisted in precisely the same way that a canister’s memory is being persisted. Most of the Bitcoin state will be living on disk, and whenever we need to fetch data from this key value store, we would only fetch the relevant bits of memory from disk. Checkpointing would only serialize the difference between what is in the replica’s memory and what is on disk. (The StableBTreeMap is an efficient approach to using stable memory that has implications for other aspects of memory management on the Internet Computer, which the R&D team is currently exploring.)
In our recent syncing of the Bitcoin testnet with a replica deployed on a testnet, we verified the correctness of the UTXO set as well as the correctness of our StableBTreeMap implementation. The next steps will involve performing further runs in test environments in order to confidently determine that everything works as intended before the first deployment on an IC mainnet subnet for observation and testing.
As a side task, another team is working on the SDK integration of the feature — i.e., managing the Bitcoin Adapter process from the SDK, including its configuration. This is crucial work that moves the feature toward full completion while allowing developers to conveniently implement canisters against the Bitcoin API.
DFINITY researchers Victor Shoup and Jens Groth recently published a paper describing the cryptographic primitives behind the threshold ECDSA feature, but work is still being done to finalize the integration with consensus — e.g., for the XNet re-sharing of a threshold ECDSA key, as well as some other parts of system integration. For example, the functionality related to the Network Nervous System proposals for key management (particularly disaster recovery) still requires more work. A remaining item will be the integration with dfx, the DFINITY command-line execution environment, which is essentially enabling the feature and generating/loading a key when dfx starts up a replica in the local development environment.
Another important and impending task is having an external party conduct a security review of the entire Bitcoin integration feature as well as the consensus-related parts of the threshold ECDSA code. This will begin soon, and we plan to publish the resulting audit report once the findings have been addressed to share its insights with the Internet Computer community. The cryptographic protocol part of threshold ECDSA has been independently audited already.
Though considerable work remains, the most challenging elements of this project have been successfully addressed. Many of the remaining tasks before arriving at general availability — such as support for Taproot addresses, pagination support for UTXOs, and performance optimizations — are relatively straightforward.
We appreciate your patience in awaiting the launch of the Bitcoin integration and threshold ECDSA features, which will unlock an array of exciting use cases for Bitcoin and the Internet Computer blockchain.
____
