L'un des points que j'ai soulevés dans mon article il y a deux ans et demi sur "the Endgame"est que les différents chemins de développement futur pour une blockchain, du moins technologiquement, semblent étonnamment similaires. Dans les deux cas, vous avez un très grand nombre de transactions onchain, et les traiter nécessite (i) une grande quantité de calcul, et (ii) une grande quantité de bande passante. Les nœuds Ethereum réguliers, tels que les 2 TB nœud d'archive rethen cours d'exécution sur l'ordinateur portable que j'utilise pour écrire cet article, ne sont pas assez puissants pour vérifier une telle quantité énorme de données et de calculs directement, même avec un travail d'ingénierie logicielle héroïque etVerkle arbres. Au lieu de cela, à la fois le "sharding L1" et un centré sur le rollupmonde, ZK-SNARKssont utilisées pour vérifier les calculs et DASpour vérifier la disponibilité des données. Le DAS dans les deux cas est le même. Les ZK-SNARKs dans les deux cas sont la même technologie, sauf que dans un cas, ils sont du code de contrat intelligent et dans l'autre cas, ils sont une caractéristique consacrée du protocole. Dans un sens technique très réel, Ethereum fait du sharding, et les rollups sont des shards.

Cela soulève une question naturelle : quelle est la différence entre ces deux mondes ? Une réponse est que les conséquences des bugs de code sont différentes : dans un monde de rollup, les pièces sont perdues, et dans un monde de chaîne shard, vous avez des échecs de consensus. Mais je m'attends à ce que, à mesure que les protocoles se solidifient et que la technologie de vérification formelle s'améliore, l'importance des bugs diminue. Alors, quelles sont les différences entre les deux visions auxquelles nous pouvons nous attendre à long terme ?

Diversité des environnements d'exécution

L'une des idées avec lesquelles nous avons brièvement joué dans Ethereum en 2019 était environnements d'exécutionEssentiellement, Ethereum aurait différentes “zones” qui pourraient avoir des règles différentes pour le fonctionnement des comptes (y compris des approches totalement différentes comme les UTXO), le fonctionnement de la machine virtuelle et d'autres fonctionnalités. Cela permettrait une diversité d'approches dans des parties de la pile où il serait difficile d'atteindre si Ethereum devait essayer de tout faire par lui-même.

Finalement, nous avons fini par abandonner certains des plans les plus ambitieux et avons simplement conservé l'EVM. Cependant, les L2 d'Ethereum (y compris les rollups, les valdiums et les Plasmas) ont fini par servir le rôle d'environnements d'exécution. Aujourd'hui, nous nous concentrons généralement sur les L2 équivalents à l'EVM, mais cela ignore la diversité de nombreuses approches alternatives :

• Arbitrum Stylus, qui ajoute une deuxième machine virtuelle basée sur WASMaux côtés de l'EVM.
• Carburant, qui utilise une architecture basée sur UTXO similaire à Bitcoin (mais plus complète en termes de fonctionnalités).
• Aztec, qui introduit un nouveau langage et un paradigme de programmation conçu autour de contrats intelligents préservant la confidentialité basés sur ZK-SNARK.

Architecture basée sur les UTXO. Source : documentation Fuel.

Nous pourrions essayer de transformer l'EVM en un super-VM qui couvre tous les paradigmes possibles, mais cela aurait entraîné des implémentations beaucoup moins efficaces de chacun de ces concepts que de permettre à des plates-formes comme celles-ci de se spécialiser.

Compromis en matière de sécurité : échelle et vitesse

Ethereum L1 fournit une garantie de sécurité vraiment forte. Si une partie des données se trouve à l'intérieur d'un bloc finalisé sur L1, l'ensemble du consensus (y compris, dans des situations extrêmes, le consensus social) travaille pour garantir que les données ne seront pas modifiées de manière à aller à l'encontre des règles de l'application qui a placé ces données là, que toute exécution déclenchée par les données ne sera pas annulée, et que les données resteront accessibles. Pour atteindre ces garanties, Ethereum L1 est prêt à accepter des coûts élevés. Au moment de la rédaction de cet article, les frais de transaction sont relativement faibles: les couches 2 facturent moins d'un centpar transaction, et même le L1 est inférieur à 1 $ pour un transfert ETH de base. Ces coûts peuvent rester faibles à l'avenir si la technologie s'améliore suffisamment rapidement pour que l'espace de bloc disponible augmente afin de répondre à la demande - mais cela peut ne pas être le cas. Même 0,01 $ par transaction est trop élevé pour de nombreuses applications non financières, par exemple les médias sociaux ou les jeux.

