> For the complete documentation index, see [llms.txt](https://bitvm.gitbook.io/doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitvm.gitbook.io/doc/featured-articles/robin-linus-on-bitvm/ppt-ying-wen-ban.md).

# PPT英文版

{% file src="/files/4yKBkvLkSBqMba3QxgFA" %}

## 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

<figure><img src="https://2933093085-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2E93vAVWL3E2kQSMHQMn%2Fuploads%2FDXldwRsayziTwuaXUN3a%2F%E7%AC%AC9%E9%A1%B5-1.PNG?alt=media&amp;token=cbf20f4f-735c-4eca-87a1-f5df9472d45f" alt=""><figcaption></figcaption></figure>

## 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&#x20;

<figure><img src="https://2933093085-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2E93vAVWL3E2kQSMHQMn%2Fuploads%2FEFLxBRXMNcDPkXFO71wA%2F%E7%AC%AC16%E9%A1%B5-2.PNG?alt=media&amp;token=5a6413d1-8ab9-4ca0-beac-26ef9baee6e0" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2933093085-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2E93vAVWL3E2kQSMHQMn%2Fuploads%2FjowuLyGOkoHxGQVagWKK%2F%E7%AC%AC17%E9%A1%B5-3.PNG?alt=media&amp;token=0eeae40a-2156-466a-8dc2-36e9a065136a" alt=""><figcaption></figcaption></figure>

&#x20;

## BitVM Bridges&#x20;

### BitVM Bridges&#x20;

●   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

<figure><img src="https://2933093085-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2E93vAVWL3E2kQSMHQMn%2Fuploads%2FAViL9PNNqWDWi2TkKozo%2F%E7%AC%AC21%E9%A1%B5-4.PNG?alt=media&amp;token=ba53415e-ecdf-4c7d-9123-cf8a8600293f" alt=""><figcaption></figcaption></figure>

### 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