À but éducatif uniquement ; ne constitue pas un conseil financier, d’investissement, de pont ou de sécurité. Les garanties d’un rollup dépendent des contrats déployés, du système de preuve, de la disponibilité des données, des autorisations de l’opérateur, de la gouvernance et de la couche de base, tous susceptibles de changer.
Réponse directe
Un rollup est un modèle de mise à l’échelle qui exécute les transactions hors d’une couche de base, tout en utilisant celle-ci pour publier des données ou engagements définis par le protocole et régler les transitions d’état contestées ou prouvées. De nombreuses transactions partagent le coût des données et du règlement. Un rollup dépasse donc la compression et une racine d’état seule ne fournit pas les données nécessaires à la reconstruction de la chaîne.
Les rollups optimistes acceptent généralement les affirmations d’état sauf si une contestation par preuve de faute démontre une transition invalide. Les rollups ZK soumettent des preuves de validité vérifiées par le contrat de règlement. Ces termes décrivent l’acceptation des transitions, pas une garantie universelle sur la décentralisation du séquenceur, le stockage, les mises à niveau, les frais ou le délai de retrait.
Fonctionnement
- Ordonner et exécuter. Un séquenceur ou autre mécanisme sélectionne et ordonne les transactions puis calcule l’état résultant. Un reçu rapide peut précéder la confirmation sur la couche de base.
- Publier les données. Le système publie assez de données d’entrée, souvent comme calldata ou blobs, sur la couche de base, ou emploie une disponibilité distincte. Celle-ci détermine si des nœuds indépendants peuvent reconstruire et vérifier l’état.
- Engager l’état. Le rollup publie des racines d’état ou d’autres engagements qui le lient à un résultat. Un engagement est compact mais n’est pas l’historique sous-jacent.
- Vérifier les transitions. Le modèle optimiste dépend d’une fenêtre de contestation et d’un processus de preuve de faute déployé ; le ZK dépend d’une preuve de validité et d’un vérificateur on-chain. Bogues, autorisations et disponibilité restent importants.
- Régler et retirer. Les contrats de base déterminent quand une affirmation ou preuve est acceptée et comment messages et actifs sont finalisés. Les retraits canoniques peuvent subir les délais de preuve, contestation ou finalité ; un pont rapide ajoute fournisseur de liquidité et risque de contrepartie.
- Mettre à niveau et récupérer. Gouvernance, conseils de sécurité, gardiens ou administrateurs peuvent suspendre ou modifier les contrats. Verrou temporel, voie d’évacuation et inclusion forcée doivent être vérifiés pour le déploiement précis.
Exemple
Supposons un lot de 1,000 transactions. Les utilisateurs paient ensemble 0.8 ETH, les données de base coûtent 0.5 ETH et l’exécution du rollup 0.2 ETH. Le solde inexpliqué vaut 0.8 - 0.5 - 0.2 = 0.1 ETH, soit 0.1 / 1,000 = 0.0001 ETH par transaction avant génération des preuves, infrastructure, lots échoués, coût du capital et remboursements. C’est un rapprochement des coûts, pas le bénéfice de l’opérateur.
Avant de considérer le lot final, vérifiez si le reçu vient seulement du séquenceur, si données et engagement ont atteint la couche de base, si la fenêtre de preuve de faute a pris fin ou la preuve de validité a été acceptée, et si le message de retrait est devenu séparément exécutable.
Risques
- Un séquenceur centralisé peut censurer, réordonner ou arrêter temporairement les transactions.
- Des données de lot manquantes ou indisponibles peuvent empêcher reconstruction et sorties indépendantes.
- Programmes de preuve de faute, circuits de validité, vérificateurs ou clients peuvent comporter des bogues.
- Contestataires ou producteurs de preuves peuvent être hors ligne, censurés, sous-financés ou mal autorisés.
- Congestion, réorganisation ou panne de la couche de base peut retarder publication, preuve et règlement.
- Clés de mise à niveau, gardiens ou gouvernance peuvent modifier code, paramètres ou pont.
- Ponts canoniques et associations de jetons peuvent échouer malgré une exécution correcte.
- Frais, temps de preuve et délais de retrait varient et peuvent changer après une mise à niveau.
Idées reçues
- Tous les rollups stockent tout définitivement sur la couche de base. Formats de publication et garanties d’archivage varient ; les blobs ne sont pas un stockage permanent.
- Un reçu du séquenceur est un règlement final. Il peut n’être qu’une promesse initiale d’ordre.
- ZK signifie privé. Les preuves de validité établissent un calcul correct ; la confidentialité est un choix distinct.
- Optimiste signifie sans vérification. L’exactitude exige des données reproductibles, un système de preuve de faute actif et des participants capables de contester.
- Des frais moyens réduits éliminent le risque opérationnel. Le règlement partagé réduit parfois les coûts, mais les dépendances au séquenceur, aux preuves, à la gouvernance, au pont et aux données persistent.
Sujets liés
Sources
- Mise à l’échelle - Ethereum.org (consulté le : 2026-08-21)
- Rollups optimistes - Ethereum.org (consulté le : 2026-08-21)
- Rollups à divulgation nulle de connaissance - Ethereum.org (consulté le : 2026-08-21)
- EIP-4844 : transactions de blobs de fragments - Ethereum Improvement Proposals (consulté le : 2026-08-21)