Eine Blockchain-native Anwendung ist wirtschaftliche Aktivität, deren Abwicklung, Verwahrung und Regeln von Grund auf on-chain liegen, und kein herkömmliches Geschäft, an das seitlich ein Token angeheftet ist. Das klingt nach einer anderen Art von Engineering. Der Unterschied ist kleiner, als es klingt.

Jede Komponente des Stacks, den Sie heute bauen, hat ein Gegenstück. Das Gegenstück erfüllt dieselbe Aufgabe mit einer Änderung: Worauf man bisher vertrauen musste, das wird jetzt bewiesen. Apogee existiert, um diese Änderung so günstig zu machen, dass sie zum Standard wird.

Der Wandel in einem Satz#

In einer herkömmlichen Anwendung ist der Server die Autorität: Er hält die Daten, wendet die Regeln an und meldet das Ergebnis. In einer Blockchain-nativen Anwendung hält die Chain ein Commitment auf die Daten, die Regeln sind ein Programm, das jeder über seinen Digest benennen kann, und ein Ergebnis wird nur mit einem Beweis akzeptiert, dass dieses Programm es erzeugt hat.

Der Betreiber verschwindet nicht. Jemand führt weiterhin das Programm aus, speichert die Daten und beantwortet Anfragen. Was verschwindet, ist die Notwendigkeit, ihm zu glauben.

Schicht für Schicht#

Die mittlere Spalte ist das, woraus eine Blockchain-native Anwendung besteht. Apogee liefert die Maschinerie darunter: die RISC-V-Maschine, die Schaltkreise, die Commitments, die Rekursion und den Verifier-Contract. Nichts davon taucht in Ihrem Programm auf.

Was sich nicht ändert#

• Sie schreiben weiterhin gewöhnliches Rust. Structs, Enums, Traits, Iteratoren, Vec, BTreeMap und jedes Crate, das ohne std baut. Es gibt keine Schaltkreissprache zu lernen.
• Sie testen weiterhin auf Ihrem Laptop. Der übliche Aufbau legt die Anwendungslogik in eine no_std-Bibliothek, die auf dem Host unter cargo test genau so läuft wie im Gastprogramm. Siehe Ein Gastprogramm schreiben.
• Sie denken weiterhin in Zustand, Anfragen und Antworten. Die Formen bleiben gleich; nur ihre Garantien ändern sich.
• Deterministischer Code bleibt deterministisch. Guter Backend-Code vermeidet ohnehin versteckte Eingaben. Die VM macht daraus eine absolute Regel.

Was sich ändert#

• Keine Außenwelt. Ein Gastprogramm hat keine Uhr, keinen Zufall, kein Netzwerk und keine Dateien. Alles, was es weiß, kommt als öffentliche Eingabe oder als Hilfsdaten an, und eine Anfrage nach Daten des Hosts ist ein Aufruf, den kein Beweis zulässt.
• Jeder Befehl hat einen Preis. Jeder ausgeführte Befehl wird zu einer bewiesenen Zeile. Kopien, Allokationen und Leerlaufschleifen kosten Beweiszeit; die alte Disziplin des Zyklenzählens kehrt also zurück.
• Gelieferte Daten werden geprüft, nicht geglaubt. Hilfsdaten wählt der Prover. Ein Gastprogramm prüft sie gegen etwas, das der Beweis bindet, bevor irgendetwas daraus Abgeleitetes veröffentlicht wird.
• Ausgaben sind klein und öffentlich. Das Journal fasst höchstens 16.380 Byte. Ein großes Ergebnis wird als Digest veröffentlicht.
• Nichts ist verborgen. Beweise von Apogee v1.0.0 sind succinct, aber nicht zero-knowledge. Ein Gastprogramm darf keine Geheimnisse enthalten.

Ein Hauptbuch, auf beide Arten gebaut#

Eine Einzahlung auf einen Kontostand: die kleinste Zustandsänderung, die einen Beweis lohnt.

Die herkömmliche Version#

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

Die Nutzer vertrauen darauf, dass der Betreiber genau dies ausgeführt hat, gegen die echte Tabelle, und dass er das Ergebnis ehrlich meldet.

Die Blockchain-native Version#

Die Konten liegen in einem binären Merkle-Baum, dessen Blätter keccak256(account ‖ balance) sind. Ein Contract speichert die Wurzel. Das Gastprogramm erhält die alte Wurzel und die Anfrage als öffentliche Eingabe, den Kontostand und den Merkle-Pfad des Kontos als Hilfsdaten, prüft den Pfad und veröffentlicht die alte und die neue Wurzel.

#![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());
}

Lesen Sie es neben dem SQL. Aus SELECT … FOR UPDATE wurde ein Merkle-Pfad, der gegen die Wurzel geprüft wird. Aus UPDATE wurde ein neues Blatt auf demselben Pfad. Aus COMMIT wurden vier Aufrufe von commit, die das Journal schreiben, das der Beweis binden wird. Der Kontostand kam vom Prover, und das ist in Ordnung: Ein Kontostand, den die Wurzel nicht festlegt, scheitert an der Prüfung, und der Lauf endet mit Exit-Status 2.

Der Contract, dem die Wurzel gehört, akzeptiert einen Übergang nur mit einem Beweis, dass dieses Programm ihn erzeugt hat und mit Exit-Status 0 endete:

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]);
    }
}

Das Modell in drei Zeilen#

1. Die Chain hält eine Wurzel.
2. Das Gastprogramm beweist den Übergang.
3. Der Contract schreibt die Wurzel fort.

Alles andere, von den Shards und Schaltkreisen bis zur Rekursion und zum Decider, übernimmt Apogee. Das ist die Abstraktion: ein Programm, seine Eingabe und seine Ausgabe sowie ein Beweis, der sie miteinander verbindet.

Nächste Schritte#

In einem Absatz#

Apogee VM ist eine RISC-V-zkVM. Die VM beweist, dass ein RV32IMAC-Programm, benannt durch einen Digest seines Images, mit einer gegebenen öffentlichen Eingabe bis zu einem Exit-Status gelaufen ist und eine gegebene öffentliche Ausgabe geschrieben hat. Diesen Beweis führt sie über einen Rekursionsbaum zu einem einzigen Groth16-Beweis, den ein Ethereum-Contract prüft. Jeder Schaltkreis ist ein geschichteter GKR-Schaltkreis über dem Skalarkörper von BN254, jede committete Spalte wird mit Mercury geöffnet, und jede Challenge stammt aus einem Poseidon2-Transkript. Körper, Kurve, Pairing, MSM, Hash, Polynom-Commitment, GKR-Prover und Groth16 sind sämtlich im Repository implementiert. Die Referenz-Arbeitslast ist die Validierung von Ethereum-Blöcken.

Die Fakten#

Gemessen#

Alle Zahlen beziehen sich auf Block 257.510 von glamsterdam-devnet-8, ausgeführt im Gastprogramm des zustandslosen Validators: 60 Transaktionen, 101,5 Mgas, 198 Mio. Zyklen. Quellen: Rekursion §10 und Streaming §1 der Spezifikation.

Was ein Verifier besitzen muss#

Zwei Werte, bezogen über einen Kanal, den der Prover nicht kontrolliert:

• Die Programmidentität, ein Körperelement. Gegenüber einer vom Prover gelieferten Identität zeigt ein Beweis nur, dass irgendein Programm gelaufen ist.
• Der SRS-Digest der Zeremonie. Ein Schlüssel, der über einem bekannten τ gebaut wurde, wird nur durch diesen Vergleich zurückgewiesen.

Der Verifikationsschlüssel selbst darf von beliebiger Seite kommen: Beim Laden werden beide Werte aus seinem eigenen Inhalt neu berechnet, und seine Schaltkreise werden mit der Registry des Verifiers abgeglichen. Das Sicherheitsmodell enthält die vollständige Liste der Annahmen.

Wo v1.0.0 endet#

• Nicht zero-knowledge. Keine Verblindung in Mercury, GKR oder dem Decider.
• Hilfsdaten sind ungebunden. Ein Gastprogramm prüft sie gegen etwas, das ein Beweis bindet.
• Traps sind nicht beweisbar. Ein nicht ausgerichteter Zugriff, ein Zugriff außerhalb des gemappten Speichers, ebreak oder ein pc ohne Befehl beendet den Lauf ohne Beweis.
• sc.w gelingt immer. Die einzige Abweichung von RV32IMAC: Es gibt keinen Reservierungszustand.
• Die Delegationen bilden eine feste Menge von sechs. EVM-MULMOD mit beliebigem Modul, MODEXP und BLS12-381 laufen als gewöhnliche Befehle.
• Die Beweiserzeugung ist speichergebunden. Der gemessene Block erreichte eine Spitze von 174 GiB; der Speicherbedarf folgt den gerade bearbeiteten Shards, nicht der Länge des Laufs.
• Der Decider-Schlüssel gilt je Wurzelform und ist nur so vertrauenswürdig wie seine Zeremonie. Der Entwicklungsschlüssel ist fälschbar.

Wer es baut#

Apogee VM ist das Flaggschiff des Forschungsprogramms von G Web3 für Blockchain-native Anwendungsumgebungen: eine optimierte Umgebung pro wirtschaftlicher Anwendung, deren Abwicklung jeweils per Gültigkeitsbeweis auf Ethereum erfolgt. Die Position des Programms ist in der These dargelegt; wohin die nächste Version geht, beschreibt Quantensprung.

Ein Gastprogramm (Guest) ist das Programm, das Apogee beweist: ein no_std-Rust-Binary, kompiliert für riscv32imac-unknown-none-elf, mit einem Einsprungpunkt, drei Speicherbereichen für seine Eingaben und Ausgaben und sonst nichts. Der Host ist alles darum herum: der Code, der die Eingabe liefert, Apogee um einen Beweis bittet und diesen Beweis an denjenigen weitergibt, der ihn prüft. Sie schreiben beides. Apogee liefert die Maschine, die Schaltkreise und den Verifier.

Dieser Abschnitt ist für zwei Leser zugleich geschrieben: einen Entwickler an der Tastatur und das Modell, mit dem er arbeitet. Jede Seite nennt ihre Regeln ohne Umschweife, und der KI-Begleiter verdichtet sie alle in einer einzigen Datei, die Sie einem Assistenten übergeben können, bevor er eine Zeile schreibt.

Das Modell#

Ein Beweis sagt genau eines aus: Das Programm mit dieser Identität, gestartet auf seinem Image mit dieser öffentlichen Eingabe und irgendwelchen vom Prover gewählten Hilfsdaten, ist bis EXIT mit diesem Status gelaufen und hat dabei dieses Journal geschrieben. Alles, was Sie bauen, ruht auf diesem Satz.

Der Ablauf#

Der Schnellstart geht den gesamten Ablauf einmal mit einem Gastprogramm aus drei Zeilen durch.

Die wichtigsten Regeln#

Jede wird im Programmierleitfaden für Gastprogramme erklärt, mit dem, was schiefgeht, und dem, was stattdessen zu tun ist.

• usize und jeder Zeiger sind 32 Bit breit. Ein Überlauf von usize löst nur im Gastprogramm einen Panic aus, x as usize schneidet stillschweigend ab, und alles, dessen Layout oder Hash von einer Länge abhängt, unterscheidet sich zwischen Host und Gastprogramm.
• Der Allokator gibt nie Speicher frei. Er schiebt einen Zeiger ab __heap_start nach oben; was einem Gastprogramm den Speicher ausgehen lässt, ist also die Gesamtmenge dessen, was es über den Lauf alloziert, nicht sein Spitzenbedarf. Verwenden Sie Puffer wieder und dimensionieren Sie sie mit with_capacity.
• Atomics funktionieren, und Sie sollten sie nicht schreiben. Die Maschine hat einen einzigen Hart; die A-Erweiterung ist also für die Kompatibilität mit Code da, der sie bereits verwendet. Neuer Code in Gastprogrammen hat nichts zu synchronisieren.
• Es gibt keine Außenwelt. Keine Dateien, keine Uhr, kein Zufall, kein Netzwerk. Ein Gastprogramm kennt seine öffentliche Eingabe, seine Hilfsdaten und das, was es berechnet.
• Hilfsdaten wählt der Prover. Prüfen Sie sie gegen etwas, das der Beweis bindet, bevor irgendetwas daraus Abgeleitetes ins Journal gelangt.
• Das Journal ist klein. Höchstens 16.380 Byte. Veröffentlichen Sie einen Digest von allem, was wächst.
• Überlaufprüfungen bleiben im Release-Build aktiv. Sie sind Teil dessen, was das Programm berechnet; deshalb legt das Profil der Gastprogramme sie fest.
• Jeder ausgeführte Befehl ist eine bewiesene Zeile. Die Beweiskosten folgen der Zyklenzahl; bauen Sie also mit --release und zählen Sie Zyklen, bevor Sie irgendetwas anderes optimieren.

Wo Sie beginnen#

Diese Seite geht den gesamten Ablauf einmal mit dem kleinsten Gastprogramm (Guest) durch, das etwas tut: Es liest seine öffentliche Eingabe und veröffentlicht sie als sein Journal. Jede Ausgabe unten ist entstanden, indem genau diese Befehle auf Apogee v1.0.0 ausgeführt wurden.

[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

Was gerade passiert ist#

Der Emulator hat die 114 Befehle zweimal ausgeführt. Der erste Durchlauf hat die Speicherspalten jedes Shards committet und die Aussage festgelegt. Der zweite hat jeden Shard befüllt und bewiesen. Es waren sieben Shards: je einer für jede der vier Befehlsfamilien, die ausgeführt wurden, einer für das Speicherfenster, das das Image des Programms enthält, und je einer für die öffentliche Eingabe und das Journal. Dieses Gastprogramm hat seinen Stack nie berührt, also brauchte kein weiteres Fenster einen Shard; bei einem typischen Programm kommt der Shard des Stacks hinzu. Jeder Shard wurde vom GKR-Schaltkreis seiner Familie bewiesen und mit einem einzigen Mercury-Beweis geöffnet, und der Verifier hat die Lese- und Schreibzugriffe auf den Speicher aller sieben in einer einzigen Gleichung abgeglichen. Die Architekturübersicht verfolgt denselben Weg im Detail.

Nächste Schritte#

Apogee v1.0.0 ist ein Rust-Repository. Außer rustup gibt es nichts zu installieren: Das Repository legt seine Toolchain fest, und die Toolchain bringt das Target der Gastprogramme (Guests) mit. Ein Gastprogramm zu schreiben, zu bauen, auszuführen und zu profilieren erfordert nichts weiter. Das Beweisen fügt eine große Datei hinzu und eine Maschine mit entsprechend viel Arbeitsspeicher.

Die Toolchain#

rust-toolchain.toml im Wurzelverzeichnis des Repositorys legt stable Rust 1.96.1 mit rustfmt, clippy und llvm-tools fest, dazu das Target riscv32imac-unknown-none-elf, dessen core und alloc vorkompiliert mitgeliefert werden. rustup wendet diese Festlegung in jedem Verzeichnis unterhalb der Wurzel an und installiert die Toolchain bei der ersten Verwendung.

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

Nirgends werden Nightly oder instabile Features verwendet. llvm-tools liefert die zum LLVM des Compilers passenden llvm-objdump und llvm-nm, die das Repository für seine eingecheckten Disassembly-Listings verwendet und mit denen Sie den Code Ihres Gastprogramms lesen können.

Zwei Workspaces#

Der Checkout enthält zwei Cargo-Workspaces, und die Trennung ist wichtig:

Gastprogramme werden getrennt gehalten, weil jedes Mitglied für das Target der Gastprogramme kompiliert und einen #[panic_handler] linkt; cargo test --workspace in der Wurzel darf sie nie erreichen. Der Gastprogramm-Workspace bringt außerdem mit, was ein Gastprogramm braucht, um korrekt gebaut zu werden, sodass Sie es nie eintippen:

• guests/.cargo/config.toml setzt das Target und übergibt dem Linker -T crates/guest-sdk/link.ld, die Speicherkarte, sowie --no-relax, weil Relaxation Adressen verschieben würde, die die Programmidentität bindet.
• guests/Cargo.toml legt beide Build-Profile auf dieselbe Semantik fest, Überlaufprüfungen eingeschlossen (Bauen und inspizieren).
• Sein [patch.crates-io] leitet k256, ark-ff und revm-precompile auf mitgelieferte Kopien um, die die Delegationen von Apogee aufrufen (Delegationen).

Die Zeremoniedatei#

Jedes Commitment, das Apogee bildet, beruht auf den Potenzen eines geheimen τ aus einer öffentlichen Zeremonie: den Perpetual Powers of Tau der PSE, Beitrag 80. Eine einzige Datei dient jedem Zweck:

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

Sie brauchen sie, um eine Programmidentität zu berechnen, um echte Schlüssel zu bauen und um zu beweisen. Sie brauchen sie nicht, um ein Gastprogramm zu bauen, auszuführen oder zu profilieren, und auch nicht für die Workspace-Tests, die über eigenen Spielzeug-Setups beweisen.

Dateien aus der Zeremonie der PSE sind aus einem einzigen Transkript geschnitten; jede Datei mit Potenz 24 oder mehr ist also geeignet. powersOfTau28_hez_final_*.ptau von Hermez ist eine andere Zeremonie mit einem anderen τ: Der Reader liest sie ebenso bereitwillig ein, und jedes Commitment, jeder Schlüssel und jede Identität darüber fällt anders aus. Damit Sie bestätigen können, dass Sie die richtige Zeremonie haben: Das [τ]_1 der Zeremonie, als Hex seiner kanonischen Kodierung x ‖ y, lautet:

9bbb31bedc304e081e2aada4b56c2217e0e94ee16874e3517d14bef5dcec3a16
317ff1589e53513fa333591b318e8f1e55ef7c37d92beb6d9a61d770a2f39506

Die SRS-Seite der Spezifikation legt genau dar, was der Reader prüft und was er ungeprüft voraussetzt.

Die Maschine#

Bauen und Ausführen sind Laptop-Arbeit. Beweisen ist speichergebunden, und sein Speicherbedarf folgt den gleichzeitig bewiesenen Shards, nicht der Länge des Laufs.

Die Seite zum Beweisen erklärt, wie Höhen und die Zahl der gleichzeitig bearbeiteten Shards Speicher gegen Zeit tauschen: Beweisen und verifizieren.

Ihren Checkout prüfen#

Was die CI ausführt, alles ohne die Zeremoniedatei:

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)

Die Suiten, die echte Shards beweisen, sind mit #[ignore] markiert, weil jede Dutzende GiB braucht. Rufen Sie eine namentlich auf, wenn Sie auf Ihrer eigenen Maschine sehen wollen, wie ein Beweis erstellt und zurückgewiesen wird:

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

Weiter: Ein Gastprogramm schreiben, oder gehen Sie den gesamten Ablauf einmal im Schnellstart durch.

Das Crate#

In v1.0.0 ist ein Gastprogramm (Guest) ein Binary-Crate im Workspace guests/ des Repositorys. Der Workspace liefert das Target, die Linker-Flags, die festgelegten Profile und die mitgelieferten Crates; das eigene Manifest eines Gastprogramms bleibt also kurz:

[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);
}

Tragen Sie "my-app" in members in guests/Cargo.toml ein und bauen Sie aus dem eigenen Verzeichnis des Gastprogramms: cargo build --release --target riscv32imac-unknown-none-elf.

Was unter Ihnen läuft#

Das Guest-SDK ist die gesamte Laufzeitumgebung. Es ist klein genug, um vollständig beschrieben zu werden:

• Start. _start liegt bei 0x0001_0000, dem ersten Byte von .text. Es setzt sp auf das obere Ende des RAM, füllt .bss Byte für Byte mit Nullen und ruft main auf. entry!(f) exportiert dieses main als Wrapper um Ihre Funktion, die keine Argumente nimmt und () zurückgibt.
• Exit. Eine Rückkehr aus main ist gleichbedeutend mit exit(0). guest_sdk::exit(code) beendet den Lauf mit einem beliebigen Status. Ein Status ungleich null ist eine fehlgeschlagene Ausführung, und auch eine fehlgeschlagene Ausführung ist beweisbar: Die Aussage enthält den Status, und ein Verifier liest ihn.
• Panic. Der Panic-Handler beendet den Lauf mit Status 101 und schreibt nichts. Es gibt keinen Diagnosekanal. Ein Gastprogramm, das einen Panic auslöst, hat trotzdem alles veröffentlicht, was es vor dem Panic festgeschrieben hat.
• Heap. Ein Bump-Allokator wächst ab __heap_start, direkt oberhalb von .bss, nach oben. Er gibt nie Speicher frei. Siehe den Heap.
• Systemaufrufe. Die einzigen ecalls, die ein Gastprogramm absetzt, sind EXIT und die Delegationsaufrufe, die das SDK für Sie absetzt. Eingabe, Hilfsdaten (Advice) und Ausgabe sind Speicher, gelesen und geschrieben mit gewöhnlichen Lade- und Speicherbefehlen.

Die Speicherkarte#

Der gesamte 32-Bit-Adressraum, wie ein Gastprogramm ihn sieht:

Code ist statisch. Der Befehl jedes pc stammt aus den dekodierten Tabellen des Programms, nie aus dem RAM; ein Schreibzugriff auf .text ändert also, was ein späterer Lesezugriff liest, aber nicht, was ausgeführt wird.

Der Heap#

