# Apogee en un coup d’œil

> Les faits sur une seule page. Ce que prouve Apogee VM, comment, à quel coût, sous quelles hypothèses, et où s’arrête la version 1.0.0.

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

| | Apogee VM v1.0.0 |
| --- | --- |
| Ce qu’énonce une preuve | Que le programme de cette identité, lancé à son point d’entrée sur son image, avec cette entrée publique et certaines données auxiliaires (*advice*), s’est exécuté instruction par instruction jusqu’à `EXIT` avec ce statut, après avoir écrit ce journal |
| Jeu d’instructions | RV32IMAC sur un seul hart : les 59 instructions de RV32IMA (40 de base, 8 M, 11 A), les instructions compressées étant développées au chargement |
| Langage des programmes invités | Rust, `#![no_std]` avec `alloc`, stable 1.96.1, cible `riscv32imac-unknown-none-elf` |
| Arithmétisation | 23 familles de circuits, chacune un circuit GKR en couches : 7 pour les instructions, 5 pour les fenêtres mémoire, 6 délégations, 5 pour la récursion |
| Arguments | Les portes par sumcheck; la mémoire par un seul multiensemble lecture/écriture sur toute l’exécution; les lookups par LogUp |
| Corps | Le corps des scalaires de BN254, 254 bits |
| Engagements | Mercury, multilinéaire sur KZG, une ouverture de 704 octets par shard quel que soit le nombre de colonnes |
| Mise en place | Les puissances de tau perpétuelles de PSE, contribution 80; une seconde cérémonie, propre au circuit, pour le décideur sur la chaîne |
| Transcription | Une éponge duplex Poseidon2 sur `Fr`, largeur 3, débit 2 |
| Règlement | Arbre de récursion → décideur Groth16 → `ApogeeVerifier.sol` |
| Niveau de sécurité | Environ 100 bits, fixé par BN254 |
| Divulgation nulle de connaissance | Non. Les preuves sont succinctes, pas à divulgation nulle de connaissance, et aucun aveuglement n’est appliqué |
| Opérations déléguées | Tours de keccak-f[1600], tours de SHA-256, Poseidon2, arithmétique `Fr` de BN254, multiplication modulaire sur 256 bits pour quatre modules d’Ethereum, addition complète de points sur secp256k1 et sur G1 de BN254 |
| Valeurs publiques | Au plus 16 380 octets d’entrée et 16 380 octets de journal; données auxiliaires jusqu’à 2 GiB |
| Longueur d’exécution | Jusqu’à `2^36 − 1` cycles |
| Taille du code | `.text` dans la limite de 7,94 MiB pour une hauteur de table de `2^22`; image dans la limite de 4 MiB par défaut |
| Cryptographie tierce | Aucune sur un chemin de preuve. arkworks, Plonky3 et zkhash n’apparaissent que comme oracles de test |

## 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](https://apogee.gweb3networks.com/docs/auditors/spec/recursion#s10) et [prouveur en flux §1](https://apogee.gweb3networks.com/docs/auditors/spec/streaming#s1) dans la spécification.

| Étape | Résultat |
| --- | --- |
| Preuve de base | 207 shards, 14,5 MB, 2 481 s sur 32 vCPU et 247,7 GiB, pic de RSS de 173,92 GiB |
| Arbre de récursion | 116 shards : quatre feuilles d’au plus 64 shards de base (2 157 s au total, pic de 92 GiB) et une racine (460 s, 1,03 MB) |
| Circuit du décideur | 7 896 686 contraintes sur un domaine de `2^23` |
| Preuve du décideur | 18,5 s et 6,1 GB sur un portable à 18 cœurs, la clé étant lue en 1 s |
| Vérification sur la chaîne | 3 620 026 gas, 34 980 octets de calldata, 358 points repliés par le contrat |
| Conformité | Les 67 251 paires de `tests-zkevm` v21.0.1 concordent toutes en exécution native |

## 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é](https://apogee.gweb3networks.com/docs/architecture/security) 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](https://www.gweb3networks.com/thesis.html); la direction de la prochaine version, dans [Saut quantique](https://apogee.gweb3networks.com/docs/quantum-leap).