Mais les médias sociaux et les jeux ne nécessitent pas le même modèle de sécurité que L1. Il est acceptable que quelqu'un puisse payer un million de dollars pour annuler un enregistrement de sa défaite à une partie d'échecs, ou faire paraître l'un de vos messages sur Twitter comme s'il avait été publié trois jours après sa date réelle. Ainsi, ces applications ne devraient pas avoir à supporter les mêmes coûts de sécurité. Une approche centrée sur L2 permet cela, en soutenant un éventail d'approches de disponibilité des données allant derollupsàplasma à validiums.

Différents types de L2 pour différents cas d'utilisation. En savoir plus ici.

Un autre compromis en matière de sécurité se pose autour de la question du transfert d'actifs de L2 à L2. À terme (d'ici 5 à 10 ans), je m'attends à ce que tous les rollups soient des rollups ZK, et des systèmes de preuve hyper-efficaces comme BiniusetCercle STARKsavecrecherches, plus couches d'agrégation de preuves, permettra aux L2 de fournir des racines d'état finalisées dans chaque fente. Pour l'instant, cependant, nous avons un mélange compliqué de rollups optimistes et de rollups ZK avec diverses fenêtres temporelles de preuve. Si nous avions mis en œuvre le sharding d'exécution en 2021, le modèle de sécurité pour maintenir l'honnêteté des shards aurait été des rollups optimistes, pas ZK - et donc L1 aurait dû gérer le systémiquement complexelogique de preuve de fraude sur la chaîne et avoir une période de retrait d'une semaine pour déplacer des actifs d'un fragment à un autre. Mais comme les bugs de code, je pense que ce problème est finalement temporaire.

Un troisième dimension, et une fois de plus plus durable, du compromis de sécurité est la vitesse des transactions. Ethereum a des blocs toutes les 12 secondes et ne veut pas aller beaucoup plus vite car cela centraliserait trop le réseau. Cependant, de nombreux L2 explorent des temps de bloc de quelques centaines de millisecondes. 12 secondes n'est déjà pas si mal : en moyenne, un utilisateur qui soumet une transaction doit attendre environ 6-7 secondes pour être inclus dans un bloc (pas seulement 6 à cause de la possibilité que le bloc suivant ne les inclura pas). Cela est comparable à ce que je dois attendre lorsque je fais un paiement avec ma carte de crédit. Mais de nombreuses applications exigent une vitesse beaucoup plus élevée, et les L2 la fournissent.

Pour fournir cette vitesse plus élevée, les L2 s'appuient sur des mécanismes de préconfirmation : les validateurs propres au L2 signent numériquement une promesse d'inclure la transaction à un moment particulier, et s'il la transaction n'est pas incluse, ils peuvent être pénalisés. Un mécanisme appelé StakeSuregénéralise cela davantage.

L2 préconfirmations.

Maintenant, nous pourrions essayer de faire tout cela sur la couche 1. La couche 1 pourrait incorporer un système de "pré-confirmation rapide" et "confirmation finale lente". Elle pourrait incorporer différents fragments avec différents niveaux de sécurité. Cependant, cela ajouterait beaucoup de complexité au protocole. De plus, tout faire sur la couche 1 comporterait des risquessurchargeant le consensus, parce que bon nombre des approches à grande échelle ou à débit plus rapide présentent des risques de centralisation plus élevés ou nécessitent des formes plus fortes de « gouvernance », et si cela est fait au niveau L1, les effets de ces demandes plus fortes se répercuteraient sur le reste du protocole. En offrant ces compromis à travers les couches 2, Ethereum peut en grande partie éviter ces risques.

Les avantages des couches 2 sur l'organisation et la culture

Imaginez qu'un pays soit coupé en deux, et qu'une moitié devienne capitaliste et l'autre soit fortement dirigée par le gouvernement (contrairement à ce qui s'est passécela se produitdansréalité, supposez que dans cette expérience de pensée, ce n'est pas le résultat d'une sorte de guerre traumatique; plutôt, un jour, une frontière se lève magiquement et c'est tout). Dans la partie capitaliste, les restaurants sont tous gérés par diverses combinaisons de propriété décentralisée, de chaînes et de franchises. Dans la partie dirigée par le gouvernement, ce sont toutes des succursales du gouvernement, comme des postes de police. Le premier jour, pas grand-chose ne changerait. Les gens suivent largement leurs habitudes existantes, et ce qui fonctionne et ce qui ne fonctionne pas dépend de réalités techniques comme les compétences en matière de main-d'œuvre et d'infrastructure. Un an plus tard, cependant, vous vous attendriez à voir de grands changements, car les différentes structures d'incitations et de contrôle entraînent de grands changements de comportement, qui affectent qui vient, qui reste et qui part, ce qui est construit, ce qui est entretenu, et ce qui est laissé à l'abandon.

