Beaucoup de personnes, lorsqu’elles entendent parler de Rollup pour la première fois, rencontrent une affirmation contre-intuitive : un Rollup peut « compresser 10 000 transactions en une seule ».

Cette phrase donne l’impression qu’il s’agit de compression de fichiers — comme si l’on glissait un gros fichier zip dans une petite enveloppe avant de l’envoyer sur Ethereum. Mais si c’était vraiment le cas, un problème se poserait : si un Rollup ne faisait que réduire les données, pourquoi Ethereum croirait-il que ces transactions ont réellement eu lieu et que le résultat est correct ? Un fichier compressé, en lui-même, ne rend pas les transactions dignes de confiance.

Pour comprendre un Rollup, l’essentiel n’est pas de se demander « comment les données deviennent plus petites », mais de se demander « quel travail Ethereum effectuait à l’origine, et où le Rollup a déplacé ce travail ». Cet article suivra cette question étape par étape : pourquoi Ethereum ne peut pas traiter davantage de transactions, ce que fait réellement un Rollup, d’où vient sa sécurité, et pourquoi il ne permet toujours pas une scalabilité illimitée.

Pourquoi faut-il « compresser 10 000 transactions en une seule »

Commençons par regarder ce qu’Ethereum fait lui-même.

Ethereum est une blockchain de couche 1, souvent appelée L1. Sur L1, chaque transaction doit être vérifiée et exécutée par un grand nombre de nœuds du réseau, et l’état des comptes à l’échelle du réseau doit être mis à jour. Ici, « exécuter » ne signifie pas simplement enregistrer quelque chose : il faut réellement faire tourner la logique de la transaction. Combien de jetons ont été transférés, quel contrat a été appelé, comment les soldes changent — tout cela doit être calculé.

Cette conception est la source de la sécurité d’Ethereum, mais c’est aussi son goulot d’étranglement. Plus il y a de transactions, plus le travail que l’ensemble du réseau doit répéter est important. Chaque transaction doit être exécutée une fois par des milliers de nœuds, et le coût augmente donc linéairement avec le nombre de transactions. En cas de congestion du réseau, les utilisateurs ne peuvent qu’augmenter sans cesse les frais pour être traités en premier, ce qui rend les transactions à la fois lentes et coûteuses.

Une idée naturelle est alors apparue : ne pourrait-on pas éviter de placer chaque transaction sur L1 et de l’exécuter une par une ?

Supposons qu’il y ait 10 000 transactions. Si elles sont toutes exécutées une par une sur L1, alors L1 devra exécuter 10 000 fois. Mais si l’on procède autrement — exécuter ces 10 000 transactions ailleurs, puis publier sur L1 uniquement « les données de ce lot de transactions » et « le résultat après exécution » — L1 n’aura plus besoin de répéter ces 10 000 exécutions ; il lui suffira de recevoir ce lot de données et d’enregistrer ce résultat.

C’est là le vrai sens de « 10 000 compressées en une seule ». Il ne s’agit pas de supprimer des informations ni de les compresser sans perte, mais de regrouper la charge de vérification de 10 000 transactions en un seul lot, faisant passer L1 de « ouvrier exécutant une par une » à « partie de règlement qui vérifie les résultats ».

Il faut souligner que la baisse des coûts ne vient pas de la réduction du fichier de données, mais du changement de ce que L1 doit faire. Il n’a plus besoin d’exécuter 10 000 calculs ; il supporte principalement le coût de publication de ce lot de données. Cela explique aussi pourquoi cette approche peut à la fois maintenir des coûts plus faibles et une sécurité élevée : le travail d’exécution a été déplacé, mais le règlement reste sur Ethereum.

Le cœur d’un Rollup n’est pas la compression, mais le transfert de l’exécution

Une fois l’idée ci-dessus comprise, la structure de base d’un Rollup devient claire.

Un Rollup est une chaîne qui fonctionne en dehors d’Ethereum et constitue un type de couche 2 (L2). Les utilisateurs émettent normalement leurs transactions sur cette chaîne Rollup, plutôt que d’opérer directement sur le réseau principal. Ces transactions sont reçues par un acteur chargé de l’ordonnancement et de l’exécution — généralement appelé séquenceur (sequencer) ou opérateur (operator). Il ordonne les transactions, les exécute, puis regroupe les transactions d’une certaine période en un lot.

