Note de l'éditeur: Cet après-midi, au lieu principal de l'événement Devcon à Bangkok, Justin Drake, développeur principal d'Ethereum, a annoncé la proposition de changement de couche de consensus la plus ambitieuse d'Ethereum au cours des dernières années - Beam Chain, qui introduit une série de technologies ZK pour remplacer l'ancienne Beacon Chain Ethereum. Lors de la réunion, Justin a déclaré que le développement de la nouvelle couche de consensus pourrait se poursuivre jusqu'en 2030. Cependant, le marché ne semblait pas l'acheter et pendant la conférence de presse, le prix d'Ethereum a chuté brusquement. Tout le monde semble se demander: la fondation a-t-elle une autre excuse pour vendre des coins?

Ce qui suit est le texte intégral du discours:

Le projet dans lequel j'ai investi beaucoup de temps cette année s'appelle "Beam Chain". Beam Chain est une refonte de la couche de consensus qui intègre les idées les plus récentes et les plus avancées de la feuille de route de recherche. L'objectif est de passer de la Beacon Chain actuelle à cette conception de manière sûre et rapide, ce qui sera plus proche de la forme finale d'Ethereum.

Source de l'image: Uncommons Dasong

Avant de partager plus, deux avertissements : Premièrement, ceci est une proposition, la mienne seulement, et ne progressera qu'avec consensus. Deuxièmement, il n'y a pas de nouveau jeton, pas de nouveau réseau, nous continuerons à utiliser le même symbole, Vitalik a été très clair à ce sujet.

Dans la présentation suivante, je vais essayer d'expliquer une idée apparemment folle en une proposition raisonnable - à savoir de redessiner complètement la couche de consensus.

Tout d'abord, je voudrais parler de la grande vision d'ensemble de Beam Chain. La portée de Beam Chain se concentre sur la couche de consensus et n'inclut pas les blobs dans la couche de données et l'EVM dans la couche d'exécution, car les blobs et l'EVM sont utilisés directement par les applications et doivent maintenir une compatibilité ascendante, les possibilités de changement de ces deux couches sont donc relativement limitées. La couche de consensus n'est pas consommée directement par les applications, ce qui nous permet d'avoir plus de liberté d'ajustement à cet égard.

Pourquoi Beam Chain?

Alors pourquoi proposer cette refonte massive de la couche de consensus maintenant ?

La principale raison est que Beacon Chain est déjà un peu "ancienne".

Les «spécifications» ont été figées il y a cinq ans, et beaucoup de choses ont changé au cours de ces cinq années, en particulier notre compréhension des nouvelles perspectives est beaucoup plus profonde qu'il y a cinq ans. Nous étions relativement naïfs en ce qui concerne le PoW il y a cinq ans, mais depuis lors, le marché a connu une croissance rapide et nous avons une meilleure compréhension des mécanismes qui peuvent aider à atténuer les externalités négatives de MEV.

Deuxièmement, d'un point de vue technique, nous disposons maintenant d'une technologie très puissante appelée SNARKs. Au cours des cinq dernières années, il y a eu de nombreuses avancées dans la technologie SNARKs, augmentant les vitesses de plusieurs ordres de grandeur. En même temps, nous avons également vu la naissance des zkVMs, une technologie incroyable qui permet à n'importe quel programmeur dans le monde de tirer parti de cette technologie puissante sans avoir besoin d'être versé dans la cryptographie ou d'avoir une compréhension approfondie des SNARKs.

De plus, avec le temps, nous avons maintenant une compréhension claire des erreurs qui ont été commises sur Beacon Chain et de la dette technique qui s'est accumulée. Ces dettes sont très tenaces et vont croître avec le temps.

Maintenant, peut-être avons-nous l'opportunité de résoudre cette dette technique. Par conséquent, je recommande d'intégrer les technologies les plus avancées de la feuille de route de la couche de consensus dans Beam Chain.

Quels changements inclut Beam Chain?

Ensuite, je vais prendre un moment pour décrire ce qui est exactement inclus dans la feuille de route de la couche de consensus. Il y a essentiellement neuf projets différents, et je les ai divisés en trois catégories : production de blocs, mise en jeu et cryptographie.

Source: Aaros.183

Le premier est la production de blocs, qui implique MEV. Il existe actuellement de nombreux problèmes de centralisation au niveau du constructeur de blocs et du relais. Nous espérons introduire une «liste d'inclusion» pour améliorer considérablement la résistance à la censure. Une fois que la liste d'inclusion est résistante à la censure, nous pourrons clairement séparer les validateurs du processus de production de blocs. Cela s'appelle la séparation du constructeur-proposant (PBS) et comprend des idées telles que les fonctions d'exécution.

