Rejoignez-Nous sur

L'aube des protocoles hybrides de couche 2

RollupAnatomy

News

L'aube des protocoles hybrides de couche 2

Un merci spécial à l'équipe de Plasma Group pour ses commentaires et ses commentaires

Les approches actuelles de la mise à l'échelle de la couche 2 – essentiellement le plasma et les canaux d'état – passent de plus en plus de la théorie à la pratique, mais il est en même temps plus facile de comprendre les défis inhérents au traitement de ces techniques en tant que solution de mise à l'échelle à part entière pour Ethereum. Ethereum a sans aucun doute eu beaucoup de succès en raison de son expérience de développeur très simple: vous écrivez un programme, le publiez et tout le monde peut interagir avec celui-ci. D'autre part, la conception d'un canal d'État ou d'une application Plasma repose sur un raisonnement explicite concernant les incitations et la complexité du développement spécifique à une application. Les canaux d’État fonctionnent bien pour des cas d’utilisation spécifiques tels que les paiements répétés entre les mêmes parties et les jeux à deux joueurs (mis en œuvre avec succès dans Celer), mais une utilisation plus généralisée s'avère difficile. Plasma, en particulier Plasma Cash, peut bien fonctionner pour les paiements, mais la généralisation comporte également des difficultés: même pour mettre en place un échange décentralisé, les clients doivent stocker beaucoup plus de données d’historique, et la généralisation à des contrats intelligents de type Ethereum semble extrêmement difficile.

Mais dans le même temps, on assiste à la résurgence d’une catégorie oubliée de protocoles de «demi-couche 2», catégorie qui promet des gains d’échelle moins extrêmes, mais avec l’avantage d’une généralisation beaucoup plus facile et de modèles de sécurité plus favorables. UNE article de blog oublié de 2014 introduit l’idée de «chaînes d’ombre», une architecture dans laquelle les données de bloc sont publiées en chaîne, mais pas les blocs. vérifié par défaut. Plutôt, les blocs sont acceptés provisoirement et ne sont finalisés qu’après un certain temps (par exemple 2 semaines). Pendant ces 2 semaines, un bloc accepté provisoirement peut être contesté; alors seulement, le bloc est vérifié et si le bloc s’avère invalide, la chaîne à partir de ce bloc est annulée et le dépôt de l’éditeur original est pénalisé. Le contrat ne garde pas trace de l'état complet du système; il ne fait que suivre la racine de l'état, et les utilisateurs eux-mêmes peuvent calculer l'état en traitant les données soumises à la chaîne de bout en bout. Une proposition plus récente, ZK Rollup, fait la même chose sans périodes de challenge, en utilisant ZK-SNARK pour vérifier la validité des blocs.


