Une application native blockchain est une activité économique dont le règlement, la garde des actifs et les règles sont sur la chaîne par construction, et non une entreprise conventionnelle à laquelle on aurait greffé un jeton. Cela ressemble à une tout autre ingénierie. L’écart est moindre qu’il n’y paraît.

Chaque composant de la pile que vous construisez aujourd’hui a son équivalent. Cet équivalent fait le même travail, à un changement près : ce qui relevait de la confiance est désormais prouvé. Apogee existe pour rendre ce changement assez peu coûteux pour qu’il devienne la norme.

Le changement en une phrase#

Dans une application conventionnelle, le serveur fait autorité : il détient les données, applique les règles et rapporte le résultat. Dans une application native blockchain, la chaîne détient un engagement sur les données, les règles sont un programme que chacun peut désigner par son condensé, et un résultat n’est accepté qu’accompagné d’une preuve que ce programme l’a produit.

L’opérateur ne disparaît pas. Quelqu’un exécute toujours le programme, stocke les données et répond aux requêtes. Ce qui disparaît, c’est la nécessité de le croire.

Couche par couche#

La colonne centrale est ce dont est faite une application native blockchain. Apogee fournit la machinerie qui se trouve en dessous : la machine RISC-V, les circuits, les engagements, la récursion et le contrat vérificateur. Rien de tout cela n’apparaît dans votre programme.

Ce qui ne change pas#

• Vous écrivez toujours du Rust ordinaire. Structures, énumérations, traits, itérateurs, Vec, BTreeMap, et toute crate qui compile sans std. Il n’y a aucun langage de circuits à apprendre.
• Vous testez toujours sur votre ordinateur portable. L’organisation habituelle place la logique applicative dans une bibliothèque no_std qui s’exécute sur l’hôte, sous cargo test, exactement comme elle s’exécute dans le programme invité. Voir Écrire un programme invité.
• Vous raisonnez toujours en termes d’état, de requêtes et de réponses. Les formes sont les mêmes; seules leurs garanties changent.
• Le code déterministe reste déterministe. Un bon code côté serveur évite déjà les entrées cachées. La VM rend cette règle absolue.

Ce qui change#

• Aucun monde ambiant. Un programme invité n’a ni horloge, ni aléa, ni réseau, ni fichiers. Tout ce qu’il sait lui parvient comme entrée publique ou comme données auxiliaires, et une demande de données à l’hôte est un appel qu’aucune preuve n’admet.
• Chaque instruction a un prix. Chaque instruction exécutée devient une ligne prouvée. Les copies, les allocations et les boucles inutiles coûtent du temps de preuve : la vieille discipline du décompte des cycles fait son retour.
• Les données fournies sont vérifiées, pas crues sur parole. Les données auxiliaires sont choisies par le prouveur. Un programme invité les vérifie par rapport à quelque chose que la preuve lie avant que quoi que ce soit qui en dérive ne soit publié.
• Les sorties sont petites et publiques. Le journal contient au plus 16 380 octets. Un résultat volumineux est publié sous forme de condensé.
• Rien n’est caché. Les preuves d’Apogee v1.0.0 sont succinctes, pas à divulgation nulle de connaissance. Un programme invité ne doit détenir aucun secret.

Un registre, construit des deux façons#

Un dépôt sur le solde d’un compte : le plus petit changement d’état qui vaille la peine d’être prouvé.

La version conventionnelle#

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

Les utilisateurs font confiance à l’opérateur pour avoir exécuté exactement ceci, sur la vraie table, et pour rapporter le résultat honnêtement.

La version native blockchain#

Les comptes résident dans un arbre de Merkle binaire dont les feuilles sont keccak256(account ‖ balance). Un contrat stocke la racine. Le programme invité reçoit l’ancienne racine et la requête comme entrée publique, reçoit le solde du compte et son chemin de Merkle comme données auxiliaires, vérifie le chemin, puis publie l’ancienne et la nouvelle racine.

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

Lisez-le en regard du SQL. SELECT … FOR UPDATE est devenu un chemin de Merkle vérifié par rapport à la racine. UPDATE est devenu une nouvelle feuille sur le même chemin. COMMIT est devenu quatre appels à commit, qui écrivent le journal que la preuve liera. Le solde vient du prouveur, et cela ne pose aucun problème : un solde sur lequel la racine ne s’engage pas échoue à la vérification, et l’exécution se termine avec le statut 2.

Le contrat qui détient la racine n’accepte une transition qu’accompagnée d’une preuve que ce programme l’a produite et s’est terminé avec le statut 0 :

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

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

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

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

Le modèle en trois lignes#

1. La chaîne détient une racine.
2. Le programme invité prouve la transition.
3. Le contrat fait avancer la racine.

Tout le reste, des shards et des circuits à la récursion et au décideur, relève d’Apogee. Voilà l’abstraction : un programme, son entrée et sa sortie, et une preuve qui les relie.

Pour la suite#

En un paragraphe#

Apogee VM est une zkVM RISC-V. Elle prouve qu’un programme RV32IMAC, désigné par un condensé de son image, s’est exécuté sur une entrée publique donnée jusqu’à un statut de sortie et a écrit une sortie publique donnée. Elle porte cette preuve, à travers un arbre de récursion, jusqu’à une seule preuve Groth16 que vérifie un contrat Ethereum. Chaque circuit est un circuit GKR en couches sur le corps des scalaires de BN254, chaque colonne engagée est ouverte avec Mercury, et chaque défi provient d’une transcription Poseidon2. Les corps, la courbe, le couplage, la MSM, le hachage, l’engagement polynomial, le prouveur GKR et Groth16 sont tous implémentés dans le dépôt. Sa charge de travail de référence est la validation de blocs Ethereum.

Les faits#

Mesures#

Tous les chiffres concernent le bloc 257 510 de glamsterdam-devnet-8, passé par le programme invité validateur sans état : 60 transactions, 101,5 Mgas, 198 millions de cycles. Sources : récursion §10 et prouveur en flux §1 dans la spécification.

Ce que doit détenir un vérificateur#

Deux valeurs, obtenues par un canal que le prouveur ne contrôle pas :

• L’identité du programme, un élément du corps. Face à une identité fournie par le prouveur, une preuve montre seulement qu’un programme quelconque s’est exécuté.
• Le condensé SRS de la cérémonie. Une clé construite sur un τ connu n’est refusée que par cette comparaison.

La clé de vérification elle-même peut provenir de n’importe qui : son chargement recalcule les deux valeurs à partir de son propre contenu et exige que ses circuits soient ceux du registre du vérificateur. Le modèle de sécurité donne la liste complète des hypothèses.

Où s’arrête la v1.0.0#

• Pas de divulgation nulle de connaissance. Aucun aveuglement dans Mercury, dans GKR ni dans le décideur.
• Les données auxiliaires ne sont pas liées. Un programme invité les vérifie par rapport à quelque chose qu’une preuve lie.
• Les déroutements (traps) ne sont pas prouvables. Un accès non aligné, un accès hors de la mémoire projetée, ebreak ou un pc sans instruction termine l’exécution sans preuve.
• sc.w réussit toujours. C’est le seul écart par rapport à RV32IMAC : il n’y a pas d’état de réservation.
• Les délégations forment un ensemble fixe de six. MULMOD de l’EVM avec un module arbitraire, MODEXP et BLS12-381 s’exécutent comme des instructions ordinaires.
• La génération de preuves est limitée par la mémoire. Le bloc mesuré a culminé à 174 GiB; la mémoire suit les shards en cours de traitement, pas la longueur de l’exécution.
• La clé du décideur est propre à chaque forme de racine, et n’est digne de confiance que dans la mesure où sa cérémonie l’est. La clé de développement est falsifiable.

Qui construit Apogee VM#

Apogee VM est le projet phare du programme de recherche de G Web3 consacré aux environnements d’applications natifs blockchain : un environnement optimisé par application économique, chacun effectuant son règlement sur Ethereum au moyen d’une preuve de validité. La position du programme est exposée dans la thèse; la direction de la prochaine version, dans Saut quantique.

Un programme invité est le programme que prouve Apogee : un binaire Rust no_std compilé pour riscv32imac-unknown-none-elf, avec un point d’entrée, trois régions mémoire pour ses entrées et ses sorties, et rien d’autre. L’hôte est tout ce qui l’entoure : le code qui fournit l’entrée, demande une preuve à Apogee et remet cette preuve à quiconque la vérifie. Vous écrivez les deux. Apogee fournit la machine, les circuits et le vérificateur.

Cette section s’adresse à deux lecteurs à la fois : un ingénieur devant son clavier et le modèle avec lequel il travaille. Chaque page énonce ses règles sans détour, et le Compagnon IA les condense toutes en un seul fichier que vous pouvez remettre à un assistant avant qu’il n’écrive une ligne.

Le modèle#

Une preuve dit une seule chose : le programme de cette identité, lancé sur son image avec cette entrée publique et des données auxiliaires choisies par le prouveur, s’est exécuté jusqu’à EXIT avec ce statut, après avoir écrit ce journal. Tout ce que vous construisez repose sur cette phrase.

Le flux de travail#

Le Démarrage rapide parcourt une fois la boucle complète avec un programme invité de trois lignes.

Les règles les plus importantes#

Chacune est expliquée, avec ce qui tourne mal et ce qu’il faut faire à la place, dans le guide de programmation des programmes invités.

• usize et tous les pointeurs font 32 bits. Un dépassement de usize provoque une panique dans le programme invité seulement, x as usize tronque sans rien signaler, et tout ce dont la disposition ou le hachage dépend d’une longueur diffère entre l’hôte et le programme invité.
• L’allocateur ne libère jamais rien. Il fait monter un pointeur à partir de __heap_start, si bien que ce qui épuise la mémoire d’un programme invité, c’est le total qu’il alloue au cours de l’exécution, et non son pic. Réutilisez les tampons et dimensionnez-les avec with_capacity.
• Les opérations atomiques fonctionnent, et vous ne devriez pas en écrire. La machine n’a qu’un seul hart : l’extension A est là pour la compatibilité avec le code qui l’utilise déjà. Le code d’un nouveau programme invité n’a rien à synchroniser.
• Il n’y a pas de monde extérieur. Ni fichiers, ni horloge, ni aléa, ni réseau. Un programme invité connaît son entrée publique, ses données auxiliaires et ce qu’il calcule.
• Les données auxiliaires sont choisies par le prouveur. Vérifiez-les par rapport à quelque chose que la preuve lie avant que quoi que ce soit qui en dérive n’atteigne le journal.
• Le journal est petit. 16 380 octets au plus. Publiez un condensé de tout ce qui grandit.
• Les vérifications de dépassement restent actives en release. Elles font partie de ce que calcule le programme, et le profil des programmes invités les impose donc.
• Chaque instruction exécutée est une ligne prouvée. Le coût de la preuve suit le nombre de cycles : compilez avec --release et comptez les cycles avant d’optimiser quoi que ce soit d’autre.

Par où commencer#

Cette page parcourt une fois la boucle complète avec le plus petit programme invité qui fasse quelque chose : il lit son entrée publique et la publie comme journal. Chaque sortie ci-dessous a été produite en exécutant exactement ces commandes sur Apogee v1.0.0.

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

[dependencies]
guest-sdk.workspace = true

#![no_std]
#![no_main]

guest_sdk::entry!(main);

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

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

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

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

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

cycles by family
  ADD_SUB_LUI_AUIPC            64
  JUMP_BRANCH_SLT              21
  MEM_WORD                     3
  MEM_SUBWORD                  26

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

program identity  9ead85cee880df30daa8eba657316215107a075640a64ccf2424a054b758b802

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

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

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

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

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

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

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

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

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

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

Ce qui vient de se passer#

L’émulateur a exécuté les 114 instructions deux fois. La première passe a engagé les colonnes mémoire de chaque shard et fixé l’énoncé. La seconde a rempli chaque shard et l’a prouvé. Il y avait sept shards : un pour chacune des quatre familles d’instructions exécutées, un pour la fenêtre mémoire qui contient l’image du programme, puis un pour l’entrée publique et un pour le journal. Ce programme invité n’a jamais touché à sa pile, si bien qu’aucune autre fenêtre n’a eu besoin d’un shard; un programme typique y ajoute celui de la pile. Chaque shard a été prouvé par le circuit GKR de sa famille et ouvert avec une seule preuve Mercury, et le vérificateur a rapproché les lectures et les écritures mémoire des sept shards en une seule équation. La vue d’ensemble de l’architecture suit le même chemin en détail.

Pour la suite#

Apogee v1.0.0 est un dépôt Rust. Il n’y a rien à installer hormis rustup : le dépôt fixe sa chaîne d’outils, et la chaîne d’outils comprend la cible des programmes invités. Écrire, compiler, exécuter et profiler un programme invité ne demande rien de plus. La génération de preuves ajoute un gros fichier et une machine dotée d’une mémoire à l’avenant.

La chaîne d’outils#

rust-toolchain.toml, à la racine du dépôt, fixe Rust stable 1.96.1 avec rustfmt, clippy et llvm-tools, ainsi que la cible riscv32imac-unknown-none-elf, dont core et alloc sont livrés précompilés. rustup l’applique dans chaque répertoire sous la racine et l’installe à la première utilisation.

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

Aucune version nightly ni aucune fonctionnalité instable n’est utilisée nulle part. llvm-tools fournit les llvm-objdump et llvm-nm correspondant au LLVM du compilateur, que le dépôt utilise pour ses listages de désassemblage versionnés et dont vous pouvez vous servir pour lire le code de votre programme invité.

Deux espaces de travail#

La copie de travail contient deux espaces de travail Cargo, et cette séparation compte :

Les programmes invités sont tenus à part parce que chaque membre se compile pour la cible des programmes invités et lie un #[panic_handler]; cargo test --workspace à la racine ne doit jamais les atteindre. L’espace de travail des programmes invités contient aussi ce dont un programme invité a besoin pour être compilé correctement, si bien que vous n’avez jamais à le taper :

• guests/.cargo/config.toml fixe la cible et passe à l’éditeur de liens -T crates/guest-sdk/link.ld, la carte mémoire, et --no-relax, parce que la relaxation déplacerait des adresses que lie l’identité du programme.
• guests/Cargo.toml fixe les deux profils de compilation à la même sémantique, vérifications de dépassement comprises (Compiler et inspecter).
• Sa section [patch.crates-io] redirige k256, ark-ff et revm-precompile vers des copies embarquées qui appellent les délégations d’Apogee (Délégations).

Le fichier de cérémonie#

Chaque engagement que produit Apogee repose sur les puissances d’un τ secret issu d’une cérémonie publique : les puissances de tau perpétuelles de PSE, contribution 80. Un seul fichier sert à tous les usages :

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

Il vous le faut pour calculer une identité de programme, pour construire de vraies clés et pour prouver. Il ne vous le faut pas pour compiler, exécuter ou profiler un programme invité, ni pour lancer les tests de l’espace de travail, qui prouvent sur leur propre mise en place jouet.

Les fichiers de la cérémonie de PSE sont tirés d’une même transcription, si bien que tout fichier de puissance 24 ou plus convient. Le powersOfTau28_hez_final_*.ptau de Hermez provient d’une autre cérémonie, avec un autre τ : le lecteur l’ingère tout aussi facilement, et chaque engagement, chaque clé et chaque identité calculés sur ce fichier en sortent différents. Pour confirmer que vous détenez la bonne cérémonie, voici son [τ]_1, en hexadécimal de son encodage canonique x ‖ y :

9bbb31bedc304e081e2aada4b56c2217e0e94ee16874e3517d14bef5dcec3a16
317ff1589e53513fa333591b318e8f1e55ef7c37d92beb6d9a61d770a2f39506

La page SRS de la spécification énonce exactement ce que vérifie le lecteur et ce qu’il tient pour acquis.

La machine#

Compiler et exécuter, c’est un travail de portable. La génération de preuves est limitée par la mémoire, et la mémoire qu’elle consomme suit les shards prouvés simultanément, pas la longueur de l’exécution.

La page sur la génération de preuves explique comment les hauteurs et le nombre de shards en cours de traitement arbitrent entre mémoire et temps : Prouver et vérifier.

Vérifier votre copie de travail#

Ce qu’exécute la CI, le tout sans le fichier de cérémonie :

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)

Les suites qui prouvent de vrais shards sont marquées #[ignore], parce que chacune nécessite des dizaines de GiB. Lancez-en une par son nom quand vous voulez voir une preuve produite et refusée sur votre propre machine :

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

Ensuite : écrivez un programme invité, ou parcourez une fois la boucle complète dans le Démarrage rapide.

La crate#

Dans la v1.0.0, un programme invité est une crate binaire de l’espace de travail guests/ du dépôt. L’espace de travail fournit la cible, les options de l’éditeur de liens, les profils fixés et les crates embarquées, si bien que le manifeste propre au programme invité reste court :

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

Ajoutez "my-app" à members dans guests/Cargo.toml, et compilez à partir du répertoire du programme invité lui-même : cargo build --release --target riscv32imac-unknown-none-elf.

Ce qui s’exécute sous votre code#

Le SDK des programmes invités constitue tout l’environnement d’exécution. Il est assez petit pour être décrit en entier :

• Démarrage. _start se trouve à 0x0001_0000, le premier octet de .text. Il fait pointer sp vers le haut de la RAM, met .bss à zéro octet par octet, et appelle main. entry!(f) exporte ce main comme une enveloppe autour de votre fonction, qui ne prend aucun argument et renvoie ().
• Sortie. Le retour de main équivaut à exit(0). guest_sdk::exit(code) termine l’exécution avec un statut quelconque. Un statut non nul signale une exécution en échec, et une exécution en échec reste prouvable : l’énoncé porte le statut, et un vérificateur le lit.
• Panique. Le gestionnaire de panique termine l’exécution avec le statut 101 et n’écrit rien. Il n’y a aucun flux de diagnostic. Un programme invité qui panique a tout de même publié ce qu’il avait consigné avant la panique.
• Tas. Un allocateur linéaire (bump allocator) croît vers le haut à partir de __heap_start, juste au-dessus de .bss. Il ne libère jamais rien. Voir le tas.
• Appels système. Les seuls ecalls qu’émet un programme invité sont EXIT et les appels de délégation que le SDK effectue pour vous. L’entrée, les données auxiliaires (advice) et la sortie sont de la mémoire, lue et écrite par des chargements et des rangements ordinaires.

