Rust smart contracts via ink! and the contract pallet

[nud3l]

Abstract

Add support for Rust smart contracts by adding the contracts pallet and allow access to the BTC-Relay for smart contracts to interact with Bitcoin.

Motivation

Building an L2 for Bitcoin should use Rust as its core programming language: the new Bitcoin apps (e.g., https://github.com/ordinals/ord and https://github.com/rust-nostr/nostr), libraries (e.g., https://github.com/rust-bitcoin), and SDKs (e.g., https://github.com/lightningdevkit and https://bitcoindevkit.org/) are majorly based on Rust.

Ink is well supported in substrate and offers a developer experience very close to core Rust as it wraps the smart contracts inside a macro to handle its integration into a runtime (https://use.ink/basics/contract-template). From there, contracts need to be provided access to the existing runtime functions like the bitcoin light client, AMM, lending, bridge, …. For a great dev experience, hackathon templates and a well-documented SDK needs to be created for devs to get started with a new contract as simply as possible (should take less than 20 minutes to get started).

Possible use cases that could be build with this:

• Trustless P2P swaps between BTC, BRC20s, Ordinals and USDT, USDC using cross-chain proofs
• Bitcoin derivatives with settlement in Bitcoin or stables.
• Taproot NFT marketplace.
• Bitcoin hashrate derivatives / tokenized mining.
• DAO BTC treasury management.
• BTC payments for web3 games.

Specification

• Add the contracts pallet to the runtime: https://github.com/paritytech/substrate/tree/master/frame/contracts
• Allow access from smart contracts to the BTC-Relay
• Allow smart contracts to interact with the runtime by sending transactions
• Change the on-chain Bitcoin types to be compatible with rust-bitcoin
• Allow anyone to deploy smart contracts
• Add a SDK to allow development for smart contracts locally with default forking from mainnet for quick development and testing of integrations

Reference Implementation

Proof of concept: #1114

Security Considerations

TBD