À ce stade, beaucoup de personnes pensent à tort que, puisque l’exécution se fait hors chaîne, Ethereum ne sait rien. Ce n’est pas le cas.

L’essentiel est que, même si l’exécution a lieu hors chaîne, les résultats et les données de transaction doivent tout de même être publiés sur L1. Concrètement, un Rollup soumet deux choses au contrat Rollup sur Ethereum :

• les données de ce lot de transactions elles-mêmes, ou des informations permettant de les reconstituer ;
• l’engagement sur l’état après exécution, généralement représenté par une nouvelle racine d’état (state root).

La racine d’état peut être comprise comme « un court résumé de l’ensemble des états de comptes actuels ». C’est comme l’empreinte du sommaire d’un livre : vous n’avez pas besoin de recopier tout le livre ; il suffit de retenir cette empreinte pour représenter l’état à un moment donné. Dès que ce lot de transactions modifie les soldes des comptes, la racine d’état change en conséquence.

Alors, comment L1 fait-il pour « croire » ce résultat ? La réponse est : le contrat L1 n’a pas besoin de réexécuter chaque transaction ; il lui suffit de vérifier si l’engagement de ce lot est valide. Selon les différents types de Rollup, la manière de déterminer cette « validité » diffère, et nous y reviendrons en détail plus loin. Mais la logique centrale reste la même : L1 passe d’exécutant à partie de règlement et de vérification.

Une analogie courante est celle des notes de frais : les employés traitent eux-mêmes leurs notes de frais tout en conservant les justificatifs originaux ; le service financier n’a pas besoin de payer à nouveau chaque montant, il lui suffit de vérifier le tableau récapitulatif et, au besoin, de consulter les justificatifs originaux. Cette analogie aide à comprendre le « transfert de l’exécution », mais elle a une limite importante : dans la réalité, le service financier pourrait payer directement par confiance, alors qu’un Rollup ne peut pas dépendre uniquement de la confiance dans le séquenceur. Il doit s’appuyer sur la disponibilité des données et des mécanismes de preuve pour garantir que n’importe qui peut vérifier les résultats. C’est précisément le point que nous allons aborder.

Disponibilité des données : pourquoi cette « unique transaction » doit permettre à tous de vérifier les comptes

Nous arrivons maintenant à l’élément le plus souvent négligé et pourtant le plus crucial de la sécurité d’un Rollup.

Imaginons une situation : un lot ne publie sur L1 qu’un hash, c’est-à-dire une empreinte calculée à partir des données de ce lot de transactions, mais le contenu original des transactions n’est pas du tout rendu public. Que se passe-t-il ?

Les personnes extérieures ne voient qu’une empreinte, mais aucune transaction originale. Cela signifie que personne ne peut reconstruire l’état avant et après l’exécution de ce lot de transactions, et donc personne ne peut vérifier si le résultat soumis par le séquenceur est correct. Le séquenceur pourrait parfaitement modifier l’état en secret hors chaîne, puis ne publier sur L1 que le résumé correspondant, sans que les observateurs extérieurs puissent le détecter.

C’est pourquoi la disponibilité des données est si importante. Elle exige que les données de transaction, ou au moins les informations suffisantes pour reconstituer l’état complet, soient réellement publiées sur L1, afin que quiconque puisse les télécharger, reconstruire l’état et calculer de manière indépendante. Ce que résout la disponibilité des données, ce n’est pas « le résultat est-il correct ? », mais « avez-vous le droit de vérifier le résultat ? »

Une fois les données disponibles, tout ce qui suit peut tenir :

• n’importe qui peut obtenir ce lot de transactions, le rejouer lui-même et voir si la nouvelle racine d’état est correcte ;
• si une erreur est détectée, un litige ou une preuve peut être déclenché ;
• même si le séquenceur veut tricher, les données publiques le feront apparaître au grand jour.

À l’inverse, sans disponibilité des données, que ce soit pour les preuves de fraude ou les preuves de validité, tout peut être vidé de sa substance — si vous ne pouvez même pas obtenir les données originales, comment prouver qu’elles sont fausses ? C’est pourquoi un système qui ne publie que des résumés et pas les données, même doté d’un mécanisme de preuve très sophistiqué, verra sa sécurité considérablement réduite.

