Article de Vitalik Buterin publié sur https://vitalik.ca/general/2021/01/05/rollup.html, traduit par Jean Zundel.

Depuis longtemps, les couches de niveau 2 sont vues comme un moyen de passer à l’échelle, pour augmenter le nombre de transactions par seconde limitant naturellement une blockchain décentralisée comme Ethereum. Les rollups, dont le nom évoque les rouleaux de pièces que l’on peut commodément transporter et stocker, sont rapidement devenus la technologie la plus en vue. Après un bref survol des solutions développées auparavant, Plasma et les channels, Vitalik Buterin expose ici les principes fondamentaux des deux principaux types de rollups ainsi que les avantages et les inconvénients de chacun.

Les rollups font fureur dans la communauté Ethereum, et sont en passe de devenir la solution clé pour le scaling, le passage à l’échelle d’Ethereum dans un avenir proche. Mais qu’est-ce exactement que cette technologie, que peut-on en attendre et comment l’utiliser ? Cet article tentera de répondre à certaines de ces questions.

Contexte : qu’est-ce que le passage à l’échelle des couches 1 et 2 ?

Il existe deux manières de passer à l’échelle l’écosystème d’une blockchain. Premièrement, on peut faire en sorte que la blockchain elle-même ait une capacité de transactions plus élevée. Le principal inconvénient de cette technique est que les blockchains comportant de « plus grands blocs » sont intrinsèquement plus difficiles à vérifier et risquent de devenir plus centralisées. Pour éviter ce risque, les développeurs peuvent soit augmenter l’efficacité du logiciel client, soit, de manière plus durable, utiliser des techniques telles que le sharding pour permettre de répartir le travail de construction et de vérification de la chaîne sur de nombreux nœuds ; le projet connu sous le nom de « eth2 » est actuellement en train de mettre en œuvre cette solution pour Ethereum.

Deuxièmement, on peut changer la façon dont on utilise la blockchain. Au lieu de placer directement toute l’activité sur la blockchain, les utilisateurs effectuent la majeure partie de leur activité hors chaîne dans un protocole dit de « niveau 2 ». Il existe un smart contract ou contrat autonome sur la chaîne, qui n’a que deux tâches : traiter les dépôts et les retraits, et vérifier les preuves que tout ce qui se passe hors de la chaîne respecte les règles. Il existe plusieurs manières de faire ces preuves, mais elles ont toutes en commun le fait que la vérification des preuves sur la chaîne est beaucoup moins coûteuse que le calcul originel hors chaîne.

Comparaison : state channels, Plasma et rollups

Les trois principaux types de mise à l’échelle par une couche de niveau 2 sont les state channels ou canaux d’état, Plasma et les rollups. Il s’agit de trois paradigmes différents, avec des avantages et des inconvénients différents, et à ce stade, nous sommes assez confiants dans le fait que toutes les mises à l’échelle de la couche 2 entrent à peu près dans ces trois catégories (bien que des controverses de dénomination existent à la marge, voir par exemple «validium»).

Comment fonctionnent les channels ?

Voir aussi : https://www.jeffcoleman.ca/state-channels et statechannels.org

Imaginez qu’Alice offre une connexion Internet à Bob, en échange de quoi ce dernier lui verse 0,001 dollar par mégaoctet. Au lieu d’effectuer une transaction pour chaque paiement, Alice et Bob utilisent le système de niveau 2 suivant.

D’abord, Bob met 1$ (ou l’équivalent en ETH ou en monnaie stable) dans un contrat autonome. Pour effectuer son premier paiement à Alice, Bob signe un «ticket» (un message hors chaîne), qui dit simplement «0,001$», et l’envoie à Alice. Pour effectuer son deuxième paiement, Bob signe un autre ticket qui indique «0,002$» et l’envoie à Alice. Et ainsi de suite pour autant de paiements que nécessaire. Lorsque Alice et Bob ont terminé leurs transactions, Alice peut publier le ticket de plus grande valeur à la chaîne, enveloppé dans une autre signature de sa part. Le contrat vérifie les signatures d’Alice et de Bob, verse à Alice le montant indiqué sur le ticket de Bob et renvoie le reste à Bob. Si Alice ne veut pas fermer le channel (pour cause de malveillance ou de défaillance technique), Bob peut déclencher une période de retrait (par exemple, 7 jours) ; si Alice ne fournit pas de ticket dans ce délai, Bob est alors remboursé de tout son argent.