La carte mémoire#

L’espace d’adressage complet de 32 bits, tel que le voit un programme invité :

Le code est statique. L’instruction de chaque pc provient des tables décodées du programme, jamais de la RAM, si bien qu’un rangement dans .text change ce que lit un chargement ultérieur, mais pas ce qui s’exécute.

Le tas#

L’allocateur fait avancer un pointeur, et dealloc ne fait rien. C’est la bonne conception pour un programme court dont chaque cycle coûte du temps de preuve, et cela change votre façon d’écrire du Rust :

• Ce qui épuise votre mémoire, c’est le total que vous allouez, et non votre pic. Une boucle qui construit puis détruit un Vec à chaque itération consomme du tas neuf à chaque fois.
• Réutilisez les tampons. Sortez les allocations des boucles, appelez clear() puis remplissez à nouveau au lieu de réallouer, et dimensionnez avec with_capacity les collections qui grandissent, pour qu’elles ne soient pas réallouées et recopiées à mesure qu’elles grandissent.
• Le plafond, c’est le statut 71. Une allocation qui se terminerait au-dessus de 0x7F80_0000, ou au-dessus du pointeur de pile courant, termine l’exécution avec le statut 71 plutôt que de renvoyer un pointeur nul ou d’écraser la pile.

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

La pile dispose de sa réserve de 8 MiB, et une récursion profonde à l’intérieur de celle-ci ne pose aucun problème. Ce que rien ne détecte, c’est une pile qui dépasse sa réserve après que le tas a rempli l’espace situé sous elle : des blocs du tas changeraient alors sous une chaîne d’appels profonde. Gardez la récursion bornée, ou rendez-la itérative.

Dépendances#

Toute crate qui se compile pour riscv32imac-unknown-none-elf sans std fera l’affaire. En pratique :

• Désactivez les fonctionnalités par défaut (default-features = false) et activez alloc là où une crate le propose.
• Une crate qui entraîne getrandom, une horloge ou std::collections::HashMap avec sa graine aléatoire n’a aucune source où puiser. Un tel appel répond -ENOSYS et rend l’exécution non prouvable. Préférez BTreeMap, ou une table de hachage dotée d’une fonction de hachage fixe et déterministe.
• La virgule flottante se compile en routines logicielles sur entiers, parce que la cible n’a pas d’extension F ni D. Elle est correcte et déterministe, et coûte de nombreuses instructions par opération. L’arithmétique entière ou en virgule fixe coûte moins cher.
• Le hachage et l’arithmétique sur courbes elliptiques ont des circuits dédiés. Utilisez les fonctions du SDK ou les crates embarquées pour que vos dépendances les atteignent : Délégations.

Le tester d’abord sur l’hôte#

Un programme invité n’affiche rien : le débogage se fait donc sur l’hôte. L’organisation qui facilite cela place le programme dans une bibliothèque #![no_std] qui transforme des octets en octets, réduit main.rs au transfert des octets vers les régions et depuis celles-ci, et fait du SDK une dépendance de la seule cible des programmes invités :

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

Le code hôte dépend alors de la bibliothèque par son chemin, comme crates/emulator dépend de guests/revm-block, exécute my_app::run en natif, et compare le résultat au journal que produit l’émulateur pour la même entrée (Exécuter et profiler). Votre logique bénéficie de tests unitaires, d’un débogueur et de println! sur l’hôte, et le binaire du programme invité reste une mince enveloppe autour d’un code que vous avez déjà testé.

Assembleur et jeu d’instructions#

Le décodeur accepte exactement les 59 instructions de RV32IMA, ainsi que les instructions compressées (C), qui sont développées au chargement. L’assembleur en ligne est permis à l’intérieur de cet ensemble. Tout ce qui en sort, comme un accès à un CSR, fence.i, un encodage à virgule flottante ou RV64, empêche l’enregistrement du programme entier, même si cette instruction n’est jamais atteinte : la dérivation signale Not all opcodes supported: pc=…. Un ebreak, un saut vers un demi-mot sans instruction, ou un accès non aligné à un demi-mot ou à un mot termine l’exécution sans preuve.

Les instructions atomiques se décodent et se prouvent, avec un seul écart : sc.w réussit toujours, parce que la machine ne conserve aucun état de réservation. Le guide de programmation des programmes invités explique pourquoi le code d’un nouveau programme invité ne devrait pas utiliser d’opérations atomiques du tout.

Pour la suite#

Un programme invité d’Apogee n’a ni descripteurs de fichiers, ni flux, ni appel système d’E/S. Ses entrées et ses sorties sont trois régions de mémoire, lues et écrites par des chargements et des rangements ordinaires, et la preuve en lie deux.

Les trois régions#

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() et advice() renvoient des tranches sur la mémoire; rien n’est copié. read_input(buf) copie min(buf.len(), input.len()) octets et renvoie leur nombre : la fonction peut donc en copier moins que demandé.
• commit ajoute à la fin du journal et tient à jour un mot de longueur, et c’est ce qui fait que la preuve lie une chaîne d’octets exacte plutôt qu’une fenêtre complétée par des zéros. La fonction termine l’exécution avec le statut 70 plutôt que de faire déborder la fenêtre.
• advice() dans une exécution sans données auxiliaires provoque un OutOfBounds fatal, et non une tranche vide : une exécution sans données auxiliaires n’a aucune région de données auxiliaires, et ne paie rien pour en avoir une.

Ce que signifie « lié »#

L’énoncé qu’établit une preuve porte les octets de l’entrée publique, les octets du journal et le statut de sortie. La preuve montre que la fenêtre d’entrée contenait exactement l’entrée de l’énoncé avant le premier accès du programme invité, et que la fenêtre du journal contenait exactement la sortie de l’énoncé quand le programme invité s’est terminé. Cela repose sur l’argument de mémoire, et non sur quoi que ce soit que fasse le programme invité : il n’y a aucun hachage que le programme invité doive calculer ni aucune convention qu’il doive suivre.

Les données auxiliaires, c’est autre chose. Le contenu initial de leur région est ce que le prouveur y a écrit, quel qu’il soit, et rien ne le rattache à l’identité du programme, à l’énoncé ni à aucune porte. Une preuve dit qu’il existe certaines données auxiliaires avec lesquelles le programme, sur cette entrée, a publié ce journal. Une telle affirmation vaut exactement ce que valent les vérifications que le programme invité fait lui-même sur les données auxiliaires.

Le motif : engager, fournir, vérifier#

Un programme invité dont l’entrée est volumineuse en reçoit l’essentiel sous forme de données auxiliaires, sur lesquelles l’entrée publique s’engage, puis vérifie la concordance des deux avant que quoi que ce soit qui dérive des données auxiliaires n’atteigne le journal :

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
}

La vérification n’a pas besoin d’être un hachage de toutes les données auxiliaires. Ce peut être un chemin de Merkle vérifié par rapport à une racine que porte l’entrée, comme dans l’exemple du registre, ou une signature sur les données, ou une contrainte que le résultat lui-même satisfait, comme un ordre trié annoncé que le programme invité vérifie en une seule passe au lieu de trier. Ce qui compte, c’est que ce par rapport à quoi elles sont vérifiées soit lié.

Données structurées#

Encodez les entrées structurées avec un sérialiseur no_std comme postcard sur serde avec la fonctionnalité alloc, ce qu’utilise le programme invité Ethereum du dépôt lui-même pour son témoin de bloc. Deux habitudes gardent un format honnête :

• Utilisez des entiers de largeur fixe. u32 et u64, jamais usize, dont la largeur diffère entre votre hôte et le programme invité.
• Exigez un seul encodage par valeur quand cela compte. Un désérialiseur qui accepte des octets en trop à la fin ou des varints non minimaux admet deux chaînes d’octets pour une même valeur. Là où l’unicité compte, décodez, réencodez et comparez, comme le fait BlockWitness::decode dans le programme invité Ethereum.

Les sorties qui grandissent#

Le journal contient 16 380 octets. Une sortie qui grandit avec le travail, comme un enregistrement par transaction, n’a pas de borne fixe, et l’exécution finira par se terminer avec le statut 70. Publiez plutôt un condensé : hachez les enregistrements à mesure que vous les produisez et consignez le résultat de 32 octets, puis laissez quiconque a besoin des enregistrements les recalculer en natif et comparer. Le validateur Ethereum sans état du dépôt publie ainsi un journal de 43 octets pour un bloc entier.

Pour une preuve vérifiée sur Ethereum, donnez aux deux valeurs publiques une longueur fixe. Le contrat vérificateur déployé est construit pour une seule longueur d’entrée et une seule longueur de sortie, et refuse tout le reste (Régler sur la chaîne).

Le statut de sortie#

Rien n’est publié à la sortie au-delà de ce qui a été consigné, et une exécution qui panique ou se termine avec un statut non nul a une preuve valide de ce qu’elle a fait. Un vérificateur lit donc le statut de sortie avant de lire le journal. Sur la chaîne, le contrat vérificateur prend le statut attendu en argument, et une application passe 0. Les statuts propres au SDK :

Choisissez vos propres codes d’échec en dehors de ceux-ci, comme le fait l’exemple du registre avec 1, 2 et 3.

Ce que la preuve ne dit pas#

• Rien n’ordonne les écritures du journal, et rien n’oblige un programme invité à lire son entrée. La preuve lie le contenu des fenêtres, pas les accès qui l’ont produit.
• Les données auxiliaires sont modifiables. Un rangement dans leur région est un rangement ordinaire. Elles restent non liées dans un cas comme dans l’autre.
• Le journal est tout le contenu final de la fenêtre. commit maintient cette forme. Un programme invité qui écrit directement dans la fenêtre doit la respecter : une longueur d’au plus 16 380, autant d’octets, puis des zéros.

La spécification énonce tout cela avec précision : Valeurs publiques et données auxiliaires.

Certains calculs sont bien moins coûteux à prouver avec un circuit conçu pour eux que sous forme de suite d’instructions RISC-V. Apogee les appelle des délégations. Une délégation est une famille de circuits qui prouve une fonction d’un cadre de mots en RAM, invoquée par un ecall, et le SDK des programmes invités effectue ces appels pour vous derrière des fonctions ordinaires. Vous n’écrivez jamais d’ecall vous-même.

Ce que vous appelez, et ce que cela atteint#

Les fonctions sont identiques bit à bit à leurs définitions logicielles. keccak256 est le Keccak d’Ethereum, pas SHA3-256. sha256 est conforme à FIPS 180-4. ec_add utilise la formule complète de Renes, Costello et Batina (2015, algorithme 7), si bien que le doublement, P + (−P), l’élément neutre et tout Z ne demandent aucun cas particulier.

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

Le code des bibliothèques les atteint aussi#

L’espace de travail des programmes invités corrige trois crates pour que leur code appelle les délégations sur la cible des programmes invités, le code amont servant de chemin de repli :

Un programme invité qui dépend de ces crates reçoit automatiquement les copies corrigées, par la section [patch.crates-io] de guests/Cargo.toml. Sans correctif, la multiplication et l’élévation au carré dans le corps de k256 représentaient à elles seules 44 % des cycles d’un bloc du réseau principal. La récupération de clé à partir d’une signature secp256k1 est du code k256 ordinaire, que les correctifs transforment en arithmétique déléguée.

Ce que coûte une délégation#

Une famille de délégation ne fait partie d’un programme que si le programme lie l’un de ses shims, et un appel se paie en shards de la hauteur de cette famille :

• Liée et jamais appelée : rien. La famille est déclarée et prouve zéro shard.
• Appelée une fois : un shard entier. Un shard coûte sa hauteur complète, quel que soit son taux d’occupation.
• Appelée souvent : très peu par appel. La preuve d’un shard ne grandit que d’un tour de sumcheck par variable à mesure que sa hauteur augmente.

Le prix se paie en mémoire plus qu’en temps : la passe avant d’un shard KECCAK_F de 2^18 occupe environ 42 GiB d’éléments du corps, et deux de ces shards en cours de traitement ont fixé le pic du bloc Ethereum mesuré.

Règles sur les opérandes#

• Des opérandes inférieurs à leur module. Un opérande de MOD_MUL ou d’EC_ADD supérieur ou égal au module que désigne son sélecteur n’a pas de preuve : l’exécuteur refuse le cadre par une erreur fatale DelegationFrame. La version embarquée de k256 réduit ses éléments du corps à réduction paresseuse avant l’appel.
• Les points ne sont pas vérifiés à votre place. EC_ADD prouve l’arithmétique de la formule. Savoir si un point est sur la courbe est l’affaire du code appelant, et un programme invité qui tire des points des données auxiliaires (advice) doit poser la question.
• Chaque opération en plusieurs appels correspond à une seule fonction du SDK. Une permutation keccak représente 24 appels sur un même cadre, une compression SHA-256 en représente 16, une addition de points 3. Chaque appel prouve sa propre étape, et rien ne refuse des appels passés dans le mauvais ordre : ils calculent autre chose. Utilisez keccak256, sha256 et ec_add, qui émettent les appels dans l’ordre, plutôt que les shims bruts.
• Le statut 72 signifie qu’une délégation a répondu quelque chose que son shim refuse. Sur l’exécuteur d’Apogee lui-même, cela n’arrive pas pour un cadre bien formé.

Ce qui n’est pas délégué#

• Le MULMOD de l’EVM avec un module arbitraire, MODEXP, BLS12-381, et toute primitive absente du tableau ci-dessus s’exécutent sous forme d’instructions.
• Aucun schéma de signature ni aucun couplage n’est délégué en bloc. La récupération de clé secp256k1, c’est k256 sur MOD_MUL et EC_ADD; un couplage BN254, c’est ark-bn254 sur MOD_MUL.
• Une délégation est le cœur d’une opération. Le bourrage, les éponges, les boucles sur les blocs et l’échelle d’une multiplication scalaire relèvent du code du programme invité, prouvé sous forme d’instructions.

Les schémas de signature pour les programmes invités figurent dans la feuille de route de la v2.0.0.

Une nouvelle délégation en vaut-elle la peine?#

Le profileur de cycles chiffre les candidats évidents dans chaque rapport, sous forme de plafond sur les cycles qu’une délégation pourrait éliminer :

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

cycles est la part de l’exécution qui revient à la catégorie, calls le nombre d’entrées dans les fonctions du candidat, et 4 + 2·frame_words le shim qu’une délégation laisserait derrière elle : les rangements du cadre, l’ecall et les chargements du résultat. La formule ne compte rien pour les shards de la nouvelle famille : traitez-la comme une borne supérieure. Exécuter et profiler montre un rapport.

La spécification de chaque délégation, colonne par colonne, se trouve sous Circuits de délégation.

Compiler#

À partir du répertoire du programme invité, sans autre option que la cible :

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

L’ELF se retrouve dans l’unique répertoire cible de l’espace de travail des programmes invités, guests/target/riscv32imac-unknown-none-elf/. guests/.cargo/config.toml ajoute deux arguments de l’éditeur de liens que vous ne tapez jamais :

• -T crates/guest-sdk/link.ld, la carte mémoire, qui définit aussi les symboles qu’utilisent le code de démarrage et l’allocateur.
• --no-relax. La relaxation de l’éditeur de liens réécrit des séquences d’instructions et décale toutes les adresses qui suivent, et l’identité du programme lie ces adresses.

Il n’y a pas de runner : rien en dehors d’Apogee ne projette les régions d’un programme invité, si bien que cargo run n’a rien avec quoi l’exécuter. Vous exécutez un programme invité au moyen de l’émulateur (Exécuter et profiler).

Profils#

guests/Cargo.toml fixe les deux profils à une seule sémantique. Ils ne diffèrent que par l’optimisation et par les assertions de débogage des dépendances :

Le profil release par défaut de Cargo désactive les vérifications de dépassement, et dans un programme invité, ce n’est pas un réglage de performance. Cela change l’énoncé : u32::MAX + 1 consignerait 00000000 et se terminerait avec le statut 0, là où la compilation dev panique avec le statut 101. L’espace de travail garde donc les vérifications actives dans les deux profils. Une assertion de débogage d’une dépendance vérifie un invariant propre à cette crate, et une dépendance correcte calcule la même chose sans elle : release les désactive donc et économise ces cycles, soit 6,8 % de l’exécution du programme invité Ethereum sans état.

Prouvez la compilation release. Chaque instruction exécutée est une ligne prouvée, opt-level = 3 retire d’un quart à plus de la moitié de l’image d’un programme invité, et le code de chaque famille doit tenir dans sa table décodée : l’image debug du programme invité Ethereum exige des tables de 2^22 lignes, son image release, des tables de 2^20. L’identité que vous publiez est celle de l’image release.

Reproductibilité#

Deux compilations propres sur une même machine produisent des ELF identiques. Des compilations sur deux machines, en général, non : l’ELF incorpore, dans les chaînes de localisation des paniques, les chemins absolus des sources de core de la chaîne d’outils, de crates/guest-sdk et du registre cargo, tandis que les fichiers propres au programme invité apparaissent relativement à guests/. Une compilation ailleurs donne une autre image, avec une autre identité.

Ce que vous enregistrez et transmettez est donc l’ELF d’une compilation, et non une recette. Conservez l’ELF que vous avez prouvé, et laissez quiconque veut vérifier l’identité la recalculer à partir de cet ELF, des paramètres et du fichier de cérémonie.

Exporter l’image#

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

Cette commande écrit artifacts/my-app.img, la ProgramImage chargée dans son format de sérialisation (postcard, sans en-tête), et artifacts/my-app.img.txt, un rapport produit à partir de l’image relue par le lecteur validant. Elle affiche le point d’entrée, le nombre de segments et d’instructions, ainsi que la taille et le SHA-256 de l’artefact. Si la relecture diffère, ou si le chargeur refuse l’ELF, elle n’écrit rien.

Le .img est la description statique du programme, à conserver et à comparer; rien en aval n’en a besoin, puisque la mise en place et les outils prennent l’ELF. Son SHA-256 fixe des octets. Ce n’est pas l’identité du programme.

Lire le rapport#

Une instruction compressée garde son adresse et ses deux octets; seul len indique si le pc suivant est pc + 2 ou pc + 4. Pour les mnémoniques, utilisez la vue tables ci-dessous ou le désassembleur de la chaîne d’outils fixée :

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