Une comparaison technique permet de l’illustrer : si seul un hash est publié, les personnes extérieures ne voient aucune transaction originale ; si les données de transaction originales sont publiées sur L1 en tant que données (par exemple sous forme de calldata ou de blobs), alors n’importe qui peut télécharger ces données et reconstruire l’état. Les différents Rollups peuvent actuellement choisir des modes de publication de données différents, mais la ligne rouge commune est la suivante : il doit y avoir suffisamment de données à l’extérieur pour vérifier, plutôt que de devoir se fier uniquement à la parole de l’opérateur.

Le coût de la disponibilité des données est aussi l’un des coûts L1 qu’un Rollup doit assumer. C’est ce coût qui détermine le plafond de débit, point que nous mentionnerons à nouveau dans la dernière section.

Deux approches : Optimistic Rollup et ZK Rollup

La question devient maintenant : les données sont publiées, et L1 ne veut pas réexécuter toutes les transactions ; comment détermine-t-il alors si ce lot de résultats est correct ? Il existe actuellement principalement deux approches techniques.

Optimistic Rollup : correct par défaut, contesté après coup

L’idée de l’Optimistic Rollup est directe : par défaut, chaque lot de transactions est correct ; le résultat est publié d’abord, sans vérification immédiate. Pour donner à chacun une chance de détecter une erreur, il prévoit une période de contestation (challenge period).

Pendant cette période, toute personne qui découvre une erreur peut soumettre une preuve de fraude (fraud proof), indiquant que le résultat d’exécution d’un lot de transactions ne correspond pas aux données réelles. Si la preuve est acceptée, la transaction erronée est annulée, et les validateurs concernés peuvent subir des pénalités économiques. Si personne ne conteste pendant la période de contestation, la transaction est finalement confirmée.

Cela introduit une caractéristique importante : avant la fin de la période de contestation, la transaction n’est pas réellement irréversible. La durée de la période de contestation n’est pas uniformément fixée pour tout le réseau ; elle est définie par chaque protocole, généralement en jours. Ainsi, lorsque vous voyez une transaction « réussir » sur un Optimistic Rollup, comprenez qu’il peut encore rester un certain temps avant son règlement final.

ZK Rollup : un reçu vérifiable intégré

Le ZK Rollup suit une autre voie. Il ne repose pas sur « quelqu’un signalera-t-il après coup », mais joint une preuve de validité (validity proof) au moment de soumettre le lot. Cette preuve démontre cryptographiquement que : ce lot de transactions est bien parti de l’ancien état correct et a produit le nouvel état correct.

Après réception de la preuve, le contrat L1 peut accepter ce lot de transactions dès lors qu’il vérifie que la preuve est valide. Comme la preuve est établie au moment même où elle est vérifiée, le ZK Rollup n’a pas besoin d’une longue période de contestation et peut obtenir une finalité plus rapide.

La différence entre ces deux approches peut se comprendre ainsi : l’Optimistic Rollup ressemble davantage à un audit après coup, laissant un certain temps aux problèmes pour se manifester ; le ZK Rollup ressemble davantage à chaque lot de transactions accompagné d’un reçu cryptographique vérifiable immédiatement. Il faut noter que cette analogie ne sert qu’à distinguer les deux modes de vérification et ne remplace pas la compréhension de la disponibilité des données ni du mécanisme de preuve lui-même — quelle que soit l’approche, la disponibilité des données ne peut pas être omise.

Les compromis entre les deux approches sont également clairs : l’approche Optimistic dépend de périodes de contestation et d’incitations économiques, sa structure est relativement simple, mais sa finalité est plus lente ; l’approche ZK offre une finalité plus rapide, mais exige davantage du système de preuve, et la génération des preuves elle-même est plus complexe. Mais l’objectif des deux est identique : permettre à L1 de confirmer si le résultat est correct sans réexécuter toutes les transactions.

Le parcours complet, de la transaction utilisateur au règlement sur L1

En reliant les mécanismes précédents, on peut voir le processus complet, depuis le clic d’envoi de l’utilisateur jusqu’à la fixation finale de la transaction sur Ethereum.