Cette technique est puissante : elle peut être ajustée pour gérer les paiements bidirectionnels, les relations par contrat autonome (par exemple, Alice et Bob passent un contrat financier à l’intérieur du canal) et la composition (si Alice et Bob ont un canal ouvert, tout comme Bob et Charlie, Alice peut interagir sans confiance avec Charlie). Mais les channels ont leurs limites. Les channels ne peuvent pas être utilisés pour envoyer des fonds hors chaîne à des personnes qui ne sont pas encore des participants. Les channels ne peuvent pas être utilisés pour représenter des objets qui n’ont pas de propriétaire logique clair (par exemple, Uniswap). Et les channels, surtout s’ils sont utilisés pour faire des choses plus complexes que de simples paiements récurrents, nécessitent de bloquer un capital important.

Comment Plasma fonctionne-t-il ?

Voir aussi l’article originel sur Plasma et Plasma Cash.

Pour déposer un actif, un utilisateur l’envoie au contrat autonome qui gère la chaîne Plasma. Elle lui attribue un nouvel identifiant unique (par exemple 537). Chaque chaîne Plasma a un opérateur (il peut s’agir d’un acteur centralisé, d’un multisig ou d’un élément plus complexe comme du PoS ou du DPoS). À chaque intervalle (15 secondes, ou une heure, ou entre les deux), l’opérateur génère un «lot» composé de toutes les transactions Plasma qu’il a reçues hors chaîne. Il génère un arbre de Merkle, où à chaque indice X de l’arbre, il y a une transaction transférant l’actif d’ID X s’il en existe une ; sinon cette feuille est à zéro. Ils publient la racine Merkle de cet arbre sur la chaîne. Ils envoient également la branche de Merkle de chaque index X au propriétaire actuel de cet actif. Pour retirer un actif, un utilisateur publie la branche de Merkle de la transaction la plus récente qui lui a envoyé l’actif. Le contrat déclenche une période de contestation, pendant laquelle chacun peut essayer d’utiliser d’autres branches de Merkle pour invalider la sortie en prouvant que (i) l’expéditeur ne possédait pas l’actif au moment où il l’a envoyé, ou (ii) qu’il a envoyé l’actif à quelqu’un d’autre à un moment ultérieur. Si personne ne prouve que la sortie est frauduleuse pendant (par exemple) 7 jours, l’utilisateur peut retirer le bien.

Plasma présente des propriétés plus puissantes que les canaux : vous pouvez envoyer des actifs à des participants qui n’ont jamais fait partie du système, et les exigences en matière de capital sont beaucoup plus faibles. Mais cela a un coût : les chaînes ne nécessitent aucune donnée pour tourner en «fonctionnement normal», mais Plasma exige que chaque chaîne publie une empreinte cryptographique à intervalles réguliers. De plus, les transferts Plasma ne sont pas instantanés : il faut attendre la fin de l’intervalle et la publication du bloc.

En outre, Plasma et les channels partagent une même faiblesse : la théorie des jeux sur laquelle se fonde leur sécurité repose sur l’idée que chaque objet contrôlé par les deux systèmes a un «propriétaire» logique. Si ce propriétaire ne se soucie pas de son bien, il peut en résulter un résultat «non valide» concernant cet actif. Cette situation est acceptable pour de nombreuses applications, mais elle est un facteur de rupture pour beaucoup d’autres (par exemple, Uniswap). Même les systèmes où l’état d’un objet peut être modifié sans le consentement du propriétaire (par exemple, les systèmes basés sur les comptes, où l’on peut augmenter le solde de quelqu’un sans son consentement) ne fonctionnent pas bien avec Plasma. Tout cela signifie qu’il faut beaucoup de «raisonnement spécifique à l’application» dans tout déploiement réaliste de Plasma ou de channels, et qu’il n’est pas possible de mettre en œuvre un système Plasma ou de channels qui se contente de simuler l’environnement complet d’Ethereum (ou «l’EVM»). Pour contourner ce problème, il faut… les rollups.

