Les rollups font fureur

Les cumuls font fureur dans la communauté Ethereum et sont sur le point de devenir la solution d'évolutivité clé pour Ethereum dans un avenir prévisible.

Mais qu'est-ce que cette technologie exactement, que pouvez-vous en attendre et comment allez-vous pouvoir l'utiliser ? Cet article tentera de répondre à certaines de ces questions clés.

Contexte : qu'est-ce que la mise à l'échelle des couches 1 et 2 ?

Il existe deux façons de faire évoluer un écosystème blockchain. Tout d'abord, vous pouvez faire en sorte que la blockchain elle-même ait une capacité de transaction plus élevée .

Le principal défi de cette technique est que les chaînes de blocs avec des "blocs plus gros" sont intrinsèquement plus difficiles à vérifier et susceptibles de devenir plus centralisées.

Pour éviter de tels risques, les développeurs peuvent soit augmenter l'efficacité des logiciels clients, 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 ; l' effort connu sous le nom de "eth2" construit actuellement cette mise à niveau vers Ethereum.

Deuxièmement, vous pouvez modifier la façon dont vous utilisez la blockchain . Au lieu de mettre directement toute l'activité sur la blockchain, les utilisateurs effectuent l'essentiel de leur activité hors chaîne dans un protocole de "couche 2".

Il existe un contrat intelligent en 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 chaîne respecte les règles.

Il existe plusieurs façons de faire ces preuves, mais elles partagent toutes la propriété selon laquelle vérifier les preuves en chaîne est beaucoup moins cher que de faire le calcul d'origine hors chaîne.

Chaînes d'état vs Plasma vs Rollups

Les trois principaux types de mise à l'échelle de la couche 2 sont les canaux d'état , le plasma et les cumuls.

Ce sont trois paradigmes différents, avec des forces et des faiblesses différentes, et à ce stade, nous sommes assez confiants que toute la mise à l'échelle de la couche 2 entre à peu près dans ces trois catégories (bien que des controverses de dénomination existent aux bords, par exemple voir "validium" ).

Comment fonctionnent les chaînes ?

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

Imaginez qu'Alice offre une connexion Internet à Bob, en échange de ce que Bob lui paie 0,001 USD par mégaoctet. Au lieu d'effectuer une transaction pour chaque paiement, Alice et Bob utilisent le schéma de couche 2 suivant.

Tout d'abord, Bob met 1 $ (ou un équivalent ETH ou stablecoin) dans un contrat intelligent. 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 signait un autre ticket indiquant "0,002 $" et l'envoyait à Alice. Et ainsi de suite pour autant de versements que nécessaire. Lorsqu'Alice et Bob ont terminé leurs transactions, Alice peut publier le ticket de la plus haute valeur à enchaîner, enveloppé dans une autre signature d'elle-même.

Le contrat intelligent vérifie les signatures d'Alice et de Bob, verse à Alice le montant du billet de Bob et renvoie le reste à Bob.

Si Alice n'est pas disposée à fermer la chaîne (pour cause de malveillance ou de défaillance technique), Bob peut initier un délai de rétractation (par exemple, 7 jours) ; si Alice ne fournit pas de billet dans ce délai, Bob récupère tout son argent.

Cette technique est puissante : elle peut être ajustée pour gérer les paiements bidirectionnels, les relations contractuelles intelligentes (par exemple, Alice et Bob concluant 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 en toute confiance avec Charlie).

Mais il y a des limites à ce que les canaux peuvent faire.

Les canaux ne peuvent pas être utilisés pour envoyer des fonds hors chaîne à des personnes qui ne sont pas encore participantes. Les canaux 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 canaux, surtout s'ils sont utilisés pour faire des choses plus complexes que de simples paiements récurrents, nécessitent de bloquer une grande quantité de capital.

Comment fonctionne le plasma ?

Voir aussi : le papier Plasma original , et Plasma Cash .

Pour déposer un actif, un utilisateur l'envoie au smart contract gérant la chaîne Plasma. La chaîne Plasma attribue à cet actif un nouvel identifiant unique (par exemple, 537).

