# Blocs Ethereum

> La charge de travail de référence d’Apogee. Un programme invité revm qui exécute des blocs Ethereum à l’intérieur de la VM, un validateur sans état qui concorde avec chaque cas de la version de tests zkEVM, et ce que dit la preuve d’un bloc.

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

| Binaire | Données auxiliaires (*advice*) | Journal | Énonce |
| --- | --- | --- | --- |
| `revm-block` | un `BlockWitness` : l’état antérieur que lisent les transactions | pour chaque transaction, son statut, son gas et ses données de retour; un engagement sur les journaux d’événements; un résumé de l’état postérieur | un certain témoin canonique fait produire ce journal à `revm_block::run` : la preuve d’une exécution, et non de la validité d’un bloc |
| `revm-block-stateless` | l’entrée sans état du format de banc d’essai zkEVM | 43 octets : la racine de la charge utile, le verdict, l’identifiant de chaîne, l’identifiant de schéma | la charge utile de cette racine est, ou n’est pas, un bloc valide sur cette chaîne sous ce fork |

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](https://apogee.gweb3networks.com/docs/architecture/performance) 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](https://apogee.gweb3networks.com/docs/auditors/spec/ethereum).