Vitalik's new work: What is the difference between L2 and execution sharding?

Texte : Vitalik Buterin

Peng Sun, Foresight News.

Deux ans et demi auparavant, dans l’article “Endgame”, j’ai mentionné que les différentes voies de développement futures de la blockchain semblaient être très similaires sur le plan technique. Dans les deux cas, il y a un grand nombre de transactions sur la chaîne, et le traitement de ces transactions nécessite : (1) une grande puissance de calcul ; (2) une grande bande passante de données. Même avec une puissance de calcul logicielle puissante et les arbres Verkle, les nœuds Ethereum ordinaires (comme le nœud d’archive reth de 2 To que j’exécute actuellement sur mon ordinateur) ne suffisent pas à vérifier directement de grandes quantités de données et de calculs massifs. Au contraire, dans les deux solutions “L1 Sharding” et “Rollup-centric”, le ZK-SNARK est utilisé pour vérifier les calculs, tandis que le DAS est utilisé pour vérifier la disponibilité des données. Que ce soit pour le sharding L2 ou le Rollup, le DAS est le même, tout comme la technologie ZK-SNARK. Ils sont à la fois du code de contrat intelligent et une fonction du protocole. Du point de vue technique réel, Ethereum est en train de se fragmenter, et Rollup est une forme de fragmentation.

Cela soulève naturellement une question: quelles sont les différences entre les deux ? L’une des différences réside dans les conséquences des vulnérabilités du code: dans Rollup, les jetons sont volés; dans le sharding, le consensus est rompu. Cependant, je m’attends à ce que, avec la stabilité du protocole et les améliorations de la vérification formelle, l’impact des vulnérabilités du code devienne de plus en plus faible. Donc, quelles sont les autres différences entre ces deux solutions qui pourraient exister à long terme ?

Le plus long des environnements d’exécution

En 2019, une idée que nous avons brièvement discutée dans Ethereum est l’exécution de l’environnement. Fondamentalement, Ethereum aura différentes “zones” qui peuvent définir des règles différentes pour les comptes (y compris des méthodes totalement différentes telles que UTXO), le fonctionnement de la machine virtuelle et d’autres fonctionnalités. Cela permettrait d’apporter une diversité de méthodes dans différentes parties de la pile, mais cela serait difficile à réaliser si Ethereum essaie de tout intégrer en une seule entité.

Finalement, nous avons abandonné certains plans plus ambitieux et avons seulement conservé EVM. Cependant, Ethereum L2 (y compris rollups, valdiums et Plasmas) peut être considéré comme ayant finalement joué un rôle d’environnement d’exécution. Actuellement, nous nous concentrons généralement sur EVM équivalent à L2, mais nous négligeons en réalité la diversité apportée par de nombreuses autres méthodes.

• Arbitrum Stylus, il ajoute un deuxième oracle basé sur WASM en dehors de l’EVM ;
• Fuel, qui utilise une architecture basée sur UTXO similaire à Bitcoin (mais plus complète) ;
• Aztec, il introduit un nouveau langage et un paradigme de programmation basé sur la protection de la vie privée ZK-SNARK pour la conception de contrats intelligents.

Architecture basée sur UTXO, source : Documentation sur les carburants

Nous pouvons essayer de transformer l’EVM en une machine virtuelle superpuissante qui couvre tous les paradigmes possibles, mais cela réduirait considérablement l’efficacité de chaque fonctionnalité. Il vaut mieux laisser ces plates-formes faire leur travail spécialisé.

Sécurité compromis : évolutivité et vitesse de transaction

La couche 1 d’Ethereum offre une sécurité très solide. Si certaines données sont incluses dans les blocs finaux de la couche 1, l’ensemble du consensus (y compris dans des situations extrêmes de consensus social) s’efforcera de garantir que ces données ne seront pas modifiées, de garantir que toute exécution déclenchée par ces données ne sera pas annulée et que ces données resteront accessibles. Pour assurer cette sécurité, la couche 1 d’Ethereum accepte des coûts élevés. Au moment de la rédaction de cet article, les frais de transaction sont relativement bas : les transactions sur la couche 2 coûtent moins d’un centime de dollar, même sur la couche 1, les transferts de base d’ETH coûtent moins d’un dollar. Si les progrès technologiques se font suffisamment rapidement et si l’augmentation de l’espace des blocs disponibles peut suivre la croissance de la demande, ces frais pourraient rester relativement bas à l’avenir, mais cela n’est pas garanti. Pour de nombreuses applications non financières (telles que les médias sociaux ou les jeux), même une transaction de 0,01 dollar est trop élevée.

