---
title: "ZK rollups"
description: "Guide axé sur la vérification des lots, preuves de validité, données disponibles, états de règlement, frais, retraits et risques propres à chaque déploiement ZK rollup."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ZK rollups

> À visée pédagogique uniquement ; ceci ne constitue pas un conseil en investissement, en pont inter-chaînes ou en sécurité. La fiabilité d’un ZK rollup dépend du programme prouvé, des entrées publiques, de la disponibilité des données, des contrats, opérateurs, règles de gouvernance et de la chaîne de règlement.

<a id="answer"></a>

## Réponse directe

Un ZK rollup, plus précisément un rollup de validité, exécute les transactions hors d’une chaîne de règlement, les regroupe en lots puis soumet des engagements de données, des affirmations d’état et des preuves de validité aux contrats de cette chaîne. Le vérificateur contrôle que le lot respecte les règles de transition encodées sans réexécuter chaque transaction. Les coûts de publication et de vérification sont ainsi amortis sur de nombreuses transactions.

La garantie est précise, non absolue. Une preuve vérifiée ne soutient que l’affirmation encodée par le programme déployé et liée aux entrées publiques. Elle ne prouve pas à elle seule que les données sont récupérables, le séquenceur disponible ou équitable, le bloc de règlement final, le pont correct ou une mise à niveau sûre. « ZK » ne signifie pas non plus privé : beaucoup de rollups publient transactions ou différences d’état.

<a id="mechanism"></a>

## Fonctionnement

1. Identifiez le déploiement : identifiants L1 et L2, contrats du rollup et du pont, vérificateur et version de clé, programme ou circuits prouvés, format des lots, mode de disponibilité, séquenceur, prouveur, administrateurs, pouvoirs de pause et bloc observé. Le nom d’une pile ne garantit pas tous ses déploiements.
2. Séparez ordre et preuve. Le séquenceur peut émettre rapidement un reçu et produire des blocs L2 avant que l’engagement ou la preuve atteigne L1. Notez le lot exact et distinguez les états ordonné, engagé, prouvé, accepté, sûr au règlement, finalisé au règlement et retrait achevé.
3. Reconstruisez le lot. Récupérez transactions, différences d’état, blob sidecars ou autre charge requise ; vérifiez ordre et engagements ; dérivez les racines avant et après, la racine de retraits ou messages et les autres entrées publiques. Une preuve liée à la mauvaise chaîne, au mauvais lot ou à la mauvaise racine prouve autre chose.
4. Vérifiez le parcours de preuve. Confirmez que la transaction de règlement a appelé le vérificateur prévu avec la preuve, la clé et les entrées attendues, a réussi, émis le bon événement et modifié le bon emplacement d’état. Si possible, reproduisez vérification et exécution avec un logiciel indépendant.
5. Auditez séparément les données. Les blobs Ethereum offrent disponibilité pendant la fenêtre du protocole et engagements, pas un archivage permanent. Un comité externe ou une couche DA alternative ajoute ses hypothèses. La validité d’une preuve ne restaure pas les données nécessaires pour reconstruire l’état ou sortir.
6. Suivez dépôts et retraits de bout en bout. Rapprochez jeton et messager canoniques, montant, destination, nonce, racine d’inclusion, preuve, règle de finalité et variation de solde exécutée. Un pont rapide avance des liquidités avec ses prix, routes et risques de contrepartie ; il ne raccourcit pas l’horloge canonique.
7. Surveillez disponibilité et contrôle. Mesurez files de lots et de preuves, inclusion forcée et échappatoires, diversité des prouveurs, mises à niveau, délais, gardiens et modes d’urgence. Recommencez après tout changement de contrat, circuit, clé, mode DA ou protocole.

<a id="example"></a>

## Exemples chiffrés