RollupAnatomy
Anatomie d'un package ZK Rollup publié sur la chaîne. Des centaines de "transactions internes" qui affectent l'état (c'est-à-dire les soldes des comptes) du système ZK Rollup sont compressées dans un package contenant environ 10 octets par transaction interne spécifiant les transitions d'état, ainsi qu'un SNARK d'environ 100 à 300 octets prouvant que les transitions sont toutes valides.

Dans les deux cas, la chaîne principale est utilisée pour vérifier les données disponibilité, mais ne vérifie pas (directement) le bloc validité ou effectuer tout calcul significatif, à moins que des défis ne soient posés. Cette technique n’est donc pas un énorme gain d’évolutivité, car la surcharge de données dans la chaîne finit par créer un goulot d’étranglement, mais c’est quand même un très important. Les données coûtent moins cher que le calcul, et il existe des moyens de compresser les données de transaction de manière très significative, notamment parce que la grande majorité des données d’une transaction est la signature et que de nombreuses signatures peuvent être compressées en une seule grâce à de nombreuses formes d’agrégation. ZK Rollup promet 500 tx / s, soit un gain 30 fois supérieur à la chaîne Ethereum elle-même, en comprimant chaque transaction à environ 10 octets; les signatures n'ont pas besoin d'être incluses car leur validité est vérifiée par la preuve de connaissance zéro. Avec les signatures agrégées BLS, un débit similaire peut être atteint dans les chaînes fantômes (plus récemment appelé «cumul optimiste» pour souligner ses similitudes avec le cumul ZK). Le prochain Fourchette dure d'Istanbul réduira le coût en gaz des données de 68 à 16 par octet, augmentant ainsi le débit de ces techniques de 4x plus de 2000 transactions par seconde).


Alors, quel est l’avantage des techniques de chaînes de données telles que le ZK / cumul optimiste par rapport aux techniques de chaînes de données telles que le plasma? Tout d'abord, il n'y a pas besoin d'opérateurs semi-fiables. Dans ZK Rollup, la validité étant vérifiée par des preuves cryptographiques, il n’existe aucun moyen pour un émetteur de package d’être malveillant (en fonction de la configuration, un émetteur malveillant peut provoquer l’arrêt du système pendant quelques secondes. peut être fait). En cumul optimiste, un émetteur malveillant peut publier un bloc incorrect, mais le prochain émetteur défiera immédiatement ce bloc avant de publier le sien. Tant dans ZK que dans le cumul optimiste, suffisamment de données sont publiées sur la chaîne pour permettre à quiconque de calculer l'état interne complet, simplement en traitant tous les deltas soumis dans l'ordre, et il n'y a pas d '«attaque par retenue de données» susceptible d'enlever cette propriété. Par conséquent, devenir un opérateur peut être totalement sans permission; tout ce qui est nécessaire est un dépôt de garantie (par exemple 10 ETH) à des fins anti-spam.

Deuxièmement, le cumul optimiste est beaucoup plus facile à généraliser; la fonction de transition d'état dans un système cumulatif optimiste peut être littéralement tout ce qui peut être calculé dans la limite de gaz d'un seul bloc (y compris les branches de Merkle fournissant les parties de l'état nécessaires pour vérifier la transition). ZK Rollup est théoriquement généralisable de la même manière, même si, dans la pratique, il est très difficile de faire ZK SNARK au-dessus d’un calcul général (tel que l’exécution de MVE), du moins pour le moment. Troisièmement, il est beaucoup plus facile de créer des clients pour le cumul cumulatif, car l’infrastructure réseau de seconde couche est moins nécessaire; davantage peut être fait en scannant simplement la blockchain.

Mais d'où viennent ces avantages? La réponse réside dans un problème très technique connu sous le nom de problème de disponibilité des données (voir Remarque, vidéo). Fondamentalement, il existe deux façons d’essayer de tricher dans un système de couche 2. La première consiste à publier des données non valides dans la blockchain. La seconde est de ne pas publier de données du tout (par exemple dans Plasma, publier le hachage racine d’un nouveau bloc Plasma dans la chaîne principale mais sans en révéler le contenu à qui que ce soit). Il est très facile de traiter des données publiées mais non valides, car une fois que les données sont publiées dans la chaîne, il existe de nombreuses façons de déterminer sans ambiguïté si elles sont valides ou non, et une soumission invalide est non invalide de sorte que le demandeur peut être lourdement pénalisé. . Les données indisponibles, en revanche, sont beaucoup plus difficiles à gérer, car même si une indisponibilité peut être détectée si elle est contestée, il est impossible de déterminer de manière fiable de qui est la faute de la non-publication, en particulier si les données sont conservées par défaut et révélées uniquement à la demande. quand un mécanisme de vérification essaie de vérifier sa disponibilité. Ceci est illustré dans le «dilemme du pêcheur», qui montre comment un jeu défi-réponse ne peut pas faire la distinction entre les auteurs malveillants et les concurrents malveillants:


fisherman dilemma 1

Le dilemme du pêcheur. Si vous ne commencez à regarder qu'une donnée spécifique à l'instant T3, vous ne savez pas si vous vivez dans le cas 1 ou le cas 2, et par conséquent, qui est en faute.

Le plasma et les canaux contournent le dilemme du pêcheur en renvoyant le problème aux utilisateurs: si vous décidez qu'un autre utilisateur avec lequel vous interagissez (une contrepartie dans un canal d'état, un opérateur dans une chaîne Plasma) ne vous publie pas de données. qu’ils devraient publier, c’est à vous qu’il incombe de sortir et de passer à une autre contrepartie / opérateur. Le fait qu’en tant qu’utilisateur, vous avez tous les précédent données, et données sur toutes les transactions vous signé, vous permet de prouver à la chaîne quels actifs vous avez conservés dans le protocole de couche 2 et de les faire sortir en toute sécurité du système. Vous prouvez l'existence d'une opération (précédemment acceptée) qui vous a donné l'actif. Personne d'autre ne peut prouver l'existence d'une opération approuvée par vous qui a envoyé l'actif à quelqu'un d'autre. Vous obtenez donc l'actif.

La technique est très élégante. Cependant, il repose sur une hypothèse clé: chaque objet d’état a un «propriétaire» logique, et l’état de l’objet ne peut être modifié sans le consentement de ce dernier. Cela fonctionne bien pour les paiements basés sur UTXO (mais pas les paiements basés sur un compte, où pouvez modifier le solde de quelqu'un d'autre ascendant sans leur consentement; c'est pourquoi le plasma basé sur les comptes est si difficile), et on peut même le faire fonctionner pour un échange décentralisé, mais cette propriété de «propriété» est loin d'être universelle. Certaines applications, par exemple. Uniswap n’ayant pas de propriétaire naturel, et même dans les applications qui en ont, plusieurs personnes peuvent légitimement modifier légitimement l’objet. Et il n'y a aucun moyen d'autoriser des tiers arbitraires à quitter un actif sans introduire la possibilité d'attaques par déni de service (DoS), précisément parce qu'on ne peut pas prouver que l'éditeur ou le fournisseur est en faute.

Il existe d'autres problèmes propres au plasma et aux canaux individuellement. Les canaux n'autorisent pas les transactions hors chaîne aux utilisateurs qui ne font pas déjà partie du canal (argument: supposons qu'il existe un moyen d'envoyer $ 1 à un nouvel utilisateur arbitraire à l'intérieur d'un canal. Cette technique pourrait alors être utilisée de nombreuses fois en parallèle de envoyer 1 $ à plus d’utilisateurs qu’il n’ya de fonds dans le système, brisant déjà sa garantie de sécurité). Le plasma nécessite que les utilisateurs stockent de grandes quantités de données d'historique, qui deviennent encore plus grandes lorsque différents actifs peuvent être entrelacés (par exemple, lorsqu'un actif est transféré conditionnellement au transfert d'un autre actif, comme dans un échange décentralisé avec un mécanisme de carnet d'ordres à une étape). ).