Mais les médias sociaux et les jeux n’ont pas besoin du même niveau de sécurité que L1. Il n’y a pas de problème si quelqu’un peut dépenser un million de dollars pour annuler un enregistrement de partie perdue ou si votre tweet semble avoir été publié trois jours après sa publication réelle. Par conséquent, ces applications ne devraient pas payer le même coût de sécurité. Les solutions L2 parviennent à cela en prenant en charge une série de méthodes de disponibilité des données, allant des rollups et du plasma aux validiums.

Différents types de L2 conviennent à différentes situations d’utilisation. Plus de détails peuvent être consultés.

Un autre compromis est celui qui tourne autour du problème du transfert d’actifs de L2 à L2. Je m’attends à ce que dans les 5 à 10 prochaines années, tous les Rollups soient des ZK Rollups, et des systèmes de preuve ultra efficaces tels que Binius et Circle STARKs avec des lookups, ainsi qu’une couche d’agrégation des preuves, rendront possible l’obtention de l’état final de L2 à chaque slot. Mais pour l’instant, nous ne pouvons fusionner de manière complexe Optimistic Rollup et ZK Rollup, et utiliser des fenêtres de preuve différentes. Si nous implémentons le sharding en 2021, le modèle de sécurité pour maintenir l’honnêteté du sharding sera l’Optimistic Rollup, et non le ZK. Par conséquent, L1 devra gérer une logique de preuve de fraude complexe hors chaîne, et le temps de retrait des actifs entre les shards sera d’une semaine. Mais comme les bogues de code, je pense que ce problème sera également temporaire.

La vitesse de transaction est le troisième aspect compromis de sécurité et également un aspect plus durable. Ethereum produit un bloc toutes les 12 secondes et ne peut pas être plus rapide, sinon il serait trop centralisé. Cependant, de nombreux L2 explorent la possibilité de compresser le temps de blocage à quelques centaines de millisecondes. 12 secondes ne sont pas si mauvaises : les utilisateurs doivent en moyenne attendre environ 6 à 7 secondes après avoir soumis une transaction pour qu’elle soit incluse dans un bloc (pas seulement 6 secondes, car le bloc suivant pourrait ne pas les inclure). Cela correspond à peu près au temps d’attente lors du paiement par carte de crédit. Cependant, de nombreuses applications nécessitent une vitesse plus rapide, ce qui peut être réalisé avec L2.

Pour accélérer la vitesse, L2 dispose d’un mécanisme de pré-confirmation : les validateurs de L2 s’engagent à inclure les transactions à un moment précis par le biais de signatures digitales. S’ils ne le font pas, ils seront punis. Le mécanisme de StakeSure étend davantage cette fonctionnalité.

Pré-confirmation L2

Maintenant, nous pouvons essayer de réaliser toutes ces fonctionnalités sur L1. L1 peut inclure un système de “pré-confirmation rapide” et de “confirmation finale lente”. Il peut contenir différentes shardings avec différents niveaux de sécurité. Cependant, cela augmenterait la complexité du protocole. De plus, il y a un risque de surcharge du consensus si L1 effectue tout le travail, car de nombreuses méthodes à plus grande échelle ou à débit plus élevé présentent un risque centralisé plus élevé ou nécessitent une forme de “gouvernance” plus forte. Si ces exigences plus fortes étaient remplies sur L1, elles affecteraient d’autres parties du protocole. Grâce à L2, Ethereum peut en grande partie éviter ces risques.

Les avantages de Layer2 pour l’organisation et la culture

