PPT英文版
最后更新于
最后更新于
● Blockchains don't scale
● Lightning doesn't quite scale
● Can we scale Bitcoin to billions of users?
● 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!
● Stateful Bitcoin Scripts
● BitVM architecture
● BitVM bridges
● 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
● 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...
● Conceptually very simple
● Require only hash functions
● Possible in Bitcoin Script
● Main drawback: large
● But one can sign a u8, u32, u160
● 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++
● 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
● 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
● Basic instruction set rv32i
● Compile target for clang, gcc, LLVM
● Use existing C / C++ / Rust / ... libraries
● STARK & SNARK verifiers, etc...
● 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
● 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
● 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
● 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
● 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
