区块链原生应用，是结算、托管与规则从构造上就在链上的经济活动，而不是一门在旁边挂上一个代币的传统生意。这听起来像是另一种工程，其实差别没有听上去那么大。

你今天所用技术栈的每个组件都有对应物。对应物做同样的工作，只改变一点：过去靠信任的，现在靠证明。远地虚拟机的存在，就是为了让这一改变便宜到足以成为默认选择。

一句话说清这一转变#

在传统应用中，服务器就是权威：它持有数据、执行规则、报告结果。在区块链原生应用中，链持有对数据的承诺，规则是一个任何人都能用其摘要指明的程序，而结果只有附带一份“确由该程序产生”的证明才会被接受。

运营方并不会消失。仍然有人运行程序、存储数据、响应请求。消失的，是必须相信他们这件事。

逐层对照#

中间一列就是区块链原生应用的构成。其下的机制由远地虚拟机提供：RISC-V 机器、电路、承诺、递归和验证者合约。这些都不会出现在你的程序里。

不变的部分#

• 你写的仍然是普通的 Rust。 结构体、枚举、trait、迭代器、Vec、BTreeMap，以及任何不依赖 std 就能构建的 crate。没有电路语言要学。
• 你仍然在自己的笔记本电脑上测试。 常见的布局是把应用逻辑放进一个 no_std 库：它在宿主机（host）上通过 cargo test 运行，行为与在客户程序中运行时完全一致。参见编写客户程序。
• 你思考的仍然是状态、请求与响应。 形态不变，变的只是它们的保证。
• 确定性的代码依然是确定性的。 好的后端代码本来就避免隐藏的输入，虚拟机把这一点变成绝对的要求。

改变的部分#

• 没有外部世界。 客户程序没有时钟、没有随机数、没有网络，也没有文件。它知道的一切都以公开输入或证明者提示的形式送达，而向宿主程序请求数据，是一种任何证明都不会接纳的调用。
• 每条指令都有代价。 每条执行过的指令都会成为一行被证明的数据。复制、内存分配和空转循环都要消耗证明时间，于是精打细算周期数的老规矩又回来了。
• 外部提供的数据要检查，而不是信任。 证明者提示由证明者选择。在发布任何由它推导出的内容之前，客户程序要先把它与证明所绑定的某样东西进行核对。
• 输出小而公开。 公开输出最多容纳 16,380 字节。较大的结果以摘要形式发布。
• 没有任何东西是隐藏的。 远地虚拟机 v1.0.0 的证明是简洁的，但不是零知识的。客户程序不得持有秘密。

一个账本，两种做法#

向一个账户余额存入一笔款项：值得证明的最小状态变化。

传统版本#

BEGIN;
SELECT balance FROM accounts WHERE id = $1 FOR UPDATE;    -- read
UPDATE accounts SET balance = balance + $2 WHERE id = $1;  -- write
COMMIT;                                                     -- make it durable

用户信任运营方：相信它对真实的表执行的正是这段代码，并且如实报告了结果。

区块链原生版本#

账户存放在一棵二叉 Merkle 树中，叶子为 keccak256(account ‖ balance)。合约存储树根。客户程序以公开输入的形式接收旧根和请求，以证明者提示的形式接收账户余额及其 Merkle 路径，检查路径，然后发布旧根和新根。

#![no_std]
#![no_main]

guest_sdk::entry!(main);

const DEPTH: usize = 20; // room for 2^20 accounts

/// A leaf commits to one account's balance.
fn leaf(account: &[u8; 20], balance: u64) -> [u8; 32] {
    let mut bytes = [0u8; 28];
    bytes[..20].copy_from_slice(account);
    bytes[20..].copy_from_slice(&balance.to_le_bytes());
    guest_sdk::keccak256(&bytes)
}

/// Fold a leaf up its Merkle path; bit `level` of `index` says whether the
/// node is a right child at that level.
fn root_of(mut node: [u8; 32], index: u32, path: &[[u8; 32]; DEPTH]) -> [u8; 32] {
    let mut pair = [0u8; 64];
    for (level, sibling) in path.iter().enumerate() {
        let (left, right) = if (index >> level) & 1 == 0 { (&node, sibling) } else { (sibling, &node) };
        pair[..32].copy_from_slice(left);
        pair[32..].copy_from_slice(right);
        node = guest_sdk::keccak256(&pair);
    }
    node
}

/// Public input: old_root (32) ‖ account (20) ‖ amount (8, LE)
/// Advice:       balance (8, LE) ‖ index (4, LE) ‖ path (DEPTH × 32)
/// Journal:      old_root ‖ new_root ‖ account ‖ amount
fn main() {
    let input = guest_sdk::public_input();
    let advice = guest_sdk::advice();
    if input.len() != 60 || advice.len() != 12 + 32 * DEPTH {
        guest_sdk::exit(1);
    }
    let old_root: [u8; 32] = input[..32].try_into().unwrap();
    let account: [u8; 20] = input[32..52].try_into().unwrap();
    let amount = u64::from_le_bytes(input[52..60].try_into().unwrap());

    let balance = u64::from_le_bytes(advice[..8].try_into().unwrap());
    let index = u32::from_le_bytes(advice[8..12].try_into().unwrap());
    let mut path = [[0u8; 32]; DEPTH];
    for (i, sibling) in path.iter_mut().enumerate() {
        sibling.copy_from_slice(&advice[12 + 32 * i..12 + 32 * (i + 1)]);
    }

    // The query: the balance the prover supplied is the one the root commits to.
    if root_of(leaf(&account, balance), index, &path) != old_root {
        guest_sdk::exit(2);
    }
    // The write: the same path with the new leaf gives the new root.
    let Some(new_balance) = balance.checked_add(amount) else { guest_sdk::exit(3) };
    let new_root = root_of(leaf(&account, new_balance), index, &path);

    // The commit: publish the transition for the contract to apply.
    guest_sdk::commit(&old_root);
    guest_sdk::commit(&new_root);
    guest_sdk::commit(&account);
    guest_sdk::commit(&amount.to_le_bytes());
}

对照 SQL 来读：SELECT … FOR UPDATE 变成了对照根检查的 Merkle 路径；UPDATE 变成了同一路径上的新叶子；COMMIT 变成了四次 commit 调用，它们写入的公开输出将由证明绑定。余额来自证明者，这没有问题：根并未承诺的余额无法通过检查，运行以 2 退出。

持有根的合约只有在收到证明、表明这次转换由该程序产生并以 0 退出时，才会接受它：

interface IApogeeVerifier {
    function verify(bytes calldata input, bytes calldata output, uint256 exitStatus,
                    uint256[10] calldata proof, uint256[] calldata points) external view returns (bool);
}

contract Ledger {
    IApogeeVerifier public immutable verifier;
    bytes32 public root;

    constructor(IApogeeVerifier v, bytes32 genesis) { verifier = v; root = genesis; }

    function apply(bytes calldata input, bytes calldata journal,
                   uint256[10] calldata proof, uint256[] calldata points) external {
        require(verifier.verify(input, journal, 0, proof, points), "proof");
        require(bytes32(journal[0:32]) == root, "stale root");
        root = bytes32(journal[32:64]);
    }
}

三行概括这个模型#

1. 链持有一个根。
2. 客户程序证明这次转换。
3. 合约推进这个根。

其余的一切，从分片、电路到递归与判定器，都由远地虚拟机负责。这就是这层抽象：一个程序、它的输入与输出，以及把它们联系在一起的一份证明。

下一步#

一段话概述#

远地虚拟机是一台 RISC-V zkVM。它证明：一个由其映像摘要所指明的 RV32IMAC 程序，在给定的公开输入上运行到某个退出状态，并写出了给定的公开输出。它把这份证明经由递归树带到一份 Groth16 证明，交由以太坊合约检验。每个电路都是 BN254 标量域上的分层 GKR 电路，每个已承诺列都用 Mercury 打开，每个挑战都来自 Poseidon2 transcript。域、曲线、配对、MSM、哈希、多项式承诺、GKR 证明者和 Groth16 全部在仓库内实现。它的参考工作负载是以太坊区块校验。

基本事实#

实测数据#

所有数据均来自 glamsterdam-devnet-8 的第 257,510 号区块，由无状态校验器客户程序执行：60 笔交易，101.5 Mgas，198M 个周期。来源：规范的 recursion §10 与 streaming §1。

验证者必须持有的值#

两个值，都要取自证明者无法控制的渠道：

• 程序身份，一个域元素。如果对照的是证明者提供的身份，证明只能说明有某个程序运行过。
• 仪式的 SRS 摘要。 基于已知 τ 构造的密钥，只有通过这项比对才会被拒绝。

验证密钥本身可以来自任何人：加载时会根据其自身内容重新计算这两个值，并要求其中的电路与验证者的注册表一致。安全模型列出了全部假设。

v1.0.0 止步之处#

• 不是零知识的。 Mercury、GKR 和判定器中都没有盲化。
• 证明者提示不受绑定。 客户程序要将它与证明所绑定的某样东西进行核对。
• 陷入（trap）不可证明。 未对齐的访问、对映射内存之外的访问、ebreak，或者 pc 处没有指令，都会使运行终止，且不产生证明。
• sc.w 总是成功。 这是与 RV32IMAC 唯一的偏差：没有保留（reservation）状态。
• 委托固定为六种。 任意模数的 EVM MULMOD、MODEXP 与 BLS12-381 都以普通指令运行。
• 证明受内存限制。 实测区块的内存峰值为 174 GiB；内存占用取决于同时处理中的分片，而不是运行长度。
• 判定器密钥随根的形状而定，其可信程度取决于它的仪式。开发用密钥是可伪造的。

谁在构建#

远地虚拟机是 G Web3 面向区块链原生应用环境的研究计划的旗舰项目：每个经济应用一个经过优化的环境，各自以有效性证明结算到以太坊。该计划的立场见核心理念；下一个版本的方向见量子跃迁。

客户程序（guest）是远地虚拟机所证明的程序：一个为 riscv32imac-unknown-none-elf 编译的 no_std Rust 二进制程序，带一个入口点、三个用于输入和输出的内存区域，除此之外别无他物。宿主程序（host）是围绕它的一切：负责提供输入、向远地虚拟机请求证明、再把证明交给检验方的代码。两者都由你编写。远地虚拟机提供机器、电路和验证者。

本节同时写给两类读者：坐在键盘前的工程师，以及与他们协作的模型。每一页都把规则直白地写出来，AI 随行手册则把全部规则浓缩进一个文件，你可以在助手写下第一行代码之前就交给它。

基本模型#

一份证明只陈述一件事：具有此身份的程序，在其映像上以此公开输入和某份由证明者选定的证明者提示启动，运行至以此状态调用 EXIT，并已写出此公开输出。你构建的一切都建立在这句话之上。

工作流程#

快速上手用一个只有三行的客户程序，把整个流程完整走一遍。

最重要的规则#

客户程序编程指南逐条解释了这些规则，说明违反时会出什么问题，以及应该怎么做。

• usize 和所有指针都是 32 位。 usize 溢出只在客户程序中触发 panic，x as usize 会静默截断，任何布局或哈希依赖于长度的东西，在宿主机与客户程序之间都不一致。
• 分配器从不释放内存。 它从 __heap_start 起向上推进一个指针，所以让客户程序耗尽内存的，是它在整个运行期间分配的总量，而不是峰值。复用缓冲区，并用 with_capacity 预先设定容量。
• 原子操作能正常工作，但你不应该写它们。 这台机器只有一个 hart，A 扩展的存在是为了兼容已经在使用它的代码。新写的客户程序代码没有任何需要同步的东西。
• 没有外部世界。 没有文件、没有时钟、没有随机数、没有网络。客户程序所知道的，只有它的公开输入、它的证明者提示，以及它自己算出的东西。
• 证明者提示由证明者选择。 在任何由它推导出的内容进入公开输出之前，先把它与证明所绑定的某样东西核对。
• 公开输出很小。 最多 16,380 字节。任何会增长的内容，都发布其摘要。
• release 构建中溢出检查保持开启。 它们是程序计算内容的一部分，所以客户程序的构建 profile 把它们固定下来。
• 每条执行过的指令都是一行被证明的数据。 证明成本取决于周期数，所以先用 --release 构建并统计周期数，再去优化其他任何东西。

从哪里开始#

本页用一个最小的、确实做了点事情的客户程序（guest），把整个流程完整走一遍：它读取自己的公开输入，并把它作为公开输出（journal）发布。下面的每一段输出，都是在远地虚拟机 v1.0.0 上原样运行这些命令得到的。

[package]
name = "hello"
version.workspace = true
edition.workspace = true
publish.workspace = true

[dependencies]
guest-sdk.workspace = true

#![no_std]
#![no_main]

guest_sdk::entry!(main);

fn main() {
    // The public input is memory: a slice, with no ecall and no cursor.
    guest_sdk::commit(guest_sdk::public_input());
}

members = ["fib", "echo", … , "recursion", "hello"]

cd guests/hello
cargo build --release --target riscv32imac-unknown-none-elf
cd ../..

printf 'hello, apogee' > /tmp/hello.in
cargo run --release -p profiler -- elf guests/target/riscv32imac-unknown-none-elf/release/hello --input /tmp/hello.in

workload
  label                        hello
  guest                        hello
  guest cycles                 114
  exit status                  0
  journal bytes                13

cycles by family
  ADD_SUB_LUI_AUIPC            64
  JUMP_BRANCH_SLT              21
  MEM_WORD                     3
  MEM_SUBWORD                  26

cargo run --release -p artifact-dump -- tables \
    guests/target/riscv32imac-unknown-none-elf/release/hello \
    --ptau assets/ptau/ppot_0080_24.ptau

program identity  9ead85cee880df30daa8eba657316215107a075640a64ccf2424a054b758b802

VmConfig
--------
  id  family              height     live rows  columns
   0  ADD_SUB_LUI_AUIPC     4194304         33  pc next_pc rs1 rs2 rd imm extra_mask
   1  JUMP_BRANCH_SLT       4194304         12  pc next_pc rs1 rs2 rd imm extra_mask
   4  MEM_WORD              4194304          3  pc next_pc rs1 rs2 rd imm extra_mask
   5  MEM_SUBWORD           4194304          3  pc next_pc rs1 rs2 rd imm extra_mask
   7  INIT_TEARDOWN         4194304          0  none: claims no pc
   8  ZERO_WINDOWS          4194304          0  none: claims no pc
  12  PUBLIC_INPUT             4096          0  none: claims no pc
  13  PUBLIC_OUTPUT            4096          0  none: claims no pc
  14  ADVICE_WINDOWS        4194304          0  none: claims no pc

use constants::family;
use emulator::GuestIo;
use program::ProgramParams;
use srs::Srs;

fn main() {
    let elf = std::fs::read("guests/target/riscv32imac-unknown-none-elf/release/hello")
        .expect("build the guest with --release first");

    // Small heights for a small program: the seven instruction families at
    // their 2^20 floor, the three RAM-window families at 2^16. Every choice of
    // heights is its own program identity.
    let mut params = ProgramParams::defaults();
    for f in 0..7 {
        params.heights[f] = 1 << 20;
    }
    for f in [family::INIT_TEARDOWN, family::ZERO_WINDOWS, family::ADVICE_WINDOWS] {
        params.heights[f as usize] = 1 << 16;
    }

    // As many ceremony powers as the tallest family has rows: 2^20 here.
    let ptau = std::path::Path::new("assets/ptau/ppot_0080_24.ptau");
    let srs = Srs::from_ptau(ptau, 20).expect("the ceremony file reads");
    let setup = host::setup(&elf, &params, srs).expect("the program registers");

    let io = GuestIo { input: b"hello, apogee".to_vec(), advice: Vec::new() };
    let proven = host::prove(&setup, &io, 2).expect("the run proves"); // two shards in flight
    host::verify(&setup.vk, &proven.block).expect("the block verifies");

    assert_eq!(proven.exit_code, 0);
    assert_eq!(proven.journal, b"hello, apogee");
    let id: String = setup.vk.identity.to_bytes().iter().map(|b| format!("{b:02x}")).collect();
    println!("identity  {id}");
    println!("cycles    {}", proven.cycles);
    println!("shards    {}", proven.report.shards);
    println!("journal   {:?}", core::str::from_utf8(&proven.journal).unwrap());
}

cargo run --release -p host --example prove_hello

identity  606d1f1d720459cc1a078787381656b29c9fce5a9e539b36f899e62b64129c14
cycles    114
shards    7
journal   "hello, apogee"

assert_eq!(setup.vk.identity.to_bytes(), registered); // `registered` from your own channel

刚才发生了什么#

模拟器把这 114 条指令执行了两遍。第一遍承诺了每个分片的内存列，并确定了陈述；第二遍填充每个分片并证明它。一共七个分片：执行过的四个指令电路族各一个，存放程序映像的内存窗口一个，公开输入和公开输出各一个。这个客户程序从未触及自己的栈，所以没有其他窗口需要分片；典型的程序还会多出栈所在窗口的分片。每个分片都由其电路族的 GKR 电路证明，并用一个 Mercury 证明打开；验证者用一个等式核对了全部七个分片的内存读写。系统架构概述沿着同一条路径给出了详细说明。

