Nouvelle proposition de couche de consensus Beam Chain de Justin pour Ethereum

Rédigé par : Tia, Techub News

Lors de la scène principale de Devcon en Thaïlande hier, Justin Drake, chercheur chez Ethereum, a présenté pour la première fois la proposition de Beam Chain lors d'une conférence. Beam Chain est une proposition de révision de la couche de consensus d'Ethereum, conçue par Justin pour une amélioration ultérieure de Beacon Chain, dans le but de progresser vers la vision finale d'Ethereum. Cet article vous présentera rapidement les objectifs d'amélioration de la proposition Beam Chain et les mises en œuvre technologiques associées.

Bien que ce soit une refonte de la couche de consensus, Beam Chain continuera d'utiliser les Jetons Ethereum, sans émettre de nouveaux Jetons ni lancer de nouveau réseau.

Pourquoi proposer Beam Chain?

Ethereum a trois niveaux : la couche d'exécution, la couche de données blob et la couche de consensus. La couche d'exécution est la partie d'Ethereum qui traite les transactions et exécute les smart contracts, gérant directement l'état et la logique de l'application. La couche de données blob est responsable du stockage d'une grande quantité de données nécessaires au stockage à long terme des applications. Ces deux couches appartiennent aux niveaux qui interagissent directement avec les applications, et tout changement affectera directement la compatibilité de ces couches.

La couche de consensus est principalement responsable de garantir le consensus des données entre les nœuds du réseau, sans traiter directement l'état ou les données de l'application. Cette indirectivité facilite l'introduction d'innovations et de mises à niveau sans avoir d'impact direct sur l'application. Ainsi, des améliorations telles que la proposition Beam Chain dans la couche de consensus peuvent offrir un espace d'innovation sans compromettre la compatibilité de la couche d'application frontale.

De plus, Beacon Chain est une conception datant de 5 ans et est très obsolète. Au bout de 5 ans, le marché a une bonne compréhension des erreurs de Beacon Chain et une compréhension plus approfondie de MEV. Parallèlement aux avancées de la technologie SNARK, une série de réparations ont été apportées à la couche de consensus d'ETH.

Objectifs du projet Beam Chain

Le but peut être divisé en trois parties : la production de blocs, le stake, et la cryptographie.

Les objectifs de production du Bloc sont au nombre de trois, principalement liés à la MEV : premièrement, prévoir d'augmenter l'anti-censure avec des listes d'inclusion, etc. ; deuxièmement, isoler les validateurs de la production du Bloc en utilisant la séparation des Attester Proposer et des enchères ; troisièmement, réaliser des slots plus rapides en raccourcissant le temps de slot à 4 secondes.

L'objectif de la partie stake est d'améliorer la courbe d'émission actuelle, de réduire le seuil de mise de 32 ETH à 1 ETH, et d'atteindre une finalité unique de slot rapide.

L'objectif de la cryptographie est d'utiliser zkVM et autres pour réaliser la snarkification de la chaîne ; maintenir la sécurité de la cryptographie ETH pendant des décennies, voire des centaines d'années ; et maintenir une forte aléatoire avec des techniques comme MinRoot VDF.

Pour la réalisation de ces objectifs, Justin a divisé ces objectifs en deux catégories. La partie verte sera accomplie progressivement par fork, tandis que la partie rouge devrait être réalisée simultanément dans son ensemble.

Par exemple, en utilisant la snarkification (utilisation de la technologie zk-SNARKs pour prouver des données ou des calculs), si l'on souhaite réaliser une preuve en temps réel, des ajustements structurels doivent être apportés au système, notamment au niveau des fonctions de hachage, des modes de signature, de la sérialisation et de la Merkleization. Les modes de signature doivent être capables de générer et de vérifier rapidement, et la sérialisation doit permettre à des structures de données complexes d'être transmises et stockées entre les nœuds, puis les données sérialisées doivent être traitées en arbre de Merkle, pour répondre aux besoins de preuve de connaissance nulle en formatant et en transformant les données de manière vérifiable, ainsi qu'en vérifiant efficacement l'état.

