Écrit par Tia, Techub News

Lors du Mainstage de Devcon en Thaïlande hier, le chercheur d'Éther Justin Drake a présenté pour la première fois la proposition de Beam Chain sous forme de discours. Beam Chain est une proposition de Justin visant à redessiner la couche de consensus d'Éther, qui vise à améliorer davantage Beacon Chain pour progresser vers la vision finale d'Éther. Cet article vous présentera les objectifs d'amélioration de la proposition Beam Chain et sa mise en œuvre technologique.

Bien que Beam Chain soit une refonte de la couche de consensus, elle continuera d'utiliser les Jetons Ethereum, sans émission de nouveaux Jetons ni 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 des applications. La couche de données blob est responsable du stockage de grandes quantités de données, impliquant le stockage à long terme des données nécessaires aux applications. Ces deux couches sont des niveaux qui interagissent directement avec les applications, toute modification aura un impact direct sur la compatibilité de ces couches.

La couche Consensus est principalement responsable de garantir le consensus des données entre tous 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 de la couche Consensus telles que la proposition Beam Chain peuvent fournir un espace d'innovation sans compromettre la compatibilité de la couche Application en amont.

De plus, Beacon Chain est une conception datant de 5 ans et elle est très obsolète. Après 5 ans, le marché a une compréhension suffisante de certaines erreurs de Beacon Chain et une compréhension plus approfondie de la MEV. De plus, la technologie SNARK a également fait des percées. Par conséquent, profitant de cette percée, des 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 trois objectifs de la production de blocs sont principalement liés à MEV : premièrement, augmenter la résistance à la censure en utilisant des listes d'inclusion ; deuxièmement, isoler les validateurs de la production de blocs en utilisant la séparation des attesteurs et des proposants ainsi que des enchères d'exécution ; troisièmement, réduire le temps de slot à 4 secondes pour une plus grande rapidité.

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

L'objectif de la partie cryptographique est d'utiliser zkVM et autres pour réaliser la snarkification de la chaîne ; maintenir la sécurité cryptographique d'ETH-BTC pour qu'elle puisse durer des dizaines voire des centaines d'années ; et maintenir une forte aléatoire avec l'utilisation de MinRoot VDF, etc.

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

Prenons l'exemple de 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 effectués dans le système, notamment au niveau des fonctions de hachage, des méthodes de signature, de la sérialisation et de la mérialisation. La méthode de signature doit être capable de générer et de vérifier rapidement, et la sérialisation permet à des structures de données complexes d'être transmises et stockées entre les nœuds, après quoi les données sérialisées sont traitées à l'aide d'un arbre de Merkle pour répondre aux besoins de la preuve à zéro connaissance en termes de formatage et de transformation vérifiables des données, ainsi que de vérification efficace de l'état.

Chaîne Beam ZK-hashed

Dans le passé, le consensus d'ETH a subi une transition de la preuve de travail (POW) à la preuve d'enjeu (POS). Dans le mécanisme de Beam Chain, le consensus sera encore plus avancé - une pleine ZK transformation, c'est-à-dire l'application de snark à l'ensemble de la couche de consensus.

Chain snarkification

Il est important de souligner que la partie snarkifiée n'existe que dans les transitions d'état, mais les calculs de base (calculs logiques effectués avant les transactions ou les transitions d'état du Mécanisme de consensus), la couche réseau (communication et 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 (par exemple, la logique centrale de Beam Chain écrite en Go ou Rust et le code de consensus) doit être converti en un format compréhensible par zkVM. Une fois que le code d'implémentation de Beam Chain est compilé dans le format de 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 zk-SNARKs, il comprend un code au format spécifique pour la vérification de la preuve de connaissance nulle. Le processus de compilation du code en un format exécutable par zkVM peut inclure la transformation d'un langage de haut niveau (comme Go ou Rust) en un format intermédiaire de bas niveau (comme l'ensemble d'instructions RISC-V), suivi de l'exécution dans zkVM.

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

Attestation****snarkification

Une autre partie qui utilise snark est la signature agrégée, c'est-à-dire le processus de compression des signatures de nombreux validateurs et attestants en une seule preuve agrégée et vérifiable.

Nous espérons avoir une sécurité de signature post-quantique (résistante aux attaques quantiques), donc nous nous attendons à utiliser une fonction de hachage ici. 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 pour construire des systèmes cryptographiques. En utilisant des snarks basés sur le hachage, des milliers de signatures peuvent être compressées en une preuve. C'est ce qu'on appelle une signature post-quantique agrégée. De plus, cette signature post-quantique agrégée est récursive à l'infini, vous pouvez continuellement superposer, agréger à nouveau plusieurs signatures agrégées pour atteindre une efficacité de compression plus élevée, ce qui représente une amélioration considérable par rapport à l'agrégation de signatures BLS traditionnelle.

Au cours des derniers mois, la technologie de hachage snark a connu une amélioration significative, 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 avancée de performance rend les schémas de signature agrégée résistants aux quantiques plus praticables dans la réalité, offrant ainsi la possibilité d'un chiffrement efficace et résistant aux quantiques.

De plus, la chaîne Beam transformée en snark comprime les processus de vérification, de stockage et de calcul qui étaient auparavant complexes, ce qui permet à une série d'infrastructures telles que libp2p, ssz, pyspec, protocolguild, qui ne pouvaient pas être directement utilisées dans Beacon Chain, de fonctionner.

Planification de la chronologie

Dans la planification de la chronologie, Justin prévoit de spécifier en 2025, de construire en 2026 et de tester en 2027. Pour l'instant, 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.