下一步#

远地虚拟机 v1.0.0 是一个 Rust 代码仓库。除了 rustup 之外无需安装任何东西：仓库固定了自己的工具链，工具链自带客户程序（guest）的编译目标。编写、构建、运行客户程序以及分析其性能，都不再需要别的东西。证明则额外需要一个大文件，以及一台内存相应充足的机器。

工具链#

仓库根目录下的 rust-toolchain.toml 固定了 stable 版 Rust 1.96.1，连同 rustfmt、clippy 和 llvm-tools，以及目标 riscv32imac-unknown-none-elf，该目标的 core 和 alloc 以预编译形式提供。rustup 会在根目录以下的每个目录中应用它，并在首次使用时安装。

cd apogee-vm
rustup show active-toolchain     # 1.96.1, overridden by rust-toolchain.toml
cargo --version

仓库中任何地方都不使用 nightly，也不使用任何不稳定特性。llvm-tools 提供与编译器的 LLVM 相匹配的 llvm-objdump 和 llvm-nm：仓库用它们生成已提交的反汇编清单，你也可以用它们阅读客户程序的代码。

两个工作空间#

检出的代码中有两个 Cargo 工作空间，这一划分很重要：

客户程序之所以单独存放，是因为每个成员都为客户程序目标编译，并链接一个 #[panic_handler]；在根目录运行的 cargo test --workspace 绝不能触及它们。客户程序工作空间还带有正确构建客户程序所需的设置，所以你永远不必手动输入：

• guests/.cargo/config.toml 设定目标，并向链接器传入 -T crates/guest-sdk/link.ld（即内存布局）和 --no-relax，因为链接器松弛（relaxation）会移动程序身份所绑定的地址。
• guests/Cargo.toml 把两个构建 profile 固定为相同的语义，溢出检查也包括在内（构建与检查）。
• 它的 [patch.crates-io] 把 k256、ark-ff 和 revm-precompile 指向仓库内的 vendored 副本，这些副本会调用远地虚拟机的委托（委托）。

仪式文件#

远地虚拟机做出的每个承诺，都基于一场公开仪式所产生的秘密 τ 的各次幂：PSE 的 perpetual powers of tau，第 80 次贡献。一个文件满足所有用途：

assets/ptau/ppot_0080_24.ptau        19.3 GB, 2^24 powers; assets/ptau/ is gitignored

计算程序身份、构建真实密钥和执行证明都需要它。构建、运行客户程序和分析其性能，或者运行工作空间测试，都不需要它；这些测试在各自的玩具设置上做证明。

PSE 仪式的各个文件截取自同一份 transcript，所以任何幂次不低于 24 的文件都可以用。Hermez 的 powersOfTau28_hez_final_*.ptau 是另一场仪式，τ 也不同：读取器同样能顺利读入它，但基于它得到的每个承诺、密钥和程序身份都会不同。为确认你持有的是正确的仪式文件，可以核对它的 [τ]_1，其规范编码 x ‖ y 的十六进制表示为：

9bbb31bedc304e081e2aada4b56c2217e0e94ee16874e3517d14bef5dcec3a16
317ff1589e53513fa333591b318e8f1e55ef7c37d92beb6d9a61d770a2f39506

规范中的 SRS 页面准确说明了读取器检查哪些内容、又默认信任哪些内容。

机器#

构建和运行在笔记本电脑上就能完成。证明受内存限制，其内存占用取决于同时证明的分片，而不是运行的长度。

证明页面解释了高度和同时处理的分片数如何在内存与时间之间权衡：证明与验证。

检查你检出的代码#

CI 运行的内容如下，全部不需要仪式文件：

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
cargo run -p kat-gen && git diff --exit-code      # committed fixtures regenerate identically
(cd guests && cargo clippy --bins -- -D warnings)

证明真实分片的测试套件都标记了 #[ignore]，因为每个都需要数十 GiB 内存。想在自己的机器上亲眼看到证明的生成与拒绝时，按名称运行其中一个：

cargo test --release -p prover --test acceptance -- --include-ignored --test-threads=1

下一步：编写客户程序，或者在快速上手中把整个流程走一遍。

客户程序 crate#

在 v1.0.0 中，客户程序（guest）是代码仓库 guests/ 工作空间中的一个二进制 crate。工作空间提供目标、链接器参数、固定的 profile 和 vendored crate，所以客户程序自己的清单可以保持简短：

[package]
name = "my-app"
version.workspace = true
edition.workspace = true
publish.workspace = true

[dependencies]
guest-sdk.workspace = true

#![no_std]
#![no_main]

extern crate alloc; // Vec, Box, String, BTreeMap, over the SDK's allocator

use alloc::vec::Vec;

guest_sdk::entry!(main);

fn main() {
    let input = guest_sdk::public_input();
    let mut out = Vec::with_capacity(input.len());
    out.extend(input.iter().rev());
    guest_sdk::commit(&out);
}

把 "my-app" 加入 guests/Cargo.toml 的 members，然后在客户程序自己的目录下构建：cargo build --release --target riscv32imac-unknown-none-elf。

底层运行着什么#

客户程序 SDK 就是全部运行时。它小到可以完整列出：

• 启动。 _start 位于 0x0001_0000，即 .text 的第一个字节。它让 sp 指向 RAM 顶端，逐字节将 .bss 清零，然后调用 main。entry!(f) 导出的那个 main 是对你的函数的包装；你的函数不带参数，返回 ()。
• 退出。 从 main 返回即为 exit(0)。guest_sdk::exit(code) 以任意状态结束运行。非零状态表示执行失败，而失败的执行仍然可以被证明：陈述带有这个状态，验证者会读取它。
• Panic。 panic 处理程序以状态 101 退出，不写出任何内容。没有诊断输出流。发生 panic 的客户程序，在 panic 之前提交的内容依然已经发布。
• 堆。 一个 bump 分配器从紧挨 .bss 之上的 __heap_start 向上增长。它从不释放内存。参见堆。
• 系统调用。 客户程序发出的 ecall 只有 EXIT，以及 SDK 替你发出的委托调用。输入、证明者提示（advice）和输出都是内存，用普通的加载和存储指令读写。

内存布局#

客户程序所见的整个 32 位地址空间：

代码是静态的。每个 pc 处的指令都取自程序的解码表，从不取自 RAM，所以向 .text 写入会改变之后的加载读到的内容，但不会改变执行的指令。

堆#

分配器向上推进一个指针，dealloc 什么也不做。对于一个每个周期都要耗费证明时间的短程序，这是正确的设计，而它也改变了你写 Rust 的方式：

• 让你耗尽内存的是分配总量，而不是峰值。 一个每轮迭代都构建并丢弃一个 Vec 的循环，每次都会消耗新的堆空间。
• 复用缓冲区。 把分配提到循环之外；用 clear() 清空后重新填充，而不是重新分配；用 with_capacity 为会增长的集合预设容量，让它们在增长时不必重新分配和复制。
• 上限是退出状态 71。 一次分配如果末端会高于 0x7F80_0000，或高于当前的栈指针，就以状态 71 退出，而不是返回空指针或覆盖栈。

// Allocates a fresh Vec per record: total heap grows with the record count.
for record in records {
    let fields: Vec<&[u8]> = record.split(|b| *b == b',').collect();
    handle(&fields);
}

// One buffer, reused: total heap is the largest record's field count.
let mut fields: Vec<&[u8]> = Vec::with_capacity(16);
for record in records {
    fields.clear();
    fields.extend(record.split(|b| *b == b','));
    handle(&fields);
}

栈有 8 MiB 的预留区，在其中深度递归没有问题。没有任何机制能察觉的情况是：堆已经填满了预留区下方的空间，栈又越过了预留区，这时堆块会在深层调用链之下被改写。让递归保持有界，或者改写成迭代。

依赖#

任何不依赖 std、能为 riscv32imac-unknown-none-elf 构建的 crate 都可以用。实践中：

• 关闭默认特性（default-features = false），并在 crate 提供 alloc 时启用它。
• 引入 getrandom、时钟，或带随机种子的 std::collections::HashMap 的 crate，在这里没有任何来源可用。这样的调用会得到 -ENOSYS，并使这次运行无法被证明。优先使用 BTreeMap，或者使用固定、确定性哈希器的哈希表。
• 浮点运算会编译成整数软件例程，因为目标没有 F 或 D 扩展。它正确且确定，但每次运算都要花费许多条指令。整数或定点运算更便宜。
• 哈希和椭圆曲线运算有专用电路。使用 SDK 的函数或 vendored crate，让你的依赖能用上这些电路：委托。

先在宿主机上测试#

客户程序不打印任何东西，所以调试在宿主机上进行。让这件事变得容易的布局是：把程序写成一个从字节到字节的 #![no_std] 库；让 main.rs 只负责把字节搬进、搬出各个内存区域；并且只在客户程序目标上依赖 SDK：

[package]
name = "my-app"
version.workspace = true
edition.workspace = true
publish.workspace = true

[target.'cfg(target_arch = "riscv32")'.dependencies]
guest-sdk.workspace = true

#![no_std]
extern crate alloc;
use alloc::vec::Vec;

/// The whole application: public input and advice in, journal out.
pub fn run(input: &[u8], advice: &[u8]) -> Result<Vec<u8>, i32> {
    let _ = advice;
    let mut out = Vec::with_capacity(input.len());
    out.extend(input.iter().rev());
    Ok(out)
}

#![no_std]
#![no_main]

guest_sdk::entry!(main);

fn main() {
    match my_app::run(guest_sdk::public_input(), &[]) {
        Ok(journal) => guest_sdk::commit(&journal),
        Err(code) => guest_sdk::exit(code),
    }
}

宿主程序代码随后按路径依赖这个库（就像 crates/emulator 依赖 guests/revm-block 那样），原生运行 my_app::run，再把结果与模拟器对同一输入产生的公开输出相比较（运行与性能分析）。你的逻辑在宿主机上可以用单元测试、调试器和 println!，而客户程序二进制只是包在已测试代码外面的一层薄壳。

汇编与指令集#

解码器恰好接受 RV32IMA 的 59 条指令，以及在加载时展开的压缩（C）指令。在这个指令集之内，内联汇编没有问题。任何超出它的东西，例如 CSR 访问、fence.i、浮点或 RV64 编码，即使永远不会被执行到，也会让整个程序无法登记：推导时会报告 Not all opcodes supported: pc=…。ebreak、跳转到一个没有指令的半字，或者未对齐的半字或字访问，都会使运行终止且不产生证明。

原子指令可以解码，也可以证明，只有一处偏差：sc.w 总是成功，因为这台机器不保存保留（reservation）状态。客户程序编程指南解释了为什么新的客户程序代码根本不应该使用原子操作。

下一步#

远地虚拟机的客户程序（guest）没有文件描述符、没有流，也没有 I/O 系统调用。它的输入和输出是三个内存区域，用普通的加载和存储指令读写，证明绑定其中的两个。

三个内存区域#

let input: &[u8] = guest_sdk::public_input(); // a slice over the input window, no copy
let data: &[u8] = guest_sdk::advice();        // a slice over the advice region
guest_sdk::commit(b"result");                  // appends to the journal

• public_input() 和 advice() 返回的是内存上的切片，不发生任何复制。read_input(buf) 复制 min(buf.len(), input.len()) 个字节并返回实际数量，所以返回值可能小于请求的长度。
• commit 追加数据并维护一个长度字，正是这个长度字让证明绑定一个确切的字节串，而不是一个用零填充的窗口。它宁可以状态 70 退出，也不会让窗口溢出。
• 在没有提供证明者提示的运行中调用 advice()，会导致致命的 OutOfBounds，而不是返回空切片：没有证明者提示的运行根本没有证明者提示区域，也不必为它付出任何代价。

“绑定”是什么意思#

证明所确立的陈述，带有公开输入的字节、公开输出的字节和退出状态。证明表明：在客户程序第一次访问之前，输入窗口存放的恰好是陈述中的输入；客户程序退出时，公开输出窗口存放的恰好是陈述中的输出。这一点依靠的是内存论证，而不是客户程序做的任何事：客户程序不必计算任何哈希，也不必遵循任何约定。

证明者提示则不同。证明者提示区域的初始内容是证明者写进去的任何东西，没有任何东西把它与程序身份、陈述或任何门联系起来。证明只说明：存在某份证明者提示，使程序在这个输入下发布了这份公开输出。这一保证的强度，恰好等于客户程序自己对证明者提示所做检查的强度。

模式：承诺、提供、检查#

输入较大的客户程序，把大部分数据作为证明者提示接收，由公开输入对它做出承诺；在任何由证明者提示推导出的内容进入公开输出之前，先把两者相互核对：

fn main() {
    let want = guest_sdk::public_input(); // 32 bytes: keccak256 of the advice
    let data = guest_sdk::advice();       // the prover's bytes, bound by nothing
    if guest_sdk::keccak256(data).as_slice() != want {
        guest_sdk::exit(1); // refused before anything derived from it is committed
    }
    let sum = data.iter().fold(0u32, |s, b| s.wrapping_add(u32::from(*b)));
    guest_sdk::commit(&sum.to_le_bytes()); // the journal: what the proof publishes
}

这项检查不一定是对整个证明者提示求哈希。它可以是对照输入所携带的根来检查的 Merkle 路径，就像账本示例那样；也可以是对数据的签名；或者是结果本身满足的约束，例如证明者声称的排序顺序，由客户程序用一遍扫描来验证，而不必自己排序。关键在于，用来核对的那样东西必须是受绑定的。

结构化数据#

用 no_std 序列化器对结构化输入编码，例如基于 serde、启用 alloc 特性的 postcard；仓库自己的以太坊客户程序就用它来编码区块见证。两个习惯能让格式保持严谨：

• 使用定宽整数。 用 u32 和 u64，绝不用 usize，它的宽度在你的宿主机（host）和客户程序之间不同。
• 在要紧的地方，坚持每个值只有一种编码。接受尾随字节或非最短变长整数（varint）的反序列化器，会让同一个值对应两个字节串。在唯一性要紧的地方，先解码、再重新编码并比较，以太坊客户程序的 BlockWitness::decode 就是这样做的。

会增长的输出#

公开输出最多容纳 16,380 字节。随工作量增长的输出，例如每笔交易一条记录，没有固定的上界，迟早会以 70 退出。改为发布摘要：边生成记录边对其求哈希，提交 32 字节的结果，再让需要这些记录的一方在原生环境中重新计算并比对。仓库中的无状态以太坊校验器就是这样为整个区块发布一份 43 字节的公开输出。

对于要在以太坊上检验的证明，两个公开值都要保持固定长度。部署的验证者合约是针对一个输入长度和一个输出长度构建的，任何其他长度都会被拒绝（链上结算）。

退出状态#

退出时，除了已经提交的内容之外，不会发布任何东西；而发生 panic 或以非零状态退出的运行，对它所做的事有一份有效的证明。所以验证者先读退出状态，再读公开输出。在链上，验证者合约把预期的状态作为参数，应用传入 0。SDK 自身使用的状态：

自定义的失败代码要避开这些值，就像账本示例使用 1、2 和 3 那样。

证明没有说明什么#

• 没有任何东西规定公开输出的写入顺序，也没有任何东西强制客户程序读取它的输入。证明绑定的是窗口的内容，而不是产生这些内容的访问。
• 证明者提示是可写的。 向证明者提示区域写入就是一次普通的存储。无论写与不写，它都不受绑定。
• 公开输出就是窗口的全部最终内容。 commit 会维持这种格式。直接写这个窗口的客户程序必须自己保持它：一个不超过 16,380 的长度，随后是这么多字节，再之后全是零。

规范对这一切有精确的表述：公开值与证明者提示。

有些计算，用专门为它们构建的电路来证明，要比作为一串 RISC-V 指令来证明便宜得多。远地虚拟机把这些称为委托。委托是一个电路族，由 ecall 调用，证明作用于 RAM 中一个由字组成的帧的某个函数；客户程序（guest）SDK 在普通函数背后替你发出这些调用。你永远不必自己写 ecall。

你调用什么，会用到哪个委托#

这些函数的结果与其软件定义逐位一致。keccak256 是以太坊的 Keccak，而不是 SHA3-256。sha256 遵循 FIPS 180-4。ec_add 使用 Renes、Costello 和 Batina 的完全加法公式（2015，算法 7），因此倍点、P + (−P)、单位元以及任意 Z 都不需要特殊处理。

use guest_sdk::{ec_mul, keccak256, recursion::SECP256K1_GROUPS, ProjectivePoint};

let digest: [u8; 32] = keccak256(b"blockchain-native");

