Introduction

En 2024, de nombreux événements importants ont eu lieu autour d'Ethereum. En début d'année, Ethereum a introduit des blobs grâce à la mise à niveau de Dencun. Cette mise à jour a considérablement réduit les coûts de transaction pour les rollups existants, posant les bases de l'expansion rapide des écosystèmes de rollup.

(Réduction des frais dans les chaînes OP après la mise à niveau de Dencun | Source:Optimism X)

Cependant, alors que les dapps au sein de l'écosystème migraient vers des rollups hautement évolutifs et des réseaux alternatifs de couche 1 (L1), l'activité des utilisateurs sur Ethereum a commencé à décliner. De plus, alors que les rollups ont cessé de soumettre des frais élevés à Ethereum, des préoccupations ont commencé à apparaître au sein de la communauté.

De plus, 2024 a été une année où des L1 axés sur la scalabilité comme Solana et Sui ont démontré une force significative. Le nombre énorme de TPS (transactions par seconde) générées par ces réseaux a rendu l'activité sur les rollups relativement faible.

Dans ce contexte, des critiques ont émergé, telles que "La feuille de route d'Ethereum centrée sur les rollups est défectueuse" ou "Le développement d'Ethereum est trop lent pour réussir." Ethereum est-il vraiment sur la bonne voie? À quoi ressemblera Ethereum en 2025 ou même en 2030?

Cette série explore des parties de la feuille de route d'Ethereum sous deux principaux thèmes, en analysant son avenir en fonction des détails techniques. Le premier sujet est la Beam Chain.

Qu'est-ce que la proposition de la chaîne Beam, et pourquoi est-elle importante?

Si l'on devait choisir le sujet le plus discuté au sein de la communauté Ethereum cette année, il s'agirait probablement de l'annonce du chercheur Ethereum Justin Drake sur Beam Chain à Devcon. Cette annonce a suscité beaucoup d'intérêt et, par conséquent, beaucoup de bruit. Analysons ce que cette proposition signifie.

L'idée principale de la proposition Beam Chain est de repenser complètement la couche de consensus d'Ethereum. Justin Drake a présenté les trois raisons suivantes pour lesquelles la couche de consensus actuelle, la Beacon Chain, doit être repensée :

• Une meilleure compréhension de MEV grâce aux expériences passées
• Des avancées rapides dans la technologie SNARK (par exemple, le développement de zkVM progresse à un rythme stupéfiant, plus de 10 fois plus rapide)
• Éliminer la "dette technique" présente dans la Beacon Chain

Actuellement, la feuille de route de la couche de consensus d'Ethereum comprend les éléments suivants :

Parmi ceux-ci, les quatre domaines marqués en gras représentent des changements fondamentaux qui vont au-delà de simples modifications de la Beacon Chain. Par exemple, la snarkification de la chaîne fait référence à la conversion de la gestion de l'état de la couche de consensus en technologie ZK, nécessitant des changements fondamentaux allant des fonctions de hachage aux méthodes de merkleizing/sérialisation de l'état.

De plus, des fentes plus rapides et une finalité plus rapide sont de nouvelles conceptions proposées pour réaliser des améliorations de performances tout en maintenant la sécurité, un facteur qui n'était pas priorisé dans les conceptions initiales. La mise en œuvre de celles-ci nécessite des modifications importantes au niveau de consensus.

La chaîne Beam propose d'effectuer ces changements par le biais d'une seule mise à jour majeure. En résumé:

1. La mise en œuvre de la feuille de route de la couche de consensus d'Ethereum nécessite une refonte complète de la couche de consensus.
2. À cette fin, les grands changements sur la feuille de route seront regroupés dans un hard fork nommé Beam Chain.
3. Il comprend quatre éléments: des temps de bloc plus rapides, une finalité plus rapide, une snarkification de la chaîne et une résistance quantique.

Ensuite, explorons comment chacun d'entre eux est mis en œuvre et les impacts techniques qu'ils entraînent.

Détails techniques de la conception de la Beam Chain

Des emplacements plus rapides & une finalité plus rapide

Actuellement, le temps de fente d'Ethereum est de 12 secondes, et il faut 2 à 3 époques (environ 15 minutes) pour qu'un bloc connecté à une fente atteigne la finalité. Améliorer ces délais aurait un impact positif sur les utilisateurs, les applications et les rollups construits sur Ethereum.