- **Compression.** Un lot pédagogique contient `10,000 transactions` ; `1,200 KB` d’entrées brutes deviennent `300 KB`. Le ratio est `1,200 / 300 = 4.0x`, la réduction `1 - 300 / 1,200 = 75%` et la moyenne décimale `300,000 / 10,000 = 30 bytes/transaction`. Ces chiffres ne mesurent ni solidité de preuve, ni croissance d’état, ni archivage.
- **Répartition des coûts.** Les utilisateurs paient `3.0 ETH` ; les données L1 coûtent `1.4 ETH`, la vérification `0.4 ETH` et l’exécution L2 `0.2 ETH`. Le résidu vaut `3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH` et la moyenne `3.0 / 10,000 = 0.0003 ETH/transaction`. Ce n’est pas un bénéfice net : preuve, matériel, échecs, ponts, capital et impôts sont exclus.
- **Cycle de vie.** Le portefeuille reçoit un reçu à `minute 0` ; l’engagement arrive sur L1 à `minute 12` ; la preuve est acceptée à `minute 50` ; la politique de finalité est satisfaite à `minute 64` ; le retrait canonique s’exécute à `minute 70`. Le délai séquentiel est `12 + 38 + 14 + 6 = 70 minutes`. Aucun instant antérieur n’équivaut au retrait achevé.

<a id="risks"></a>

## Risques

- Mauvaise chaîne, déploiement, contrat, lot, racine, vérificateur, clé ou version de circuit.
- Programme prouvé incomplet ou faux qu’un système fiable prouve fidèlement.
- Entrées publiques, séparateurs de domaine, messages ou paramètres absents ou mal encodés.
- Failles du vérificateur, précompilé, pont, messager ou contrat de mise à jour d’état.
- Matériel d’initialisation compromis ou hypothèses cryptographiques rompues.
- Censure, réordonnancement, équivoque, panne ou publication tardive du séquenceur.
- Panne, centralisation, censure, capacité insuffisante ou file croissante du prouveur.
- Transactions, différences d’état ou blob sidecars indisponibles, mal formés ou non archivés.
- Confondre engagement ou signature de comité avec récupérabilité actuelle.
- Réorganisation L1 ou confiance prématurée dans une transaction de règlement non sûre.
- Mise à niveau privilégiée, délai court, remplacement, pause ou contournement d’urgence.
- Inclusion forcée, récupération ou sortie absente, désactivée ou inutilisable.
- Failles du pont canonique, mauvais jeton, rejeu, message ou preuve de retrait défaillante.
- Risques de liquidité, prix, route, insolvabilité et contrepartie des ponts rapides.
- Estimations omettant données L1, preuve, pont, congestion ou transactions échouées.
- Supposer qu’EVM, finalité, confidentialité ou sécurité d’un rollup vaut pour un autre.

<a id="misconceptions"></a>

## Idées reçues

- Tout ZK rollup masque montants, adresses et activité des applications.
- Une preuve valide garantit les données et permet de reconstruire l’état.
- Un reçu du séquenceur équivaut à une preuve acceptée sur L1 ou à un retrait finalisé.
- Les preuves de validité suppriment les risques de séquenceur, prouveur, gouvernance, mise à niveau et pont.
- Le système de preuve le moins cher ou le plus rapide donne automatiquement le résultat le plus sûr.

<a id="related"></a>

## Sujets connexes

- [Preuve de validité](/fr/crypto/validity-proof/)
- [Disponibilité des données](/fr/crypto/data-availability/)
- [Couche 2](/fr/crypto/layer2/)
- [Rollup](/fr/crypto/rollup/)
- [Preuve à divulgation nulle de connaissance](/fr/crypto/zero-knowledge-proof/)

<a id="sources"></a>

## Sources

- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (consulté le 2026-08-22)
- [Zero-knowledge proofs](https://ethereum.org/zero-knowledge-proofs/) - Ethereum.org (consulté le 2026-08-22)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consulté le 2026-08-22)
- [Rollup Process](https://docs.scroll.io/en/technology/chain/rollup/) - Scroll Documentation (consulté le 2026-08-22)
- [Data availability](https://docs.starknet.io/learn/protocol/data-availability) - Starknet Documentation (consulté le 2026-08-22)

Source: https://wiki.fcontext.com/fr/crypto/zk-rollup/index.mdx