Vitalik parle des L2 et du sharding d'exécution : quelles différences et quels défis ?
TechFlow SélectionTechFlow Sélection
Vitalik parle des L2 et du sharding d'exécution : quelles différences et quels défis ?
L'écosystème centré sur la couche 2 est, en un vrai sens technique, du sharding.
Dédié à des analyses Web3 approfondiesRédaction : Vitalik Buterin
Traduction : Peng Sun, Foresight News
Il y a deux ans et demi, dans mon article « Endgame », j'ai indiqué que les différentes voies futures du développement des blockchains ressemblent techniquement beaucoup à première vue. Dans les deux cas, il y a de nombreuses transactions sur la chaîne, dont le traitement nécessite : (1) une grande puissance de calcul ; (2) une large bande passante pour les données. Un nœud Ethereum ordinaire (comme le nœud d'archive reth de 2 To que j'exécute actuellement sur mon ordinateur), même avec un excellent génie logiciel et des arbres Verkle, ne suffit pas à valider directement de telles quantités massives de données et de calculs. En revanche, dans les deux approches — « sharding L1 » ou centrée sur les Rollups — les ZK-SNARK sont utilisés pour vérifier les calculs, et le DAS (disponibilité des données) pour garantir la disponibilité des données. Que ce soit pour les shards L2 ou les rollups, le DAS est identique, tout comme la technologie ZK-SNARK. Ces outils constituent à la fois du code de contrats intelligents et une fonctionnalité du protocole. D’un point de vue strictement technique, Ethereum est en cours de fragmentation, et les rollups sont eux-mêmes des fragments.
Cela soulève naturellement la question suivante : quelle est la différence ? L'une réside dans les conséquences des bogues logiciels : dans un rollup, des jetons peuvent être volés ; dans un shard, c'est le consensus qui se brise. Mais je prévois qu’avec la stabilisation des protocoles et l'amélioration des techniques de vérification formelle (formal verification), l'impact des erreurs de code deviendra de plus en plus négligeable. Alors, quelles autres différences existent entre ces deux solutions potentiellement durables ?
Diversité des environnements d'exécution
En 2019, nous avions évoqué brièvement dans Ethereum l'idée d'environnements d’exécution. En substance, Ethereum aurait possédé différents « zones », pouvant appliquer des règles distinctes concernant les comptes (y compris des méthodes complètement différentes, comme UTXO), le fonctionnement de la machine virtuelle et d'autres fonctionnalités. Cela permettrait une diversité d'approches au sein de la pile, chose difficile à réaliser si Ethereum tente d'intégrer trop de fonctions en un seul système.
Finalement, nous avons abandonné certains projets ambitieux pour conserver uniquement l'EVM. Toutefois, les L2 d’Ethereum (y compris les rollups, les validiums et les plasmas) jouent effectivement le rôle d’environnements d’exécution. Actuellement, nous nous concentrons principalement sur les L2 compatibles EVM, mais cela fait abstraction de la richesse offerte par d’autres approches :
-
Arbitrum Stylus, qui ajoute un deuxième oracle basé sur WASM en plus de l’EVM ;
-
Fuel, qui utilise une architecture basée sur UTXO similaire à Bitcoin (mais plus complète) ;
-
Aztec, qui introduit un nouveau langage et un nouveau paradigme de programmation autour des contrats intelligents privés basés sur ZK-SNARK.
Architecture basée sur UTXO, source : documentation Fuel
On pourrait essayer de transformer l’EVM en une super-machine virtuelle couvrant tous les paradigmes possibles, mais cela compromettrait gravement l’efficacité de chaque fonctionnalité. Il vaut mieux laisser chaque plateforme exceller dans son domaine spécifique.
Compromis de sécurité : évolutivité contre rapidité des transactions
Ethereum L1 offre une sécurité très forte. Si certaines données sont incluses dans un bloc finalisé sur L1, alors tout le consensus (y compris, dans les cas extrêmes, le consensus social) s'efforcera de garantir que ces données ne soient jamais modifiées, que toute exécution déclenchée par celles-ci ne puisse être annulée, et que les données restent accessibles. Pour obtenir cette garantie de sécurité, Ethereum L1 accepte volontairement des coûts élevés. Au moment où cet article est écrit, les frais de transaction sont relativement faibles : moins d’un centime par transaction sur la couche 2 selon Growthepie, et même sur L1, un simple transfert ETH coûte moins d’un dollar. Si les progrès technologiques sont suffisants et que l’espace de bloc disponible croît aussi vite que la demande, ces frais pourraient rester bas à long terme, mais ce n’est pas garanti. Pour de nombreuses applications non financières (comme les réseaux sociaux ou les jeux), même 0,01 $ par transaction reste trop élevé.
Toutefois, les réseaux sociaux et les jeux n’ont pas besoin du même modèle de sécurité que L1. Il n’y a pas de problème majeur si quelqu’un dépense un million de dollars pour annuler le résultat d’une partie perdue, ou faire apparaître qu’un message a été publié trois jours après sa date réelle. Par conséquent, ces applications ne devraient pas payer le même coût de sécurité. Les solutions L2 permettent précisément cela, en supportant une gamme de méthodes de disponibilité des données allant des rollups, aux plasma, jusqu’aux validiums.
Les différents types de L2 conviennent à différents cas d’usage. Voir plus de lectures.
Un autre compromis concerne les transferts d’actifs entre L2. J’anticipe que, dans les 5 à 10 prochaines années, tous les rollups seront des ZK-Rollups, et que des systèmes de preuves ultra-performants comme Binius ou les lookups dans les Circle STARKs, combinés à des couches d’agrégation de preuves, rendront possible pour chaque L2 de fournir une racine d’état finale à chaque slot. Pour l’instant, nous devons encore combiner de manière complexe Optimistic Rollups et ZK Rollups avec différentes fenêtres de temps de preuve. Si nous avions implémenté le sharding d’exécution en 2021, le modèle de sécurité pour maintenir l’honnêteté des shards aurait été basé sur Optimistic Rollup plutôt que sur ZK, forçant ainsi L1 à gérer une logique complexe de preuves de fraude sur la chaîne, et imposant des délais de retrait d’une semaine pour transférer des actifs entre shards. Mais comme pour les bogues de code, je pense que ce problème est également temporaire.
La rapidité des transactions constitue un troisième aspect du compromis de sécurité, et probablement plus durable. Ethereum produit un bloc toutes les 12 secondes, et ne peut aller plus vite sans risquer un haut degré de centralisation. Pourtant, de nombreux L2 explorent des temps de bloc réduits à quelques centaines de millisecondes. Douze secondes n’est déjà pas si mal : après avoir soumis une transaction, l’utilisateur attend en moyenne 6 à 7 secondes avant qu’elle soit incluse dans un bloc (pas seulement 6 secondes, car le prochain bloc ne l’inclura peut-être pas). Cela correspond à peu près au temps d’attente lors d’un paiement par carte bancaire. Toutefois, de nombreuses applications exigent une rapidité supérieure, que les L2 peuvent offrir.
Pour accélérer les choses, les L2 disposent d’un mécanisme de « pré-confirmation » : les validateurs du L2 s’engagent par signature numérique à inclure une transaction à un moment donné, et encourent une sanction s’ils ne le font pas. Le mécanisme StakeSure généralise davantage cette idée.
Pré-confirmation L2
On pourrait envisager d’intégrer toutes ces fonctionnalités directement dans L1. L1 pourrait contenir un système de « pré-confirmation rapide » et de « confirmation finale lente ». Il pourrait comporter des shards avec différents niveaux de sécurité. Cependant, cela augmenterait la complexité du protocole. De plus, effectuer tout cela sur L1 comporte le risque de surcharge du consensus, car les méthodes plus scalables ou à débit plus élevé comportent souvent un risque accru de centralisation ou exigent une forme de « gouvernance » plus forte, dont les effets négatifs pourraient alors impacter l’ensemble du protocole. En proposant ces compromis via les L2, Ethereum évite largement ces risques.
Avantages organisationnels et culturels des L2
Imaginez un pays divisé en deux : une moitié devient capitaliste, l’autre devient fortement dirigée par l’État (contrairement à la réalité où cela résulte d’un conflit traumatisant, supposons ici que cette frontière apparaisse naturellement un jour, sans autre cause). Dans la partie capitaliste, les restaurants sont gérés par des propriétaires décentralisés, des blockchains et des élections. Dans la partie étatique, ils sont tous des agences gouvernementales, comme les postes de police. Le premier jour, peu de changements visibles. Les gens continuent leurs habitudes, ce qui fonctionne ou non dépendant de réalités techniques comme les compétences professionnelles ou les infrastructures. Mais un an plus tard, d’énormes différences apparaissent : les structures d’incitation et de contrôle différentes entraînent des comportements radicalement distincts, influençant qui reste, qui part, ce qui est construit, entretenu ou abandonné.
La théorie de l’organisation industrielle traite beaucoup de ces distinctions : elle compare non seulement économie étatique et capitaliste, mais aussi une économie dominée par de grandes franchises à une autre où chaque supermarché est dirigé par un entrepreneur indépendant. Je pense que la différence entre un écosystème centré sur L1 et un écosystème centré sur L2 est similaire.
L’architecture « les développeurs centraux gèrent tout » pose de gros problèmes
En tant qu’écosystème centré sur les L2, je pense que l’avantage principal d’Ethereum est le suivant :
Étant donné qu’Ethereum est un écosystème centré sur les L2, vous êtes libre de construire indépendamment un sous-écosystème doté de fonctionnalités uniques, tout en faisant toujours partie du grand écosystème Ethereum.
Si vous construisez simplement un client Ethereum, vous faites bien partie d’Ethereum, mais votre espace d’innovation est limité comparé à celui d’un L2. Si vous construisez une chaîne totalement indépendante, vous avez un très grand espace de création, mais vous perdez les avantages de la sécurité partagée et des effets réseau communs. Les L2 représentent un excellent équilibre.
Ils offrent non seulement des opportunités techniques pour expérimenter de nouveaux environnements d’exécution et des compromis de sécurité, permettant évolutivité, flexibilité et rapidité, mais aussi un ensemble d’incitations qui motivent à la fois les développeurs à construire et à maintenir, et les communautés à soutenir.
Le fait que chaque L2 soit isolé signifie aussi que le déploiement de nouvelles méthodes est sans autorisation : inutile de convaincre tous les développeurs centraux 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 proposer des idées originales (par exemple, la méthode Plasma d’Intmax) et continuer à construire et déployer, même si les développeurs centraux d’Ethereum n’y prêtent aucune attention. Ce n’est pas le cas des fonctionnalités L1 ou des précompilations : même dans Ethereum, le succès ou l’échec du développement L1 dépend souvent, finalement, de considérations politiques, plus que ce que nous souhaiterions. Quoi que l’on puisse théoriquement construire, les incitations différentes générées par un écosystème centré sur L1 versus un écosystème centré sur L2 affecteront profondément ce qui est réellement construit, sa qualité et son ordre de priorité.
Quels défis l’écosystème Ethereum centré sur les L2 doit-il relever ?
L’architecture L1 + L2 pose de gros problèmes.
Source image : Reddit
Cette approche centrée sur les L2 fait face à un défi clé que les écosystèmes centrés sur L1 rencontrent presque pas : la coordination. Autrement dit, bien qu’Ethereum dispose de nombreux L2, le défi consiste à faire en sorte qu’il continue de ressembler à « Ethereum », avec ses effets réseau, plutôt qu’à N chaînes indépendantes. Aujourd’hui, cette situation laisse à désirer sur plusieurs plans :
-
Le pontage entre L2 requiert généralement des ponts centralisés, ce qui est très complexe pour les utilisateurs ordinaires. Si vous détenez des jetons sur Optimism, vous ne pouvez pas simplement coller l’adresse Arbitrum d’un tiers dans votre portefeuille pour envoyer des fonds.
-
La prise en charge des portefeuilles intelligents multi-chaînes est insuffisante, que ce soit pour les portefeuilles individuels ou organisationnels (y compris les DAO). Si vous changez de clé sur un L2, vous devez aussi changer celle de chacun des autres L2.
-
L’infrastructure de validation décentralisée fait souvent défaut. Ethereum commence enfin à disposer de bons clients légers, comme Helios. Mais si toute l’activité se déroule sur des L2, tous dépendant de RPC centralisés, cela perd tout sens. En principe, une fois que vous avez l’en-tête d’un bloc Ethereum, construire un client léger pour un L2 n’est pas difficile ; en pratique, on y accorde trop peu d’attention.
La communauté travaille activement à améliorer ces trois aspects. Pour les échanges inter-chaînes, la norme ERC-7683 propose une solution nouvelle, sans nœuds fixes, jetons ni gouvernance centralisés, contrairement aux « ponts centralisés » actuels. Pour les comptes inter-chaînes, la plupart des portefeuilles adoptent une approche à court terme basée sur des messages rejouables pour mettre à jour les clés, et à long terme sur les keystore rollups. Des clients légers pour L2 commencent à apparaître, comme Beerus pour Starknet. De plus, les améliorations récentes apportées par les portefeuilles de nouvelle génération ont résolu des problèmes plus fondamentaux, comme l’accès aux DApp sans avoir à changer manuellement de réseau.
Vue consolidée des soldes multi-chaînes de Rabby, quelque chose que les portefeuilles précédents ne pouvaient pas faire !
Mais il faut reconnaître qu’un écosystème centré sur les L2 aura toujours du mal à coordonner. Car aucun L2 individuel n’a d’incitation économique naturelle à construire des infrastructures de coordination : les petits L2 n’ont pas intérêt à le faire car ils n’en tireraient qu’un petit bénéfice ; les grands L2 non plus, car ils tirent autant, voire plus, d’avantages à renforcer leurs propres effets réseau locaux. Si chaque L2 ne pense qu’à lui-même, sans personne pour penser à l’alignement avec l’ensemble d’Ethereum, alors nous échouerons, tout comme l’utopie urbaine illustrée ci-dessus.
Il est difficile de proposer une solution parfaite à ce problème. Je dirai seulement que l’écosystème doit mieux comprendre que l’infrastructure transverse aux L2 est un type d’infrastructure Ethereum au même titre que les clients L1, les outils de développement ou les langages de programmation, et qu’elle mérite donc reconnaissance et financement. Nous avons le Protocol Guild ; peut-être avons-nous besoin d’un Basic Infrastructure Guild.
Conclusion
Dans de nombreux débats publics, « L2 » et « sharding » sont souvent perçus comme deux stratégies opposées d’évolutivité blockchain. Pourtant, lorsque l’on examine les technologies sous-jacentes, on découvre un paradoxe : les méthodes réelles de mise à l’échelle sont exactement les mêmes. Que ce soit le partitionnement des données, les validateurs de fraude ou de ZK-SNARK, ou les solutions de communication entre « rollups et shards », la principale différence réside dans : qui construit et met à jour ces composants, et quel degré d’autonomie possèdent-ils ?
Un écosystème centré sur les L2 est, du point de vue technique pur, du sharding, mais dans lequel vous pouvez créer votre propre fragment selon vos propres règles. C’est extrêmement puissant, offrant une créativité infinie et une large autonomie d’innovation. Mais cela présente aussi des défis clés, particulièrement en matière de coordination. Pour réussir, un écosystème comme Ethereum, centré sur les L2, doit comprendre ces défis et s’efforcer activement de les surmonter afin de bénéficier autant que possible des atouts d’un écosystème centré sur L1, et de se rapprocher au maximum du meilleur des deux mondes.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@VitalikButerin