Le dernier élément de la catégorie de production de blocs est des intervalles de temps plus rapides, peut-être que nous pouvons encore réduire les intervalles de temps tout en maintenant les intervalles de temps actuels de 12 secondes inchangés et nous assurer que même avec une connexion réseau domestique, même si la latence du réseau est élevée en Australie, les utilisateurs peuvent toujours participer en tant que validateurs et profiter de droits de première classe.

La deuxième catégorie est l'engagement. Les chercheurs sont largement parvenus à un consensus selon lequel la courbe d'émission actuelle est défectueuse et qu'il existe des opportunités d'ajustements pour améliorer la santé et le développement à long terme d'Ethereum. Le deuxième projet dans la catégorie de mise en jeu consiste à réduire considérablement le montant d'ETH requis pour devenir un validateur, passant de l'actuel 32 ETH à seulement 1 ETH.

Il y a eu récemment quelques idées sur "Orbit". De plus, une autre idée qui est discutée depuis des années est la finalité à un seul emplacement, ce qui pourrait accélérer considérablement le processus de finalité d'Ethereum.

La dernière catégorie est la cryptographie, qui comprend deux projets importants. Le premier projet est la vérification SNARK de l'ensemble de la couche de consensus en temps réel, avec un support matériel raisonnable.

Enfin, pouvons-nous rendre la cryptographie qui sécurise Ethereum durable et résistante aux attaques quantiques pour les décennies, voire les siècles à venir?

Ici, j'utilise différentes couleurs pour différencier si les éléments de la feuille de route peuvent être réalisés facilement ou progressivement, ou s'ils sont difficiles à atteindre. Les quatre projets verts dans le coin supérieur gauche sont des projets que je pense pouvoir et devoir mettre en œuvre progressivement sur Beacon Chain, et lorsque ces projets plus petits seront terminés, il restera quelques projets majeurs (parties rouges) que je pense être les meilleurs grâce à une approche plus holistique.

Prenant «Notification de changement» comme exemple, afin de réaliser une preuve en temps réel de Beacon Chain sur un matériel raisonnable, nous devons changer la fonction de hachage, la méthode de signature et les méthodes de sérialisation et de Merkelization d'état. Ce sera un grand changement pour Beacon Chain, donc peut-être qu'il y a une opportunité pour nous de faire ces ajustements aux côtés d'autres améliorations.

Une situation similaire s'applique aux "Faster Slots" et "Faster Finality" dans les deux boîtes rouges en bas. Lorsque nous avons conçu Beacon Chain il y a cinq ans, notre priorité était la sécurité, pas les performances. Maintenant, cependant, nous découvrons qu'il existe des conceptions qui peuvent maintenir la sécurité dont nous avons besoin tout en améliorant également les performances et en saisissant certaines améliorations de performances faciles à réaliser.

Ce PPT montre la correspondance entre la feuille de route de la couche de consensus que je viens de mentionner et la feuille de route plus large de Vitalik. Certains de nos projets sont dans la phase Merge, certains sont dans la phase Scourge, et certains sont dans les phases Verge et Scourge.

Le but principal de cette présentation est de transmettre que Beam Chain ne modifie pas l'ensemble de la feuille de route, mais identifie un sous-ensemble spécifique, l'accélère et lui donne une signification unique.

Source: Aaros.183

Les « créneaux horaires plus rapides » dans la feuille de route de la couche de consensus sont nouveaux, car les discussions sur les créneaux horaires plus rapides ont commencé en 2024 et la feuille de route de Vitalik a été mise à jour pour la dernière fois en 2023.

En plus de pouvoir accélérer ces projets importants, nous pouvons également éliminer une partie de la dette technique mentionnée précédemment. Si nous mettons en œuvre une finalité à source unique, les époques ne seront plus nécessaires et les slots pourront être utilisés directement. De plus, le contrat de dépôt actuel est un peu complexe et est un héritage de la fusion ; une infrastructure comme le comité de synchronisation ne sera plus nécessaire une fois que la SNARK en temps réel de Beacon Chain sera réalisée. C'est une occasion de tout nettoyer d'un coup.

Si vous êtes intéressé par certains des problèmes liés à la conception de Beacon Chain, l'année dernière, j'ai donné une conférence complète discutant plus de 20 erreurs que nous avons commises lors de la conception de Beacon Chain.