Organisation industriellela théorie couvre bon nombre de ces distinctions : elle parle non seulement des différences entre une économie dirigée par le gouvernement et une économie capitaliste, mais aussi entre une économie dominée par de grandes franchises et une économie où par exemple chaque supermarché est géré par un entrepreneur indépendant. Je soutiendrais que la différence entre un écosystème centré sur la couche 1 et un écosystème centré sur la couche 2 suit des lignes similaires.

Une architecture "les développeurs principaux contrôlent tout" très mal tournée.

Je formulerais l'avantage clé pour Ethereum d'être un écosystème centré sur la couche 2 comme suit :

Parce qu'Ethereum est un écosystème centré sur la couche 2, vous êtes libre de construire indépendamment un sous-écosystème qui vous appartient avec vos caractéristiques uniques, tout en faisant partie d'un plus grand Ethereum.

Si vous créez simplement un client Ethereum, vous faites partie d'un plus grand Ethereum, et bien que vous ayez un certain espace pour la créativité, il est bien moins que ce qui est disponible pour les L2. Et si vous créez une chaîne complètement indépendante, vous avez un espace maximal pour la créativité, mais vous perdez les avantages tels que la sécurité partagée et les effets de réseau partagés. Les L2s forment un juste milieu.

Les couches 2 ne créent pas seulement une opportunité technique pour expérimenter de nouveaux environnements d'exécution et compromis de sécurité pour atteindre l'échelle, la flexibilité et la vitesse : elles créent également une incitation à : à la fois pour les développeurs de le construire et de le maintenir, et pour la communauté de se former autour et de le soutenir.

Le fait que chaque L2 soit isolé signifie également que le déploiement de nouvelles approches est sans permission : il n'est pas nécessaire de convaincre tous les développeurs principaux que votre nouvelle approche est "sûre" pour le reste de la chaîne. Si votre L2 échoue, c'est votre responsabilité. N'importe qui peut travailler sur des idées totalement étranges (par ex. L'approche d'Intmax envers Plasma) et même s'ils sont complètement ignorés par les développeurs principaux d'Ethereum, ils peuvent continuer à construire et éventuellement déployer. Les fonctionnalités de L1 et les précompilations ne sont pas comme ça, et même dans Ethereum, ce qui réussit et ce qui échoue dans le développement de L1 finit souvent par dépendre de la politique dans une mesure plus élevée que nous le voudrions. Indépendamment de ce qui pourrait théoriquement être construit, les incitations distinctes créées par un écosystème centré sur L1 et un écosystème centré sur L2 finissent par influencer fortement ce qui se construit en pratique, avec quel niveau de qualité et dans quel ordre.

Quels défis rencontre l'écosystème centré sur la couche 2 d'Ethereum ?

Une architecture de couche 1 + couche 2 qui a très mal tourné.Source.

Il y a un défi clé à ce type d'approche centrée sur la couche 2, et c'est un problème auquel les écosystèmes centrés sur la couche 1 n'ont pas à faire face dans la même mesure : la coordination. En d'autres termes, alors qu'Ethereum se diversifie, le défi réside dans la préservation de la propriété fondamentale selon laquelle tout doit encore donner l'impression d'être de l'"Ethereum", et bénéficier des effets de réseau d'être Ethereum plutôt que d'être N chaînes séparées. Aujourd'hui, la situation est suboptimale à bien des égards :