1. L’utilisateur signe et soumet une transaction sur L2. Cette transaction n’est pas envoyée au réseau principal Ethereum, mais à cette chaîne Rollup, la signature étant réalisée par le portefeuille.
2. Le séquenceur reçoit et ordonne les transactions. Il décide dans quel ordre ces transactions sont traitées, puis les regroupe dans un lot.
3. Le séquenceur exécute les transactions et met à jour l’état local. Une fois l’exécution terminée, il obtient la nouvelle racine d’état ainsi que les données correspondant à ce lot de transactions.
4. Les données du lot sont soumises au contrat Rollup sur L1. L1 enregistre alors ce lot de données (ce qui satisfait la disponibilité des données) et met à jour l’engagement sur le résumé du résultat.
5. Selon l’approche, l’étape de règlement commence. L’Optimistic Rollup attend la fin de la période de contestation ; le ZK Rollup soumet une preuve de validité et attend la validation par le contrat L1.
6. La confirmation finale au niveau L1 est achevée. Ce n’est qu’à ce moment que la transaction obtient véritablement la sécurité offerte par Ethereum.

Ce parcours explique pourquoi « exécuter sur L2 » et « confirmer finalement sur L1 » sont deux choses différentes. Le retour instantané que vous voyez sur un Rollup provient de l’exécution par le séquenceur ; ce qui la rend réellement irréversible, c’est son règlement sur L1. Le décalage temporel entre les deux est particulièrement visible sur les Optimistic Rollups.

Les limites d’un Rollup et les malentendus courants

Les Rollups améliorent réellement le débit utilisable et réduisent les coûts, mais ils ne sont pas magiques. Comprendre leurs limites permet de se faire des attentes correctes.

Premièrement, un Rollup ne peut pas scaler à l’infini. Il doit toujours publier des données sur L1 et assumer les coûts de disponibilité des données et de vérification de L1. Cette bande passante et ces frais constituent le plafond de débit. Quelle que soit l’efficacité du mécanisme de preuve, tant que les données doivent encore être publiées sur L1, le système restera contraint par la capacité de données de L1.

Deuxièmement, Rollup n’est pas synonyme de toutes les couches 2. La couche 2 est un terme générique pour une grande catégorie de solutions de scalabilité. Le Rollup est l’une des approches dont la sécurité se rapproche le plus de L1, et sa caractéristique clé est justement de « publier les données sur L1 ». D’autres solutions comme les canaux d’état et les sidechains ont des modèles de sécurité différents, et certaines ne dépendent pas de la publication des données sur L1. Considérer « toutes les L2 comme des Rollups » conduit à mal estimer leurs hypothèses de confiance.

Troisièmement, l’exécution sur un Rollup n’équivaut pas à une confirmation finale immédiate. En particulier pour les Optimistic Rollups, les transactions situées dans la période de contestation peuvent encore être annulées. Prendre un « succès » sur L2 pour une irréversibilité équivalente à celle de L1 est un malentendu courant.

Quatrièmement, la sécurité d’un Rollup est ancrée dans L1, mais elle est aussi affectée par L1. Si la publication des données de L1 pose problème, ou si l’implémentation du contrat Rollup elle-même présente des défauts, la sécurité s’en trouvera également affectée. Un Rollup ancre sa sécurité dans Ethereum, mais cela ne signifie pas qu’il acquiert automatiquement toutes les propriétés d’Ethereum.

Cinquièmement, un Rollup ne cache pas les données. Au contraire, sa sécurité dépend de la disponibilité publique des données. Un système qui dissimule complètement les données de transaction et ne publie que des résumés ne dispose pas, à strictement parler, des garanties de sécurité requises par un Rollup.

Revenons à la question initiale : comment 10 000 transactions sont-elles compressées en une seule par un Rollup ?

La réponse n’est pas qu’il compresse les données comme un zip, mais qu’il déplace l’exécution des transactions hors chaîne, publie les données de transaction et les engagements de résultat sur L1, et fait passer L1 du rôle d’exécutant transaction par transaction à celui de partie de règlement et de vérification. L1 n’a plus besoin de répéter 10 000 exécutions, mais il conserve toujours la capacité de vérifier les résultats grâce à la disponibilité des données et aux mécanismes de preuve.

La sécurité d’un Rollup ne vient pas de la confiance accordée à un séquenceur, mais du fait qu’il permet à chacun de consulter les données et de vérifier les résultats. Et précisément parce qu’il doit publier ces données sur L1, sa capacité de scalabilité a toujours une limite supérieure — ce n’est pas un défaut, mais le prix clair qu’il paie en échangeant de la sécurité contre de l’efficacité.