Understanding ICP for Bitcoin developers
This guide is designed to help Bitcoin developers understand the core concepts of ICP in order to properly use ICP as a Layer-2 solution for Bitcoin.
Terminology mapping
ICP uses different terminology for concepts similar to those in Bitcoin. This table summarizes the key terminology differences between Bitcoin and ICP:
| Bitcoin term | ICP term |
|---|---|
| Smart contract | Canister |
| Gas | Cycles |
| Account | Principal |
In addition, ICP has implemented similar token standards as Bitcoin:
| Bitcoin standard | ICP standard |
|---|---|
| BRC-20 | ICRC-1/ICRC-2 |
| BRC-721 | ICRC-7 |
Smart contracts
Bitcoin’s scripting language, Script, makes complex smart contracts rather difficult to deploy directly on the Bitcoin mainnet due to the language's limited capabilities.
Bitcoin developers who are looking to build complex smart contracts will need to use a Bitcoin smart contract layer (referred to as a Layer-2 or L2), such as ICP. Each L2 solution offers a unique set of developer tools.
Canister smart contracts on ICP have special properties that allow developers to develop scalable services. Canisters can be written in any language that complies to Wasm, including Rust, Typescript, Motoko, and Python. This allows for greater complexity in smart contract development compared to Bitcoin's Script language.
To learn more about full canister smart contract functionality, refer to the smart contracts documentation.
Specifically, through protocol-level integration of ICP with the Bitcoin network, ICP smart contracts can interact with the Bitcoin network directly. Canister smart contracts can run queries against the full Bitcoin UTXO set, including finding the balance of any Bitcoin address. They can hold, sign, and submit transactions to the Bitcoin network.
The Threshold Schnorr integration allows developers to interact with Runes and Ordinals directly in canisters. A Schnorr canister example is available in Motoko and Rust.
To learn more about the Bitcoin integration on ICP, refer to the Bitcoin integration documentation.
Consensus
Bitcoin uses proof of work as its consensus mechanism. Using proof of work, the Bitcoin blockchain waits for ten minutes before validating transactions one block at a time, posing challenges to security and scalability.
Instead of imposing time constraints, ICP relies on cryptographic signatures to finalize a block. A block maker selects available messages, merging them into a block. The consensus protocol maintains a tree of notarized blocks. Each replica creates a distinct finalization share for every notarized block, serving as a definitive indicator that consensus has been achieved. This entire process could take less than two seconds.
To enhance scalability, ICP divides canisters into smaller groups, each running within a subnet with a diverse set of replicas. This approach allows for additional subnets as needed.
To learn more about the consensus mechanism of ICP, refer to the consensus resource.
The enhanced ICP enhanced security and scalability make it suitable as a Layer 2 solution for Bitcoin.