• Transférer des jetons d'une couche 2 à une autre nécessite souvent des plateformes de pont centralisées, et est compliqué pour l'utilisateur moyen. Si vous avez des pièces sur Optimism, vous ne pouvez pas simplement coller l'adresse d'Arbitrum de quelqu'un dans votre portefeuille et leur envoyer des fonds.
• Le support du portefeuille de contrat intelligent inter-chaînes n'est pas excellent, que ce soit pour les portefeuilles de contrat intelligent personnels ou pour les portefeuilles organisationnels (y compris les DAO). Si vous changez votre clé sur une L2, vous devez également aller changer votre clé sur chaque autre L2.
• L'infrastructure de validation décentralisée fait souvent défaut. Ethereum commence enfin à disposer de clients légers décents, tels que HeliosCependant, cela n'a aucun intérêt si toute l'activité se déroule sur des couches 2 qui nécessitent toutes leurs propres RPC centralisées. En principe, une fois que vous avez la chaîne d'en-têtes Ethereum, créer des clients légers pour les L2 n'est pas difficile ; en pratique, il y a beaucoup trop peu d'accent mis dessus.

Il existe des efforts visant à améliorer tous les trois. Pour l'échange de jetons inter-chaînes, le ERC-7683standard est une option émergente, et contrairement aux "ponts centralisés" existants, il n'a pas d'opérateur central, de jeton ou de gouvernance consacrés. Pour les comptes inter-chaînes, l'approche adoptée par la plupart des portefeuilles est d'utiliser des messages reproductibles inter-chaînes pour mettre à jour les clés à court terme, et rouleaux de dépôtà plus long terme. Les clients légers pour les L2 commencent à émerger, par exemple. Beeruspour Starknet. De plus, les améliorations récentes de l'expérience utilisateur grâce aux portefeuilles de nouvelle génération ont déjà résolu des problèmes beaucoup plus basiques, comme l'élimination de la nécessité pour les utilisateurs de basculer manuellement vers le bon réseau pour accéder à une dapp.

Rabby montrant une vue intégrée des soldes d'actifs sur plusieurs chaînes. Dans les sombres vieux jours pas si lointains, les portefeuilles ne faisaient pas cela!

Mais il est important de reconnaître que les écosystèmes centrés sur la couche 2 nagent à contre-courant dans une certaine mesure lorsqu'ils essaient de se coordonner. Les couches 2 individuelles n'ont pas d'incitation économique naturelle à construire l'infrastructure de coordination : les petites n'en voient pas l'intérêt, car elles ne bénéficieraient que d'une petite part des avantages de leurs contributions, et les grandes non plus, car elles bénéficieraient autant, voire plus, en renforçant leurs propres effets de réseau locaux. Si chaque couche 2 optimise séparément son morceau individuel, et que personne ne réfléchit à la manière dont chaque morceau s'intègre dans l'ensemble plus large, nous rencontrons des échecs comme la dystopie urbanistique dans l'image quelques paragraphes plus haut.

Je ne prétends pas avoir des solutions parfaites magiques à ce problème. Le mieux que je puisse dire, c'est que l'écosystème doit reconnaître plus pleinement que l'infrastructure inter-L2 est un type d'infrastructure Ethereum, aux côtés des clients L1, des outils de développement et des langages de programmation, et devrait être valorisée et financée en conséquence. Nous avons Protocole Guild; peut-être avons-nous besoin de la Guilde de l'Infrastructure de Base.

Conclusions

Les «Layer 2» et le «sharding» sont souvent décrits dans le discours public comme étant deux stratégies opposées pour mettre à l'échelle une blockchain. Mais lorsque vous regardez la technologie sous-jacente, il y a un puzzle : les approches sous-jacentes réelles de mise à l'échelle sont exactement les mêmes. Vous avez une sorte de fragmentation des données. Vous avez des prouveurs de fraude ou des prouveurs de ZK-SNARK. Vous avez des solutions pour la communication inter-{rollup, shard}. La principale différence est : qui est responsable de la construction et de la mise à jour de ces éléments, et quelle autonomie ont-ils ?

Un écosystème centré sur la couche 2 fait du sharding dans un sens technique très réel, mais c'est du sharding où vous pouvez créer votre propre shard avec vos propres règles. C'est puissant et permet beaucoup de créativité et d'innovation indépendante. Mais cela comporte également des défis clés, en particulier en matière de coordination. Pour qu'un écosystème centré sur la couche 2 comme Ethereum réussisse, il doit comprendre ces défis et y faire face de front, afin de tirer autant d'avantages que possible des écosystèmes centrés sur la couche 1, et se rapprocher le plus possible d'avoir le meilleur des deux mondes.

Avertissement：

1. Cet article est repris de [Gatevitalik] Transférer le titre original 'Comment les couches 2 diffèrent-elles vraiment du sharding d'exécution ?', S'il y a des objections à cette reproduction, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.

2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.