Imagine a country divided into two halves, one becoming a capitalist country and the other becoming a government-dominated country (unlike what happens in reality, let’s assume in this thought experiment that this is not the result of any traumatic war, but simply a natural emergence of borders). In the capitalist part, restaurants are made up of different decentralized ownership, blockchain, and voting rights. In the government-dominated country, they are all government branches, just like police stations. On the first day, there won’t be much change. People will basically follow existing habits, what is feasible and what is not depends on labor skills and technological realities such as infrastructure. However, after a year, you will see significant changes because different incentive and control structures will lead to significant changes in behavior, affecting people’s comings and goings, what gets built, what gets maintained, and what gets abandoned.

Les théories de l’organisation industrielle ont abordé de nombreuses différences de ce type : elles ont non seulement évoqué les différences entre une économie gérée par le gouvernement et une économie capitaliste, mais aussi les différences entre une économie dominée par de grandes entreprises franchisées et une économie où chaque supermarché est géré par des entrepreneurs indépendants. Je pense que les différences entre un écosystème centré sur L1 et un écosystème centré sur L2 sont similaires.

Quelque chose s’est terriblement mal passé avec l’architecture « le développeur principal gère tout »

En tant qu’écosystème axé sur la couche 2, je pense que les principaux avantages d’Ethereum sont les suivants :

Étant donné que Ethereum est un écosystème centré sur L2, vous pouvez construire librement un sous-écosystème avec ses propres fonctionnalités uniques, tout en étant une partie plus grande d’Ethereum.

Si vous ne construisez qu’un client Ethereum, vous faites partie d’une plus grande partie d’Ethereum, bien que vous ayez une certaine marge de manœuvre pour l’innovation, mais pas autant que L2. En revanche, si vous construisez une chaîne complètement indépendante, vous avez beaucoup plus de liberté créative, mais vous perdez également les avantages de la sécurité partagée et des effets de réseau partagés. L2 est un bon point d’équilibre.

Il offre non seulement des opportunités techniques pour expérimenter de nouveaux environnements d’exécution et des compromis de sécurité, mais aussi des opportunités pour l’évolutivité, la flexibilité et la vitesse. Il propose également un mécanisme d’incitation à la fois pour les développeurs pour construire et maintenir, et pour la communauté pour soutenir.

En fait, chaque L2 est isolé, ce qui signifie que le déploiement de nouvelles méthodes n’est pas autorisé : il n’est pas nécessaire de convaincre tous les développeurs principaux que votre nouvelle méthode est “sûre” pour le reste de la chaîne. Si votre L2 échoue, c’est de votre responsabilité. N’importe qui peut proposer des idées étranges (comme la méthode Plasma d’Intmax), même si les développeurs principaux d’Ethereum ne s’en préoccupent pas du tout, ils peuvent continuer à construire et à déployer. Ce n’est pas le cas des fonctionnalités et des précompilations de L1, même dans Ethereum, où le succès du développement de L1 dépend souvent de la politique, à un degré plus élevé que ce que nous souhaitons. Quoi qu’il en soit, les différents mécanismes d’incitation entre l’écosystème centré sur L1 et l’écosystème centré sur L2 auront finalement un impact considérable sur le contenu, la qualité et l’ordre de construction réels.

Quels sont les défis auxquels fait face l’écosystème Ethereum centré sur L2 ?

L’architecture L1 + L2 a de gros problèmes.

Source de l’image : Reddit

Cette approche centrée sur L2 est confrontée à un défi clé, tandis que l’écosystème centré sur L1 ne rencontre presque pas les mêmes problèmes : la coordination. En d’autres termes, bien qu’Ethereum ait de nombreux L2, le défi consiste à le faire encore ressembler à “Ethereum” et à bénéficier de l’effet de réseau d’Ethereum, plutôt que d’avoir N chaînes indépendantes. Aujourd’hui, cette situation laisse beaucoup à désirer à bien des égards.