Rollups

Voir aussi : EthHub sur les optimistic rollups et les ZK rollups.

Plasma et les channels sont des représentations «complètes» de couche de niveau 2, en ce qu’ils tentent de déplacer les données et les calculs hors de la chaîne. Cependant, les questions fondamentales de la théorie des jeux concernant la disponibilité des données signifient qu’il est impossible de le faire en toute sécurité pour toutes les applications. Plasma et les channels contournent ce problème grâce à une notion explicite de propriétaire, mais cela les empêche d’être totalement généraux. Les rollups, en revanche, sont une représentation «hybride» de couche 2. Les rollups déplacent le calcul (et le stockage de l’état) hors chaîne, mais conservent certaines données par transaction sur la chaîne. Dans un souci d’efficacité, ils utilisent toute une série d’astuces de compression pour remplacer les données par du calcul chaque fois que cela est possible. Il en résulte un système dont l’évolutivité est toujours limitée par la bande passante de données de la blockchain sous-jacente, mais dans un rapport très favorable : alors qu’un transfert de jetons ERC20 de la couche de base d’Ethereum coûte environ 45000 gaz, un transfert de jetons ERC20 dans un rollup occupe 16 octets d’espace sur la chaîne et coûte moins de 300 gaz.

Le fait que les données résident sur la chaîne est essentiel (N.B.: le fait de mettre les données «sur IPFS» n’est pas suffisant car IPFS ne permet pas d’obtenir un consensus sur la disponibilité ou non d’une donnée ; les données doivent se trouver sur une blockchain). Le fait de mettre les données sur la chaîne et d’avoir un consensus à ce sujet permet à quiconque de traiter localement toutes les opérations du rollup s’il le souhaite, ce qui lui permet de détecter la fraude, d’initier des retraits ou de commencer personnellement à produire des lots de transactions. L’absence de problèmes de disponibilité des données signifie qu’un opérateur malveillant ou hors ligne peut faire encore moins de mal (par exemple, il ne peut pas causer un retard d’une semaine), ce qui ouvre un espace de conception beaucoup plus grand pour qui a le droit de publier des batches, des lots, et ce qui rend les rollups beaucoup plus faciles à raisonner. Et surtout, l’absence de problèmes de disponibilité des données signifie qu’il n’est plus nécessaire de faire correspondre les actifs aux propriétaires, ce qui explique pourquoi la communauté Ethereum est aussi enthousiaste à l’égard des rollups comparé aux formes précédentes de passage à l’échelle de niveau 2 : les rollups sont totalement génériques, et on peut même faire fonctionner une EVM à l’intérieur d’un rollup, ce qui permet aux applications Ethereum existantes de migrer vers des rollups pratiquement sans avoir à écrire de nouveau code.

Bon, mais comment fonctionne un rollup exactement ?

Il existe un contrat autonome sur la chaîne qui maintient une racine d’état : la racine Merkle de l’état du rollup (c’est-à-dire les soldes des comptes, le code du contrat, etc. qui sont «à l’intérieur» du rollup).

Tout le monde peut publier un lot, un ensemble de transactions fortement compressé avec la racine d’état précédente et la nouvelle racine d’état (la racine Merkle après le traitement des transactions). Le contrat vérifie que la racine d’état précédente du lot correspond à sa racine d’état actuelle ; si c’est le cas, la nouvelle racine d’état devient l’actuelle.

Pour faciliter les dépôts et les retraits, nous ajoutons la possibilité d’avoir des transactions dont l’entrée ou la sortie est «en dehors» de l’état du rollup. Si un lot comporte des entrées provenant de l’extérieur, la transaction qui soumet le lot doit également transférer ces actifs au contrat de rollup. Si un lot a des sorties vers l’extérieur, alors, lors du traitement du lot, le contrat autonome initie ces retraits.

