PPT英文版

495KB

bitvm-slides.pdf

pdf

BitVM Off-chain Bitcoin Contracts

Motivation

● Blockchains don't scale

● Lightning doesn't quite scale

● Can we scale Bitcoin to billions of users?

Envisioning an Ideal World

● 100 - 1000x higher throughput

● Free market of L2s (zk-rollups, sidechains,zkCoins, ...)

● Rapid innovation / cheap experimentation

● All L2s interconnected via LN

● Possible, but we need bridges!

Overview

● Stateful Bitcoin Scripts

● BitVM architecture

● BitVM bridges

Stateful Bitcoin Scripts

Bitcoin Script

● Satoshi disabled all the fun opcodes

● Reduced to minimum

● But enough interesting opcodes are left

● Scripts can be up to 4mb

● Bitcoin Script code golf

Stateful Bitcoin Scripts

● Idea: If we could sign a value...

● Enforcing the same value for x in script1 and script2

● Punish equivocation

● How to sign a value though?

● We don't have CSFS...

Lamport Signatures

● Conceptually very simple

● Require only hash functions

● Possible in Bitcoin Script

● Main drawback: large

● But one can sign a u8, u32, u160

Lamport Signature for a 1-bit Message

BitVM Architecture

BitVM the paradigm

● Tries to keep things off-chain (like LN)

● 2-party setting: prover and verifier

● Optimistic computation

● Disprove a faulty result (much easier than execution)

● Tree++

Tree++

● Language to express Bitcoin Contracts in graphs of transactions

● Templating language for Script

○ Evaluate constant expressions

○ Unroll loops

○ Compose functions

● Statefulness via Lamport signatures (u8, u32, u160, ...)

● Composite opcodes (xor, shift, mul, blake3, ...)

● Connector outputs

● Potentially large scripts, large Taptrees, and large TX graphs

BitVM the Bitcoin VM

● Don't want to hand-craft and hand-optimize a low-level circuit for every application

● Build some generic VM

● Succinctly disprove any faulty result

● Ideally: RISC-V architecture

BitVM Specs

● Basic instruction set rv32i

● Compile target for clang, gcc, LLVM

● Use existing C / C++ / Rust / ... libraries

● STARK & SNARK verifiers, etc...

BitVM Detailed Specs

● Max steps: 2^32

● Memory: 2^32 * 4 bytes ~ 17GB

● Worst case: ~40 rounds of challenge & response

● "Court case" runs for up to half a year

● In total: ~150kb of Scripts

● Worst case is heavily disincentivized

● Likely never happens in real world applications

BitVM Bridges

BitVM Bridges

● Bridge BTC to any other system

● Idea: a bit clunky is fine

● Bridge is used rarely. Only large amounts

● End users use cross-chain swaps

BitVM Bridge Guarantees

● A Federation, but a single honest member suffices

● Guarantees that the bridge is safe and live

○ safe: nobody can steal the deposit

○ live: you can't stop a valid peg-out

● Large federations: +100 members

● You can be a member. Then you don't have to trust anyone

Limitations

● Complexity

● Balancing incentives: Loser has to pay winner's fees + bounty

● If incentives are balanced the chain is not needed

● Potentially capital intensive

● But no 1:1 collateral required

● For every peg-in all N parties have to pre-sign N peg-out TXs

● Federation can censor peg-ins

Summary & Outlook

● BitVM enables more complex Bitcoin contracts

● Use case: trust-minimized bridges for rollups, sidechains, L2s, ...

● Limitation: practical but clunky

● Requires no softfork

● Toy version ready this month

● Reckless mainnet this year