• Les interactions cross-chain entre L2 nécessitent généralement des bridges cross-chain centralisés, ce qui est très complexe pour les utilisateurs ordinaires. Si vous avez des jetons sur Optimism, vous ne pouvez pas coller l’adresse Arbitrum d’une autre personne dans votre portefeuille pour envoyer des fonds.
• Pour les portefeuilles de contrats intelligents individuels et les portefeuilles d’organisations (y compris les DAO), la prise en charge des portefeuilles de contrats intelligents inter-chaînes n’est pas très bonne. Si vous changez une clé secrète sur L2, vous devez également changer chaque clé secrète sur les autres L2.
• Les infrastructures de validation décentralisées sont généralement assez rares. Ethereum a enfin commencé à avoir des clients légers décents, tels que Helios. Mais si toutes les activités se déroulent sur L2 et nécessitent leur propre RPC centralisé, cela n’a aucun sens. En principe, une fois que vous avez les en-têtes de bloc Ethereum, il n’est pas difficile de construire un client léger pour L2 ; mais dans la pratique, cela est trop peu pris en compte.

La communauté travaille dur pour améliorer ces trois aspects. Pour l’échange de jetons cross-chain, la norme ERC-7683 est une nouvelle solution qui diffère des “ponts cross-chain centralisés” existants car elle n’a pas de nœuds centralisés fixes, de jetons ou de gouvernance. Pour les comptes cross-chain, la plupart des portefeuilles utilisent une méthode consistant à mettre à jour la clé à court terme à l’aide de messages réutilisables (replayable) cross-chain, et à utiliser des rollups de keystore à long terme. Des clients légers pour L2 commencent également à apparaître, comme Beerus pour Starknet. De plus, des améliorations récentes apportées aux portefeuilles de nouvelle génération ont résolu des problèmes plus fondamentaux, tels que l’accès aux DApp sans avoir à basculer manuellement entre les réseaux.

Rabby vue d’ensemble du solde des actifs multi-chaînes, les portefeuilles précédents ne peuvent pas le faire !

Mais il faut reconnaître que l’écosystème centré sur L2 aura du mal à coordonner les choses. Parce qu’un L2 individuel n’a pas d’incitation économique naturelle pour construire une infrastructure de coordination : les L2 à petite échelle ne le feront pas car ils n’en retirent qu’une petite partie des avantages ; les L2 à grande échelle non plus, car ils peuvent obtenir autant, voire plus, d’avantages en renforçant leurs propres effets de réseau locaux. Si chaque L2 ne pense qu’à lui-même sans se soucier de s’aligner avec le système Ethereum plus large, alors nous échouerons, tout comme les utopies urbaines illustrées dans les images ci-dessus.

Il est difficile de dire qu’il existe une solution sans faille à ce problème. Tout ce que je peux dire, c’est que l’écosystème doit reconnaître plus pleinement que l’infrastructure inter-L2, ainsi que les clients L1, les outils de développement et les langages de programmation, sont un type d’infrastructure Ethereum et devraient donc être valorisés et financés. Nous avons la Guilde du Protocole et peut-être avons-nous besoin de la Guilde de l’Infrastructure de Base.

Résumé

Dans diverses discussions publiques, “L2” et “Sharding” sont souvent considérés comme deux stratégies opposées pour l’évolutivité de la blockchain. Cependant, lorsque vous étudiez la technologie sous-jacente, vous découvrirez un problème : les méthodes d’évolutivité réelles sont exactement les mêmes. Que ce soit le sharding des données, les validateurs de fraude ou les validateurs ZK-SNARK, ou encore les solutions de communication entre “Rollup” et “Sharding”, la principale différence réside dans : qui est responsable de la construction et de la mise à jour de ces composants, et quelle est leur autonomie ?

À partir d’un point de vue technique, l’écosystème centré sur L2 est essentiellement un processus de sharding, où vous pouvez construire vos propres règles pour votre propre shard. C’est extrêmement puissant et offre une infinité de possibilités créatives pour réaliser de nombreuses innovations autonomes. Mais cela présente également quelques défis clés, notamment en termes de coordination. Pour qu’un écosystème centré sur L2, comme Ethereum, puisse réussir, il est essentiel de comprendre ces défis, de les affronter et de les résoudre afin de tirer le meilleur parti possible des avantages d’un écosystème centré sur L1 et de se rapprocher autant que possible de la situation idéale pour les deux.