Cette image montre l'image complète de nos mises à niveau de la couche de consensus depuis sa création. Comme vous pouvez le voir dans le coin inférieur gauche, la genèse a eu lieu en 2020, et depuis lors, nous avons eu une nouvelle fourche chaque année, et avec chaque fourche, nous avons apporté des améliorations incrémentielles à la couche de consensus.

En 2021, nous avons ajouté un comité de synchronisation, en 2022 nous avons effectué une fusion, en 2023 nous avons ajouté des capacités de retrait et un éclatement dynamique natif, et en 2025 nous augmenterons le solde effectif maximum.

Attendez-vous à ce que nous continuions à effectuer ces fourches incrémentielles au cours des prochaines années, en saisissant les projets à faible difficulté marqués en vert dans le coin supérieur gauche de la feuille de route.

Peu à peu, nous rencontrerons un goulot d’étranglement. Une fois que tous les projets de faible difficulté sont terminés, les autres sont des projets majeurs difficiles à mettre en œuvre progressivement. À ce moment-là, « Beam Fork » est nécessaire. Beam Fork offre la possibilité de faire un grand bond en avant dans la couche de consensus grâce à une mise à niveau unique. Considérez le Beam Fork comme une opportunité de traitement par lots, où plusieurs mises à niveau sont fusionnées en un seul fork, avec des avantages à la fois techniques et de gouvernance.

Cette opportunité de traitement par lots peut être appelée "accélération solidifiée". Cela ressemble à un oxymore, mais l'idée de base est de vouloir qu'Ethereum entre en mode de maintenance le plus rapidement possible, et il y a une telle tension pour le moment. Nous savons qu'il y a quelques projets importants qui nécessitent une restructuration fondamentale d'Ethereum, et plus ces changements sont retardés, plus il faudra de temps avant qu'Ethereum n'atteigne un état stable.

Quelles technologies utilise Beam Chain?

Ensuite, nous passons à la deuxième partie, où j'introduis certaines des techniques qui seront utilisées dans Beam Chain. Pensez à cela comme à différentes époques du mécanisme de consensus d'Ethereum : initialement l'ère de la Preuve de Travail (POW), puis en passant à l'ère de la Preuve d'Enjeu (POS), et maintenant nous pourrions entrer dans une ère de Preuve de Connaissance Zéro (ZK).

À l'ère ZK, nous ferons un usage intensif de la technologie SNARKs. Un endroit où nous utilisons déjà les SNARKs est de fournir une vérification à connaissance nulle pour l'ensemble de la Beam Chain - la couche de consensus entière - et c'est là que les zkVMs (machines virtuelles à connaissance nulle) deviennent très utiles.

Imaginez que nous pourrions implémenter Beam Chain dans différents langages de programmation de haut niveau, tels que Rust et Go, puis compiler ces langages de haut niveau en bytecode que les zkVM peuvent comprendre pour réaliser une vérification SNARK sans se soucier des détails de bas niveau.

Un point qui doit être souligné est que la seule partie qui nécessite une vérification SNARK est la fonction de transition d'état, qui est le cœur de devenir un client de consensus. Essentiellement, la fonction de transition d'état est une très petite partie de la construction du client, et l'infrastructure environnante (comme le réseau, la synchronisation, l'optimisation du cache ou les règles de sélection de blocs) ne nécessite pas de vérification SNARK.

RISC-V est devenu la norme de l'industrie pour ces zkVM au cours des dernières années. RISC-V est un jeu d'instructions qui compile essentiellement du code de haut niveau en instructions RISC-V. Il existe maintenant sept entreprises proposant des zkVM RISC-V, telles que RISC Zero et SP1, dont vous avez peut-être entendu parler.

Il est important de noter que cette technologie puissante peut également être utilisée dans la couche d'exécution, ce qui est une autre histoire que Beam Chain, mais c'est très excitant car cela signifie que nous pouvons augmenter considérablement le plafond de gaz et améliorer Ethereum en tant que L1 Scalabilité verticale, mais c'est un autre sujet.

Un autre endroit où les SNARKs sont largement utilisés dans Beam Chain est dans les signatures agrégables. Nous aimerions avoir des signatures agrégables résistantes à la cryptographie quantique, et la proposition ici est d'utiliser des fonctions de hachage. Les fonctions de hachage sont résistantes à la cryptographie quantique et peuvent être utilisées comme module de base pour construire la cryptographie.