Der Allokator schiebt einen Zeiger weiter, und dealloc tut nichts. Das ist das richtige Design für ein kurzes Programm, bei dem jeder Zyklus Beweiszeit kostet, und es verändert, wie Sie Rust schreiben:

• Was Ihnen den Speicher ausgehen lässt, ist die Gesamtmenge Ihrer Allokationen, nicht Ihr Spitzenbedarf. Eine Schleife, die in jeder Iteration einen Vec aufbaut und verwirft, verbraucht jedes Mal frischen Heap.
• Verwenden Sie Puffer wieder. Ziehen Sie Allokationen aus Schleifen heraus, leeren Sie mit clear() und füllen Sie neu, statt neu zu allozieren, und dimensionieren Sie wachsende Collections mit with_capacity, damit sie beim Wachsen nicht neu allozieren und kopieren.
• Die Obergrenze ist Exit 71. Eine Allokation, die oberhalb von 0x7F80_0000 oder oberhalb des aktuellen Stack-Pointers enden würde, beendet den Lauf mit Status 71, statt null zurückzugeben oder den Stack zu überschreiben.

// 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);
}

Der Stack hat seine Reserve von 8 MiB, und tiefe Rekursion innerhalb davon ist unproblematisch. Was nichts erkennt, ist ein Stack, der über die Reserve hinauswächst, nachdem der Heap den Raum darunter gefüllt hat: Heap-Blöcke würden sich dann unter einer tiefen Aufrufkette verändern. Halten Sie Rekursion beschränkt, oder formulieren Sie sie iterativ.

Abhängigkeiten#

Jedes Crate, das ohne std für riscv32imac-unknown-none-elf baut, ist geeignet. In der Praxis:

• Schalten Sie die Default-Features ab (default-features = false) und aktivieren Sie alloc, wo ein Crate es anbietet.
• Ein Crate, das getrandom, eine Uhr oder std::collections::HashMap mit seinem zufälligen Seed einbindet, hat keine Quelle, aus der es schöpfen kann. Ein solcher Aufruf erhält -ENOSYS als Antwort und macht den Lauf unbeweisbar. Bevorzugen Sie BTreeMap oder eine Hash-Map mit einem festen, deterministischen Hasher.
• Gleitkommaarithmetik wird zu Ganzzahl-Softwareroutinen kompiliert, weil das Target keine F- oder D-Erweiterung hat. Sie ist korrekt und deterministisch und kostet viele Befehle pro Operation. Ganzzahl- oder Festkommaarithmetik ist günstiger.
• Hashing und Arithmetik auf elliptischen Kurven haben eigene Schaltkreise. Verwenden Sie die Funktionen des SDK oder die mitgelieferten Crates, damit Ihre Abhängigkeiten sie erreichen: Delegationen.

Zuerst auf dem Host testen#

Ein Gastprogramm gibt nichts aus; das Debugging findet also auf dem Host statt. Der Aufbau, der das einfach macht, hält das Programm in einer #![no_std]-Bibliothek, die Bytes auf Bytes abbildet, beschränkt main.rs darauf, Bytes in die Speicherbereiche hinein und aus ihnen heraus zu bewegen, und macht das SDK zu einer Abhängigkeit allein des Gastprogramm-Targets:

[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),
    }
}

Host-Code hängt dann per Pfad von der Bibliothek ab, so wie crates/emulator von guests/revm-block abhängt, führt my_app::run nativ aus und vergleicht das Ergebnis mit dem Journal, das der Emulator für dieselbe Eingabe erzeugt (Ausführen und profilieren). Ihre Logik bekommt auf dem Host Unit-Tests, einen Debugger und println!, und das Binary des Gastprogramms bleibt eine dünne Hülle um Code, den Sie bereits getestet haben.

Assembly und der Befehlssatz#

Der Decoder akzeptiert genau die 59 Befehle von RV32IMA sowie komprimierte Befehle (C), die beim Laden expandiert werden. Inline-Assembly innerhalb dieser Menge ist unproblematisch. Alles außerhalb davon, etwa ein CSR-Zugriff, fence.i, eine Gleitkomma- oder eine RV64-Kodierung, führt dazu, dass sich das gesamte Programm nicht registrieren lässt, selbst wenn die Stelle nie erreicht wird: Die Ableitung meldet Not all opcodes supported: pc=…. Ein ebreak, ein Sprung auf ein Halbwort ohne Befehl oder ein nicht ausgerichteter Halbwort- oder Wortzugriff beendet den Lauf ohne Beweis.

Atomare Befehle werden dekodiert und bewiesen, mit einer Abweichung: sc.w gelingt immer, weil die Maschine keinen Reservierungszustand führt. Der Programmierleitfaden für Gastprogramme erklärt, warum neuer Code in Gastprogrammen überhaupt keine Atomics verwenden sollte.

Nächste Schritte#

Ein Gastprogramm (Guest) von Apogee hat keine Dateideskriptoren, keine Streams und keinen I/O-Syscall. Seine Eingaben und Ausgaben sind drei Speicherbereiche, gelesen und geschrieben mit gewöhnlichen Lade- und Speicherbefehlen, und der Beweis bindet zwei davon.

Die drei Speicherbereiche#

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() und advice() geben Slices über Speicher zurück; nichts wird kopiert. read_input(buf) kopiert min(buf.len(), input.len()) Bytes und gibt die Anzahl zurück; es kann also weniger liefern als angefordert.
• commit hängt an und führt ein Längenwort mit, und genau das sorgt dafür, dass der Beweis einen exakten Byte-String bindet statt eines mit Nullen aufgefüllten Fensters. Es beendet den Lauf mit Status 70, statt das Fenster überlaufen zu lassen.
• advice() in einem Lauf ohne Hilfsdaten ist ein fataler OutOfBounds-Fehler, kein leerer Slice: Ein Lauf ohne Hilfsdaten hat überhaupt keinen Bereich für Hilfsdaten und zahlt nichts dafür.

Was „gebunden“ bedeutet#

Die Aussage, die ein Beweis begründet, enthält die Bytes der öffentlichen Eingabe, die Bytes des Journals und den Exit-Status. Der Beweis zeigt, dass das Eingabefenster vor dem ersten Zugriff des Gastprogramms genau die Eingabe der Aussage enthielt und dass das Journal-Fenster beim Exit des Gastprogramms genau die Ausgabe der Aussage enthielt. Das beruht auf dem Speicherargument, nicht auf irgendetwas, das das Gastprogramm tut: Es gibt keinen Hash, den das Gastprogramm berechnen, und keine Konvention, der es folgen muss.

Bei Hilfsdaten ist es anders. Der Anfangsinhalt des Bereichs der Hilfsdaten ist das, was der Prover dort hineingeschrieben hat, und nichts verknüpft ihn mit der Programmidentität, der Aussage oder irgendeinem Gate. Ein Beweis sagt aus, dass es irgendwelche Hilfsdaten gibt, unter denen das Programm mit dieser Eingabe dieses Journal veröffentlicht hat. Das ist genauso stark wie die eigenen Prüfungen des Gastprogramms an den Hilfsdaten.

Das Muster: committen, liefern, prüfen#

Ein Gastprogramm mit einer großen Eingabe nimmt den Großteil als Hilfsdaten entgegen, für die die öffentliche Eingabe ein Commitment enthält, und prüft das eine gegen das andere, bevor irgendetwas aus den Hilfsdaten Abgeleitetes ins Journal gelangt:

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
}

Die Prüfung muss kein Hash über die gesamten Hilfsdaten sein. Sie kann ein Merkle-Pfad sein, geprüft gegen eine Wurzel, die die Eingabe mitbringt, wie im Hauptbuch-Beispiel, oder eine Signatur über die Daten, oder eine Bedingung, die das Ergebnis selbst erfüllt, etwa eine behauptete Sortierreihenfolge, die das Gastprogramm in einem Durchgang verifiziert, statt zu sortieren. Entscheidend ist, dass das, wogegen geprüft wird, gebunden ist.

Strukturierte Daten#

Kodieren Sie strukturierte Eingaben mit einem no_std-Serialisierer wie postcard über serde mit dem Feature alloc; genau das verwendet das Ethereum-Gastprogramm des Repositorys für seinen Block-Witness. Zwei Gewohnheiten halten ein Format ehrlich:

• Verwenden Sie Ganzzahlen fester Breite. u32 und u64, nie usize, dessen Breite sich zwischen Ihrem Host und dem Gastprogramm unterscheidet.
• Bestehen Sie auf einer einzigen Kodierung pro Wert, wenn es darauf ankommt. Ein Deserialisierer, der überzählige Bytes am Ende oder nicht minimale Varints akzeptiert, lässt zwei Byte-Strings für einen Wert zu. Wo Eindeutigkeit zählt, dekodieren Sie, kodieren erneut und vergleichen, wie es BlockWitness::decode im Ethereum-Gastprogramm tut.

Ausgaben, die wachsen#

Das Journal fasst 16.380 Byte. Eine Ausgabe, die mit der Arbeit wächst, etwa ein Datensatz pro Transaktion, hat keine feste Schranke und endet irgendwann mit Exit 70. Veröffentlichen Sie stattdessen einen Digest: Hashen Sie die Datensätze, während Sie sie erzeugen, schreiben Sie das 32-Byte-Ergebnis fest, und lassen Sie jeden, der die Datensätze braucht, sie nativ neu berechnen und vergleichen. Der zustandslose Ethereum-Validator des Repositorys veröffentlicht auf diese Weise ein 43-Byte-Journal für einen ganzen Block.

Für einen Beweis, der auf Ethereum geprüft wird, halten Sie beide öffentlichen Werte auf fester Länge. Der bereitgestellte Verifier-Contract ist für eine Eingabelänge und eine Ausgabelänge gebaut und weist alles andere zurück (On-Chain abwickeln).

Der Exit-Status#

Beim Exit wird nichts über das Festgeschriebene hinaus veröffentlicht, und ein Lauf, der einen Panic auslöst oder mit einem Status ungleich null endet, hat einen gültigen Beweis dessen, was er getan hat. Deshalb liest ein Verifier den Exit-Status, bevor er das Journal liest. On-chain nimmt der Verifier-Contract den erwarteten Status als Argument entgegen, und eine Anwendung übergibt 0. Die eigenen Statuswerte des SDK:

Wählen Sie Ihre eigenen Fehlercodes außerhalb dieser Werte, wie es das Hauptbuch-Beispiel mit 1, 2 und 3 tut.

Was der Beweis nicht aussagt#

• Nichts ordnet die Schreibzugriffe auf das Journal, und nichts zwingt ein Gastprogramm, seine Eingabe zu lesen. Der Beweis bindet die Inhalte der Fenster, nicht die Zugriffe, die sie erzeugt haben.
• Hilfsdaten sind beschreibbar. Ein Schreibzugriff auf den Bereich der Hilfsdaten ist ein gewöhnlicher Schreibzugriff. Ungebunden bleiben sie so oder so.
• Das Journal ist der gesamte Endinhalt des Fensters. commit hält diese Form ein. Ein Gastprogramm, das das Fenster direkt beschreibt, muss sie einhalten: eine Länge von höchstens 16.380, so viele Bytes, dann Nullen.

Die Spezifikation legt all dies präzise fest: Öffentliche Werte und Hilfsdaten.

Manche Berechnungen lassen sich mit einem eigens für sie gebauten Schaltkreis weit günstiger beweisen denn als Folge von RISC-V-Befehlen. Apogee nennt sie Delegationen. Eine Delegation ist eine Schaltkreisfamilie, die eine Funktion über einem Frame aus Wörtern im RAM beweist und über einen ecall aufgerufen wird, und das Guest-SDK setzt diese Aufrufe für Sie hinter gewöhnlichen Funktionen ab. Sie schreiben nie selbst einen ecall.

Was Sie aufrufen und was es erreicht#

Die Funktionen sind bitgenau identisch mit ihren Software-Definitionen. keccak256 ist das Keccak von Ethereum, nicht SHA3-256. sha256 ist FIPS 180-4. ec_add verwendet die vollständige Formel von Renes, Costello und Batina (2015, Algorithmus 7); Verdopplung, P + (−P), das neutrale Element und jedes Z brauchen also keinen Sonderfall.

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")
}

Auch Bibliothekscode erreicht sie#

Der Gastprogramm-Workspace patcht drei Crates so, dass der Code in ihnen auf dem Target der Gastprogramme Delegationen aufruft, mit dem Upstream-Code als Fallback-Pfad:

Ein Gastprogramm, das von diesen Crates abhängt, erhält die gepatchten Kopien automatisch über das [patch.crates-io] in guests/Cargo.toml. Ungepatcht machten allein die Körpermultiplikation und -quadrierung von k256 44 % der Zyklen eines Mainnet-Blocks aus. Die secp256k1-Signatur-Recovery ist gewöhnlicher k256-Code, den die Patches in delegierte Arithmetik verwandeln.

Was eine Delegation kostet#

Eine Delegationsfamilie ist nur dann Teil eines Programms, wenn das Programm einen ihrer Shims linkt, und ein Aufruf kostet Shards der Höhe dieser Familie:

• Gelinkt und nie aufgerufen: nichts. Die Familie ist deklariert und beweist null Shards.
• Einmal aufgerufen: ein ganzer Shard. Ein Shard kostet seine volle Höhe, unabhängig von seiner Belegung.
• Oft aufgerufen: sehr wenig pro Aufruf. Der Beweis eines Shards wächst mit dessen Höhe nur um eine Sumcheck-Runde pro Variable.

Der Preis ist eher Speicher als Zeit: Der Vorwärtsdurchlauf eines KECCAK_F-Shards der Höhe 2^18 hält etwa 42 GiB an Körperelementen, und zwei davon, gleichzeitig in Bearbeitung, bestimmten die Spitze des gemessenen Ethereum-Blocks.

Regeln für Operanden#

• Operanden unterhalb ihres Moduls. Ein Operand von MOD_MUL oder EC_ADD, der den Modul, den sein Selektor benennt, erreicht oder übersteigt, hat keinen Beweis: Der Executor weist den Frame als fatalen DelegationFrame-Fehler zurück. Das mitgelieferte k256 reduziert seine verzögert reduzierten Körperelemente vor dem Aufruf.
• Punkte werden nicht für Sie geprüft. EC_ADD beweist die Arithmetik der Formel. Ob ein Punkt auf der Kurve liegt, ist eine Frage an den aufrufenden Code, und ein Gastprogramm, das Punkte aus Hilfsdaten (Advice) übernimmt, muss sie stellen.
• Operationen aus mehreren Aufrufen sind jeweils eine SDK-Funktion. Eine Keccak-Permutation sind 24 Aufrufe auf einem Frame, eine SHA-256-Kompression 16, eine Punktaddition 3. Jeder Aufruf beweist seinen eigenen Schritt, und nichts weist eine falsche Reihenfolge zurück: Es wird dann schlicht etwas anderes berechnet. Verwenden Sie keccak256, sha256 und ec_add, die die Aufrufe in der richtigen Reihenfolge absetzen, statt der rohen Shims.
• Exit 72 bedeutet, dass eine Delegation etwas geantwortet hat, das ihr Shim zurückweist. Auf dem eigenen Executor von Apogee kommt das bei einem wohlgeformten Frame nicht vor.

Was nicht delegiert wird#

• MULMOD der EVM mit beliebigem Modul, MODEXP, BLS12-381 und jedes Primitiv außerhalb der obigen Tabelle laufen als Befehle.
• Kein Signaturverfahren und kein Pairing wird als Ganzes delegiert. Die secp256k1-Recovery ist k256 über MOD_MUL und EC_ADD; ein BN254-Pairing ist ark-bn254 über MOD_MUL.
• Eine Delegation ist der Kern einer Operation. Padding, Sponges, Blockschleifen und die Leiter einer Skalarmultiplikation sind Code des Gastprogramms und werden als Befehle bewiesen.

Signaturverfahren für Gastprogramme stehen auf der Roadmap für v2.0.0.

Lohnt sich eine neue Delegation?#

Der Zyklus-Profiler bepreist die naheliegenden Kandidaten in jedem Bericht, als Obergrenze der Zyklen, die eine Delegation einsparen könnte:

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

cycles ist der Anteil der Kategorie am Lauf, calls die Zahl der Einsprünge in die Funktionen des Kandidaten und 4 + 2·frame_words der Shim, den eine Delegation zurücklassen würde: die Schreibzugriffe für den Frame, der ecall und die Lesezugriffe für das Ergebnis. Die Formel veranschlagt nichts für die Shards der neuen Familie; behandeln Sie sie also als obere Schranke. Ausführen und profilieren zeigt einen Bericht.

Die Spezifikation jeder Delegation, Spalte für Spalte, steht unter Delegationsschaltkreise.

Bauen#

Aus dem Verzeichnis des Gastprogramms (Guest), ohne weiteres Flag außer dem Target:

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

Das ELF landet im einzigen Target-Verzeichnis des Gastprogramm-Workspace, guests/target/riscv32imac-unknown-none-elf/. guests/.cargo/config.toml fügt zwei Linker-Argumente hinzu, die Sie nie eintippen:

• -T crates/guest-sdk/link.ld, die Speicherkarte, die auch die Symbole definiert, die der Startup-Code und der Allokator verwenden.
• --no-relax. Linker-Relaxation schreibt Befehlsfolgen um und verschiebt jede spätere Adresse, und die Programmidentität bindet diese Adressen.

Es gibt keinen runner: Nichts außerhalb von Apogee bildet die Speicherbereiche eines Gastprogramms ab; cargo run hat also nichts, womit es das Gastprogramm ausführen könnte. Sie führen ein Gastprogramm über den Emulator aus (Ausführen und profilieren).

Profile#

guests/Cargo.toml legt beide Profile auf eine einzige Semantik fest. Sie unterscheiden sich nur in der Optimierung und in den Debug-Assertions der Abhängigkeiten:

Das Standard-Release-Profil von Cargo schaltet Überlaufprüfungen ab, und in einem Gastprogramm ist das keine Performance-Einstellung. Es ändert die Aussage: u32::MAX + 1 würde 00000000 festschreiben und mit Exit 0 enden, wo der Dev-Build einen Panic auslöst und mit Exit 101 endet. Deshalb lässt der Workspace die Prüfungen in beiden Profilen aktiv. Die Debug-Assertion einer Abhängigkeit prüft eine Invariante dieses Crates selbst, und eine korrekte Abhängigkeit berechnet ohne sie dasselbe; das Release-Profil schaltet sie deshalb ab und spart die Zyklen: 6,8 % des Laufs des zustandslosen Ethereum-Gastprogramms.

Beweisen Sie den Release-Build. Jeder ausgeführte Befehl ist eine bewiesene Zeile, opt-level = 3 entfernt ein Viertel bis über die Hälfte des Images eines Gastprogramms, und der Code jeder Familie muss in ihre dekodierte Tabelle passen: Das Debug-Image des Ethereum-Gastprogramms braucht Tabellen mit 2^22 Zeilen, sein Release-Image 2^20. Die Identität, die Sie veröffentlichen, ist die des Release-Images.

Reproduzierbarkeit#

Zwei saubere Builds auf einer Maschine erzeugen identische ELFs. Builds auf zwei Maschinen im Allgemeinen nicht: Das ELF bettet in Strings für Panic-Locations absolute Pfade ein, zu den core-Quellen der Toolchain, zu crates/guest-sdk und zur Cargo-Registry, während die eigenen Dateien des Gastprogramms relativ zu guests/ erscheinen. Ein Build an anderer Stelle ist ein anderes Image mit einer anderen Identität.

Was Sie registrieren und weitergeben, ist also das ELF eines Builds, kein Rezept. Bewahren Sie das ELF auf, das Sie bewiesen haben, und lassen Sie jeden, der die Identität prüfen will, sie aus diesem ELF, den Parametern und der Zeremoniedatei neu berechnen.

Das Image exportieren#

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

Das schreibt artifacts/my-app.img, das geladene ProgramImage in seinem Serialisierungsformat (postcard, ohne Header), und artifacts/my-app.img.txt, einen Bericht, der aus dem über den validierenden Reader zurückgelesenen Image erzeugt wird. Ausgegeben werden der Einsprungpunkt, die Zahl der Segmente und Befehle sowie Größe und SHA-256 des Artefakts. Weicht das Zurückgelesene ab oder weist der Loader das ELF zurück, wird nichts geschrieben.

Die .img-Datei ist die statische Beschreibung des Programms, zum Aufbewahren und Vergleichen; nichts Nachgelagertes braucht sie, denn das Setup und die Werkzeuge nehmen das ELF entgegen. Ihr SHA-256 legt Bytes fest. Er ist nicht die Programmidentität.

Den Bericht lesen#

Ein komprimierter Befehl behält seine Adresse und seine zwei Bytes; allein len gibt an, ob der nächste pc pc + 2 oder pc + 4 ist. Für Mnemonics verwenden Sie die Ansicht tables unten oder den festgelegten Disassembler:

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

Die not code-Halbwörter#

Ein Bericht kann eine Zeile wie ---- not code: 0x00010f9a .. 0x00010f9c, 1 halfword ---- enthalten. Das ist gewöhnliche Compiler-Ausgabe. LLVM hat den Default-Zweig eines match als unerreichbar bewiesen, rustc hat den unerreichbaren Block zu unimp übersetzt, und mit der C-Erweiterung ist das c.unimp, das Halbwort aus lauter Nullen, die definiert illegale Kodierung von RVC. Der Loader verzeichnet es als Nicht-Befehl und macht weiter. Kein pc erreicht es; einer, der es täte, würde den Lauf mit NotAnInstruction anhalten.