// A point is homogeneous projective (x = X/Z, y = Y/Z), each coordinate eight
// little-endian u32 limbs below the field modulus. The scalar is eight limbs too.
fn times(p: &ProjectivePoint, k: &[u32; 8]) -> ProjectivePoint {
    ec_mul(&SECP256K1_GROUPS, p, k).expect("EC_ADD is implemented on Apogee")
}

库代码同样能用上委托#

客户程序工作空间给三个 crate 打了补丁，使其中的代码在客户程序目标上调用委托，并以上游代码作为回退路径：

依赖这些 crate 的客户程序，会通过 guests/Cargo.toml 的 [patch.crates-io] 自动得到打过补丁的副本。不打补丁时，仅 k256 的域乘法和平方就占了一个主网区块 44% 的周期。secp256k1 签名恢复是普通的 k256 代码，补丁把它变成了委托运算。

委托的成本#

只有当程序链接了某个委托电路族的某个 shim 时，该电路族才成为程序的一部分；调用的成本以该电路族高度的分片计：

• 链接了但从未调用：没有成本。 该电路族已声明，证明零个分片。
• 调用一次：一整个分片。 不论占用率如何，一个分片的成本都按其完整高度计算。
• 大量调用：每次调用的成本很低。 分片高度增长时，其证明只按每个变量增加一轮求和校验（sumcheck）。

代价主要在内存而不是时间：一个 2^18 的 KECCAK_F 分片在前向过程中约占用 42 GiB 的域元素，实测以太坊区块的内存峰值，就是由两个同时处理中的此类分片决定的。

操作数规则#

• 操作数必须小于其模数。 MOD_MUL 或 EC_ADD 的操作数若大于或等于其选择子所指定的模数，就没有证明：执行器会以致命错误 DelegationFrame 拒绝该帧。vendored 的 k256 在调用之前，会先对它惰性约简的域元素做约简。
• 点不会替你检查。 EC_ADD 证明的是公式的算术。一个点是否在曲线上，是调用代码要回答的问题；从证明者提示（advice）中取点的客户程序必须检查这一点。
• 每个多次调用的操作都对应一个 SDK 函数。 一次 keccak 置换是在同一个帧上的 24 次调用，一次 SHA-256 压缩是 16 次，一次点加是 3 次。每次调用只证明自己的那一步，顺序错了也不会被拒绝：它只会算出别的东西。使用会按顺序发出调用的 keccak256、sha256 和 ec_add，而不是原始的 shim。
• 退出状态 72 表示某个委托返回了其 shim 拒绝接受的结果。在远地虚拟机自己的执行器上，格式正确的帧不会出现这种情况。

哪些运算没有委托#

• 任意模数的 EVM MULMOD、MODEXP、BLS12-381，以及上表之外的所有原语，都以普通指令运行。
• 没有任何签名方案或配对作为整体被委托。secp256k1 签名恢复是建立在 MOD_MUL 和 EC_ADD 之上的 k256；BN254 配对是建立在 MOD_MUL 之上的 ark-bn254。
• 委托承担的是运算的核心。填充、海绵结构、分块循环以及标量乘法的阶梯（ladder），都是客户程序代码，以指令的形式被证明。

面向客户程序的签名方案在 v2.0.0 路线图上。

新增一个委托值得吗？#

周期分析器在每份报告中都会为显而易见的候选项定价，给出一个委托最多能省掉多少周期的上限：

removable = max(0, cycles − calls·(4 + 2·frame_words))

cycles 是该类别在这次运行中所占的周期，calls 是进入候选函数的次数，4 + 2·frame_words 是委托之后仍会留下的 shim：帧的存储、ecall 以及结果的加载。它没有计入新电路族分片的成本，所以只能当作上界。运行与性能分析给出了一份报告。

每个委托逐列展开的规范，见委托电路。

构建#

在客户程序（guest）的目录下构建，除了目标之外不加任何参数：

cd guests/my-app
cargo build --release --target riscv32imac-unknown-none-elf     # .../release/my-app
cargo build --target riscv32imac-unknown-none-elf               # .../debug/my-app

ELF 生成在客户程序工作空间唯一的 target 目录 guests/target/riscv32imac-unknown-none-elf/ 中。guests/.cargo/config.toml 会加上两个你永远不必手动输入的链接器参数：

• -T crates/guest-sdk/link.ld，即内存布局，它还定义了启动代码和分配器所用的符号。
• --no-relax。链接器松弛（relaxation）会改写指令序列，并移动其后的每一个地址，而程序身份绑定了这些地址。

没有 runner：远地虚拟机之外没有任何东西能映射客户程序的内存区域，所以 cargo run 无从运行它。客户程序要通过模拟器运行（运行与性能分析）。

构建 profile#

guests/Cargo.toml 把两个 profile 固定为同一语义。它们只在优化级别和依赖的调试断言上有所不同：

Cargo 默认的 release profile 会关闭溢出检查，而在客户程序中，这不是一个性能设置。它会改变陈述：u32::MAX + 1 会提交 00000000 并以 0 退出，而 dev 构建在同一处会 panic，以 101 退出。所以工作空间在两个 profile 中都保持检查开启。依赖的调试断言检查的是该 crate 自身的不变量，正确的依赖在没有断言时计算结果相同，所以 release 关闭它们，省下这部分周期：相当于无状态以太坊客户程序运行周期的 6.8%。

证明 release 构建。 每条执行过的指令都是一行被证明的数据；opt-level = 3 能去掉客户程序映像的四分之一到一半以上；而且每个电路族的代码都必须装进它的解码表：以太坊客户程序的 debug 映像需要 2^22 行的表，release 映像只需 2^20。你发布的程序身份，是 release 映像的程序身份。

可复现性#

同一台机器上的两次干净构建，会产出完全相同的 ELF。两台机器上的构建一般则不会：ELF 在 panic 位置字符串中嵌入了绝对路径，涉及工具链的 core 源码、crates/guest-sdk 和 cargo registry，而客户程序自己的文件则以相对于 guests/ 的路径出现。在别处构建，得到的是另一个映像，以及另一个程序身份。

所以你登记并交付的是一次构建产出的 ELF，而不是构建方法。保留你证明过的那个 ELF，想核对程序身份的人可以从这个 ELF、参数和仪式文件重新计算它。

导出映像#

cargo run -p artifact-dump -- guests/target/riscv32imac-unknown-none-elf/release/my-app --out artifacts

该命令写出 artifacts/my-app.img，即加载后的 ProgramImage 的序列化格式（postcard，无文件头），以及 artifacts/my-app.img.txt：一份根据经带校验的读取器读回的映像生成的报告。它会打印入口点、段数和指令数，以及制品的大小和 SHA-256。如果读回的结果不一致，或者加载器拒绝了该 ELF，它什么也不写。

.img 是程序的静态描述，用于保存和比对差异；下游没有任何东西需要它，因为设置步骤和各种工具接受的都是 ELF。它的 SHA-256 固定的是字节。它不是程序身份。

阅读报告#

压缩指令保留自己的地址和两个字节；下一个 pc 是 pc + 2 还是 pc + 4，只由 len 表明。要看助记符，使用下面的 tables 视图，或者固定版本的反汇编器：