Et c’est tout ! Sauf un détail majeur : comment savoir si les racines post-état des lots sont correctes ? Si quelqu’un peut soumettre un lot avec n’importe quelle racine post-état sans conséquences, il pourrait simplement se transférer toutes les pièces à l’intérieur du rollup. Cette question est essentielle car il existe deux familles de solutions très différentes au problème, et ces deux familles de solutions mènent aux deux saveurs de rouleaux.

Optimistic rollups contre ZK rollups

Les deux types de rollups sont :

1. Les Optimistic rollups, qui utilisent des preuves de fraude : le contrat de rollup conserve une trace de tout son historique des racines de l’état et l’empreinte cryptographique de chaque batch. Si quelqu’un découvre qu’un batch avait une racine post-état incorrecte, il peut publier une preuve sur la chaîne, prouvant que le lot a été mal calculé. Le contrat vérifie la preuve et renvoie ce lot ainsi que tous les lots     suivants. 
2. Les ZK rollups, qui utilisent des preuves de validité : chaque lot comprend une preuve cryptographique appelée ZK-SNARK (par exemple en utilisant le protocole PLONK), qui prouve que la racine post-état est le résultat correct de l’exécution du lot. Quelle que soit l’ampleur du calcul, la preuve peut être très rapidement vérifiée sur la chaîne. 

Les compromis entre les deux types de rollups sont complexes :

Propriété	Optimistic rollups	ZK rollups
Coût fixe du gaz par batch	~40 000 (une transaction légère qui ne fait que changer la valeur de la racine de l’État)	~500 000 (la vérification d’un ZK-SNARK est un travail de calcul assez intensif)
Délai de rétractation	~1 semaine (les retraits doivent être retardés pour donner le temps à quelqu’un de publier une preuve de fraude et d’annuler le retrait s’il est frauduleux)	Très rapide (il suffit d’attendre le prochain lot)
Complexité de la technologie	Faible	Élevée (les ZK-SNARK sont une technologie très nouvelle et mathématiquement complexe)
Possibilité de généralisation	Plus facile (les rollups EVM à usage général sont déjà proches du réseau principal)	Plus difficile (prouver des ZK-SNARK avec une EVM générique est beaucoup plus difficile que de prouver des calculs simples, bien qu’il y ait des efforts (par exemple Cairo) pour améliorer cela)
Coût du gaz par transaction sur la chaîne	Supérieur	Inférieur (si les données d’une transaction ne sont utilisées que pour vérifier, et non pour provoquer des changements d’état, alors ces données peuvent être omises, alors que dans un Optimistic rollup, elles devraient être publiées afin de pouvoir les vérifier lors d’une preuve de fraude)
Coûts de calcul hors chaîne	Inférieurs (bien qu’il soit plus nécessaire de refaire le calcul pour de nombreux nœuds complets)	Supérieurs (un ZK-SNARK s’avère particulièrement coûteux, potentiellement des milliers de fois plus cher que le calcul direct)

D’une manière générale, mon avis est qu’à court terme, les optimistic rollups devraient l’emporter pour le calcul générique sur l’EVM et les ZK rollups sont susceptibles de l’emporter pour les paiements simples, les échanges et d’autres cas d’usage spécifiques aux applications ; mais à moyen et long terme, les ZK rollups l’emporteront dans tous les cas d’usage à mesure que la technologie des ZK-SNARK s’améliorera.

Anatomie d’une preuve de fraude

La sécurité d’un Optimistic rollup repose sur l’idée que si quelqu’un publie un lot non valable dans le rollup, qui que ce soit d’autre qui suit la chaîne et a détecté la fraude peut publier une preuve de fraude, prouvant au contrat que ce lot est non valable et doit être annulé.