Chaque chaîne Plasma a un opérateur (cela peut être un acteur centralisé, ou un multisig, ou quelque chose de plus complexe comme PoS ou DPoS). À chaque intervalle (cela peut être 15 secondes, une heure ou quoi que ce soit 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.

Ils génèrent un arbre de Merkle, où à chaque index X de l'arbre, il y a une transaction transférant l'ID d'actif X si une telle transaction existe, et sinon cette feuille est zéro. Ils publient la racine Merkle de cet arbre à chaîner.

Ils envoient également la branche Merkle de chaque index X au propriétaire actuel de cet actif. Pour retirer un actif, un utilisateur publie la branche Merkle de la transaction la plus récente qui lui a envoyé l'actif.

Le contrat commence une période de contestation, au cours de laquelle n'importe qui peut essayer d'utiliser d'autres succursales Merkle pour invalider la sortie en prouvant que (i) l'expéditeur n'était pas propriétaire de l'actif au moment où il l'a envoyé, ou (ii) 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 l'actif.

Le plasma offre des propriétés plus solides que les canaux : vous pouvez envoyer des actifs à des participants qui n'ont jamais fait partie du système, et les besoins en capital sont beaucoup plus faibles.

Mais cela a un coût : les chaînes ne nécessitent aucune donnée pour être en chaîne pendant le "fonctionnement normal", mais Plasma exige que chaque chaîne publie un hachage à intervalles réguliers.

De plus, les transferts Plasma ne sont pas instantanés : il faut attendre que l'intervalle se termine et que le bloc soit publié.

De plus, Plasma et les canaux partagent une faiblesse clé en commun : la théorie du jeu expliquant pourquoi ils sont sécurisés 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 actif, un résultat "invalide" impliquant cet actif peut en résulter. C'est correct pour de nombreuses applications, mais c'est un facteur décisif 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 des comptes, où vous pouvez augmenter le solde de quelqu'un sans son consentement) ne fonctionnent pas bien avec Plasma.

Tout cela signifie qu'une grande quantité de "raisonnement spécifique à l'application" est nécessaire dans tout déploiement réaliste de plasma ou de canaux, et il n'est pas possible de créer un système de plasma ou de canaux qui simule simplement l'environnement Ethereum complet (ou "l'EVM") . Pour contourner ce problème, nous arrivons à... des cumuls.

Cumuls

Voir aussi : EthHub sur les cumuls optimistes et les cumuls ZK .

Le plasma et les canaux sont des schémas de couche 2 "complets", en ce sens qu'ils tentent de déplacer à la fois les données et les calculs hors chaîne.

Cependant, les problèmes fondamentaux 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. Le plasma et les canaux contournent cela en s'appuyant sur une notion explicite de propriétaires, mais cela les empêche d'être totalement généraux.

Les cumuls, en revanche, sont un schéma de couche 2 "hybride".

Les cumuls déplacent le calcul (et le stockage d'état) hors chaîne, mais conservent certaines données par transaction en chaîne .

Pour améliorer l'efficacité, ils utilisent toute une série d'astuces de compression fantaisistes pour remplacer les données par des calculs dans la mesure du possible.

Le résultat est un système où l'évolutivité est encore limitée par la bande passante de données de la blockchain sous-jacente, mais à un ratio très favorable : alors qu'un transfert de jeton ERC20 de la couche de base Ethereum coûte environ 45 000 gaz, un transfert de jeton ERC20 dans un rollup en prend 16. octets d'espace sur la chaîne et coûte moins de 300 gaz.

Le fait que les données soient en chaîne est essentiel (remarque : mettre des données "sur IPFS" ne fonctionne pas , car IPFS ne fournit pas de consensus sur la disponibilité ou non d'une donnée donnée ; les données doivent aller sur une blockchain).

Mettre les données en chaîne et avoir un consensus sur ce fait permet à quiconque de traiter localement toutes les opérations du cumul 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.

Le manque 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 de retard d'une semaine), ouvrant un espace de conception beaucoup plus grand pour qui a le droit de publier des lots et facilitant grandement les cumuls raisonner.

Et surtout, le manque de problèmes de disponibilité des données signifie qu'il n'est plus nécessaire de mapper les actifs aux propriétaires, ce qui explique la principale raison pour laquelle la communauté Ethereum est tellement plus enthousiasmée par les cumuls que les formes précédentes de mise à l'échelle de la couche 2 : les cumuls sont entièrement à usage général, et on peut même exécuter un EVM dans un rollup, permettant aux applications Ethereum existantes de migrer vers des rollups sans presque avoir besoin d'écrire de nouveau code .

OK, alors comment fonctionne exactement un rollup ?

Il existe un smart contract on-chain 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).

N'importe qui peut publier un lot , une collection de transactions sous une forme hautement compressée 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 dans le lot correspond à sa racine d'état actuelle ; si c'est le cas, il bascule la racine d'état vers la nouvelle racine d'état.

Pour prendre en charge le dépôt et le retrait, nous ajoutons la possibilité d'avoir des transactions dont l'entrée ou la sortie est "en dehors" de l'état de cumul.

Si un lot contient des entrées de l'extérieur, la transaction soumettant le lot doit également transférer ces actifs vers le contrat de cumul. Si un lot a des sorties vers l'extérieur, lors du traitement du lot, le contrat intelligent initie ces retraits.

Et c'est tout! A un détail près près : comment savoir si les racines post-état dans les lots sont correctes ?

Si quelqu'un peut soumettre un lot avec n'importe quelle racine post-état sans conséquences, il peut simplement transférer toutes les pièces à l'intérieur du cumul à lui-même.

Cette question est essentielle car il existe deux familles de solutions très différentes au problème, et ces deux familles de solutions conduisent aux deux types de cumuls.

Cumuls optimistes vs cumuls ZK

Les deux types de cumuls sont :

1. Rollups optimistes , qui utilisent des preuves de fraude : le contrat de rollup garde une trace de tout son historique des racines d'état et du hachage de chaque lot.

   
   

   Si quelqu'un découvre qu'un lot avait une racine post-état incorrecte, il peut publier une preuve à la chaîne, prouvant que le lot a été calculé de manière incorrecte.

   
   

   Le contrat vérifie la preuve et annule ce lot et tous les lots qui le suivent.

   
   

2. Rollups ZK , 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 la taille du calcul, la preuve peut être très rapidement vérifiée en chaîne.

Il existe des compromis complexes entre les deux types de cumuls :

En général, mon opinion est qu'à court terme, les cumuls optimistes sont susceptibles de l'emporter pour le calcul EVM à usage général et les cumuls ZK sont susceptibles de l'emporter pour les paiements simples, les échanges et d'autres cas d'utilisation spécifiques à l'application, mais dans le Les cumuls ZK à moyen et long terme l'emporteront dans tous les cas d'utilisation à mesure que la technologie ZK-SNARK s'améliorera.

Anatomie d'une preuve de fraude

La sécurité d'un cumul optimiste dépend de l'idée que si quelqu'un publie un lot invalide dans le cumul, toute autre personne qui suivait la chaîne et a détecté la fraude peut publier une preuve de fraude, prouvant au contrat que ce lot est invalide et devrait être inversé.

Une preuve de fraude affirmant qu'un lot n'était pas valide 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 Merkle nécessaires pour prouver uniquement les comptes spécifiques qui ont été lus et/ ou modifié 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 c'est exactement la même chose que la façon dont les clients sans état vérifient les blocs individuels).

Si la racine post-état calculée et la racine post-état fournie dans le lot ne sont pas identiques, le lot est frauduleux.

Il est garanti que si un lot a été construit de manière incorrecte et que tous les lots précédents ont été construits correctement , il est alors possible de créer une preuve de fraude montrant que le lot a été construit de manière incorrecte.

Notez la réclamation concernant les lots précédents : s'il y avait plus d'un lot non valide publié dans le cumul, il est préférable d'essayer de prouver que le premier lot n'est pas valide. Il est également, bien sûr, garanti que si un lot a été construit correctement, il n'est jamais possible de créer une preuve de fraude montrant que le lot n'est pas valide.

Comment fonctionne la compression ?

Une simple transaction Ethereum (pour envoyer des ETH) prend environ 110 octets. Cependant, un transfert ETH sur un rollup ne prend que ~12 octets :

Une partie de cela est simplement un codage supérieur : le 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 astucieuses :

• Nonce : le but de ce paramètre est d'empêcher les replays. Si le nonce actuel d'un compte est 5, la prochaine transaction de ce compte doit avoir le nonce 5, mais une fois la transaction traitée, le nonce du compte sera incrémenté à 6 afin que la transaction ne puisse plus être traitée.

  
  

  Dans le cumul, nous pouvons omettre entièrement le nonce, car nous récupérons simplement le nonce du pré-état ; si quelqu'un essaie de rejouer une transaction avec un nonce antérieur, la signature échouera à être vérifiée, car la signature sera vérifiée par rapport aux données qui contiennent le nouveau nonce supérieur.

  
  

• Prix du gaz : nous pouvons permettre aux utilisateurs de payer avec une fourchette fixe de prix du gaz, par ex. un choix de 16 puissances consécutives de deux.

  
  

  Alternativement, nous pourrions simplement avoir un niveau de frais fixe dans chaque lot, ou même déplacer entièrement le paiement du gaz en dehors du protocole de cumul et demander aux opérateurs de payer les créateurs de lots pour les inclure via un canal.

  
  

• Gaz : on pourrait de même restreindre le gaz total à un choix de puissances consécutives de deux. Alternativement, nous pourrions simplement avoir 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'arborescence, nous utilisons simplement l'index 4527 pour y faire référence.

  
  

  Nous ajouterions un sous-arbre à l'état pour stocker le mappage des index aux adresses).

  
  

• Valeur : nous pouvons stocker la valeur en notation scientifique. Dans la plupart des cas, les transferts n'ont besoin que de 1 à 3 chiffres significatifs.

  
  

• Signature : nous pouvons utiliser les signatures agrégées BLS , ce qui permet d'agréger de nombreuses signatures en une seule signature d'environ 32 à 96 octets (selon le protocole).

  
  

  Cette signature peut ensuite être comparée à l'ensemble des messages et des expéditeurs d'un lot en une seule fois.

  
  

  Le ~0,5 dans le tableau représente le fait qu'il y a une limite sur le nombre de signatures pouvant être combinées dans un agrégat qui peut être vérifié dans un seul bloc, et donc les gros lots nécessiteraient une signature pour ~100 transactions.

Une astuce de compression importante spécifique aux cumuls ZK est que si une partie d'une transaction n'est utilisée que pour la vérification et n'est pas pertinente pour le calcul de la mise à jour de l'état, cette partie peut être laissée hors chaîne.

Cela ne peut pas être fait dans un cumul optimiste 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 cumul ZK, 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 de ceci est les cumuls préservant la confidentialité : dans un cumul optimiste, les ~500 octets ZK-SNARK utilisés pour la confidentialité dans chaque transaction doivent être mis en chaîne, alors que dans un cumul ZK, le ZK-SNARK couvrant l'ensemble du lot ne laisse déjà aucun doute que les ZK-SNARK "intérieurs" soient valides.

Ces astuces de compression sont essentielles à l'évolutivité des cumuls ; sans eux, les cumuls ne seraient peut-être qu'une amélioration d'environ 10 fois l'évolutivité de la chaîne de base (bien qu'il existe des applications spécifiques nécessitant beaucoup de calculs où même les cumuls simples sont puissants), alors qu'avec des astuces de compression, le facteur de mise à l'échelle peut dépasser 100x pendant presque toutes les candidatures.

Qui peut soumettre un lot ?

Il existe un certain nombre d'écoles de pensée pour savoir qui peut soumettre un lot dans un cumul optimiste ou ZK.

Généralement, tout le monde s'accorde à dire que pour pouvoir soumettre un lot, un utilisateur doit déposer un acompte important ; si jamais cet utilisateur soumet un lot frauduleux (par exemple avec une racine d'état invalide), ce dépôt sera en partie brûlé et en partie donné en récompense au prouveur de fraude. Mais au-delà de cela, il existe de nombreuses possibilités :

• Anarchie totale : n'importe qui 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 une grande quantité d'efforts gaspillés dans la génération d'épreuves et/ou un gaspillage de gaz dans la publication de lots à chaîner.

  
  

• Séquenceur centralisé : il y a un seul acteur, le séquenceur , qui 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 prochain lot, l'utilisateur peut soumettre lui-même un lot d'une seule opération).

  
  

  C'est la plus "efficace", mais elle s'appuie sur un acteur central pour la vivacité.

  
  

• Enchère du séquenceur : une enchère est organisée (par ex. tous les jours) pour déterminer qui a le droit d'être le séquenceur du lendemain.

  
  

  Cette technique a l'avantage de lever des fonds qui pourraient être distribués par ex. un DAO piloté par le rollup (voir : enchères MEV )

  
  

• Sélection aléatoire à partir de l'ensemble PoS : n'importe qui peut déposer des ETH (ou peut-être le propre jeton de protocole du rollup) dans le contrat de rollup, et le séquenceur de chaque lot est sélectionné 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 à de grandes quantités de capital bloqué inutilement.

  
  

• Vote DPoS : il y a un seul séquenceur sélectionné avec une enchère mais s'ils fonctionnent mal, les détenteurs de jetons peuvent voter pour les expulser et organiser une nouvelle enchère pour les remplacer.

Séparer le traitement par lots et fournir la racine de l'état

Certains des cumuls en cours de développement utilisent un paradigme de "lot divisé", où l'action de soumettre un lot de transactions de couche 2 et l'action de soumettre une racine d'état sont effectuées séparément.

Cela présente certains avantages clés :

1. Vous pouvez autoriser plusieurs séquenceurs en parallèle à publier des lots afin d'améliorer la résistance à la censure, sans craindre que certains lots ne soient invalides car un autre lot a été inclus en premier.

   
   

2. Si une racine d'état est frauduleuse, vous n'avez pas besoin de rétablir l'intégralité du lot ; vous pouvez 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 annulées.

Donc, dans l'ensemble, il existe un zoo assez complexe de techniques qui tentent d'équilibrer entre des compromis compliqués impliquant efficacité, simplicité, résistance à la censure et d'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 quantité de mise à l'échelle les rollups vous offrent-ils ?

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 cumul ZK est utilisé, dépensant 500 000 gaz pour la vérification de la preuve), ce lot peut avoir (12 millions / 16) = 750 000 octets de données.

