Différents types de couches 2

Nous remercions tout particulièrement Karl Floersch pour ses commentaires et sa révision.

L'écosystème de la couche 2 d'Ethereum s'est rapidement développé au cours de l'année écoulée. L'écosystème des rollups EVM, traditionnellement composé d'Arbitrum, Optimism et Scroll, et plus récemment de Kakarot et Taiko, a progressé rapidement, faisant de grands progrès dans l'amélioration de leur sécurité ; la page L2beat fait un bon travail pour résumer l'état de chaque projet. En outre, nous avons vu des équipes construisant des sidechains commencer à construire des rollups(Polygon), des projets de couche 1 cherchant à devenir des validiums(Celo), et des efforts totalement nouveaux(Linea, Zeth...). Enfin, il y a l'écosystème qui ne se limite pas à l'EVM : des "presque-EVM" comme Zksync, des extensions comme Arbitrum Stylus, et des efforts plus larges comme l'écosystème Starknet, Fuel et d'autres.

L'une des conséquences inévitables de cette évolution est que nous constatons une tendance à l'hétérogénéité des projets de la couche 2. Je m'attends à ce que cette tendance se poursuive, pour quelques raisons essentielles :

• Certains projets qui sont actuellement des couches 1 indépendantes cherchent à se rapprocher de l'écosystème Ethereum, et éventuellement à devenir des couches 2. Ces projets nécessiteront probablement une transition progressive. La transition en une seule fois entraînerait une diminution de la facilité d'utilisation, car la technologie n'est pas encore prête pour tout mettre sur un rollup. En procédant à la transition d'un seul coup, vous risquez de sacrifier l'élan et d'arriver trop tard pour être utile.
• Certains projets centralisés souhaitent donner à leurs utilisateurs davantage de garanties de sécurité et explorent pour ce faire des voies basées sur la blockchain. Dans de nombreux cas, il s'agit de projets qui auraient exploré les "chaînes de consortium autorisées" à une époque antérieure. En réalité, ils n'ont probablement besoin que d'un niveau de décentralisation "intermédiaire". En outre, leur débit souvent très élevé les rend inadaptés, même pour les rollups, du moins à court terme.
• Les applications non financières, comme les jeux ou les médias sociaux, veulent être décentralisées mais n'ont besoin que d'un niveau de sécurité intermédiaire. Dans le cas des médias sociaux, cela implique concrètement de traiter différemment les différentes parties de l'application : les activités rares et de grande valeur telles que l'enregistrement du nom d'utilisateur et la récupération du compte doivent faire l'objet d'un rollup, tandis que les activités fréquentes et de faible valeur telles que les messages et les votes requièrent moins de sécurité. Si une défaillance de la chaîne entraîne la disparition de votre poste, c'est un coût acceptable. Si une défaillance de la chaîne vous fait perdre votre compte, le problème est bien plus grave.

L'un des thèmes principaux est que si les applications et les utilisateurs qui sont aujourd'hui sur la couche 1 d'Ethereum seront en mesure de payer des frais de rollup plus faibles mais toujours visibles à court terme, les utilisateurs du monde non-blockchain ne le seront pas : il est plus facile de justifier un paiement de 0,10 $ si vous payiez 1 $ auparavant que si vous payiez 0 $ auparavant. Cela s'applique à la fois aux applications qui sont centralisées aujourd'hui et aux petites entreprises de niveau 1, qui ont généralement des frais très bas alors que leur base d'utilisateurs reste petite.

La question qui se pose naturellement est la suivante : lequel de ces compromis compliqués entre les rollups, les validiums et les autres systèmes est le plus judicieux pour une application donnée ?

Rollups vs validiums vs systèmes déconnectés

La première dimension de la sécurité par rapport à l'échelle que nous allons explorer peut être décrite comme suit : si vous disposez d'un actif émis sur L1, puis déposé sur L2, puis transféré à vous, quel niveau de garantie avez-vous que vous serez en mesure de ramener l'actif sur L1 ?

Une question parallèle se pose également : quel est le choix technologique qui aboutit à ce niveau de garantie, et quels sont les compromis de ce choix technologique ?

Nous pouvons décrire cela simplement à l'aide d'un graphique :

https://s3.ap-northeast-1.amazonaws.com/gimg.gateimg.com/learn/b05ca283dcc74f262ac7a71f340dc85fb3a13b11.png