Une preuve de fraude prétendant qu’un lot est invalide contiendrait les données en vert : le lot lui-même (qui pourrait être vérifié par rapport à un hachage stocké sur la chaîne) et les parties de l’arbre de Merkle devaient prouver uniquement les comptes spécifiques qui ont été lus et/ou modifiés par le lot. Les nœuds de l’arbre en jaune peuvent être reconstruits à partir des nœuds en vert et n’ont donc pas besoin d’être fournis. Ces données sont suffisantes pour exécuter le lot et calculer la racine post-état (notez que les clients sans état vérifient les blocs individuels exactement de la même manière). Si la racine post-état calculée et la racine post-état fournie dans le lot ne sont pas les mêmes, le lot est frauduleux.

On a la garantie que si un lot a été mal assemblé, et que tous les lots précédents ont été assemblés correctement, il est possible de créer une preuve de fraude montrant que le lot a été assemblé de manière incorrecte. Notez la déclaration concernant les lots précédents : si plusieurs lots non valides ont été publiés dans le rollup, il est préférable d’essayer de prouver que le premier est non valide. Bien entendu, on a également la garantie que si un lot a été assemblé correctement, il n’est jamais possible de créer une preuve de fraude montrant que le lot est invalide.

Comment fonctionne la compression ?

Une simple transaction Ethereum (pour envoyer de l’ETH) prend ~110 octets. Un transfert ETH sur un rollup, en revanche, ne prend que ~12 octets :

Paramètre	Ethereum	Rollup
Nonce	~3	0
Prix du gaz	~8	0-0.5
Gaz	3	0-0.5
Destinataire	21	4
Valeur	~9	~3
Signature	~68 (2+33+33)	~0.5
Depuis	0 (récupéré de sig)	4
Total	~112	~12

Cela provient pour partie d’un meilleur encodage : la RLP d’Ethereum gaspille 1 octet par valeur sur la longueur de chaque valeur. Mais il y a aussi des astuces de compression très bien trouvées qui entrent en jeu :

• Nonce : le but de ce paramètre est d’empêcher les rediffusions. Si le nonce courant d’un compte est de 5, la prochaine opération de ce compte doit avoir un nonce 5, mais une fois l’opération traitée, le nonce du compte sera incrémenté à 6, de sorte que l’opération     ne pourra pas être traitée à nouveau. Dans le rollup, nous pouvons omettre complètement le nonce, car nous nous contentons de récupérer le nonce de l’état antérieur ; si quelqu’un essaie de rejouer une transaction avec un nonce antérieur, la signature ne sera pas vérifiée, car la signature sera comparée aux données qui contiennent le nouveau nonce supérieur.
• Prix du gaz : nous pouvons permettre aux utilisateurs de payer dans une de prix du gaz, par exemple un choix de 16 puissances consécutives de deux. Une autre possibilité serait de fixer un niveau de prix fixe pour chaque lot, ou même d’exclure entièrement le paiement du gaz du protocole de rollup et de faire payer les créateurs de lots par les participants aux transactions pour inclusion par un channel.
• Le gaz : nous pourrions tout aussi bien utiliser la totalité du gaz pour choisir entre des puissances consécutives de 2. On pourrait aussi se contenter d’une limite de gaz uniquement au niveau du lot.    
• To : nous pouvons remplacer l’adresse de 20 octets par un index (par exemple, si une adresse est la 4527e adresse ajoutée à l’arbre, nous utilisons simplement l’index 4527 pour y faire référence. Nous ajoutons un sous-arbre à l’état pour stocker la correspondance des index aux adresses). 
• Valeur : nous pouvons stocker la valeur en notation scientifique. Dans la plupart des cas, les transferts ne nécessitent que 1 à 3 chiffres significatifs.    
• Signature : nous pouvons utiliser les signatures agrégées BLS, qui permettent d’agréger de nombreuses signatures en une seule de ~32-96 octets (selon le protocole). Cette signature peut ensuite être vérifiée par rapport à l’ensemble des messages et des expéditeurs d’un même lot en une seule fois. Le ~0,5 du tableau représente le fait qu’il y a une limite au nombre de signatures pouvant être combinées dans un agrégat qui peuvent être vérifiées dans un seul bloc, et donc de grands lots auraient besoin d’une signature pour ~100 transactions.

