ZK rollups : aller plus loin
Cycle de vie d'une preuve de validité, coût des provers, types de zkEVM, finalité et retraits, et les vrais risques : mises à jour et centralisation.
L’essentiel
Rappel : preuve de validité contre preuve de fraude
Les rollups optimistes supposent que les lots sont valides et laissent une période pendant laquelle chacun peut contester avec une preuve de fraude. Les ZK rollups font l'inverse : aucun nouvel état n'est accepté sans preuve.
Une preuve de validité est une preuve cryptographique courte qui atteste qu'un calcul a été fait correctement, sans que le vérificateur ait à refaire ce calcul. Le terme « ZK » (zero-knowledge, divulgation nulle de connaissance) est un peu trompeur ici : la plupart des ZK rollups utilisent ces preuves surtout pour leur concision, pas pour cacher des informations.
Si ces notions sont nouvelles pour vous, commencez par le guide sur les rollups optimistes et ZK, puis celui sur les preuves à divulgation nulle.
Le cycle de vie d'un lot, étape par étape
D'après ethereum.org, le fonctionnement se déroule ainsi :
- Envoi. Vous signez une transaction et l'envoyez à l'opérateur du rollup, le plus souvent un séquenceur.
- Exécution hors chaîne. Le séquenceur ordonne et exécute les transactions, puis les regroupe en lots (batches).
- Publication des données. Les données nécessaires pour reconstruire l'état sont publiées, idéalement sur Ethereum (en blobs ou calldata).
- Calcul de la nouvelle racine d'état. L'état du rollup est représenté par un arbre de Merkle ; sa « racine » (une empreinte unique) résume tous les soldes et contrats.
- Génération de la preuve. Un prover (prouveur) calcule la preuve que le passage de l'ancienne racine à la nouvelle respecte les règles.
- Vérification sur Ethereum. Un contrat vérificateur sur Ethereum contrôle la preuve. Ce n'est qu'après cette vérification que la nouvelle racine devient canonique.
Point important : entre l'étape 1 et l'étape 6, il peut s'écouler un temps significatif. La confirmation que vous voyez dans votre wallet au bout de quelques secondes est celle du séquenceur, pas celle d'Ethereum.
SNARK ou STARK : deux familles de preuves
ethereum.org résume les différences principales :
| Critère | SNARK | STARK |
|---|---|---|
| Mise en place | Cérémonie de confiance (trusted setup) | Transparente, sans cérémonie |
| Taille de preuve | Plus petite | Plus grande |
| Coût de vérification | Plus faible | Plus élevé |
La cérémonie de confiance consiste à générer des paramètres publics à partir de secrets fournis par plusieurs participants. Selon ethereum.org, la sécurité est garantie tant qu'au moins un participant honnête a détruit sa contribution.
En pratique, de nombreux projets combinent les deux : ils produisent une preuve STARK, puis l'« enveloppent » dans une preuve SNARK plus petite pour réduire le coût de vérification sur Ethereum. La fiche L2BEAT de Scroll décrit par exemple des STARK enveloppées dans des SNARK.
Le coût des provers
Générer une preuve est très coûteux en calcul. ethereum.org identifie ce point comme un inconvénient majeur : la production de preuves de validité requiert du matériel spécialisé, ce qui peut favoriser le contrôle de la chaîne par un petit nombre d'acteurs. La vérification a aussi un coût, estimé par ethereum.org à environ 500 000 gas par preuve sur Ethereum.
Conséquences pour l'utilisateur :
- Les preuves sont souvent regroupées pour amortir ce coût, ce qui allonge le délai avant que votre lot soit prouvé.
- Le rôle de prover est fréquemment tenu par l'équipe du projet ou un nombre restreint d'opérateurs.
- Les frais que vous payez intègrent une part de ce coût de preuve, en plus de la publication des données.
Les types de zkEVM selon Vitalik Buterin
Un zkEVM est un ZK rollup capable d'exécuter des contrats compatibles avec l'EVM (la machine virtuelle d'Ethereum). En août 2022, Vitalik Buterin a proposé une classification en types, du plus compatible au plus rapide à prouver :
- Type 1 – entièrement équivalent à Ethereum. Vérifie les blocs Ethereum tels quels. Compatibilité parfaite, mais génération de preuves très lente.
- Type 2 – entièrement équivalent à l'EVM. Même comportement au niveau de la machine virtuelle, mais certaines structures internes (arbre d'état, fonctions de hachage) sont modifiées pour accélérer les preuves.
- Type 2.5 – équivalent sauf le coût en gas. Les opérations difficiles à prouver coûtent plus cher, ce qui peut casser certaines applications.
- Type 3 – presque équivalent. Certaines fonctionnalités difficiles (par exemple des précompilés) sont retirées ; certaines applications doivent être réécrites.
- Type 4 – équivalent au niveau du langage. Le code Solidity ou Vyper est compilé vers un langage adapté aux preuves. Preuves rapides, mais incompatibilités, par exemple des adresses de contrats différentes.
Dans ce billet de 2022, Vitalik classait notamment zkSync et Starknet (via le compilateur Warp) en type 4, et Scroll ou Polygon Hermez entre les types 2 et 3, en transition. Ces positions datent de 2022 et les projets ont évolué depuis : servez-vous de la grille pour comprendre les compromis, pas comme classement actuel. Starknet utilise d'ailleurs sa propre machine virtuelle et son langage, Cairo, plutôt que l'EVM.
Ce que cela change pour vous : sur un zkEVM moins compatible, une application ou un wallet peut se comporter différemment d'Ethereum (adresses, gas, fonctions indisponibles). Ce n'est pas un défaut en soi, mais une source d'erreurs si vous supposez une équivalence parfaite.
Finalité et retraits
C'est l'argument le plus cité en faveur des ZK rollups. ethereum.org explique qu'il n'y a pas de délai de contestation : une fois la preuve vérifiée par le contrat, les retraits peuvent être exécutés. Vous brûlez vos actifs sur le L2, puis réclamez les fonds sur Ethereum avec une preuve de Merkle.
Trois nuances pratiques :
- Le délai de preuve. Votre retrait n'est exécutable qu'après la vérification de la preuve du lot concerné, ce qui dépend du rythme de publication du projet.
- Les délais ajoutés. Certains projets ajoutent des délais de sécurité ou dépendent d'opérateurs pour finaliser. Consultez la section « retraits » de la fiche L2BEAT.
- Les ponts tiers. Des services de bridge permettent de sortir plus vite en échange de frais, avec leurs propres risques (voir le guide sur les bridges).
Les vrais risques : au-delà des mathématiques
Une preuve de validité garantit que le calcul est correct selon le contrat vérificateur en place. Si ce contrat peut être remplacé du jour au lendemain, la garantie mathématique perd beaucoup de sa valeur.
1. La possibilité de mettre à jour les contrats
Le cadre des « stages » de L2BEAT mesure précisément ce point :
- Stage 1 : seul un Security Council (conseil de sécurité) compromis à au moins 75 % peut bloquer indéfiniment un retrait, et les mises à jour initiées par d'autres acteurs doivent laisser au moins 7 jours pour sortir.
- Stage 2 : les utilisateurs disposent d'au moins 30 jours pour sortir en cas de mise à jour non désirée, et le conseil de sécurité ne peut intervenir qu'en cas de bug démontrable sur la chaîne.
Illustrations tirées des fiches L2BEAT consultées à la date de ce guide :
- Scroll est classé Stage 0. L2BEAT indique que ses contrats peuvent être mis à jour instantanément, sans fenêtre de sortie, et signale que le Security Council indépendant (9 sur 12) a été remplacé le 1er juin 2026 par un multisig d'administration de l'équipe (3 sur 4).
- Starknet est classé Stage 1. Les mises à jour normales passent par un délai de 8 jours, mais le Security Council (9 sur 12) peut agir instantanément en urgence.
2. La centralisation du prover et du proposer
Sur Starknet, L2BEAT indique que seuls des proposers sur liste blanche peuvent soumettre les racines d'état, et que les retraits sont gelés s'ils cessent de le faire, sauf intervention du Security Council. À l'inverse, la fiche de Scroll indique qu'en cas de défaillance du proposer, les utilisateurs peuvent utiliser le prover dont le code est disponible pour soumettre eux-mêmes des preuves.
3. La censure par le séquenceur
ethereum.org décrit la possibilité de soumettre des transactions directement au contrat du rollup sur Ethereum en cas de censure. Mais les modalités varient fortement : L2BEAT mentionne jusqu'à 7 jours de délai pour forcer une transaction sur Scroll, et indique que sur Starknet les utilisateurs ne peuvent pas forcer l'inclusion de leurs messages, sans délai garanti par le protocole.
4. Les bugs dans les circuits
Un circuit de preuve est un logiciel complexe. Un bug pourrait permettre de prouver un état incorrect. C'est l'une des raisons pour lesquelles les projets gardent des pouvoirs de mise à jour d'urgence, ce qui ramène au risque n°1.
Checklist de lecture d'une fiche L2BEAT
- Quel « stage » (0, 1 ou 2) ?
- Les données sont-elles publiées sur Ethereum ?
- Qui peut soumettre les preuves et les racines d'état ? Que se passe-t-il s'ils s'arrêtent ?
- Peut-on forcer une transaction via Ethereum, et en combien de temps ?
- Quelle fenêtre de sortie en cas de mise à jour ? Le conseil de sécurité est-il indépendant ?
Exemple concret
Sophie hésite entre deux ZK rollups pour conserver durablement des stablecoins. Tous deux affichent des preuves de validité et des frais bas.
Elle ouvre leurs fiches L2BEAT. Le premier est en Stage 1 : délai de plusieurs jours pour les mises à jour normales, conseil de sécurité multi-parties, données publiées sur Ethereum. Le second est en Stage 0 : contrats modifiables instantanément par un multisig de l'équipe, sans fenêtre de sortie.
Sa conclusion : sur le second, sa sécurité dépend avant tout de la bonne foi et de la sécurité opérationnelle des détenteurs de ce multisig, bien plus que des mathématiques des preuves. Elle réserve ce rollup à un usage ponctuel avec des montants limités, et vérifie à nouveau les fiches tous les quelques mois, car ces paramètres changent.
Les erreurs à éviter
- Penser que « ZK » signifie « sans confiance ». La preuve protège contre un calcul faux, pas contre une mise à jour malveillante des contrats.
- Confondre confirmation du séquenceur et vérification de la preuve. Seule la seconde rend l'état définitif sur Ethereum.
- Supposer une compatibilité EVM parfaite. Adresses, coûts en gas ou fonctions peuvent différer : testez avec de petits montants.
- Se fier à un classement ancien. Les types de zkEVM de 2022 et les stages L2BEAT évoluent ; vérifiez la situation actuelle.
- Ignorer le rôle du prover. S'il est unique et que rien ne permet de le remplacer, une panne peut bloquer les retraits.
Ce guide est une information générale et ne constitue pas un conseil en investissement.
À retenir
- Un ZK rollup n'accepte un nouvel état qu'après vérification d'une preuve de validité sur Ethereum, ce qui supprime la période de contestation.
- Générer ces preuves coûte cher et demande du matériel spécialisé, ce qui tend à concentrer le rôle de prover.
- La classification des zkEVM (types 1 à 4) décrit un compromis entre compatibilité avec Ethereum et rapidité des preuves.
- Les retraits restent dépendants du rythme des preuves et des éventuels délais ajoutés par chaque projet.
- Le principal risque pratique est souvent la gouvernance : contrats modifiables, conseil de sécurité, fenêtre de sortie.
- Les fiches et le cadre « stages » de L2BEAT sont le meilleur point de départ pour évaluer un ZK rollup.