Il convient de préciser qu'il s'agit d'un schéma simplifié et qu'il existe de nombreuses options intermédiaires. Par exemple :

• Entre le rollup et le validium : un validium où n'importe qui pourrait effectuer un paiement sur la chaîne pour couvrir le coût des frais de transaction, l'opérateur étant alors obligé de fournir certaines données à la chaîne sous peine de perdre un dépôt.
• Entre plasma et validium : un système Plasma offre des garanties de sécurité de type rollup avec une disponibilité des données hors chaîne, mais il ne prend en charge qu'un nombre limité d'applications. Un système pourrait proposer un EVM complet et offrir des garanties de niveau Plasma aux utilisateurs qui n'utilisent pas ces applications plus compliquées, et des garanties de niveau Valium aux utilisateurs qui les utilisent.

Ces options intermédiaires peuvent être considérées comme se situant sur un spectre entre le rollup et le validium. Mais qu'est-ce qui motive les demandes à choisir un point particulier de ce spectre, et non un point plus à gauche ou plus à droite ? Ici, il y a deux facteurs principaux :

1. Le coût de la disponibilité des données natives d'Ethereum, qui diminuera au fur et à mesure que la technologie s'améliorera. Le prochain hard fork d'Ethereum, Dencun, introduit l'EIP-4844 (alias "proto-danksharding"), qui fournit ~32 kB/sec de disponibilité de données sur la chaîne. Au cours des prochaines années, ce chiffre devrait augmenter par étapes au fur et à mesure que <a href="https://hackmd.io/@vbuterin/sharding_proposal"> full danksharding sera déployé, pour finalement atteindre une disponibilité de données d'environ 1,3 Mo/sec. Dans le même temps, les améliorations apportées à la compression des données nous permettront de faire plus avec la même quantité de données.
2. Les besoins propres de l'application : dans quelle mesure les utilisateurs souffriraient-ils de frais élevés ou d'un dysfonctionnement de l'application ? Les applications financières perdraient davantage en cas de défaillance de l'application ; les jeux et les médias sociaux impliquent beaucoup d'activité par utilisateur, et une activité de valeur relativement faible, de sorte qu'un compromis différent en matière de sécurité est logique pour eux.

En gros, ce compromis se présente comme suit :

Un autre type de garantie partielle mérite d'être mentionné : les pré-confirmations. Les pré-confirmations sont des messages signés par un ensemble de participants à un rollup ou à un validium qui disent "nous attestons que ces transactions sont incluses dans cet ordre, et la racine post-état est celle-ci". Ces participants peuvent très bien signer une pré-confirmation qui ne correspond pas à une réalité ultérieure, mais si c'est le cas, un dépôt est brûlé. Cela est utile pour les applications de faible valeur, comme les paiements de consommateurs, tandis que les applications de plus grande valeur, comme les transferts financiers de plusieurs millions de dollars, attendront probablement une confirmation "normale" soutenue par la sécurité totale du système.

Les pré-confirmations peuvent être considérées comme un autre exemple de système hybride, similaire à l'"hybride plasma / validium" mentionné ci-dessus, mais cette fois-ci hybride entre un rollup (ou validium) qui a une sécurité totale mais une latence élevée, et un système avec un niveau de sécurité beaucoup plus bas qui a une faible latence. Les applications qui ont besoin d'une latence plus faible bénéficient d'une sécurité moindre, mais peuvent vivre dans le même écosystème que les applications qui acceptent une latence plus élevée en échange d'une sécurité maximale.

Lire Ethereum en toute confiance

Une autre forme de connexion à laquelle on pense moins, mais qui est pourtant très importante, concerne la capacité d'un système à lire la blockchain Ethereum. Il s'agit notamment de pouvoir revenir en arrière si Ethereum revient en arrière. Pour comprendre l'intérêt d'une telle démarche, examinez la situation suivante :

Supposons que, comme le montre le diagramme, la chaîne Ethereum s'inverse. Il peut s'agir d'un contretemps temporaire au cours d'une époque, alors que la chaîne n'a pas été finalisée, ou d'une période de fuite d'inactivité au cours de laquelle la chaîne n'est pas finalisée pendant une longue période parce qu'un trop grand nombre de validateurs sont hors ligne.