Une astuce de compression importante, spécifique aux ZK rollups, est que si une partie d’une transaction est uniquement utilisée pour la vérification et n’est pas pertinente pour le calcul de la mise à jour de l’état, alors cette partie peut être laissée hors chaîne. Cela ne peut pas être fait dans un optimistic rollup car ces données devraient toujours être incluses dans la chaîne au cas où elles devraient être vérifiées ultérieurement dans une preuve de fraude, alors que dans un ZK rollup, le SNARK prouvant l’exactitude du lot prouve déjà que toutes les données nécessaires à la vérification ont été fournies. Un exemple important est celui des rollups de protection de la vie privée : dans un optimistic rollup, le ZK-SNARK d’environ 500 octets utilisé pour la confidentialité dans chaque transaction doit être intégré à la chaîne, tandis que dans un ZK rollup, le ZK-SNARK couvrant l’ensemble du lot ne laisse déjà aucun doute sur la validité des ZK-SNARK «internes».

Ces astuces de compression sont la clé de l’extensibilité des rollups ; sans elles, les rollups ne représenteraient peut-être qu’une amélioration d’un facteur ~10 par rapport à l’extensibilité de la chaîne de base (bien qu’il existe certaines applications spécifiques gourmandes en calculs où même les simples rollups sont puissants), alors qu’avec ces astuces de compression, le facteur d’échelle peut dépasser 100 fois pour presque toutes les applications.

Qui peut soumettre un lot ?

Il existe plusieurs écoles pour déterminer qui peut soumettre un lot dans un optimistic ou un ZK rollup. En général, tout le monde s’accorde à dire que, pour pouvoir soumettre un lot, un utilisateur doit verser un dépôt important ; si cet utilisateur soumet un jour un lot frauduleux (par exemple avec une racine d’état invalide), ce dépôt sera en partie brûlé et en partie donné comme récompense à celui qui a prouvé la fraude. Mais au-delà de cela, il existe de nombreuses possibilités :

• Anarchie totale : tout le monde peut soumettre un lot à tout moment. C’est l’approche la plus simple, mais elle présente des inconvénients importants. En particulier, il existe un risque que plusieurs participants génèrent et tentent de soumettre des lots en parallèle, et qu’un seul de ces lots puisse être inclus avec succès. Cela entraîne un gaspillage important d’efforts pour produire des épreuves et/ou un gaspillage de gaz pour publier les lots à enchaîner.        
• Séquenceur centralisé : un seul acteur, le séquenceur, peut soumettre des lots (à l’exception des retraits : la technique habituelle est qu’un utilisateur peut d’abord soumettre une demande de retrait, puis si le séquenceur ne traite pas ce retrait dans le lot suivant, l’utilisateur peut alors soumettre lui-même un lot à opération unique). C’est la plus «efficiente», mais elle dépend d’un acteur central à vie.
• Vente aux enchères du séquenceur : une vente aux enchères est organisée (par exemple tous les jours) afin de déterminer qui a le droit d’être le séquenceur pour le jour suivant. Cette technique présente l’avantage de permettre de lever des fonds qui pourraient être distribués par une DAO contrôlée par le rollup (voir : enchères MEV)    
• Sélection aléatoire à partir de l’ensemble du PoS : n’importe qui peut déposer de l’ETH (ou peut-être le jeton de protocole propre au rollup) dans le contrat de rollup, et     le séquenceur de chaque lot est choisi au hasard parmi l’un des déposants, la probabilité d’être sélectionné étant proportionnelle au montant déposé. Le principal inconvénient de cette technique est qu’elle conduit à l’immobilisation inutile d’un capital important. 
• Vote DPoS : un seul séquenceur est sélectionné lors d’une enchère, mais s’il n’est pas performant, les détenteurs de jetons peuvent voter pour le jeter dehors et organiser une nouvelle enchère pour le remplacer.    

Fractionnement des lots et fourniture de racines par l’État

Certains des rollups actuellement en cours de développement utilisent un paradigme de «split batch» ou lot éclaté, où l’action de soumettre un lot de transactions de couche 2 et celle de soumettre une racine d’état sont effectuées séparément. Cela présente certains avantages clés :