Finalité plus courte (Orbit SSF)

Ce sujet, connu des chercheurs en Ethereum sous le nom de SSF (Finalité d'un seul créneau), vise à réduire le temps nécessaire aux blocs Ethereum pour atteindre la finalité d'environ 15 minutes à moins de 12 secondes, offrant ainsi aux utilisateurs une confirmation plus rapide. Pour comprendre la finalité d'un seul créneau, nous devons comprendre l'algorithme de consensus actuel d'Ethereum, Gasper.

Un principe de conception clé de Gasper est de garantir qu'un bloc proposé dans un créneau atteigne un certain niveau de sécurité économique après un certain temps tout en minimisant la charge de communication sur chaque validateur. Pour cela, Ethereum divise l'ensemble des validateurs en comités répartis sur 32 créneaux. Chaque créneau peut contenir jusqu'à 64 comités et l'objectif est de composer chaque comité de 128 validateurs (bien que ce nombre puisse augmenter si le nombre total de validateurs actifs dépasse cette limite).

Les validateurs au sein de chaque comité vérifient indépendamment le bloc et votent dessus en utilisant des signatures BLS. Le mécanisme de signature BLS permet d'agréger plusieurs signatures en une seule, ce qui signifie qu'un nœud désigné au sein du comité collecte ces signatures et les compile dans un seul paquet de données compact. En diffusant cette signature agrégée, le prochain proposant de bloc peut confirmer avec un minimum de données que le bloc a été correctement vérifié.

(Aggrégation de signatures BLS entre les validateurs d'Ethereum | Source: eth2book)

En résumé, le Gasper d'Ethereum parvient à la fois à la scalabilité et à la sécurité économique grâce aux mécanismes suivants:

• Les validateurs sont répartis dans des créneaux au sein de comités sur une période de 6,4 minutes, ce qui élimine la nécessité d'une communication directe entre tous les validateurs.
• Le processus de signature agrégée garantit que les votes des validateurs sur le bloc peuvent être vérifiés à l'aide d'une petite quantité de données.

Cependant, un problème se pose car Gasper fonctionne sur une base d'époque, et la "connectivité" entre les époques doit être vérifiée avant qu'une fente puisse atteindre la finalité. Dans Gasper, un minimum de deux époques (64 fentes) doit s'écouler avant d'atteindre une finalité équivalente à la sécurité économique complète d'Ethereum.

Cela donne la représentation diagrammatique suivante:

(Finalité économique à Gasper | Source:Orbit SSF)

Cela présente divers défis et diminue l'expérience utilisateur. Par exemple:

• Lorsque vous retirez des fonds d'un CEX (échange centralisé) vers Ethereum, ou vice versa, la période de confirmation peut être d'environ 10 minutes, ce qui est relativement excessif.
• Les rollups Ethereum et les dApps courent le risque que les blocs L1 sur lesquels ils s'appuient ne soient pas finalisés et puissent être invalidés. Si des contre-mesures appropriées ne sont pas mises en place, cela pourrait causer des problèmes.

Par exemple, en mars 2024, Polygon zkEVM a connu un arrêt de chaîne de plus de deux jours en raison d'une gestion inadéquate de la réorganisation d'Ethereum.

Réduire le temps de finalité n'est pas impossible, comme le montrent des algorithmes de consensus tels que Tendermint, qui sont déjà appliqués dans plusieurs protocoles. Cependant, le défi de l'adoption du mécanisme de Tendermint réside dans la fréquente communication P2P entre les nœuds, ce qui introduit des limitations de scalabilité.

Dans Tendermint, si le nombre de nœuds est N, sa complexité de message est O(N^3). Cela signifie que lorsque le nombre de nœuds augmente, la fréquence de communication entre eux augmente de manière exponentielle, limitant la scalabilité. Ainsi, des protocoles comme Ethereum, avec de nombreux validateurs, ne peuvent pas adopter directement Tendermint tel quel.

Des travaux supplémentaires doivent être effectués pour résoudre ces problèmes et appliquer le consensus de style Tendermint à Ethereum.

Un aperçu de la proposition Orbit SSF

Orbit SSF vise à modifier le mécanisme du comité de Gasper afin de réduire le temps de finalité des slots tout en maintenant une sécurité économique élevée.

La proposition est de réduire la taille de l'époque de 32 créneaux à un seul créneau (~12 secondes). Cependant, comme mentionné précédemment, cela augmenterait l'utilisation des ressources pour la communication des validateurs, impactant négativement la décentralisation d'Ethereum.

Pour remédier à cela, Orbit SSF propose les idées suivantes :

Augmenter le montant maximum de mise en jeu pour chaque validateur Ethereum peut permettre d'atteindre le même niveau de sécurité économique avec moins de validateurs.

Au lieu d'avoir plusieurs comités par créneau horaire, Orbit SSF suggère d'introduire un seul "super comité". Les validateurs avec des montants de mise plus élevés seraient presque toujours inclus proportionnellement dans le comité, garantissant ainsi le maintien du même niveau de sécurité économique même avec moins de comités.

La prochaine mise à niveau d'Ethereum, Pectra, comprend EIP-7251, qui propose d'augmenter le montant maximum de mise en jeu (MaxEB) pour les validateurs de 32 ETH à 2048 ETH. Bien que cette proposition soit attrayante pour les opérateurs d'infrastructure de nœuds Ethereum, elle est également une condition préalable à Orbit SSF.

Cependant, si les validateurs disposant de grandes sommes d'enjeu sont presque toujours inclus dans les comités, les plus petits validateurs en solo pourraient connaître des récompenses réduites, ce qui pourrait nuire à la décentralisation d'Ethereum. Pour éviter cela, Orbit SSF ajuste les récompenses de manière à ce que le taux annuel augmente linéairement avec le montant d'enjeu tout en veillant à ce que les plus grands validateurs soient inclus plus fréquemment dans les comités.

(Récompense et probabilité d'être inclus dans le comité dans Orbit SSF | Source:Orbit SSF)

De plus, Orbit SSF se dirige vers une « finalité basée sur le comité ». Dans Gasper, les comités ne pouvaient contribuer à la finalité qu'après que deux époques ou plus se soient écoulées, mais Orbit SSF permet à chaque comité assigné à une fente de contribuer en temps réel à la finalité. Il vise à faire des comités des contributeurs plus actifs à la finalité et à atteindre une scalabilité plus rapide.

(Finality in Orbit SSF using Cap-and-slow-rotate | Source:Orbit SSF)

La clé réside ici dans la composition des membres du comité. Orbit SSF propose un mécanisme de «rotation lente» où les validateurs de gros enjeux sont mathématiquement presque fixes au sein des comités tandis que les validateurs plus petits sont tournés en rotation. Cela permet de fixer la valeur de F, représentant le seuil de sécurité économique, très élevée tout en maintenant une communication minimale entre les validateurs et en garantissant des délais de finalité faibles.

Par exemple, en fixant n = 3 et un F considérablement grand, Ethereum pourrait atteindre la finalité en environ trois slots, réalisant ainsi la vision de Justin Drake d'un FFG à 3 slots.

Cependant, élever F au niveau de l'ensemble des validateurs d'Ethereum n'est pas facile. Cela pourrait réduire le coût de la réalisation d'une attaque de 51% sur Ethereum. Ainsi, le principal défi pour Orbit SSF à l'avenir est de déterminer comment augmenter techniquement F pour garantir que la sécurité d'Ethereum reste robuste sans sacrifier beaucoup de décentralisation.

Des durées de slot plus courtes (slots de 4 secondes) Même si SSF (ou finalité à 3 slots) est atteint, les utilisateurs d'Ethereum continueraient à subir un temps de confirmation de transaction minimum de 12 secondes. Cela entraîne deux principaux inconvénients pour les utilisateurs :

1. Latence élevée par rapport à d'autres L1 comme Solana et Sui
2. Vulnérabilité accrue à la MEV (la MEV diminue à mesure que le temps de bloc raccourcit, rendant les utilisateurs d'Ethereum plus susceptibles à la MEV)

De plus, un temps de bloc de 12 secondes est particulièrement défavorable pour les rollups, en particulier les rollups basés. Par exemple, Taiko met en œuvre un rollup basé en publiant chaque bloc L2 sur L1. En conséquence, le temps de bloc de Taiko pourrait augmenter à un minimum de 12 secondes et parfois dépasser 24 secondes.

Deux solutions ont été proposées pour résoudre cela :

a. Réduire le temps de bloc d'Ethereum à 4 ou 8 secondes

b. Utiliser des préconfirmations

Réduction du temps de blocage d'Ethereum

Réduire le temps de blocage d'Ethereum est un sujet de discussion active. Il a été formalisé sous la forme de l'EIP-7782, qui propose de réduire le temps de slot de 12 secondes à 8 secondes, augmentant ainsi la scalabilité d'Ethereum de 33%. Cependant, un temps de slot de 8 secondes peut ne pas être optimal pour l'expérience utilisateur ou pour les rollups basés. Atteindre un temps de slot plus court semble plus souhaitable.

Cela dit, des temps de bloc plus courts pourraient conduire à une centralisation accrue de l'ensemble des validateurs. En raison de contraintes physiques, les validateurs géographiquement éloignés font face à des temps de communication plus longs, et un délai de slot de 4 secondes pourrait rendre la communication infeasible dans certains scénarios.

Les statistiques sur le temps de propagation des blocs du réseau principal d'Ethereum fournissent des informations sur la faisabilité d'un temps de bloc de 4 secondes. Le graphique ci-dessous montre la répartition des temps de propagation des blocs.

(CDF of message arrival times | Source:Latence de propagation de message Gossipsub)

Environ 98% des blocs sont propagés en 4 secondes, tandis que environ 2% prennent plus de temps. Sur la base de ces données, un temps de bloc de 4 secondes peut sembler réalisable. Cependant, le temps de bloc prend en compte plus que simplement la communication - cela inclut l'exécution et le vote. En tenant compte de ces facteurs, seulement environ 2 secondes d'un temps de bloc de 4 secondes seraient disponibles pour la communication. Dans ces conditions, atteindre un temps de bloc de 4 secondes est un défi.

Pour remédier à cela, la taille des données transmises doit être réduite, les performances des composants P2P des clients doivent être maximisées, ou la communication physique doit devenir plus efficace.

Utilisation de préconfirmations

En attendant, les préconfirmations peuvent améliorer l'expérience utilisateur. Les préconfirmations permettent aux entités productrices de blocs de promettre aux utilisateurs que leur transaction sera incluse dans le prochain bloc, offrant ainsi des résultats plus rapides aux utilisateurs que le temps d'intervalle.

L'avantage de la préconfirmation est que les validateurs L1 peuvent l'utiliser sans nécessiter de fork ou de modifications du client. Par exemple, Commit-Boost est un logiciel permettant aux validateurs Ethereum de générer et propager en toute sécurité des préconfirmations.

Commit-Boost, comme MEV-Boost, est une extension facultative pour les validateurs, leur permettant de générer et de propager en toute sécurité des « engagements ». Selon le cas d'utilisation, ces engagements peuvent prendre différentes formes :

En utilisant le troisième type d'architecture de préconfirmation, la latence perçue pour les utilisateurs peut être considérablement réduite même avec des temps de bloc plus longs. Lorsqu'un validateur reçoit la transaction d'un utilisateur, il peut l'exécuter et renvoyer le résultat à l'utilisateur. Comme ce résultat est basé sur l'engagement du validateur et non sur la création de bloc, les utilisateurs peuvent le recevoir en quelques millisecondes.

Cependant, l'efficacité de Commit-Boost dépend de l'adoption par les validateurs. Si seulement quelques validateurs l'utilisent, l'impact sur l'UX sera minimal. Cela dit, Commit-Boost a reçu un fort soutien de la communauté Ethereum et a le potentiel de devenir un middleware répandu comme MEV-Boost. Il a reçu des approbations d'opérateurs de validateurs bien connus tels que Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 et Figment. De plus, il a obtenu des subventions de EF, Lido et Eigenlayer et bénéficie d'un fort soutien de Titan, constructeur de blocs.

Cependant, comme mentionné précédemment, la préconfirmation est plus susceptible d'être utilisée en tant que sidecar hors chaîne comme MEV-Boost plutôt que d'être intégrée directement dans le protocole.

Le rôle de Beam Chain dans des slots plus rapides

Comme discuté dans la présentation de Justin Drake, l'objectif de Beam Chain est de réduire le temps de bloc. Ainsi, la recherche et la mise en œuvre se concentreront probablement sur la réduction du temps de slot à 4 secondes sans sacrifier la décentralisation. Cela pourrait être résolu avec la snarkification complète d'Ethereum, qui sera expliquée dans la dernière partie de cet article.

Snarkification de chaîne et résistance quantique

Justin a déclaré dans sa présentation que l'objectif de Beam Chain est de snarkifier le client de consensus en utilisant la technologie ZK. Que signifie cela, comment peut-il être réalisé et pourquoi est-ce nécessaire?

Chain snarkification

Actuellement, la chaîne de balises Ethereum parvient à un consensus en demandant aux validateurs de "ré-exécuter" chaque bloc pour vérifier que la racine d'état résultante est correcte. Ce processus de ré-exécution introduit des inefficacités et constitue un obstacle à la réduction des exigences matérielles pour les validateurs.

Beam Chain vise à remplacer ce processus de réexécution par une « vérification » à l'aide de la technologie ZK. Cela réduirait considérablement les exigences matérielles pour les validateurs et permettrait à quiconque de lancer un nœud Ethereum de n'importe où. Pour y parvenir, Beam Chain et Ethereum utiliseront des ZK SNARKs.

ZK dans le protocole Ethereum

Les ZK SNARKs ont les deux propriétés suivantes:

1. Ils permettent de vérifier le fait qu'un certain calcul a été effectué sans avoir besoin de réexécuter le calcul
2. La taille de la preuve est compacte par rapport aux données d'origine

L’idée est d’appliquer ZK aux calculs et aux données nécessaires au consensus dans Ethereum, générant ainsi la preuve que la logique prescrite a été suivie. Cela signifie que les validateurs peuvent parvenir à un consensus en vérifiant la preuve ZK au lieu de réexécuter l’ensemble du bloc et de stocker l’état mis à jour. La vérification d’une preuve ZK est beaucoup plus efficace en termes de taille et d’évolutivité des données que la réexécution.

Par conséquent, les exigences matérielles pour les validateurs Ethereum peuvent être considérablement réduites. Par exemple, Vitalik a exprimé dans l'article de The Verge que l'objectif est de permettre aux validateurs de fonctionner même dans des environnements aux ressources limitées tels que les montres connectées.

Que faut-il faire?

La première étape consiste à snarkifier la fonction de transition d'état. La fonction de transition d'état prend généralement la forme suivante:

f(S,B)=S’

Ici :

• S: L'état préalable de la chaîne de blocs
• B: Le bloc donné
• S': L'état final de la blockchain après l'exécution du bloc
• f: La fonction de transition d'état

Toutes les blockchains sont basées sur des fonctions de transition d'état déterministes, et Ethereum ne fait pas exception. Ethereum dispose de différentes fonctions de transition d'état pour ses couches de consensus et d'exécution. Le fait de les snarkifier permettrait de vérifier l'ensemble du système Ethereum en utilisant ZK, rendant ainsi possible la validation complètement légère.

Dans Beam Chain, l'objectif est de snarkifier la fonction de transition d'état de la couche de consensus. Actuellement, la fonction de transition d'état au sein de la couche de consensus d'Ethereum est exécutée à chaque créneau et effectue les actions suivantes :

• Met à jour les informations d'emplacement et d'en-tête de bloc après réception d'un bloc
• Vérifie la signature du validateur qui a proposé le bloc
• Valide les transactions au sein du bloc
• Traite les retraits, les réductions, la finalisation des blocs et autres informations chaque fois qu'une époque passe.

Cette fonction est exécutée chaque fois qu'un validateur reçoit un bloc d'un autre validateur. Si cette fonction est snarkifiée, les validateurs n'auraient plus besoin d'exécuter directement la fonction de transition d'état. Au lieu de cela, ils pourraient vérifier une preuve montrant que la fonction a été exécutée correctement.

Dans ce cas, qui génère la preuve ZK ? En général, on pourrait supposer que le proposant du bloc est également responsable de la génération de la preuve ZK. Cependant, il est important de noter que tous les validateurs ne peuvent pas générer de preuves ZK.

Beam Chain vise à atteindre des performances permettant de générer une preuve ZK en 3 secondes sur un ordinateur portable standard. Cependant, même si cet objectif est atteint, les validateurs fonctionnant sur des appareils tels que des montres intelligentes ou des smartphones peuvent ne pas disposer de ressources suffisantes pour générer des preuves ZK.

Ici, le réseau peut compter sur l'altruisme. Seule une preuve ZK pour la transition d'état de la couche de consensus est nécessaire par bloc, et elle n'a pas nécessairement à être générée par le proposant de bloc. En d'autres termes, tant qu'au moins une entité dans le réseau génère une preuve ZK pour chaque bloc, cela peut garantir que les blocs de Beam Chain sont correctement produits.

Avenir : Snarkification complète d'Ethereum

Ce changement seul pourrait ne pas améliorer significativement les performances des validateurs. La fonction de transition d'état de la couche de consensus implique des actions relativement légères par rapport à la fonction de transition d'état de la couche d'exécution. Cependant, le principal goulot d'étranglement ne réside pas dans les ressources requises pour exécuter la fonction de transition d'état, mais dans la bande passante du réseau. Les validateurs ont du mal à parvenir à un consensus dans le temps imparti lorsque la taille des données (blocs) qu'ils échangent augmente. C'est l'une des raisons pour lesquelles Ethereum a maintenu une limite de gaz de 30M au cours des trois dernières années.

Si ce changement est mis en œuvre en même temps que la snarkification de la couche d'exécution, les validateurs n'auraient besoin d'échanger que des quantités beaucoup plus petites de données par rapport aux blocs entiers. Cela est dû au fait que les preuves SNARK sont considérablement plus compactes que les données d'origine. Les validateurs d'Ethereum entièrement snarkifiés échangeraient moins de données, réduisant les exigences du réseau par rapport au système actuel.

En résumé, voici les avantages de la pleine snarkification d'Ethereum pour les validateurs.

1. Les validateurs n'ont besoin de vérifier que les preuves, sans réexécuter les calculs, ce qui réduit les exigences en matière de calcul.
2. Les validateurs échangent des données de preuve au lieu de données de bloc complètes, ce qui réduit les exigences de bande passante du réseau

En conséquence, l'écosystème d'Ethereum pourrait changer radicalement. Par exemple :

• Des choses comme les «Applications de nœud Ethereum» pourraient permettre aux validateurs d'opérer sur des appareils mobiles.
• Toute personne remplissant les exigences minimales de mise en jeu pourrait exéer un nœud Ethereum, ce qui abaisserait considérablement la barrière à devenir un validateur.

Cela rendrait la participation des validateurs beaucoup plus accessible et décentralisée.

Signatures résistantes à la cryptanalyse quantique

Le fait de rendre snark le seul état de transition suffit-il pour le Beam Chain en tant que couche de consensus ?

Quels problèmes Ethereum rencontrera-t-il dans un monde post-quantique?

Il existe un autre domaine que Beam Chain vise à snarkifier : la génération de signatures. La couche de consensus d'Ethereum utilise actuellement les signatures des validateurs comme données d'attestation pour finaliser les blocs et déterminer la chaîne correcte en cas de forks.

Ethereum utilise actuellement des signatures BLS à cette fin, qui, comme expliqué précédemment, ont la propriété d'agrégation, permettant à plusieurs signatures d'être combinées en une seule. Cette agrégation améliore considérablement l'efficacité du processus de consensus d'Ethereum. Cependant, ce mécanisme de signature présente un problème fondamental : il est vulnérable aux ordinateurs quantiques.

Les signatures BLS utilisées dans la Beacon Chain d'Ethereum sont basées sur des courbes elliptiques. La sécurité des mécanismes de signature basés sur les courbes elliptiques repose sur le Problème du Logarithme Discret (DLP), que la puissance de calcul supérieure des ordinateurs quantiques pourrait compromettre. Cela rend les signatures basées sur les courbes elliptiques intrinsèquement vulnérables aux ordinateurs quantiques.

L'informatique quantique progresse rapidement, comme en témoignent les récents développements de Google avec des puces d'informatique quantique telles que Willow. Google affirme que Willow peut effectuer des calculs en 5 minutes, ce qui prendrait un superordinateur pendant 10^25 années. Bien que cela ne menace pas encore fondamentalement la sécurité des courbes elliptiques, des avancées continues à ce rythme pourraient mettre en danger les systèmes de blockchain d'ici quelques années.

(Transition vers les normes de cryptographie post-quantique | Source: NIST IR 8547)

L'Institut national des normes et de la technologie (NIST) des États-Unis a déjà commencé à standardiser les algorithmes de signature résistants à la cryptographie quantique afin de faire face à l'effondrement anticipé des systèmes existants en raison des ordinateurs quantiques.

Ethereum prend également ce problème au sérieux. Dans Beam Chain, l'objectif est d'atteindre des algorithmes de signature résistants aux attaques quantiques.

Il existe plusieurs types de signatures résistantes aux attaques quantiques, mais la présentation de la chaîne Beam de Justin a spécifiquement mentionné les algorithmes de signature basés sur des hachages. Contrairement aux courbes elliptiques, les signatures basées sur des hachages ne reposent pas sur des mécanismes mathématiques, ce qui les rend considérablement plus difficiles à compromettre pour les ordinateurs quantiques. En conséquence, les signatures basées sur des hachages sont considérées comme résistantes aux attaques quantiques, et Beam Chain vise à adopter de telles signatures.

Défis et rôle de ZK

Le principal défi est que les signatures basées sur le hachage manquent de la propriété d'agrégation présente dans les signatures BLS. Ethereum s'appuie sur l'agrégation de signatures lors du consensus pour atteindre l'efficacité. Sans agrégation, Ethereum ne serait plus en mesure d'accueillir un grand ensemble de validateurs.

ZK peut être utilisé pour résoudre ce problème. Il s'agit d'exploiter l'agrégation de preuves, une technologie qui combine plusieurs preuves ZK en une seule preuve. Le mécanisme fonctionne comme suit :

(Diagram of Proof Aggregation | Source: Figment Capital)

1. Les validateurs signent un bloc à l'aide d'un algorithme résistant à la cryptographie quantique.
2. Les signatures sont envoyées à un agrégateur **ou comité d'agrégation.
3. L'agrégateur génère une preuve ZK vérifiant la correction des signatures.
4. En utilisant des techniques d'agrégation de preuves, l'agrégateur combine de nouvelles preuves avec celles existantes au fur et à mesure que de nouvelles signatures sont reçues.

Cette approche permet à Ethereum d'atteindre la même efficacité que l'agrégation de signatures BLS tout en atteignant également la résistance quantique au niveau du consensus.

Rôles de ZK dans Beam Chain

En résumé, la chaîne Beam avec ZK apportera les avantages suivants :

1. Permettre aux validateurs d'effectuer une vérification de preuve au lieu d'une ré-exécution pour la fonction de transition d'état de la couche de consensus contribuant aux exigences légères des validateurs.
2. Servant de base pour un algorithme d'agrégation pour des signatures résistantes à la cryptographie quantique, améliorant l'efficacité de la couche de consensus.

zkVM comme fondement de ZK dans Beam Chain

Le système de preuve sous-jacent à ZK dans Beam Chain sera zkVM. zkVM basé sur Risc-V permet la preuve de n'importe quel programme dans n'importe quel langage, offrant une plus grande flexibilité.

(La transition de l'état Beam sera compilée en Risc-V et prouvée dans zkVMs | Source: Annonce de la chaîne Beam par Justin Drake)

Cela s'aligne bien avec l'écosystème client existant d'Ethereum, qui est développé dans plusieurs langages, préservant la diversité et la tolérance aux pannes d'Ethereum. Dans le futur Beam chain, différents clients écriront la fonction de transition d'état dans plusieurs langages de programmation, la compileront en Risc-V et permettront de la prouver dans n'importe quel zkVM basé sur Risc-V. Pour cette raison, zkVM est un choix naturel pour Beam Chain.

Conclusion

Si Beam Chain est mis en œuvre avec succès, Ethereum aura probablement les fonctionnalités suivantes:

1. Les utilisateurs bénéficieront de confirmations de transaction en moins de 4 secondes, avec une finalité atteinte en moins de 12 secondes.
2. Les validateurs vérifieront les transitions d'état dans la couche de consensus à l'aide de preuves ZK. Si la couche d'exécution est également snarkifiée, les validateurs n'auront besoin que de quantités minimales de données pour participer au consensus.
3. Les signatures des validateurs seront quantiquement résistantes
4. t, empêchant les ordinateurs quantiques de compromettre le consensus d’Ethereum.

Actuellement, Beam Chain n'a pas été officiellement reconnu comme faisant partie de la feuille de route d'Ethereum. Sa mise en œuvre nécessiterait des recherches approfondies, du développement et des tests sur une longue période. Cependant, si Ethereum procède à la division de la Beam Chain, les améliorations de l'expérience utilisateur qui en résulteront pourraient être transformatrices.

Cela conclut notre exploration de la façon dont Ethereum pourrait évoluer dans cinq ans à travers le prisme de Beam Chain. Dans le prochain article, nous examinerons à quoi Ethereum pourrait ressembler en 2025 selon deux perspectives : l'expérience utilisateur et la résistance à la censure.

Annexe : Beam Chain FAQs

(Q): La proposition de Justin Drake a été discutée en privé. N'est-ce pas en conflit avec la valeur fondamentale d'Ethereum d'être “ouverte”?

(R) : Non, ce n’est pas le cas. La proposition de Beam Chain suggère simplement de mettre en œuvre certaines parties de la feuille de route existante d’Ethereum en une seule fois. La question de savoir s’il sera mis en œuvre ou non est quelque chose qui nécessite encore une discussion communautaire. Tous les sujets abordés ci-dessus sont déjà associés à des EIP ou à des publications sur Ethresear.ch. Ceci, plus ou moins, montre que la Beam Chain n’est pas une proposition qui propose une nouvelle direction, jusqu’alors non divulguée, pour Ethereum. De plus, les discussions concernant la feuille de route d’Ethereum ont lieu publiquement lors de l’appel bihebdomadaire All Core Devs Call, auquel tout le monde peut participer. Si quelqu’un n’est pas d’accord avec la feuille de route ou a de nouvelles idées, il peut exprimer son opinion lors de ces appels ou soumettre de nouvelles propositions sous la forme d’EIP ou de publications sur Ethresear.ch.

En résumé, la proposition de Justin pour Beam Chain ne vise pas à modifier la feuille de route, mais plutôt à regrouper certaines parties de la feuille de route sous un nom ou un mème unique.

(Q): N'est-ce pas trop long pour mettre en œuvre Beam Chain pendant 5 ans ?

(A) : Cinq ans peuvent sembler longs, mais deux facteurs doivent être pris en compte :

1. Ethereum est construit sur une architecture multi-client.
2. Ethereum compte le plus grand nombre de validateurs de toutes les blockchains.

(Diversité des clients de consensus | Source: Diversité des clients Ethereum)

Le mécanisme de consensus d'Ethereum suit un protocole basé sur la BFT où si plus d'un tiers des validateurs agissent différemment des autres, les blocs ne peuvent pas être finalisés. Si Ethereum était construit avec seulement un ou deux clients, tout bug dans ces clients pourrait perturber la production de blocs. Par conséquent, Ethereum a toujours visé une architecture multi-client développée dans plusieurs langages de programmation. Cette diversité est évidente dans l'écosystème actuel de clients d'Ethereum.

Comme le montre l'image, la couche de consensus d'Ethereum fonctionne actuellement avec au moins quatre clients. Pour remplacer la Beacon Chain par la Beam Chain, les quatre équipes de clients doivent collaborer sur le développement. Compte tenu de cela et du grand ensemble de validateurs d'Ethereum, le processus de développement de la Beam Chain doit donner la priorité à la stabilité et ne peut pas être accéléré sur une période de quelques mois ou de 1 à 2 ans.

Clause de non-responsabilité:

1. Cet article est repris à partir de [ 2077research]. Tous les droits d'auteur appartiennent à l'auteur original [sm-stack]. S'il y a des objections à cette réimpression, veuillez contacter le Apprendre Gatel'é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. L'équipe de traduction de Gate Learn réalise des traductions de l'article dans d'autres langues. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.