"$(rustc --print sysroot)"/lib/rustlib/*/bin/llvm-objdump \
    --disassemble --no-print-imm-hex -M no-aliases <elf>

not code 半字#

报告中可能出现 ---- not code: 0x00010f9a .. 0x00010f9c, 1 halfword ---- 这样的行。这是普通的编译器输出：LLVM 证明了某个 match 的默认分支不可达，rustc 为这个不可达块生成了 unimp，在 C 扩展下它就是 c.unimp，即全零半字，RVC 中明确定义为非法的编码。加载器把它记录为非指令，然后继续。没有任何 pc 会到达它；如果有，运行会以 NotAnInstruction 终止。

虚拟机将要证明的内容#

cargo run --release -p artifact-dump -- tables <elf> --ptau assets/ptau/ppot_0080_24.ptau

该命令在默认参数下打印映像推导出的 VmConfig：每个电路族的高度、有效行数和解码列。随后打印每条指令的 pc、next_pc、电路族、助记符和各字段。加上 --ptau 和仪式文件，它还会打印程序身份，即验证者要登记的值。快速上手展示了一个真实的例子。

程序身份是一个域元素。它绑定每条指令及其 pc、长度、操作数和类别（kind），映像中每个来自文件的字节（.text、.rodata、.data），入口点，电路族集合，每个高度，代码大小上限和代码版本。它不绑定符号表、.bss，也不绑定任何由执行过程决定的东西。同一个 ELF 在两种高度设置下有两个程序身份。

推导会在以下情况下拒绝，并指出出错的 pc 或大小：

核对构建#

构建到一个全新的 target 目录，再次导出，然后比较：

cd guests/my-app
CARGO_TARGET_DIR=/tmp/fresh cargo build --release --target riscv32imac-unknown-none-elf
cd ../..
cargo run -p artifact-dump -- /tmp/fresh/riscv32imac-unknown-none-elf/release/my-app --out /tmp/again
cmp artifacts/my-app.img /tmp/again/my-app.img
diff artifacts/my-app.img.txt /tmp/again/my-app.img.txt     # differs only in the `source ELF` line

运行客户程序（guest）几乎没有成本；证明它的成本则与它运行的周期数成正比。所以先运行，与你的宿主机（host）构建比较，并在证明任何东西之前先看一看周期分布。

在 Rust 中：模拟器#

emulator::run 在宿主程序代码中，以给定的公开输入和证明者提示（advice）执行一个已加载的映像，不生成证明：

let elf = std::fs::read(elf_path)?;
let image = loader::load_elf(&elf).expect("the ELF loads");
let io = emulator::GuestIo { input: b"hi".to_vec(), advice: Vec::new() };
let run = emulator::run(&image, &io).expect("no fatal error");

assert_eq!(run.exit_code, 0);
assert_eq!(run.io.output, my_app::run(b"hi", &[]).unwrap()); // the host build agrees
println!("{} cycles", run.cycle_count);

run 返回一个 Execution：最终的寄存器、退出状态、周期数和公开值。非零退出状态仍然是一次执行，而不是错误，它通过 exit_code 返回。致命的执行器错误，例如 OutOfBounds、Misaligned 或 NotAnInstruction，以 EmuError 返回，这样的运行没有证明（故障排查）。

模拟器是映像和输入的纯函数：没有时钟、没有随机数、没有线程。相同的输入给出逐周期相同的执行，这也正是证明者能够执行两遍并切出相同分片的原因。

在命令行中：周期分析器#

cargo run --release -p profiler -- elf <elf> [--input <file>] [--advice <file>] [--top <n>] [--json <path>]

它以能容纳客户程序代码的最小表高度，用给定的文件运行客户程序，并打印一份报告。报告中的数字是已执行周期的计数，在任何机器上都相同。

workload
  label                        hello
  guest cycles                 114
  exit status                  0
  journal bytes                13

cycles by semantic workload
  core runtime                             94   82.46%
  unattributed                             20   17.54%

cycles by family
  ADD_SUB_LUI_AUIPC            64
  JUMP_BRANCH_SLT              21
  MEM_WORD                     3
  MEM_SUBWORD                  26

top functions
            94   82.46%          1 calls        94.0 c/call  guest_sdk::commit  [core runtime]
             8    7.02%          1 calls         8.0 c/call  main  [unattributed]

如何阅读这份报告：

• 按电路族统计的周期（cycles by family）就是你要付费的部分。每个有行的电路族，至少要花费一个其高度的分片；一个电路族中的周期越多，它的分片就越多。
• 热点函数（top functions）把每个函数自身的周期记在它名下，包括编译器内联进它的一切，但不包括它调用的函数。调用次数在函数的第一条指令处计数。
• 按语义工作负载统计的周期（cycles by semantic workload）按名称把函数归入十四个类别，例如哈希、签名和核心运行时。未归类部分的占比和助记符分布用来检验这种归类，因为任何符号表都不可能把它们标错。
• 加速候选项（accelerator candidates）为未来版本可能新增的委托定价，给出的是上限：参见委托。

周期分析器还有两个子命令，用于以太坊工作负载：block <stem> 在一份录制好的测试数据上运行 revm 客户程序，record <number|latest> 从 ETH_RPC_URL 录制一个区块并运行它。

降低成本#

通常最划算的顺序：

1. 用 --release 构建。 优化能去掉客户程序四分之一到一半以上的指令。
2. 委托哈希和曲线运算。 使用 guest_sdk::keccak256、sha256、ec_add 以及 vendored 的 k256 和 ark-ff，而不是把软件实现编译进客户程序。
3. 不要在循环中分配。 每次分配都要花费指令，而在 bump 分配器下，它还是你永远收不回来的内存（堆）。
4. 检查，而不是计算。 如果一个结果求出来昂贵、验证起来便宜，例如排序顺序、平方根或一条穿过树的路径，就让证明者把它作为证明者提示提供，由客户程序来验证。
5. 避免浮点运算。 它会编译成软件例程；整数和定点运算要便宜得多。

然后再测一次。周期数精确且可重复，所以每一处改动都会体现为一个数字。

三个调用#

let params = program::ProgramParams::defaults();
let ptau = std::path::Path::new("assets/ptau/ppot_0080_24.ptau");
let srs = srs::Srs::from_ptau(ptau, 22).expect("ceremony");

let setup = host::setup(&elf, &params, srs).expect("registers");          // once per program
let proven = host::prove(&setup, &io, 4).expect("proves");                // at most 4 shards in flight
host::verify(&setup.vk, &proven.block).expect("verifies");

assert_eq!(setup.vk.identity.to_bytes(), registered); // from your own channel, never the proof
assert_eq!(proven.exit_code, 0);

• host::setup 加载 ELF，把它解码为各电路族的表和 VmConfig，在仪式之下承诺设置列，并构建验证密钥。它的成本按程序和高度选择计算，而不是按运行计算。
• host::prove 把客户程序（guest）执行两遍，并证明每个分片（见下文）。它返回一个 Proven：BlockProof、退出码、周期数、公开输出（journal）以及这次运行的报告。
• host::verify 用块（block）所携带的陈述，对照密钥检查该块。它不会拿程序身份或 SRS 摘要与任何东西比较，所以这项比较要由你来做。

快速上手在一个小型客户程序上运行的正是这段代码，并附有真实输出。

验证者必须自己持有的值#

有两个值必须来自证明者无法控制的渠道：

1. 程序身份。 如果对照的是证明者提供的身份，证明只能说明某个程序运行过。验证者登记它所信任的发布版本的程序身份，并与密钥中的程序身份比较。
2. 仪式的 SRS 摘要。 不论密钥自身的点给出什么摘要，密钥都会按这个摘要加载。基于已知 τ 构建的密钥可以打开任何东西，只有把它的摘要与仪式的摘要比较，才能拒绝它。

验证密钥本身可以来自任何人，包括证明者：加载时会根据其自身内容重新计算程序身份和 SRS 摘要，并要求其中的电路与验证者自己的注册表一致。然后读取陈述：先读退出状态，再读公开输出。

高度#

每个电路族都有一个高度，即它一个分片中的行数，从 2^8, 2^12, 2^16, 2^18, 2^20, 2^22 中选取。高度属于程序，而不属于某次运行：每个高度都被绑定进程序身份。

一个有行的电路族，至少要花费一整个其高度的分片，所以短的运行在较小的高度下浪费更少，长的运行在较大的高度下需要的分片更少。解码表还必须足够高，才能覆盖到该电路族的最后一条指令：2^20 可覆盖 1.9375 MiB 代码，2^22 可覆盖 7.9375 MiB。以太坊客户程序对每个高度可选的电路族都使用 2^20 进行证明。

use constants::family;

let mut params = program::ProgramParams::defaults();
for f in 0..7 {
    params.heights[f] = 1 << 20;
}
for f in [family::INIT_TEARDOWN, family::ZERO_WINDOWS, family::ADVICE_WINDOWS] {
    params.heights[f as usize] = 1 << 16; // window 0 is then 256 KiB: the image must fit in it
}

仪式提供的幂次数必须不少于最高的电路族的行数，并且至少为 2^18，以满足通用查找（lookup）表的需要：调用 Srs::from_ptau(path, k) 时，2^k 至少要等于最大的高度。

同时处理中的分片#

host::prove 的第三个参数是 max_in_flight，即同时证明的分片数。它是唯一一个在内存与时间之间权衡的旋钮：

• 内存取决于同时处理中的分片，而不是周期数。每个同时处理中的分片都持有自己的行、前向过程，以及不断增长的证明。最宽的指令电路族的一个 2^20 分片，在前向过程中约占 8.4 GiB；一个 2^18 的 KECCAK_F 分片约占 42 GiB。
• 时间取决于有多少分片并行运行，最多到你拥有的核心数为止。在一个分片内部，工作在所有核心上运行。
• 证明与它无关。 同时处理 1 个和 8 个分片时，得到的块逐字节相同。

在笔记本电脑上从较小的值开始，两个或四个；在服务器上逐步调高，直到限制你的是内存而不是核心数。bench prove 的默认值是 8。

两遍执行#

host::prove 以流式方式工作。它从不持有整个执行轨迹；按每个周期约 300 字节计算，执行轨迹会是系统中最大的对象。

1. 第一遍执行客户程序，每填满一个分片，就承诺它的内存列，保留承诺，丢弃行数据。到退出时，它构建陈述，并抽取所有分片共用的挑战。
2. 第二遍再次执行。模拟器是确定性的，所以切出的分片完全相同。每个分片一到达就被填充、证明并丢弃，只保留它的证明。

这就是为什么证明要花两次执行的时间，而内存以同时处理中的分片为界。流式证明者对此有深入的解释。

保存证明#

host::proof_archive::write_proof(dir, stem, vk, block) 写出四个文件，每个文件都是对应类型的原始字节：

<stem>.vk         the verifying key
<stem>.identity   the key's identity, 64 lowercase hex digits and a newline
<stem>.public     the statement: input, journal, exit status, the execution's record
<stem>.block      the block proof

read_proof(dir, stem) 把它们读回来。.identity 文件记录的是这次运行所声称的身份；验证者仍要与自己的副本比较。verifier 命令行工具可以检查一份归档：

cargo run --release -p verifier -- block <stem>.vk <identity-hex> <stem>.public <stem>.block

全部验证通过时它以 0 退出；以 1 退出时会指出第一处拒绝；用法错误或程序身份格式错误时以 2 退出。它把你传入的程序身份与密钥中的比较，SRS 摘要则取自密钥文件。

当证明失败时#

诚实的证明者永远不会生成无法通过验证的证明，所以一旦失败，要么是它接受了不该接受的输入，要么是存在 bug。打开证明者的调试日志重新构建，然后重新运行：

cargo run --release -p bench --features prover/debug-info -- prove ...
APOGEE_DEBUG=detail <the same run> 2>&1 | tee run.log
grep -E 'FAIL|NOT CANONICAL|UNBALANCED|OVER the|NAMES NO|DISAGREES|NOT LOOPING|ABORTED' run.log

日志会指出失败的分片；self_check FAILED 会指出某一行违反的第一个门，并给出每个操作数的值。工具列出了所有标记。日志只存在于启用了 debug-info 特性的构建中，不会改变证明的任何字节。

下一步：链上结算。

基础证明是由分片证明组成的一个块（block），每个分片证明都是一份 GKR 证明及其承诺：数兆字节的数据和数百个曲线点，任何合约都无法检验。结算分三个阶段压缩它，每个阶段都在仓库根目录下用 bench 运行。

1. 递归树#

节点就是远地虚拟机在证明一个验证者程序。叶节点验证一段连续的基础分片；内部节点验证二到四个子证明；根节点覆盖全部基础分片。每个节点还会把它的分片和子节点所延迟的每个 Mercury 检查折叠成一对点，因此整棵树最终在顶端归结为单个配对断言。

# the base proof as an archive: host::proof_archive::write_proof from your host
# program, or `bench prove ... --out <dir>` for the Ethereum guests
cargo run --release -p bench -- recurse <dir>/<stem> --out <out> --in-flight 4

recurse 写出两个递归程序的密钥，在其上构建叶程序和节点程序的二进制文件，在证明任何东西之前先确定计划（<out>/tree.txt：叶节点至多包含 --leaf 64 个基础分片，其上的节点至多有 --fan-in 4 个子节点），然后逐个节点进行证明。每个节点是一个独立的进程，在证明之前先原生验证其输入，所以错误的输入会被指名拒绝。中断的运行可以恢复：已在 <out> 中的证明会被保留，而计划或程序不同的运行会被拒绝。

基础证明完全不受这些影响。叶节点按基础分片的原样验证它们。

2. 判定器#

根节点仍然是一份 GKR 证明外加数百个点。判定器是一个 Groth16 电路，它像节点那样验证根节点，但不做任何折叠。取而代之，它把以下各项绑定为由合约提供取值的线：两个递归程序的程序身份、基础陈述的退出状态、逐字节的公开输入和公开输出（journal），以及根节点欠下一次配对的每个点及其标量。Groth16 证明携带对所有这些线的一个承诺，合约用自己持有的值来检查它。

Groth16 密钥需要一场仪式。第一阶段就是递归树的承诺所依据的同一个 powers-of-tau 文件。第二阶段专属于这个电路，分两轮贡献进行：

cargo run --release -p bench -- ceremony <out> init          # once per root shape
cargo run --release -p bench -- ceremony <out> contribute    # round 1: alpha and beta, each contributor in turn
cargo run --release -p bench -- ceremony <out> seal
cargo run --release -p bench -- ceremony <out> contribute    # round 2: gamma, delta and eta
cargo run --release -p bench -- ceremony <out> key
cargo run --release -p bench -- decide <out>                 # the Groth16 proof, checked natively and in an EVM

每一份贡献都把某个陷门乘以一个只有该贡献者知道的因子，并用一个 Schnorr 证明记录下来，所以任何状态都只需对照电路和仪式文件就能验证。只要某个陷门的贡献者中有一位是诚实的，这个陷门就无人知晓。各轮的顺序是可靠性的一部分：在任何东西被 delta 或 eta 除之前，alpha 和 beta 就已完成。

decide 写出 decision.constructor 和 decision.calldata：以十六进制表示的部署参数和调用。

3. 合约#

contracts/ApogeeVerifier.sol 只有一个入口：

function verify(
    bytes calldata input,        // the base program's public input
    bytes calldata output,       // its journal
    uint256 exitStatus,          // the status you require, normally 0
    uint256[10] calldata proof,  // Groth16 A, B, C and the bound wires' commitment D
    uint256[] calldata points    // x, y and scalar of each point, side [1]_2's then side [x]_2's
) external view returns (bool);

它根据 calldata 重建被绑定的值，检查 Groth16 配对等式，用 ecMul 和 ecAdd 折叠每一侧的点（这同时要求每个点都在曲线上），然后检查折叠后的断言 e(A, [1]_2) = e(B, [x]_2)。应用合约调用它，然后根据公开输出采取行动：参见账本草图。

一次部署固定了什么#

构造函数接收 Groth16 密钥、仪式的两个 G2 点、叶程序和节点程序的程序身份、每一侧的点数，以及公开输入和公开输出的字节长度。所以一个已部署的验证者服务于：

• 一个基础程序。 它的程序身份是叶程序映像中的一个常量，而叶程序的程序身份绑定了这个映像。
• 一种根的形状。 判定器的电路取决于根节点的程序、它的分片数和公开值的长度，所以密钥及其仪式都是按形状区分的。
• 定长的公开值。 verify 会拒绝任何其他长度的输入或公开输出。要把客户程序（guest）设计成链上公开值具有固定大小，例如一条定长记录或一个 32 字节的摘要。

合约为每个点支付约 9,000 gas，因为电路一个点也不折叠。

实测数据#

第 257,510 号区块；递归树在一台 32 CPU、247 GiB 内存的机器上运行，仪式和判定器在一台 18 核笔记本电脑上运行：

这一切的规范见递归与判定器。

编写客户程序（guest），大部分时候就是在写 Rust。本页讲的是其余部分：一台裸机、单 hart、需要被证明的机器，在哪些地方与你习惯的宿主机（host）表现不同。每条规则都说明该怎么做、为什么，以及不这样做会出什么问题。AI 随行手册以一种可以直接交给模型的形式，收录了同样的规则。

类型与内存#

usize 是 32 位，所有指针也是#

客户程序的目标是 riscv32imac：usize、isize 和所有指针都是 32 位宽，而在你的宿主机上它们是 64 位。

• usize 溢出在客户程序上会 panic，在宿主机上则不会。
• 在客户程序上，从 u64 做 x as usize 会静默截断。
• 任何包含长度或指针的东西，其 size_of::<T>()、结构体布局和 core::hash 在两种构建之间都不相同。

应当：在你要提交、哈希、序列化或与宿主机计算结果比较的任何东西中，使用显式的 u32 和 u64。在值可能装不下的地方用 usize::try_from(x) 转换，让它在两种构建上都明确地报错。不要：提交 usize，对包含它的结构体求哈希，或者派生依赖内存布局的编码。

let n = u64::from_le_bytes(input[..8].try_into().unwrap());
let len = usize::try_from(n).expect("length fits the guest"); // not `n as usize`

分配器从不释放内存#

堆是一个 bump 分配器：alloc 把一个指针向上移动，dealloc 什么也不做，内存只有在程序退出时才会归还。所以，让客户程序耗尽内存的，是它在整个运行期间分配的总量，而不是峰值。 如果一次分配的末端会高于栈的预留区，或高于当前的栈指针，客户程序就以状态 71 退出。

应当：

• 分配一次，反复复用：把缓冲区提到循环之外，用 clear() 清空它们，而不是构建新的。
• 用 Vec::with_capacity、String::with_capacity 预先设定集合的容量，让它们在增长时不必重新分配和复制。一个靠逐次 push 增长到 n 个元素的 Vec，还会把它先前那些较小的缓冲区遗留在堆上。
• 优先借用（&[u8]、&str）而不是克隆，优先使用迭代器而不是中间集合。
• 就地处理大块的证明者提示（advice）：advice() 本来就是内存上的切片，无需复制。

不要：在热循环里 collect() 出一个新的 Vec；克隆只读的值；或者在一个映射表清空后就能重新填充的情况下，为每个请求重建映射表。

// Total heap grows with the number of requests:
for req in requests {
    let parts: Vec<u32> = req.chunks(4).map(|c| u32::from_le_bytes(c.try_into().unwrap())).collect();
    process(&parts);
}

// Total heap is one buffer:
let mut parts: Vec<u32> = Vec::with_capacity(MAX_PARTS);
for req in requests {
    parts.clear();
    parts.extend(req.chunks(4).map(|c| u32::from_le_bytes(c.try_into().unwrap())));
    process(&parts);
}

栈有 8 MiB，远端没有任何防护#

栈从 0x8000_0000 向下增长，有一个任何堆块都不得进入的 8 MiB 预留区。在预留区内深度递归没有问题。没有任何机制能察觉的情况是：堆已经填满了预留区下方的空间，栈却越过了预留区；这时堆块会在深层调用链之下被悄无声息地改写。应当：让递归深度有界且可预测，或者用显式的工作列表把深度遍历改写成迭代。不要：递归到一个由不可信输入决定的深度。

只允许对齐访问#

通过未对齐指针进行半字或字访问是致命的，绝不会被拆分处理，这次运行也没有证明。安全的 Rust 永远不会产生这种访问。不要把字节指针强制转换为 *const u32 再解引用；用 u32::from_le_bytes 读取（它会编译成字节加载），或者用 ptr::read_unaligned。

空指针指向空洞#

0x8000 以下的地址不属于任何东西，所以空指针或数值很小的野指针会导致致命的 OutOfBounds，而不是读到垃圾数据。它表现为一次没有证明的运行，而绝不会表现为一个错误的答案。

并发#

原子操作：受支持，但不用于新的客户程序代码#

如果原子操作经由依赖进入了你的客户程序，你需要知道：

• 在单个 hart 上，原子操作只是一次读-改-写。 fetch_add 就是一条做加法的 amoadd.w，没有任何东西能与它交错执行。
• sc.w 总是成功。 这台机器不保存保留（reservation）状态，所以条件存储（store-conditional）总会执行存储，并向 rd 写入 0。编译器为 compare_exchange 生成的 lr.w/sc.w 重试循环不受影响，因为在任何 hart 上首次尝试就成功都是合法的。依赖 sc.w 在没有有效保留时失败的代码，在这里得不到这种失败。这是远地虚拟机唯一偏离 RV32IMAC 的地方。
• fence 什么也不做，内存序（aq、rl、SeqCst）在单个 hart 上也不对任何东西排序。
• 它们会多花一个电路族。 原子操作会把 ATOMICS 电路族加入程序，于是程序至少要证明它的一个分片。

应当：在新的客户程序代码中，用普通变量、Cell 和 RefCell 保存状态。不要：在一个根本没有第二个线程可共享的客户程序中加入 AtomicU32、类似 Mutex 的自旋锁或 Arc。

输入与输出#

先检查证明者提示，再让由它推导的内容进入公开输出#

证明者提示是证明者填写的内存，没有任何东西绑定它。在提交任何依赖于它的内容之前，先把它与证明确实绑定的某样东西核对，例如公开输入中的哈希或 Merkle 根、一个签名，或者结果的某种性质。提交未经检查的证明者提示的函数值，就等于发布一个由证明者选定的值。参见这一模式。

公开值要小，用于链上时还要定长#

输入和公开输出（journal）各自最多容纳 16,380 字节。commit 宁可以 70 退出，也不会溢出。大的输入应放进证明者提示，并以承诺加以约束；会增长的输出则应以摘要发布。验证者合约是针对一个输入长度和一个公开输出长度构建的，所以要在以太坊上结算的客户程序应当发布定长的公开输出。

想清楚失败是什么样子#

以非零状态退出或发生 panic 的客户程序，对它所做的事依然有一份有效的证明，而验证者先读退出状态，再读公开输出。为每一种拒绝分配一个专属的退出码，并避开 SDK 使用的那些（70、71、72 和 101）；在可能拒绝某份未经检查的数据的检查完成之前，不要提交任何由这份数据推导出的内容。

没有外部世界#

客户程序没有时钟、没有随机数、没有网络、没有文件，也没有环境变量。向宿主程序索取其中任何一样的库调用，都会得到 -ENOSYS，并使这次运行无法被证明。给 HashMap 一个确定性的种子，或者使用 BTreeMap；算法需要随机性时，从输入中推导；时间则作为输入传进来。

成本#

每条执行过的指令都是一行被证明的数据#

证明成本取决于周期数，按电路族分别计算。用 --release 构建，用周期分析器测量，像嵌入式程序员对待字节那样对待周期。

有电路的运算，交给委托#

keccak256、sha256、椭圆曲线加法和乘法、Poseidon2、BN254 域运算以及 256 位模乘都有专用电路。通过 guest_sdk 以及 vendored 的 k256、ark-ff 和 revm-precompile 使用它们，而不是把软件实现编译进客户程序。参见委托。

验证，而不是计算#

当一个结果求解昂贵、检查便宜时，让证明者去求解并作为证明者提示传入，再由客户程序检查：排序顺序、因数分解、逆元、穿过树的路径、搜索结果。

避免浮点运算#

目标没有 F 或 D 扩展，所以 f32 和 f64 会编译成整数软件例程。它们正确且确定，但每次运算都要花费许多条指令。使用整数或定点数。

高度按整个分片计价#

一个有行的电路族，不论填了多少行，至少都要花费一个其高度的分片。只用到某个电路族一次的程序，也要为一整个分片付费；你的代码用到的电路族以及你选择的高度，决定了每份证明的成本下限。参见高度。

代码与程序身份#

指令流就是映像#

代码是静态的：每个 pc 处的指令都取自加载时构建的解码表，从不取自 RAM。向 .text 写入改变的是数据，而不是行为；跳转到没有指令的半字会使运行终止且不产生证明。没有 JIT，也没有自修改代码。

任何位置的一个非法字都会让整个程序被拒绝#

解码器会处理整个 .text，不论是否可达。内联汇编中的 CSR 访问、fence.i、浮点或 RV64 编码，或者被汇编进 .text 的数据，都会让推导拒绝整个程序。ebreak 可以解码，但没有证明。

溢出检查是程序的一部分#

客户程序的 profile 在 release 中保持 overflow-checks 开启，因为关掉它会改变客户程序计算的内容：u32::MAX + 1 会回绕并以 0 退出，而不是 panic。在确实需要的地方使用 wrapping_*、checked_* 和 saturating_*。

一次构建就是一个程序身份#

程序身份绑定代码和数据的每个字节、入口点和每个高度。在另一台机器上重新构建会得到另一个程序身份，因为 ELF 嵌入了绝对路径。登记并交付你证明过的那个 ELF，而不是生成它的命令。

检查清单#

在证明之前：

• 为 riscv32imac-unknown-none-elf 执行 cargo build --release，并已审阅周期分析器的周期报告
• 提交、哈希或序列化的任何东西中都没有 usize
• 热循环中没有分配；会增长的集合已用 with_capacity 设定容量
• 你自己的客户程序代码中没有原子操作、锁或 Arc
• 每一处对证明者提示的使用，都在任何依赖它的提交之前，与证明所绑定的某样东西核对过
• 公开输出有上界；若要在链上结算，则为定长
• 哈希和曲线运算都经由委托完成
• 每种拒绝都有各自不同的退出码
• 对于你的测试输入，宿主机构建与模拟器得出的公开输出一致
• 已从你将要交付的 ELF 记录下程序身份

客户程序（guest）可能在六个环节止步，得不到通过验证的证明。先找到症状，再找到对应的行。

运行以意料之外的状态退出#

运行已经结束，并且可以被证明；是客户程序自己选择了失败。SDK 自身使用的状态：

其他任何状态都来自你自己的 exit(code)。

运行因致命错误而停止#

模拟器返回一个 EmuError，既没有退出状态，也没有证明：

ELF 被拒绝#

对于加载器无法接受的 ELF，artifact-dump、host::setup 和各种工具都会以 LoaderError 拒绝：

程序无法登记#

ELF 能够加载，但程序无法被解码为一个配置：

如果程序用到的某个电路族被设置在其下限以下（指令电路族为 2^20，RAM 窗口电路族为 2^16），密钥也会构建失败，因为那里不存在电路。

证明者失败#

诚实的证明者在证明模拟器执行过的内容时不会失败，所以失败意味着它接受了不该接受的输入，或者存在 bug。大多数情况属于以下两种：

• 没有证明的调用。 某个库为获取宿主机数据而发出的、EXIT 和委托之外的系统调用，会得到 -ENOSYS，运行继续进行，但证明者在填充时会拒绝那一行，并指出对应的周期。找出那个索取随机数或时间的依赖。
• 内存不足。 进程在分片处理过程中被杀死。调低 host::prove 的第三个参数，或者降低高度。

其他情况，打开证明者的调试日志重新构建，然后重新运行：

cargo run --release -p bench --features prover/debug-info -- prove ...
APOGEE_DEBUG=detail <the run> 2>&1 | tee run.log
grep -c 'begin h=' run.log; grep -c 'gkr done' run.log     # unequal: a shard died
grep 'begin h=' run.log | tail -1                           # which one
grep -E 'FAIL|NOT CANONICAL|UNBALANCED|OVER the|NAMES NO|DISAGREES|NOT LOOPING|ABORTED' run.log

self_check FAILED 会指出该行第一个不满足的门，以及每个操作数的值。调试日志列出了所有标记。

验证失败#

verify_shard 和 verify_block 返回一个 VerifyError，它的类别说明了哪里出了问题：

如果证明是由远地虚拟机自己的证明者、根据模拟器接受的一次执行生成的，那么验证失败意味着验证者和证明者对程序的认识不一致：检查你加载的是否就是生成该证明时所用的密钥，高度是否相同，仪式是否相同。

程序身份不符#

你计算出的程序身份与预期的不同：

• 另一台机器上的构建。 ELF 嵌入了绝对路径，所以在别处重新构建得到的是另一个映像。要与被证明的那个 ELF 比较，而不是与一次新的构建比较。
• 不同的高度。 每个高度都被绑定进程序身份。artifact-dump tables 报告的是默认高度下的程序身份；你的设置可能用了别的高度。
• 另一场仪式。 Hermez 的 powers-of-tau 文件对应的是另一个 τ，所以每个承诺都不同。把文件的 [τ]_1 与该仪式的值核对。

guests/ 工作空间包含代码仓库构建和测试的所有客户程序（guest）。每一个都是为了检验某样东西而存在的，这使它们成为你即将编写的模式的最佳参考。它们都可以在各自的目录下用 cargo build --target riscv32imac-unknown-none-elf 构建。

从这里开始#

应用模式#

委托#

机器本身#

最小的实用客户程序#

fib 读取一个 u32，用回绕算术执行同样多步的斐波那契迭代，然后提交结果：

#![no_std]
#![no_main]

guest_sdk::entry!(main);

fn main() {
    let mut n = [0u8; 4];
    assert_eq!(
        guest_sdk::read_input(&mut n),
        4,
        "fib: the public input is one u32"
    );
    let n = u32::from_le_bytes(n);

    let mut a: u32 = 0;
    let mut b: u32 = 1;
    for _ in 0..n {
        let next = a.wrapping_add(b);
        a = b;
        b = next;
    }
    guest_sdk::commit(&a.to_le_bytes());
}

输入过短是错误，而不是默认值：在一个只填了一部分的缓冲区上继续执行的客户程序，证明的是一个关于零的陈述。加法有意采用回绕，所以大于 47 的 n（超出了能放进 32 位的最后一项）是一个有普通答案的普通输入，而不是一次失败的运行。这里也没有证明者提示，因为对验证者来说，检查 f_n 和计算它的成本一样高：通过证明者提示给出的答案，必须重新计算一遍才能让人相信。

crates/guest-sdk 是客户程序（guest）的全部运行时：启动代码、入口宏、分配器、panic 处理程序和 ecall shim。它只为 riscv32imac-unknown-none-elf 编译。

入口#

guest_sdk::entry!(main);

导出启动代码所调用的 main 符号，它是调用你的函数的包装；你的函数不带参数，返回 ()。你的函数保留自己的名字，它本身也可以叫 main。从它返回即为 exit(0)。

内存区域#

哈希#

椭圆曲线#

pub type ProjectivePoint = [[u32; 8]; 3];

齐次射影坐标下的一个点，x = X/Z，y = Y/Z，每个坐标是八个小端序的 32 位 limb，数值小于曲线的域模数。它不是雅可比（Jacobian）坐标：arkworks 的 Projective 才是，所以从它转换的调用方，传入时映射为 (X·Z, Y·Z², Z)，传出时映射为 (X·Z, Y, Z³)。单位元是 (0 : 1 : 0)。

公式证明的是算术，而不是点是否在曲线上：从证明者提示中取得的点，要自己检查。

原始委托 shim#

guest_sdk::recursion 包含作用于按字对齐的帧类型的各个 shim。每个帧类型都是 #[repr(C, align(4))]，所以它的对齐由类型决定，而不取决于代码生成器把局部变量放在了哪里。基础格式的 shim 恰好在 -ENOSYS 时返回 false；任何其他非零应答都以 72 退出。

每个 shim 从其电路族的声明记录中读取自己的 ecall 编号；声明记录是一个 12 字节的 static，位于它自己的链接器段中。链接一个 shim 就声明了相应的电路族；已声明但从未调用的电路族证明零个分片。

运行时行为#

透明委托#

代码仓库中有两个库 crate 在客户程序目标上进行委托而无需显式指名 SDK，靠的是只在该目标上生效的对 SDK 的依赖：

• field::Fr：加法、Montgomery 乘法（*、square、pow 以及各种转换）和非零元素的 inverse 都调用 FR_ARITH。使用 Fr 算术的客户程序会声明该电路族。
• transcript::poseidon2_permute 调用 POSEIDON2。

vendored 的 k256、ark-ff 和 revm-precompile 为 secp256k1、BN254 和 EVM 预编译合约做了同样的事：委托。

这一切之下的 ABI 规范见客户程序 ABI。

面向远地虚拟机编写的代码，很多会由模型起草。一个从没见过远地虚拟机的模型，会写出一个看似合理的客户程序（guest）：使用 std，在每个循环里分配内存，顺手用上原子计数器，信任它的证明者提示（advice），还提交一个 usize。AI 随行手册是一个 Markdown 文件，预先载入防止这些错误所需的一切：客户程序是什么、硬性规则、SDK 完整的公开接口及其确切签名、可以照抄的模式、各种错误及其修复方法，以及一份审查清单。

如何使用#

• 在对话中：在描述你想构建的东西之前，先附上这个文件，或者把它作为第一条消息粘贴进去。
• 在编程智能体中：把它保存到项目根目录，使用你的工具按惯例读取的文件名，例如 AGENTS.md 或 CLAUDE.md，或者把它加入该工具的项目规则。智能体随后会在每次会话开始时读取它。
• 用于审查：让模型对照文件第 8 节的审查清单，逐行检查一个客户程序。

这个文件用 MUST 和 MUST NOT 来陈述规则，每条旁边都附有理由，因为对于明确且有解释的约束，模型遵循得比需要自行推断的惯例更可靠。

包含的内容#

它着重强调的规则#

随行手册重申了本手册的规则，其中有三条值得特别指出，因为模型最常在这些地方出错：

• 指针和 usize 是 32 位。 主要在 64 位代码上训练的模型，会不假思索地序列化 usize。于是客户程序和宿主机得出的字节就不一致了。
• 堆从不释放内存。 惯用的 Rust 写法随意分配内存，因为真正的分配器会把内存还回来。在这里，每一次分配在剩余的运行期间都是永久的，所以随行手册要求处处复用缓冲区、处处使用 with_capacity。
• 原子操作能编译，但不属于新的客户程序代码。 支持它们是为了兼容现有的库。在单个 hart 上它们不同步任何东西，还会给证明增加一个电路族。

给直接阅读本文档的智能体#

• /llms.txt 以 Markdown 形式索引本站的每一页，供浏览网页的模型使用。
• /docs/llms-full.txt 是合成一个文件的全部英文文档，规范也包括在内。
• 每一页都有一个 以 Markdown 查看 链接和一个 复制为 Markdown 按钮，位于标题下方和右侧栏中。

英文是本文档的标准语言，随行手册在所有语言版本中都以英文发布：英文是模型遵循得最可靠的语言，也是规范的写作语言。

远地虚拟机证明 RV32IMAC 程序的执行。本节在大组件的层面描述这个系统：每个组件做什么、为什么这样构建，以及它如何把工作交给下一个组件。审计专区则在每一列、每一个门的层面呈现同一个系统。

一份证明陈述什么#

验证者持有三样不凭证明者一面之词获得的东西：

• 程序身份，一个域元素，是程序的指令表、初始内存映像、入口 pc 和配置的摘要；
• 仪式的 SRS 摘要，验证密钥必须带有这个摘要；
• 一个验证密钥，它可以来自任何人，因为加载它时会根据其自身内容重新计算程序身份和 SRS 摘要，并要求其中的电路与验证者的注册表一致。

证明的陈述带有公开输入、公开输出（journal）、退出状态，以及这次执行的形状记录：分片数、内存窗口、最终的寄存器和 pc，以及每个分片的内存承诺和根。一份通过验证的证明确立的是：具有该身份的程序，在其映像上从入口 pc 启动，输入窗口中存放该公开输入，并带有某份由证明者选择的证明者提示（advice），逐条指令执行直至以该状态调用 EXIT，且已写出该公开输出。对证明者提示不作任何断言，也没有任何东西被隐藏：没有任何承诺或证明经过盲化。

从二进制到合约调用#

1. 程序。 加载器把 ELF 读入一个 ProgramImage，并在原位展开压缩指令。解码器把每条指令路由到七个指令电路族之一，为每个电路族构建解码表（代码的每个半字一行），然后把这一切承诺为程序身份。程序与身份。
2. 执行。 模拟器在单个 hart 上运行客户程序（guest）。一个周期就是其指令所属电路族中的一行，记录对 pc、寄存器和 RAM 带时间戳的读写。哈希和大整数运算被委托出去：一个 ecall 指明 RAM 中的一个帧，由某个委托电路族的一行在这个帧上完成计算。执行、电路族与分片。
3. 分片。 一个电路族的行被切分为若干分片，每片的行数等于该电路族的高度，即 2^8 到 2^22 之间的某个 2 的幂。一次执行所触及的内存由窗口电路族的分片覆盖，它们给出每个字的初始值和最终值。分片是证明的单位；一个块（block）有数百个分片。
4. 分片的证明。 它的各列用 Mercury 承诺。GKR 引擎把电路族的电路从输出反向运行到这些列，每层一次求和校验（sumcheck）；所有列都在这一过程终止的那个点上打开，合为一次批量打开。
5. 块。 BlockProof 由陈述及其分片证明组成。验证时运行一次全局 transcript，逐一运行每个分片的检查，再在所有分片的根上做一次内存核对。
6. 递归与结算。 由远地虚拟机自己证明的验证者程序，逐段验证连续的分片，并折叠它们被延迟的配对。这些程序构成的树终止于一个根节点，一个 Groth16 电路重新验证根节点，ApogeeVerifier.sol 则检查这份证明以及折叠后的配对。递归与结算。

证明者把客户程序执行两遍：第一遍承诺每个分片的内存列，从而固定陈述及其挑战；第二遍在每个分片填满时证明它。它的内存以同时处理中的分片为界，而不取决于执行的长度。流式证明者。

塑造它的设计决策#

一个域，一条曲线。 一切都建立在 BN254 的标量域上：电路、transcript、承诺和递归。正因如此，递归树的节点才能用自身的算术验证基础分片，整棵树也才能终结于一份由以太坊用其配对预编译合约检查的 Groth16 证明。

用分层 GKR 电路，而不是已承诺的约束表。 电路族的电路是叠在其已承诺列之上的一摞 2 次门层。只有最底层被承诺；其上的每一层都在一次反向过程中由求和校验证明，从不承诺。这一过程结束时，每个已承诺列都在同一个点上有一个断言，所以一个分片恰好只需一次打开。GKR 引擎解释了为什么这是该引擎最核心的节省。

常数大小的打开。 Mercury 用八个曲线点和六个域元素打开一个多线性承诺，共 704 字节，与多项式的大小无关，也与有多少列共享这个点无关。它的检查形如 e(A, [1]_2) = e(B, [x]_2)，递归可以折叠这种检查，而不必计算配对。

整个执行只有一个内存论证。 每个电路族的每个分片中的每次访问，都是同一个读/写多重集中的一个元组，验证者对每个陈述只核对一次各个乘积。pc 是这个多重集中的一个单元，所以跨分片的顺序、连续性和周期唯一性都不需要别的论证，也没有哪个分片需要与相邻分片衔接。

委托是电路族，而不是指令。 昂贵的函数拥有自己的电路族，通过一个作用于 RAM 帧的 ecall 调用，并经由同一个多重集与其请求一一配对。指令电路因此保持精简，客户程序只为它实际调用的委托付费。

流式处理，而不是物化。 按每个周期约 300 字节计算，执行轨迹会是系统中最大的对象，所以它从不存在。证明者执行两遍，只持有正在处理的分片。

不借用外部密码学。 域、曲线、配对、MSM、哈希、多项式承诺、GKR 和 Groth16 都在仓库内实现，并逐页写成规范。arkworks、Plonky3 和 zkhash 只作为测试参照（oracle）出现。

可靠性如何组合#

每个分片的 GKR 过程和打开，把其电路的输出与已承诺列联系起来。在此之上，以下论证贯穿整个执行：

挑战来自 Poseidon2 双工 transcript。全局 transcript 在内存挑战产生之前吸收整个陈述，包括每个分片的内存承诺；每个分片的 transcript 都以全局 transcript 的最终状态为种子。可靠性地图把每一行断言一直追溯到证明它的章节。

代码，按层划分#

验证者是唯一受信任的一方：证明者不做任何校验，错误的输入只会让诚实的证明者得到一份无法通过验证的证明。安全模型确切列出了可靠性依赖哪些 crate。

在任何东西执行之前，远地虚拟机先把客户程序（guest）二进制变成程序的一份固定描述：它的映像、按电路族归类的指令、证明时所依据的配置，以及承诺这一切的一个域元素。每一步都是其输入的纯函数。

加载#

加载器接受静态的 32 位小端序 RISC-V 可执行文件，要求其可加载段位于客户程序 RAM 内的偶数地址上、两两不相交，并且至少有一个可执行段。它只读取程序头的类型、偏移、大小和可执行位，别的一概不读：这台虚拟机没有分页，也没有权限，无论各段声明了什么，整个 RAM 都可寻址。

随后它逐个半字扫描每个可执行段。二进制以 11 结尾的半字开始一条 4 字节指令；全零半字是非指令（LLVM 用它填充不可达的基本块）；其余的都是压缩指令，在原位展开为 32 位形式。地址从不紧缩：位于 0x1002 的 c.addi 留在原处并占两个字节，因此链接器解析出的每个地址都依然成立，而下一个 pc 是 pc + 2 还是 pc + 4，只由指令的长度记录。

扫描即使失去同步，也无法让错误的指令变得可证明。一个槽位是其自身 pc 处字节的函数，所以每个指令槽位都正是 hart 在那里取指时会解码出的内容。让扫描偏离真实边界的数据只会造成两种结果：丢失真实的指令起点，使这些 pc 在表中没有对应的行；或者遇到一个无人认领的编码，从而拒绝整个映像。

解码与路由#

解码器只接受 32 位字，并且恰好接受 RV32IMA 的 59 条指令：基础指令集 40 条，M 扩展 8 条，A 扩展 11 条。其余一切，从 RV64 编码、浮点到 CSR 和 fence.i，都是解码错误；可执行代码中任何位置只要有一个无法解码的字，无论是否可达，程序都会被拒绝。每条指令都被路由到七个指令电路族中的恰好一个：

这种分组依据的是电路之间共享的部分。一个比较 gadget 为每种分支和每种 slt 确定有符号与无符号的大小关系；一个乘积恒等式同时服务于全部四种乘法和除法；任一方向的移位都是与一个查表所得的 2 的幂的一次乘积。

解码表#

每个指令电路族都有一张解码表，即它的设置列：第 i 行对应 pc 2i，在表所覆盖的地址空间中每个半字一行。有效行以元组 pc, next_pc, rs1, rs2, rd, imm, extra_mask 存放该电路族的一条指令，其中掩码以一个比特指明助记符。其余每一行都是填充行，每个字段都是 −1，所以有效行永远不会是填充行，全零的行也永远不会成为 pc 0 处一条可被声称的指令。

每个周期的行都以自己的 pc 在其电路族的表中查找自身。正是这次查找把一次执行与程序绑定在一起：一行的指令就是程序在该 pc 处的指令，而在任何表中都没有有效行的 pc 无法被可证明地执行。代码因此是静态的。对 .text 的存储会改变之后的加载读到的内容，但永远不会改变执行的内容。

配置#

程序的静态形状就是它的 VmConfig：它用到的电路族（每个都有一个高度），以及代码大小的上限。电路族集合不是选出来的，而是推导出来的：

• 映像中含有某个指令电路族的指令时，该电路族就存在；
• 负责内存初始化与收尾的五个窗口电路族总是存在；
• 委托电路族在映像声明它时存在，声明的方式是一条 12 字节的记录：链接该委托的 shim，就会在映像的字节中留下这条记录。

电路族的高度是它一个分片中的行数，从 2^8, 2^12, 2^16, 2^18, 2^20, 2^22 中选取。每个高度都是 2 的偶数次幂，因为 Mercury 打开要求如此。高度是程序的参数，而不是某次运行的参数；每一种高度选择都构成一个独立的程序。

程序身份#

程序身份是 Fr 中的一个元素：对代码版本、VmConfig、入口 pc 以及每个电路族的设置承诺所做的 Poseidon2 摘要；这些设置承诺是对解码表和映像初始内存字的 Mercury 承诺。

它绑定：扫描找到的每条指令及其 pc、长度、操作数和类别，以及其他 pc 上都没有指令这一事实；映像中每个来自文件的字节，其中包括委托声明；入口 pc；电路族集合、每个高度、代码大小上限和代码版本。它不绑定：仪式和通用查找（lookup）表，它们由 SRS 摘要覆盖；电路，加载密钥时会要求它们与验证者的注册表一致；任何由执行过程选择的东西；以及 ELF 中加载器不读取的任何内容，例如符号表。

计算程序身份需要仪式提供的幂次，用来做承诺。检查它则只需要这些承诺，而验证密钥带有它们：加载密钥时会根据它们重新计算程序身份，每个分片的打开也会对照同样的这些点检查其设置列。正是这一点，把证明读取的表与验证者所登记的程序身份联系在一起。

规范见程序与身份。

机器#

模拟器在单个 hart 上、基于一个 ProgramImage 运行 RV32IMAC，没有中断，也没有特权级。一次运行是映像及其输入的纯函数，没有时钟、随机数或线程，所以两次运行切出的分片完全相同。它与宿主环境中的 RV32IMAC 有三处不同：sc.w 总是成功；未对齐的半字或字访问是致命错误，而不会被拆分；指令流就是加载时解码的映像。

运行在到达 EXIT 之前停下的其他所有情形，例如访问映射区域之外的地址、ebreak，或者跳转到一个没有指令的半字，都是致命错误，不产生执行轨迹。这样的运行没有证明。非零退出状态不是错误：它和其他任何执行一样，是一次可证明的执行。

时钟与查询#

周期 c 占据四个时间戳 4c + Δ，每个槽位 Δ ∈ {0, 1, 2, 3} 一个。每条指令是一个周期，除此之外没有任何东西是周期：委托调用搭乘发起它的那个周期。周期从 1 开始编号，因为时间戳 0 是每个地址的初始写入。时钟为 38 位，所以一次执行最多运行 2^36 − 1 个周期。

每次内存访问都是一次查询：读取一个在某个更早的时间戳上最后写入的值，并在当前时间戳上写入。只读的查询会写回它读到的值。每个周期的槽位 0 是 pc 查询，它读取 pc 并写入 next_pc。随后是该指令在固定槽位上的寄存器查询和内存查询：

地址分属不同的空间：32 个寄存器、按 4 字节对齐的字编址的 RAM、pc、每种委托类型各一个锚点空间，以及递归格式的域单元。x0 在执行轨迹中是一个普通寄存器，在机器中则是一个常量：对它的每次查询都读写 0。

二十三个电路族#

电路族是一个电路及其所证明的行。电路族分为四类：

每个周期都归入这样一个执行电路族：其解码表认领该周期的 pc。各电路族在时间上交错：ADD_SUB_LUI_AUIPC 可能拥有周期 1 和 3，JUMP_BRANCH_SLT 拥有周期 2。没有任何东西要求它们连续，因为内存论证按 pc 写入为每一行排序。

窗口电路族之所以存在，是因为内存论证要求一次执行触及的每个地址都恰好有一个初始值和一个最终值。INIT_TEARDOWN 覆盖 RAM 窗口 0，以程序映像作为其初始内容；ZERO_WINDOWS 覆盖这次运行触及的普通 RAM 的其他每个窗口，初始为零；两个公开窗口电路族覆盖输入窗口和公开输出（journal）窗口；ADVICE_WINDOWS 覆盖证明者提示（advice）区域，以证明者的字节作为初始内容。

分片#

一个电路族的行按出现顺序被切分为若干分片，每片的行数等于该电路族的高度。最后一个分片用全零行填充，电路在构建时就保证接受这样的行。不论占用率如何，一个分片都按其完整高度计算成本，所以程序触及哪些电路族、选择哪些高度，决定了每份证明的下限。

每个分片都由其电路族的电路独立证明，内存论证除外：每个分片的电路输出其读元组之积与写元组之积，验证者在陈述的所有分片上对这些乘积做一次核对。这是把各分片联系在一起的唯一纽带。不存在逐分片的 pc 衔接，相邻分片之间也没有共享边界。

在默认高度下，分片证明的大小从公开窗口的约 12.5 KB 到 POSEIDON2 分片的 665 KB 不等；指令电路族的分片证明为 64 至 77 KB。性能页面给出了完整的表。

规范见执行轨迹、电路与注册表。

远地虚拟机中的每个分片都以同一种方式证明：使用其电路族的电路，这个电路写成一摞层，由 GKR 引擎从电路的输出反向运行到其已承诺列。本页讨论为什么这个引擎位于系统的核心，以及为什么它所属的这一类证明系统，正是证明技术前沿推进的方向。

基本思想#

证明一项计算的经典做法，是把它排成一张表，承诺每一列（包括中间值），再证明一组约束在整张表上为零。承诺是其中昂贵的部分：每个被承诺的列都要花费一次多标量乘法或一棵 Merkle 树，还要在约束论证问到的每个点上做一次打开。

GKR（得名于 Goldwasser、Kalai 和 Rothblum）改变了必须承诺的内容。计算被表示为一个分层电路。只有最底层，也就是输入，才被承诺。其上的每一层都由作用于下一层的门定义，证明者从不承诺它。取而代之的是：关于顶层的断言，经一次求和校验（sumcheck）归约为关于其下一层的断言，再归约到更下一层，直到这些断言全部落在已承诺的输入上，并且都位于同一个随机点。一次打开就能了结它们。

这给 zkVM 带来的好处：

• 中间值不花费任何承诺。 电路族的电路可以计算数百个内部列、乘积树和分式树，它们无一被承诺。被承诺的只有执行轨迹列。
• 每个分片一个打开点。 反向过程结束时，每个已承诺列都在同一个点上有一个断言。无论有多少列，一个分片都恰好只需一次批量打开，704 字节。
• 证明者的工作是域运算。 每一层的求和校验在 Fr 上进行，耗时与该层的大小成线性关系，每层都不需要承诺、变换或哈希。
• 论证在电路内部组合。 内存论证的大乘积和查找（lookup）的 LogUp 求和，只是同一个电路中更多的层，在同一个过程中归约。

电路族的电路，逐层来看#

最底层是分片的已承诺列，分为三种，区别在于何时被绑定：M，内存列，在任何内存挑战产生之前于陈述的全局 transcript 中承诺；W，见证列，在分片自己的 transcript 中承诺；S，设置列，由程序身份或仪式绑定。它们旁边是虚拟表：诸如行索引或 16 位范围这样的闭式表达式，验证者可以在任意点上对其求值，它们从不被承诺。

在第 0 层之上，每个电路族的电路都有相同的结构：

1. 门列表 0 逐行计算内存叶子（每个查询的读元组和写元组）、查找分式（每个查找一个 (numerator, denominator) 对，另加表本身的一对），以及每个约束门：电路族的约束，每一个都是必须在每一行上为零的多项式。
2. 逐行列表合并兄弟叶子：乘积树把元组相乘，分式树按 (n_a·d_b + n_b·d_a, d_a·d_b) 把分式相加，直到每一行的每棵树只剩一个节点。
3. 折半列表按分片高度的每个变量各有一个，把各行两两合并：前一半与后一半。经过 n 个折半列表后，电路到达一个没有变量的顶层：分片的读根、写根，以及每个查找通道最终的分子和分母。

所以一个电路在一个过程中同时证明电路族的约束、计算它对内存论证的贡献，并对它的查找求和。每个门的次数至多为 2，所以每次求和校验的每个轮多项式都是三次多项式。

反向过程#

证明者自下而上把每一层物化一次。随后证明自上而下进行，它的 transcript 时序对每个电路都相同：

1. 输出首先被吸收，这样在任何挑战产生之前，证明者就已被这些根绑定。
2. 对于从第 k + 1 层到第 k 层的每次转换，一个挑战 λ 把第 k + 1 层上的每个断言，连同该列表的每个约束门，批量合成一个和。一次求和校验把这个和归约为在随机点 ρ 上的一个求值，每个变量一条三次多项式消息。
3. 证明者给出第 k 层各列在 ρ 上的值。对于折半列表，它给出两个子节点的值，再由另一个挑战 τ 把它们合并为每列一个断言。
4. 到第 0 层时，每个已承诺列都有一个断言，全部位于同一点 u。

分片唯一的那次 Mercury 打开，对照各承诺证明这些断言：内存列的承诺取自陈述，见证列的取自分片证明，设置列的取自验证密钥。虚拟表由验证者自己求值。

约束门可以免费搭车。约束门断言自己处处为 0，所以它加入其所在转换的批次；一旦某个门被违反，批量和以压倒性的概率不为零。一个 LayerInconsistency 错误同时涵盖错误的下行断言和被违反的门：批量和无法区分二者，证明也不为区分它们花费任何代价。

为什么它是可靠的#

每个挑战都在它所保护的一切之后抽取：

• 输出点在输出之后抽取，所以证明者无法挑选只在将被检查之处与真实值一致的表；
• λ 在断言和点之后抽取，所以虚假的断言或被违反的门，只有当 λ 恰为某个非零多项式的根时才能幸存；
• 每个求和校验挑战在其所在轮的三次多项式之后抽取，所以错误的三次多项式与真实的三次多项式一致的概率至多为 3/|Fr|；
• τ 在两个子节点的值之后抽取。

对注册表中任一电路在其默认高度下的全部转换求和，可靠性误差保持在 2^14/|Fr| 以下；这里 Fiat–Shamir 基于 Poseidon2 transcript，并在随机预言机模型中分析。

以数据表示的电路#

电路不是代码，而是一个 CircuitArtifact：按名称列出的已承诺列、虚拟表、使用七种门形状的门列表、同一组关系的扁平列表、查找以及填充行，以规范形式序列化。四条法则让每个制品都保持一致的形式：每个操作数在被读取之处都可读；每个列表的宽度由其门推导而来；顶层恰好就是输出；分层的门与扁平关系是同一个约束集。这些法则只在构建制品或加载密钥时运行一次，从不针对每个证明运行。

对任何评估这个系统的人来说，有两点后果值得关注：

• 验证密钥携带自己的电路，验证者要求它们与自己的注册表一致。 程序身份绑定程序；注册表绑定证明该程序的电路。
• 电路可以由第二套实现检查。 checker crate 在不共享构造器代码的前提下，重新实现了各项法则、查找规则和填充约定，并且只通过双方都视为语义权威的那一个门内核对门求值。

代价#

这个引擎用内存换掉了承诺。前向过程以域元素的形式持有每一个内部层：最宽的指令电路族的一个 2^20 分片约占 8.4 GiB，一个 2^18 的 KECCAK_F 分片占 42 GiB，其电路要计算 5,490 个内部列。这就是证明受内存限制的原因，也是高度成为调优参数、流式证明者以同时处理中的分片为内存上界的原因。证明大小只会随每层每个变量增加一轮求和校验而增长：一个 KECCAK_F 分片的证明在 2^18 时为 381,100 字节，在 2^16 时为 373,276 字节，而前者的工作量是后者的四倍。

规范见 GKR 引擎，以及审计专区下每个电路族各自的页面。

远地虚拟机承诺的每一列都是一个多线性多项式，即布尔超立方体上 2^n 个求值构成的表。每一列都用 Mercury（Eagen 与 Gabizon，ePrint 2025/385）承诺和打开，最后以 BDFG20（Boneh、Drake、Fisch 与 Gabizon，ePrint 2020/081）的批量 KZG 打开收尾。规范确定了这些论文没有确定的部分，并增加了两样东西：同一点上多列的批处理，以及由递归树折叠的延迟形式。

承诺#

Mercury 承诺恰好就是把求值表当作系数读取时的 KZG 承诺：在仪式的 τ 的前 n 个幂次上做一次多标量乘法，得到一个 G1 点，64 字节。它背后没有第二套方案。由此得出两条性质，系统的其余部分两者都会用到：

• 它是线性的。 Σ ρ^i·f_i 的承诺就是 Σ ρ^i·cm_i，正因如此，多列才能共享一次打开。
• 零系数不增加任何东西。 用全零行扩展的列保持原有承诺，所以通用查找（lookup）表的三个承诺适用于每一个容得下这张表的高度，它们是仪式的常量。

各列按其整数宽度承诺：比特列、字节列、半字列或字列都走一次以 u32 为标量的 MSM，按 32 位而不是 254 位重新编码，这让承诺执行轨迹保持低成本。

打开#

Mercury 把 s = 2t 个变量的打开点 u 分成两半，用挑战 α 折叠多项式，用一个对称化的见证证明剩下的两个内积，最后在三个点上做一次批量 KZG 打开。对任意大小，证明都是八个 G1 点和六个域元素：704 字节。由此产生一项要求：变量数必须是偶数，这就是为什么可选的每个高度都是 2 的偶数次幂。

验证者做 O(t) 次域运算、规模分别为十个点和两个点的 MSM，以及一次包含两对的配对检查。它检查的两个关系都写成 e(A, [1]_2) = e(B, [x]_2) 的形式，所以两个 G2 参数都是设置中的常量，验证者完全不做 G2 运算。也正是这种形状，让递归可以推迟配对，而不必计算它。

一个分片的所有列，一次打开#

GKR 过程结束时，分片的每个已承诺列都在同一点 u 上有一个断言。所以不需要任何合并断言的求和校验（sumcheck）：打开直接把它们全部批量处理。挑战 ρ 在每个承诺和每个声称值之后抽取，以 ρ^i 为第 i 列加权；证明者对 Σ ρ^i·f_i 打开一次，验证者通过一次 k 点 MSM 构造 Σ ρ^i·cm_i。虚假断言幸存的概率至多为 (k − 1)/|Fr|。

批中的列来自三处，按固定顺序排列，而这个顺序本身也是被证明内容的一部分：内存列的承诺来自陈述，见证列的来自分片证明，设置列的来自验证密钥。正是从密钥中取得设置承诺，才使这次打开绑定了程序身份所承诺的解码表和映像。

延迟验证#

延迟检查执行除配对之外的一切，并把关系中的各项保存为十二个 (side, scalar, point) 条目。递归正是这样使用它的：树的每个节点用自身的算术计算一个分片的十二个标量，用新抽取的挑战为它们加权，并把它们累加进一对持续更新的点 (A, B)。整棵树中每个分片的打开都折叠为一个断言 e(A, [1]_2) = e(B, [x]_2)，最终只由以太坊上的合约检查。递归与结算展示了折叠过程。

实测数据#

在一台 18 核的 Apple M5 Pro 上：

安全性#

在代数群模型中、q-DLOG 假设下，知识可靠性成立；前提是 Fiat–Shamir 基于 Poseidon2 transcript 并在随机预言机模型中分析，且 SRS 的 τ 无人知晓。统计项，即对各挑战应用 Schwartz–Zippel 得到的项，对所用的每个实例都保持在 2^−220 以下，所以安全级别就是 BN254 的安全级别，约 100 位。没有任何部分具备隐藏性，也没有任何部分经过盲化：远地虚拟机 v1.0.0 不是零知识的。

SRS 是 PSE 的 perpetual powers of tau 的第 80 次贡献，只要有一位贡献者是诚实的，它就是可靠的。它的文件会被解码，每个点都要检查是否位于其曲线上、是否属于正确的子群；但没有任何东西能证明一个文件就出自该仪式，所以验证者要把 SRS 摘要与通过自己的渠道获得的仪式 SRS 摘要相比较。

规范见 Mercury、结构化参考串。

电路族的门每次只约束一行。一切跨越行、分片或电路族的内容，例如寄存器存放的值、加载返回的值、一行执行的是哪条指令、一个值是否放得进 32 位，都由两个论证承载，而这两个论证就位于同样的 GKR 电路之中。

内存论证#

每次内存访问都变成一个域元素，即一个元组：

T(AS, ADDR, TS, VAL) = γ + AS + α_addr·ADDR + α_ts·TS + α_val·VAL

它作用于地址空间、地址、时间戳和值，其中的四个挑战每个陈述只抽取一次。一个查询把它的读元组贡献给一侧，把写元组贡献给另一侧。每个分片的电路输出两个数：其读元组之积与写元组之积。然后验证者在整个陈述上检查一个等式：

∏ read roots · R_b  =  ∏ write roots · W_b          over every shard of every family

W_b 和 R_b 是 32 个寄存器和 pc 的初始元组与最终元组，它们没有自己的行：验证者根据陈述携带的 64 个边界标量把它们乘进去。RAM 的初始值和最终值来自窗口电路族的分片，每行存放一个字：窗口 0 中是程序映像，这次运行触及的其他每个窗口中是零，公开输入窗口中是陈述的输入，证明者提示（advice）中是证明者的字节。

如果等式成立，那么两个多重集以压倒性的概率相等。多重集相等意味着每次读取都返回在它之前的最近一次写入：每次读取恰好与一次写入匹配，读取必须严格晚于它所消费的写入，并且每个地址恰好有一次初始写入。

免费得到的顺序#

pc 和其他内存单元一样，也是一个内存单元，位于它自己空间的地址 0。每一行都读取 pc 并写入下一个 pc，其电路要求这次写入至少比读取晚四个时间戳。所以 pc 的历史是一条穿过每个电路族每个有效行的路径，从入口点一直到退出行。这一条路径带来：

• 程序顺序，因为各行按其 pc 写入排序；
• 跨分片、跨电路族的连续性，因为每一行的 pc 读取都消费了某一行的 pc 写入；
• 没有周期被证明两次，因为任何写入都不能被消费两次。

没有哪个分片与相邻分片衔接，也不需要衔接。分片所声称的时间窗口不绑定任何东西，只检查其形状。

什么必须先确定#

内存挑战每个陈述只抽取一次，位于全局 transcript 的末尾，在元组可能读取的一切都已固定之后：每个分片的内存承诺、程序身份（它固定了入口 pc 和映像）、仪式摘要、分片数和窗口列表、公开输入与公开输出（journal）的摘要，最后是 64 个边界标量。在挑战之后才选定的值，可以被反解出来；正是 transcript 的顺序禁止了这一点。出于同样的原因，内存元组只能读取内存列、设置列和虚拟列，绝不能读取见证列，因为见证列是在挑战之后、于分片自己的 transcript 中承诺的。电路构造器会拒绝任何违反这一点的制品。

查找#

查找（lookup）是说：一行中若干值构成的元组，是某张表中的一行。远地虚拟机用 LogUp 证明一个分片的每个查找：每张表（即每个通道）一个恒等式，

Σ_rows Σ_lookups 1/(E(y) + g)  −  Σ_rows mult(y)/(T(y) + g)  =  0

该恒等式由电路族自身 GKR 电路中的分式树求和，并在树根处检查：分子为零，分母非零。重数列完全不需要约束：一个不在任何表行中的元组会留下一个重数无法抵消的极点。

其中三张表是虚拟的：它们是行索引的闭式表达式，由验证者自己求值，不花费任何承诺。通用表用仪式的幂次承诺一次，并由 SRS 摘要覆盖。

解码器查找#

每个执行电路族都为每个有效行在自己的解码表中做一次查找，以该行从内存中读到的 pc 为键。这一次查找就把这个周期绑定到程序：该行的操作数、立即数和指令类别都是程序在该 pc 处的；它的类别位是 one-hot 的，因为表的每个有效行都存放一个 one-hot 掩码，而每个填充行存放 −1，任何类别位之和都达不到这个值。如果程序在某个 pc 处没有指令，位于该 pc 的行根本找不到任何表行。

键必须有界#

通道证明的是属于某张表，仅此而已。几张子表以互不相交的键范围共用通用表，所以一个无界的键可能落进错误的子表，从而证明一个错误的 AND。因此，每个电路族都用同一选择子下的范围查找，为它查找的每个键设定界；电路构造器还会检查：通过缩放因子写出的界，同时也带有直接界。规范针对每个电路族说明了这一规则所防范的攻击。

如何组合起来#

这两个论证与每个电路族的门一起，赋予陈述其含义：每一行都遵循其指令，该指令就是程序的指令，每次读取都看到最近一次写入，各行构成一条从入口到出口的路径，每个值都是它所声称的那个整数，公开窗口存放的是陈述中的字节。可靠性地图把每项断言对应到证明它的章节。

规范见内存论证、查找。

哈希和大整数运算在真实工作负载中占主导：在一个以太坊主网区块中，被委托之前，仅 secp256k1 的域乘法和平方就占了 44% 的周期。逐条指令地证明它们是可行的，但很慢。委托为这样的函数提供一个专属的电路族，由客户程序（guest）调用，这样指令电路保持精简，程序也只为它调用的委托付费。

调用方式#

委托只会被调用，从不被解码。客户程序在 RAM 中写入一个由 32 位字组成的帧，然后发出 ecall，a7 中放委托编号，a0 中放帧的基地址。这个 ecall 是 ADD_SUB_LUI_AUIPC 电路族中的一行，即请求。实际的计算是该委托自身电路族中的一行，即调用：它在发起请求的那个周期读取帧中的每个字，并把每个字（其中包括结果）写回。调用不拥有任何周期，它搭乘发起它的那个周期。

帧按字对齐，并完全位于普通 RAM 中，所以任何帧都不会与公开窗口或证明者提示（advice）区域重叠，帧的读写也都是普通的内存查询。因此，委托计算出的结果与任何一次存储一样受到绑定：经由那唯一的内存多重集。

锚点#

请求与调用必须一一配对：否则多个请求可能对着同一次调用闭合，使一些调用实际上没有执行；或者一次未被请求的调用可能改写某个帧。它们通过同一个内存多重集配对，配对发生在一个锚点空间中，这个空间只属于该委托类型，任何指令都无法触及：

请求一侧的三个门把它的读取固定在时间戳 0、值 0，并使它向 a0 写入 0。于是，时间戳为 0 的元组恰好就是各请求的读取和各调用的应答，所以在相同的基地址上，调用与请求一样多；又因为没有两个请求共享同一个周期，每次调用的读取恰好就是某一个请求的写入。每次调用都位于其请求的基地址和周期上。委托电路中的任何门都完全不必知道请求的存在。

多次调用，一个操作#

一行容纳不下的操作，就在同一个帧上分成几次调用，由帧中的一个字指明是哪一步：一次 keccak-f[1600] 置换是 24 次轮调用，一次 SHA-256 压缩是 16 次各含四轮的调用，一次完全点加是三次调用。没有任何门把两行连接起来。每次调用都在帧的当前状态上证明自己那一步；它的读取位于每个字唯一的那条内存历史上，所以读到的是上一步的写入。每一步都按顺序执行，这要由调用代码来保证，而调用代码是以指令形式被证明的客户程序代码。SDK 用一个函数发出每个多次调用的操作，所以客户程序从不需要手动安排步骤的顺序。

静态声明#

指令扫描看不到调用，因为委托编号是 a7 在运行时的值。所以 SDK 中的每个 shim 都在自己的链接器段中留下一条 12 字节的声明记录，只有当该 shim 可达时，这条记录才会被保留。程序推导过程在映像中扫描这些记录，被声明的电路族加入配置，并通过映像字节受程序身份绑定。已链接但从未调用的电路族证明零个分片；如果被调用的编号所对应的电路族从未被程序声明，就没有证明。

六个电路#

有几种构造在它们之间反复出现。单一编码规则把一个指明 k 种情形之一的帧字解码为布尔选择子，并保证恰好只有一个被置位，因为编码会相加：没有这条规则，选择子 1 和 3 就能应答对 4 的请求。规范性链通过 32 位 limb 上的借位，证明一个 256 位的值小于某个模数。此外，每个被写入的字都被限定在 2^32 以下，使 RAM 中始终都是字，这是每个指令电路族都依赖的前提。

经济性#

委托电路族的高度决定一个分片能容纳多少次调用，而不论占用率如何，一个分片的成本都按其高度计算：

对于调用很多的电路族，更大的分片反而更便宜：KECCAK_F 的证明从 2^16 到 2^18 几乎没有变大。代价是内存。一个 2^18 的 KECCAK_F 分片的前向过程占 42 GiB，同时处理中的两个这样的分片决定了实测区块的内存峰值。

哪些被委托，哪些没有#

库代码通过打过补丁的 k256、ark-ff 和 revm-precompile 副本用上委托：secp256k1 签名恢复变成建立在 MOD_MUL 和 EC_ADD 之上的 k256 代码，BN254 配对变成建立在 MOD_MUL 之上的 ark-bn254 代码。EVM 中任意模数的 MULMOD、MODEXP、BLS12-381，以及所有作为整体的签名方案，都以普通指令运行。面向客户程序的专用签名支持，是 v2.0.0 演进方向的一部分。

规范见委托 ABI、委托电路。

一个完整的以太坊区块约有 2 亿个周期。它的执行轨迹，即每个电路族的每一行和每一个内存事件，每个周期约 300 字节：在承诺任何一列之前就已达到数十 GB。远地虚拟机的证明者从不构建它。它把客户程序（guest）执行两遍，只持有正在处理的分片。

两遍执行#

第一遍执行客户程序，每填满一个分片，就承诺它的内存列，保留承诺，丢弃行数据。退出时，它从最终的内存状态推导出陈述所需的其余一切：寄存器与 pc 的边界、这次运行触及的内存窗口列表，以及窗口电路族的分片。随后它运行全局 transcript：吸收陈述（包括每一个内存承诺），并抽取内存挑战，以及作为每个分片种子的摘要。

第二遍再次执行。模拟器是其输入的纯函数，所以切出的分片完全相同，第二遍还会断言自己的周期分布、窗口列表和边界与第一遍相同。每个分片都得到它的全部已承诺列并被证明：它的 transcript、它的 GKR 过程、它的打开。内存列不会被重新承诺：打开从陈述中取得它们的承诺，从第二遍取得它们的值，所以如果两遍之间某些列不一致，得到的打开会被验证者拒绝。

这个顺序是可靠性所强制的。内存挑战必须在内存元组可能读取的每个值之后产生，所以每个分片的内存列都要在任何分片能够被证明之前承诺。

流水线#

固定数量（max_in_flight）的工作线程共用一把保护执行器的锁。持有锁时，工作线程交回已完成的分片并认领下一个：如果有已填满的分片在等待，就认领它；否则它自己推进执行器，直到某个缓冲区填满。在锁外，它构建该分片的列、证明它，然后丢弃它。

• 执行器从不超前于需求运行。 每个电路族至多有一个已填满、未被认领的分片以行的形式等待。
• 在一个分片内部，工作是数据并行的，分布在所有核心上。阻塞在这项工作中的工作线程不会再接第二个分片。
• 块（block）不依赖于调度。 分片的证明是全局状态和它自身各列的函数；证明按其在陈述中的位置放置。同时处理 1 个和 8 个分片时，得到的字节完全相同。
• 失败是确定性的。 无论工作线程有多少，返回的都是按填充顺序最早的那个失败。

成本#

内存由以下几部分构成：每个电路族一个未填满的缓冲区、最近访问表、正在处理的分片，以及输出。一个分片的工作集以其前向过程为主，即以域元素形式存放的每个 GKR 内部层：一个 2^20 的 SHIFT_BITWISE 分片为 8.4 GiB，一个 2^18 的 KECCAK_F 分片为 42 GiB。所以 max_in_flight 决定了有多少个这样的工作集同时存在，而高度决定了每个有多大。

在第 257,510 号区块（60 笔交易，101.5 Mgas，198M 个周期，207 个分片）上实测，机器为 32 vCPU、247.7 GiB 内存，同时处理十二个分片：

峰值来自某一个委托电路族的高度，而不是十二个同时处理中的分片。这就是可调节之处：Keccak 调用更少的区块，或者把 Keccak 设在更低的高度，峰值就更低。

规范见流式证明者。

一个以太坊区块的基础证明由 207 个分片证明组成：14.5 MB，每个分片都是一份 GKR 证明，带着它的承诺，以及一次以配对检查收尾的 Mercury 打开。合约无法直接检查其中任何一项。递归负责压缩它，而递归的做法，是仅次于 GKR 引擎本身的、影响最深远的设计选择。

基础证明保持不变#

第一个决定，是递归不做什么。没有任何基础密钥、陈述或证明为了支持递归而改变：叶节点验证基础分片的方式，与原生验证者完全相同。递归所需的一切都添加在基础证明之上，从不进入其内部。同一个块（block）的同一份字节，可以原生验证，可以递归，也可以两者兼做。

远地虚拟机证明它自己的验证者#

树的节点就是远地虚拟机在证明一个验证者程序。叶节点验证一段连续的基础分片，从 from 到 to；内部节点验证二到四个子节点，每个子节点都是叶程序或节点程序的一份完整证明；根节点覆盖全部基础分片。每个节点都由证明基础块的同一个流式证明者来证明。

把 Rust 验证者作为 RISC-V 指令运行是可行的，实测验证一个区块的 207 个分片需要 30 亿个周期：是该区块本身的十五倍。所以节点改为在递归格式中运行。

递归格式#

当且仅当一个陈述的程序声明了域电路族时，该陈述采用递归格式。该格式增加一个地址空间和基于它的四个协处理器电路族，全部通过普通的委托 ABI 调用，除此之外不做任何改变：

另有两处改动，让父节点验证递归分片的成本更低。它的内存列和见证列以至多 2^24 个求值的堆叠形式承诺，所以父节点只需折叠少数几个点，而不是数百个。此外，递归请求写回的帧基地址会越过该帧向前推进，所以首尾相接排布的帧可以作为首尾相接的 ecall 重放，每次调用一行。

Tape#

对给定的电路族和高度，一个分片的检查具有固定的形状。所以宿主程序（host）把它们一次性编译成一条 tape：一个作用于绝对单元地址的直线式协处理器调用列表，其中没有任何东西根据值来分支。分片的 tape 与原生验证者对该分片执行的步骤逐个调用对应：分片 transcript、GKR 反向过程、查找（lookup）与根的检查，以及 Mercury 打开的十二个标量。每项检查都是一次断言相等。

每个递归程序的 tape、折叠模板和常量，都在编译时由验证者 crate 自己构建，并放进程序的只读数据中。因此，程序身份绑定了该程序重放的每一条 tape：证明一个节点运行了它的程序，就是证明它恰好运行了这些检查。

贯穿整棵树的 transcript 链#

基础陈述的全局 transcript 是覆盖整个陈述的一个海绵。递归树把它拆开，但不改变它。持有分片 0 的节点运行前缀部分，直到公开输入摘要为止；每个节点从其前驱留下的状态继续，吸收它自己那些分片的内存承诺；持有最后一个分片的节点运行后缀部分，并抽取内存挑战，而这些挑战此前在每个节点中都被当作断言接受。节点的公开输出（journal）记录链在其区间两端的状态，父节点要求其各个子节点的状态首尾相接。

节点还要求它的各个子节点彼此一致：退出状态为 0；同一个基础陈述（其形状、摘要、挑战、输入与公开输出的摘要、退出状态和分片数）；相邻的分片区间；首尾相接的链状态；跨越接缝处按顺序排列的时间窗口；以及递归程序的程序身份。持有整个陈述的节点完成内存论证。

折叠配对#

没有任何节点计算配对。每个分片的 Mercury 检查都被延迟为十二个 (side, scalar, point) 条目；在分片的 tape 之后，节点自己的 transcript 吸收分片 transcript 的最终状态并抽取权重，每个条目经加权后累加进一对持续更新的点 (A, B)，它代表断言 e(A, [1]_2) = e(B, [x]_2)。把分片的组合承诺与其各列联系起来的批量检查，也在旁边一并折叠。一个电路族所有分片共享的点，例如 [1]_1 和设置承诺，各自只累积一个标量，并且只加入一次。子节点的 (A, B) 以一个在其完整公开输出之后抽取的权重加入。

每一侧都是在 FQ_OP 上执行的一次多标量乘法，以静态模板运行：基于 GLV 分解后的两半、采用 8 位数位的 Pippenger 算法，每个点都被约束在曲线上，每一步都事先固定。每个点的成本约为 400 次 FQ_OP 调用。

到了根节点，整棵树的全部内容都已坍缩：每个基础分片都已验证，transcript 已从头到尾运行完毕，内存论证已经完成，每次打开都已折叠成一个配对断言。剩下的只有这个断言和两个程序身份。

判定器#

根节点仍然是一份 GKR 证明加上数百个点，合约无法检查。判定器是一个 Groth16 电路：它通过一个写出秩 1 约束（而不是协处理器调用）的驱动程序，对唯一的子节点，即根节点，运行节点流程，并要求根节点的公开输出对应全部基础分片区间。它不折叠任何东西：根节点欠最终配对的每个点连同其标量，都成为一条绑定线，即由验证者持有的一个值，在证明中以第五个陷门承诺，而不是作为公开输入传递。两个程序身份、基础退出状态，以及逐字节的基础公开输入和公开输出，也都是这样处理的。

远地虚拟机的 Groth16 与教科书版本有三处不同：绑定线承诺、没有盲化，以及证明密钥建立在 powers-of-tau 仪式已经公布的 Lagrange 基之上。它的密钥来自一个两阶段仪式：第一阶段就是承诺所依据的同一个仪式文件；第二阶段专属于这个电路，对 α 和 β 的贡献要在对 γ、δ 和 η 的任何贡献之前完成，而这个顺序本身就是可靠性的一部分。

ApogeeVerifier.sol 根据 calldata 重建被绑定的值，检查 Groth16 等式，用 ecMul 和 ecAdd 折叠两侧的点（这同时要求每个点都在曲线上），然后检查剩下的那一次配对。它的构造函数固定密钥、仪式的两个 G2 点以及两个递归程序的程序身份。一次部署服务于一个基础程序、一种根的形状和固定的公开值长度。

实测数据#

第 257,510 号区块；递归树在一台 32 CPU 的机器上运行，仪式和判定器在一台 18 核笔记本电脑上运行：

规范见递归与判定器。亲自运行一遍：链上结算。

远地虚拟机证明任意的 RV32IMAC 程序。它的参考工作负载，也就是测量和调优所依据的那个，是常见工作负载中最难的一个：在虚拟机内用 revm（Rust 实现的 EVM）校验以太坊区块。同一个库 revm_block 既为客户程序（guest）编译，也为宿主机（host）编译，两个二进制程序证明两个不同的陈述。

两个二进制程序，两个陈述#

真正证明区块的是无状态校验器。它实现了以太坊执行规范中的 verify_stateless_new_payload：解码请求，对照父区块检查祖先区块头和区块头规则，恢复每笔交易的发送者，在一个通过哈希约束到父区块状态根的前置状态上执行每笔交易，处理提款和请求，并重新计算收据根、bloom、gas、请求哈希、区块访问列表和后置状态根。见证本身不需要额外的绑定：公布的根固定了载荷，见证通过哈希受这个根约束，所以错误的见证无法让无效的载荷变得有效。判定结果为 false，只说明这份输入没有通过校验。

分叉与一致性#

校验器根据输入的 schema ID 确定分叉，没有编译进任何激活时间表：Osaka、BPO1、BPO2 和 Amsterdam。tests-zkevm v21.0.1 发布版本的全部 67,251 个测试对在原生运行下一致；CI 用一个已提交的、包含 34 个用例的子集约束这个库，该子集在两种输入布局下覆盖了该发布版本涉及的每条规则。

实践中的委托#

两个二进制程序都声明了 KECCAK_F、SHA256_COMP、MOD_MUL 和 EC_ADD。Keccak 经由 alloy-primitives 的 native-keccak 钩子用到其电路。SHA-256、secp256k1 和 BN254 经由打过补丁的 revm-precompile、k256 和 ark-ff 副本用到各自的电路，每个副本都以上游代码作为回退路径。每个发送者都在客户程序中按 EIP-2 的规则恢复，所用的 k256 算术被补丁路由到 MOD_MUL 和 EC_ADD。

这两个二进制程序以 --release 构建，证明时每个高度可选的电路族都使用 2^20：无状态二进制程序的 .text 约为 1.96 MB，占 2^20 表覆盖范围的 96.6%。

实测区块#

glamsterdam-devnet-8 的第 257,510 号区块，经由 revm-block-stateless：60 笔交易，101.5 Mgas，1.98 亿个周期，切分为 207 个分片。基础证明在一台 32 vCPU、247.7 GiB 内存的机器上耗时 2,481 s，内存峰值 174 GiB；递归另外花费约 2,620 s；合约以 3,620,026 gas 接受了结果。性能逐一拆解了每个阶段。

区块证明不做什么#

• 校验器的输入来自外部的见证生成方。 eth_getProof 返回每个键路径上的 trie 节点，但使某个分支折叠的删除操作，需要一个不在任何已改变键的路径上的兄弟节点。因此仓库中的记录器无法生成无状态输入；这些输入来自 tests-zkevm 发布版本或 zkEVM 基准测试的数据集。
• mini-block 二进制程序证明的是在一个已记录的前置状态上的一次执行，通常是某个区块的前几笔交易，不对状态根作任何断言。它的公开输出每笔交易增加一条记录，最终会超出公开窗口，这就是完整区块要走无状态校验器的原因。

规范见以太坊区块。

证明确立什么#

一份通过验证的证明确立的是：具有给定身份的程序，在其映像上从入口 pc 启动，输入窗口中存放该公开输入，并带有某份由证明者选择的证明者提示（advice），逐条指令执行直至以给定状态调用 EXIT，且已写出给定的公开输出（journal）。对证明者提示不作任何断言。没有任何东西被隐藏。

假设#

BN254 提供约 100 位的安全性。每一层协议的统计误差，从求和校验（sumcheck）和批量打开，到内存论证与查找（lookup）论证，都远低于此：一个电路的整个 GKR 过程低于 2^14/|Fr|，每个查找通道低于 2^−190，每个 Mercury 实例低于 2^−220。

验证者必须自己持有的值#

两个值，都要取自证明者无法控制的渠道：

• 程序身份。 如果对照的是证明者提供的身份，证明只能说明有某个程序运行过。
• 仪式的 SRS 摘要。 不论密钥自身的点给出什么摘要，密钥都会按这个摘要加载，所以基于已知 τ 构建的密钥，只有通过这项比对才会被拒绝。

验证密钥本身可以来自任何人。加载它时会根据其自身内容重新计算程序身份和 SRS 摘要，并要求其中的电路与验证者的注册表一致：程序身份绑定程序，注册表绑定电路。verifier 命令行工具只比较程序身份，SRS 摘要则取自密钥；host::verify 两者都不比较，并且把检查陈述中的输入、公开输出和退出状态的工作也留给调用方。

受信任的代码#

可靠性只取决于验证者。它依赖于 constants、field、curve、transcript、poly、sumcheck、pcs-verify、pcs、gkr-verify、verifier-core、verifier，以及 constraints，因为电路是陈述的一部分，缺失一个门就是可靠性漏洞。从 ELF 计算程序身份还要信任 loader、isa 和 program。上链的最后一步又加入了递归程序、groth16、判定器的电路和合约。

证明者、模拟器、执行轨迹构建器，以及宿主程序（host）SDK 中负责证明的一半，都是不受信任的。证明者不做任何校验；错误的输入只会让诚实的证明者得到一份无法通过验证的证明，而作弊的证明者本来就不会运行这些代码。

不是常数时间的，也不是零知识的#

代码中没有任何部分是常数时间的：约简、幂运算、点加和标量阶梯都会根据操作数分支。这在这里无害，因为没有任何证明是零知识的，证明过程不保有任何秘密。代码处理的唯一秘密，是判定器仪式贡献者的因子，它经过的是同一个非常数时间的阶梯；请在你自己控制的机器上进行贡献。

v1.0.0 的限制#

下一个版本将改变什么#

上面涉及 BN254 的每一个假设，从 q-DLOG、配对到 Groth16，都会被一台足够大的量子计算机攻破。v2.0.0 的演进方向是一个可靠性改为建立在格问题之上的证明核心。

从审计者的视角，逐个 crate、逐个论证地审视同一个模型：审计指南、可靠性地图。

所有端到端数据都来自 glamsterdam-devnet-8 的第 257,510 号区块，经由无状态校验器客户程序（guest）证明：60 笔交易，101.5 Mgas，1.98 亿个周期。每一项数据都来自规范中的测量。

端到端#

基础证明，逐遍拆解#

峰值由某一个委托电路族的高度决定，而不是由同时处理中的分片数决定。

一个小型客户程序#

快速上手中的客户程序，在四个指令电路族中运行 114 个周期，以 2^20 的指令高度和 2^16 的窗口高度、同时处理两个分片进行证明：在一台 18 核、48 GiB 内存的笔记本电脑上，共 7 个分片，耗时 52 s，峰值 18 GB，几乎全部来自正在处理的两个 2^20 分片。证明的下限由其电路族和高度决定，而不是由周期数决定。

每个电路族的分片#

以下均为默认高度下的数据。分片证明的大小由其电路的形状和高度确定；证明成本取决于高度与电路宽度的乘积，不论有多少行是有效行。

高度只改变折半列表的数量和求和校验（sumcheck）的轮数，不改变门：ADD_SUB_LUI_AUIPC 在 2^20 时有 298 个内部列，证明为 57,196 字节，而在 2^22 时分别为 314 个和 64,764 字节。

前向过程的内存#

GKR 证明者以域元素的形式持有每个内部层，每个单元 32 字节。代表性的工作集：

Mercury#

在一台 18 核的 Apple M5 Pro 上：

如何解读这些数字#

证明受内存限制，其内存取决于同时处理中的分片及其高度，从不取决于执行的长度。时间取决于各电路族各自的周期数。链上成本取决于根节点欠最终配对的点数，每个点约 9,000 gas。周期数本身是精确的，且与机器无关，所以要估算其余任何一项，周期分析器都是首选工具。

1.0.0 版回答了这套架构能否在完整规模下成立的问题：一个完整的以太坊区块，从 Rust 客户程序（guest）一路到返回 true 的合约。2.0.0 版改变的是这套架构的根基及其服务对象：证明核心迁移到量子计算机无法攻破的数学之上，面向开发者的部分则从一个代码仓库成长为一个部署应用的系统。

四项举措#

演进轨迹#

延续下来的部分#

跃迁发生在根基上，而不在开发者编程所面对的模型上：

• 客户程序。 Rust、RISC-V、三个内存区域、一个程序身份、一份公开输出（journal）。为 v1.0.0 编写的程序保持原有形态。
• GKR 引擎。 分层电路和求和校验（sumcheck）在任何域上都有定义。这个把整个电路收束到一个点上的引擎，是远地虚拟机中迁移到新域最直接的部分。
• 论证。 覆盖整个执行过程的单一内存多重集，以及 LogUp 通道，都作为构造保留下来；它们的表和范围论证将按新域的大小重新推导。
• 工程纪律。 规范先行；每一层都对照一个独立的参照（oracle）检查；每一类伪造都由一个篡改孪生守住。

为什么是现在#

有效性证明的抗量子能力，取决于产生它的系统。BN254 上的证明建立在配对和离散对数之上，因此一台足够大的量子计算机可以伪造证明，而无须触碰客户程序计算过的任何东西。区块链原生应用要承载数十年的价值。它们赖以结算的根基，必须比那些终有一天会攻破今天这些曲线的机器更长久；而迁移根基的时机，是在那些机器出现之前。

阅读各项举措：后量子证明 · 面向客户程序的签名 · 部署系统。

什么会被攻破，又在哪里#

远地虚拟机 v1.0.0 之下的每一个密码学假设都涉及 BN254。Mercury 和 KZG 在代数群模型中、q-DLOG 假设下是可靠的；递归树折叠的是配对检查；判定器是 Groth16。在规模足够的量子计算机上，Shor 算法能求解离散对数，上述每一个假设也随之失效。客户程序（guest）的计算依然如故，但证明它正确运行的那份证明将不再有任何意义。

这种依赖集中在承诺上。每个分片的每一列都用它来承诺，每次打开都以它的配对收尾，而递归的存在正是为了折叠这些配对。换掉承诺，证明核心的其余部分就再没有任何依赖离散对数的东西。

QL-01 · 格承诺#

格承诺是一个线性映射 t = A·s mod q，作用于一个元素很小的向量 s。只要没有人能找到一个被该矩阵映射为零的短向量，它就具有绑定性：这就是 Module-SIS，ML-DSA 和 ML-KEM 这两项 NIST 后量子标准所依赖的假设族，背后有最坏情况归约和数十年的密码分析支撑。

它保留了 KZG 对远地虚拟机最有用、而基于哈希的承诺所放弃的那一点：它是同态的。 对多个数据块的承诺可以用挑战系数组合起来，组合结果只需一个向量即可打开。批量处理一个分片的各列、延迟检查、沿树向上折叠，都是线性运算，而线性运算在迁移之后依然成立。Merkle 路径则根本无法组合。

代价是一种别处没有的约束：承诺只绑定短向量，每次组合都会让向量变长，证明者必须证明它仍然足够短。近两年的各种方案，主要区别就在于如何支付这一代价，而且进展很快。对于 2^30 个系数的多项式，已发表的 Module-SIS 方案给出的求值证明为 53 至 72 KB，验证时间则从 2024 年的 2.8 秒降到 2026 年的 8 至 16 毫秒。专题文章 Lattice-Based Polynomial Commitment Schemes 逐一梳理了这些方案，并把这些数字与基于哈希的一方对照解读。

QL-02 · 换域#

格方案并不属于 BN254 的世界。主流构造工作在小素数模数上，为保证可靠性，求值点取自扩域；这适合小域证明系统，而不适合 254 位的系统。因此承诺的迁移会把域一并带走：v2.0.0 为算术化换域，把每个电路从 BN254 的标量域迁移到与承诺相匹配的小域上。

这次迁移本身就能收回成本：

• 每一层都更便宜。 GKR 证明者的时间都花在域运算上，而小域中的一次乘法只是 254 位域中一次乘法的零头。该引擎最核心的节省在于中间层从不承诺；这一点与剩下每一层都更便宜的运算叠加在一起。
• 承诺更便宜。 承诺一个执行轨迹列，是对一组小取值数位做一次线性映射，成本按非零项计算，而不是在曲线上做多标量乘法。
• 引擎原样延续。 GKR 和求和校验（sumcheck）在任何域上都有定义。挑战移到扩域上；反向过程、层模型以及建立在其上的各项论证都保持原有结构。

需要重建的，是一切以大域为前提的部分：能宽裕地放进一个 BN254 元素的字级数值、按 254 位模数确定大小的范围论证和进位、规范性链（canonicity chain），以及递归格式中的域单元。每一项都会针对新域重新推导，并像 v1.0.0 的那些部分一样写成规范，配有自己的参照（oracle）和篡改孪生。

结算#

以太坊现有的验证预编译合约都基于配对。后量子证明核心如何在这条链上结算，最后一步中有哪些部分可以建立在格之上，属于同一项工作计划，并会在发布之前以与核心同等的严谨程度写成规范。

返回任务简报。

几乎每个区块链原生应用都会在每次请求时问同一个问题：这是正确的密钥授权的吗？在 v1.0.0 中，客户程序（guest）用代码来回答。secp256k1 公钥恢复由 k256 在委托的 MOD_MUL 与 EC_ADD 电路之上完成，这让以太坊自身的签名变得负担得起；其他任何方案都只能用普通指令执行。QL-03 让签名验证成为客户程序的一等操作。

签名方案#

一个签名方案证明起来便宜与否，几乎完全取决于它的验证算法：做什么运算、在哪个域上做、调用哪个哈希。签名者从不在证明内部运行。以下四种设计覆盖了整个设计空间：

四种验证算法都是“计算后比较”，不涉及秘密，也不依据秘密做分支，正因如此每一种都可以被证明。专题文章 ZK-Friendly Signature Schemes 用玩具示例逐一推演，并比较了它们在电路中的成本。

成本由什么决定#

有两个杠杆决定了每一个数字：

• 证明者所用的域。 一个方案的运算就是电路的运算时，它才是原生的。因此哪个方案最便宜，取决于 QL-02 的换域，方案的选择也将与之一同做出。
• 哈希。 后量子验证算法的成本主要来自其标准哈希，而不是代数运算。换成算术哈希就偏离了标准，这是面向零知识的构造所选择的变体；保留标准哈希，则是与现有密钥互操作的前提。两者各有用武之地，由客户程序决定。

面向开发者#

目标是让客户程序验证授权，就像今天计算哈希一样：一次调用，委托给电路，应用自己的代码里没有任何密码学。这将打开区块链原生应用赖以构建的各种模式：所用密钥并非链上原生密钥的账户、状态转换函数内部的多方审批、会话密钥，以及在其诞生所依托的曲线被攻破之后依然有效的身份。

返回任务简报。

1.0.0 版交给开发者的是一个代码仓库、配套工具和这份手册。从一个已证明的客户程序（guest）到一个上线运行的应用，中间的一切，从密钥和仪式到验证者合约、桥和运维，仍要由开发者自己组装。远地区块链原生化部署系统是这次跃迁的后半程：一套门户与工具链，把客户程序变成运行中的区块链原生环境，并让它持续运行。

模块#