1. On peut permettre à plusieurs séquenceurs en parallèle de publier des lots afin d’améliorer la résistance à la censure, sans craindre que certains lots soient invalides parce qu’un autre lot a été inclus en premier.    
2. Si une racine d’état est frauduleuse, il n’est pas nécessaire de rétablir l’ensemble du lot     ; on peut rétablir uniquement la racine d’état et attendre que quelqu’un fournisse une nouvelle racine d’état pour le même lot. Cela donne aux expéditeurs de transactions une meilleure garantie que leurs transactions ne seront pas inversées.

Il existe donc un attirail assez complexe de techniques qui tentent de trouver un équilibre entre des compromis compliqués impliquant efficacité, simplicité, résistance à la censure, entre autres objectifs. Il est encore trop tôt pour dire quelle combinaison de ces idées fonctionne le mieux ; le temps nous le dira.

Quelle est l’ampleur du passage à l’échelle apporté par les rollups ?

Sur la chaîne Ethereum existante, la limite de gaz est de 12,5 millions, et chaque octet de données dans une transaction coûte 16 gaz. Cela signifie que si un bloc ne contient qu’un seul lot (nous dirons qu’un ZK rollup est utilisé, dépensant 500k de gaz pour la vérification des preuves), ce lot peut avoir (12 millions / 16) = 750000 octets de données. Comme indiqué ci-dessus, un rollup pour les transferts ETH ne nécessite que 12 octets par opération utilisateur, ce qui signifie que le lot peut contenir jusqu’à 62500 transactions. Avec un temps de bloc moyen de 13 secondes, cela se traduit par ~4807 TPS (contre 12,5 millions / 21000 / 13 ~= 45 TPS pour les transferts d’ETH sur Ethereum lui-même).

Voici un tableau pour d’autres exemples de cas d’utilisation :

Application	Octets dans le rollup	Coût du gaz sur la couche 1	Gain maximal
Transfert d’ETH	12	21 000	105x
Transfert ERC20	16 (4 octets supplémentaires pour préciser quel jeton)	~50 000	187x
Trade Uniswap	~14 (4 octets expéditeur + 4 octets destinataire + 3 octets valeur + 1 octet prix maxi + 1 octet divers)	~100000	428x
Retrait avec confidentialité (Optimistic rollup)	296 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire + 256 octets de preuve ZK-SNARK)	~380 000	77x
Retrait avec confidentialité (ZK rollup)	40 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire)	~380 000	570x

Il convient maintenant de garder à l’esprit que ces chiffres sont trop optimistes. Avant tout, un bloc ne contiendra presque toujours plus d’un seul lot, à tout le moins parce qu’il y a et qu’il y aura plusieurs rollups. Deuxièmement, les dépôts et les retraits continueront d’exister. Troisièmement, à court terme, l’utilisation sera faible, et les coûts fixes domineront donc. Mais même en tenant compte de ces facteurs, des gains d’extensibilité de plus de 100 devraient être la norme.

Maintenant, que faire si nous voulons aller au-delà de ~1000-4000 TPS (selon le cas d’utilisation spécifique) ? C’est ici qu’intervient le sharding d’eth2. La proposition sur le sharding, ou fragmentation, ouvre un espace de 16 Mo toutes les 12 secondes qui peut être rempli avec n’importe quelles données, et le système garantit un consensus sur la disponibilité de ces données. Cet espace de données peut être utilisé par des rollups. Cette capacité de ~1398k octets par seconde est une amélioration de 23x par rapport aux ~60 kB/sec de la chaîne Ethereum existante, et à plus long terme, la capacité en données devrait encore augmenter. Par conséquent, les rollups qui utilisent des données eth2 fragmentées peuvent traiter collectivement jusqu’à ~100k TPS, et même plus à l’avenir.

Quels sont les problèmes non encore résolus dans les rollups ?