Was die VM beweisen wird#

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

Das gibt bei den Standardparametern die VmConfig aus, die aus dem Image abgeleitet wird: die Höhe jeder Familie, ihre belegten Zeilen und dekodierten Spalten. Danach folgen für jeden Befehl pc, next_pc, Familie, Mnemonic und Felder. Mit --ptau und der Zeremoniedatei gibt es außerdem die Programmidentität aus, den Wert, den ein Verifier registriert. Der Schnellstart zeigt eine echte.

Die Identität ist ein einziges Körperelement. Sie bindet jeden Befehl mit seinem pc, seiner Länge, seinen Operanden und seiner Art, jedes in der Datei enthaltene Byte des Images (.text, .rodata, .data), den Einsprungpunkt, die Menge der Familien, jede Höhe, die Obergrenze der Codegröße und die Codeversion. Sie bindet nicht die Symboltabelle, nicht .bss und nichts, was eine Ausführung wählt. Ein ELF mit zwei Einstellungen der Höhen hat zwei Identitäten.

Die Ableitung weist das Programm zurück und nennt dabei den pc oder die Größe:

Einen Build prüfen#

Bauen Sie in ein frisches Target-Verzeichnis, exportieren Sie erneut und vergleichen Sie:

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

Ein Gastprogramm (Guest) auszuführen kostet fast nichts; es zu beweisen kostet proportional zu den Zyklen, die es ausführt. Führen Sie es also zuerst aus, vergleichen Sie es mit Ihrem Host-Build und sehen Sie sich das Zyklenprofil an, bevor Sie irgendetwas beweisen.

Aus Rust: der Emulator#

emulator::run führt ein geladenes Image über einer öffentlichen Eingabe und Hilfsdaten (Advice) aus, in Host-Code, ohne Beweis:

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 gibt eine Execution zurück: die finalen Register, den Exit-Status, die Zyklenzahl und die öffentlichen Werte. Ein Exit-Status ungleich null ist eine Ausführung, kein Fehler, und kommt als exit_code zurück. Ein fataler Fehler des Executors, etwa OutOfBounds, Misaligned oder NotAnInstruction, kommt als EmuError zurück, und ein solcher Lauf hat keinen Beweis (Fehlerbehebung).

Der Emulator ist eine reine Funktion des Images und der Eingabe: keine Uhr, kein Zufall, keine Threads. Dieselbe Eingabe ergibt dieselbe Ausführung, Zyklus für Zyklus, und genau das erlaubt es auch dem Prover, zweimal auszuführen und identische Shards zu schneiden.

Von der Kommandozeile: der Profiler#

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

Er führt das Gastprogramm über den angegebenen Dateien bei der kleinsten Tabellenhöhe aus, in die sein Code passt, und gibt einen Bericht aus. Seine Zahlen sind Zählungen ausgeführter Zyklen, auf jeder Maschine dieselben.

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]

So lesen Sie ihn:

• Der Abschnitt cycles by family zeigt, wofür Sie bezahlen. Jede Familie mit Zeilen kostet mindestens einen Shard ihrer Höhe, und mehr Zyklen in einer Familie bedeuten mehr Shards davon.
• Der Abschnitt top functions rechnet jeder Funktion ihre eigenen Zyklen an, einschließlich allem, was der Compiler per Inlining in sie übernommen hat, aber nicht die der von ihr aufgerufenen Funktionen. Aufrufe werden am ersten Befehl der Funktion gezählt.
• Der Abschnitt cycles by semantic workload ordnet Funktionen anhand ihres Namens vierzehn Kategorien zu, etwa Hashing, Signaturen und dem Kern der Laufzeitumgebung. Der nicht zugeordnete Anteil und die Verteilung der Mnemonics dienen als Kontrolle dieser Zuordnung, denn keine Symboltabelle kann sie falsch beschriften.
• Der Abschnitt accelerator candidates bepreist die Delegationen, die eine künftige Version hinzufügen könnte, als Obergrenze: siehe Delegationen.

Der Profiler hat zwei weitere Unterbefehle für die Ethereum-Arbeitslast: block <stem> führt das revm-Gastprogramm über einer aufgezeichneten Fixture aus, und record <number|latest> zeichnet einen Block von ETH_RPC_URL auf und führt ihn aus.

Günstiger machen#

Die Reihenfolge, die sich meist auszahlt:

1. Bauen Sie mit --release. Die Optimierung entfernt ein Viertel bis über die Hälfte der Befehle eines Gastprogramms.
2. Delegieren Sie Hashing und Kurvenarithmetik. Verwenden Sie guest_sdk::keccak256, sha256, ec_add und die mitgelieferten k256 und ark-ff, statt eine Software-Implementierung in das Gastprogramm zu kompilieren.
3. Hören Sie auf, in Schleifen zu allozieren. Jede Allokation kostet Befehle, und mit einem Bump-Allokator ist sie außerdem Speicher, den Sie nie zurückbekommen (der Heap).
4. Prüfen statt berechnen. Ist ein Ergebnis teuer zu finden und günstig zu verifizieren, etwa eine Sortierreihenfolge, eine Quadratwurzel oder ein Pfad durch einen Baum, lassen Sie es den Prover als Hilfsdaten liefern und das Gastprogramm es verifizieren.
5. Vermeiden Sie Gleitkommaarithmetik. Sie wird zu Softwareroutinen kompiliert; Ganzzahl- und Festkommaarithmetik sind weit günstiger.

Messen Sie dann erneut. Zyklenzahlen sind exakt und reproduzierbar; jede Änderung zeigt sich also als Zahl.

Die drei Aufrufe#

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 lädt das ELF, dekodiert es in seine Familientabellen und seine VmConfig, committet die Setup-Spalten unter der Zeremonie und baut den Verifikationsschlüssel. Seine Kosten fallen pro Programm und pro Wahl der Höhen an, nicht pro Lauf.
• host::prove führt das Gastprogramm (Guest) zweimal aus und beweist jeden Shard (unten). Es gibt ein Proven zurück: den BlockProof, den Exit-Code, die Zyklenzahl, das Journal und einen Bericht über den Lauf.
• host::verify prüft den Block gegen den Schlüssel, anhand der Aussage, die der Block mitführt. Es vergleicht weder die Identität noch den SRS-Digest mit irgendetwas; dieser Vergleich ist also Ihre Aufgabe.

Der Schnellstart führt genau diesen Code über einem kleinen Gastprogramm aus, mit seiner echten Ausgabe.

Was ein Verifier selbst besitzen muss#

Zwei Werte stammen aus einem Kanal, den der Prover nicht kontrolliert:

1. Die Programmidentität. Gegenüber einer vom Prover gelieferten Identität zeigt ein Beweis nur, dass irgendein Programm gelaufen ist. Ein Verifier registriert die Identität des Release, dem er vertraut, und vergleicht sie mit der des Schlüssels.
2. Der SRS-Digest der Zeremonie. Ein Schlüssel wird unter jedem Digest geladen, den seine eigenen Punkte ergeben. Einer, der über einem bekannten τ gebaut wurde, könnte alles öffnen und wird nur durch den Vergleich seines Digests mit dem der Zeremonie zurückgewiesen.

Der Verifikationsschlüssel selbst darf von beliebiger Seite stammen, auch vom Prover: Beim Laden werden die Identität und der SRS-Digest aus seinem eigenen Inhalt neu berechnet, und seine Schaltkreise werden mit der eigenen Registry des Verifiers abgeglichen. Lesen Sie dann die Aussage: zuerst den Exit-Status, dann das Journal.

Höhen#

Jede Familie hat eine Höhe, die Zahl der Zeilen in einem ihrer Shards, gewählt aus 2^8, 2^12, 2^16, 2^18, 2^20, 2^22. Höhen sind Teil des Programms, nicht eines Laufs: Jede Höhe ist in die Identität eingebunden.

Eine Familie mit Zeilen kostet mindestens einen ganzen Shard ihrer Höhe; ein kurzer Lauf verschwendet also bei kleineren Höhen weniger, und ein langer braucht bei größeren Höhen weniger Shards. Eine dekodierte Tabelle muss außerdem hoch genug sein, um den letzten Befehl der Familie zu erreichen: 2^20 reicht für 1,9375 MiB Code und 2^22 für 7,9375 MiB. Das Ethereum-Gastprogramm beweist bei 2^20 für jede Familie, deren Höhe wählbar ist.

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
}

Die Zeremonie muss so viele Potenzen liefern, wie die höchste Familie Zeilen hat, und mindestens 2^18 für die generische Lookup-Tabelle: Srs::from_ptau(path, k) mit 2^k mindestens so groß wie die größte Höhe.

Gleichzeitig bearbeitete Shards#

Das dritte Argument von host::prove ist max_in_flight, die Zahl der gleichzeitig bewiesenen Shards. Es ist der eine Regler, der Speicher gegen Zeit tauscht:

• Der Speicherbedarf folgt den gleichzeitig bearbeiteten Shards, nicht der Zyklenzahl. Jeder gerade bearbeitete Shard hält seine Zeilen, seinen Vorwärtsdurchlauf und seinen Beweis, während dieser wächst. Ein 2^20-Shard der breitesten Befehlsfamilie hält in seinem Vorwärtsdurchlauf etwa 8,4 GiB; ein KECCAK_F-Shard der Höhe 2^18 etwa 42 GiB.
• Die Zeit folgt der Zahl der nebeneinander laufenden Shards, bis zur Zahl Ihrer Kerne. Innerhalb eines Shards läuft die Arbeit auf allen Kernen.
• Der Beweis hängt nicht davon ab. Der Block ist bei 1 und bei 8 gleichzeitig bearbeiteten Shards byte-identisch.

Beginnen Sie auf einem Laptop niedrig, mit zwei oder vier, und erhöhen Sie den Wert auf einem Server, bis der Speicher und nicht die Kerne die Grenze bilden. bench prove verwendet standardmäßig 8.

Die zwei Durchläufe#

host::prove arbeitet im Streaming-Verfahren. Es hält nie den gesamten Ausführungs-Trace, der mit etwa 300 Byte pro Zyklus das größte Objekt im System wäre.

1. Durchlauf 1 führt das Gastprogramm aus und committet, sobald ein Shard gefüllt ist, dessen Speicherspalten, behält die Commitments und verwirft die Zeilen. Beim Exit baut er die Aussage und zieht die Challenges, die alle Shards teilen.
2. Durchlauf 2 führt erneut aus. Der Emulator ist deterministisch und schneidet daher dieselben Shards. Jeder wird bei seinem Eintreffen befüllt, bewiesen und verworfen, und nur sein Beweis wird behalten.

Deshalb kostet das Beweisen die Zeit zweier Ausführungen und einen Speicherbedarf, der durch die gleichzeitig bearbeiteten Shards beschränkt ist. Der Streaming-Prover erklärt das ausführlich.

Den Beweis aufbewahren#

host::proof_archive::write_proof(dir, stem, vk, block) schreibt vier Dateien, jede mit den reinen Bytes ihres Typs:

<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) liest sie zurück. Die Datei .identity hält fest, was der Lauf behauptet hat; ein Verifier vergleicht trotzdem mit seiner eigenen Kopie. Das Kommandozeilenwerkzeug verifier prüft ein Archiv:

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

Es endet mit 0, wenn die Verifikation vollständig gelingt, mit 1 unter Nennung der ersten Zurückweisung und mit 2 bei einem Aufruffehler oder einer fehlerhaft formatierten Identität. Es vergleicht die übergebene Identität mit der des Schlüssels und entnimmt den SRS-Digest der Schlüsseldatei.

Wenn ein Beweis fehlschlägt#

Ein ehrlicher Prover erzeugt nie einen Beweis, der fehlschlägt; ein Fehlschlag bedeutet also eine Eingabe, die er nicht hätte annehmen dürfen, oder einen Bug. Bauen Sie mit aktiviertem Debug-Log des Provers neu und führen Sie erneut aus:

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

Das Log nennt den Shard, der abgebrochen ist, und self_check FAILED nennt das erste Gate, das eine Zeile verletzt, mit dem Wert jedes Operanden. Werkzeuge und CLIs listet jeden Marker auf. Das Log existiert nur in Builds mit dem Feature debug-info und ändert kein Byte des Beweises.

Weiter: On-Chain abwickeln.

Ein Basisbeweis ist ein Block aus Shard-Beweisen, jeder ein GKR-Beweis mit seinen Commitments: Megabytes an Daten und Hunderte von Kurvenpunkten, die kein Contract prüfen kann. Die Abwicklung komprimiert ihn in drei Stufen, jede mit bench im Wurzelverzeichnis des Repositorys ausgeführt.

1. Der Rekursionsbaum#

Ein Knoten ist Apogee beim Beweisen eines Verifier-Programms. Ein Blatt verifiziert eine Reihe aufeinanderfolgender Basis-Shards; ein innerer Knoten verifiziert zwei bis vier Kind-Beweise; die Wurzel deckt jeden Basis-Shard ab. Jeder Knoten faltet außerdem jede Mercury-Prüfung, die seine Shards und Kinder aufschieben, in ein einziges Punktepaar, sodass der ganze Baum an der Spitze auf eine einzige Pairing-Behauptung hinausläuft.

# 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 schreibt die Schlüssel der beiden Rekursionsprogramme, baut darauf die Blatt- und Knoten-Binaries, legt einen Plan fest, bevor irgendetwas bewiesen wird (<out>/tree.txt: Blätter aus höchstens --leaf 64 Basis-Shards, dann Knoten aus höchstens --fan-in 4 Kindern), und beweist Knoten für Knoten. Jeder Knoten ist ein eigener Prozess, der seine Eingaben vor dem Beweisen nativ verifiziert; eine fehlerhafte Eingabe wird also namentlich zurückgewiesen. Ein angehaltener Lauf lässt sich fortsetzen: Bereits in <out> liegende Beweise bleiben erhalten, und ein Lauf mit abweichendem Plan oder abweichenden Programmen wird zurückgewiesen.

Das Beweisen der Basis bleibt von alledem unberührt. Ein Blatt verifiziert Basis-Shards genau so, wie sie sind.

2. Der Decider#

Die Wurzel ist immer noch ein GKR-Beweis und einige Hundert Punkte. Der Decider ist ein Groth16-Schaltkreis, der die Wurzel so verifiziert, wie es ein Knoten täte, und nichts faltet. Stattdessen bindet er als Wires, deren Werte der Contract liefert, die Identitäten der beiden Rekursionsprogramme, den Exit-Status der Basisaussage, ihre öffentliche Eingabe und ihr Journal Byte für Byte sowie jeden Punkt, dem die Wurzel ein Pairing schuldet, mit seinem Skalar. Der Groth16-Beweis trägt ein einziges Commitment auf all diese Wires, und der Contract prüft es gegen die Werte, die er besitzt.

Ein Groth16-Schlüssel braucht eine Zeremonie. Phase 1 ist dieselbe Powers-of-Tau-Datei, auf der die Commitments des Baums beruhen. Phase 2 ist schaltkreisspezifisch und läuft in zwei Beitragsrunden:

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

Jeder Beitrag multipliziert eine Falltür mit einem Faktor, den nur sein Beitragender kannte, und wird mit einem Schnorr-Beweis festgehalten; jeder Zustand lässt sich also allein gegen den Schaltkreis und die Zeremoniedatei verifizieren. Eine Falltür ist unbekannt, solange einer ihrer Beitragenden ehrlich war. Die Reihenfolge der Runden ist Teil der Soundness: alpha und beta sind abgeschlossen, bevor irgendetwas durch delta oder eta geteilt wird.

decide schreibt decision.constructor und decision.calldata: die Deployment-Argumente und den Aufruf, als Hex.

3. Der Contract#

contracts/ApogeeVerifier.sol hat einen einzigen Einsprungpunkt:

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);

Der Contract rekonstruiert die gebundenen Werte aus den Calldata, prüft die Pairing-Gleichung von Groth16, faltet die Punkte jeder Seite mit ecMul und ecAdd, was zugleich erzwingt, dass jeder Punkt auf der Kurve liegt, und prüft die gefaltete Behauptung e(A, [1]_2) = e(B, [x]_2). Ein Anwendungs-Contract ruft ihn auf und handelt dann anhand des Journals: siehe die Skizze des Hauptbuchs.

Was ein Deployment festlegt#

Der Konstruktor nimmt den Groth16-Schlüssel, die beiden G2-Punkte der Zeremonie, die Identitäten der Blatt- und Knotenprogramme, die Zahl der Punkte auf jeder Seite und die Bytelängen der öffentlichen Eingabe und des Journals entgegen. Ein bereitgestellter Verifier bedient also:

• Ein einziges Basisprogramm. Seine Identität ist eine Konstante im Image des Blattprogramms, die die Identität des Blatts bindet.
• Eine einzige Wurzelform. Der Schaltkreis des Deciders hängt vom Programm der Wurzel, ihren Shard-Zahlen und den Längen der öffentlichen Werte ab; ein Schlüssel und seine Zeremonie gelten also je Form.
• Öffentliche Werte fester Länge. verify weist eine Eingabe oder ein Journal jeder anderen Länge zurück. Entwerfen Sie Gastprogramme (Guests), deren öffentliche Werte on-chain eine feste Größe haben, etwa einen festen Datensatz oder einen 32-Byte-Digest.

Der Contract zahlt etwa 9.000 gas pro Punkt, weil der Schaltkreis keinen davon faltet.

Gemessen#

Block 257.510, mit dem Baum auf einer Maschine mit 32 CPUs und 247 GiB und mit Zeremonie und Decider auf einem Laptop mit 18 Kernen:

Die Spezifikation all dessen ist Rekursion und Decider.

Ein Gastprogramm (Guest) zu schreiben heißt größtenteils, Rust zu schreiben. Diese Seite behandelt den Rest: die Stellen, an denen sich eine bewiesene Bare-Metal-Maschine mit einem einzigen Hart anders verhält als der Host, den Sie gewohnt sind. Jede Regel sagt, was zu tun ist, warum und was sonst schiefgeht. Der KI-Begleiter enthält dieselben Regeln in einer Form, die Sie einem Modell übergeben können.

Typen und Speicher#

usize ist 32 Bit breit, und jeder Zeiger ebenso#

Das Target der Gastprogramme ist riscv32imac: usize, isize und jeder Zeiger sind 32 Bit breit, die Ihres Hosts dagegen 64.

• Ein Überlauf eines usize löst im Gastprogramm einen Panic aus, auf dem Host nicht.
• x as usize aus einem u64 schneidet im Gastprogramm stillschweigend ab.
• size_of::<T>(), das Struct-Layout und core::hash von allem, was eine Länge oder einen Zeiger enthält, unterscheiden sich zwischen den beiden Builds.

