# PPT英文版

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

## BitVM Off-chain Bitcoin Contracts&#x20;

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

&#x20;

## 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="/files/zLGyZNPVoqdYfCgWkiMi" 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="/files/UmILKh1Iem341mf4wWVy" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/OH6xhO3n7ncwjRLCkhSk" 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="/files/yJnetWnlLbZ6usdEcCzk" 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://bitvm.gitbook.io/doc/featured-articles/robin-linus-on-bitvm/ppt-ying-wen-ban.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