Bien que le concept de base d’un rollup soit maintenant bien compris, que nous soyons tout à fait certains qu’il est fondamentalement faisable et sûr, et que de multiples rollups aient déjà été déployés sur le réseau principal, il reste encore de nombreuses zones d’ombre quant à leur conception, ainsi qu’un certain nombre de défis à relever pour amener de grandes parties de l’écosystème Ethereum sur des rollups afin de profiter du passage à l’échelle qu’ils offrent. Voici quelques-uns des principaux défis en question :

• Intégration des utilisateurs et de l’écosystème – peu d’applications utilisent des rollups, ils sont peu connus des utilisateurs et peu de portefeuilles ont commencé à les intégrer. Les commerçants et les associations ne les acceptent pas encore pour les paiements. 
• Transactions croisées – transfert efficace des actifs et des données (par exemple, les résultats d’oracles) d’un rollup à l’autre sans avoir à passer par la couche de base. 
• Audit des incitations – comment maximiser les chances qu’au moins un nœud honnête vérifie effectivement un optimistic rollup afin de pouvoir publier une preuve de fraude si quelque chose tourne mal ? Pour les rollups à petite échelle (jusqu’à quelques centaines de TPS), ce n’est pas     un problème important et on peut simplement compter sur l’altruisme, mais pour les rollups à plus grande échelle, une réflexion plus comlète est nécessaire sur ce sujet.    
• Exploration     de l’espace de conception entre le plasma et les rollups – existe-t-il des techniques permettant de mettre sur la chaîne certaines données pertinentes pour la mise à jour de l’état, mais pas toutes, et y a-t-il quelque chose d’utile qui pourrait en résulter ?     
• Maximiser la sécurité des pré-confirmations – de nombreux rollups fournissent une notion de «pré-confirmation» pour des UX plus rapides, où le séquenceur fournit immédiatement une promesse qu’une transaction sera incluse dans le lot suivant, et le dépôt du séquenceur est détruit s’ils manquent à leur parole. Mais la sécurité économique de ce système est limitée en raison de la possibilité de faire de nombreuses promesses à de très nombreux acteurs en même temps. Ce mécanisme peut-il être amélioré ?
• Améliorer la vitesse de réponse aux séquenceurs absents – si le séquenceur d’un rollup se met soudainement hors ligne, il serait utile de revenir à la normale rapidement et à moindre coût, soit en sortant en masse rapidement et à moindre coût vers un autre rollup, soit en remplaçant le séquenceur.     
• ZK-VM efficiente – génération d’une preuve ZK-SNARK selon laquelle le code de l’EVM générique (ou une autre VM sur laquelle les contrats existants peuvent être compilés) a été exécuté correctement et a donné un certain résultat. 

Conclusion

Les rollups constituent un nouveau paradigme puissant de passage à l’échelle de la couche de niveau 2 et devraient devenir une pierre angulaire du passage à l’échelle d’Ethereum à court et moyen terme (et peut-être aussi à long terme). La communauté Ethereum s’est montrée très enthousiaste car, contrairement aux tentatives précédentes de passage à l’échelle en couche 2, elle peut prendre en charge le code EVM générique, ce qui permet aux applications existantes de migrer facilement. Pour ce faire, ils ont fait un compromis essentiel : ils n’ont pas essayé de se retirer complètement de la chaîne, mais ont laissé une petite quantité de données par transaction sur la chaîne.

Il existe de nombreux types de rollups, et de nombreux choix dans l’espace de conception : on peut employer un optimistic rollup en utilisant des preuves de fraude, ou un ZK rollup en utilisant des preuves de validité (c.à.d. ZK-SNARK). Le séquenceur (l’utilisateur qui peut publier des lots de transactions à enchaîner) peut être un acteur centralisé, ou tout le monde et n’importe qui, ou encore un choix intermédiaire entre ces deux extrêmes. Les rollups sont une technologie encore très jeune et leur développement se poursuit rapidement, mais ils fonctionnent et certains (notamment Loopring, ZKSync et DeversiFi) fonctionnent déjà depuis des mois. On peut s’attendre à ce que des travaux passionnants dans ce domaine émergent dans les années à venir.

The post Un guide incomplet des rollups first appeared on Ethereum France.