Comme indiqué ci-dessus, un cumul pour les transferts ETH ne nécessite que 12 octets par opération utilisateur, ce qui signifie que le lot peut contenir jusqu'à 62 500 transactions.

Avec un temps de blocage moyen de 13 secondes , cela se traduit par ~4807 TPS (contre 12,5 millions / 21000 / 13 ~= 45 TPS pour les transferts ETH directement sur Ethereum lui-même).

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

Le gain d'évolutivité maximal est calculé comme suit (coût du gaz L1) / (octets dans le cumul * 16) * 12 millions / 12,5 millions.

Maintenant, il convient de garder à l'esprit que ces chiffres sont trop optimistes pour plusieurs raisons. Plus important encore, un bloc ne contiendrait presque jamais un seul lot, à tout le moins parce qu'il existe et qu'il y aura plusieurs cumuls.

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. Mais même avec ces facteurs pris en compte, des gains d'évolutivité de plus de 100x devraient être la norme.

Maintenant, que se passe-t-il si nous voulons aller au-dessus de ~ 1000-4000 TPS (selon le cas d'utilisation spécifique) ? C'est là qu'intervient le partage de données eth2 .

La proposition de partitionnement 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 cumuls.

Ces ~1398k octets par seconde représentent une amélioration de 23 fois par rapport aux ~60 Ko/sec de la chaîne Ethereum existante, et à plus long terme, la capacité de données devrait encore augmenter.

Par conséquent, les cumuls qui utilisent des données fragmentées eth2 peuvent traiter collectivement jusqu'à environ 100 000 TPS, et encore plus à l'avenir.

Quels sont certains défis non encore entièrement résolus dans les cumuls ?

Alors que le concept de base d'un rollup est maintenant bien compris, nous sommes tout à fait certains qu'ils sont fondamentalement faisables et sécurisés, et plusieurs rollups ont déjà été déployés sur le réseau principal, il y a encore de nombreux domaines de conception de rollup qui n'ont pas été bien explorés, et pas mal de défis pour intégrer pleinement de grandes parties de l'écosystème Ethereum dans les rollups afin de tirer parti de leur évolutivité.

Certains défis clés incluent :

• Intégration des utilisateurs et de l'écosystème - peu d'applications utilisent des rollups , les rollups ne sont pas familiers aux utilisateurs et peu de portefeuilles ont commencé à intégrer des rollups.

  
  

  Les commerçants et les organisations caritatives ne les acceptent pas encore pour les paiements.

  
  

• Transactions de cumul croisé - déplacement efficace des actifs et des données (par exemple, les sorties Oracle) d'un cumul à un autre sans encourir les frais de passage par la couche de base.

  
  

• Audit des incitations - comment maximiser les chances qu'au moins un nœud honnête vérifie entièrement un cumul optimiste afin qu'il puisse publier une preuve de fraude en cas de problème ?

  
  

  Pour les cumuls à 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 cumuls à plus grande échelle, un raisonnement plus explicite à ce sujet est nécessaire.

  
  

• Explorer l'espace de conception entre plasma et rollups - existe-t-il des techniques qui mettent en 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 sortir?

  
  

• Maximiser la sécurité des pré-confirmations - de nombreux rollups fournissent une notion de "pré-confirmation" pour une UX plus rapide, où le séquenceur fournit immédiatement une promesse qu'une transaction sera incluse dans le prochain lot, et le dépôt du séquenceur est détruit s'il rompt son mot.

  
  

  Mais la sécurité économique de ce schéma est limitée, du fait 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 déconnecte soudainement, il serait utile de se remettre de cette situation rapidement et à moindre coût, soit en sortant rapidement et à moindre coût vers un autre rollup, soit en remplaçant le séquenceur.

  
  

• ZK-VM efficace - générant une preuve ZK-SNARK que le code EVM à usage général (ou une machine virtuelle différente sur laquelle les contrats intelligents existants peuvent être compilés) a été exécuté correctement et a un résultat donné.

conclusion

Les cumuls sont un nouveau paradigme puissant de mise à l'échelle de la couche 2 et devraient être la pierre angulaire de la mise à l'échelle d'Ethereum à court et à moyen terme (et peut-être également à long terme).

Ils ont constaté un grand enthousiasme de la part de la communauté Ethereum car, contrairement aux tentatives précédentes de mise à l'échelle de la couche 2, ils peuvent prendre en charge le code EVM à usage général, permettant aux applications existantes de migrer facilement.

Pour ce faire, ils font un compromis clé : ne pas essayer d'aller complètement hors chaîne, mais plutôt laisser une petite quantité de données par transaction en chaîne.

Il existe de nombreux types de cumuls et de nombreux choix dans l'espace de conception : on peut avoir un cumul optimiste utilisant des preuves de fraude, ou un cumul ZK utilisant des preuves de validité (alias ZK-SNARK).

Le séquenceur (l'utilisateur qui peut publier des lots de transactions à chaîner) peut être soit un acteur centralisé, soit un libre pour tous, soit de nombreux autres choix intermédiaires.

Les rollups sont encore une technologie à un stade précoce, et le développement se poursuit rapidement, mais ils fonctionnent et certains (notamment Loopring , ZKSync et DeversiFi ) fonctionnent déjà depuis des mois. Attendez-vous à ce que des travaux beaucoup plus excitants sortent de l'espace de déploiement dans les années à venir.