Empfohlen: Verwenden Sie explizit u32 und u64 in allem, was Sie festschreiben, hashen, serialisieren oder mit einer Berechnung auf dem Host vergleichen. Konvertieren Sie mit usize::try_from(x), wo ein Wert womöglich nicht passt, damit es auf beiden Builds laut fehlschlägt. Zu vermeiden: usize festschreiben, eine Struktur hashen, die eines enthält, oder eine layoutabhängige Kodierung ableiten.

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`

Der Allokator gibt nie Speicher frei#

Der Heap ist ein Bump-Allokator: alloc schiebt einen Zeiger nach oben, dealloc tut nichts, und Speicher kommt erst zurück, wenn das Programm endet. Deshalb gilt: Was einem Gastprogramm den Speicher ausgehen lässt, ist die Gesamtmenge dessen, was es über den Lauf alloziert, nicht sein Spitzenbedarf. Läge das Ende einer Allokation oberhalb der Reserve des Stacks oder oberhalb des aktuellen Stack-Pointers, endet das Gastprogramm mit Status 71.

Empfohlen:

• Einmal allozieren und wiederverwenden: Puffer aus Schleifen herausziehen und mit clear() leeren, statt neue zu bauen.
• Collections vorab mit Vec::with_capacity, String::with_capacity dimensionieren, damit sie beim Wachsen nicht neu allozieren und kopieren. Ein Vec, der Push für Push auf n Elemente wächst, lässt außerdem seine früheren, kleineren Puffer zurück.
• Borrowing (&[u8], &str) dem Klonen vorziehen und Iteratoren den Zwischen-Collections.
• Große Hilfsdaten (Advice) an Ort und Stelle verarbeiten: advice() ist bereits ein Slice über Speicher, es gibt also nichts zu kopieren.

Zu vermeiden: in einer heißen Schleife mit collect() in einen neuen Vec sammeln, Werte klonen, die Sie nur lesen, oder eine Map pro Anfrage neu aufbauen, wenn sich eine einzige Map leeren und neu befüllen lässt.

// 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);
}

Der Stack hat 8 MiB, und nichts bewacht seinen fernen Rand#

Der Stack wächst ab 0x8000_0000 nach unten und hat eine Reserve von 8 MiB, in die kein Heap-Block eindringen darf. Tiefe Rekursion innerhalb davon ist unproblematisch. Was nichts erkennt, ist ein Stack, der über seine Reserve hinauswächst, nachdem der Heap den Raum darunter gefüllt hat: Heap-Blöcke ändern sich dann unter einer tiefen Aufrufkette, stillschweigend. Empfohlen: die Rekursionstiefe beschränkt und vorhersehbar halten oder tiefe Traversierungen iterativ mit einer expliziten Arbeitsliste schreiben. Zu vermeiden: bis zu einer Tiefe rekursieren, die eine nicht vertrauenswürdige Eingabe bestimmt.

Nur ausgerichtete Zugriffe#

Ein Halbwort- oder Wortzugriff über einen nicht ausgerichteten Zeiger ist fatal, wird nie aufgeteilt, und der Lauf hat keinen Beweis. Safe Rust erzeugt nie einen solchen Zugriff. Vermeiden Sie es, einen Byte-Zeiger nach *const u32 zu casten und ihn zu dereferenzieren; lesen Sie mit u32::from_le_bytes, das zu Byte-Ladebefehlen kompiliert, oder mit ptr::read_unaligned.

Null ist ein Loch#

Adressen unterhalb von 0x8000 gehören zu nichts; ein Null-Zeiger oder ein kleiner wilder Zeiger ist also ein fataler OutOfBounds-Fehler statt eines Lesezugriffs auf Datenmüll. Er zeigt sich als Lauf ohne Beweis, nie als falsche Antwort.

Nebenläufigkeit#

Atomics: unterstützt, aber nicht für neuen Code in Gastprogrammen#

Was Sie wissen sollten, wenn Atomics über eine Abhängigkeit in Ihr Gastprogramm gelangen:

• Auf einem einzigen Hart ist eine atomare Operation nur ein Read-Modify-Write. fetch_add ist ein amoadd.w, das addiert; nichts kann sich dazwischenschieben.
• sc.w gelingt immer. Die Maschine führt keinen Reservierungszustand; ein Store-Conditional speichert also und schreibt 0 nach rd. Die lr.w/sc.w-Wiederholungsschleife, die kompilierter Code für compare_exchange verwendet, ist davon nicht betroffen, weil Erfolg beim ersten Versuch auf jedem Hart zulässig ist. Code, der sich darauf verlässt, dass sc.w ohne gültige Reservierung fehlschlägt, bekommt diesen Fehlschlag hier nicht. Das ist die einzige Stelle, an der Apogee von RV32IMAC abweicht.
• fence tut nichts, und Speicherordnungen (aq, rl, SeqCst) ordnen auf einem einzigen Hart nichts.
• Sie kosten eine Schaltkreisfamilie. Eine atomare Operation fügt dem Programm die Familie ATOMICS hinzu, das dann mindestens einen Shard davon beweist.

Empfohlen: gewöhnliche Variablen, Cell und RefCell für Zustand in neuem Code von Gastprogrammen verwenden. Zu vermeiden: AtomicU32, Mutex-artige Spinlocks oder Arc in ein Gastprogramm aufnehmen, das keinen zweiten Thread hat, mit dem es sie teilen könnte.

Eingaben und Ausgaben#

Hilfsdaten prüfen, bevor irgendetwas daraus Abgeleitetes ins Journal gelangt#

Hilfsdaten sind Speicher, den der Prover gefüllt hat, und nichts bindet sie. Prüfen Sie sie gegen etwas, das der Beweis sehr wohl bindet, etwa einen Hash oder eine Merkle-Wurzel in der öffentlichen Eingabe, eine Signatur oder eine Eigenschaft des Ergebnisses, bevor Sie irgendetwas festschreiben, das von ihnen abhängt. Wer eine Funktion ungeprüfter Hilfsdaten festschreibt, veröffentlicht einen Wert, den der Prover gewählt hat. Siehe das Muster.

Öffentliche Werte klein halten, on-chain mit fester Größe#

Eingabe und Journal fassen jeweils höchstens 16.380 Byte. commit endet mit Exit 70, statt überzulaufen. Große Eingaben gehören in Hilfsdaten hinter einem Commitment, wachsende Ausgaben hinter einen Digest. Ein Verifier-Contract ist für eine Eingabelänge und eine Journal-Länge gebaut; ein Gastprogramm, das auf Ethereum abgewickelt wird, sollte also ein Journal fester Größe veröffentlichen.

Festlegen, wie ein Fehlschlag aussieht#

Ein Gastprogramm, das mit einem Status ungleich null endet oder einen Panic auslöst, hat trotzdem einen gültigen Beweis dessen, was es getan hat, und ein Verifier liest den Status vor dem Journal. Geben Sie jeder Zurückweisung einen eigenen Exit-Code außerhalb der Codes des SDK (70, 71, 72 und 101), und schreiben Sie nichts aus ungeprüften Daten Abgeleitetes fest, bevor die Prüfungen gelaufen sind, die es zurückweisen können.

Keine Außenwelt#

Ein Gastprogramm hat keine Uhr, keinen Zufall, kein Netzwerk, keine Dateien und keine Umgebung. Ein Bibliotheksaufruf, der den Host nach einem davon fragt, erhält -ENOSYS als Antwort und macht den Lauf unbeweisbar. Initialisieren Sie HashMap mit einem deterministischen Seed oder verwenden Sie BTreeMap; leiten Sie Zufall aus der Eingabe ab, wenn ein Algorithmus ihn braucht; übergeben Sie die Zeit als Eingabe.

Kosten#

Jeder ausgeführte Befehl ist eine bewiesene Zeile#

Die Beweiskosten folgen der Zyklenzahl, Familie für Familie. Bauen Sie mit --release, messen Sie mit dem Profiler und behandeln Sie Zyklen so, wie Embedded-Entwickler Bytes behandeln.

Delegieren, was einen Schaltkreis hat#

keccak256, sha256, Addition und Multiplikation auf elliptischen Kurven, Poseidon2, Körperarithmetik von BN254 und modulare 256-Bit-Multiplikation haben eigene Schaltkreise. Erreichen Sie sie über guest_sdk und die mitgelieferten k256, ark-ff und revm-precompile, nicht über eine in das Gastprogramm kompilierte Software-Implementierung. Siehe Delegationen.

Verifizieren statt berechnen#

Ist ein Ergebnis teuer zu finden und günstig zu prüfen, lassen Sie den Prover es finden und als Hilfsdaten übergeben, und lassen Sie das Gastprogramm es prüfen: eine Sortierreihenfolge, eine Faktorisierung, ein Inverses, einen Pfad durch einen Baum, ein Suchergebnis.

Gleitkommaarithmetik vermeiden#

Das Target hat keine F- oder D-Erweiterung; f32 und f64 werden also zu Ganzzahl-Softwareroutinen kompiliert. Sie sind korrekt und deterministisch, und jede Operation kostet viele Befehle. Verwenden Sie Ganzzahlen oder Festkomma.

Höhen kosten ganze Shards#

Eine Familie mit Zeilen kostet mindestens einen Shard ihrer Höhe, wie wenige Zeilen sie auch füllt. Ein Programm, das eine Familie ein einziges Mal berührt, bezahlt einen ganzen Shard; die Familien, die Ihr Code verwendet, und die Höhen, die Sie wählen, bestimmen die Untergrenze jedes Beweises. Siehe Höhen.

Code und Identität#

Der Befehlsstrom ist das Image#

Code ist statisch: Der Befehl jedes pc stammt aus den beim Laden gebauten dekodierten Tabellen, nie aus dem RAM. Ein Schreibzugriff auf .text ändert Daten, nicht das Verhalten, und ein Sprung auf ein Halbwort ohne Befehl beendet den Lauf ohne Beweis. Es gibt keinen JIT und keinen selbstmodifizierenden Code.

Ein illegales Wort irgendwo, und das Programm wird zurückgewiesen#

Der Decoder nimmt sich ganz .text vor, erreichbar oder nicht. Ein CSR-Zugriff, fence.i, eine Gleitkomma- oder RV64-Kodierung in Inline-Assembly oder in .text assemblierte Daten führen dazu, dass die Ableitung das gesamte Programm zurückweist. ebreak wird dekodiert, hat aber keinen Beweis.

Überlaufprüfungen sind Teil des Programms#

Die Profile der Gastprogramme lassen overflow-checks auch im Release-Build aktiv, weil das Abschalten ändert, was ein Gastprogramm berechnet: u32::MAX + 1 würde umlaufen und mit Exit 0 enden, statt einen Panic auszulösen. Verwenden Sie wrapping_*, checked_* und saturating_* dort, wo Sie genau das meinen.

Ein Build ist eine Identität#

Die Identität bindet jedes Byte an Code und Daten, den Einsprungpunkt und jede Höhe. Ein Neubau auf einer anderen Maschine erzeugt eine andere Identität, weil das ELF absolute Pfade einbettet. Registrieren und verteilen Sie das ELF, das Sie bewiesen haben, nicht den Befehl, der es erzeugt hat.

Checkliste#

Bevor Sie beweisen:

• cargo build --release für riscv32imac-unknown-none-elf, Zyklenbericht des Profilers durchgesehen
• kein usize in irgendetwas, das festgeschrieben, gehasht oder serialisiert wird
• keine Allokation in heißen Schleifen; wachsende Collections mit with_capacity dimensioniert
• keine Atomics, Locks oder Arc in eigenem Code des Gastprogramms
• jede Verwendung von Hilfsdaten gegen etwas geprüft, das der Beweis bindet, vor jedem Festschreiben, das davon abhängt
• Journal beschränkt, und von fester Größe, wenn es on-chain abgewickelt wird
• Hashing und Kurvenarithmetik über Delegationen geleitet
• eigene Exit-Codes für jede Zurückweisung
• Host-Build und Emulator stimmen für Ihre Testeingaben im Journal überein
• die Programmidentität aus dem ELF festgehalten, das Sie ausliefern werden

Ein Gastprogramm (Guest) kann an sechs Stellen vor einem verifizierten Beweis stehen bleiben. Suchen Sie das Symptom, dann die Zeile.

Der Lauf endet mit einem Status, den Sie nicht erwartet haben#

Der Lauf ist beendet und beweisbar; das Gastprogramm hat sich für einen Fehlschlag entschieden. Die eigenen Statuswerte des SDK:

Jeder andere Status ist Ihr eigenes exit(code).

Der Lauf bricht mit einem fatalen Fehler ab#

Der Emulator gibt einen EmuError zurück, und es gibt weder Exit-Status noch Beweis:

Das ELF wird zurückgewiesen#

artifact-dump, host::setup und die Werkzeuge weisen ein ELF, das der Loader nicht annehmen kann, mit einem LoaderError zurück:

Das Programm lässt sich nicht registrieren#

Das ELF lädt, aber das Programm lässt sich nicht in eine Konfiguration dekodieren:

Ein Schlüssel lässt sich außerdem nicht bauen, wenn eine Familie, die das Programm verwendet, unter ihre Untergrenze gesetzt ist, 2^20 für eine Befehlsfamilie und 2^16 für die RAM-Fensterfamilien, weil dort kein Schaltkreis existiert.

Der Prover schlägt fehl#

Ein ehrlicher Prover, der beweist, was der Emulator ausgeführt hat, schlägt nicht fehl; ein Fehlschlag deutet also auf eine Eingabe hin, die er nicht hätte annehmen dürfen, oder auf einen Bug. Zwei Fälle machen den Großteil aus:

• Ein Aufruf ohne Beweis. Ein Systemaufruf außerhalb von EXIT und den Delegationen, den eine Bibliothek für Daten des Hosts abgesetzt hat, erhält -ENOSYS als Antwort, und der Lauf geht weiter, aber das Befüllen im Prover weist diese Zeile zurück und nennt den Zyklus. Suchen Sie die Abhängigkeit, die nach Zufall oder Zeit fragt.
• Speicher erschöpft. Der Prozess wird beendet, während Shards in Bearbeitung sind. Verringern Sie das dritte Argument von host::prove oder die Höhen.

Für alles andere bauen Sie mit dem Debug-Log des Provers neu und führen erneut aus:

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 nennt das erste fehlschlagende Gate der Zeile und den Wert jedes Operanden. Das Debug-Log listet jeden Marker auf.

Die Verifikation schlägt fehl#

verify_shard und verify_block geben einen VerifyError zurück, dessen Klasse angibt, was fehlgeschlagen ist:

Wenn Sie den Beweis mit dem eigenen Prover von Apogee aus einer Ausführung erstellt haben, die der Emulator akzeptiert hat, bedeutet ein Verifikationsfehler, dass Verifier und Prover sich über das Programm uneinig sind: Prüfen Sie, dass Sie den Schlüssel laden, unter dem der Beweis erstellt wurde, mit denselben Höhen und über derselben Zeremonie.

Abweichende Identität#

Die Identität, die Sie berechnet haben, weicht von der erwarteten ab:

• Der Build einer anderen Maschine. Das ELF bettet absolute Pfade ein; ein Neubau an anderer Stelle ist also ein anderes Image. Vergleichen Sie mit dem ELF, das bewiesen wurde, nicht mit einem frischen Build.
• Andere Höhen. Jede Höhe ist in die Identität eingebunden. artifact-dump tables meldet die Identität bei den Standardhöhen; Ihr Setup verwendet möglicherweise andere.
• Eine andere Zeremonie. Eine Powers-of-Tau-Datei von Hermez hat ein anderes τ; jedes Commitment ist also anders. Prüfen Sie das [τ]_1 der Datei gegen das der Zeremonie.

Der Workspace guests/ enthält jedes Gastprogramm (Guest), das das Repository baut und testet. Jedes existiert, um etwas zu erproben, und das macht sie zur besten Referenz für das Muster, das Sie gerade schreiben wollen. Alle bauen mit cargo build --target riscv32imac-unknown-none-elf aus ihrem eigenen Verzeichnis.

Hier beginnen#

Anwendungsmuster#

Delegationen#

Die Maschine selbst#

Das kleinste nützliche Gastprogramm#

fib liest ein u32, macht so viele Fibonacci-Schritte mit umlaufender Arithmetik und schreibt das Ergebnis fest:

#![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());
}

Eine zu kurze Eingabe ist ein Fehler und kein Fall für einen Standardwert: Ein Gastprogramm, das mit einem teilweise gefüllten Puffer weitermacht, beweist eine Aussage über Nullen. Die Addition läuft absichtlich um; ein n über 47, jenseits des letzten Glieds, das in 32 Bit passt, ist also eine gewöhnliche Eingabe mit einer gewöhnlichen Antwort und kein fehlgeschlagener Lauf. Und es gibt keine Hilfsdaten, weil f_n einen Verifier beim Prüfen genauso viel kostet wie beim Berechnen: Eine als Hilfsdaten gelieferte Antwort müsste neu berechnet werden, damit man ihr glauben kann.

crates/guest-sdk ist die gesamte Laufzeitumgebung eines Gastprogramms (Guest): der Startup-Code, das Einsprungmakro, der Allokator, der Panic-Handler und die ecall-Shims. Es kompiliert nur für riscv32imac-unknown-none-elf.

Einsprung#

guest_sdk::entry!(main);

Exportiert das Symbol main, das der Startup-Code aufruft, als Wrapper, der Ihre Funktion aufruft; diese nimmt keine Argumente und gibt () zurück. Ihre Funktion behält ihren eigenen Namen und darf selbst main heißen. Eine Rückkehr aus ihr ist gleichbedeutend mit exit(0).

Die Speicherbereiche#

Hashing#

Elliptische Kurven#

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

Ein Punkt in homogen projektiven Koordinaten, x = X/Z und y = Y/Z, jede Koordinate acht Little-Endian-Limbs zu 32 Bit unterhalb des Körpermoduls der Kurve. Das sind keine Jacobi-Koordinaten: Projective von arkworks verwendet solche; ein Aufrufer, der von dort konvertiert, bildet also beim Hineinkonvertieren auf (X·Z, Y·Z², Z) und beim Zurückkonvertieren auf (X·Z, Y, Z³) ab. Das neutrale Element ist (0 : 1 : 0).

Die Formel beweist Arithmetik, nicht die Zugehörigkeit zur Kurve: Prüfen Sie Punkte, die aus Hilfsdaten stammen, selbst.

Rohe Delegations-Shims#

guest_sdk::recursion enthält die Shims über wortausgerichteten Frame-Typen. Jeder Frame-Typ ist #[repr(C, align(4))]; seine Ausrichtung ergibt sich also aus dem Typ und nicht daraus, wo der Codegenerator gerade eine lokale Variable abgelegt hat. Ein Shim im Basisformat gibt genau bei -ENOSYS false zurück; jede andere Antwort ungleich null führt zu Exit 72.

Jeder Shim liest seine ecall-Nummer aus dem Deklarationsdatensatz seiner Familie, einem 12-Byte-static in einer eigenen Linker-Sektion. Einen Shim zu linken deklariert die Familie; eine deklarierte Familie, die nie aufgerufen wird, beweist null Shards.

Laufzeitverhalten#

Transparente Delegation#

Zwei Bibliotheks-Crates des Repositorys delegieren auf dem Target der Gastprogramme, ohne das SDK zu benennen, über eine nur für dieses Target geltende Abhängigkeit davon:

• field::Fr: Addition, Montgomery-Multiplikation (*, square, pow und die Konvertierungen) und inverse für Werte ungleich null rufen FR_ARITH auf. Ein Gastprogramm, das Fr-Arithmetik verwendet, deklariert diese Familie.
• transcript::poseidon2_permute ruft POSEIDON2 auf.

Die mitgelieferten k256, ark-ff und revm-precompile tun dasselbe für secp256k1, BN254 und die Precompiles der EVM: Delegationen.

Die Spezifikation des ABI, das all dem zugrunde liegt, ist Gastprogramm-ABI.

Ein Großteil des Codes, der für Apogee geschrieben wird, wird von einem Modell entworfen werden. Ein Modell, das Apogee nie gesehen hat, schreibt ein plausibles Gastprogramm (Guest), das std verwendet, in jeder Schleife alloziert, zu einem atomaren Zähler greift, seinen Hilfsdaten (Advice) vertraut und ein usize festschreibt. Der KI-Begleiter ist eine einzige Markdown-Datei, die alles vorab bereitstellt, was diese Fehler verhindert: was ein Gastprogramm ist, die harten Regeln, die vollständige öffentliche Oberfläche des SDK mit exakten Signaturen, Muster zum Übernehmen, die Fehler und ihre Behebung sowie eine Checkliste für das Review.

So verwenden Sie ihn#

• In einem Chat: Hängen Sie die Datei an oder fügen Sie sie als erste Nachricht ein, bevor Sie beschreiben, was gebaut werden soll.
• In einem Coding-Agenten: Speichern Sie sie im Wurzelverzeichnis Ihres Projekts unter dem Namen, den Ihr Werkzeug per Konvention liest, etwa AGENTS.md oder CLAUDE.md, oder fügen Sie sie den Projektregeln des Werkzeugs hinzu. Der Agent liest sie dann zu Beginn jeder Sitzung.
• Für das Review: Bitten Sie das Modell, ein Gastprogramm Zeile für Zeile gegen Abschnitt 8 der Datei zu prüfen, die Review-Checkliste.

Die Datei formuliert ihre Regeln als MUST und MUST NOT, jeweils mit der Begründung daneben, weil Modelle expliziten und begründeten Vorgaben zuverlässiger folgen als Konventionen, die sie selbst erschließen sollen.

Was er enthält#

Die Regeln, auf denen er besteht#

Der Begleiter wiederholt die Regeln dieses Handbuchs, und drei davon verdienen es, hervorgehoben zu werden, weil Modelle sie am häufigsten falsch machen:

• Zeiger und usize sind 32 Bit breit. Ein Modell, das überwiegend mit 64-Bit-Code trainiert wurde, serialisiert usize, ohne zweimal nachzudenken. Gastprogramm und Host sind sich dann über die Bytes uneinig.
• Der Heap gibt nie Speicher frei. Idiomatisches Rust alloziert großzügig, weil ein echter Allokator Speicher zurückgibt. Hier ist jede Allokation für den Rest des Laufs dauerhaft; der Begleiter verlangt deshalb überall Wiederverwendung und with_capacity.
• Atomics kompilieren, und sie gehören nicht in neuen Code von Gastprogrammen. Sie werden für die Kompatibilität mit bestehenden Bibliotheken unterstützt. Auf einem einzigen Hart synchronisieren sie nichts, und sie fügen dem Beweis eine Schaltkreisfamilie hinzu.

Für Agenten, die diese Dokumentation direkt lesen#

• /llms.txt verzeichnet jede Seite dieser Website in Markdown, für Modelle, die das Web lesen.
• /docs/llms-full.txt ist die gesamte englische Dokumentation, einschließlich der Spezifikation, in einer einzigen Datei.
• Jede Seite hat einen Link Als Markdown anzeigen und eine Schaltfläche Als Markdown kopieren, unter ihrem Titel und in der rechten Spalte.

Englisch ist die kanonische Sprache der Dokumentation, und der Begleiter wird für jede Sprachversion auf Englisch veröffentlicht: Es ist die Sprache, der Modelle am zuverlässigsten folgen, und die, in der die Spezifikation geschrieben ist.

Apogee beweist Ausführungen von RV32IMAC-Programmen. Dieser Abschnitt beschreibt das System auf der Ebene seiner großen Komponenten: was jede davon tut, warum sie so gebaut ist, wie sie gebaut ist, und wie sie an die nächste übergibt. Der Abschnitt Auditoren enthält dasselbe System auf der Ebene jeder Spalte und jedes Gates.

Was ein Beweis aussagt#

Ein Verifier besitzt drei Dinge, die er nicht auf das Wort des Provers hin übernimmt:

• die Programmidentität, ein einziges Körperelement, das die Befehlstabellen des Programms, sein anfängliches Speicher-Image, seinen Einsprung-pc und seine Konfiguration zu einem Digest verdichtet;
• den SRS-Digest der Zeremonie, den ein Verifikationsschlüssel tragen muss;
• einen Verifikationsschlüssel, der von beliebiger Seite stammen darf, weil beim Laden die Identität und der SRS-Digest aus seinem eigenen Inhalt neu berechnet und seine Schaltkreise mit der Registry des Verifiers abgeglichen werden.

Die Aussage des Beweises enthält die öffentliche Eingabe, die öffentliche Ausgabe (das Journal), den Exit-Status und die Aufzeichnung der Form der Ausführung: die Shard-Zahlen, die Speicherfenster, die finalen Register und den finalen pc sowie die Speicher-Commitments und Wurzeln jedes Shards. Ein Beweis, der die Verifikation besteht, begründet, dass das Programm dieser Identität, gestartet an seinem Einsprung-pc auf seinem Image, mit der öffentlichen Eingabe in seinem Eingabefenster und irgendwelchen vom Prover gewählten Hilfsdaten (Advice), Befehl für Befehl bis zu EXIT mit diesem Status ausgeführt wird und dabei dieses Journal geschrieben hat. Über die Hilfsdaten wird nichts behauptet, und nichts wird verborgen: Kein Commitment und kein Beweis ist verblindet.

Vom Binary zum Contract-Aufruf#

1. Das Programm. Der Loader liest das ELF in ein ProgramImage ein und expandiert dabei komprimierte Befehle an Ort und Stelle. Der Decoder ordnet jeden Befehl einer von sieben Befehlsfamilien zu, baut die dekodierte Tabelle jeder Familie mit einer Zeile pro Halbwort Code und committet dann all das als Programmidentität. Programme und Identität.
2. Ausführung. Der Emulator führt das Gastprogramm (Guest) auf einem Hart aus. Ein Zyklus ist eine Zeile der Familie, der sein Befehl gehört, und zeichnet mit Zeitstempeln versehene Lese- und Schreibzugriffe auf pc, Register und RAM auf. Hashing und Arithmetik mit großen Ganzzahlen werden delegiert: Ein ecall benennt einen Frame im RAM, und eine Zeile einer Delegationsfamilie erledigt die Arbeit darauf. Ausführung, Familien und Shards.
3. Shards. Die Zeilen einer Familie werden in Shards der Höhe dieser Familie geschnitten, einer Zweierpotenz zwischen 2^8 und 2^22. Den Speicher, den eine Ausführung berührt, decken Shards der Fensterfamilien ab, die jedem Wort seinen Anfangs- und seinen Endwert geben. Ein Shard ist die Einheit des Beweisens; ein Block umfasst Hunderte davon.
4. Der Beweis eines Shards. Seine Spalten werden mit Mercury committet. Den Schaltkreis der Familie durchläuft die GKR-Engine rückwärts, von seinen Ausgaben bis zu diesen Spalten, mit einem Sumcheck pro Schicht, und jede Spalte wird an dem einen Punkt, an dem dieser Durchlauf endet, in einer einzigen gebündelten Öffnung geöffnet.
5. Der Block. Ein BlockProof besteht aus der Aussage und ihren Shard-Beweisen. Die Verifikation führt einmal das globale Transkript, die Prüfungen jedes Shards und einmal den Speicherabgleich über die Wurzeln aller Shards aus.
6. Rekursion und Abwicklung. Verifier-Programme, die Apogee selbst beweist, verifizieren Reihen von Shards und falten deren aufgeschobene Pairings. Ein Baum aus ihnen endet in einer Wurzel, ein Groth16-Schaltkreis verifiziert die Wurzel erneut, und ApogeeVerifier.sol prüft diesen Beweis und das gefaltete Pairing. Rekursion und Abwicklung.

Der Prover führt das Gastprogramm zweimal aus: einmal, um die Speicherspalten jedes Shards zu committen, was die Aussage und ihre Challenges festlegt, und einmal, um jeden Shard zu beweisen, sobald er gefüllt ist. Sein Speicherbedarf ist durch die gleichzeitig bearbeiteten Shards beschränkt, nicht durch die Länge der Ausführung. Der Streaming-Prover.

Die Entscheidungen, die das System prägen#

Ein Körper, eine Kurve. Alles liegt über dem Skalarkörper von BN254: die Schaltkreise, das Transkript, die Commitments und die Rekursion. Deshalb kann ein Knoten des Rekursionsbaums Basis-Shards in seiner eigenen Arithmetik verifizieren, und deshalb kann der Baum in einem Groth16-Beweis enden, den Ethereum mit seinem Pairing-Precompile prüft.

Geschichtete GKR-Schaltkreise statt committeter Constraint-Tabellen. Der Schaltkreis einer Familie ist ein Stapel von Gate-Schichten vom Grad 2 über ihren committeten Spalten. Nur die unterste Schicht wird committet; jede Schicht darüber wird in einem einzigen Rückwärtsdurchlauf per Sumcheck bewiesen und nie committet. Der Durchlauf endet mit Behauptungen über jede committete Spalte an ein und demselben Punkt; ein Shard braucht also genau eine Öffnung. Die GKR-Engine erklärt, warum darin die zentrale Ersparnis der Engine liegt.

Eine Öffnung konstanter Größe. Mercury öffnet ein multilineares Commitment mit acht Kurvenpunkten und sechs Körperelementen, 704 Byte, unabhängig von der Größe des Polynoms und davon, wie viele Spalten sich den Punkt teilen. Seine Prüfungen haben die Form e(A, [1]_2) = e(B, [x]_2), die die Rekursion falten kann, statt Pairings zu berechnen.

Ein Speicherargument für die gesamte Ausführung. Jeder Zugriff, in jedem Shard jeder Familie, ist ein Tupel in einer einzigen Lese-/Schreib-Multimenge, und der Verifier gleicht die Produkte einmal pro Aussage ab. Der pc ist eine Zelle dieser Multimenge; Reihenfolge, Kontinuität und Eindeutigkeit der Zyklen über Shards hinweg brauchen also kein weiteres Argument, und kein Shard muss sich mit seinem Nachbarn verketten.

Delegationen als Familien, nicht als Befehle. Eine teure Funktion erhält eine eigene Schaltkreisfamilie, aufgerufen durch einen ecall über einem Frame aus RAM und über dieselbe Multimenge eins zu eins mit ihrer Anfrage gepaart. Die Befehlsschaltkreise bleiben klein, und ein Gastprogramm bezahlt für eine Delegation nur, wenn es sie aufruft.

Streaming statt Materialisierung. Der Trace wäre mit etwa 300 Byte pro Zyklus das größte Objekt im System; deshalb existiert er nie. Der Prover führt zweimal aus und hält nur die Shards, die gerade bearbeitet werden.

Keine geliehene Kryptografie. Körper, Kurve, Pairing, MSM, Hash, Polynom-Commitment, GKR und Groth16 sind im Repository implementiert und Seite für Seite spezifiziert. arkworks, Plonky3 und zkhash kommen nur als Testorakel vor.

Wie sich die Soundness zusammensetzt#

Der GKR-Durchlauf und die Öffnung jedes Shards binden die Ausgaben seines Schaltkreises an committete Spalten. Darüber hinaus erstrecken sich diese Argumente über die gesamte Ausführung:

Die Challenges stammen aus einem Poseidon2-Duplex-Transkript. Das globale Transkript absorbiert die gesamte Aussage, einschließlich der Speicher-Commitments jedes Shards, bevor es die Speicher-Challenges gibt; das Transkript jedes Shards wird aus dem Endzustand des globalen Transkripts initialisiert. Die Soundness-Karte führt jede Zeile dieser Tabelle bis zu den Abschnitten, die sie beweisen.

Der Code, nach Schichten#

Der Verifier ist die einzige Partei, der vertraut wird: Der Prover validiert nichts, und eine falsche Eingabe führt bei einem ehrlichen Prover zu einem Beweis, der fehlschlägt. Das Sicherheitsmodell führt genau auf, auf welchen Crates die Soundness beruht.

Bevor irgendetwas ausgeführt wird, macht Apogee aus dem Binary des Gastprogramms (Guest) eine feste Beschreibung des Programms: sein Image, seine nach Schaltkreisfamilien sortierten Befehle, die Konfiguration, unter der es bewiesen wird, und ein einziges Körperelement, das all das committet. Jeder Schritt ist eine reine Funktion seiner Eingabe.

Laden#

Der Loader akzeptiert ein statisches 32-Bit-RISC-V-Executable im Little-Endian-Format, dessen ladbare Segmente im RAM des Gastprogramms an geraden Adressen liegen, paarweise disjunkt und mindestens eines davon ausführbar. Aus einem Program Header liest er Typ, Offsets, Größen und das Ausführbarkeits-Bit und sonst nichts: Die VM hat keine Speicherseiten und keine Berechtigungen, und der gesamte RAM ist adressierbar, was auch immer die Segmente deklarieren.

Danach durchläuft er jedes ausführbare Segment Halbwort für Halbwort. Ein Halbwort, das binär auf 11 endet, beginnt einen 4-Byte-Befehl; das Null-Halbwort ist ein Nicht-Befehl (LLVM füllt unerreichbare Blöcke damit auf); alles andere ist ein komprimierter Befehl, der an Ort und Stelle zu seiner 32-Bit-Form expandiert wird. Adressen werden nie verdichtet: Ein c.addi bei 0x1002 bleibt dort und belegt zwei Byte; jede vom Linker aufgelöste Adresse bleibt also gültig, und allein die Länge eines Befehls hält fest, ob der nächste pc pc + 2 oder pc + 4 ist.

Ein desynchronisierter Durchlauf kann keinen falschen Befehl beweisbar machen. Ein Slot ist eine Funktion der Bytes an seinem eigenen pc; jeder Befehls-Slot ist also das, was ein Hart dekodieren würde, der dort einen Befehl holt. Daten, die den Durchlauf von den wahren Grenzen verschieben, können nur echte Befehlsanfänge verlieren, deren pcs dann keine Tabellenzeile haben, oder auf eine nicht zugewiesene Kodierung treffen, woraufhin das ganze Image zurückgewiesen wird.

Dekodieren und Zuordnen#

Der Decoder nimmt nur 32-Bit-Wörter entgegen und akzeptiert genau die 59 Befehle von RV32IMA: 40 aus dem Basissatz, 8 aus M, 11 aus A. Alles andere, von RV64-Kodierungen und Gleitkomma bis zu CSRs und fence.i, ist ein Dekodierfehler, und ein einziges nicht dekodierbares Wort irgendwo im ausführbaren Code führt zur Zurückweisung des Programms, ob erreichbar oder nicht. Jeder Befehl wird genau einer von sieben Befehlsfamilien zugeordnet:

Die Gruppierung folgt dem, was die Schaltkreise gemeinsam haben. Ein einziges Vergleichs-Gadget entscheidet die Ordnung mit und ohne Vorzeichen für jede Art von Verzweigung und slt; eine einzige Produktidentität dient allen vier Multiplikationen und der Division; ein Shift in jede Richtung ist ein einziges Produkt mit einer nachgeschlagenen Zweierpotenz.

Dekodierte Tabellen#

Jede Befehlsfamilie erhält eine dekodierte Tabelle: ihre Setup-Spalten, in denen Zeile i zu pc 2i gehört, eine Zeile pro Halbwort des Adressraums, den die Tabelle erreicht. Eine aktive Zeile enthält einen der Befehle der Familie als Tupel pc, next_pc, rs1, rs2, rd, imm, extra_mask, wobei ein einzelnes Bit der Maske das Mnemonic benennt. Jede andere Zeile ist Padding, −1 in jedem Feld; keine aktive Zeile ist also je die Padding-Zeile, und eine Zeile aus lauter Nullen ist nie ein beanspruchbarer Befehl bei pc 0.

Die Zeile jedes Zyklus schlägt sich selbst anhand ihres pc in der Tabelle ihrer Familie nach. Dieser Lookup bindet eine Ausführung an das Programm: Der Befehl einer Zeile ist der Befehl des Programms an diesem pc, und ein pc ohne aktive Zeile in irgendeiner Tabelle kann nicht beweisbar ausgeführt werden. Code ist daher statisch. Ein Store in .text ändert, was ein späterer Load liest, nie, was ausgeführt wird.

Die Konfiguration#

Die statische Form eines Programms ist seine VmConfig: die Familien, die es verwendet, jede mit einer Höhe, und eine Obergrenze für seine Codegröße. Die Menge der Familien wird nicht gewählt, sondern abgeleitet:

• eine Befehlsfamilie ist vorhanden, wenn das Image einen ihrer Befehle enthält;
• die fünf Fensterfamilien, die den Speicher initialisieren und abschließen, sind immer vorhanden;
• eine Delegationsfamilie ist vorhanden, wenn das Image sie deklariert, über einen 12-Byte-Datensatz, den das Linken ihres Shims unter den Bytes des Images hinterlässt.

Die Höhe einer Familie ist die Zahl der Zeilen in einem ihrer Shards, gewählt aus 2^8, 2^12, 2^16, 2^18, 2^20, 2^22. Jede Höhe ist eine Zweierpotenz mit geradem Exponenten, weil eine Mercury-Öffnung das verlangt. Höhen sind ein Parameter des Programms, nicht eines Laufs, und jede Wahl der Höhen ist ein eigenes Programm.

Programmidentität#

Die Programmidentität ist ein einziges Element von Fr: ein Poseidon2-Digest über die Codeversion, die VmConfig, den Einsprung-pc und die Setup-Commitments jeder Familie, also die Mercury-Commitments auf die dekodierten Tabellen und auf die anfänglichen Speicherwörter des Images.

Sie bindet jeden Befehl, den der Durchlauf gefunden hat, mit seinem pc, seiner Länge, seinen Operanden und seiner Art, sowie die Tatsache, dass kein anderer pc einen Befehl enthält; jedes in der Datei enthaltene Byte des Images, was die Delegationsdeklarationen einschließt; den Einsprung-pc; die Menge der Familien, jede Höhe, die Obergrenze der Codegröße und die Codeversion. Sie bindet nicht die Zeremonie oder die generische Lookup-Tabelle, die der SRS-Digest abdeckt; nicht die Schaltkreise, die beim Laden eines Schlüssels mit der Registry des Verifiers abgeglichen werden; nichts, was eine Ausführung wählt; und nichts aus dem ELF, was der Loader nicht liest, etwa die Symboltabelle.

Ihre Berechnung braucht die Potenzen der Zeremonie, um zu committen. Ihre Prüfung braucht nur die Commitments, die ein Verifikationsschlüssel mitführt: Beim Laden eines Schlüssels wird die Identität aus ihnen neu berechnet, und die Öffnung jedes Shards prüft seine Setup-Spalten gegen dieselben Punkte. Das verbindet die Tabellen, die ein Beweis liest, mit der Identität, die ein Verifier registriert hat.

Die Spezifikation: Programm und Identität.

Die Maschine#

Der Emulator führt RV32IMAC auf einem Hart über einem ProgramImage aus, ohne Interrupts und ohne Privilegstufen. Ein Lauf ist eine reine Funktion des Images und seiner Eingabe, ohne Uhr, Zufall oder Threads; zwei Läufe schneiden also identische Shards. Von einer gehosteten RV32IMAC-Umgebung weicht er in drei Punkten ab: sc.w gelingt immer, ein nicht ausgerichteter Halbwort- oder Wortzugriff ist fatal, statt aufgeteilt zu werden, und der Befehlsstrom ist das beim Laden dekodierte Image.

Jede andere Art, wie ein Lauf vor EXIT enden kann, etwa ein Zugriff außerhalb der gemappten Bereiche, ebreak oder ein Sprung zu einem Halbwort ohne Befehl, ist ein fataler Fehler ohne Trace. Ein solcher Lauf hat keinen Beweis. Ein Exit-Status ungleich null ist kein Fehler: Es handelt sich um eine Ausführung wie jede andere, und sie ist beweisbar.

Die Uhr und die Abfrage#

Zyklus c belegt die vier Zeitstempel 4c + Δ, einen pro Slot Δ ∈ {0, 1, 2, 3}. Jeder Befehl ist ein Zyklus, und sonst ist nichts ein Zyklus: Ein Delegationsaufruf läuft im Zyklus mit, der ihn angefordert hat. Zyklen werden ab 1 gezählt, weil Zeitstempel 0 der anfängliche Schreibzugriff jeder Adresse ist. Die Uhr hat 38 Bit; eine Ausführung läuft also höchstens 2^36 − 1 Zyklen.

Jeder Speicherzugriff ist eine Abfrage: ein Lesezugriff auf einen Wert, der zuletzt zu einem früheren Zeitstempel geschrieben wurde, und ein Schreibzugriff zum aktuellen Zeitstempel. Eine Abfrage, die nur liest, schreibt zurück, was sie gelesen hat. Slot 0 jedes Zyklus ist die pc-Abfrage, die pc liest und next_pc schreibt. Danach folgen die Register- und Speicherabfragen des Befehls an festen Slots:

Adressen liegen in Adressräumen: die 32 Register, der RAM in Wörtern mit 4-Byte-Ausrichtung, der pc, ein Ankerraum pro Delegationstyp und die Körperzellen des Rekursionsformats. x0 ist im Trace ein gewöhnliches Register und in der Maschine eine Konstante: Jede Abfrage an diesem Register liest und schreibt 0.

Dreiundzwanzig Familien#

Eine Familie ist ein Schaltkreis zusammen mit den Zeilen, die er beweist. Es gibt vier Arten:

Jeder Zyklus geht an die eine Ausführungsfamilie, deren dekodierte Tabelle seinen pc beansprucht. Familien wechseln sich zeitlich ab: ADD_SUB_LUI_AUIPC kann die Zyklen 1 und 3 besitzen und JUMP_BRANCH_SLT den Zyklus 2. Nichts verlangt, dass sie zusammenhängend sind, weil das Speicherargument jede Zeile über ihren pc-Schreibzugriff ordnet.

Die Fensterfamilien gibt es, weil das Speicherargument verlangt, dass jede Adresse, die eine Ausführung berührt, genau einen Anfangswert und einen Endwert hat. INIT_TEARDOWN deckt RAM-Fenster 0 ab und belegt es zu Beginn mit dem Image des Programms; ZERO_WINDOWS deckt jedes andere Fenster gewöhnlichen RAMs ab, das der Lauf berührt hat, und belegt es zu Beginn mit null; das öffentliche Paar deckt die Fenster für Eingabe und Journal ab; ADVICE_WINDOWS deckt den Bereich der Hilfsdaten (Advice) ab und belegt ihn zu Beginn mit den Bytes des Provers.

Shards#

Die Zeilen einer Familie werden in der Reihenfolge ihres Auftretens in Shards der Höhe dieser Familie geschnitten. Der letzte wird mit Nullzeilen aufgefüllt, die die Schaltkreise per Konstruktion akzeptieren. Ein Shard kostet seine volle Höhe, unabhängig von seiner Belegung; die Familien, die ein Programm berührt, und die Höhen, die es wählt, bestimmen also die Untergrenze jedes Beweises.

Ein Shard wird für sich bewiesen, durch den Schaltkreis seiner Familie, mit Ausnahme des Speicherarguments: Der Schaltkreis jedes Shards gibt das Produkt seiner Lesetupel und das Produkt seiner Schreibtupel aus, und der Verifier gleicht diese Produkte einmal über alle Shards der Aussage ab. Das ist das Einzige, was Shards verbindet. Es gibt keine Verkettung des pc von Shard zu Shard und keinen gemeinsamen Rand zwischen Nachbarn.

Die Größen der Shard-Beweise bei den Standardhöhen reichen von etwa 12,5 KB für ein öffentliches Fenster bis zu 665 KB für einen POSEIDON2-Shard; der Beweis einer Befehlsfamilie liegt bei 64 bis 77 KB. Die Tabelle steht unter Performance.

Die Spezifikation: Ausführungs-Trace, Schaltkreise und Registry.

Jeder Shard in Apogee wird auf dieselbe Weise bewiesen: durch den Schaltkreis seiner Familie, geschrieben als Stapel von Schichten, den die GKR-Engine rückwärts durchläuft, von den Ausgaben des Schaltkreises bis zu seinen committeten Spalten. Diese Seite erklärt, warum diese Engine im Zentrum des Systems steht und warum sich die Front des Beweisens in Richtung der Familie von Beweissystemen bewegt, zu der sie gehört.

Die Idee#

Der klassische Weg, eine Berechnung zu beweisen, besteht darin, sie als Tabelle anzulegen, jede Spalte einschließlich der Zwischenwerte zu committen und zu beweisen, dass eine Menge von Constraints über der Tabelle verschwindet. Die Commitments sind der teure Teil: Jede committete Spalte kostet eine Multi-Skalar-Multiplikation oder einen Merkle-Baum und eine Öffnung an jedem Punkt, nach dem das Constraint-Argument fragt.

GKR, nach Goldwasser, Kalai und Rothblum, ändert, was committet werden muss. Die Berechnung ist ein geschichteter Schaltkreis. Nur die unterste Schicht, die Eingaben, wird committet. Jede Schicht darüber ist durch Gates über der Schicht darunter definiert, und der Prover committet sie nie. Stattdessen wird eine Behauptung über die oberste Schicht durch einen Sumcheck auf eine Behauptung über die Schicht darunter zurückgeführt, dann auf die nächste, bis die Behauptungen bei den committeten Eingaben ankommen, alle an einem einzigen zufälligen Punkt. Eine einzige Öffnung löst sie ein.

Was das einer zkVM einbringt:

• Zwischenwerte kosten kein Commitment. Ein Familienschaltkreis kann Hunderte innerer Spalten, Produktbäume und Bruchbäume berechnen, und nichts davon wird je committet. Nur seine Trace-Spalten werden committet.
• Ein Öffnungspunkt pro Shard. Der Rückwärtsdurchlauf endet mit Behauptungen über jede committete Spalte an demselben Punkt. Ein Shard braucht genau eine gebündelte Öffnung, 704 Byte, unabhängig davon, wie viele Spalten er hat.
• Die Arbeit des Provers ist Körperarithmetik. Der Sumcheck jeder Schicht ist linear in der Größe der Schicht, über Fr, ohne Commitment, Transformation oder Hash pro Schicht.
• Argumente setzen sich innerhalb des Schaltkreises zusammen. Die Grand Products des Speicherarguments und die LogUp-Summen der Lookups sind einfach weitere Schichten desselben Schaltkreises, reduziert im selben Durchlauf.

Ein Familienschaltkreis, Schicht für Schicht#

Die unterste Schicht bilden die committeten Spalten des Shards, in drei Arten, die sich darin unterscheiden, wann sie gebunden werden: M, die Speicherspalten, committet im globalen Transkript der Aussage, bevor es irgendeine Speicher-Challenge gibt; W, die Witness-Spalten, committet im eigenen Transkript des Shards; und S, die Setup-Spalten, gebunden durch die Programmidentität oder durch die Zeremonie. Daneben stehen virtuelle Tabellen: geschlossene Formen wie der Zeilenindex oder der 16-Bit-Bereich, die der Verifier an jedem beliebigen Punkt auswertet und die nie committet werden.

Oberhalb von Schicht 0 hat jeder Familienschaltkreis denselben Aufbau:

1. Gate-Liste 0 berechnet Zeile für Zeile die Speicherblätter (die Lese- und Schreibtupel jeder Abfrage), die Lookup-Brüche (ein Paar (numerator, denominator) pro Lookup, dazu das der Tabelle) und jedes Constraint-Gate: die Constraints der Familie, jedes ein Polynom, das auf jeder Zeile verschwinden muss.
2. Zeilenweise Listen kombinieren Geschwisterblätter: Ein Produktbaum multipliziert Tupel, ein Bruchbaum addiert Brüche als (n_a·d_b + n_b·d_a, d_a·d_b), bis jede Zeile einen Knoten pro Baum enthält.
3. Halbierende Listen, eine pro Variable der Höhe des Shards, kombinieren die Zeilen paarweise: die erste Hälfte mit der zweiten. Nach n von ihnen erreicht der Schaltkreis eine Spitze ohne Variablen: die Lesewurzel des Shards, seine Schreibwurzel sowie den finalen Zähler und Nenner jedes Lookup-Kanals.

Ein einziger Schaltkreis beweist also die Constraints der Familie, berechnet ihren Beitrag zum Speicherargument und summiert ihre Lookups, in einem einzigen Durchlauf. Jedes Gate hat höchstens Grad 2; jedes Rundenpolynom jedes Sumchecks ist also kubisch.

Der Rückwärtsdurchlauf#

Der Prover materialisiert jede Schicht einmal, von unten nach oben. Der Beweis läuft dann nach unten, und sein Transkriptablauf ist für jeden Schaltkreis derselbe:

1. Die Ausgaben werden zuerst absorbiert, sodass der Prover an die Wurzeln gebunden ist, bevor es irgendeine Challenge gibt.
2. Für jeden Übergang von Schicht k + 1 hinunter zu Schicht k bündelt eine Challenge λ jede Behauptung über Schicht k + 1 zusammen mit jedem Constraint-Gate der Liste zu einer einzigen Summe. Ein Sumcheck reduziert diese Summe auf eine Auswertung an einem zufälligen Punkt ρ, mit einer kubischen Nachricht pro Variable.
3. Der Prover nennt die Werte der Spalten von Schicht k an der Stelle ρ. Bei einer halbierenden Liste nennt er beide Kinder, und eine weitere Challenge τ führt sie zu einer Behauptung pro Spalte zusammen.
4. Auf Schicht 0 hat jede committete Spalte eine einzige Behauptung, alle am selben Punkt u.

Die eine Mercury-Öffnung des Shards beweist diese Behauptungen gegen die Commitments: die der Speicherspalten aus der Aussage, die der Witness-Spalten aus dem Shard-Beweis, die der Setup-Spalten aus dem Verifikationsschlüssel. Virtuelle Tabellen wertet der Verifier selbst aus.

Constraint-Gates fahren kostenlos mit. Ein Constraint-Gate behauptet überall 0; es tritt also dem Batch des Übergangs bei, in dem es liegt, und ein verletztes Gate macht die gebündelte Summe mit überwältigender Wahrscheinlichkeit ungleich null. Ein einziger Fehler LayerInconsistency deckt eine falsche absteigende Behauptung und ein verletztes Gate gleichermaßen ab; eine gebündelte Summe kann die beiden nicht unterscheiden, und der Beweis wendet nichts dafür auf, sie zu unterscheiden.

Woher die Soundness kommt#

Jede Challenge wird nach allem gezogen, was sie schützt:

• der Ausgabepunkt nach den Ausgaben, sodass ein Prover keine Tabellen wählen kann, die nur dort mit der Wahrheit übereinstimmen, wo geprüft wird;
• λ nach den Behauptungen und dem Punkt, sodass eine falsche Behauptung oder ein verletztes Gate nur an einer Nullstelle eines von null verschiedenen Polynoms in λ überlebt;
• jede Sumcheck-Challenge nach dem kubischen Polynom ihrer Runde, sodass ein falsches kubisches Polynom mit Wahrscheinlichkeit höchstens 3/|Fr| mit dem richtigen übereinstimmt;
• τ nach den Werten beider Kinder.

Summiert über alle Übergänge eines registrierten Schaltkreises bei seiner Standardhöhe bleibt der Soundness-Fehler unter 2^14/|Fr|, mit Fiat–Shamir über dem Poseidon2-Transkript im Random-Oracle-Modell.

Schaltkreise als Daten#

Ein Schaltkreis ist kein Code. Er ist ein CircuitArtifact: seine committeten Spalten mit Namen, seine virtuellen Tabellen, seine Gate-Listen mit sieben Gate-Formen, eine flache Liste derselben Relationen, seine Lookups und seine Padding-Zeile, kanonisch serialisiert. Vier Gesetze halten jedes Artefakt in einer konsistenten Form: Jeder Operand ist dort lesbar, wo er gelesen wird, die Breite jeder Liste wird aus ihren Gates abgeleitet, die oberste Schicht besteht genau aus den Ausgaben, und die geschichteten Gates und die flachen Relationen bilden eine einzige Constraint-Menge. Sie laufen einmal, dort, wo ein Artefakt gebaut oder ein Schlüssel geladen wird, nie pro Beweis.

Zwei Folgen sind für alle wichtig, die das System bewerten:

• Ein Verifikationsschlüssel führt seine Schaltkreise mit, und der Verifier gleicht sie mit seiner eigenen Registry ab. Die Programmidentität bindet das Programm; die Registry bindet die Schaltkreise, die es beweisen.
• Die Schaltkreise lassen sich von einer zweiten Implementierung prüfen. Das Crate checker implementiert die Gesetze, die Lookup-Regeln und den Padding-Vertrag neu, ohne Code mit den Konstruktoren zu teilen, und wertet Gates ausschließlich über den einen Gate-Kernel aus, den beide Seiten als semantische Autorität verwenden.

Die Kosten#

Die Engine tauscht Commitments gegen Speicher. Der Vorwärtsdurchlauf hält jede innere Schicht als Körperelemente: etwa 8,4 GiB für einen 2^20-Shard der breitesten Befehlsfamilie und 42 GiB für einen KECCAK_F-Shard der Höhe 2^18, dessen Schaltkreis 5.490 innere Spalten berechnet. Deshalb ist die Beweiserzeugung speichergebunden, deshalb sind Höhen ein Tuning-Parameter, und deshalb beschränkt der Streaming-Prover den Speicherbedarf durch die gleichzeitig bearbeiteten Shards. Die Beweisgröße wächst nur um eine Sumcheck-Runde pro Variable und Schicht: Der Beweis eines KECCAK_F-Shards umfasst 381.100 Byte bei 2^18 gegenüber 373.276 bei 2^16, für die vierfache Arbeit.

Die Spezifikation: Die GKR-Engine sowie die eigene Seite jeder Familie unter Auditoren.

Jede Spalte, die Apogee committet, ist ein multilineares Polynom, eine Tabelle von 2^n Auswertungen über dem booleschen Hyperwürfel. Jede davon wird mit Mercury (Eagen und Gabizon, ePrint 2025/385) committet und geöffnet, abgeschlossen durch die gebündelte KZG-Öffnung von BDFG20 (Boneh, Drake, Fisch und Gabizon, ePrint 2020/081). Die Spezifikation legt fest, was die Arbeiten offenlassen, und fügt zwei Dinge hinzu: einen Batch vieler Spalten an einem Punkt und eine aufgeschobene Form, die der Rekursionsbaum faltet.

Das Commitment#

Ein Mercury-Commitment ist genau das KZG-Commitment der Auswertungstabelle, gelesen als Koeffizienten: eine Multi-Skalar-Multiplikation über die ersten n Potenzen des τ der Zeremonie, ein G1-Punkt, 64 Byte. Dahinter steht kein zweites Verfahren. Daraus folgen zwei Eigenschaften, und der Rest des Systems nutzt beide:

• Es ist linear. Das Commitment von Σ ρ^i·f_i ist Σ ρ^i·cm_i; deshalb können sich viele Spalten eine Öffnung teilen.
• Nullkoeffizienten tragen nichts bei. Eine um Nullzeilen erweiterte Spalte behält ihr Commitment; die drei Commitments der generischen Lookup-Tabelle dienen also jeder Höhe, die die Tabelle aufnimmt, und sie sind eine Konstante der Zeremonie.

Spalten werden mit ihrer Ganzzahlbreite committet: Eine Bit-, Byte-, Halbwort- oder Wortspalte läuft durch eine MSM über u32-Skalare, umkodiert aus 32 statt 254 Bit, was das Committen eines Trace günstig hält.

Die Öffnung#

Mercury teilt einen Öffnungspunkt u mit s = 2t Variablen in zwei Hälften, faltet das Polynom mit einer Challenge α und beweist die beiden verbleibenden inneren Produkte mit einem symmetrisierten Witness, abgeschlossen durch eine einzige gebündelte KZG-Öffnung an drei Punkten. Der Beweis besteht aus acht G1-Punkten und sechs Körperelementen: 704 Byte, für jede Größe. Daraus folgt eine Anforderung: Die Zahl der Variablen muss gerade sein, und deshalb ist jede Höhe in der Auswahl eine Zweierpotenz mit geradem Exponenten.

Der Verifier führt O(t) Körperoperationen, MSMs über zehn und über zwei Punkte und eine Pairing-Prüfung mit zwei Paaren aus. Beide Relationen, die er prüft, sind als e(A, [1]_2) = e(B, [x]_2) geschrieben; beide G2-Argumente sind also Konstanten des Setups, und der Verifier führt überhaupt keine G2-Arithmetik aus. Diese Form erlaubt es der Rekursion auch, das Pairing aufzuschieben, statt es zu berechnen.

Die Spalten eines Shards, eine Öffnung#

Der GKR-Durchlauf endet mit Behauptungen über jede committete Spalte eines Shards am selben Punkt u. Es braucht also keinen Sumcheck, der Behauptungen zusammenführt: Die Öffnung bündelt sie alle. Eine Challenge ρ, gezogen nach jedem Commitment und jedem behaupteten Wert, gewichtet Spalte i mit ρ^i; der Prover öffnet Σ ρ^i·f_i einmal, und der Verifier bildet Σ ρ^i·cm_i durch eine MSM über k Punkte. Eine falsche Behauptung überlebt mit Wahrscheinlichkeit höchstens (k − 1)/|Fr|.

Die Spalten im Batch stammen aus drei Quellen, in einer festen Reihenfolge, die Teil dessen ist, was bewiesen wird: die Commitments der Speicherspalten aus der Aussage, die der Witness-Spalten aus dem Shard-Beweis und die der Setup-Spalten aus dem Verifikationsschlüssel. Weil die Setup-Commitments dem Schlüssel entnommen werden, bindet die Öffnung die dekodierten Tabellen und das Image, die die Programmidentität committet.

Aufgeschobene Verifikation#

Eine aufgeschobene Prüfung führt alles außer dem Pairing aus und behält die Terme der Relation als zwölf Einträge (side, scalar, point). Genau das nutzt die Rekursion: Jeder Knoten des Baums berechnet die zwölf Skalare eines Shards in seiner eigenen Arithmetik, gewichtet sie mit frischen Challenges und addiert sie in ein einziges laufendes Punktepaar (A, B). Die Öffnung jedes Shards im gesamten Baum wird in eine einzige Behauptung e(A, [1]_2) = e(B, [x]_2) gefaltet, die erst der Contract auf Ethereum endgültig prüft. Rekursion und Abwicklung zeigt das Falten.

Gemessen#

Auf einem Apple M5 Pro mit 18 Kernen:

Sicherheit#

Knowledge Soundness gilt im algebraischen Gruppenmodell unter q-DLOG, mit Fiat–Shamir über dem Poseidon2-Transkript im Random-Oracle-Modell und einem SRS, dessen τ niemand kennt. Die statistischen Terme, Schwartz–Zippel über die Challenges, bleiben für jede verwendete Instanz unter 2^−220; das Sicherheitsniveau ist also das von BN254, etwa 100 Bit. Nichts ist hiding, und nichts wird verblindet: Apogee v1.0.0 ist nicht zero-knowledge.

Als SRS dienen die Perpetual Powers of Tau der PSE, Beitrag 80, deren Soundness gegeben ist, solange ein Beitragender ehrlich war. Ihre Datei wird dekodiert, und für jeden Punkt wird geprüft, dass er auf seiner Kurve und in der richtigen Untergruppe liegt; nichts beweist, dass eine Datei die dieser Zeremonie ist, und deshalb vergleicht ein Verifier den SRS-Digest mit dem der Zeremonie aus seinem eigenen Kanal.

Die Spezifikation: Mercury, Der strukturierte Referenzstring.

Die Gates einer Familie stellen Bedingungen an jeweils eine Zeile. Alles, was über Zeilen, Shards oder Familien hinausreicht, etwa was ein Register enthält, was ein Load liefert, welchen Befehl eine Zeile ausführt und ob ein Wert in 32 Bit passt, tragen zwei Argumente, die in denselben GKR-Schaltkreisen leben.

Das Speicherargument#

Jeder Speicherzugriff wird zu einem Körperelement, einem Tupel:

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

über dem Adressraum, der Adresse, dem Zeitstempel und dem Wert, mit vier Challenges, die einmal pro Aussage gezogen werden. Eine Abfrage trägt ihr Lesetupel zu einer Seite bei und ihr Schreibtupel zur anderen. Der Schaltkreis jedes Shards gibt zwei Zahlen aus, das Produkt seiner Lesetupel und das Produkt seiner Schreibtupel. Der Verifier prüft dann eine einzige Gleichung über die gesamte Aussage:

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

W_b und R_b sind die Anfangs- und Endtupel der 32 Register und des pc, die keine eigenen Zeilen haben: Der Verifier bildet sie aus 64 Randskalaren, die die Aussage mitführt, und multipliziert sie ein. Der RAM erhält seine Anfangs- und Endwerte aus den Shards der Fensterfamilien, die ein Wort pro Zeile enthalten: das Image des Programms in Fenster 0, Nullen in jedem anderen Fenster, das der Lauf berührt hat, die Eingabe der Aussage im öffentlichen Eingabefenster, die Bytes des Provers in den Hilfsdaten (Advice).

Gilt die Gleichung, sind die Multimengen mit überwältigender Wahrscheinlichkeit gleich. Gleiche Multimengen bedeuten, dass jeder Lesezugriff den letzten Schreibzugriff davor liefert: Jeder Lesezugriff wird genau einem Schreibzugriff zugeordnet, ein Lesezugriff muss strikt auf den Schreibzugriff folgen, den er konsumiert, und jede Adresse hat genau einen anfänglichen Schreibzugriff.

Reihenfolge ohne Zusatzkosten#

Der pc ist eine Speicherzelle wie jede andere, an Adresse 0 seines eigenen Adressraums. Jede Zeile liest den pc und schreibt den nächsten, und ihr Schaltkreis erzwingt, dass der Schreibzugriff mindestens vier Zeitstempel nach dem Lesezugriff liegt. Die Historie des pc ist also ein einziger Pfad durch jede aktive Zeile jeder Familie, vom Einsprungpunkt bis zur Exit-Zeile. Dieser eine Pfad liefert:

• Programmreihenfolge, da Zeilen nach ihren pc-Schreibzugriffen geordnet sind;
• Kontinuität über Shards und Familien hinweg, da der pc-Lesezugriff jeder Zeile den pc-Schreibzugriff irgendeiner Zeile konsumiert;
• keinen doppelt bewiesenen Zyklus, da kein Schreibzugriff zweimal konsumiert werden kann.

Kein Shard ist mit seinem Nachbarn verkettet, und keiner muss es sein. Das behauptete Zeitfenster eines Shards bindet nichts; es wird nur auf seine Form geprüft.

Was zuerst feststehen muss#

Die Speicher-Challenges werden einmal pro Aussage gezogen, am Ende des globalen Transkripts, nachdem alles feststeht, was ein Tupel lesen kann: die Speicher-Commitments jedes Shards, die Programmidentität (die den Einsprung-pc und das Image festlegt), der Digest der Zeremonie, die Shard-Zahlen und die Fensterliste, der Digest von öffentlicher Eingabe und Journal und zuletzt die 64 Randskalare. Ein nach den Challenges gewählter Wert ließe sich passend errechnen; die Reihenfolge des Transkripts verhindert das. Aus demselben Grund darf ein Speichertupel nur Speicher-, Setup- und virtuelle Spalten lesen, nie eine Witness-Spalte, die im eigenen Transkript des Shards nach den Challenges committet wird. Die Schaltkreiskonstruktoren weisen jedes Artefakt zurück, das dagegen verstößt.

Lookups#

Ein Lookup besagt, dass ein Tupel aus Werten einer Zeile eine Zeile irgendeiner Tabelle ist. Apogee beweist jeden Lookup eines Shards mit LogUp: eine Identität pro Tabelle oder Kanal,

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

summiert über einen Bruchbaum im eigenen GKR-Schaltkreis der Familie und an dessen Wurzel geprüft: Zähler null, Nenner ungleich null. Die Multiplizitätsspalte braucht überhaupt keinen Constraint: Ein Tupel, das in keiner Tabellenzeile vorkommt, hinterlässt eine Polstelle, die die Multiplizitäten nicht aufheben können.

Drei der Tabellen sind virtuell: geschlossene Formen des Zeilenindex, die der Verifier selbst auswertet und die kein Commitment kosten. Die generische Tabelle wird einmal mit den Potenzen der Zeremonie committet und ist durch den SRS-Digest abgedeckt.

Der Decoder-Lookup#

Jede Ausführungsfamilie macht pro aktiver Zeile einen Lookup in ihre eigene dekodierte Tabelle, mit dem pc als Schlüssel, den die Zeile aus dem Speicher gelesen hat. Dieser eine Lookup bindet den Zyklus an das Programm: Operanden, Immediate und Befehlsart der Zeile sind die des Programms an diesem pc, und ihre Bits für die Befehlsart sind one-hot, weil jede aktive Zeile der Tabelle eine One-hot-Maske enthält und jede Padding-Zeile −1, was keine Summe solcher Bits erreicht. Eine Zeile an einem pc, an dem das Programm keinen Befehl hat, findet überhaupt keine Tabellenzeile.

Schlüssel müssen beschränkt sein#

Ein Kanal beweist die Zugehörigkeit zu einer Tabelle und nichts weiter. Mehrere Teiltabellen teilen sich die generische Tabelle unter disjunkten Schlüsselbereichen; ein unbeschränkter Schlüssel könnte also in der falschen Teiltabelle landen und ein falsches AND beweisen. Jede Familie beschränkt deshalb jeden Schlüssel, den sie nachschlägt, mit einem Bereichs-Lookup unter demselben Selektor, und die Schaltkreiskonstruktoren prüfen, dass eine über einen Skalierungsfaktor geschriebene Schranke zusätzlich eine direkte Schranke trägt. Die Spezifikation nennt für jede Familie den Angriff, den das verhindert.

Wie sich alles zusammenfügt#

Zusammen mit den Gates jeder Familie geben diese beiden Argumente der Aussage ihre Bedeutung: Jede Zeile befolgt ihren Befehl, der Befehl ist der des Programms, jeder Lesezugriff sieht den letzten Schreibzugriff, die Zeilen bilden einen einzigen Pfad vom Einsprung bis zum Exit, jeder Wert ist die ganze Zahl, die er zu sein behauptet, und die öffentlichen Fenster enthalten die Bytes der Aussage. Die Soundness-Karte führt jede Behauptung zu den Abschnitten, die sie beweisen.

Die Spezifikation: Das Speicherargument, Lookups.

Hashing und Arithmetik mit großen Ganzzahlen dominieren reale Arbeitslasten: In einem Ethereum-Mainnet-Block machten allein die Körpermultiplikation und -quadrierung von secp256k1 44 % der Zyklen aus, bevor sie delegiert wurden. Sie Befehl für Befehl zu beweisen ist möglich und langsam. Eine Delegation gibt einer solchen Funktion eine eigene Schaltkreisfamilie, die aus dem Gastprogramm (Guest) aufgerufen wird; die Befehlsschaltkreise bleiben so klein, und ein Programm bezahlt nur für die Delegationen, die es aufruft.

Der Aufruf#

Eine Delegation wird aufgerufen, nie dekodiert. Das Gastprogramm schreibt einen Frame aus 32-Bit-Wörtern in den RAM und setzt einen ecall ab, mit der Nummer der Delegation in a7 und der Basisadresse des Frames in a0. Der ecall ist eine Zeile der Familie ADD_SUB_LUI_AUIPC, die Anfrage. Die Arbeit ist eine Zeile der eigenen Familie der Delegation, der Aufruf, der im anfragenden Zyklus jedes Frame-Wort liest und jedes Frame-Wort zurückschreibt, darunter die Ergebnisse. Ein Aufruf besitzt keinen Zyklus; er läuft in dem Zyklus mit, der ihn angefordert hat.

Frames sind wortausgerichtet und liegen vollständig im gewöhnlichen RAM; kein Frame überlappt also ein öffentliches Fenster oder die Hilfsdaten (Advice), und die Lese- und Schreibzugriffe des Frames sind gewöhnliche Speicherabfragen. Was eine Delegation berechnet hat, ist daher genau so gebunden wie jeder Store: über die eine Speicher-Multimenge.

Der Anker#

Anfragen und Aufrufe müssen sich eins zu eins paaren: Sonst könnten viele Anfragen gegen einen einzigen Aufruf aufgehen und Anfragen unausgeführt zurücklassen, oder ein nicht angefragter Aufruf könnte einen Frame überschreiben. Sie paaren sich über dieselbe Speicher-Multimenge, in einem Ankerraum, der allein dem Delegationstyp gehört und den kein Befehl erreichen kann:

Drei Gates auf der Anfrageseite legen ihren Lesezugriff auf Zeitstempel 0 und Wert 0 fest und lassen sie 0 in a0 schreiben. Dann sind die mit 0 gestempelten Tupel genau die Lesezugriffe der Anfragen und die Antworten der Aufrufe; es gibt also ebenso viele Aufrufe wie Anfragen über denselben Basisadressen; und da keine zwei Anfragen einen Zyklus teilen, ist der Lesezugriff jedes Aufrufs genau der Schreibzugriff einer Anfrage. Jeder Aufruf sitzt an der Basisadresse und im Zyklus seiner Anfrage. Kein Gate in einem Delegationsschaltkreis musste überhaupt etwas von Anfragen wissen.

Viele Aufrufe, eine Operation#

Eine Operation, die für eine Zeile zu breit ist, besteht aus mehreren Aufrufen auf einem Frame, wobei ein Frame-Wort den Schritt benennt: Eine Permutation von keccak-f[1600] sind 24 Rundenaufrufe, eine SHA-256-Kompression 16 Aufrufe zu je vier Runden, eine vollständige Punktaddition drei Aufrufe. Kein Gate verbindet zwei Zeilen. Jeder Aufruf beweist seinen Schritt auf dem Frame so, wie er ihn vorfindet; seine Lesezugriffe liegen auf der einzigen Speicherhistorie jedes Worts, also liest er die Schreibzugriffe des vorherigen Schritts. Dass jeder Schritt läuft, und zwar in der richtigen Reihenfolge, muss der aufrufende Code sicherstellen, und der aufrufende Code ist Code des Gastprogramms, der als Befehle bewiesen wird. Das SDK setzt jede Operation aus mehreren Aufrufen aus einer einzigen Funktion ab; ein Gastprogramm ordnet die Schritte also nie von Hand.

Statisch deklariert#

Der Befehlsdurchlauf kann einen Aufruf nicht sehen, weil die Nummer ein Laufzeitwert von a7 ist. Deshalb hinterlässt jeder Shim im SDK einen 12-Byte-Deklarationsdatensatz in einer eigenen Linker-Sektion, der nur erhalten bleibt, wenn der Shim erreichbar ist. Die Ableitung des Programms durchsucht das Image nach solchen Datensätzen, und eine deklarierte Familie wird Teil der Konfiguration, gebunden durch die Identität über die Bytes des Images. Eine gelinkte, aber nie aufgerufene Familie beweist null Shards; eine aufgerufene Nummer, deren Familie das Programm nie deklariert hat, hat keinen Beweis.

Die sechs Schaltkreise#

Einige Konstruktionen kehren in ihnen wieder. Eine Ein-Code-Regel dekodiert ein Frame-Wort, das einen von k Fällen benennt, in boolesche Selektoren, von denen genau einer gesetzt ist, weil sich Codes addieren: Ohne sie beantworten die Selektoren 1 und 3 eine Anfrage nach 4. Eine Kanonizitätskette beweist mittels Borrows über 32-Bit-Limbs, dass ein 256-Bit-Wert unter einem Modul liegt. Und jedes geschriebene Wort ist unter 2^32 beschränkt, damit der RAM aus Wörtern besteht, worauf sich jede Befehlsfamilie verlässt.

Die Wirtschaftlichkeit#

Die Höhe einer Delegationsfamilie bestimmt, wie viele Aufrufe ein Shard aufnimmt, und ein Shard kostet seine Höhe, unabhängig von seiner Belegung:

Für eine Familie mit vielen Aufrufen ist der größere Shard der günstigere: Ein KECCAK_F-Beweis wächst von 2^16 auf 2^18 kaum. Der Preis ist Speicher. Der Vorwärtsdurchlauf eines KECCAK_F-Shards der Höhe 2^18 umfasst 42 GiB, und zwei davon, gleichzeitig in Bearbeitung, bestimmten die Spitze des gemessenen Blocks.

Was delegiert wird und was nicht#

Bibliothekscode erreicht die Delegationen über gepatchte Kopien von k256, ark-ff und revm-precompile: Die secp256k1-Recovery wird zu k256-Code über MOD_MUL und EC_ADD, und ein BN254-Pairing wird zu ark-bn254-Code über MOD_MUL. MULMOD der EVM mit beliebigem Modul, MODEXP, BLS12-381 und jedes Signaturverfahren als Ganzes laufen als Befehle. Eigene Signaturunterstützung für Gastprogramme ist Teil der Flugbahn zu v2.0.0.

Die Spezifikation: Delegations-ABI, Delegationsschaltkreise.

Ein vollständiger Ethereum-Block umfasst etwa 200 Millionen Zyklen. Sein Trace, jede Zeile jeder Familie und jedes Speicherereignis, wäre etwa 300 Byte pro Zyklus groß: Dutzende Gigabyte, bevor eine einzige Spalte committet ist. Der Prover von Apogee baut ihn nie. Er führt das Gastprogramm (Guest) zweimal aus und hält nur die Shards, an denen er gerade arbeitet.

Zwei Durchläufe#

Durchlauf 1 führt das Gastprogramm aus und committet, sobald ein Shard gefüllt ist, dessen Speicherspalten, behält die Commitments und verwirft die Zeilen. Beim Exit leitet er alles Weitere, was die Aussage braucht, aus dem finalen Speicherzustand ab: die Randwerte von Registern und pc, die Liste der Speicherfenster, die der Lauf berührt hat, und die Shards der Fensterfamilien. Dann führt er das globale Transkript aus, das die Aussage einschließlich jedes Speicher-Commitments absorbiert, und zieht die Speicher-Challenges sowie den Digest, mit dem jeder Shard initialisiert wird.

Durchlauf 2 führt erneut aus. Der Emulator ist eine reine Funktion seiner Eingabe und schneidet daher dieselben Shards, und Durchlauf 2 prüft per Assertion, dass sein Zyklenprofil, seine Fensterliste und seine Randwerte die von Durchlauf 1 sind. Jeder Shard erhält jede committete Spalte und wird bewiesen: sein Transkript, sein GKR-Durchlauf, seine Öffnung. Die Speicherspalten werden nicht erneut committet: Die Öffnung nimmt ihre Commitments aus der Aussage und ihre Werte aus Durchlauf 2; Spalten, die sich zwischen den Durchläufen unterschieden, ergäben also eine Öffnung, die der Verifier zurückweist.

Die Reihenfolge ist durch die Soundness erzwungen. Die Speicher-Challenges müssen auf jeden Wert folgen, den ein Speichertupel lesen kann; deshalb werden die Speicherspalten jedes Shards committet, bevor irgendein Shard bewiesen werden kann.

Die Pipeline#

Eine feste Zahl von Workern, max_in_flight, teilt sich ein Lock um den Executor. Unter dem Lock gibt ein Worker seinen fertigen Shard zurück und beansprucht den nächsten: einen gefüllten Shard, falls einer wartet, und andernfalls lässt er den Executor selbst Schritt für Schritt laufen, bis ein Puffer voll ist. Außerhalb des Locks baut er die Spalten des Shards, beweist ihn und verwirft ihn.

• Der Executor läuft dem Bedarf nie voraus. Höchstens ein gefüllter, nicht beanspruchter Shard pro Familie wartet, in Form von Zeilen.
• Innerhalb eines Shards ist die Arbeit datenparallel, über alle Kerne. Ein Worker, der in dieser Arbeit blockiert ist, nimmt keinen zweiten Shard.
• Der Block hängt nicht vom Scheduling ab. Der Beweis eines Shards ist eine Funktion des globalen Zustands und seiner eigenen Spalten; Beweise werden nach ihrer Position in der Aussage abgelegt. Die Bytes sind bei 1 und bei 8 gleichzeitig bearbeiteten Shards identisch.
• Fehlschläge sind deterministisch. Zurückgegeben wird der früheste Fehlschlag in der Befüllungsreihenfolge, bei jeder Zahl von Workern.

Was es kostet#

Der Speicher besteht aus einem Teilpuffer pro Familie, den Tabellen der letzten Zugriffe, den gerade bearbeiteten Shards und der Ausgabe. Den Speicherbedarf eines Shards bestimmt vor allem sein Vorwärtsdurchlauf, jede innere GKR-Schicht als Körperelemente: 8,4 GiB für einen SHIFT_BITWISE-Shard der Höhe 2^20, 42 GiB für einen KECCAK_F-Shard der Höhe 2^18. max_in_flight beschränkt also, wie viele davon zusammenfallen, und die Höhen bestimmen, wie groß jeder ist.

Gemessen an Block 257.510 (60 Transaktionen, 101,5 Mgas, 198 Mio. Zyklen, 207 Shards) auf 32 vCPUs und 247,7 GiB, mit zwölf gleichzeitig bearbeiteten Shards:

Die Spitze ergab sich aus der Höhe einer einzigen Delegationsfamilie, nicht aus den zwölf gleichzeitig bearbeiteten Shards. Das ist der Hebel: Ein Block mit weniger Keccak-Aufrufen oder mit Keccak bei geringerer Höhe erreicht eine niedrigere Spitze.

Die Spezifikation: Der Streaming-Prover.

Ein Basisbeweis eines Ethereum-Blocks besteht aus 207 Shard-Beweisen: 14,5 MB, jeder Shard ein GKR-Beweis mit seinen Commitments und einer Mercury-Öffnung, die in einer Pairing-Prüfung endet. Ein Contract kann nichts davon direkt prüfen. Die Rekursion komprimiert ihn, und die Art, wie sie das tut, ist nach der GKR-Engine selbst die folgenreichste Designentscheidung.

Der Basisbeweis bleibt unberührt#

Die erste Entscheidung betrifft das, was die Rekursion nicht tut. Kein Basisschlüssel, keine Basisaussage und kein Basisbeweis ändert sich, um die Rekursion möglich zu machen: Ein Blatt verifiziert Basis-Shards genau so, wie es ein nativer Verifier täte. Alles, was die Rekursion braucht, wird oberhalb des Basisbeweises hinzugefügt, nie in ihm. Ein Block lässt sich aus denselben Bytes nativ verifizieren, rekursiv verarbeiten oder beides.

Apogee beweist seinen eigenen Verifier#

Ein Knoten des Baums ist Apogee beim Beweisen eines Verifier-Programms. Ein Blatt verifiziert eine Reihe aufeinanderfolgender Basis-Shards, von from bis to; ein innerer Knoten verifiziert zwei bis vier Kinder, jedes ein vollständiger Beweis eines Blatt- oder Knotenprogramms; die Wurzel deckt jeden Basis-Shard ab. Jeder Knoten wird von demselben Streaming-Prover bewiesen wie ein Basisblock.

Den Rust-Verifier als RISC-V-Befehle auszuführen würde funktionieren und ergab gemessen 3,0 Milliarden Zyklen für die 207 Shards eines Blocks: das Fünfzehnfache des Blocks selbst. Deshalb laufen Knoten stattdessen in einem Rekursionsformat.

Das Rekursionsformat#

Eine Aussage ist genau dann im Rekursionsformat, wenn ihr Programm Körperfamilien deklariert. Das Format fügt einen Adressraum und vier Koprozessor-Familien darauf hinzu, die alle über das gewöhnliche Delegations-ABI aufgerufen werden, und ändert sonst nichts:

Zwei weitere Änderungen machen einen Rekursions-Shard für seinen Elternknoten günstiger zu verifizieren. Seine Speicher- und Witness-Spalten werden als Stapel von bis zu 2^24 Auswertungen committet; ein Elternknoten faltet also eine Handvoll Punkte statt Hunderter. Und eine Rekursionsanfrage schreibt ihre Frame-Basis hinter das Ende des Frames vorgerückt zurück; direkt hintereinander liegende Frames werden also als direkt aufeinanderfolgende ecalls abgespielt, eine Zeile pro Aufruf.

Tapes#

Die Prüfungen eines Shards haben für seine Familie und Höhe eine feste Form. Deshalb kompiliert der Host sie einmal in ein Tape: eine lineare Liste von Koprozessor-Aufrufen über absoluten Zellen, in der nichts abhängig von einem Wert verzweigt. Das Tape eines Shards besteht aus den Schritten des nativen Verifiers für diesen Shard, Aufruf für Aufruf: das Shard-Transkript, der GKR-Rückwärtsdurchlauf, die Lookup- und Wurzelprüfungen und die zwölf Skalare der Mercury-Öffnung. Jede Prüfung ist ein Assert-Equal.

Die Tapes, Faltungsvorlagen und Konstanten jedes Rekursionsprogramms werden zur Compile-Zeit vom Verifier-Crate selbst gebaut und in den schreibgeschützten Daten des Programms abgelegt. Die Programmidentität bindet daher jedes Tape, das das Programm abspielt: Zu beweisen, dass ein Knoten sein Programm ausgeführt hat, heißt zu beweisen, dass er genau diese Prüfungen ausgeführt hat.

Ein über den Baum verkettetes Transkript#

Das globale Transkript der Basisaussage ist ein einziger Sponge über die gesamte Aussage. Der Baum teilt es auf, ohne es zu verändern. Der Knoten, der Shard 0 hält, führt das Präfix aus, bis einschließlich des Digests der öffentlichen Eingabe; jeder Knoten absorbiert die Speicher-Commitments seiner eigenen Shards und setzt dabei an dem Zustand an, den sein Vorgänger hinterlassen hat; der Knoten, der den letzten Shard hält, führt das Suffix aus und zieht die Speicher-Challenges, die jeder Knoten als Behauptungen übernommen hatte. Das Journal eines Knotens hält den Zustand der Kette an beiden Enden seines Bereichs fest, und ein Elternknoten verlangt, dass die Zustände seiner Kinder aneinander anschließen.

Ein Knoten gleicht seine Kinder außerdem miteinander ab: Exit-Status 0, eine einzige Basisaussage (ihre Form, ihr Digest, ihre Challenges, der Digest von Eingabe und Journal, ihr Exit-Status und ihre Shard-Zahl), aneinandergrenzende Shard-Bereiche, aneinander anschließende Kettenzustände, Zeitfenster in Reihenfolge über die Naht hinweg und die Identitäten der Rekursionsprogramme. Ein Knoten, der eine ganze Aussage hält, führt das Speicherargument aus.

Die Pairings falten#

Kein Knoten berechnet ein Pairing. Die Mercury-Prüfung jedes Shards wird als zwölf Einträge (side, scalar, point) aufgeschoben; nach dem Tape des Shards absorbiert das eigene Transkript des Knotens den Endzustand des Shard-Transkripts und zieht Gewichte, und jeder Eintrag wird gewichtet in ein einziges laufendes Punktepaar (A, B) addiert, das die Behauptung e(A, [1]_2) = e(B, [x]_2) darstellt. Die Batch-Prüfung, die das kombinierte Commitment eines Shards an seine Spalten bindet, wird daneben gefaltet. Punkte, die alle Shards einer Familie teilen, etwa [1]_1 und die Setup-Commitments, sammeln je einen Skalar an und gehen einmal ein. Das (A, B) eines Kindes geht unter einem Gewicht ein, das nach seinem gesamten Journal gezogen wird.

Jede Seite ist eine einzige Multi-Skalar-Multiplikation auf FQ_OP, ausgeführt als statische Vorlage: Pippenger mit 8-Bit-Ziffern über GLV-Hälften, für jeden Punkt erzwungen, dass er auf der Kurve liegt, jeder Schritt im Voraus festgelegt. Ein Punkt kostet etwa 400 FQ_OP-Aufrufe.

An der Wurzel ist der gesamte Inhalt des Baums zusammengefallen: jeder Basis-Shard verifiziert, das Transkript von Anfang bis Ende ausgeführt, das Speicherargument geführt und jede Öffnung in eine einzige Pairing-Behauptung gefaltet. Übrig bleiben diese Behauptung und zwei Programmidentitäten.

Der Decider#

Die Wurzel ist immer noch ein GKR-Beweis und einige Hundert Punkte, was ein Contract nicht prüfen kann. Der Decider ist ein Groth16-Schaltkreis, der das Knotenverfahren über einem einzigen Kind, der Wurzel, ausführt, und zwar über einen Treiber, der Rank-1-Constraints statt Koprozessor-Aufrufen schreibt, und der das Journal der Wurzel an den gesamten Bereich der Basis-Shards bindet. Er faltet nichts: Jeder Punkt, den die Wurzel dem finalen Pairing schuldet, wird mit seinem Skalar zu einem gebundenen Wire, einem Wert, den der Verifier besitzt, im Beweis unter einer fünften Falltür committet, statt als öffentliche Eingabe übergeben zu werden. Dasselbe gilt für die beiden Identitäten, den Exit-Status der Basisaussage sowie die öffentliche Eingabe und das Journal der Basisaussage, Byte für Byte.

Das Groth16 von Apogee weicht in drei Punkten vom Lehrbuch ab: das Commitment auf die gebundenen Wires, keine Verblindung und ein Beweisschlüssel über der Lagrange-Basis, die die Powers-of-Tau-Zeremonie bereits veröffentlicht. Sein Schlüssel stammt aus einer zweiphasigen Zeremonie: Phase 1 ist dieselbe Zeremoniedatei, auf der die Commitments beruhen; Phase 2 gehört allein dem Schaltkreis, wobei die Beiträge zu α und β abgeschlossen sind, bevor irgendein Beitrag zu γ, δ und η erfolgt, eine Reihenfolge, die selbst Teil der Soundness ist.

ApogeeVerifier.sol rekonstruiert die gebundenen Werte aus den Calldata, prüft die Groth16-Gleichung, faltet die Punkte beider Seiten mit ecMul und ecAdd, was zugleich erzwingt, dass jeder Punkt auf der Kurve liegt, und prüft das eine verbleibende Pairing. Sein Konstruktor legt den Schlüssel, die beiden G2-Punkte der Zeremonie und die Identitäten der beiden Rekursionsprogramme fest. Ein Deployment bedient ein einziges Basisprogramm, eine einzige Wurzelform und feste Längen der öffentlichen Werte.

Gemessen#

Block 257.510, der Baum auf einer Maschine mit 32 CPUs, Zeremonie und Decider auf einem Laptop mit 18 Kernen:

Die Spezifikation: Rekursion und Decider. Selbst ausführen: On-Chain abwickeln.

Apogee beweist beliebige RV32IMAC-Programme. Seine Referenz-Arbeitslast, an der es gemessen und abgestimmt wird, ist die schwierigste gängige: die Validierung eines Ethereum-Blocks innerhalb der VM mit revm, der EVM in Rust. Eine einzige Bibliothek, revm_block, wird sowohl für das Gastprogramm (Guest) als auch für den Host kompiliert, und zwei Binaries beweisen zwei verschiedene Aussagen.

Zwei Binaries, zwei Aussagen#

Der zustandslose Validator ist derjenige, der Blöcke beweist. Er implementiert verify_stateless_new_payload aus den Execution Specifications von Ethereum: Er dekodiert die Anfrage, prüft die Vorfahren-Header und die Header-Regeln gegen den Elternblock, rekonstruiert jeden Absender, führt jede Transaktion gegen einen Vorzustand aus, der über Hashes an die Zustandswurzel des Elternblocks gebunden ist, wendet Withdrawals und Requests an und berechnet die Receipts-Wurzel, den Bloom-Filter, das Gas, den Requests-Hash, die Block Access List und die Wurzel des Nachzustands neu. Der Witness braucht keine eigene Bindung: Die veröffentlichte Wurzel legt den Payload fest, und der Witness ist über Hashes an sie gebunden; ein falscher Witness kann also keinen ungültigen Payload gültig machen. Ein Urteil false bedeutet nur, dass diese Eingabe die Validierung nicht bestanden hat.

Forks und Konformität#

Der Validator bestimmt den Fork anhand der Schema-ID der Eingabe, ohne einkompilierten Aktivierungsplan: Osaka, BPO1, BPO2 und Amsterdam. Alle 67.251 Paare des Release tests-zkevm v21.0.1 stimmen nativ überein, und die CI prüft die Bibliothek gegen eine eingecheckte Teilmenge von 34 Fällen, die jede Regel abdeckt, die das Release erreicht, in beiden Eingabe-Layouts.

Delegationen in der Praxis#

Beide Binaries deklarieren KECCAK_F, SHA256_COMP, MOD_MUL und EC_ADD. Keccak erreicht seinen Schaltkreis über den Native-Keccak-Hook von alloy-primitives. SHA-256, secp256k1 und BN254 erreichen ihre Schaltkreise über gepatchte Kopien von revm-precompile, k256 und ark-ff, jeweils mit dem Upstream-Code als Fallback-Pfad. Jeder Absender wird im Gastprogramm nach den Regeln von EIP-2 rekonstruiert, mit k256-Arithmetik, die die Patches zu MOD_MUL und EC_ADD leiten.

Die Binaries werden mit --release gebaut und mit jeder Familie, deren Höhe wählbar ist, bei 2^20 bewiesen: Der .text-Abschnitt des zustandslosen Binarys ist etwa 1,96 MB groß, 96,6 % dessen, was eine 2^20-Tabelle erreicht.

Der gemessene Block#

Block 257.510 von glamsterdam-devnet-8, über revm-block-stateless: 60 Transaktionen, 101,5 Mgas, 198 Millionen Zyklen, geschnitten in 207 Shards. Der Basisbeweis dauerte 2.481 s auf einer Maschine mit 32 vCPUs und 247,7 GiB und erreichte eine Spitze von 174 GiB, die Rekursion kam mit etwa 2.620 s hinzu, und der Contract akzeptierte das Ergebnis für 3.620.026 gas. Performance schlüsselt jede Stufe auf.

Was ein Blockbeweis nicht leistet#

• Der Validator bezieht seine Eingabe von einem externen Witness-Erzeuger. eth_getProof liefert die Trie-Knoten auf dem Pfad jedes Schlüssels, aber eine Löschung, die einen Branch zusammenfallen lässt, braucht einen Geschwisterknoten, der auf dem Pfad keines geänderten Schlüssels liegt. Der Recorder des Repositorys kann deshalb keine zustandslosen Eingaben erzeugen; sie stammen aus einem Release von tests-zkevm oder aus den Datensätzen des zkEVM-Benchmarks.
• Das Mini-Block-Binary beweist eine Ausführung über einem aufgezeichneten Vorzustand, meist die der ersten paar Transaktionen eines Blocks, und stellt keine Behauptung über die Zustandswurzel auf. Sein Journal wächst um einen Datensatz pro Transaktion und wird größer als das öffentliche Fenster; deshalb laufen vollständige Blöcke über den zustandslosen Validator.

Die Spezifikation: Ethereum-Blöcke.

Was ein Beweis begründet#

Ein Beweis, der die Verifikation besteht, begründet, dass das Programm einer gegebenen Identität, gestartet an seinem Einsprung-pc auf seinem Image, mit der öffentlichen Eingabe in seinem Eingabefenster und irgendwelchen vom Prover gewählten Hilfsdaten (Advice), Befehl für Befehl bis zu EXIT mit einem gegebenen Status ausgeführt wird und dabei ein gegebenes Journal geschrieben hat. Über die Hilfsdaten wird nichts behauptet. Nichts wird verborgen.

Annahmen#

BN254 bietet etwa 100 Bit Sicherheit. Der statistische Fehler jeder Protokollschicht, von den Sumchecks und der gebündelten Öffnung bis zu den Speicher- und Lookup-Argumenten, liegt weit darunter: unter 2^14/|Fr| für den gesamten GKR-Durchlauf eines Schaltkreises, unter 2^−190 für jeden Lookup-Kanal, unter 2^−220 für jede Mercury-Instanz.

Was ein Verifier selbst besitzen muss#

Zwei Werte, bezogen über einen Kanal, den der Prover nicht kontrolliert:

• Die Programmidentität. Gegenüber einer vom Prover gelieferten Identität zeigt ein Beweis nur, dass irgendein Programm gelaufen ist.
• Der SRS-Digest der Zeremonie. Ein Schlüssel wird unter jedem Digest geladen, den seine eigenen Punkte ergeben; ein Schlüssel, der über einem bekannten τ gebaut wurde, wird also nur durch diesen Vergleich zurückgewiesen.

Der Verifikationsschlüssel selbst darf von beliebiger Seite stammen. Beim Laden werden die Identität und der SRS-Digest aus seinem eigenen Inhalt neu berechnet, und seine Schaltkreise werden mit der Registry des Verifiers abgeglichen: Die Identität bindet das Programm, die Registry bindet die Schaltkreise. Das Kommandozeilenwerkzeug verifier vergleicht nur die Identität und entnimmt den SRS-Digest dem Schlüssel; host::verify vergleicht keines von beiden und überlässt es seinem Aufrufer, auch Eingabe, Journal und Exit-Status der Aussage zu prüfen.

Vertrauenswürdiger Code#

Die Soundness liegt allein beim Verifier. Sie beruht auf constants, field, curve, transcript, poly, sumcheck, pcs-verify, pcs, gkr-verify, verifier-core, verifier und constraints, weil die Schaltkreise Teil der Aussage sind und ein fehlendes Gate ein Soundness-Fehler ist. Das Berechnen einer Identität aus einem ELF vertraut außerdem loader, isa und program. Der letzte Schritt zur Chain fügt die Rekursionsprogramme, groth16, den Schaltkreis des Deciders und den Contract hinzu.

Dem Prover, dem Emulator, den Trace-Buildern und der beweisenden Hälfte des Host-SDK wird nicht vertraut. Der Prover validiert nichts; eine falsche Eingabe führt bei einem ehrlichen Prover zu einem Beweis, der fehlschlägt, und ein betrügerischer Prover führt diesen Code ohnehin nicht aus.

Nicht in konstanter Zeit, nicht zero-knowledge#

Nichts im Code läuft in konstanter Zeit: Reduktionen, Exponentiationen, Punktadditionen und Skalarleitern verzweigen abhängig von ihren Operanden. Das ist hier unschädlich, weil kein Beweis zero-knowledge ist und das Beweisen somit nichts geheim hält. Das einzige Geheimnis, mit dem der Code umgeht, ist der Faktor eines Beitragenden zur Zeremonie des Deciders, und er durchläuft dieselbe Leiter mit variabler Laufzeit; führen Sie Beiträge auf einer Maschine aus, die Sie kontrollieren.

Grenzen von v1.0.0#

Wohin die nächste Version das verschiebt#

Jede der obigen Annahmen, die BN254 betrifft, von q-DLOG und dem Pairing bis zu Groth16, hält einem hinreichend großen Quantencomputer nicht stand. Die Flugbahn zu v2.0.0 führt zu einem Beweiskern, dessen Soundness stattdessen auf Gitterproblemen beruht.

Die Sicht eines Auditors auf dasselbe Modell, Crate für Crate und Argument für Argument: Audit-Leitfaden, Soundness-Karte.

Alle End-to-End-Zahlen beziehen sich auf Block 257.510 von glamsterdam-devnet-8, bewiesen über das Gastprogramm (Guest) des zustandslosen Validators: 60 Transaktionen, 101,5 Mgas, 198 Millionen Zyklen. Jede Zahl stammt aus den Messungen der Spezifikation.

Von Anfang bis Ende#

Der Basisbeweis, Durchlauf für Durchlauf#

Die Spitze wurde durch die Höhe einer einzigen Delegationsfamilie bestimmt, nicht durch die Zahl der gleichzeitig bearbeiteten Shards.

Ein kleines Gastprogramm#

Das Gastprogramm des Schnellstarts, 114 Zyklen in vier Befehlsfamilien, bewiesen bei Befehlshöhen von 2^20 und Fensterhöhen von 2^16 mit zwei gleichzeitig bearbeiteten Shards: 7 Shards, 52 s und eine Spitze von 18 GB auf einem Laptop mit 18 Kernen und 48 GiB, fast alles davon die beiden 2^20-Shards in Bearbeitung. Die Untergrenze eines Beweises bestimmen seine Familien und Höhen, nicht seine Zyklenzahl.

Der Shard jeder Familie#

Bei den Standardhöhen. Die Beweisgröße eines Shards ist durch Form und Höhe seines Schaltkreises festgelegt; seine Beweiskosten folgen seiner Höhe mal der Breite seines Schaltkreises, unabhängig davon, wie viele Zeilen aktiv sind.

Eine Höhe ändert nur die Zahl der halbierenden Listen und Sumcheck-Runden, nicht die Gates: Bei 2^20 hat ADD_SUB_LUI_AUIPC 298 innere Spalten und einen Beweis von 57.196 Byte, gegenüber 314 und 64.764 bei 2^22.

Speicher des Vorwärtsdurchlaufs#

Der GKR-Prover hält jede innere Schicht als Körperelemente, 32 Byte pro Zelle. Repräsentativer Speicherbedarf:

Mercury#

Auf einem Apple M5 Pro mit 18 Kernen:

Wie diese Zahlen zu lesen sind#

Die Beweiserzeugung ist speichergebunden, und ihr Speicherbedarf folgt den gleichzeitig bearbeiteten Shards und deren Höhen, nie der Länge der Ausführung. Die Zeit folgt der Zyklenzahl, Familie für Familie. Die On-Chain-Kosten folgen der Zahl der Punkte, die die Wurzel dem finalen Pairing schuldet, mit etwa 9.000 gas pro Punkt. Zyklenzahlen selbst sind exakt und maschinenunabhängig; der Zyklus-Profiler ist also das richtige erste Werkzeug, um alles Übrige abzuschätzen.

Version 1.0.0 klärt die Frage, ob die Architektur im vollen Maßstab trägt: ein ganzer Ethereum-Block, von einem Gastprogramm (Guest) in Rust bis zu einem Contract, der true sagt. Version 2.0.0 ändert, worauf diese Architektur ruht und wem sie dient. Der Beweiskern wechselt auf Mathematik, die ein Quantencomputer nicht bricht, und die Oberfläche für Entwickler wächst von einem Repository zu einem System, das Anwendungen deployt.

Die vier Initiativen#

Die Flugbahn#

Was erhalten bleibt#

Der Sprung betrifft die Fundamente, nicht das Modell, gegen das ein Entwickler programmiert:

• Das Gastprogramm. Rust, RISC-V, drei Speicherbereiche, eine Identität, ein Journal. Für v1.0.0 geschriebene Programme behalten ihre Form.
• Die GKR-Engine. Geschichtete Schaltkreise und Sumcheck sind über jedem Körper definiert. Die Engine, die einen Schaltkreis auf einen einzigen Punkt zurückführt, ist der Teil von Apogee, der am direktesten in den neuen Körper wechselt.
• Die Argumente. Eine einzige Speicher-Multimenge über die gesamte Ausführung und die LogUp-Kanäle bleiben als Konstruktionen erhalten; ihre Tabellen und Bereichsargumente werden für die Größe des neuen Körpers neu hergeleitet.
• Die Disziplin. Zuerst die Spezifikation, jede Schicht gegen ein unabhängiges Orakel geprüft, jede Fälschungsklasse durch einen Manipulations-Zwilling abgedeckt.

Warum jetzt#

Ein Gültigkeitsbeweis ist nur so quantensicher wie das System, das ihn erzeugt. Ein Beweis über BN254 beruht auf Pairings und diskreten Logarithmen; ein hinreichend großer Quantencomputer könnte ihn also fälschen, ohne irgendetwas anzutasten, was das Gastprogramm berechnet hat. Blockchain-native Anwendungen sollen über Jahrzehnte Werte halten. Das Fundament, auf dem ihre Abwicklung beruht, muss die Maschinen überdauern, die eines Tages die heutigen Kurven brechen werden, und der richtige Zeitpunkt für den Umzug liegt, bevor es diese Maschinen gibt.

Zu den Initiativen: Post-Quanten-Beweise · Signaturen für Gastprogramme · Das Deployment-System.

Was bricht, und wo#

Jede kryptografische Annahme, auf der Apogee v1.0.0 ruht, betrifft BN254. Die Soundness von Mercury und KZG gilt unter q-DLOG im algebraischen Gruppenmodell; der Rekursionsbaum faltet Pairing-Prüfungen; der Decider ist Groth16. Shors Algorithmus löst auf einem hinreichend großen Quantencomputer diskrete Logarithmen und bricht damit jede einzelne dieser Annahmen. Die Berechnung des Gastprogramms (Guest) bliebe, was sie war; der Beweis, dass sie korrekt lief, hätte keinerlei Bedeutung mehr.

Im Commitment konzentriert sich die Abhängigkeit. Jede Spalte jedes Shards wird damit committet, jede Öffnung endet in seinem Pairing, und die Rekursion existiert, um diese Pairings zu falten. Ersetzt man das Commitment, bleibt im Rest des Beweiskerns nichts mehr, das von einem diskreten Logarithmus abhängt.

QL-01 · Gitterbasierte Commitments#

Ein Gitter-Commitment ist eine lineare Abbildung, t = A·s mod q, angewandt auf einen Vektor s mit kleinen Einträgen. Es ist bindend, solange niemand einen kurzen Vektor finden kann, den die Matrix auf null abbildet: Module-SIS, die Annahmenfamilie hinter ML-DSA und ML-KEM, den Post-Quanten-Standards des NIST, gestützt auf Worst-Case-Reduktionen und jahrzehntelange Kryptoanalyse.

Es bewahrt, was KZG für Apogee so nützlich gemacht hat und was hashbasierte Commitments aufgeben: Es ist homomorph. Commitments auf viele Teilstücke lassen sich mit Challenge-Koeffizienten kombinieren, und die Kombination wird durch einen einzigen Vektor geöffnet. Das Bündeln der Spalten eines Shards, das Aufschieben von Prüfungen und ihr Falten einen Baum hinauf sind lineare Operationen, und lineare Operationen überstehen den Wechsel. Merkle-Pfade lassen sich überhaupt nicht kombinieren.

Der Preis ist eine Einschränkung, die es anderswo nicht gibt: Das Commitment bindet nur kurze Vektoren, jede Kombination macht den Vektor länger, und der Prover muss zeigen, dass er noch kurz genug ist. Die Verfahren der letzten zwei Jahre unterscheiden sich vor allem darin, wie sie diesen Preis zahlen, und sie haben sich schnell entwickelt. Für Polynome mit 2^30 Koeffizienten liefern die veröffentlichten Module-SIS-Verfahren Auswertungsbeweise von 53 bis 72 KB, und die Verifikation sank von 2,8 Sekunden im Jahr 2024 auf 8 bis 16 Millisekunden im Jahr 2026. Die Abhandlung Lattice-Based Polynomial Commitment Schemes stellt sie Verfahren für Verfahren vor und setzt die Zahlen in Beziehung zur hashbasierten Seite.

QL-02 · Körperwechsel#

Die Gitterverfahren leben nicht in der Welt von BN254. Die führenden Konstruktionen arbeiten über kleinen Primzahlmoduln, mit Auswertungspunkten aus einem Erweiterungskörper, um die Soundness zu erhalten; das passt zu einem Beweissystem über einem kleinen Körper und nicht zu einem über einem 254-Bit-Körper. Der Wechsel des Commitments zieht also den Körper mit: v2.0.0 überträgt die Arithmetisierung auf einen neuen Körper und verlegt jeden Schaltkreis vom Skalarkörper von BN254 auf einen kleinen, zum Commitment passenden Körper.

Der Wechsel macht sich bezahlt:

• Jede Schicht wird günstiger. Ein GKR-Prover verbringt seine Zeit mit Körperarithmetik, und eine Multiplikation in einem kleinen Körper kostet einen Bruchteil einer Multiplikation in einem 254-Bit-Körper. Die zentrale Ersparnis der Engine, dass Zwischenschichten nie committet werden, verstärkt sich mit billigerer Arithmetik auf jeder verbleibenden Schicht.
• Commitments werden günstiger. Das Commitment auf eine Trace-Spalte ist eine lineare Abbildung über kleinen Ziffern, bezahlt pro Eintrag ungleich null, statt einer Multi-Skalar-Multiplikation über einer Kurve.
• Die Engine bleibt erhalten. GKR und Sumcheck sind über jedem Körper definiert. Challenges wandern in einen Erweiterungskörper; der Rückwärtsdurchlauf, das Schichtenmodell und die darauf aufbauenden Argumente behalten ihre Struktur.

Neu gebaut werden muss alles, was einen großen Körper voraussetzte: Werte auf Wortebene, die mit reichlich Spielraum in ein BN254-Element passen, Bereichsargumente und Überträge, die auf einen 254-Bit-Modul ausgelegt sind, Kanonizitätsketten und die Körperzellen des Rekursionsformats. Jedes davon wird für den neuen Körper neu hergeleitet und so spezifiziert wie die von v1.0.0, mit eigenem Orakel und eigenen Manipulations-Zwillingen.

Abwicklung#

Die Verifikations-Precompiles von Ethereum sind heute pairing-basiert. Wie die Beweise eines Post-Quanten-Beweiskerns auf dieser Chain abgewickelt werden und welcher Teil des letzten Schritts auf Gittern ruhen kann, gehört zum selben Arbeitsprogramm und wird, bevor es ausgeliefert wird, mit derselben Sorgfalt spezifiziert wie der Kern.

Zurück zum Missionsbriefing.

Fast jede Blockchain-native Anwendung stellt bei jeder Anfrage dieselbe Frage: Hat der richtige Schlüssel das autorisiert? In v1.0.0 beantwortet ein Gastprogramm (Guest) sie mit Code. Die secp256k1-Recovery ist k256, ausgeführt auf den delegierten Schaltkreisen MOD_MUL und EC_ADD, was Ethereums eigene Signaturen erschwinglich macht; alles andere besteht aus gewöhnlichen Befehlen. QL-03 macht die Signaturverifikation zu einer vollwertigen Operation des Gastprogramms.

Die Verfahren#

Ob sich ein Signaturverfahren günstig beweisen lässt, hängt fast ausschließlich von seinem Algorithmus zur Verifikation ab: welche Arithmetik er ausführt, in welchem Körper und welchen Hash er aufruft. Der Signierer läuft nie innerhalb des Beweises. Vier Entwürfe decken das Feld ab:

Alle vier Verifikationsalgorithmen folgen dem Muster „berechnen und vergleichen“, ohne Geheimnisse und ohne Verzweigungen auf Geheimnissen, und genau das macht jeden von ihnen beweisbar. Die Abhandlung ZK-Friendly Signature Schemes arbeitet jedes Verfahren an einem Spielzeugbeispiel durch und vergleicht ihre Kosten im Schaltkreis.

Was die Kosten bestimmt#

Zwei Hebel bewegen jede Zahl:

• Der Körper, über dem der Prover arbeitet. Ein Verfahren ist nativ, wenn seine Arithmetik die Arithmetik des Schaltkreises ist. Welches Verfahren am günstigsten ist, folgt daher aus dem Körperwechsel von QL-02, und die Auswahl wird zusammen mit ihm getroffen.
• Der Hash. Bei den Post-Quanten-Verifikationsalgorithmen dominiert ihr Standard-Hash, nicht ihre Algebra. Ihn durch einen arithmetischen Hash zu ersetzen, verlässt den Standard und ist die Variante, die die ZK-orientierten Konstruktionen wählen; die Interoperabilität mit bestehenden Schlüsseln verlangt, ihn beizubehalten. Beides hat seinen Platz, und das Gastprogramm entscheidet.

Für Entwickler#

Das Ziel ist ein Gastprogramm, das eine Autorisierung so verifiziert, wie es heute einen Hash berechnet: ein Aufruf, an einen Schaltkreis delegiert, keine Kryptografie im eigenen Code der Anwendung. Das erschließt die Muster, auf denen Blockchain-native Anwendungen aufbauen: Konten, deren Schlüssel nicht die der Chain sind, Mehrparteien-Freigaben innerhalb der Zustandsübergangsfunktion, Session-Keys und Identitäten, die gültig bleiben, nachdem die Kurven, auf denen sie entstanden sind, gefallen sind.

Zurück zum Missionsbriefing.

Version 1.0.0 gibt einem Entwickler ein Repository, seine Werkzeuge und dieses Handbuch. Alles zwischen einem bewiesenen Gastprogramm (Guest) und einer Anwendung im Live-Betrieb, von Schlüsseln und Zeremonien bis zu Verifier-Contracts, Bridges und Betrieb, muss der Entwickler noch selbst zusammensetzen. Das Blockchain-native Deployment-System von Apogee ist die zweite Hälfte des Sprungs: ein Portal und eine Toolchain, die ein Gastprogramm in eine laufende Blockchain-native Umgebung verwandeln und sie am Laufen halten.

Die Module#