Le pire scénario possible est le suivant. Supposons que le premier bloc de la chaîne supérieure lise des données du bloc le plus à gauche de la chaîne Ethereum. Par exemple, un utilisateur d'Ethereum dépose 100 ETH dans la chaîne supérieure. Ensuite, Ethereum revient en arrière. Toutefois, la chaîne supérieure n'est pas inversée. Par conséquent, les futurs blocs de la chaîne supérieure suivent correctement les nouveaux blocs de la chaîne Ethereum nouvellement corrigée, mais les conséquences de l'ancien lien désormais erroné (à savoir le dépôt de 100 ETH) font toujours partie de la chaîne supérieure. Cet exploit pourrait permettre d'imprimer de l'argent, en transformant l'ETH bridgé sur la chaîne supérieure en une réserve fractionnaire.

Il y a deux façons de résoudre ce problème :

1. La chaîne supérieure ne pouvait lire que les blocs finalisés d'Ethereum, de sorte qu'elle n'aurait jamais besoin de revenir en arrière.
2. La chaîne supérieure pourrait s'inverser si Ethereum s'inversait. Les deux permettent d'éviter ce problème. La première solution est plus facile à mettre en œuvre, mais elle peut entraîner une perte de fonctionnalité pendant une période prolongée si Ethereum entre dans une période de fuite d'inactivité. Cette dernière est plus difficile à mettre en œuvre, mais elle garantit la meilleure fonctionnalité possible à tout moment.

Notez que (1) comporte un cas limite. Si une attaque de 51 % sur Ethereum crée deux nouveaux blocs incompatibles qui apparaissent tous deux finalisés en même temps, la chaîne supérieure pourrait bien se verrouiller sur le mauvais bloc (c'est-à-dire sur le bloc le plus récent). celle que le consensus social d'Ethereum ne privilégie pas), et il faudrait revenir en arrière pour passer à la bonne. On peut soutenir qu'il n'est pas nécessaire d'écrire du code pour gérer ce cas à l'avance ; il pourrait simplement être géré par le hard-forking de la chaîne supérieure.

La capacité d'une chaîne à lire Ethereum en toute confiance est précieuse pour deux raisons :

1. Elle réduit les problèmes de sécurité liés à l'intégration des jetons émis sur Ethereum (ou d'autres L2) dans cette chaîne.
2. Il permet aux portefeuilles d'abstraction de compte qui utilisent l'architecture de stockage de clés partagées de détenir des actifs sur cette chaîne en toute sécurité.
3. est important, même si l'on peut dire que ce besoin est déjà largement reconnu. (Le point 2 est également important, car il signifie que vous pouvez disposer d'un portefeuille qui permet de changer facilement de clé et qui détient des actifs sur un grand nombre de chaînes différentes.

Le fait d'avoir un pont fait-il de vous un valide ?

Supposons que la chaîne supérieure commence par être une chaîne distincte et que quelqu'un mette sur Ethereum un contrat de transition. Un contrat pont est simplement un contrat qui accepte les en-têtes de blocs de la chaîne supérieure, vérifie que tout en-tête qui lui est soumis est accompagné d'un certificat valide montrant qu'il a été accepté par le consensus de la chaîne supérieure, et ajoute cet en-tête à une liste. Les applications peuvent s'appuyer sur cette base pour mettre en œuvre des fonctionnalités telles que le dépôt et le retrait de jetons. Une fois qu'un tel pont est en place, fournit-il l'une ou l'autre des garanties de sécurité des actifs que nous avons mentionnées plus tôt ?

Jusqu'à présent, pas encore ! Pour deux raisons :

1. Nous validons que les blocs ont été signés, mais pas que les transitions d'état sont correctes. Par conséquent, si vous avez un actif émis sur Ethereum déposé sur la chaîne supérieure et que les validateurs de la chaîne supérieure sont malhonnêtes, ils peuvent signer une transition d'état invalide qui vole ces actifs.
2. La chaîne supérieure n'a toujours aucun moyen de lire l'Ethereum. Par conséquent, vous ne pouvez même pas déposer des actifs natifs d'Ethereum sur la chaîne supérieure sans dépendre d'une autre passerelle tierce (éventuellement non sécurisée).

Maintenant, faisons du pont un pont de validation : il vérifie non seulement le consensus, mais aussi un ZK-SNARK prouvant que l'état de tout nouveau bloc a été calculé correctement.