Les techniques de couche 2 de calcul hors chaîne des données sur la chaîne ne posant pas de problème de disponibilité des données, elles ne présentent aucune de ces faiblesses. ZK et le cumul optimiste prennent grand soin de mettre suffisamment de données en chaîne pour permettre aux utilisateurs de calculer l'état complet du système de couche 2, en veillant à ce que, si un participant disparaît, un nouveau puisse prendre la place. Le seul problème qu'ils ont est la vérification du calcul sans le faire en chaîne, ce qui est un problème beaucoup plus facile. Et les gains en évolutivité sont significatifs: environ 10 octets par transaction dans ZK Rollup, et un niveau similaire d’évolutivité peut être atteint en cumul optimiste en utilisant l’agrégation BLS pour agréger les signatures. Cela correspond à un maximum théorique d'environ 500 transactions par seconde aujourd'hui et de plus de 2000 après Istanbul.


Mais si vous voulez plus d'évolutivité? Il existe ensuite un large terrain d'entente entre les protocoles de couche 2 de données sur chaîne et de couche 2 de données hors chaîne, avec de nombreuses approches hybrides qui vous offrent l'un des avantages des deux. Pour donner un exemple simple, il est possible d’éviter l’explosion de stockage d’historique dans un échange décentralisé implémenté sur Plasma Cash en publiant un mappage indiquant les ordres appariés aux ordres (moins de 4 octets par ordre) de la chaîne:


Plasma Cash 0Plasma Cash 1Plasma Cash 2
La gauche: Données de l'historique qu'un utilisateur de Plasma Cash doit stocker s'il possède 1 pièce. Milieu: Données de l'historique qu'un utilisateur de Plasma Cash doit stocker s'il possède 1 pièce qui a été échangée avec une autre pièce à l'aide d'un échange atomique. Droite: Données de l'historique qu'un utilisateur de Plasma Cash doit stocker si la correspondance de commande est publiée sur la chaîne.

Même en dehors du contexte d'échange décentralisé, la quantité d'histoire que les utilisateurs doivent stocker dans Plasma peut être réduite en faisant en sorte que la chaîne Plasma publie périodiquement certaines données par utilisateur sur la chaîne. On pourrait aussi imaginer une plate-forme qui fonctionne comme le plasma dans le cas où un État Est-ce que avoir un «propriétaire» logique et fonctionne comme un ZK ou un cumul optimiste dans le cas contraire. Développeurs de plasma commencent déjà à travailler sur ce genre d'optimisations.

Il est donc fortement souhaitable que les développeurs de solutions d’extensibilité de couche 2 s’engagent davantage à publier au moins une fois par chaîne des données par utilisateur: cela accroît considérablement la facilité de développement, la généralité et la sécurité et réduit charge par utilisateur (par exemple, pas besoin pour les utilisateurs de stocker les données d'historique). Les pertes d'efficacité liées à cette opération sont également surestimées: même dans une architecture de couche 2 totalement hors chaîne, les utilisateurs qui déposent, se retirent et se déplacent entre des contreparties et des fournisseurs différents vont devenir un événement inévitable et fréquent. quelle que soit la quantité de données par utilisateur sur la chaîne. La route hybride ouvre la voie à un déploiement relativement rapide de contrats intelligents totalement généralisés de type Ethereum dans une architecture de quasi-couche 2.

Voir également:



Traduction de l’article de : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Les Plus Populaires

Acheter des Bitcoin

Acheter des Alt-Coins

Sécuriser vos Cryptos

Vêtements et Produits Dérivés

Top
elementum porta. Aliquam luctus dictum lectus