Les demi-mots not code#

Un rapport peut afficher une ligne comme ---- not code: 0x00010f9a .. 0x00010f9c, 1 halfword ----. C’est une sortie ordinaire du compilateur. LLVM a prouvé que la branche par défaut d’un match était inatteignable, rustc a abaissé le bloc inatteignable en unimp, et avec l’extension C, c’est c.unimp, le demi-mot entièrement nul, l’encodage que RVC définit comme illégal. Le chargeur l’enregistre comme une non-instruction et poursuit. Aucun pc ne l’atteint; un pc qui l’atteindrait arrêterait l’exécution avec NotAnInstruction.

Ce que la VM prouvera#

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

Cette commande affiche, aux paramètres par défaut, la VmConfig que dérive l’image : la hauteur de chaque famille, ses lignes actives et ses colonnes décodées. Elle affiche ensuite, pour chaque instruction, le pc, next_pc, la famille, le mnémonique et les champs. Avec --ptau et le fichier de cérémonie, elle affiche aussi l’identité du programme, la valeur qu’enregistre un vérificateur. Le Démarrage rapide en montre une réelle.

L’identité est un seul élément du corps. Elle lie chaque instruction avec son pc, sa longueur, ses opérandes et son type, chaque octet de l’image issu du fichier (.text, .rodata, .data), le point d’entrée, l’ensemble des familles, chaque hauteur, le plafond de taille du code et la version du code. Elle ne lie ni la table des symboles, ni .bss, ni rien de ce que choisit une exécution. Un même ELF avec deux réglages de hauteurs a deux identités.

La dérivation refuse le programme dans les cas suivants, en nommant le pc ou la taille :

Vérifier une compilation#

Compilez dans un répertoire cible neuf, exportez de nouveau, et comparez :

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

Exécuter un programme invité ne coûte presque rien; le prouver coûte en proportion des cycles qu’il exécute. Exécutez donc d’abord, comparez avec votre compilation pour l’hôte, et examinez le profil des cycles avant de prouver quoi que ce soit.

Depuis Rust : l’émulateur#

emulator::run exécute une image chargée sur une entrée publique et des données auxiliaires (advice), dans du code hôte, sans preuve :

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 renvoie une Execution : les registres finaux, le statut de sortie, le nombre de cycles et les valeurs publiques. Un statut de sortie non nul est une exécution, pas une erreur, et revient dans exit_code. Une erreur fatale de l’exécuteur, comme OutOfBounds, Misaligned ou NotAnInstruction, revient sous la forme d’une EmuError, et une telle exécution n’a pas de preuve (Dépannage).

L’émulateur est une fonction pure de l’image et de l’entrée : ni horloge, ni aléa, ni fils d’exécution. La même entrée donne la même exécution, cycle pour cycle, et c’est aussi ce qui permet au prouveur d’exécuter deux fois et de découper des shards identiques.

En ligne de commande : le profileur#

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

Il exécute le programme invité sur les fichiers donnés, à la plus petite hauteur de table dans laquelle tient son code, et affiche un rapport. Ses chiffres sont des décomptes de cycles exécutés, identiques sur toute machine.

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]

Comment le lire :

• La section cycles by family montre ce que vous payez. Chaque famille qui a des lignes coûte au moins un shard de sa hauteur, et plus de cycles dans une famille signifie plus de shards de cette famille.
• La section top functions impute à chaque fonction ses propres cycles, y compris tout ce que le compilateur y a intégré en ligne, mais pas ceux des fonctions qu’elle appelle. Les appels sont comptés à la première instruction de la fonction.
• La section cycles by semantic workload regroupe les fonctions en quatorze catégories selon leur nom, comme le hachage, les signatures et l’environnement d’exécution de base. La part non attribuée et la répartition des mnémoniques servent de contrôle à cette attribution, puisqu’aucune table des symboles ne peut les étiqueter de travers.
• La section accelerator candidates chiffre les délégations qu’une version future pourrait ajouter, sous forme de plafond : voir Délégations.

Le profileur a deux autres verbes, pour la charge de travail Ethereum : block <stem> exécute le programme invité revm sur des données de référence enregistrées, et record <number|latest> enregistre un bloc à partir de ETH_RPC_URL et l’exécute.

Réduire le coût#

L’ordre qui est généralement rentable :

1. Compilez avec --release. L’optimisation retire d’un quart à plus de la moitié des instructions d’un programme invité.
2. Déléguez le hachage et l’arithmétique de courbe. Utilisez guest_sdk::keccak256, sha256, ec_add et les versions embarquées de k256 et ark-ff, au lieu de compiler une implémentation logicielle dans le programme invité.
3. Cessez d’allouer dans les boucles. Chaque allocation coûte des instructions, et avec un allocateur linéaire, c’est aussi de la mémoire que vous ne récupérez jamais (le tas).
4. Vérifiez au lieu de calculer. Si un résultat est coûteux à trouver et peu coûteux à vérifier, comme un ordre trié, une racine carrée ou un chemin dans un arbre, laissez le prouveur le fournir sous forme de données auxiliaires et faites-le vérifier par le programme invité.
5. Évitez la virgule flottante. Elle se compile en routines logicielles; l’arithmétique entière et en virgule fixe coûte bien moins cher.

Puis mesurez de nouveau. Les décomptes de cycles sont exacts et reproductibles : chaque changement se traduit par un nombre.

Les trois appels#

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 charge l’ELF, le décode en ses tables de familles et sa VmConfig, engage les colonnes de mise en place sous la cérémonie, et construit la clé de vérification. Son coût se paie une fois par programme et par choix de hauteurs, et non à chaque exécution.
• host::prove exécute le programme invité deux fois et prouve chaque shard (ci-dessous). Il renvoie un Proven : le BlockProof, le code de sortie, le nombre de cycles, le journal et un rapport sur l’exécution.
• host::verify vérifie le bloc par rapport à la clé, à l’aide de l’énoncé que porte le bloc. Il ne compare ni l’identité ni le condensé SRS à quoi que ce soit : cette comparaison vous revient.

Le Démarrage rapide exécute exactement ce code sur un petit programme invité, avec sa sortie réelle.

Ce qu’un vérificateur doit détenir lui-même#

Deux valeurs proviennent d’un canal que le prouveur ne contrôle pas :

1. L’identité du programme. Face à une identité fournie par le prouveur, une preuve montre seulement qu’un programme quelconque s’est exécuté. Un vérificateur enregistre l’identité de la version à laquelle il fait confiance et la compare à celle de la clé.
2. Le condensé SRS de la cérémonie. Une clé se charge sous le condensé que donnent ses propres points, quel qu’il soit. Une clé construite sur un τ connu pourrait ouvrir n’importe quoi, et n’est refusée que par la comparaison de son condensé avec celui de la cérémonie.

La clé de vérification elle-même peut provenir de n’importe qui, y compris du prouveur : son chargement recalcule l’identité et le condensé SRS à partir de son propre contenu et exige que ses circuits soient ceux du registre du vérificateur. Lisez ensuite l’énoncé : le statut de sortie d’abord, puis le journal.

Hauteurs#

Chaque famille a une hauteur, le nombre de lignes de l’un de ses shards, choisie parmi 2^8, 2^12, 2^16, 2^18, 2^20, 2^22. Les hauteurs font partie du programme, et non d’une exécution : chaque hauteur est liée dans l’identité.

Une famille qui a des lignes coûte au moins un shard entier de sa hauteur : une exécution courte gaspille donc moins aux petites hauteurs, et une longue a besoin de moins de shards aux grandes hauteurs. Une table décodée doit aussi être assez haute pour atteindre la dernière instruction de la famille : 2^20 atteint 1,9375 MiB de code et 2^22 atteint 7,9375 MiB. Le programme invité Ethereum se prouve à 2^20 pour chaque famille dont la hauteur est au choix.

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
}

La cérémonie doit fournir autant de puissances que la famille la plus haute a de lignes, et au moins 2^18 pour la table de lookup générique : Srs::from_ptau(path, k) avec 2^k au moins égal à la plus grande hauteur.

Shards en cours de traitement#

Le troisième argument de host::prove est max_in_flight, le nombre de shards prouvés simultanément. C’est le seul réglage qui échange de la mémoire contre du temps :

• La mémoire suit les shards en cours de traitement, et non le nombre de cycles. Chaque shard en cours de traitement occupe ses lignes, sa passe avant et sa preuve à mesure qu’elle grandit. Un shard 2^20 de la famille d’instructions la plus large occupe environ 8,4 GiB dans sa passe avant; un shard KECCAK_F de 2^18, environ 42 GiB.
• Le temps suit le nombre de shards qui avancent côte à côte, jusqu’à concurrence de vos cœurs. Au sein d’un shard, le travail s’exécute sur tous les cœurs.
• La preuve n’en dépend pas. Le bloc est identique octet pour octet avec 1 ou 8 shards en cours de traitement.

Commencez bas sur un portable, à deux ou quatre, et augmentez la valeur sur un serveur jusqu’à ce que la limite soit la mémoire, et non les cœurs. bench prove utilise 8 par défaut.

Les deux passes#

host::prove travaille en flux. Il ne détient jamais la trace d’exécution entière, qui, à environ 300 octets par cycle, serait le plus gros objet du système.

1. La passe 1 exécute le programme invité et, à mesure que chaque shard se remplit, engage ses colonnes mémoire, conserve les engagements et abandonne les lignes. À la sortie, elle construit l’énoncé et tire les défis que partagent tous les shards.
2. La passe 2 exécute de nouveau. L’émulateur est déterministe : elle découpe donc les mêmes shards. Chacun est rempli, prouvé et abandonné à son arrivée, et seule sa preuve est conservée.

C’est pourquoi la génération de preuves prend le temps de deux exécutions, avec une mémoire bornée par les shards en cours de traitement. Le prouveur en flux l’explique en profondeur.

Conserver la preuve#

host::proof_archive::write_proof(dir, stem, vk, block) écrit quatre fichiers, chacun contenant les octets bruts de son type :

<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) les relit. Le fichier .identity enregistre ce qu’a affirmé l’exécution; un vérificateur compare tout de même avec sa propre copie. L’outil en ligne de commande verifier vérifie une archive :

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

Il se termine avec le code 0 quand tout est vérifié, 1 en nommant le premier refus, et 2 en cas d’erreur d’utilisation ou d’identité mal formée. Il compare l’identité que vous passez à celle de la clé, et prend le condensé SRS dans le fichier de la clé.

Quand une preuve échoue#

Un prouveur honnête ne produit jamais une preuve qui échoue : un échec signifie donc une entrée qu’il n’aurait pas dû accepter, ou un bogue. Recompilez avec le journal de débogage du prouveur activé, puis relancez :

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

Le journal de débogage nomme le shard qui a échoué, et self_check FAILED nomme la première porte que viole une ligne, avec la valeur de chaque opérande. Outils énumère chaque marqueur. Ce journal n’existe que dans les compilations dotées de la fonctionnalité debug-info et ne change aucun octet de preuve.

Ensuite : Régler sur la chaîne.

Une preuve de base est un bloc de preuves de shards, chacune étant une preuve GKR accompagnée de ses engagements : des mégaoctets de données et des centaines de points de courbe, qu’aucun contrat ne peut vérifier. Le règlement la compresse en trois étapes, chacune lancée avec bench à partir de la racine du dépôt.

1. L’arbre de récursion#

Un nœud, c’est Apogee qui prouve un programme vérificateur. Une feuille vérifie une suite de shards de base consécutifs; un nœud interne vérifie de deux à quatre preuves enfants; la racine couvre tous les shards de base. Chaque nœud replie aussi chaque vérification Mercury que ses shards et ses enfants diffèrent en une seule paire de points, si bien que l’arbre entier se réduit à une seule affirmation de couplage au sommet.

# 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 écrit les clés des deux programmes de récursion, construit sur elles les binaires feuille et nœud, fixe un plan avant que quoi que ce soit ne soit prouvé (<out>/tree.txt : des feuilles d’au plus --leaf 64 shards de base, puis des nœuds d’au plus --fan-in 4 enfants), et prouve nœud par nœud. Chaque nœud est un processus distinct, qui vérifie ses entrées en natif avant de prouver, si bien qu’une mauvaise entrée est refusée nommément. Une exécution interrompue reprend : les preuves déjà présentes dans <out> sont conservées, et une exécution dont le plan ou les programmes diffèrent est refusée.

La preuve de base n’est en rien touchée par tout ceci. Une feuille vérifie les shards de base exactement tels qu’ils sont.

2. Le décideur#

La racine reste une preuve GKR accompagnée de quelques centaines de points. Le décideur est un circuit Groth16 qui vérifie la racine comme le ferait un nœud, et ne replie rien. Il lie plutôt, sous forme de fils dont le contrat fournit les valeurs, les identités des deux programmes de récursion, le statut de sortie de l’énoncé de base, son entrée publique et son journal octet par octet, et chaque point auquel la racine doit un couplage, avec son scalaire. La preuve Groth16 porte un seul engagement sur l’ensemble de ces fils, et le contrat le vérifie par rapport aux valeurs qu’il détient.

Une clé Groth16 exige une cérémonie. La phase 1 est le même fichier de puissances de tau que celui sur lequel reposent les engagements de l’arbre. La phase 2 est propre au circuit et se déroule en deux tours de contributions :

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

Chaque contribution multiplie une trappe par un facteur que seul son contributeur connaissait, et l’enregistre avec une preuve de Schnorr, si bien que tout état peut être vérifié par rapport au seul circuit et au seul fichier de cérémonie. Une trappe reste inconnue tant qu’un seul de ses contributeurs a été honnête. L’ordre des tours fait partie de la solidité (soundness) : alpha et beta sont achevés avant que quoi que ce soit ne soit divisé par delta ou eta.

decide écrit decision.constructor et decision.calldata : les arguments de déploiement et l’appel, en hexadécimal.

3. Le contrat#

contracts/ApogeeVerifier.sol a un seul point d’entrée :

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

Il reconstruit les valeurs liées à partir du calldata, vérifie l’équation de couplage de Groth16, replie les points de chaque côté avec ecMul et ecAdd, ce qui astreint aussi chaque point à la courbe, et vérifie l’affirmation repliée e(A, [1]_2) = e(B, [x]_2). Un contrat d’application l’appelle, puis agit selon le journal : voir l’esquisse du registre.

Ce que fixe un déploiement#

Le constructeur prend la clé Groth16, les deux points G2 de la cérémonie, les identités des programmes feuille et nœud, le nombre de points de chaque côté, et les longueurs en octets de l’entrée publique et du journal. Un vérificateur déployé sert donc :

• Un seul programme de base. Son identité est une constante de l’image du programme feuille, que lie l’identité de la feuille.
• Une seule forme de racine. Le circuit du décideur dépend du programme de la racine, de ses nombres de shards et des longueurs des valeurs publiques : une clé et sa cérémonie sont donc propres à chaque forme.
• Des valeurs publiques de longueur fixe. verify refuse une entrée ou un journal de toute autre longueur. Concevez des programmes invités dont les valeurs publiques sur la chaîne ont une taille fixe, comme un enregistrement fixe ou un condensé de 32 octets.

Le contrat paie environ 9 000 gas par point, parce que le circuit n’en replie aucun.

Mesures#

Bloc 257 510, avec l’arbre sur une machine à 32 CPU et 247 GiB, et la cérémonie et le décideur sur un portable à 18 cœurs :

La spécification de l’ensemble se trouve dans Récursion et décideur.

Écrire un programme invité, c’est surtout écrire du Rust. Cette page traite du reste : les endroits où une machine prouvée, sans système d’exploitation et à un seul hart, se comporte autrement que l’hôte auquel vous êtes habitué. Chaque règle dit quoi faire, pourquoi, et ce qui tourne mal autrement. Le Compagnon IA reprend les mêmes règles sous une forme que vous pouvez remettre à un modèle.

Types et mémoire#

usize fait 32 bits, comme tous les pointeurs#

La cible des programmes invités est riscv32imac : usize, isize et tous les pointeurs ont une largeur de 32 bits, alors que ceux de votre hôte en ont 64.

• Un dépassement de usize provoque une panique dans le programme invité, mais pas sur l’hôte.
• x as usize à partir d’un u64 tronque sans rien signaler dans le programme invité.
• size_of::<T>(), la disposition des structures et core::hash de tout ce qui contient une longueur ou un pointeur diffèrent entre les deux compilations.

