Vitalik : La théorie de l'évolution d'Ethereum - suite, quatre axes clés d'amélioration pour les L2
TechFlow SélectionTechFlow Sélection
Vitalik : La théorie de l'évolution d'Ethereum - suite, quatre axes clés d'amélioration pour les L2
L'extensibilité d'Ethereum n'est plus une question de « passer de zéro à un », mais de « passer de un à plusieurs ».
Dédié à des analyses Web3 approfondiesRédaction : Vitalik Buterin
Traduction : jk, ODaily Planet Daily
Le 13 mars, le fork dur Dencun a été activé, rendant possible l'une des fonctionnalités tant attendues d’Ethereum : le proto-danksharding (également connu sous le nom d'EIP-4844 ou « blobs »). Initialement, ce fork a réduit les frais de transaction des rollups de plus de 100 fois, car les blobs étaient presque gratuits. Au cours de ces derniers jours, nous avons enfin vu un pic d'utilisation des blobs, avec l'activation du marché des frais grâce au protocole Blobscriptions. Les blobs ne sont pas gratuits, mais restent bien moins coûteux que le calldata.
À gauche : Grâce à Blobscriptions, l’utilisation des blobs atteint enfin l’objectif de 3 par bloc. À droite : les frais associés aux blobs entrent dans une phase de découverte des prix.
Source : https://dune.com/0xRob/blobs
Ce jalon marque un tournant clé dans la feuille de route à long terme d’Ethereum : avec les blobs, la mise à échelle d’Ethereum n’est plus une question de « zéro à un », mais devient celle de « un à plusieurs ». Désormais, les efforts majeurs en matière de mise à échelle — qu’il s’agisse d’augmenter le nombre de blobs ou d’améliorer la capacité des rollups à exploiter chaque blob — se poursuivront, mais de manière plus progressive. Les changements fondamentaux liés à la scalabilité qui transforment profondément le fonctionnement d’Ethereum comme écosystème sont désormais derrière nous. En outre, l’attention commence à se déplacer progressivement, et continuera de le faire, des problèmes de niveau L1 comme la preuve d’enjeu (PoS) et la scalabilité vers des questions plus proches de la couche applicative. La question centrale abordée ici est : quelle sera la prochaine étape pour Ethereum ?
L’avenir de la scalabilité d’Ethereum
Ces dernières années, nous avons assisté à une transformation progressive d’Ethereum vers un écosystème centré sur la couche 2 (L2). Les principales applications ont commencé à migrer de la L1 vers la L2, les paiements sont désormais faits par défaut via la L2, et les portefeuilles conçoivent leur expérience utilisateur autour de cet environnement multi-L2.
Dès le départ, un élément central de la feuille de route axée sur les rollups était le concept d’espace indépendant de disponibilité des données : une section spéciale au sein d’un bloc, inaccessible à la machine virtuelle Ethereum (EVM), pouvant stocker des données destinées aux projets de couche 2 comme les rollups. Comme cet espace de données est inaccessible à l’EVM, il peut être diffusé séparément d’un bloc et validé indépendamment. Finalement, il pourrait être vérifié via une technique appelée échantillonnage de disponibilité des données (data availability sampling, DAS), permettant à chaque nœud de valider la publication correcte des données en examinant aléatoirement quelques petits échantillons. Une fois mis en œuvre, l’espace des blobs pourrait être fortement agrandi ; l’objectif final étant de 16 Mo par slot (environ 1,33 Mo/s).
Échantillonnage de disponibilité des données : chaque nœud n’a besoin que de télécharger une petite partie des données pour en vérifier la disponibilité globale.
L’EIP-4844 (les blobs) ne nous fournit pas encore l’échantillonnage de disponibilité des données. Toutefois, il établit un cadre de base de telle sorte qu’à partir de là, l’introduction du DAS et l’augmentation silencieuse du nombre de blobs puissent se faire sans aucune intervention nécessaire des utilisateurs ou des applications. En pratique, le seul « fork dur » requis serait un simple changement de paramètre.
Deux directions doivent désormais continuer à évoluer :
-
Augmenter progressivement la capacité des blobs, jusqu’à atteindre pleinement le DAS, offrant 16 Mo d’espace de données par slot ;
-
Améliorer les L2 afin d’exploiter au mieux l’espace de données disponible.
Concrétiser le DAS
La prochaine étape pourrait être une version simplifiée du DAS appelée PeerDAS. Dans PeerDAS, chaque nœud stocke une part importante des données des blobs (par exemple 1/8), tout en maintenant des connexions avec de nombreux pairs sur le réseau P2P. Lorsqu’un nœud doit échantillonner un fragment spécifique de données, il interroge l’un des pairs chargés de stocker cette portion.
Si chaque nœud doit télécharger et stocker 1/8 de toutes les données, PeerDAS permet théoriquement d’augmenter l’échelle des blobs de 8 fois (en réalité 4 fois, car nous perdons un facteur 2 dû à la redondance du codage d’effacement). PeerDAS pourrait être déployé progressivement : nous pourrions avoir une phase où les validateurs professionnels continuent de télécharger les blobs complets, tandis que les validateurs individuels ne téléchargent que 1/8 des données.
Par ailleurs, l’EIP-7623 (ou des alternatives telles que la tarification 2D) pourrait imposer des limites plus strictes à la taille maximale des blocs d’exécution (les « transactions normales »), ce qui rendrait plus sûr l’augmentation simultanée de l’objectif des blobs et du plafond de gaz L1. À long terme, des protocoles DAS 2D plus complexes nous permettront de monter en puissance et d’étendre davantage l’espace des blobs.
Améliorer les performances des L2
Aujourd’hui, les protocoles de couche 2 (L2) peuvent être améliorés selon quatre axes principaux.
1. Utiliser les octets plus efficacement grâce à la compression des données
Mon schéma récapitulatif sur la compression des données reste accessible ici ;
Naïvement, une transaction occupe environ 180 octets. Cependant, une série de techniques de compression peuvent réduire considérablement cette taille à plusieurs niveaux ; avec une compression optimisée, nous pourrions descendre à moins de 25 octets par transaction.
2. Sécuriser les L2 avec des données optimistes sur la L1 uniquement dans des cas particuliers
Plasma est une catégorie de technologies permettant de garder les données sur la L2 en conditions normales, tout en offrant à certaines applications une sécurité équivalente à celle des rollups. Pour les EVMs, Plasma ne peut pas protéger toutes les unités monétaires. Mais des constructions inspirées de Plasma peuvent protéger la majorité des jetons. Et des architectures bien plus simples que Plasma peuvent grandement améliorer les validiums actuels. Les L2 qui hésitent à publier toutes leurs données sur la chaîne devraient explorer ces technologies.
3. Continuer à améliorer les limites liées à l’exécution
Une fois le fork Dencun activé, le coût des rollups configurés pour utiliser les blobs a chuté de 100 fois. L’utilisation du rollup Base a alors explosé :
Cela a conduit Base à atteindre sa limite interne de gaz, provoquant une hausse inattendue des frais. On réalise ainsi que l’espace de données d’Ethereum n’est pas le seul élément à mettre à l’échelle : les rollups eux-mêmes doivent aussi s’agrandir.
Une partie de la solution réside dans la parallélisation ; les rollups pourraient implémenter quelque chose de similaire à l’EIP-648. Mais tout autant important est le stockage, ainsi que les effets d’interaction entre calcul et stockage. Ceci constitue un défi d’ingénierie majeur pour les rollups.
4. Continuer à renforcer la sécurité
Nous sommes encore loin d’un monde où les rollups sont véritablement protégés par le code. Selon l2beat, seul l’un des cinq, Arbitrum, est pleinement compatible EVM et atteint même ce que j’appelle la « première étape ».
Il faut affronter ce problème directement. Bien que nous ne soyons pas encore assez confiants dans le code d’un vérificateur EVM complexe, optimiste ou basé sur SNARK, nous pouvons certainement avancer à mi-chemin, en mettant en place un comité de sécurité capable de modifier le comportement du code seulement sous un seuil élevé (par exemple, je propose 6 sur 8 ; Arbitrum utilise actuellement 9 sur 12).
Les standards de l’écosystème doivent devenir plus stricts : jusqu’ici, nous avons toléré et accepté tous les projets affirmant être « sur la voie de la décentralisation ». D’ici la fin de l’année, selon moi, nos exigences devraient augmenter, et nous ne devrions considérer comme rollups que les projets ayant au minimum atteint la première étape.
Ensuite, nous pourrons progresser prudemment vers la deuxième étape : un monde où les rollups sont véritablement soutenus par le code, et où le comité de sécurité n’intervient que si le code présente une contradiction manifeste (par exemple, en acceptant deux racines d’état incompatibles, ou si deux implémentations donnent des résultats différents). Une voie sécurisée vers cet objectif consiste à utiliser plusieurs prouveurs.
Que signifie cela pour l’évolution d’Ethereum ?
Lors de l’ETHCC de l’été 2022, j’ai donné une conférence décrivant l’état actuel du développement d’Ethereum comme une courbe en S : nous étions entrés dans une période de changement très rapide, suivie d’un ralentissement lorsque la L1 se stabiliserait et que le développement se recentrerait sur les couches utilisateur et applicative.
Aujourd’hui, je dirais que nous sommes clairement dans la phase de ralentissement de cette courbe en S. Il y a deux semaines, les deux transformations majeures apportées à la blockchain Ethereum — le passage à la preuve d’enjeu et la refonte autour des blobs — étaient terminées. Les changements futurs restent importants (par exemple, les arbres de Verkle, la finalité en un seul slot, l’abstraction de compte intégrée au protocole), mais ils seront moins radicaux que la preuve d’enjeu et le sharding. En 2022, Ethereum ressemblait à un avion changeant de moteur en plein vol. En 2023, il a changé d’ailes. La transition vers les arbres de Verkle est la dernière grande évolution vraiment cruciale (nous avons déjà un testnet) ; les autres ressemblent davantage à un remplacement de l’empennage.
L’objectif de l’EIP-4844 était d’effectuer un changement massif unique afin d’assurer une stabilité à long terme pour les rollups. Maintenant que les blobs sont lancés, les futures mises à jour vers le danksharding complet avec des blobs de 16 Mo, voire la migration vers des STARKs sur un champ Goldilocks 64 bits, peuvent se produire sans aucune action supplémentaire requise des rollups ou des utilisateurs. Cela renforce également un précédent important : le processus de développement d’Ethereum suit une feuille de route à long terme bien connue, et les applications (y compris les L2) conçues autour de la « nouvelle Ethereum » bénéficient désormais d’un environnement stable sur le long terme.
Que signifie cela pour les applications et les utilisateurs ?
La première décennie d’Ethereum a largement été une phase d’entraînement : l’objectif était de faire décoller la L1 Ethereum, les applications se limitant principalement à un petit groupe enthousiaste. Beaucoup ont affirmé que l’absence d’applications grand public durant la dernière décennie prouvait que la cryptographie était inutile. J’ai toujours combattu cette idée : presque toutes les applications cryptographiques non spéculatives dépendent de frais bas — donc, quand nous faisons face à des frais élevés, nous ne devrions pas être surpris de ne voir que de la spéculation financière.
Avec les blobs, la contrainte clé qui nous bloquait depuis si longtemps commence à s’effacer. Les frais ont enfin drastiquement baissé ; ma déclaration datant de sept ans, selon laquelle Internet de l’argent ne devrait pas coûter plus de cinq cents par transaction, est enfin devenue réalité. Nous ne sommes pas complètement sortis d’affaire : si l’utilisation croît trop vite, les frais pourraient remonter, et nous devrons continuer à développer les blobs (et les rollups indépendamment) dans les années à venir. Mais nous voyons enfin la lumière au bout du tunnel… euh… la forêt sombre.
Pour les développeurs, cela signifie une chose simple : nous n’avons plus aucune excuse. Jusqu’à récemment, nous nous fixions des standards bas, construisant des applications visiblement incapables de passer à l’échelle, dès lors qu’elles fonctionnaient comme prototype et étaient raisonnablement décentralisées. Aujourd’hui, nous possédons tous les outils nécessaires, et probablement la majorité de ceux que nous aurons jamais, pour créer des applications à la fois cypherpunk et conviviales. Nous devons donc sortir et le faire.
Beaucoup relèvent ce défi. Le portefeuille Daimo se décrit explicitement comme un Venmo sur Ethereum, combinant la commodité de Venmo à la décentralisation d’Ethereum. Dans le domaine des réseaux sociaux décentralisés, Farcaster excelle à concilier une vraie décentralisation (par exemple, consultez ce guide pour apprendre à construire votre propre client alternatif) et une excellente expérience utilisateur. Contrairement à la précédente vague de « social finance », l’utilisateur moyen de Farcaster ne vient pas jouer — il passe ainsi le test crucial de la durabilité pour une application cryptographique.
Ce message a été envoyé via Warpcast, principal client Farcaster, et cette capture provient du client alternatif Firefly, combinant Farcaster et Lens.
Ces réussites sont celles sur lesquelles nous devons bâtir, et étendre à d’autres domaines d’application, notamment l’identité, la réputation et la gouvernance.
Les applications construites ou maintenues aujourd’hui doivent s’inspirer de l’Ethereum des années 2020
L’écosystème Ethereum abrite encore de nombreuses applications fonctionnant selon des flux de travail fondamentalement ancrés dans « l’Ethereum des années 2010 ». La plupart des activités ENS ont lieu encore sur la L1. La majorité des émissions de jetons se font aussi sur la L1, sans chercher sérieusement à garantir la disponibilité des jetons pontés sur la L2 (par exemple, un fan de la memecoin ZELENSKYY remercie ses dons continus à l’Ukraine, mais se plaint que les frais L1 rendent cela trop cher). En dehors de la scalabilité, nous accusons du retard en matière de confidentialité : les POAPs sont tous publiés publiquement sur la chaîne, ce qui peut être pertinent pour certains cas d’usage, mais très sous-optimal pour d’autres. La plupart des DAO et des Gitcoin Grants utilisent encore des votes entièrement transparents sur la chaîne, les rendant très vulnérables aux pots-de-vin (y compris les airdrops ex post), ce qui a déformé gravement les modèles de contribution. Aujourd’hui, les ZK-SNARKs existent depuis des années, pourtant de nombreuses applications ne commencent pas encore à les utiliser correctement.
Ce sont des équipes travailleuses confrontées à d’importants groupes d’utilisateurs existants, je ne les blâme donc pas de ne pas avoir mis à jour simultanément leurs systèmes à la dernière vague technologique. Mais bientôt, cette mise à jour devra avoir lieu. Voici quelques différences clés entre « un flux de travail fondamentalement ancré dans l’Ethereum des années 2010 » et « un flux de travail fondamentalement ancré dans l’Ethereum des années 2020 » :
Fondamentalement, Ethereum n’est plus seulement un écosystème financier. Il représente une alternative complète et intégrée aux technologies centralisées, allant même plus loin en proposant des fonctionnalités que ces dernières ne peuvent pas offrir (comme les applications liées à la gouvernance). Nous devons concevoir en gardant à l’esprit cet écosystème plus vaste.
Conclusion
Ethereum traverse une transformation décisive, passant d’une ère de progrès rapides au niveau L1 à une période où les progrès L1 resteront significatifs, mais plus mesurés, avec moins d’impact sur les applications.
Nous devons encore achever la mise à l’échelle. Ce travail se fera davantage en arrière-plan, mais demeure crucial.
Les développeurs d’applications ne construisent plus seulement des prototypes ; ils créent désormais des outils destinés à des millions d’utilisateurs. À travers tout l’écosystème, nous devons adapter notre mentalité en conséquence.
Ethereum a évolué d’un simple écosystème financier vers une pile technologique décentralisée indépendante et beaucoup plus complète. L’ensemble de l’écosystème doit également ajuster sa vision en ce sens.
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