Nous utiliserons des signatures basées sur des hachages, générées par des vérificateurs et des prouveurs, et nous introduirons également des SNARKs basés sur des hachages qui peuvent compresser des milliers de signatures en une seule preuve. En combinant les deux, nous pouvons construire une solution basée sur des hachages, agrégeable et résistante aux attaques quantiques, qui peut être utilisée sur Ethereum. Un détail intéressant est que ce schéma d'agrégation a la capacité d'une agrégation récursive infinie, ce qui signifie que les résultats d'agrégation peuvent être continuellement ré-agrégés, ce qui n'est actuellement pas possible avec les signatures BLS et qui est plus flexible.

La raison pour laquelle je propose cela aujourd'hui est qu'il y a eu d'énormes améliorations des performances de la fonction de hachage SNARK ces derniers mois. Pour ceux qui le savent, nous avons maintenant pu le vérifier sur un ordinateur portable.

Ce benchmark a été réalisé sur un MacBook Pro CPU et peut maintenant vérifier 2 millions de hachages par seconde. Il s'agit d'une vitesse incroyable, ce qui signifie que cette proposition basée sur le hachage a une excellente performance sur Beam Chain. potentiel.

En plus du zkVM et des SNARKs que nous utiliserons, je tiens également à souligner que nous réutiliserons largement l'infrastructure existante.

Par exemple, la bibliothèque réseau libp2p, la bibliothèque de sérialisation Simple Serialize, etc. peuvent être réutilisées directement. Il en va de même pour le cadre Pyspec, le cadre de spécification Python que nous utilisons pour rédiger des spécifications formelles et des tests unitaires.

De plus, l'infrastructure telle que Protocol Guild peut également être réutilisée. Cela n'existait pas dans les premiers jours de Beacon Chain, mais peut maintenant être réutilisé gratuitement.

De même, il existe maintenant plusieurs équipes soutenant le développement de Beacon Chain. À cette époque, nous n'avions pas d'équipe de client de consensus. Les cinq équipes actuelles de client de consensus peuvent être utilisées directement sans avoir besoin de se réorganiser.

De plus, nous disposons d'équipes dédiées responsables des opérations combinées, telles que le support DevOps fourni par l'équipe Panda Ops, des groupes de recherche d'applications tels que l'équipe de sécurité et l'équipe de motivation, ce sont toutes des ressources qui peuvent être directement exploitées.

Dans la dernière partie, je veux parler des prochaines étapes et des perspectives futures. Un résultat possible est que, à partir de 2025, nous entrerons dans un processus de normalisation. Cela sera effectué par une petite équipe de chercheurs et pourrait prendre toute l'année. En 2026, le processus de développement démarrera avec des équipes de clients écrivant du code de qualité de production, suivi d'un processus de test très approfondi en 2027 pour garantir la sécurité et la stabilité des déploiements de production.

Source de l'image : Uncommons Dasong

Ma prochaine tâche en tant que chercheur est de commencer à rédiger une spécification exécutable, que j'appelle une "feuille de route exécutable". L'idée est de combiner les "pixels" de la feuille de route, les centaines de milliers de mots dans diverses recherches et articles académiques, et les différentes idées dans l'esprit des chercheurs, extraire leur essence fondamentale et former un document de spécification exécutable. En fin de compte, il s'agira d'un document très compact, d'environ 1000 lignes de code Python.

La chose passionnante pour moi est que s'il y a un consensus général sur la nouvelle direction de Beam Chain, ce sera une excellente occasion d'injecter du sang neuf dans le client de consensus.

Actuellement, notre équipe de clients de consensus est répartie en Amérique du Nord, en Europe et en Océanie. Aujourd'hui, je suis heureux d'annoncer qu'une nouvelle équipe a accepté de développer le client Beam. L'une des équipes est basée en Inde, appelée Zine, et elle écrit un client Beam en utilisant le langage Zig. Il y a aussi une équipe de la classe Lambda basée en Amérique du Sud qui a également exprimé son intérêt pour le développement d'un client Beam.

Si vous êtes également intéressé à participer, nous avons besoin de beaucoup de personnes talentueuses, y compris des experts en spécifications et en réseau, des coordinateurs, des experts en cryptographie et des développeurs de clients. Veuillez nous contacter via cet e-mail pour nous rejoindre et commencer cette nouvelle aventure ensemble. Merci beaucoup!

Avertissement :

1. Cet article est reproduit à partir de [BlockBeats], Tous les droits d'auteur appartiennent à l'auteur original [BlockBeats]. Si vous avez des objections à cette reproduction, veuillez contacter lePorte Apprendrel'é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, la copie, la distribution ou le plagiat des articles traduits est interdit.