Une fois cette opération effectuée, les validateurs de la chaîne supérieure ne peuvent plus voler vos fonds. Ils peuvent publier un bloc avec des données indisponibles, empêchant tout le monde de se retirer, mais ils ne peuvent pas voler (sauf en essayant d'obtenir une rançon pour les utilisateurs en échange de la révélation des données qui leur permettent de se retirer). Il s'agit du même modèle de sécurité qu'un validium.

Cependant, nous n'avons toujours pas résolu le deuxième problème : la chaîne supérieure ne peut pas lire Ethereum.

Pour ce faire, nous avons deux possibilités :

1. Placez un contrat pont validant les blocs Ethereum finalisés dans la chaîne supérieure.
2. Faites en sorte que chaque bloc de la chaîne supérieure contienne un hachage d'un bloc Ethereum récent, et ayez une règle de choix de fourche qui applique les liens de hachage. En d'autres termes, un bloc de la chaîne supérieure qui renvoie à un bloc Ethereum qui ne fait pas partie de la chaîne canonique est lui-même non canonique, et si un bloc de la chaîne supérieure renvoie à un bloc Ethereum qui était d'abord canonique, mais qui devient ensuite non canonique, le bloc de la chaîne supérieure doit lui aussi devenir non canonique.

Les liens violets peuvent être des liens de hachage ou un contrat de pont qui vérifie le consensus d'Ethereum.

Est-ce suffisant ? Il s'avère que ce n'est toujours pas le cas, en raison de quelques petits cas particuliers :

1. Que se passe-t-il si Ethereum est attaqué à 51 % ?
2. Comment gérez-vous les mises à jour de la fourche dure d'Ethereum ?
3. Comment gérez-vous les mises à jour hard fork de votre chaîne ?

Une attaque de 51 % sur Ethereum aurait des conséquences similaires à une attaque de 51 % sur la chaîne supérieure, mais en sens inverse. Une fourche dure d'Ethereum risque de rendre le pont d'Ethereum à l'intérieur de la chaîne supérieure non valide. Un engagement social à revenir en arrière si Ethereum revient sur un bloc finalisé, et à faire un hard-fork si Ethereum fait un hard-fork, est la manière la plus propre de résoudre ce problème. Un tel engagement pourrait bien ne jamais devoir être exécuté : vous pourriez avoir un gadget de gouvernance sur la chaîne supérieure qui s'active s'il voit une preuve d'une attaque possible ou d'un hard fork, et qui ne hard fork la chaîne supérieure que si le gadget de gouvernance échoue.

La seule réponse viable au point (3) est, malheureusement, de disposer d'une forme de gadget de gouvernance sur Ethereum qui puisse faire en sorte que le contrat pont sur Ethereum soit informé des mises à niveau hard-fork de la chaîne supérieure.

Résumé : les ponts de validation bidirectionnels sont presque suffisants pour faire d'une chaîne un validium. Le principal ingrédient restant est un engagement social selon lequel si quelque chose d'exceptionnel se produit dans Ethereum et que le pont ne fonctionne plus, l'autre chaîne procédera à un hard-fork en réponse.

Conclusions

La "connectivité à Ethereum" comporte deux dimensions essentielles :

1. Sécurité des retraits en Ethereum
2. Sécurité de la lecture d'Ethereum

Ces deux éléments sont importants et doivent être pris en compte différemment. Il existe un spectre dans les deux cas :

Notez que ces deux dimensions ont chacune deux façons distinctes de les mesurer (il y a donc en réalité quatre dimensions ?): la sécurité du retrait peut être mesurée par (i) le niveau de sécurité et (ii) le pourcentage d'utilisateurs ou de cas d'utilisation bénéficiant du niveau de sécurité le plus élevé, et la sécurité de la lecture peut être mesurée par (i) la rapidité avec laquelle la chaîne peut lire les blocs Ethereum, en particulier les blocs finalisés par rapport à tous les blocs, et (ii) la force de l'engagement social de la chaîne pour gérer les cas extrêmes tels que les attaques à 51 % et les fourches dures.

Les projets sont intéressants dans de nombreuses régions de cet espace de conception. Pour certaines applications, il est important de disposer d'une sécurité élevée et d'une connectivité étroite. Pour d'autres, un système plus souple est acceptable en vue d'une plus grande évolutivité. Dans de nombreux cas, il peut s'avérer optimal de commencer par une solution plus souple aujourd'hui et de passer à un couplage plus étroit au cours de la prochaine décennie, au fur et à mesure que la technologie s'améliore.

Clause de non-responsabilité：

1. Cet article est tiré de[Vitalik Buterin]. Tous les droits d'auteur appartiennent à l'auteur original[Vitalik Buterin]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.