À faire : utilisez explicitement u32 et u64 dans tout ce que vous consignez, hachez, sérialisez ou comparez avec un calcul de l’hôte. Convertissez avec usize::try_from(x) là où une valeur risque de ne pas tenir, pour que l’échec soit bruyant sur les deux compilations. À ne pas faire : consigner un usize, hacher une structure qui en contient un, ou dériver un encodage qui dépend de la disposition en mémoire.

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`

L’allocateur ne libère jamais rien#

Le tas est un allocateur linéaire (bump allocator) : alloc fait monter un pointeur, dealloc ne fait rien, et la mémoire n’est rendue qu’à la fin du programme. Ainsi, ce qui épuise la mémoire d’un programme invité, c’est le total qu’il alloue au cours de l’exécution, et non son pic. Quand une allocation empiéterait sur la réserve de la pile, ou se terminerait au-dessus du pointeur de pile courant, le programme invité se termine avec le statut 71.

À faire :

• Allouez une fois et réutilisez : sortez les tampons des boucles et videz-les avec clear() au lieu d’en construire de nouveaux.
• Dimensionnez les collections dès le départ avec Vec::with_capacity, String::with_capacity, pour qu’elles ne soient pas réallouées et recopiées à mesure qu’elles grandissent. Un Vec qui grandit d’un push à la fois jusqu’à n éléments laisse aussi derrière lui ses tampons antérieurs, plus petits.
• Préférez l’emprunt (&[u8], &str) au clonage, et les itérateurs aux collections intermédiaires.
• Traitez sur place les données auxiliaires (advice) volumineuses : advice() est déjà une tranche sur la mémoire, il n’y a donc rien à copier.

À ne pas faire : appeler collect() vers un nouveau Vec dans une boucle critique, cloner des valeurs que vous ne faites que lire, ou reconstruire une table associative à chaque requête alors qu’une seule table peut être vidée et remplie de nouveau.

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

La pile dispose de 8 MiB, et rien ne protège sa limite basse#

La pile croît vers le bas à partir de 0x8000_0000 et dispose d’une réserve de 8 MiB dans laquelle aucun bloc du tas ne peut entrer. Une récursion profonde à l’intérieur de cette réserve ne pose aucun problème. Ce que rien ne détecte, c’est une pile qui dépasse sa réserve après que le tas a rempli l’espace situé sous elle : des blocs du tas changent alors sous une chaîne d’appels profonde, sans que rien ne le signale. À faire : gardez la profondeur de récursion bornée et prévisible, ou écrivez les parcours profonds de façon itérative, avec une liste de travail explicite. À ne pas faire : pousser la récursion jusqu’à une profondeur fixée par une entrée non fiable.

Accès alignés uniquement#

Un accès à un demi-mot ou à un mot par un pointeur non aligné est fatal, n’est jamais scindé, et l’exécution n’a pas de preuve. Le Rust sûr n’en produit jamais. Ne convertissez pas un pointeur d’octets en *const u32 pour le déréférencer; lisez avec u32::from_le_bytes, qui se compile en chargements d’octets, ou avec ptr::read_unaligned.

L’adresse nulle est un trou#

Les adresses inférieures à 0x8000 n’appartiennent à rien : un pointeur nul ou un petit pointeur sauvage provoque donc un OutOfBounds fatal plutôt qu’une lecture de données arbitraires. L’erreur se manifeste par une exécution sans preuve, jamais par une mauvaise réponse.

Concurrence#

Opérations atomiques : prises en charge, mais pas pour du code nouveau#

Ce qu’il faut savoir si des opérations atomiques atteignent votre programme invité par une dépendance :

• Sur un seul hart, une opération atomique n’est qu’une lecture-modification-écriture. fetch_add est un amoadd.w qui additionne; rien ne peut s’intercaler.
• sc.w réussit toujours. La machine ne conserve aucun état de réservation : un rangement conditionnel range donc sa valeur et écrit 0 dans rd. La boucle de nouvelle tentative lr.w/sc.w qu’utilise le code compilé pour compare_exchange n’en est pas affectée, car la réussite du premier coup est légale sur n’importe quel hart. Le code qui compte sur l’échec de sc.w en l’absence de réservation valide n’obtient pas cet échec ici. C’est le seul point sur lequel Apogee s’écarte de RV32IMAC.
• fence ne fait rien, et les ordonnancements mémoire (aq, rl, SeqCst) n’ordonnent rien sur un seul hart.
• Elles coûtent une famille de circuits. Une opération atomique ajoute la famille ATOMICS au programme, qui en prouve alors au moins un shard.

À faire : utilisez des variables ordinaires, Cell et RefCell pour l’état dans le code d’un nouveau programme invité. À ne pas faire : ajouter AtomicU32, des verrous actifs à la manière de Mutex ou Arc à un programme invité qui n’a aucun second fil d’exécution avec qui les partager.

Entrées et sorties#

Vérifier les données auxiliaires avant que quoi que ce soit qui en dérive n’atteigne le journal#

Les données auxiliaires sont de la mémoire que le prouveur a remplie, et rien ne les lie. Vérifiez-les par rapport à quelque chose que la preuve lie bel et bien, comme un hachage ou une racine de Merkle dans l’entrée publique, une signature, ou une propriété du résultat, avant de consigner quoi que ce soit qui en dépende. Consigner une fonction de données auxiliaires non vérifiées publie une valeur choisie par le prouveur. Voir le motif.

Garder les valeurs publiques petites, et de taille fixe pour un usage sur la chaîne#

L’entrée et le journal contiennent chacun au plus 16 380 octets. commit termine l’exécution avec le statut 70 plutôt que de déborder. Les grandes entrées ont leur place dans les données auxiliaires, derrière un engagement, et les sorties qui grandissent, derrière un condensé. Un contrat vérificateur est construit pour une seule longueur d’entrée et une seule longueur de journal : un programme invité réglé sur Ethereum devrait donc publier un journal de taille fixe.

Décider à quoi ressemble l’échec#

Un programme invité qui se termine avec un statut non nul, ou qui panique, a tout de même une preuve valide de ce qu’il a fait, et un vérificateur lit le statut avant le journal. Donnez à chaque refus son propre code de sortie, en dehors de ceux du SDK (70, 71, 72 et 101), et ne consignez rien qui dérive de données non vérifiées avant les vérifications qui peuvent les refuser.

Aucun monde extérieur#

Un programme invité n’a ni horloge, ni aléa, ni réseau, ni fichiers, ni environnement. Un appel de bibliothèque qui demande l’un d’eux à l’hôte répond -ENOSYS et rend l’exécution non prouvable. Initialisez HashMap avec une graine déterministe ou utilisez BTreeMap; dérivez l’aléa de l’entrée quand un algorithme en a besoin; transmettez l’heure en entrée.

Coût#

Chaque instruction exécutée est une ligne prouvée#

Le coût de la preuve suit le nombre de cycles, famille par famille. Compilez avec --release, mesurez avec le profileur, et traitez les cycles comme les programmeurs de systèmes embarqués traitent les octets.

Déléguer ce qui a un circuit#

keccak256, sha256, l’addition et la multiplication sur courbes elliptiques, Poseidon2, l’arithmétique dans le corps de BN254 et la multiplication modulaire sur 256 bits ont des circuits dédiés. Atteignez-les par guest_sdk et par les versions embarquées de k256, ark-ff et revm-precompile, et non par une implémentation logicielle compilée dans le programme invité. Voir Délégations.

Vérifier au lieu de calculer#

Quand un résultat est coûteux à trouver et peu coûteux à vérifier, laissez le prouveur le trouver et le transmettre sous forme de données auxiliaires, et faites-le vérifier par le programme invité : un ordre trié, une factorisation, un inverse, un chemin dans un arbre, un résultat de recherche.

Éviter la virgule flottante#

La cible n’a pas d’extension F ni D : f32 et f64 se compilent donc en routines logicielles sur entiers. Elles sont correctes et déterministes, et chaque opération coûte de nombreuses instructions. Utilisez des entiers ou la virgule fixe.

Les hauteurs coûtent des shards entiers#

Une famille qui a des lignes coûte au moins un shard de sa hauteur, si peu de lignes qu’elle remplisse. Un programme qui touche une famille une seule fois paie un shard entier; les familles qu’utilise votre code, et les hauteurs que vous choisissez, fixent le plancher de chaque preuve. Voir Hauteurs.

Code et identité#

Le flux d’instructions est l’image#

Le code est statique : l’instruction de chaque pc provient des tables décodées construites au chargement, jamais de la RAM. Un rangement dans .text change des données, pas le comportement, et un saut vers un demi-mot sans instruction termine l’exécution sans preuve. Il n’y a ni JIT ni code automodifiant.

Un seul mot illégal, où qu’il soit, fait refuser le programme#

Le décodeur prend tout .text, atteignable ou non. Un accès à un CSR, fence.i, un encodage à virgule flottante ou RV64 dans de l’assembleur en ligne, ou des données assemblées dans .text, font refuser le programme entier par la dérivation. ebreak se décode, mais n’a pas de preuve.

Les vérifications de dépassement font partie du programme#

Les profils des programmes invités laissent overflow-checks activé en release, parce que désactiver ces vérifications change ce que calcule un programme invité : u32::MAX + 1 reboucherait à zéro et l’exécution se terminerait avec le statut 0 au lieu de paniquer. Utilisez wrapping_*, checked_* et saturating_* là où c’est votre intention.

Une compilation est une identité#

L’identité lie chaque octet de code et de données, le point d’entrée et chaque hauteur. Recompiler sur une autre machine produit une autre identité, parce que l’ELF incorpore des chemins absolus. Enregistrez et livrez l’ELF que vous avez prouvé, pas la commande qui l’a produit.

Liste de vérification#

Avant de prouver :

• cargo build --release pour riscv32imac-unknown-none-elf, et le rapport de cycles du profileur examiné
• aucun usize dans ce qui est consigné, haché ou sérialisé
• aucune allocation dans les boucles critiques; les collections qui grandissent dimensionnées avec with_capacity
• aucune opération atomique, aucun verrou ni aucun Arc dans votre propre code de programme invité
• chaque usage des données auxiliaires vérifié par rapport à quelque chose que la preuve lie, avant toute consignation qui en dépend
• le journal borné, et de taille fixe s’il est réglé sur la chaîne
• le hachage et l’arithmétique de courbe acheminés par les délégations
• un code de sortie distinct pour chaque refus
• la compilation pour l’hôte et l’émulateur concordent sur le journal pour vos entrées de test
• l’identité du programme relevée à partir de l’ELF que vous livrerez

Un programme invité peut s’arrêter en six points avant d’obtenir une preuve vérifiée. Trouvez le symptôme, puis la ligne.

L’exécution se termine avec un statut inattendu#

L’exécution s’est terminée et est prouvable; c’est le programme invité qui a choisi d’échouer. Les statuts propres au SDK :

Tout autre statut est votre propre exit(code).

L’exécution s’arrête sur une erreur fatale#

L’émulateur renvoie une EmuError, et il n’y a ni statut de sortie ni preuve :

L’ELF est refusé#

artifact-dump, host::setup et les outils refusent un ELF que le chargeur ne peut pas prendre, avec une LoaderError :

Le programme ne s’enregistre pas#

L’ELF se charge, mais le programme ne peut pas être décodé en une configuration :

La construction d’une clé échoue aussi si une famille qu’utilise le programme est réglée sous son plancher, 2^20 pour une famille d’instructions et 2^16 pour les familles de fenêtres de RAM, puisqu’aucun circuit n’existe à ces hauteurs.

Le prouveur échoue#

Un prouveur honnête qui prouve ce qu’a exécuté l’émulateur n’échoue pas : un échec désigne donc une entrée qu’il n’aurait pas dû accepter, ou un bogue. Deux cas expliquent la plupart des échecs :

• Un appel sans preuve. Un appel système autre qu’EXIT et les délégations, qu’une bibliothèque a effectué pour obtenir des données de l’hôte, répond -ENOSYS et l’exécution continue, mais le remplissage du prouveur refuse cette ligne et nomme le cycle. Trouvez la dépendance qui demande de l’aléa ou l’heure.
• Mémoire épuisée. Le processus est tué alors que des shards sont en cours de traitement. Réduisez le troisième argument de host::prove, ou abaissez les hauteurs.

Pour tout le reste, recompilez avec le journal de débogage du prouveur et relancez :

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 nomme la première porte en échec de la ligne et la valeur de chaque opérande. Le journal de débogage énumère chaque marqueur.

La vérification échoue#

verify_shard et verify_block renvoient une VerifyError dont la classe indique ce qui a cédé :

Si vous avez construit la preuve avec le prouveur d’Apogee lui-même, à partir d’une exécution que l’émulateur a acceptée, un échec de vérification signifie que le vérificateur et le prouveur sont en désaccord sur le programme : vérifiez que vous chargez la clé sous laquelle la preuve a été produite, aux mêmes hauteurs, sur la même cérémonie.

Identité discordante#

L’identité que vous avez calculée diffère de celle que vous attendiez :

• La compilation d’une autre machine. L’ELF incorpore des chemins absolus : une recompilation ailleurs donne donc une autre image. Comparez avec l’ELF qui a été prouvé, et non avec une nouvelle compilation.
• D’autres hauteurs. Chaque hauteur est liée dans l’identité. artifact-dump tables indique l’identité aux hauteurs par défaut; votre mise en place peut en utiliser d’autres.
• Une autre cérémonie. Un fichier de puissances de tau de Hermez correspond à un autre τ, si bien que chaque engagement diffère. Comparez le [τ]_1 du fichier à celui de la cérémonie.

L’espace de travail guests/ contient tous les programmes invités que le dépôt compile et teste. Chacun existe pour mettre quelque chose à l’épreuve, ce qui en fait la meilleure référence pour le motif que vous vous apprêtez à écrire. Tous se compilent avec cargo build --target riscv32imac-unknown-none-elf à partir de leur propre répertoire.

Commencez ici#

Motifs applicatifs#

Délégations#

La machine elle-même#

Le plus petit programme invité utile#

fib lit un u32, effectue autant d’étapes de Fibonacci avec une arithmétique à rebouclage, et consigne le résultat :

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

Une entrée trop courte est une erreur, et non une invitation à compléter par défaut : un programme invité qui poursuit avec un tampon partiellement rempli prouve un énoncé sur des zéros. L’addition reboucle à dessein, si bien qu’un n supérieur à 47, au-delà du dernier terme qui tient sur 32 bits, est une entrée ordinaire avec une réponse ordinaire plutôt qu’une exécution en échec. Et il n’y a pas de données auxiliaires, parce que f_n coûte autant à un vérificateur à vérifier qu’à calculer : une réponse fournie en données auxiliaires devrait être recalculée pour être crue.

crates/guest-sdk constitue tout l’environnement d’exécution d’un programme invité : le code de démarrage, la macro d’entrée, l’allocateur, le gestionnaire de panique et les shims d’ecall. Elle ne se compile que pour riscv32imac-unknown-none-elf.

Point d’entrée#

guest_sdk::entry!(main);

Exporte le symbole main qu’appelle le code de démarrage, sous la forme d’une enveloppe qui appelle votre fonction, laquelle ne prend aucun argument et renvoie (). Votre fonction garde son propre nom et peut elle-même s’appeler main. Le retour de cette fonction équivaut à exit(0).

Les régions#

Hachage#

Courbes elliptiques#

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

Un point en coordonnées projectives homogènes, x = X/Z et y = Y/Z, chaque coordonnée étant formée de huit mots de 32 bits petit-boutistes et inférieure au module du corps de la courbe. Ce type n’est pas jacobien : le Projective d’arkworks l’est, si bien qu’un appelant qui convertit depuis ce dernier applique (X·Z, Y·Z², Z) à l’entrée et (X·Z, Y, Z³) à la sortie. L’élément neutre est (0 : 1 : 0).

La formule prouve l’arithmétique, pas l’appartenance à la courbe : vérifiez vous-même les points tirés des données auxiliaires.

Shims de délégation bruts#

guest_sdk::recursion contient les shims sur des types de cadres alignés sur un mot. Chaque type de cadre est #[repr(C, align(4))], si bien que son alignement est celui du type, et non celui de l’endroit où le générateur de code a placé une variable locale. Un shim du format de base renvoie false exactement sur -ENOSYS; toute autre réponse non nulle termine l’exécution avec le statut 72.

Chaque shim lit son numéro d’ecall dans l’enregistrement de déclaration de sa famille, un static de 12 octets placé dans sa propre section de l’éditeur de liens. Lier un shim déclare la famille; une famille déclarée qui n’est jamais appelée prouve zéro shard.

Comportement à l’exécution#

Délégation transparente#

Deux crates de bibliothèque du dépôt délèguent sur la cible des programmes invités sans nommer le SDK, par une dépendance sur celui-ci réservée à cette cible :

• field::Fr : l’addition, la multiplication de Montgomery (*, square, pow et les conversions) et inverse d’un élément non nul appellent FR_ARITH. Un programme invité qui utilise l’arithmétique de Fr déclare cette famille.
• transcript::poseidon2_permute appelle POSEIDON2.

Les versions embarquées de k256, ark-ff et revm-precompile font de même pour secp256k1, BN254 et les précompilés de l’EVM : Délégations.

La spécification de l’ABI qui sous-tend tout cela se trouve dans ABI du programme invité.

Une bonne part du code écrit pour Apogee sera rédigée par un modèle. Un modèle qui n’a jamais vu Apogee écrira un programme invité plausible qui utilise std, alloue dans chaque boucle, recourt à un compteur atomique, se fie à ses données auxiliaires (advice) et consigne un usize. Le Compagnon IA est un seul fichier Markdown qui place d’emblée en tête tout ce qui prévient ces erreurs : ce qu’est un programme invité, les règles impératives, la surface publique complète du SDK avec ses signatures exactes, des motifs à copier, les erreurs et leurs corrections, et une liste de vérification pour la revue.

Comment l’utiliser#

• Dans une conversation : joignez le fichier, ou collez-le comme premier message, avant de décrire ce que vous voulez construire.
• Dans un agent de programmation : enregistrez-le à la racine de votre projet sous le nom que votre outil lit par convention, comme AGENTS.md ou CLAUDE.md, ou ajoutez-le aux règles de projet de l’outil. L’agent le lit alors au début de chaque session.
• Pour la revue : demandez au modèle de vérifier un programme invité ligne par ligne par rapport à la section 8 du fichier, la liste de vérification pour la revue.

Le fichier énonce ses règles sous forme de MUST et de MUST NOT, chacune accompagnée de sa raison, parce que les modèles suivent plus fidèlement des contraintes explicites et expliquées que des conventions qu’ils sont censés deviner.

Ce qu’il contient#

Les règles sur lesquelles il insiste#

Le compagnon reprend les règles de ce manuel, et trois d’entre elles méritent d’être soulignées, parce que ce sont celles que les modèles enfreignent le plus souvent :

• Les pointeurs et usize font 32 bits. Un modèle entraîné surtout sur du code 64 bits sérialise usize sans y penser à deux fois. Le programme invité et l’hôte divergent alors sur les octets.
• Le tas ne libère jamais rien. Le Rust idiomatique alloue sans retenue parce qu’un véritable allocateur rend la mémoire. Ici, chaque allocation est permanente pour le reste de l’exécution : le compagnon demande donc partout la réutilisation et with_capacity.
• Les opérations atomiques se compilent, et n’ont pas leur place dans le code d’un nouveau programme invité. Elles sont prises en charge pour la compatibilité avec les bibliothèques existantes. Sur un seul hart, elles ne synchronisent rien, et elles ajoutent une famille de circuits à la preuve.

Pour les agents qui lisent directement cette documentation#

• /llms.txt répertorie chaque page de ce site en Markdown, pour les modèles qui lisent le Web.
• /docs/llms-full.txt contient toute la documentation anglaise, spécification comprise, en un seul fichier.
• Chaque page comporte un lien Voir en Markdown et un bouton Copier en Markdown, sous son titre et dans la colonne de droite.

L’anglais est la langue canonique de la documentation, et le compagnon est publié en anglais pour toutes les langues : c’est la langue que les modèles suivent le plus fidèlement, et celle dans laquelle la spécification est écrite.

Apogee prouve des exécutions de programmes RV32IMAC. Cette section décrit le système au niveau de ses grands composants : ce que fait chacun, pourquoi il est construit ainsi, et comment il passe le relais au suivant. La section Auditeurs présente le même système au niveau de chaque colonne et de chaque porte.

Ce qu’énonce une preuve#

Un vérificateur détient trois éléments qu’il ne croit pas sur la seule parole du prouveur :

• l’identité du programme, un élément du corps qui condense les tables d’instructions du programme, son image mémoire initiale, son pc d’entrée et sa configuration;
• le condensé SRS de la cérémonie que doit porter une clé de vérification;
• une clé de vérification, qui peut provenir de n’importe qui, car son chargement recalcule l’identité et le condensé SRS à partir de son propre contenu et exige que ses circuits soient ceux du registre du vérificateur.

L’énoncé de la preuve porte l’entrée publique, la sortie publique (le journal), le statut de sortie, et l’enregistrement de la forme de l’exécution : les nombres de shards, les fenêtres mémoire, les registres et le pc finaux, ainsi que les engagements mémoire et les racines de chaque shard. Une preuve dont la vérification réussit établit que le programme de cette identité, lancé à son pc d’entrée sur son image, avec l’entrée publique dans sa fenêtre d’entrée et des données auxiliaires (advice) choisies par le prouveur, s’exécute instruction par instruction jusqu’à EXIT avec ce statut, après avoir écrit ce journal. Rien n’est affirmé au sujet des données auxiliaires, et rien n’est caché : aucun engagement ni aucune preuve n’est aveuglé.

D’un binaire à un appel de contrat#

1. Le programme. Le chargeur lit l’ELF dans une ProgramImage, en développant sur place les instructions compressées. Le décodeur achemine chaque instruction vers l’une des sept familles d’instructions et construit la table décodée de chaque famille, une ligne par demi-mot de code, puis engage le tout sous la forme de l’identité du programme. Programmes et identité.
2. Exécution. L’émulateur exécute le programme invité sur un seul hart. Un cycle est une ligne de la famille à laquelle appartient son instruction, et cette ligne enregistre des lectures et des écritures horodatées du pc, des registres et de la RAM. Le hachage et l’arithmétique des grands entiers sont délégués : un ecall désigne un cadre en RAM, et une ligne d’une famille de délégation effectue le travail sur ce cadre. Exécution, familles et shards.
3. Shards. Les lignes d’une famille sont découpées en shards de la hauteur de la famille, une puissance de deux comprise entre 2^8 et 2^22. La mémoire que touche une exécution est couverte par des shards des familles de fenêtres, qui donnent à chaque mot ses valeurs initiale et finale. Le shard est l’unité de preuve; un bloc en compte des centaines.
4. La preuve d’un shard. Ses colonnes sont engagées avec Mercury. Le circuit de la famille est parcouru à rebours par le moteur GKR, de ses sorties jusqu’à ces colonnes, à raison d’un sumcheck par couche, et chaque colonne est ouverte au point unique où aboutit cette passe, en une seule ouverture groupée.
5. Le bloc. Un BlockProof est l’énoncé accompagné des preuves de ses shards. La vérification exécute la transcription globale une fois, les vérifications de chaque shard, et le rapprochement de la mémoire une fois, sur les racines de tous les shards.
6. Récursion et règlement. Des programmes vérificateurs, prouvés par Apogee lui-même, vérifient des suites de shards et replient leurs couplages différés. Un arbre de tels programmes aboutit à une racine, un circuit Groth16 revérifie la racine, et ApogeeVerifier.sol vérifie cette preuve et le couplage replié. Récursion et règlement.

Le prouveur exécute le programme invité deux fois : une fois pour engager les colonnes mémoire de chaque shard, ce qui fixe l’énoncé et ses défis, et une fois pour prouver chaque shard à mesure qu’il se remplit. Sa mémoire est bornée par les shards en cours de traitement, et non par la longueur de l’exécution. Le prouveur en flux.

Les choix qui le façonnent#

Un seul corps, une seule courbe. Tout est défini sur le corps des scalaires de BN254 : les circuits, la transcription, les engagements et la récursion. C’est ce qui permet à un nœud de l’arbre de récursion de vérifier des shards de base dans sa propre arithmétique, et à l’arbre de se terminer par une preuve Groth16 qu’Ethereum vérifie avec son précompilé de couplage.

Des circuits GKR en couches plutôt que des tables de contraintes engagées. Le circuit d’une famille est un empilement de couches de portes de degré 2 au-dessus de ses colonnes engagées. Seule la couche inférieure est engagée; chaque couche au-dessus est prouvée par sumcheck en une seule passe arrière, sans jamais être engagée. À la fin de la passe, chaque colonne engagée fait l’objet d’une affirmation en un même point : un shard a donc besoin d’exactement une ouverture. Le moteur GKR explique pourquoi c’est là l’économie centrale du moteur.

Une ouverture de taille constante. Mercury ouvre un engagement multilinéaire avec huit points de courbe et six éléments du corps, soit 704 octets, quelle que soit la taille du polynôme et quel que soit le nombre de colonnes qui partagent le point. Ses vérifications ont la forme e(A, [1]_2) = e(B, [x]_2), que la récursion peut replier au lieu d’effectuer le couplage.

Un seul argument de mémoire pour toute l’exécution. Chaque accès, dans chaque shard de chaque famille, est un tuple d’un même multiensemble lecture/écriture, et le vérificateur rapproche les produits une fois par énoncé. Le pc est une cellule de ce multiensemble : l’ordre, la continuité et l’unicité des cycles d’un shard à l’autre ne demandent donc aucun autre argument, et aucun shard n’a besoin de s’enchaîner à son voisin.

Des délégations sous forme de familles, et non d’instructions. Une fonction coûteuse dispose de sa propre famille de circuits, invoquée par un ecall sur un cadre de RAM et appariée une à une avec sa demande par le même multiensemble. Les circuits d’instructions restent petits, et un programme invité ne paie une délégation que s’il l’appelle.

Le flux plutôt que la matérialisation. À environ 300 octets par cycle, la trace serait le plus gros objet du système : elle n’existe donc jamais. Le prouveur exécute deux fois et ne détient que les shards en cours de traitement.

Aucune cryptographie empruntée. Les corps, la courbe, le couplage, la MSM, le hachage, l’engagement polynomial, GKR et Groth16 sont implémentés dans le dépôt et spécifiés page par page. arkworks, Plonky3 et zkhash n’apparaissent que comme oracles de test.

Comment la solidité (soundness) se compose#

La passe GKR et l’ouverture de chaque shard rattachent les sorties de son circuit à des colonnes engagées. Par-dessus, les arguments suivants couvrent toute l’exécution :

Les défis proviennent d’une transcription duplex Poseidon2. La transcription globale absorbe l’énoncé entier, engagements mémoire de chaque shard compris, avant que les défis mémoire n’existent; la transcription de chaque shard est amorcée à partir de son état final. La carte de solidité mène chaque ligne du tableau jusqu’aux sections qui la prouvent.

Le code, couche par couche#

Le vérificateur est la seule partie de confiance : le prouveur ne valide rien, et une entrée erronée coûte à un prouveur honnête une preuve qui échoue. Le modèle de sécurité énumère précisément les crates sur lesquelles repose la solidité.

Avant que quoi que ce soit ne s’exécute, Apogee transforme le binaire du programme invité en une description fixe du programme : son image, ses instructions réparties en familles de circuits, la configuration sous laquelle il sera prouvé, et un seul élément du corps qui engage le tout. Chaque étape est une fonction pure de son entrée.

Chargement#

Le chargeur accepte un exécutable RISC-V statique, 32 bits et petit-boutiste, dont les segments chargeables se trouvent dans la RAM du programme invité à des adresses paires, sont disjoints deux à deux et comprennent au moins un segment exécutable. Il lit le type, les décalages, les tailles et le bit d’exécution d’un en-tête de programme, et rien d’autre : la VM n’a ni pages ni permissions, et toute la RAM est adressable, quoi que déclarent les segments.

Il balaie ensuite chaque segment exécutable demi-mot par demi-mot. Un demi-mot qui se termine par 11 en binaire commence une instruction de 4 octets; le demi-mot nul est une non-instruction (LLVM en remplit les blocs inatteignables); tout le reste est une instruction compressée, développée sur place en sa forme de 32 bits. Les adresses ne sont jamais compactées : un c.addi à 0x1002 y reste et occupe deux octets, si bien que chaque adresse résolue par l’éditeur de liens reste valable, et que la longueur d’une instruction est la seule indication permettant de savoir si le pc suivant est pc + 2 ou pc + 4.

Un balayage désynchronisé ne peut pas rendre prouvable une instruction erronée. Un emplacement est une fonction des octets situés à son propre pc : chaque emplacement d’instruction est donc ce que décoderait un hart qui irait y chercher une instruction. Des données qui décalent le balayage par rapport aux vraies frontières ne peuvent que faire perdre de vrais débuts d’instruction, dont les pc n’ont alors aucune ligne de table, ou tomber sur un encodage non reconnu et faire refuser l’image entière.

Décodage et acheminement#

Le décodeur ne prend que des mots de 32 bits et accepte exactement les 59 instructions de RV32IMA : 40 du jeu de base, 8 de M, 11 de A. Tout le reste, des encodages RV64 et de la virgule flottante aux CSR et à fence.i, est une erreur de décodage, et un seul mot indécodable n’importe où dans le code exécutable entraîne le refus du programme, qu’il soit atteignable ou non. Chaque instruction est acheminée vers exactement une des sept familles d’instructions :

Le regroupement suit ce que partagent les circuits. Un seul gadget de comparaison tranche l’ordre signé et non signé pour chaque type de branchement et de slt; une seule identité de produit sert aux quatre multiplications et à la division; un décalage dans un sens ou dans l’autre est un seul produit avec une puissance de deux obtenue par lookup.

Tables décodées#

Chaque famille d’instructions reçoit une table décodée : ses colonnes de mise en place, où la ligne i correspond au pc 2i, avec une ligne par demi-mot de l’espace d’adressage qu’atteint la table. Une ligne active contient l’une des instructions de la famille sous la forme d’un tuple pc, next_pc, rs1, rs2, rd, imm, extra_mask, où le masque est un seul bit qui désigne le mnémonique. Toute autre ligne est du remplissage, −1 dans chaque champ : aucune ligne active n’est donc jamais la ligne de remplissage, et une ligne entièrement nulle ne peut jamais être revendiquée comme instruction au pc 0.

La ligne de chaque cycle se recherche elle-même dans la table de sa famille, par son pc. C’est ce lookup qui lie une exécution au programme : l’instruction d’une ligne est l’instruction du programme à ce pc, et un pc sans ligne active dans aucune table ne peut pas être exécuté de façon prouvable. Le code est par conséquent statique. Un rangement dans .text change ce que lit un chargement ultérieur, jamais ce qui s’exécute.

La configuration#

La forme statique d’un programme est sa VmConfig : les familles qu’il utilise, chacune avec une hauteur, et un plafond sur la taille de son code. L’ensemble des familles ne se choisit pas; il se dérive :

• une famille d’instructions est présente quand l’image contient l’une de ses instructions;
• les cinq familles de fenêtres, qui initialisent et finalisent la mémoire, sont toujours présentes;
• une famille de délégation est présente quand l’image la déclare, au moyen d’un enregistrement de 12 octets que l’édition de liens de son shim laisse parmi les octets de l’image.

La hauteur d’une famille est le nombre de lignes de l’un de ses shards, choisie parmi 2^8, 2^12, 2^16, 2^18, 2^20, 2^22. Chaque hauteur est une puissance paire de deux, parce qu’une ouverture Mercury l’exige. Les hauteurs sont un paramètre du programme, et non d’une exécution, et chaque choix de hauteurs constitue un programme distinct.

Identité du programme#

L’identité du programme est un élément de Fr : un condensé Poseidon2 de la version du code, de la VmConfig, du pc d’entrée et des engagements de mise en place de chaque famille, qui sont des engagements Mercury sur les tables décodées et sur les mots mémoire initiaux de l’image.

Elle lie chaque instruction qu’a trouvée le balayage, avec son pc, sa longueur, ses opérandes et son type, ainsi que le fait qu’aucun autre pc n’en contient; chaque octet de l’image issu du fichier, ce qui inclut les déclarations de délégation; le pc d’entrée; l’ensemble des familles, chaque hauteur, le plafond de taille du code et la version du code. Elle ne lie ni la cérémonie ni la table de lookup générique, que couvre le condensé SRS; ni les circuits, que le chargement d’une clé astreint au registre du vérificateur; ni rien de ce que choisit une exécution; ni rien de l’ELF que le chargeur ne lit pas, comme la table des symboles.

La calculer exige les puissances de la cérémonie, pour engager. La vérifier n’exige que les engagements, que porte une clé de vérification : le chargement d’une clé recalcule l’identité à partir d’eux, et l’ouverture de chaque shard vérifie ses colonnes de mise en place par rapport aux mêmes points. C’est ce qui rattache les tables que lit une preuve à l’identité qu’un vérificateur a enregistrée.

La spécification : Programme et identité.

La machine#

L’émulateur exécute RV32IMAC sur un seul hart à partir d’une ProgramImage, sans interruptions ni niveaux de privilège. Une exécution est une fonction pure de l’image et de son entrée, sans horloge, sans aléa ni fils d’exécution : deux exécutions découpent donc des shards identiques. Il diffère d’un RV32IMAC hébergé en trois points : sc.w réussit toujours, un accès non aligné à un demi-mot ou à un mot est fatal au lieu d’être scindé, et le flux d’instructions est l’image décodée au chargement.

Toute autre façon dont une exécution peut s’arrêter avant EXIT, comme un accès hors des régions projetées, ebreak ou un saut vers un demi-mot sans instruction, est une erreur fatale qui ne produit aucune trace. Une telle exécution n’a pas de preuve. Un statut de sortie non nul n’est pas une erreur : c’est une exécution comme une autre, et elle est prouvable.

L’horloge et la requête#

Le cycle c occupe les quatre horodatages 4c + Δ, un par créneau Δ ∈ {0, 1, 2, 3}. Chaque instruction est un cycle, et rien d’autre n’en est un : une invocation de délégation emprunte le cycle qui l’a demandée. Les cycles sont numérotés à partir de 1, parce que l’horodatage 0 est l’écriture initiale de chaque adresse. L’horloge fait 38 bits : une exécution compte donc au plus 2^36 − 1 cycles.

Chaque accès mémoire est une requête : la lecture d’une valeur écrite pour la dernière fois à un horodatage antérieur, et une écriture à l’horodatage courant. Une requête qui ne fait que lire réécrit ce qu’elle a lu. Le créneau 0 de chaque cycle est la requête du pc, qui lit pc et écrit next_pc. Viennent ensuite les requêtes de registres et de mémoire de l’instruction, à des créneaux fixes :

Les adresses résident dans des espaces : les 32 registres, la RAM par mots alignés sur 4 octets, le pc, un espace d’ancrage par type de délégation, et les cellules de corps du format de récursion. x0 est un registre ordinaire dans la trace et une constante dans la machine : chaque requête qui le vise lit et écrit 0.

Vingt-trois familles#

Une famille est un circuit et les lignes qu’il prouve. Il en existe quatre catégories :

Chaque cycle va à l’unique famille d’exécution dont la table décodée revendique son pc. Les familles s’entrelacent dans le temps : ADD_SUB_LUI_AUIPC peut posséder les cycles 1 et 3, et JUMP_BRANCH_SLT le cycle 2. Rien n’exige qu’elles soient contiguës, parce que l’argument de mémoire ordonne chaque ligne par son écriture du pc.

Les familles de fenêtres existent parce que l’argument de mémoire exige que chaque adresse que touche une exécution ait exactement une valeur initiale et une valeur finale. INIT_TEARDOWN couvre la fenêtre de RAM 0 et l’initialise avec l’image du programme; ZERO_WINDOWS couvre toutes les autres fenêtres de RAM ordinaire que l’exécution a touchées et les initialise à zéro; la paire publique couvre les fenêtres d’entrée et du journal; ADVICE_WINDOWS couvre la région des données auxiliaires (advice), qu’elle initialise avec les octets du prouveur.

Shards#

Les lignes d’une famille, dans leur ordre d’apparition, sont découpées en shards de la hauteur de la famille. Le dernier est complété par des lignes nulles, que les circuits sont construits pour accepter. Un shard coûte sa hauteur complète, quel que soit son taux d’occupation : les familles que touche un programme et les hauteurs qu’il choisit fixent donc le plancher de chaque preuve.

Un shard est prouvé isolément, par le circuit de sa famille, sauf pour l’argument de mémoire : le circuit de chaque shard produit en sortie le produit de ses tuples de lecture et celui de ses tuples d’écriture, et le vérificateur rapproche ces produits une seule fois sur l’ensemble des shards de l’énoncé. C’est la seule chose qui relie les shards. Il n’y a ni chaînage du pc d’un shard à l’autre, ni frontière partagée entre voisins.

Aux hauteurs par défaut, la taille d’une preuve de shard va d’environ 12,5 KB pour une fenêtre publique à 665 KB pour un shard POSEIDON2; celle d’une famille d’instructions va de 64 à 77 KB. La page Performances en donne le tableau.

La spécification : Trace d’exécution, Circuits et registre.

Chaque shard d’Apogee est prouvé de la même façon : par le circuit de sa famille, écrit sous forme d’empilement de couches, que le moteur GKR parcourt à rebours, des sorties du circuit jusqu’à ses colonnes engagées. Cette page explique pourquoi ce moteur occupe le centre du système, et pourquoi la famille de systèmes de preuve à laquelle il appartient est celle vers laquelle se déplace la frontière de la génération de preuves.

L’idée#

La façon classique de prouver un calcul consiste à le disposer sous forme de table, à engager chaque colonne, valeurs intermédiaires comprises, et à prouver qu’un ensemble de contraintes s’annule sur la table. Les engagements en sont la partie coûteuse : chaque colonne engagée coûte une multiplication multi-scalaire ou un arbre de Merkle, ainsi qu’une ouverture en chaque point qu’interroge l’argument de contraintes.

GKR, d’après Goldwasser, Kalai et Rothblum, change ce qui doit être engagé. Le calcul est un circuit en couches. Seule la couche inférieure, celle des entrées, est engagée. Chaque couche au-dessus est définie par des portes sur la couche du dessous, et le prouveur ne l’engage jamais. À la place, une affirmation sur la couche supérieure est ramenée par un sumcheck à une affirmation sur la couche située juste en dessous, puis à la suivante, jusqu’à ce que les affirmations aboutissent aux entrées engagées, toutes en un seul point aléatoire. Une seule ouverture les tranche toutes.

Ce que cela rapporte à une zkVM :

• Les valeurs intermédiaires ne coûtent aucun engagement. Un circuit de famille peut calculer des centaines de colonnes internes, des arbres de produits et des arbres de fractions, sans qu’aucun ne soit jamais engagé. Seules ses colonnes de trace le sont.
• Un seul point d’ouverture par shard. La passe arrière se termine avec une affirmation sur chaque colonne engagée, toutes au même point. Un shard a besoin d’exactement une ouverture groupée, de 704 octets, quel que soit son nombre de colonnes.
• Le travail du prouveur est de l’arithmétique de corps. Le sumcheck de chaque couche est linéaire en la taille de la couche, sur Fr, sans engagement, transformée ni hachage par couche.
• Les arguments se composent à l’intérieur du circuit. Les grands produits de l’argument de mémoire et les sommes LogUp des lookups ne sont que des couches supplémentaires du même circuit, réduites dans la même passe.

Un circuit de famille, couche par couche#

La couche inférieure est formée des colonnes engagées du shard, de trois sortes qui diffèrent par le moment où elles sont liées : M, les colonnes mémoire, engagées dans la transcription globale de l’énoncé avant qu’existe le moindre défi mémoire; W, les colonnes témoins, engagées dans la transcription propre au shard; et S, les colonnes de mise en place, liées par l’identité du programme ou par la cérémonie. À côté d’elles se trouvent les tables virtuelles : des formes closes comme l’indice de ligne ou l’intervalle de 16 bits, que le vérificateur évalue en n’importe quel point et qui ne sont jamais engagées.

Au-dessus de la couche 0, chaque circuit de famille a la même anatomie :

1. La liste de portes 0 calcule, ligne par ligne, les feuilles mémoire (les tuples de lecture et d’écriture de chaque requête), les fractions de lookup (une paire (numerator, denominator) par lookup, plus celle de la table), et chaque porte de contrainte : les contraintes de la famille, chacune étant un polynôme qui doit s’annuler sur chaque ligne.
2. Les listes ligne par ligne combinent les feuilles sœurs : un arbre de produits multiplie des tuples, un arbre de fractions additionne des fractions sous la forme (n_a·d_b + n_b·d_a, d_a·d_b), jusqu’à ce que chaque ligne ne contienne plus qu’un nœud par arbre.
3. Les listes à réduction de moitié, une par variable de la hauteur du shard, combinent les lignes deux à deux : la première moitié avec la seconde. Après n d’entre elles, le circuit atteint un sommet sans variables : la racine de lecture du shard, sa racine d’écriture, et le numérateur et le dénominateur finaux de chaque canal de lookup.

Un seul circuit prouve donc les contraintes de la famille, calcule sa contribution à l’argument de mémoire et somme ses lookups, en une seule passe. Chaque porte est de degré au plus 2 : chaque polynôme de tour de chaque sumcheck est donc cubique.

La passe arrière#

Le prouveur matérialise chaque couche une fois, en montant. La preuve descend ensuite, et l’ordonnancement de sa transcription est le même pour chaque circuit :

1. Les sorties sont absorbées en premier : le prouveur est ainsi engagé sur les racines avant qu’existe le moindre défi.
2. Pour chaque transition de la couche k + 1 vers la couche k, un défi λ regroupe en une seule somme chaque affirmation sur la couche k + 1, ainsi que chaque porte de contrainte de la liste. Un sumcheck ramène cette somme à une évaluation en un point aléatoire ρ, à raison d’un message cubique par variable.
3. Le prouveur annonce les valeurs des colonnes de la couche k en ρ. Pour une liste à réduction de moitié, il annonce les deux enfants, et un défi supplémentaire τ les fusionne en une seule affirmation par colonne.
4. À la couche 0, chaque colonne engagée fait l’objet d’une seule affirmation, toutes au même point u.

L’unique ouverture Mercury du shard prouve ces affirmations par rapport aux engagements : ceux des colonnes mémoire, tirés de l’énoncé; ceux des colonnes témoins, tirés de la preuve du shard; ceux des colonnes de mise en place, tirés de la clé de vérification. Les tables virtuelles sont évaluées par le vérificateur lui-même.

Les portes de contrainte voyagent sans frais. Une porte de contrainte affirme 0 partout : elle rejoint donc le lot de la transition où elle se trouve, et une porte violée rend la somme groupée non nulle avec une probabilité écrasante. Une seule erreur LayerInconsistency couvre aussi bien une affirmation descendante erronée qu’une porte violée; une somme groupée ne peut pas les distinguer, et la preuve ne dépense rien pour les distinguer.

Pourquoi c’est solide#

Chaque défi est tiré après tout ce qu’il protège :

• le point de sortie après les sorties, si bien qu’un prouveur ne peut pas choisir des tables qui ne concordent avec la vérité que là où elles seront vérifiées;
• λ après les affirmations et le point, si bien qu’une affirmation fausse ou une porte violée ne survit qu’en une racine d’un polynôme non nul en λ;
• chaque défi du sumcheck après la cubique de son tour, si bien qu’une cubique erronée concorde avec la vraie avec une probabilité d’au plus 3/|Fr|;
• τ après les valeurs des deux enfants.

Sommée sur chaque transition d’un circuit enregistré à sa hauteur par défaut, l’erreur de solidité (soundness) reste inférieure à 2^14/|Fr|, avec Fiat–Shamir sur la transcription Poseidon2 dans le modèle de l’oracle aléatoire.

Les circuits sous forme de données#

Un circuit n’est pas du code. C’est un CircuitArtifact : ses colonnes engagées, par nom, ses tables virtuelles, ses listes de portes avec sept formes de portes, une liste plate des mêmes relations, ses lookups et sa ligne de remplissage, le tout sérialisé de façon canonique. Quatre lois astreignent chaque artefact à une forme cohérente : chaque opérande est lisible là où il est lu, la largeur de chaque liste est dérivée de ses portes, la couche supérieure correspond exactement aux sorties, et les portes en couches et les relations plates forment un seul ensemble de contraintes. Elles sont vérifiées une seule fois, là où un artefact est construit ou une clé chargée, jamais à chaque preuve.

Deux conséquences comptent pour quiconque évalue le système :

• Une clé de vérification porte ses circuits, et le vérificateur les astreint à son propre registre. L’identité du programme lie le programme; le registre lie les circuits qui le prouvent.
• Les circuits peuvent être vérifiés par une seconde implémentation. La crate checker réimplémente les lois, les règles de lookup et le contrat de remplissage sans partager le code des constructeurs, et n’évalue les portes qu’au moyen du seul noyau de portes que les deux côtés tiennent pour l’autorité sémantique.

Le coût#

Le moteur échange des engagements contre de la mémoire. La passe avant détient chaque couche interne sous forme d’éléments du corps : environ 8,4 GiB pour un shard 2^20 de la famille d’instructions la plus large, et 42 GiB pour un shard KECCAK_F de 2^18, dont le circuit calcule 5 490 colonnes internes. C’est pourquoi la génération de preuves est limitée par la mémoire, pourquoi les hauteurs sont un paramètre de réglage, et pourquoi le prouveur en flux borne la mémoire par les shards en cours de traitement. La taille de la preuve ne croît que d’un tour de sumcheck par variable et par couche : la preuve d’un shard KECCAK_F fait 381 100 octets à 2^18, contre 373 276 à 2^16, pour quatre fois plus de travail.

La spécification : Le moteur GKR, et la page propre à chaque famille sous Auditeurs.

Chaque colonne qu’engage Apogee est un polynôme multilinéaire, une table de 2^n évaluations sur l’hypercube booléen. Chacune est engagée et ouverte avec Mercury (Eagen et Gabizon, ePrint 2025/385), complété par l’ouverture KZG groupée de BDFG20 (Boneh, Drake, Fisch et Gabizon, ePrint 2020/081). La spécification fixe ce que les articles laissent ouvert et ajoute deux choses : un lot de nombreuses colonnes en un même point, et une forme différée que replie l’arbre de récursion.

L’engagement#

Un engagement Mercury est exactement l’engagement KZG de la table d’évaluations lue comme une suite de coefficients : une seule multiplication multi-scalaire sur les n premières puissances du τ de la cérémonie, un seul point de G1, 64 octets. Il n’y a aucun second schéma derrière. Il en découle deux propriétés, et le reste du système utilise l’une et l’autre :

• Il est linéaire. L’engagement de Σ ρ^i·f_i est Σ ρ^i·cm_i, ce qui permet à de nombreuses colonnes de partager une seule ouverture.
• Les coefficients nuls n’ajoutent rien. Une colonne prolongée par des lignes nulles conserve son engagement : les trois engagements de la table de lookup générique servent donc à toute hauteur qui contient la table, et ce sont des constantes de la cérémonie.

Les colonnes sont engagées à leur largeur entière : une colonne de bits, d’octets, de demi-mots ou de mots passe par une MSM sur des scalaires u32, recodés à partir de 32 bits au lieu de 254, ce qui garde peu coûteux l’engagement d’une trace.

L’ouverture#

Mercury scinde en deux moitiés un point d’ouverture u de s = 2t variables, replie le polynôme par un défi α, et prouve les deux produits scalaires qui restent avec un témoin symétrisé, pour finir par une seule ouverture KZG groupée en trois points. La preuve compte huit points de G1 et six éléments du corps : 704 octets, pour toute taille. D’où une exigence : le nombre de variables doit être pair, et c’est pourquoi chaque hauteur au menu est une puissance paire de deux.

Le vérificateur effectue O(t) opérations sur le corps, des MSM de dix et de deux points, et une seule vérification de couplage à deux paires. Les deux relations qu’il vérifie s’écrivent e(A, [1]_2) = e(B, [x]_2) : les deux arguments de G2 sont donc des constantes de la mise en place, et le vérificateur n’effectue aucune arithmétique dans G2. C’est aussi cette forme qui permet à la récursion de différer le couplage au lieu de le calculer.

Les colonnes d’un shard, une seule ouverture#

La passe GKR se termine avec une affirmation sur chaque colonne engagée d’un shard, toutes au même point u. Aucun sumcheck de fusion des affirmations n’est donc nécessaire : l’ouverture les regroupe toutes. Un défi ρ, tiré après chaque engagement et chaque valeur annoncée, pondère la colonne i par ρ^i; le prouveur ouvre Σ ρ^i·f_i une seule fois, et le vérificateur forme Σ ρ^i·cm_i par une MSM à k points. Une affirmation fausse survit avec une probabilité d’au plus (k − 1)/|Fr|.

Les colonnes du lot proviennent de trois endroits, dans un ordre fixe qui fait partie de ce qui est prouvé : les engagements des colonnes mémoire, tirés de l’énoncé; ceux des colonnes témoins, tirés de la preuve du shard; et ceux des colonnes de mise en place, tirés de la clé de vérification. C’est le fait de prendre les engagements de mise en place dans la clé qui fait que l’ouverture lie les tables décodées et l’image qu’engage l’identité du programme.

Vérification différée#

Une vérification différée exécute tout sauf le couplage, et conserve les termes de la relation sous forme de douze entrées (side, scalar, point). La récursion utilise exactement cela : chaque nœud de l’arbre calcule les douze scalaires d’un shard dans sa propre arithmétique, les pondère par de nouveaux défis et les ajoute à une seule paire de points cumulative (A, B). L’ouverture de chaque shard de l’arbre entier se replie en une seule affirmation e(A, [1]_2) = e(B, [x]_2), que seul le contrat sur Ethereum vérifie en fin de compte. Récursion et règlement montre le repliement.

Mesures#

Sur un Apple M5 Pro à 18 cœurs :

Sécurité#

La solidité de connaissance (knowledge soundness) tient dans le modèle du groupe algébrique sous q-DLOG, avec Fiat–Shamir sur la transcription Poseidon2 dans le modèle de l’oracle aléatoire, et une SRS dont personne ne connaît le τ. Les termes statistiques, Schwartz–Zippel sur les défis, restent inférieurs à 2^−220 pour chaque instance utilisée : le niveau de sécurité est donc celui de BN254, environ 100 bits. Rien n’est masquant (hiding) et rien n’est aveuglé : Apogee v1.0.0 n’est pas à divulgation nulle de connaissance.

La SRS est celle des puissances de tau perpétuelles de PSE, contribution 80, solide tant qu’un seul contributeur a été honnête. Son fichier est décodé, et l’on vérifie que chaque point se trouve sur sa courbe et dans le bon sous-groupe; rien ne prouve qu’un fichier est bien celui de cette cérémonie, et c’est pourquoi un vérificateur compare le condensé SRS à celui de la cérémonie, obtenu par son propre canal.

La spécification : Mercury, La chaîne de référence structurée.

Les portes d’une famille contraignent une ligne à la fois. Tout ce qui traverse les lignes, les shards ou les familles, comme ce que contient un registre, ce que renvoie un chargement, l’instruction qu’exécute une ligne ou le fait qu’une valeur tienne sur 32 bits, est porté par deux arguments qui résident dans les mêmes circuits GKR.

L’argument de mémoire#

Chaque accès mémoire devient un élément du corps, un tuple :

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

sur l’espace d’adressage, l’adresse, l’horodatage et la valeur, avec quatre défis tirés une fois par énoncé. Une requête apporte son tuple de lecture à un côté et son tuple d’écriture à l’autre. Le circuit de chaque shard produit en sortie deux nombres, le produit de ses tuples de lecture et le produit de ses tuples d’écriture. Le vérificateur vérifie ensuite une seule équation sur l’énoncé entier :

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

W_b et R_b sont les tuples initiaux et finaux des 32 registres et du pc, qui n’ont pas de lignes propres : le vérificateur les intègre aux produits à partir de 64 scalaires de frontière que porte l’énoncé. La RAM reçoit ses valeurs initiales et finales des shards des familles de fenêtres, qui contiennent un mot par ligne : l’image du programme dans la fenêtre 0, des zéros dans chaque autre fenêtre que l’exécution a touchée, l’entrée de l’énoncé dans la fenêtre de l’entrée publique, les octets du prouveur dans les données auxiliaires (advice).

Si l’équation tient, les multiensembles sont égaux avec une probabilité écrasante. Des multiensembles égaux signifient que chaque lecture renvoie la dernière écriture qui la précède : chaque lecture est appariée à exactement une écriture, une lecture doit suivre strictement l’écriture qu’elle consomme, et chaque adresse a exactement une écriture initiale.

L’ordre sans frais#

Le pc est une cellule mémoire comme une autre, à l’adresse 0 de son propre espace. Chaque ligne lit le pc et écrit le suivant, et son circuit astreint l’écriture à se situer au moins quatre horodatages après la lecture. L’historique du pc est donc un seul chemin qui passe par chaque ligne active de chaque famille, du point d’entrée jusqu’à la ligne de sortie. Ce chemin unique donne :

• l’ordre du programme, puisque les lignes sont ordonnées par leurs écritures du pc;
• la continuité d’un shard et d’une famille à l’autre, puisque la lecture du pc de chaque ligne consomme l’écriture du pc d’une ligne;
• aucun cycle prouvé deux fois, puisqu’aucune écriture ne peut être consommée deux fois.

Aucun shard ne s’enchaîne à son voisin, et aucun n’en a besoin. La fenêtre temporelle annoncée d’un shard ne lie rien; seule sa forme est vérifiée.

Ce qui doit venir en premier#

Les défis mémoire sont tirés une fois par énoncé, à la fin de la transcription globale, après que tout ce qu’un tuple peut lire a été fixé : les engagements mémoire de chaque shard, l’identité du programme (qui fixe le pc d’entrée et l’image), le condensé de la cérémonie, les nombres de shards et la liste des fenêtres, le condensé de l’entrée publique et du journal, et en dernier les 64 scalaires de frontière. Une valeur choisie après les défis pourrait être obtenue par résolution; c’est l’ordre de la transcription qui l’interdit. Pour la même raison, un tuple mémoire ne peut lire que des colonnes mémoire, de mise en place et virtuelles, jamais une colonne témoin, laquelle est engagée dans la transcription propre au shard, après les défis. Les constructeurs de circuits refusent tout artefact qui enfreint cette règle.

Lookups#

Un lookup affirme qu’un tuple de valeurs d’une ligne est une ligne d’une certaine table. Apogee prouve chaque lookup d’un shard avec LogUp : une identité par table, ou canal,

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

sommée par un arbre de fractions à l’intérieur du circuit GKR propre à la famille et vérifiée à sa racine : numérateur nul, dénominateur non nul. La colonne des multiplicités n’a besoin d’aucune contrainte : un tuple qui ne figure dans aucune ligne de table laisse un pôle que les multiplicités ne peuvent pas annuler.

Trois des tables sont virtuelles : des formes closes de l’indice de ligne que le vérificateur évalue lui-même, et qui ne coûtent aucun engagement. La table générique est engagée une seule fois au moyen des puissances de la cérémonie et couverte par le condensé SRS.

Le lookup du décodeur#

Chaque famille d’exécution effectue un lookup par ligne active dans sa propre table décodée, indexé par le pc que la ligne a lu en mémoire. Ce seul lookup lie le cycle au programme : les opérandes, l’immédiat et le type d’instruction de la ligne sont ceux du programme à ce pc, et ses bits de type sont one-hot, parce que chaque ligne active de la table contient un masque one-hot et chaque ligne de remplissage contient −1, qu’aucune somme de bits de type n’atteint. Une ligne à un pc où le programme n’a pas d’instruction ne trouve aucune ligne de table.

Les clés doivent être bornées#

Un canal prouve l’appartenance à une table, et rien de plus. Plusieurs sous-tables partagent la table générique sous des plages de clés disjointes : une clé non bornée pourrait donc tomber dans la mauvaise sous-table et prouver un AND faux. Chaque famille borne par conséquent chaque clé qu’elle recherche, au moyen d’un lookup d’intervalle sous le même sélecteur, et les constructeurs de circuits vérifient qu’une borne écrite au moyen d’un facteur d’échelle porte aussi une borne directe. La spécification énonce, pour chaque famille, l’attaque que cela empêche.

Comment le tout se compose#

Avec les portes de chaque famille, ces deux arguments donnent son sens à l’énoncé : chaque ligne obéit à son instruction, l’instruction est celle du programme, chaque lecture voit la dernière écriture, les lignes forment un seul chemin de l’entrée à la sortie, chaque valeur est l’entier qu’elle prétend être, et les fenêtres publiques contiennent les octets de l’énoncé. La carte de solidité mène chaque affirmation jusqu’aux sections qui la prouvent.

La spécification : L’argument de mémoire, Lookups.

Le hachage et l’arithmétique des grands entiers dominent les charges de travail réelles : dans un bloc Ethereum du réseau principal, la multiplication et l’élévation au carré dans le corps de secp256k1 représentaient à elles seules 44 % des cycles avant d’être déléguées. Les prouver instruction par instruction est possible, et lent. Une délégation donne à une telle fonction une famille de circuits qui lui est propre, invoquée depuis le programme invité : les circuits d’instructions restent ainsi petits, et un programme ne paie que les délégations qu’il appelle.

L’appel#

Une délégation est invoquée, jamais décodée. Le programme invité écrit en RAM un cadre de mots de 32 bits et émet un ecall avec le numéro de la délégation dans a7 et l’adresse de base du cadre dans a0. L’ecall est une ligne de la famille ADD_SUB_LUI_AUIPC, la demande. Le travail est une ligne de la famille propre à la délégation, l’invocation, qui lit chaque mot du cadre et réécrit chaque mot du cadre, résultats compris, au cycle de la demande. Une invocation ne possède aucun cycle; elle emprunte celui qui l’a demandée.

Les cadres sont alignés sur des mots et se trouvent entièrement en RAM ordinaire : aucun cadre ne chevauche donc une fenêtre publique ni les données auxiliaires (advice), et les lectures et écritures du cadre sont des requêtes mémoire ordinaires. Ce qu’a calculé une délégation est par conséquent lié exactement comme l’est tout rangement : par l’unique multiensemble mémoire.

L’ancre#

Demandes et invocations doivent s’apparier une à une : sinon, plusieurs demandes pourraient se refermer sur une seule invocation et laisser des appels non exécutés, ou une invocation non demandée pourrait réécrire un cadre. Elles s’apparient par le même multiensemble mémoire, dans un espace d’ancrage qui n’appartient qu’au type de délégation et qu’aucune instruction ne peut atteindre :

Trois portes du côté de la demande fixent sa lecture à l’horodatage 0 et à la valeur 0, et lui font écrire 0 dans a0. Les tuples horodatés 0 sont alors exactement les lectures des demandes et les réponses des invocations : il y a donc autant d’invocations que de demandes, sur les mêmes bases; et puisque deux demandes ne partagent jamais un cycle, la lecture de chaque invocation est exactement l’écriture d’une seule demande. Chaque invocation se situe à la base et au cycle de sa demande. Aucune porte d’un circuit de délégation n’a eu à connaître quoi que ce soit des demandes.

Plusieurs appels, une seule opération#

Une opération trop large pour une seule ligne correspond à plusieurs invocations sur un même cadre, un mot du cadre désignant l’étape : une permutation keccak-f[1600] représente 24 appels de tour, une compression SHA-256 16 appels de quatre tours, une addition complète de points trois appels. Aucune porte ne relie deux lignes. Chaque appel prouve son étape sur le cadre tel qu’il le trouve, ses lectures se situant sur l’historique mémoire unique de chaque mot : il lit donc les écritures de l’étape précédente. C’est au code appelant de garantir que chaque étape s’exécute, dans l’ordre, et ce code appelant est du code de programme invité, prouvé sous forme d’instructions. Le SDK émet chaque opération en plusieurs appels à partir d’une seule fonction : un programme invité n’ordonne donc jamais les étapes à la main.

Déclarées statiquement#

Le balayage des instructions ne peut pas voir un appel, parce que le numéro est une valeur de a7 connue à l’exécution. Chaque shim du SDK laisse donc un enregistrement de déclaration de 12 octets dans sa propre section d’édition de liens, conservée seulement si le shim est atteignable. La dérivation du programme recherche ces enregistrements dans l’image, et une famille déclarée rejoint la configuration, liée par l’identité à travers les octets de l’image. Une famille liée mais jamais appelée prouve zéro shard; un numéro appelé dont le programme n’a jamais déclaré la famille n’a pas de preuve.

Les six circuits#

Quelques constructions reviennent d’un circuit à l’autre. Une règle du code unique décode un mot du cadre qui désigne l’un de k cas en sélecteurs booléens dont exactement un est activé, parce que les codes s’additionnent : sans elle, les sélecteurs 1 et 3 répondent à une demande de 4. Une chaîne de canonicité prouve qu’une valeur de 256 bits est inférieure à un module au moyen d’emprunts sur des limbs de 32 bits. Enfin, chaque mot écrit est borné sous 2^32, pour que la RAM reste faite de mots, ce sur quoi s’appuie chaque famille d’instructions.

Aspects économiques#

La hauteur d’une famille de délégation fixe le nombre d’appels que contient un shard, et un shard coûte sa hauteur quel que soit son taux d’occupation :

Pour une famille souvent appelée, c’est le shard le plus gros qui revient le moins cher : une preuve KECCAK_F grossit à peine de 2^16 à 2^18. Le prix se paie en mémoire. La passe avant d’un shard KECCAK_F de 2^18 occupe 42 GiB, et deux de ces shards en cours de traitement ont fixé le pic du bloc mesuré.

Ce qui est délégué, et ce qui ne l’est pas#

Le code des bibliothèques atteint les délégations par des copies corrigées de k256, ark-ff et revm-precompile : la récupération de clé secp256k1 devient du code k256 sur MOD_MUL et EC_ADD, et un couplage BN254 devient du code ark-bn254 sur MOD_MUL. Le MULMOD de l’EVM avec un module arbitraire, MODEXP, BLS12-381 et tout schéma de signature complet s’exécutent sous forme d’instructions. La prise en charge dédiée des signatures pour les programmes invités fait partie de la trajectoire de la v2.0.0.

La spécification : ABI de délégation, Circuits de délégation.

Un bloc Ethereum complet représente environ 200 millions de cycles. Sa trace, c’est-à-dire chaque ligne de chaque famille et chaque événement mémoire, occuperait environ 300 octets par cycle : des dizaines de gigaoctets avant même qu’une seule colonne soit engagée. Le prouveur d’Apogee ne la construit jamais. Il exécute le programme invité deux fois et ne détient que les shards sur lesquels il travaille.

Deux passes#

La passe 1 exécute le programme invité et, à mesure que chaque shard se remplit, engage ses colonnes mémoire, conserve les engagements et abandonne les lignes. À la sortie, elle dérive de l’état final de la mémoire tout le reste dont l’énoncé a besoin : la frontière des registres et du pc, la liste des fenêtres mémoire que l’exécution a touchées, et les shards des familles de fenêtres. Elle exécute ensuite la transcription globale, qui absorbe l’énoncé, chaque engagement mémoire compris, et tire les défis mémoire ainsi que le condensé à partir duquel chaque shard est amorcé.

La passe 2 exécute de nouveau. L’émulateur est une fonction pure de son entrée : il découpe donc les mêmes shards, et la passe 2 vérifie par assertion que son profil de cycles, sa liste de fenêtres et sa frontière sont ceux de la passe 1. Chaque shard reçoit chacune de ses colonnes engagées et est prouvé : sa transcription, sa passe GKR, son ouverture. Les colonnes mémoire ne sont pas engagées de nouveau : l’ouverture prend leurs engagements dans l’énoncé et leurs valeurs dans la passe 2, si bien que des colonnes qui différeraient d’une passe à l’autre donneraient une ouverture que le vérificateur refuse.

L’ordre est imposé par la solidité (soundness). Les défis mémoire doivent suivre chaque valeur que peut lire un tuple mémoire : les colonnes mémoire de chaque shard sont donc engagées avant qu’un shard quelconque puisse être prouvé.

Le pipeline#

Un nombre fixe de fils de travail, max_in_flight, partagent un seul verrou autour de l’exécuteur. Sous le verrou, un fil de travail rend son shard terminé et réclame le suivant : un shard rempli s’il y en a un en attente, sinon il fait lui-même avancer l’exécuteur jusqu’à ce qu’un tampon se remplisse. Hors du verrou, il construit les colonnes du shard, le prouve et l’abandonne.

• L’exécuteur ne devance jamais la demande. Au plus un shard rempli et non réclamé par famille attend, sous forme de lignes.
• Au sein d’un shard, le travail est parallèle sur les données, sur tous les cœurs. Un fil de travail bloqué dans ce travail ne prend pas de second shard.
• Le bloc ne dépend pas de l’ordonnancement. La preuve d’un shard est une fonction de l’état global et de ses propres colonnes; les preuves sont placées selon leur position dans l’énoncé. Les octets sont identiques avec 1 et avec 8 shards en cours de traitement.
• Les échecs sont déterministes. L’échec renvoyé est le premier dans l’ordre de remplissage, quel que soit le nombre de fils de travail.

Ce que cela coûte#

La mémoire se compose d’un tampon partiel par famille, des tables des derniers accès, des shards en cours de traitement et de la sortie. L’ensemble de travail d’un shard est dominé par sa passe avant, chaque couche GKR interne sous forme d’éléments du corps : 8,4 GiB pour un shard SHIFT_BITWISE de 2^20, 42 GiB pour un shard KECCAK_F de 2^18. Ainsi, max_in_flight borne le nombre de ces ensembles qui coexistent, et les hauteurs fixent la taille de chacun.

Mesures sur le bloc 257 510 (60 transactions, 101,5 Mgas, 198 millions de cycles, 207 shards) avec 32 vCPU et 247,7 GiB, et douze shards en cours de traitement :

Le pic est venu de la hauteur d’une seule famille de délégation, et non des douze shards en cours de traitement. C’est là le levier : un bloc avec moins d’appels Keccak, ou avec Keccak à une hauteur inférieure, culmine plus bas.

La spécification : Le prouveur en flux.

La preuve de base d’un bloc Ethereum se compose de 207 preuves de shards : 14,5 MB, chaque shard étant une preuve GKR accompagnée de ses engagements et d’une ouverture Mercury qui se termine par une vérification de couplage. Un contrat ne peut rien vérifier de tout cela directement. La récursion la compresse, et la façon dont elle le fait est le choix de conception le plus lourd de conséquences après le moteur GKR lui-même.

La preuve de base reste intacte#

La première décision porte sur ce que la récursion ne fait pas. Aucune clé, aucun énoncé ni aucune preuve de base ne change pour rendre la récursion possible : une feuille vérifie les shards de base exactement comme le ferait un vérificateur natif. Tout ce dont la récursion a besoin est ajouté au-dessus de la preuve de base, jamais à l’intérieur. Un bloc peut être vérifié en natif, passé par la récursion, ou les deux, à partir des mêmes octets.

Apogee prouve son propre vérificateur#

Un nœud de l’arbre, c’est Apogee qui prouve un programme vérificateur. Une feuille vérifie une suite de shards de base consécutifs, de from à to; un nœud interne vérifie de deux à quatre enfants, chacun étant une preuve complète d’un programme feuille ou nœud; la racine couvre tous les shards de base. Chaque nœud est prouvé par le même prouveur en flux qu’un bloc de base.

Exécuter le vérificateur Rust sous forme d’instructions RISC-V fonctionnerait, et la mesure a donné 3,0 milliards de cycles pour les 207 shards d’un bloc : quinze fois le bloc lui-même. Les nœuds s’exécutent donc plutôt dans un format de récursion.

Le format de récursion#

Un énoncé est au format de récursion exactement quand son programme déclare des familles de corps. Le format ajoute un espace d’adressage et quatre familles de coprocesseurs qui opèrent sur cet espace, toutes invoquées par l’ABI de délégation ordinaire, et ne change rien d’autre :

Deux autres changements rendent un shard de récursion moins coûteux à vérifier pour son parent. Ses colonnes mémoire et témoins sont engagées sous forme d’empilements d’au plus 2^24 évaluations : un parent replie donc une poignée de points au lieu de centaines. Et une demande de récursion écrit la base de son cadre avancée au-delà du cadre, si bien que des cadres placés bout à bout se rejouent sous forme d’ecall consécutifs, à raison d’une ligne par appel.

Bandes#

Les vérifications d’un shard ont une forme fixe pour sa famille et sa hauteur. L’hôte les compile donc, une fois pour toutes, en une bande : une liste séquentielle d’appels de coprocesseur sur des cellules absolues, dans laquelle rien ne bifurque selon une valeur. La bande d’un shard reprend, appel pour appel, les étapes du vérificateur natif pour ce shard : la transcription du shard, la passe arrière GKR, les vérifications de lookup et de racines, et les douze scalaires de l’ouverture Mercury. Chaque vérification est une assertion d’égalité.

Les bandes, les gabarits de repliement et les constantes de chaque programme de récursion sont construits à la compilation par la crate du vérificateur elle-même, et placés dans les données en lecture seule du programme. L’identité du programme lie donc chaque bande que le programme rejoue : prouver qu’un nœud a exécuté son programme, c’est prouver qu’il a exécuté exactement ces vérifications.

Une transcription chaînée à travers l’arbre#

La transcription globale de l’énoncé de base est une seule éponge sur l’énoncé entier. L’arbre la découpe sans la modifier. Le nœud qui détient le shard 0 exécute le préfixe, jusqu’au condensé de l’entrée publique inclus; chaque nœud absorbe les engagements mémoire de ses propres shards, en repartant de l’état qu’a laissé son prédécesseur; le nœud qui détient le dernier shard exécute le suffixe et tire les défis mémoire que chaque nœud avait pris comme affirmations. Le journal d’un nœud enregistre l’état de la chaîne aux deux extrémités de sa plage, et un parent exige que les états de ses enfants se rejoignent.

Un nœud astreint aussi ses enfants les uns par rapport aux autres : statut de sortie 0, un seul énoncé de base (sa forme, son condensé, ses défis, le condensé de l’entrée et du journal, le statut de sortie et le nombre de shards), des plages de shards adjacentes, des états de chaîne qui se rejoignent, des fenêtres temporelles dans l’ordre de part et d’autre de la jointure, et les identités des programmes de récursion. Un nœud qui détient un énoncé entier établit l’argument de mémoire.

Replier les couplages#

Aucun nœud ne calcule de couplage. La vérification Mercury de chaque shard est différée sous forme de douze entrées (side, scalar, point); après la bande du shard, la transcription propre au nœud absorbe l’état final de la transcription du shard et tire des poids, et chaque entrée est ajoutée, pondérée, à une seule paire de points cumulative (A, B) qui représente l’affirmation e(A, [1]_2) = e(B, [x]_2). La vérification de lot qui rattache l’engagement combiné d’un shard à ses colonnes est repliée à côté. Les points que partagent tous les shards d’une famille, comme [1]_1 et les engagements de mise en place, accumulent chacun un seul scalaire et n’entrent qu’une fois. Le (A, B) d’un enfant entre sous un poids tiré après son journal entier.

Chaque côté est une seule multiplication multi-scalaire sur FQ_OP, exécutée selon un gabarit statique : Pippenger avec des chiffres de 8 bits sur des moitiés GLV, chaque point étant astreint à la courbe, chaque étape fixée à l’avance. Un point coûte environ 400 appels FQ_OP.

À la racine, le contenu entier de l’arbre s’est contracté : chaque shard de base vérifié, la transcription exécutée de bout en bout, l’argument de mémoire établi, et chaque ouverture repliée en une seule affirmation de couplage. Il reste cette affirmation et deux identités de programme.

Le décideur#

La racine reste une preuve GKR accompagnée de quelques centaines de points, ce qu’un contrat ne peut pas vérifier. Le décideur est un circuit Groth16 qui exécute la procédure de nœud sur un seul enfant, la racine, au moyen d’un pilote écrivant des contraintes de rang 1 au lieu d’appels de coprocesseur, et qui astreint le journal de la racine à toute la plage des shards de base. Il ne replie rien : chaque point que la racine doit au couplage final, avec son scalaire, devient un fil lié, une valeur que détient le vérificateur, engagée dans la preuve sous une cinquième trappe plutôt que passée comme entrée publique. Il en va de même des deux identités, du statut de sortie de base, ainsi que de l’entrée publique et du journal de base, octet par octet.

Le Groth16 d’Apogee diffère de celui des manuels sur trois points : l’engagement des fils liés, l’absence d’aveuglement, et une clé de preuve sur la base de Lagrange que publie déjà la cérémonie des puissances de tau. Sa clé provient d’une cérémonie en deux phases : la phase 1 est le même fichier de cérémonie que celui sur lequel reposent les engagements; la phase 2 est propre au circuit, les contributions à α et à β étant achevées avant toute contribution à γ, δ et η, un ordre qui fait lui-même partie de la solidité (soundness).

ApogeeVerifier.sol reconstruit les valeurs liées à partir du calldata, vérifie l’équation de Groth16, replie les points des deux côtés avec ecMul et ecAdd, ce qui astreint aussi chaque point à la courbe, et vérifie l’unique couplage restant. Son constructeur fixe la clé, les deux points G2 de la cérémonie et les identités des deux programmes de récursion. Un déploiement sert un seul programme de base, une seule forme de racine et des longueurs de valeurs publiques fixes.

Mesures#

Bloc 257 510, avec l’arbre sur une machine à 32 CPU, et la cérémonie et le décideur sur un portable à 18 cœurs :

La spécification : Récursion et décideur. Pour l’exécuter vous-même : Régler sur la chaîne.

Apogee prouve des programmes RV32IMAC arbitraires. Sa charge de travail de référence, celle sur laquelle portent ses mesures et ses réglages, est la plus difficile des charges courantes : valider un bloc Ethereum à l’intérieur de la VM avec revm, l’EVM en Rust. Une seule bibliothèque, revm_block, se compile à la fois pour le programme invité et pour l’hôte, et deux binaires prouvent deux énoncés différents.

Deux binaires, deux énoncés#

Le validateur sans état est celui qui prouve des blocs. Il implémente verify_stateless_new_payload des spécifications d’exécution d’Ethereum : il décode la requête, vérifie les en-têtes des ancêtres et les règles d’en-tête par rapport au parent, récupère chaque expéditeur, exécute chaque transaction sur un état antérieur rattaché à la racine d’état du parent par des hachages, applique les retraits et les requêtes, et recalcule la racine des reçus, le filtre de Bloom, le gas, le hachage des requêtes, la liste d’accès du bloc et la racine de l’état postérieur. Le témoin n’a besoin d’aucune liaison propre : la racine publiée fixe la charge utile, et le témoin y est rattaché par des hachages, si bien qu’un mauvais témoin ne peut pas rendre valide une charge utile invalide. Un verdict false signifie seulement que cette entrée n’a pas passé la validation.

Forks et conformité#

Le validateur désigne le fork par l’identifiant de schéma de l’entrée, sans calendrier d’activation compilé : Osaka, BPO1, BPO2 et Amsterdam. Les 67 251 paires de la version v21.0.1 de tests-zkevm concordent toutes en natif, et la CI astreint la bibliothèque à un sous-ensemble versionné de 34 cas couvrant chaque règle qu’atteint la version, dans les deux dispositions d’entrée.

Les délégations en pratique#

Les deux binaires déclarent KECCAK_F, SHA256_COMP, MOD_MUL et EC_ADD. Keccak atteint son circuit par le crochet native-keccak d’alloy-primitives. SHA-256, secp256k1 et BN254 atteignent les leurs par des copies corrigées de revm-precompile, k256 et ark-ff, chacune ayant le code amont comme chemin de repli. Chaque expéditeur est récupéré dans le programme invité selon les règles d’EIP-2, avec une arithmétique k256 que les correctifs acheminent vers MOD_MUL et EC_ADD.

Les binaires sont compilés en --release et prouvés à 2^20 pour chaque famille dont la hauteur est au choix : le .text du binaire sans état fait environ 1,96 MB, soit 96,6 % de ce qu’atteint une table de 2^20.

Le bloc mesuré#

Le bloc 257 510 de glamsterdam-devnet-8, passé par revm-block-stateless : 60 transactions, 101,5 Mgas, 198 millions de cycles, découpés en 207 shards. La preuve de base a pris 2 481 s sur une machine à 32 vCPU et 247,7 GiB, avec un pic à 174 GiB, la récursion a ajouté environ 2 620 s, et le contrat a accepté le résultat pour 3 620 026 gas. La page Performances détaille chaque étape.

Ce que ne fait pas la preuve d’un bloc#

• Le validateur reçoit son entrée d’un producteur de témoins externe. eth_getProof renvoie les nœuds du trie situés sur le chemin de chaque clé, mais une suppression qui provoque l’effondrement d’une branche a besoin d’un nœud frère qui ne se trouve sur le chemin d’aucune clé modifiée. L’enregistreur du dépôt ne peut donc pas produire d’entrées sans état; elles proviennent d’une version de tests-zkevm ou des jeux de données du banc d’essai zkEVM.
• Le binaire mini-bloc prouve une exécution sur un état antérieur enregistré, en général les quelques premières transactions d’un bloc, et n’affirme rien sur la racine d’état. Son journal grandit d’un enregistrement par transaction et finit par dépasser la fenêtre publique, et c’est pourquoi les blocs complets passent par le validateur sans état.

La spécification : Blocs Ethereum.

Ce qu’établit une preuve#

Une preuve dont la vérification réussit établit que le programme d’une identité donnée, lancé à son pc d’entrée sur son image, avec l’entrée publique dans sa fenêtre d’entrée et des données auxiliaires (advice) choisies par le prouveur, s’exécute instruction par instruction jusqu’à EXIT avec un statut donné, après avoir écrit un journal donné. Rien n’est affirmé au sujet des données auxiliaires. Rien n’est caché.

Hypothèses#

BN254 offre environ 100 bits de sécurité. L’erreur statistique de chaque couche du protocole, des sumchecks et de l’ouverture groupée jusqu’aux arguments de mémoire et de lookup, est très en deçà : moins de 2^14/|Fr| pour toute la passe GKR d’un circuit, moins de 2^−190 pour chaque canal de lookup, moins de 2^−220 pour chaque instance de Mercury.

Ce qu’un vérificateur doit détenir lui-même#

Deux valeurs, obtenues par un canal que le prouveur ne contrôle pas :

• L’identité du programme. Face à une identité fournie par le prouveur, une preuve montre seulement qu’un programme quelconque s’est exécuté.
• Le condensé SRS de la cérémonie. Une clé se charge sous le condensé que donnent ses propres points, quel qu’il soit : une clé construite sur un τ connu n’est donc refusée que par cette comparaison.

La clé de vérification elle-même peut provenir de n’importe qui. Son chargement recalcule l’identité et le condensé SRS à partir de son propre contenu et exige que ses circuits soient ceux du registre du vérificateur : l’identité lie le programme, le registre lie les circuits. L’outil en ligne de commande verifier ne compare que l’identité, et prend le condensé SRS dans la clé; host::verify ne compare ni l’un ni l’autre, et laisse aussi à son appelant le soin de vérifier l’entrée, le journal et le statut de sortie de l’énoncé.

Code de confiance#

La solidité relève du seul vérificateur. Elle repose sur constants, field, curve, transcript, poly, sumcheck, pcs-verify, pcs, gkr-verify, verifier-core, verifier, et constraints, car les circuits font partie de l’énoncé et une porte manquante est un défaut de solidité. Le calcul d’une identité à partir d’un ELF fait aussi confiance à loader, isa et program. La dernière étape vers la chaîne ajoute les programmes de récursion, groth16, le circuit du décideur et le contrat.

Le prouveur, l’émulateur, les constructeurs de trace et la moitié du SDK hôte consacrée à la preuve ne bénéficient d’aucune confiance. Le prouveur ne valide rien; une entrée erronée coûte à un prouveur honnête une preuve qui échoue, et un prouveur malhonnête n’exécute de toute façon rien de ce code.

Ni temps constant, ni divulgation nulle de connaissance#

Rien dans le code n’est à temps constant : les réductions, les exponentiations, les additions de points et les échelles scalaires bifurquent selon leurs opérandes. C’est sans conséquence ici, car aucune preuve n’est à divulgation nulle de connaissance : la génération de preuves ne garde donc rien de secret. Le seul secret que manipule le code est le facteur d’un contributeur à la cérémonie du décideur, qui passe par la même échelle à temps variable; effectuez les contributions sur une machine que vous contrôlez.

Limites de la v1.0.0#

Ce que change la prochaine version#

Chacune des hypothèses ci-dessus qui fait intervenir BN254, de q-DLOG et du couplage jusqu’à Groth16, tombe face à un ordinateur quantique suffisamment grand. La trajectoire de la v2.0.0 est un cœur de preuve dont la solidité repose plutôt sur des problèmes de réseaux.

Pour la vue d’un auditeur sur le même modèle, crate par crate et argument par argument : Guide d’audit, Carte de solidité.

Tous les chiffres de bout en bout concernent le bloc 257 510 de glamsterdam-devnet-8, prouvé au moyen du programme invité validateur sans état : 60 transactions, 101,5 Mgas, 198 millions de cycles. Chaque chiffre provient des mesures de la spécification.

De bout en bout#

La preuve de base, passe par passe#

Le pic a été fixé par la hauteur d’une seule famille de délégation, et non par le nombre de shards en cours de traitement.

Un petit programme invité#

Le programme invité du Démarrage rapide, 114 cycles répartis sur quatre familles d’instructions, prouvé avec des hauteurs d’instructions de 2^20 et des hauteurs de fenêtres de 2^16, avec deux shards en cours de traitement : 7 shards, 52 s et un pic de 18 GB sur un portable à 18 cœurs et 48 GiB, presque entièrement dû aux deux shards de 2^20 en cours de traitement. Le plancher d’une preuve est fixé par ses familles et ses hauteurs, et non par son nombre de cycles.

Le shard de chaque famille#

Aux hauteurs par défaut. La taille de la preuve d’un shard est fixée par la forme et la hauteur de son circuit; son coût de preuve suit le produit de sa hauteur par la largeur de son circuit, quel que soit le nombre de lignes actives.

Une hauteur ne change que le nombre de listes à réduction de moitié et de tours de sumcheck, pas les portes : ADD_SUB_LUI_AUIPC à 2^20 a 298 colonnes internes et une preuve de 57 196 octets, contre 314 et 64 764 à 2^22.

Mémoire de la passe avant#

Le prouveur GKR détient chaque couche interne sous forme d’éléments du corps, à raison de 32 octets par cellule. Ensembles de travail représentatifs :

Mercury#

Sur un Apple M5 Pro à 18 cœurs :

Lire ces chiffres#

La génération de preuves est limitée par la mémoire, et sa mémoire suit les shards en cours de traitement et leurs hauteurs, jamais la longueur de l’exécution. Le temps suit le nombre de cycles, famille par famille. Le coût sur la chaîne suit le nombre de points que la racine doit au couplage final, à environ 9 000 gas par point. Les nombres de cycles eux-mêmes sont exacts et indépendants de la machine : le profileur de cycles est donc le bon premier outil pour estimer tout le reste.

La version 1.0.0 tranche la question de savoir si l’architecture tient à pleine échelle : un bloc Ethereum entier, d’un programme invité en Rust jusqu’à un contrat qui répond true. La version 2.0.0 change ce sur quoi repose cette architecture et ceux qu’elle sert. Son cœur de preuve passe à des mathématiques qu’un ordinateur quantique ne casse pas, et sa surface pour les développeurs passe d’un dépôt à un système qui déploie des applications.

Les quatre initiatives#

La trajectoire#

Ce qui est conservé#

Le saut se fait dans les fondations, pas dans le modèle pour lequel un développeur écrit :

• Le programme invité. Rust, RISC-V, trois régions mémoire, une identité, un journal. Les programmes écrits pour la v1.0.0 conservent leur forme.
• Le moteur GKR. Les circuits en couches et le sumcheck sont définis sur n’importe quel corps. Le moteur qui ramène un circuit à un seul point est la partie d’Apogee qui passe le plus directement au nouveau corps.
• Les arguments. Un seul multiensemble mémoire sur toute l’exécution, ainsi que les canaux LogUp, sont conservés en tant que constructions; leurs tables et leurs arguments d’intervalle sont redérivés pour la taille du nouveau corps.
• La discipline. La spécification d’abord, chaque couche vérifiée par rapport à un oracle indépendant, chaque classe de contrefaçon couverte par un jumeau falsifié.

Pourquoi maintenant#

Une preuve de validité ne résiste au quantique qu’autant que le système qui la produit. Une preuve sur BN254 repose sur des couplages et des logarithmes discrets : un ordinateur quantique suffisamment grand pourrait donc en contrefaire une sans toucher à rien de ce que le programme invité a calculé. Les applications natives blockchain sont destinées à conserver de la valeur pendant des décennies. Le socle sur lequel elles effectuent leur règlement doit survivre aux machines qui casseront un jour les courbes d’aujourd’hui, et c’est avant que ces machines n’existent qu’il faut le déplacer.

Lire les initiatives : Preuve post-quantique · Signatures pour les programmes invités · Le Système de déploiement.

Ce qui casse, et où#

Chaque hypothèse cryptographique sous-jacente à Apogee v1.0.0 fait intervenir BN254. Mercury et KZG sont solides sous q-DLOG dans le modèle du groupe algébrique; l’arbre de récursion replie des vérifications de couplage; le décideur est Groth16. L’algorithme de Shor résout le logarithme discret sur un ordinateur quantique de taille suffisante, et, avec lui, chacune de ces hypothèses. Le calcul du programme invité resterait ce qu’il était; la preuve qu’il s’est exécuté correctement ne voudrait plus rien dire.

C’est dans l’engagement que se concentre la dépendance. Chaque colonne de chaque shard est engagée avec lui, chaque ouverture se termine par son couplage, et la récursion existe pour replier ces couplages. Remplacez l’engagement, et le reste du cœur de preuve n’a plus rien qui dépende d’un logarithme discret.

QL-01 · Engagements sur réseaux euclidiens#

Un engagement sur réseau est une application linéaire, t = A·s mod q, appliquée à un vecteur s à petits coefficients. Il est liant tant que personne ne peut trouver un vecteur court que la matrice envoie sur zéro : c’est Module-SIS, la famille d’hypothèses qui sous-tend ML-DSA et ML-KEM, les normes post-quantiques du NIST, avec derrière elle des réductions au pire cas et des décennies de cryptanalyse.

Il conserve ce qui rendait KZG si utile à Apogee et que les engagements à base de hachage abandonnent : il est homomorphe. Les engagements de nombreux fragments se combinent sous des coefficients de défi, et la combinaison s’ouvre par un seul vecteur. Regrouper les colonnes d’un shard, différer des vérifications et les replier le long d’un arbre sont des opérations linéaires, et les opérations linéaires survivent à la transition. Les chemins de Merkle, eux, ne se combinent pas du tout.

Le prix à payer est une contrainte sans équivalent ailleurs : l’engagement ne lie que des vecteurs courts, chaque combinaison allonge le vecteur, et le prouveur doit montrer qu’il reste assez court. Les schémas des deux dernières années diffèrent surtout par la façon dont ils paient ce prix, et ils ont progressé vite. Pour des polynômes de 2^30 coefficients, les schémas Module-SIS publiés donnent des preuves d’évaluation de 53 à 72 KB, et la vérification est passée de 2,8 secondes en 2024 à 8 à 16 millisecondes en 2026. L’exposé Lattice-Based Polynomial Commitment Schemes les passe en revue schéma par schéma et met les chiffres en regard de ceux du côté à base de hachage.

QL-02 · Changement de corps#

Les schémas sur réseaux ne vivent pas dans le monde de BN254. Les principales constructions travaillent sur de petits modules premiers, avec des points d’évaluation tirés d’un corps d’extension pour préserver la solidité, ce qui convient à un système de preuve sur petit corps et ne convient pas à un système sur 254 bits. Le changement d’engagement entraîne donc celui du corps : la v2.0.0 change le corps de l’arithmétisation, en faisant passer chaque circuit du corps des scalaires de BN254 à un petit corps adapté à l’engagement.

Le changement se rentabilise de lui-même :

• Chaque couche coûte moins cher. Un prouveur GKR passe son temps en arithmétique de corps, et une multiplication dans un petit corps coûte une fraction de ce que coûte une multiplication dans un corps de 254 bits. L’économie centrale du moteur, le fait que les couches intermédiaires ne sont jamais engagées, se cumule avec une arithmétique moins coûteuse sur chaque couche qui reste.
• Les engagements coûtent moins cher. Engager une colonne de la trace revient à appliquer une application linéaire à de petits chiffres, payée par entrée non nulle, plutôt qu’à effectuer une multiplication multi-scalaire sur une courbe.
• Le moteur est conservé. GKR et le sumcheck sont définis sur n’importe quel corps. Les défis passent dans un corps d’extension; la passe arrière, le modèle en couches et les arguments construits dessus conservent leur structure.

Ce qu’il faut reconstruire, c’est tout ce qui supposait un grand corps : les valeurs au niveau du mot qui tiennent largement dans un seul élément de BN254, les arguments d’intervalle et les retenues dimensionnés en fonction d’un module de 254 bits, les chaînes de canonicité, et les cellules de corps du format de récursion. Chacun de ces éléments est redérivé pour le nouveau corps et spécifié comme l’ont été ceux de la v1.0.0, avec son propre oracle et ses jumeaux falsifiés.

Règlement#

Les précompilés de vérification d’Ethereum reposent aujourd’hui sur les couplages. La façon dont un cœur de preuve post-quantique effectue son règlement sur cette chaîne, et la part de l’étape finale qui peut reposer sur des réseaux, font partie du même programme de travail, et seront spécifiées avec le même soin que le cœur avant sa livraison.

Retour au breffage de mission.

Presque toute application native blockchain pose la même question à chaque requête : est-ce la bonne clé qui a autorisé ceci? Dans la v1.0.0, un programme invité y répond par du code. La récupération de clé secp256k1, c’est k256 qui s’exécute sur les circuits délégués MOD_MUL et EC_ADD, ce qui rend abordables les signatures propres à Ethereum; tout le reste passe par des instructions ordinaires. QL-03 fait de la vérification de signatures une opération de premier rang des programmes invités.

Les schémas#

Qu’un schéma de signature soit peu coûteux à prouver ou non tient presque entièrement à son algorithme de vérification : quelle arithmétique il effectue, dans quel corps, et quelle fonction de hachage il appelle. Le signataire ne s’exécute jamais dans la preuve. Quatre conceptions couvrent l’espace :

Les quatre vérificateurs procèdent par calcul puis comparaison, sans secret ni branchement sur des secrets, et c’est ce qui rend chacun d’eux prouvable. L’exposé ZK-Friendly Signature Schemes les examine un à un sur un exemple jouet et compare leurs coûts en circuit.

Ce qui détermine le coût#

Deux leviers font bouger chaque chiffre :

• Le corps sur lequel travaille le prouveur. Un schéma est natif quand son arithmétique est celle du circuit. Le schéma le moins coûteux dépend donc du changement de corps de QL-02, et le choix se fait en même temps que lui.
• Le hachage. Les vérificateurs post-quantiques sont dominés par leur hachage normalisé, non par leur algèbre. Le remplacer par un hachage arithmétique fait sortir de la norme, et c’est la variante que retiennent les constructions orientées ZK; le conserver est ce qu’exige l’interopérabilité avec les clés existantes. Les deux ont leur place, et c’est le programme invité qui décide.

Pour les développeurs#

Le but : un programme invité qui vérifie une autorisation comme il calcule aujourd’hui un hachage, en un seul appel délégué à un circuit, sans cryptographie dans le code propre de l’application. Cela ouvre la voie aux modèles sur lesquels se construisent les applications natives blockchain : des comptes dont les clés ne sont pas celles de la chaîne, l’approbation multipartite au sein de la fonction de transition d’état, les clés de session, et des identités qui restent valides après la chute des courbes sur lesquelles elles sont nées.

Retour au breffage de mission.