Nouvel article de Vitalik Buterin : Quelle est la différence entre Ethereum L2 et le sharding de la couche d'exécution ?
Article original: Comment faire des couches 2s est-ce vraiment différent du partitionnement d'exécution ?
Compilé par : Odaily Planet Daily Asher
L’un des points que j’ai soulevés il y a deux ans et demi dans mon « Fin de partie " l'article était que , du moins techniquement, les différentes voies empruntées par la blockchain semblaient étonnamment similaires.
Dans les deux cas, il existe un grand nombre de transactions sur la chaîne, et le traitement de ces transactions nécessite : (i) beaucoup de calculs ; (ii) beaucoup de bande passante de données. Les nœuds Ethereum ordinaires, tels que le 2 To nœud d'archive reth exécutés sur l'ordinateur portable utilisé pour écrire cet article, ne sont pas assez puissants pour vérifier directement une telle quantité de données et de calculs, même avec un excellent travail d'ingénierie logicielle et Arbres Verkle . Au lieu de cela, dans le sharding L1 et centré sur le rollup monde, ZK-SNARK sont utilisés pour vérifier les calculs et DAS sont utilisés pour vérifier la disponibilité des données. Dans les deux cas, les DAS sont identiques et les ZK-SNARK sont la même technologie, sauf que dans un cas, il s'agit de code de contrat intelligent et dans l'autre, il s'agit d'une fonction sacrée du protocole. D'un point de vue technique réel, Ethereum fait du sharding, et les rollups font du sharding.
Cela conduit naturellement à la question : quelle est la différence entre ces deux mondes ? Une réponse est que les conséquences des erreurs de codage sont différentes : dans le monde du rollup, les pièces sont perdues, tandis que dans le monde du sharding, vous avez des échecs de consensus.
Mais on s’attend à ce que l’importance des bugs diminue à mesure que les protocoles se consolident et que les techniques de vérification formelle s’améliorent. Quelles sont donc les différences entre ces deux visions, et peut-on s’attendre à ce qu’elles perdurent à long terme ?
Diversité des environnements d'exécution
Une idée qui a été brièvement discutée dans Ethereum en 2019 était environnements d'exécution Essentiellement, Ethereum aurait différentes « zones » qui pourraient avoir des règles différentes sur le fonctionnement des comptes (y compris des approches complètement différentes comme UTXO), le fonctionnement de la machine virtuelle et d’autres fonctionnalités.
Cela permet une diversité d’approche entre les différentes parties de la pile, ce qui serait difficile à réaliser si Ethereum essayait de tout faire lui-même.
Au final, certains des projets les plus ambitieux ont été abandonnés, ne laissant que l'EVM. Cependant, on peut dire qu'Ethereum L2 (y compris les rollups, les valdiums et les plasmas) a finalement servi d'environnement d'exécution.
Aujourd’hui, l’accent est souvent mis sur les équivalents L2 de l’EVM, mais cela ignore la diversité de nombreuses approches alternatives :
-
Stylet Arbitrum : ajoute une deuxième machine virtuelle basée sur WASM à l'EVM ;
-
Carburant :utilise une architecture basée sur UTXO similaire à Bitcoin (mais plus complète) ;
-
Aztèque :Introduit un nouveau langage et un nouveau paradigme de programmation conçus autour de contrats intelligents préservant la confidentialité basés sur les ZK-SNARK.
Architecture basée sur UTXO Source : Document sur le carburant
Tenter de faire de l'EVM une super machine virtuelle couvrant tous les paradigmes possibles compromettrait la mise en œuvre de chaque concept, et il serait préférable de laisser ces plateformes se spécialiser.
Compromis de sécurité : échelle ou vitesse
Ethereum L1 offre des garanties de sécurité très solides. Si certaines données se trouvent à l'intérieur d'un bloc finalisé sur L1, l'ensemble du consensus (y compris le consensus social dans les cas extrêmes) veille à ce que ces données ne puissent pas être modifiées pour violer les règles de l'application qui a placé ces données à l'intérieur du bloc, à ce que toute exécution déclenchée par ces données ne puisse pas être annulée et à ce que ces données restent accessibles.
Pour obtenir 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 transactions L2 coûtent moins d'un centime chacune , et même L1 coûte moins de $1 pour un transfert ETH de base. Si la technologie progresse suffisamment rapidement et que la croissance de l'espace de bloc disponible suit la demande, ces frais pourraient rester bas à l'avenir, mais ce ne sera peut-être pas le cas.
Et pour de nombreuses applications non financières, comme les réseaux sociaux ou les jeux, même $0,01 par transaction est trop élevé. Mais les réseaux sociaux et les jeux n'ont pas besoin du même modèle de sécurité que L1. Peu importe que quelqu'un puisse revenir sur sa partie d'échecs perdue pour un million de dollars ou faire en sorte que l'un de vos tweets semble avoir été publié trois jours après sa publication réelle.
Par conséquent, ces applications ne devraient pas payer les mêmes coûts de sécurité. Les approches centrées sur L2 permettent cela en prenant en charge une gamme de méthodes de disponibilité des données de rollups à plasma à validiums .
Différents types de L2 conviennent à différents cas d'utilisation ( Cliquez ici pour en savoir plus )
Un autre compromis de sécurité se pose autour le problème du transfert d'actifs de L2 à L2 Il est prévu qu'à l'avenir (5 à 10 ans), tous les cumuls seront des cumuls ZK et des systèmes de preuve ultra-efficaces avec des fonctions de recherche telles que Binius et Cercle STARK , couplé à une couche d'agrégation de preuves, permettra à L2 de fournir des racines d'état final dans chaque intervalle de temps. Mais actuellement, il ne peut s'agir que d'un mélange complexe de cumuls optimistes et de cumuls ZK sous différentes fenêtres temporelles de preuve.
Si le sharding de la couche d'exécution avait été mis en œuvre en 2021, le modèle de sécurité pour garder les shards honnêtes aurait été des cumuls optimistes, et non ZK — donc L1 aurait dû gérer systémiquement complexe une logique anti-fraude sur la chaîne et une période de retrait d'une semaine lors du déplacement d'actifs entre les fragments. Mais comme le bug du code, ce problème était finalement temporaire.
La vitesse des transactions est le troisième aspect, plus permanent, du compromis de sécurité. Ethereum a un bloc toutes les 12 secondes et hésite à aller plus vite car cela centraliserait excessivement le réseau. Cependant, de nombreux L2 explorent des temps de blocage de quelques centaines de millisecondes.
12 secondes, ce n'est pas si mal : les utilisateurs qui soumettent des transactions doivent attendre environ 6 à 7 secondes en moyenne pour qu'elles soient incluses dans un bloc (et pas seulement 6 secondes, car le bloc suivant pourrait ne pas les inclure). C'est comparable au temps d'attente que vous devez attendre lorsque vous payez avec une carte de crédit. Mais de nombreuses applications nécessitent des vitesses plus élevées, et L2 peut les fournir.
Pour fournir cette vitesse supérieure, L2 s'appuie sur un mécanisme de pré-confirmation : les propres validateurs de L2 signent numériquement une promesse d'inclure la transaction à un certain moment, et si la transaction n'est pas incluse, ils seront punis. Un mécanisme appelé StakeSure va encore plus loin.
Pré-confirmation L2
On pourrait maintenant essayer d'implémenter tout cela au niveau L1. Le niveau L1 pourrait inclure un système de pré-confirmations rapides et de confirmations finales lentes. Il pourrait inclure différents fragments avec différents niveaux de sécurité. Cependant, cela augmenterait la complexité du protocole. De plus, faire tout le travail en L1 risquerait surcharge du consensus , car de nombreuses approches visant à une plus grande échelle ou à un débit plus rapide présentent des risques plus élevés de centralisation ou nécessitent des formes de gouvernance plus fortes, et si elles sont réalisées au niveau L1, l'impact de ces exigences plus strictes se répercuterait sur d'autres parties du protocole. En proposant ces compromis au niveau de la couche 2, Ethereum peut largement éviter ces risques.
À quels défis l’écosystème centré sur L2 d’Ethereum est-il confronté ?
L'approche centrée sur L2 d'Ethereum est confrontée à un défi majeur auquel les écosystèmes centrés sur L1 ne sont pas autant confrontés : la coordination. En d'autres termes, bien qu'il existe de nombreuses fourches d'Ethereum, le défi consiste à maintenir sa propriété fondamentale selon laquelle l'ensemble d'Ethereum ressemble à « Ethereum » et présente les effets de réseau d'Ethereum, plutôt que N chaînes indépendantes. Aujourd'hui, cette situation est insatisfaisante à bien des égards :
-
Déplacer des jetons de la couche 2 à une autre nécessite généralement des plateformes de pont centralisées et est très complexe pour l'utilisateur moyen. Si vous avez des jetons sur Optimism, vous ne pouvez pas simplement coller l'adresse Arbitrum de quelqu'un d'autre dans votre portefeuille et lui envoyer des fonds.
-
Prise en charge des portefeuilles de contrats intelligents inter-chaînes n'est pas très bon pour les portefeuilles de contrats intelligents personnels et les portefeuilles organisationnels (y compris les DAO). Si vous changez la clé sur un L2, vous devez également changer la clé sur tous les autres L2.
-
L’infrastructure de validation décentralisée fait généralement défaut. Ethereum commence enfin à avoir des clients légers décents, tels que Hélios . Mais cela n'a pas de sens si toute l'activité se déroule sur L2, qui nécessite son propre RPC centralisé. En principe, il n'est pas difficile de créer des clients légers pour L2 une fois que vous avez une chaîne principale Ethereum ; mais dans la pratique, trop peu d'attention a été accordée à cela.
Des efforts sont en cours pour améliorer ces trois éléments. Pour les échanges de jetons inter-chaînes, le ERC-7683 La norme est une option émergente qui, contrairement aux « ponts centralisés » existants, n’a pas d’opérateur central fixe, de jeton ou d’organe directeur.
Pour les comptes inter-chaînes, la plupart des portefeuilles adoptent l'approche consistant à utiliser des informations rejouables inter-chaînes pour mettre à jour les clés à court terme et magasins de clés à long terme. Des clients légers pour L2 commencent à apparaître, tels que Bière pour le réseau Starknet. De plus, les efforts récents pour améliorer l'expérience utilisateur grâce aux portefeuilles de nouvelle génération ont résolu certains problèmes plus fondamentaux, comme le fait que les utilisateurs n'ont plus besoin de basculer manuellement vers le bon réseau pour accéder aux dapps.
Rabby affiche une vue complète des soldes d'actifs sur plusieurs chaînes (quelque chose que les portefeuilles n'avaient pas jusqu'à récemment)
Mais il est important de reconnaître qu’un écosystème centré sur L2 nage dans une certaine mesure à contre-courant lorsqu’il essaie de se coordonner.
Les institutions individuelles de L2 n’ont aucune incitation économique naturelle à construire une infrastructure de coordination : les petites institutions de L2 ne le font pas, car elles ne peuvent tirer qu’une petite partie des bénéfices de leurs contributions ; les grandes institutions de L2 ne le font pas, car elles peuvent gagner autant, voire plus, en renforçant leurs propres effets de réseau local.
Ce n'est pas comme s'il existait une solution magique parfaite à ce problème. C'est juste que l'écosystème doit reconnaître plus pleinement que l'infrastructure cross-L2 est un type d'infrastructure Ethereum, tout comme les clients L1, les outils de développement et les langages de programmation, et qu'elle doit être valorisée et financée. Guilde du Protocole , et peut-être la Guilde des infrastructures de base.
résumé
Dans les discussions publiques, le sharding de la couche 2 d'Ethereum et de la couche d'exécution sont souvent décrits comme deux stratégies opposées pour faire évoluer les blockchains. Cependant, lorsque l'on examine la technologie sous-jacente, une énigme apparaît : les méthodes de mise à l'échelle sous-jacentes sont exactement les mêmes, La principale différence étant : qui est responsable de la construction et de la mise à jour des composants correspondants, et de quel degré d'autonomie disposent-ils ?
L'écosystème Ethereum L2-centric est un sharding au sens technique du terme, mais dans le cadre du sharding, vous pouvez créer votre propre shard avec vos propres règles. Cette approche est très puissante et permet beaucoup de créativité et d'innovation autonome. Mais elle présente également des défis majeurs, notamment en termes de coordination.
Pour qu’un écosystème centré sur L2 comme Ethereum réussisse, il doit comprendre ces défis et les relever de front pour tirer le plus d’avantages possible d’un écosystème centré sur L1 et se rapprocher le plus possible du meilleur des deux mondes.
Cet article provient d'Internet : Nouvel article de Vitalik Buterin : Quelle est la différence entre Ethereum L2 et le sharding de la couche d'exécution ?
Source : CapitalismLab Le prix d'Aerdromes a traversé un tour, et Base a soutenu à lui seul le pic de 1 B Mcap, 2B FDV, cent fois la pièce, montrant ses muscles. Les externalités positives qu'il a apportées ont également revitalisé davantage l'écosystème de Base. D'un autre côté, BSC n'a fait aucun progrès même après la chute de ce tour. Où est l'écart ? Ce fil de discussion utilisera cela comme point de départ pour discuter et commenter l'écart entre les deux CEX de la chaîne dans ce tour. La raison pour laquelle Coinbase a retiré Aero est très simple. Comme le montre la figure ci-dessous, dans le passé, les projets ont incité les mineurs DeFi avec des incitations directes. Par exemple, pour un jeton de projet d'une valeur de $2, un mineur peut obtenir $1 supplémentaire du DEX…