Beaucoup de personnes, lorsqu\u2019elles entendent parler de Rollup pour la premi\u00e8re fois, rencontrent une affirmation contre-intuitive : un Rollup peut \u00ab compresser 10 000 transactions en une seule \u00bb.<\/p>\n\n\n\n
Cette phrase donne l\u2019impression qu\u2019il s\u2019agit de compression de fichiers \u2014 comme si l\u2019on glissait un gros fichier zip dans une petite enveloppe avant de l\u2019envoyer sur Ethereum. Mais si c\u2019\u00e9tait vraiment le cas, un probl\u00e8me se poserait : si un Rollup ne faisait que r\u00e9duire les donn\u00e9es, pourquoi Ethereum croirait-il que ces transactions ont r\u00e9ellement eu lieu et que le r\u00e9sultat est correct ? Un fichier compress\u00e9, en lui-m\u00eame, ne rend pas les transactions dignes de confiance.<\/p>\n\n\n\n
Pour comprendre un Rollup, l\u2019essentiel n\u2019est pas de se demander \u00ab comment les donn\u00e9es deviennent plus petites \u00bb, mais de se demander \u00ab quel travail Ethereum effectuait \u00e0 l\u2019origine, et o\u00f9 le Rollup a d\u00e9plac\u00e9 ce travail \u00bb. Cet article suivra cette question \u00e9tape par \u00e9tape : pourquoi Ethereum ne peut pas traiter davantage de transactions, ce que fait r\u00e9ellement un Rollup, d\u2019o\u00f9 vient sa s\u00e9curit\u00e9, et pourquoi il ne permet toujours pas une scalabilit\u00e9 illimit\u00e9e.<\/p>\n\n\n\n
Commen\u00e7ons par regarder ce qu\u2019Ethereum fait lui-m\u00eame.<\/p>\n\n\n\n
Ethereum est une blockchain de couche 1, souvent appel\u00e9e L1. Sur L1, chaque transaction doit \u00eatre v\u00e9rifi\u00e9e et ex\u00e9cut\u00e9e par un grand nombre de n\u0153uds du r\u00e9seau, et l\u2019\u00e9tat des comptes \u00e0 l\u2019\u00e9chelle du r\u00e9seau doit \u00eatre mis \u00e0 jour. Ici, \u00ab ex\u00e9cuter \u00bb ne signifie pas simplement enregistrer quelque chose : il faut r\u00e9ellement faire tourner la logique de la transaction. Combien de jetons ont \u00e9t\u00e9 transf\u00e9r\u00e9s, quel contrat a \u00e9t\u00e9 appel\u00e9, comment les soldes changent \u2014 tout cela doit \u00eatre calcul\u00e9.<\/p>\n\n\n\n
Cette conception est la source de la s\u00e9curit\u00e9 d\u2019Ethereum, mais c\u2019est aussi son goulot d\u2019\u00e9tranglement. Plus il y a de transactions, plus le travail que l\u2019ensemble du r\u00e9seau doit r\u00e9p\u00e9ter est important.<\/strong> Chaque transaction doit \u00eatre ex\u00e9cut\u00e9e une fois par des milliers de n\u0153uds, et le co\u00fbt augmente donc lin\u00e9airement avec le nombre de transactions. En cas de congestion du r\u00e9seau, les utilisateurs ne peuvent qu\u2019augmenter sans cesse les frais pour \u00eatre trait\u00e9s en premier, ce qui rend les transactions \u00e0 la fois lentes et co\u00fbteuses.<\/p>\n\n\n\n Une id\u00e9e naturelle est alors apparue : ne pourrait-on pas \u00e9viter de placer chaque transaction sur L1 et de l\u2019ex\u00e9cuter une par une ?<\/p>\n\n\n\n Supposons qu\u2019il y ait 10 000 transactions. Si elles sont toutes ex\u00e9cut\u00e9es une par une sur L1, alors L1 devra ex\u00e9cuter 10 000 fois. Mais si l\u2019on proc\u00e8de autrement \u2014 ex\u00e9cuter ces 10 000 transactions ailleurs, puis publier sur L1 uniquement \u00ab les donn\u00e9es de ce lot de transactions \u00bb et \u00ab le r\u00e9sultat apr\u00e8s ex\u00e9cution \u00bb \u2014 L1 n\u2019aura plus besoin de r\u00e9p\u00e9ter ces 10 000 ex\u00e9cutions ; il lui suffira de recevoir ce lot de donn\u00e9es et d\u2019enregistrer ce r\u00e9sultat.<\/p>\n\n\n\n C\u2019est l\u00e0 le vrai sens de \u00ab 10 000 compress\u00e9es en une seule \u00bb. Il ne s\u2019agit pas de supprimer des informations ni de les compresser sans perte, mais de regrouper la charge de v\u00e9rification de 10 000 transactions en un seul lot<\/strong>, faisant passer L1 de \u00ab ouvrier ex\u00e9cutant une par une \u00bb \u00e0 \u00ab partie de r\u00e8glement qui v\u00e9rifie les r\u00e9sultats \u00bb.<\/p>\n\n\n\n Il faut souligner que la baisse des co\u00fbts ne vient pas de la r\u00e9duction du fichier de donn\u00e9es, mais du changement de ce que L1 doit faire. Il n\u2019a plus besoin d\u2019ex\u00e9cuter 10 000 calculs ; il supporte principalement le co\u00fbt de publication de ce lot de donn\u00e9es. Cela explique aussi pourquoi cette approche peut \u00e0 la fois maintenir des co\u00fbts plus faibles et une s\u00e9curit\u00e9 \u00e9lev\u00e9e : le travail d\u2019ex\u00e9cution a \u00e9t\u00e9 d\u00e9plac\u00e9, mais le r\u00e8glement reste sur Ethereum.<\/p>\n\n\n\n Une fois l\u2019id\u00e9e ci-dessus comprise, la structure de base d\u2019un Rollup devient claire.<\/p>\n\n\n\n Un Rollup est une cha\u00eene qui fonctionne en dehors d\u2019Ethereum et constitue un type de couche 2 (L2). Les utilisateurs \u00e9mettent normalement leurs transactions sur cette cha\u00eene Rollup, plut\u00f4t que d\u2019op\u00e9rer directement sur le r\u00e9seau principal. Ces transactions sont re\u00e7ues par un acteur charg\u00e9 de l\u2019ordonnancement et de l\u2019ex\u00e9cution \u2014 g\u00e9n\u00e9ralement appel\u00e9 s\u00e9quenceur (sequencer) ou op\u00e9rateur (operator). Il ordonne les transactions, les ex\u00e9cute, puis regroupe les transactions d\u2019une certaine p\u00e9riode en un lot.<\/p>\n\n\n\n \u00c0 ce stade, beaucoup de personnes pensent \u00e0 tort que, puisque l\u2019ex\u00e9cution se fait hors cha\u00eene, Ethereum ne sait rien. Ce n\u2019est pas le cas.<\/p>\n\n\n\n L\u2019essentiel est que, m\u00eame si l\u2019ex\u00e9cution a lieu hors cha\u00eene, les r\u00e9sultats et les donn\u00e9es de transaction doivent tout de m\u00eame \u00eatre publi\u00e9s sur L1.<\/strong> Concr\u00e8tement, un Rollup soumet deux choses au contrat Rollup sur Ethereum :<\/p>\n\n\n\n La racine d\u2019\u00e9tat peut \u00eatre comprise comme \u00ab un court r\u00e9sum\u00e9 de l\u2019ensemble des \u00e9tats de comptes actuels \u00bb. C\u2019est comme l\u2019empreinte du sommaire d\u2019un livre : vous n\u2019avez pas besoin de recopier tout le livre ; il suffit de retenir cette empreinte pour repr\u00e9senter l\u2019\u00e9tat \u00e0 un moment donn\u00e9. D\u00e8s que ce lot de transactions modifie les soldes des comptes, la racine d\u2019\u00e9tat change en cons\u00e9quence.<\/p>\n\n\n\n Alors, comment L1 fait-il pour \u00ab croire \u00bb ce r\u00e9sultat ? La r\u00e9ponse est : le contrat L1 n\u2019a pas besoin de r\u00e9ex\u00e9cuter chaque transaction ; il lui suffit de v\u00e9rifier si l\u2019engagement de ce lot est valide.<\/strong> Selon les diff\u00e9rents types de Rollup, la mani\u00e8re de d\u00e9terminer cette \u00ab validit\u00e9 \u00bb diff\u00e8re, et nous y reviendrons en d\u00e9tail plus loin. Mais la logique centrale reste la m\u00eame : L1 passe d\u2019ex\u00e9cutant \u00e0 partie de r\u00e8glement et de v\u00e9rification.<\/p>\n\n\n\n Une analogie courante est celle des notes de frais : les employ\u00e9s traitent eux-m\u00eames leurs notes de frais tout en conservant les justificatifs originaux ; le service financier n\u2019a pas besoin de payer \u00e0 nouveau chaque montant, il lui suffit de v\u00e9rifier le tableau r\u00e9capitulatif et, au besoin, de consulter les justificatifs originaux. Cette analogie aide \u00e0 comprendre le \u00ab transfert de l\u2019ex\u00e9cution \u00bb, mais elle a une limite importante : dans la r\u00e9alit\u00e9, le service financier pourrait payer directement par confiance, alors qu\u2019un Rollup ne peut pas d\u00e9pendre uniquement de la confiance dans le s\u00e9quenceur. Il doit s\u2019appuyer sur la disponibilit\u00e9 des donn\u00e9es et des m\u00e9canismes de preuve pour garantir que n\u2019importe qui peut v\u00e9rifier les r\u00e9sultats. C\u2019est pr\u00e9cis\u00e9ment le point que nous allons aborder.<\/p>\n\n\n\n Nous arrivons maintenant \u00e0 l\u2019\u00e9l\u00e9ment le plus souvent n\u00e9glig\u00e9 et pourtant le plus crucial de la s\u00e9curit\u00e9 d\u2019un Rollup.<\/p>\n\n\n\n Imaginons une situation : un lot ne publie sur L1 qu\u2019un hash, c\u2019est-\u00e0-dire une empreinte calcul\u00e9e \u00e0 partir des donn\u00e9es de ce lot de transactions, mais le contenu original des transactions n\u2019est pas du tout rendu public. Que se passe-t-il ?<\/p>\n\n\n\n Les personnes ext\u00e9rieures ne voient qu\u2019une empreinte, mais aucune transaction originale. Cela signifie que personne ne peut reconstruire l\u2019\u00e9tat avant et apr\u00e8s l\u2019ex\u00e9cution de ce lot de transactions, et donc personne ne peut v\u00e9rifier si le r\u00e9sultat soumis par le s\u00e9quenceur est correct.<\/strong> Le s\u00e9quenceur pourrait parfaitement modifier l\u2019\u00e9tat en secret hors cha\u00eene, puis ne publier sur L1 que le r\u00e9sum\u00e9 correspondant, sans que les observateurs ext\u00e9rieurs puissent le d\u00e9tecter.<\/p>\n\n\n\n C\u2019est pourquoi la disponibilit\u00e9 des donn\u00e9es est si importante. Elle exige que les donn\u00e9es de transaction, ou au moins les informations suffisantes pour reconstituer l\u2019\u00e9tat complet, soient r\u00e9ellement publi\u00e9es sur L1, afin que quiconque puisse les t\u00e9l\u00e9charger, reconstruire l\u2019\u00e9tat et calculer de mani\u00e8re ind\u00e9pendante. Ce que r\u00e9sout la disponibilit\u00e9 des donn\u00e9es, ce n\u2019est pas \u00ab le r\u00e9sultat est-il correct ? \u00bb, mais \u00ab avez-vous le droit de v\u00e9rifier le r\u00e9sultat ? \u00bb<\/p>\n\n\n\n Une fois les donn\u00e9es disponibles, tout ce qui suit peut tenir :<\/p>\n\n\n\n \u00c0 l\u2019inverse, sans disponibilit\u00e9 des donn\u00e9es, que ce soit pour les preuves de fraude ou les preuves de validit\u00e9, tout peut \u00eatre vid\u00e9 de sa substance \u2014 si vous ne pouvez m\u00eame pas obtenir les donn\u00e9es originales, comment prouver qu\u2019elles sont fausses ?<\/strong> C\u2019est pourquoi un syst\u00e8me qui ne publie que des r\u00e9sum\u00e9s et pas les donn\u00e9es, m\u00eame dot\u00e9 d\u2019un m\u00e9canisme de preuve tr\u00e8s sophistiqu\u00e9, verra sa s\u00e9curit\u00e9 consid\u00e9rablement r\u00e9duite.<\/p>\n\n\n\n Une comparaison technique permet de l\u2019illustrer : si seul un hash est publi\u00e9, les personnes ext\u00e9rieures ne voient aucune transaction originale ; si les donn\u00e9es de transaction originales sont publi\u00e9es sur L1 en tant que donn\u00e9es (par exemple sous forme de calldata ou de blobs), alors n\u2019importe qui peut t\u00e9l\u00e9charger ces donn\u00e9es et reconstruire l\u2019\u00e9tat. Les diff\u00e9rents Rollups peuvent actuellement choisir des modes de publication de donn\u00e9es diff\u00e9rents, mais la ligne rouge commune est la suivante : il doit y avoir suffisamment de donn\u00e9es \u00e0 l\u2019ext\u00e9rieur pour v\u00e9rifier, plut\u00f4t que de devoir se fier uniquement \u00e0 la parole de l\u2019op\u00e9rateur.<\/strong><\/p>\n\n\n\n Le co\u00fbt de la disponibilit\u00e9 des donn\u00e9es est aussi l\u2019un des co\u00fbts L1 qu\u2019un Rollup doit assumer. C\u2019est ce co\u00fbt qui d\u00e9termine le plafond de d\u00e9bit, point que nous mentionnerons \u00e0 nouveau dans la derni\u00e8re section.<\/p>\n\n\n\n La question devient maintenant : les donn\u00e9es sont publi\u00e9es, et L1 ne veut pas r\u00e9ex\u00e9cuter toutes les transactions ; comment d\u00e9termine-t-il alors si ce lot de r\u00e9sultats est correct ? Il existe actuellement principalement deux approches techniques.<\/p>\n\n\n\n L\u2019id\u00e9e de l\u2019Optimistic Rollup est directe : par d\u00e9faut, chaque lot de transactions est correct<\/strong> ; le r\u00e9sultat est publi\u00e9 d\u2019abord, sans v\u00e9rification imm\u00e9diate. Pour donner \u00e0 chacun une chance de d\u00e9tecter une erreur, il pr\u00e9voit une p\u00e9riode de contestation (challenge period).<\/p>\n\n\n\n Pendant cette p\u00e9riode, toute personne qui d\u00e9couvre une erreur peut soumettre une preuve de fraude (fraud proof), indiquant que le r\u00e9sultat d\u2019ex\u00e9cution d\u2019un lot de transactions ne correspond pas aux donn\u00e9es r\u00e9elles. Si la preuve est accept\u00e9e, la transaction erron\u00e9e est annul\u00e9e, et les validateurs concern\u00e9s peuvent subir des p\u00e9nalit\u00e9s \u00e9conomiques. Si personne ne conteste pendant la p\u00e9riode de contestation, la transaction est finalement confirm\u00e9e.<\/p>\n\n\n\n Cela introduit une caract\u00e9ristique importante : avant la fin de la p\u00e9riode de contestation, la transaction n\u2019est pas r\u00e9ellement irr\u00e9versible.<\/strong> La dur\u00e9e de la p\u00e9riode de contestation n\u2019est pas uniform\u00e9ment fix\u00e9e pour tout le r\u00e9seau ; elle est d\u00e9finie par chaque protocole, g\u00e9n\u00e9ralement en jours. Ainsi, lorsque vous voyez une transaction \u00ab r\u00e9ussir \u00bb sur un Optimistic Rollup, comprenez qu\u2019il peut encore rester un certain temps avant son r\u00e8glement final.<\/p>\n\n\n\n Le ZK Rollup suit une autre voie. Il ne repose pas sur \u00ab quelqu\u2019un signalera-t-il apr\u00e8s coup \u00bb, mais joint une preuve de validit\u00e9 (validity proof) au moment de soumettre le lot. Cette preuve d\u00e9montre cryptographiquement que : ce lot de transactions est bien parti de l\u2019ancien \u00e9tat correct et a produit le nouvel \u00e9tat correct.<\/strong><\/p>\n\n\n\n Apr\u00e8s r\u00e9ception de la preuve, le contrat L1 peut accepter ce lot de transactions d\u00e8s lors qu\u2019il v\u00e9rifie que la preuve est valide. Comme la preuve est \u00e9tablie au moment m\u00eame o\u00f9 elle est v\u00e9rifi\u00e9e, le ZK Rollup n\u2019a pas besoin d\u2019une longue p\u00e9riode de contestation et peut obtenir une finalit\u00e9 plus rapide.<\/p>\n\n\n\n La diff\u00e9rence entre ces deux approches peut se comprendre ainsi : l\u2019Optimistic Rollup ressemble davantage \u00e0 un audit apr\u00e8s coup, laissant un certain temps aux probl\u00e8mes pour se manifester ; le ZK Rollup ressemble davantage \u00e0 chaque lot de transactions accompagn\u00e9 d\u2019un re\u00e7u cryptographique v\u00e9rifiable imm\u00e9diatement. Il faut noter que cette analogie ne sert qu\u2019\u00e0 distinguer les deux modes de v\u00e9rification et ne remplace pas la compr\u00e9hension de la disponibilit\u00e9 des donn\u00e9es ni du m\u00e9canisme de preuve lui-m\u00eame \u2014 quelle que soit l\u2019approche, la disponibilit\u00e9 des donn\u00e9es ne peut pas \u00eatre omise.<\/p>\n\n\n\n Les compromis entre les deux approches sont \u00e9galement clairs : l\u2019approche Optimistic d\u00e9pend de p\u00e9riodes de contestation et d\u2019incitations \u00e9conomiques, sa structure est relativement simple, mais sa finalit\u00e9 est plus lente ; l\u2019approche ZK offre une finalit\u00e9 plus rapide, mais exige davantage du syst\u00e8me de preuve, et la g\u00e9n\u00e9ration des preuves elle-m\u00eame est plus complexe. Mais l\u2019objectif des deux est identique : permettre \u00e0 L1 de confirmer si le r\u00e9sultat est correct sans r\u00e9ex\u00e9cuter toutes les transactions.<\/strong><\/p>\n\n\n\n En reliant les m\u00e9canismes pr\u00e9c\u00e9dents, on peut voir le processus complet, depuis le clic d\u2019envoi de l\u2019utilisateur jusqu\u2019\u00e0 la fixation finale de la transaction sur Ethereum.<\/p>\n\n\n\n Ce parcours explique pourquoi \u00ab ex\u00e9cuter sur L2 \u00bb et \u00ab confirmer finalement sur L1 \u00bb sont deux choses diff\u00e9rentes. Le retour instantan\u00e9 que vous voyez sur un Rollup provient de l\u2019ex\u00e9cution par le s\u00e9quenceur ; ce qui la rend r\u00e9ellement irr\u00e9versible, c\u2019est son r\u00e8glement sur L1. Le d\u00e9calage temporel entre les deux est particuli\u00e8rement visible sur les Optimistic Rollups.<\/p>\n\n\n\n Les Rollups am\u00e9liorent r\u00e9ellement le d\u00e9bit utilisable et r\u00e9duisent les co\u00fbts, mais ils ne sont pas magiques. Comprendre leurs limites permet de se faire des attentes correctes.<\/p>\n\n\n\n Premi\u00e8rement, un Rollup ne peut pas scaler \u00e0 l\u2019infini.<\/strong> Il doit toujours publier des donn\u00e9es sur L1 et assumer les co\u00fbts de disponibilit\u00e9 des donn\u00e9es et de v\u00e9rification de L1. Cette bande passante et ces frais constituent le plafond de d\u00e9bit. Quelle que soit l\u2019efficacit\u00e9 du m\u00e9canisme de preuve, tant que les donn\u00e9es doivent encore \u00eatre publi\u00e9es sur L1, le syst\u00e8me restera contraint par la capacit\u00e9 de donn\u00e9es de L1.<\/p>\n\n\n\n Deuxi\u00e8mement, Rollup n\u2019est pas synonyme de toutes les couches 2.<\/strong> La couche 2 est un terme g\u00e9n\u00e9rique pour une grande cat\u00e9gorie de solutions de scalabilit\u00e9. Le Rollup est l\u2019une des approches dont la s\u00e9curit\u00e9 se rapproche le plus de L1, et sa caract\u00e9ristique cl\u00e9 est justement de \u00ab publier les donn\u00e9es sur L1 \u00bb. D\u2019autres solutions comme les canaux d\u2019\u00e9tat et les sidechains ont des mod\u00e8les de s\u00e9curit\u00e9 diff\u00e9rents, et certaines ne d\u00e9pendent pas de la publication des donn\u00e9es sur L1. Consid\u00e9rer \u00ab toutes les L2 comme des Rollups \u00bb conduit \u00e0 mal estimer leurs hypoth\u00e8ses de confiance.<\/p>\n\n\n\n Troisi\u00e8mement, l\u2019ex\u00e9cution sur un Rollup n\u2019\u00e9quivaut pas \u00e0 une confirmation finale imm\u00e9diate.<\/strong> En particulier pour les Optimistic Rollups, les transactions situ\u00e9es dans la p\u00e9riode de contestation peuvent encore \u00eatre annul\u00e9es. Prendre un \u00ab succ\u00e8s \u00bb sur L2 pour une irr\u00e9versibilit\u00e9 \u00e9quivalente \u00e0 celle de L1 est un malentendu courant.<\/p>\n\n\n\n Quatri\u00e8mement, la s\u00e9curit\u00e9 d\u2019un Rollup est ancr\u00e9e dans L1, mais elle est aussi affect\u00e9e par L1.<\/strong> Si la publication des donn\u00e9es de L1 pose probl\u00e8me, ou si l\u2019impl\u00e9mentation du contrat Rollup elle-m\u00eame pr\u00e9sente des d\u00e9fauts, la s\u00e9curit\u00e9 s\u2019en trouvera \u00e9galement affect\u00e9e. Un Rollup ancre sa s\u00e9curit\u00e9 dans Ethereum, mais cela ne signifie pas qu\u2019il acquiert automatiquement toutes les propri\u00e9t\u00e9s d\u2019Ethereum.<\/p>\n\n\n\n Cinqui\u00e8mement, un Rollup ne cache pas les donn\u00e9es.<\/strong> Au contraire, sa s\u00e9curit\u00e9 d\u00e9pend de la disponibilit\u00e9 publique des donn\u00e9es. Un syst\u00e8me qui dissimule compl\u00e8tement les donn\u00e9es de transaction et ne publie que des r\u00e9sum\u00e9s ne dispose pas, \u00e0 strictement parler, des garanties de s\u00e9curit\u00e9 requises par un Rollup.<\/p>\n\n\n\n Revenons \u00e0 la question initiale : comment 10 000 transactions sont-elles compress\u00e9es en une seule par un Rollup ?<\/p>\n\n\n\n La r\u00e9ponse n\u2019est pas qu\u2019il compresse les donn\u00e9es comme un zip, mais qu\u2019il d\u00e9place l\u2019ex\u00e9cution des transactions hors cha\u00eene, publie les donn\u00e9es de transaction et les engagements de r\u00e9sultat sur L1, et fait passer L1 du r\u00f4le d\u2019ex\u00e9cutant transaction par transaction \u00e0 celui de partie de r\u00e8glement et de v\u00e9rification<\/strong>. L1 n\u2019a plus besoin de r\u00e9p\u00e9ter 10 000 ex\u00e9cutions, mais il conserve toujours la capacit\u00e9 de v\u00e9rifier les r\u00e9sultats gr\u00e2ce \u00e0 la disponibilit\u00e9 des donn\u00e9es et aux m\u00e9canismes de preuve.<\/p>\n\n\n\n La s\u00e9curit\u00e9 d\u2019un Rollup ne vient pas de la confiance accord\u00e9e \u00e0 un s\u00e9quenceur, mais du fait qu\u2019il permet \u00e0 chacun de consulter les donn\u00e9es et de v\u00e9rifier les r\u00e9sultats. Et pr\u00e9cis\u00e9ment parce qu\u2019il doit publier ces donn\u00e9es sur L1, sa capacit\u00e9 de scalabilit\u00e9 a toujours une limite sup\u00e9rieure \u2014 ce n\u2019est pas un d\u00e9faut, mais le prix clair qu\u2019il paie en \u00e9changeant de la s\u00e9curit\u00e9 contre de l\u2019efficacit\u00e9.<\/p>\n","protected":false},"excerpt":{"rendered":" Beaucoup de personnes, lorsqu\u2019elles entendent parler de Rollup pour la […]<\/p>\n","protected":false},"author":1,"featured_media":12448,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[102],"tags":[],"class_list":["post-12479","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-crypto-basics"],"yoast_head":"\nLe c\u0153ur d\u2019un Rollup n\u2019est pas la compression, mais le transfert de l\u2019ex\u00e9cution<\/h2>\n\n\n\n
\n
Disponibilit\u00e9 des donn\u00e9es : pourquoi cette \u00ab unique transaction \u00bb doit permettre \u00e0 tous de v\u00e9rifier les comptes<\/h2>\n\n\n\n
\n
Deux approches : Optimistic Rollup et ZK Rollup<\/h2>\n\n\n\n
Optimistic Rollup : correct par d\u00e9faut, contest\u00e9 apr\u00e8s coup<\/h3>\n\n\n\n
ZK Rollup : un re\u00e7u v\u00e9rifiable int\u00e9gr\u00e9<\/h3>\n\n\n\n
Le parcours complet, de la transaction utilisateur au r\u00e8glement sur L1<\/h2>\n\n\n\n
\n
Les limites d\u2019un Rollup et les malentendus courants<\/h2>\n\n\n\n