Chaîne Beam convertie en ZK

Dans le passé, le consensus de la chaîne Ethereum a subi une transition de POW à POS, tandis que dans le mécanisme de Beam Chain, le consensus subira une mise à jour plus poussée - une complète ZKification, c'est-à-dire l'application de snark à l'ensemble de la couche de consensus.

Chain snarkification

Il convient de souligner que la partie snarkifiée n'existe que dans la transition d'état, mais certains calculs de base (les calculs logiques que le Mécanisme de consensus effectue avant de traiter les transactions ou les transitions d'état), les couches réseau (la communication et la transmission de données entre les Nœuds), la gestion du cache et l'optimisation des performances restent inchangés et ne sont pas affectés par ZK.

Le code d'implémentation de Beam Chain (c'est-à-dire la logique centrale de Beam Chain et le code de l'algorithme de consensus écrit en Go ou Rust) doit être converti en un format compréhensible par zkVM. Une fois que le code d'implémentation de Beam Chain est compilé en code zkVM, zkVM peut exécuter ce code, lire les entrées externes de la chaîne de blocs, vérifier la légitimité du processus de transition d'état et générer une preuve de connaissance nulle.

zkVM est un environnement d'exécution de Machine virtuelle à connaissance nulle qui comprend un code au format spécifique pour vérifier la preuve de connaissance nulle. Le processus de compilation du code en un format exécutable pour zkVM peut inclure la conversion d'un langage de haut niveau (tel que Go ou Rust) en un format intermédiaire de bas niveau (tel que l'ensemble d'instructions RISC-V), puis l'exécuter dans zkVM.

Actuellement, RISC-V est devenu la norme de l'industrie pour zkVM. Actuellement, sept entreprises proposent Risc-v zkVM.

Snarkification d'attestation

Une autre partie de l'utilisation de snark est la signature agrégeable (aggregatable signatures), c'est-à-dire le processus de compression des signatures de plusieurs validateurs et témoins (attesters), regroupant de nombreuses signatures en une seule preuve vérifiable.

Nous espérons avoir une sécurité de signature d'agrégation post-quantique (résistante aux attaques quantiques), il est donc prévu d'utiliser ici la fonction de hachage. Les fonctions de hachage ont un niveau de sécurité post-quantique et peuvent être utilisées comme composant de base ou module de base d'un système cryptographique. En utilisant des snarks basés sur le hachage, des milliers de signatures peuvent être compressées en une seule preuve. C'est ce qu'on appelle une signature d'agrégation post-quantique. De plus, cette signature d'agrégation post-quantique est récursive à l'infini, vous pouvez continuellement l'ajouter en agrégeant à nouveau plusieurs signatures d'agrégation pour obtenir une efficacité de compression plus élevée, ce qui entraîne une amélioration considérable par rapport à l'agrégation de signatures BLS traditionnelle.

Au cours des derniers mois, la technologie de hachage avec snark a connu des améliorations significatives, permettant de générer rapidement des preuves sur un ordinateur portable et de réaliser environ 2 millions d'opérations de hachage par seconde. Cette percée de performance rend les schémas de signature agrégée post-quantique plus pratiques dans la réalité, offrant ainsi la possibilité d'un chiffrement efficace et résistant aux attaques quantiques.

De plus, la chaîne Beam transformée en snark comprime les processus de vérification, de stockage et de calcul complexes, ce qui permet de mettre en œuvre une série d'infrastructures de base telles que libp2p, ssz, pyspec, protocolguild, etc., qui ne pouvaient pas être directement utilisées sur la chaîne Beacon.

Planification de la chronologie

Dans la planification de la chronologie, Justin prévoit de définir les spécifications en 2025, de construire en 2026 et de tester en 2027. Actuellement, deux équipes sont prêtes à développer le client Beam Chain Consensus, l'une étant Zeam lambda d'Inde et l'autre Lambda d'Amérique du Sud.