Nouvel article de Vitalik : L'avenir possible du protocole Ethereum The Verge

En réalité, il nous faudra des années pour obtenir une preuve de validité du consensus d’Ethereum.

Titre original : « Possible futures of the Ethereum protocol, part 4: The Verge »

Auteur : Vitalik Buterin

Traduction : Mensh, ChainCatcher

 

Remerciements particuliers à Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams et Uma Roy pour leurs retours et relectures.

L’une des fonctionnalités les plus puissantes de la blockchain est que n’importe qui peut exécuter un nœud sur son propre ordinateur et vérifier la validité de la blockchain. Même si 9596 nœuds exécutant le consensus de la chaîne (PoW, PoS) acceptaient immédiatement de modifier les règles et commençaient à produire des blocs selon ces nouvelles règles, toute personne exécutant un nœud de validation complet refuserait d’accepter cette chaîne. Les producteurs de blocs qui ne font pas partie de ce complot convergeraient automatiquement vers une chaîne qui continue de suivre les anciennes règles et continueraient à construire dessus, tandis que les utilisateurs effectuant une validation complète suivraient cette chaîne.

C’est la différence clé entre la blockchain et les systèmes centralisés. Cependant, pour que cette propriété tienne, il faut que l’exécution d’un nœud de validation complet soit réellement faisable pour un nombre suffisant de personnes. Cela concerne aussi bien les producteurs de blocs (car s’ils ne valident pas la chaîne, ils ne contribuent pas à l’application des règles du protocole) que les utilisateurs ordinaires. Aujourd’hui, il est possible d’exécuter un nœud sur un ordinateur portable grand public (y compris celui utilisé pour écrire cet article), mais cela reste difficile. The Verge vise à changer cela, à rendre le coût de calcul pour valider complètement la chaîne très faible, de sorte que chaque portefeuille mobile, portefeuille navigateur, voire montre connectée, effectue par défaut une validation.

Feuille de route The Verge 2023

À l’origine, « Verge » désignait le transfert du stockage de l’état d’Ethereum vers les arbres Verkle — une structure arborescente permettant des preuves plus compactes, rendant possible la validation sans état des blocs Ethereum. Un nœud peut valider un bloc Ethereum sans stocker aucun état Ethereum (soldes de comptes, code de contrat, espace de stockage...) sur son disque dur, au prix de quelques centaines de Ko de données de preuve et de quelques centaines de millisecondes supplémentaires pour valider une preuve. Aujourd’hui, Verge représente une vision plus large, axée sur la validation la plus efficiente possible des ressources de la chaîne Ethereum, incluant non seulement la validation sans état, mais aussi l’utilisation de SNARK pour vérifier toute l’exécution d’Ethereum.

Outre l’intérêt à long terme pour la vérification SNARK de la chaîne entière, une autre question récente concerne la pertinence des arbres Verkle comme technologie optimale. Les arbres Verkle sont vulnérables aux attaques des ordinateurs quantiques, donc si nous remplaçons l’arbre Merkle Patricia KECCAK actuel par un arbre Verkle, il faudra peut-être le remplacer à nouveau plus tard. Une alternative auto-remplaçante de l’arbre Merkle consiste à passer directement à l’utilisation de STARK sur des branches Merkle, dans un arbre binaire. Historiquement, cette approche était jugée irréaliste à cause de la surcharge et de la complexité technique. Mais récemment, Starkware a prouvé 1,7 million de hachages Poseidon par seconde sur un ordinateur portable, et grâce à des techniques comme GKB, la preuve de hachages plus « traditionnels » s’accélère rapidement. Ainsi, au cours de l’année écoulée, « Verge » est devenu plus ouvert, avec plusieurs possibilités.

The Verge : Objectifs clés

• Client sans état : l’espace de stockage requis pour un client de validation complet et un nœud témoin ne doit pas dépasser quelques Go.
• (À long terme) Validation complète de la chaîne (consensus et exécution) sur une montre connectée. Télécharger quelques données, vérifier un SNARK, terminé.

Dans ce chapitre

• Client sans état : Verkle ou STARKs
• Preuve de validité de l’exécution EVM
• Preuve de validité du consensus

Validation sans état : Verkle ou STARKs

Quel problème voulons-nous résoudre ?

Aujourd’hui, un client Ethereum doit stocker des centaines de gigaoctets de données d’état pour valider les blocs, et ce chiffre augmente chaque année. Les données d’état brutes augmentent d’environ 30 Go par an, et chaque client doit stocker des données supplémentaires pour mettre à jour efficacement les triplets.

Cela réduit le nombre d’utilisateurs capables d’exécuter un nœud Ethereum de validation complet : bien que les disques durs suffisamment grands pour stocker tout l’état Ethereum et des années d’historique soient courants, les ordinateurs achetés par défaut n’ont souvent que quelques centaines de Go d’espace. La taille de l’état rend aussi le processus d’initialisation d’un nœud très laborieux : il faut télécharger tout l’état, ce qui peut prendre des heures ou des jours. Cela entraîne divers effets en chaîne. Par exemple, cela complique grandement la mise à niveau des nœuds. Techniquement, cela peut se faire sans interruption — démarrer un nouveau client, attendre la synchronisation, puis éteindre l’ancien et transférer les clés — mais en pratique, c’est très complexe.

Comment cela fonctionne-t-il ?

La validation sans état permet à un nœud de valider un bloc sans posséder tout l’état. À la place, chaque bloc est accompagné d’un témoin, qui inclut : (i) les valeurs, codes, soldes, stockages des positions de l’état que le bloc va accéder ; (ii) une preuve cryptographique de la validité de ces valeurs.

En pratique, la validation sans état nécessite de modifier la structure de l’arbre d’état d’Ethereum. L’arbre Merkle Patricia actuel est extrêmement inadapté à toute preuve cryptographique, surtout dans le pire des cas. Que ce soit des branches Merkle « brutes » ou des branches Merkle encapsulées dans un STARK, la difficulté principale vient de certaines faiblesses du MPT :

1. C’est un arbre à 16 branches (chaque nœud a 16 enfants). Cela signifie que, dans un arbre de taille N, une preuve nécessite en moyenne 32*(16-1)*log16(N) = 120*log2(N) octets, soit environ 3840 octets pour un arbre de 2^32 éléments. Pour un arbre binaire, il ne faut que 32*(2-1)*log2(N) = 32*log2(N) octets, soit environ 1024 octets.

2. Le code n’est pas Merklisé. Cela signifie que pour prouver l’accès au code d’un compte, il faut fournir tout le code, jusqu’à 24000 octets.

 

On peut calculer le pire des cas comme suit :

30000000 gas / 2400 (coût de lecture d’un compte froid) * (5 * 488 + 24000) = 330000000 octets

Le coût des branches est légèrement réduit (on utilise 5*480 au lieu de 8*480), car lorsque les branches sont nombreuses, leur sommet se répète. Mais même ainsi, la quantité de données à télécharger dans un slot est irréaliste. Si on essaie d’encapsuler cela dans un STARK, on rencontre deux problèmes : (i) KECCAK n’est pas très adapté aux STARK ; (ii) 330 Mo de données signifient qu’il faut prouver 5 millions d’appels à la fonction KECCAK round, ce qui est probablement infaisable pour tout matériel sauf le plus puissant, même si l’on améliore l’efficacité des preuves STARK pour KECCAK.

Si on remplace directement l’arbre hexadécimal par un arbre binaire et qu’on Merklise le code, le pire des cas devient environ 30000000/2400*32*(32-14+8) = 10400000 octets (14 est la soustraction des bits redondants pour 2^14 branches, 8 est la longueur de la preuve pour entrer dans une feuille de code). À noter : cela nécessite de modifier le coût en gas, en facturant chaque accès à un bloc de code ; c’est ce que fait l’EIP-4762. 10,4 Mo, c’est bien mieux, mais pour beaucoup de nœuds, c’est encore trop à télécharger en un slot. Il faut donc des techniques plus puissantes. Deux solutions principales : les arbres Verkle et les arbres de hachage binaires STARKed.

Arbres Verkle

Les arbres Verkle utilisent des engagements vectoriels basés sur les courbes elliptiques pour des preuves plus courtes. La clé est que, quelle que soit la largeur de l’arbre, chaque relation parent-enfant dans la preuve ne fait que 32 octets. La seule limite à la largeur de l’arbre est que, s’il est trop large, l’efficacité du calcul de la preuve diminue. La proposition pour Ethereum fixe la largeur à 256.

Ainsi, la taille d’une branche de preuve devient 32 - log256(N) = 4*log2(N) octets. Donc, la taille maximale théorique de la preuve est environ 30000000 / 2400 *32*(32-14+8)/8 = 130000 octets (en réalité, c’est légèrement différent à cause de la distribution inégale des blocs d’état, mais c’est une bonne approximation).

À noter aussi : dans tous ces exemples, ce « pire des cas » n’est pas le pire absolu : un attaquant pourrait « miner » deux adresses ayant un long préfixe commun dans l’arbre, et lire depuis l’une d’elles, doublant la longueur de la branche. Mais même ainsi, la longueur maximale de preuve pour Verkle est de 2,6 Mo, ce qui correspond à la taille maximale actuelle des données de vérification.

On exploite aussi cette propriété pour rendre l’accès à des espaces de stockage « adjacents » très peu coûteux : soit de nombreux blocs de code du même contrat, soit des slots de stockage voisins. L’EIP-4762 définit l’adjacence et ne facture que 200 gas pour les accès adjacents. Dans ce cas, la taille maximale de la preuve devient 30000000 / 200*32 - 4800800 octets, ce qui reste dans la tolérance. Pour plus de sécurité, on peut augmenter légèrement le coût des accès adjacents.

Arbres de hachage binaires STARKed

Le principe est simple : on construit un arbre binaire, on obtient une preuve de 10,4 Mo maximum, on prouve les valeurs dans le bloc, puis on remplace la preuve par un STARK. Ainsi, la preuve ne contient que les données prouvées, plus une surcharge fixe de 100 à 300 Ko du STARK.

Le principal défi ici est le temps de vérification. On peut refaire le même calcul, mais en nombre de hachages. Un bloc de 10,4 Mo implique 330000 hachages. Si un attaquant « mine » des adresses avec un long préfixe commun, on atteint 660000 hachages dans le pire des cas. Si on peut prouver 200 000 hachages par seconde, c’est bon.

Sur un ordinateur portable grand public avec la fonction de hachage Poseidon, ces chiffres sont déjà atteints, et Poseidon est conçu pour être STARK-friendly. Mais Poseidon reste relativement nouveau, donc la confiance dans sa sécurité n’est pas totale. Deux voies réalistes :

1. Analyser rapidement la sécurité de Poseidon et s’y familiariser pour un déploiement sur L1
2. Utiliser des fonctions de hachage plus « conservatrices » comme SHA256 ou BLAKE

Pour ces fonctions conservatrices, le cercle STARK de Starkware ne prouve aujourd’hui que 10-30k hachages par seconde sur un ordinateur portable. Mais la technologie STARK progresse vite. Même aujourd’hui, les techniques basées sur GKR montrent qu’on peut atteindre 100-200k.

Cas d’usage des témoins hors validation de blocs

Outre la validation des blocs, il existe trois autres cas d’usage clés pour une validation sans état plus efficace :

• Mempool : lors de la diffusion d’une transaction, les nœuds du réseau P2P doivent vérifier sa validité avant de la relayer. Aujourd’hui, cela inclut la vérification de la signature, du solde et du nonce. À l’avenir (par exemple avec l’abstraction de compte native, EIP-7701), cela pourrait impliquer l’exécution de code EVM accédant à l’état. Si le nœud est sans état, la transaction doit inclure une preuve de l’état.
• Liste d’inclusion : fonctionnalité proposée permettant à des validateurs PoS (peut-être petits et simples) d’imposer l’inclusion d’une transaction dans le prochain bloc, indépendamment de la volonté des constructeurs de blocs (peut-être plus grands et complexes). Cela limite la capacité des puissants à manipuler la chaîne en retardant des transactions. Mais cela nécessite que les validateurs puissent vérifier la validité des transactions de la liste d’inclusion.
• Client léger : pour que les utilisateurs accèdent à la chaîne via leur portefeuille (Metamask, Rainbow, Rabby, etc.), ils doivent exécuter un client léger (comme Helios). Le module central de Helios fournit la racine d’état vérifiée. Pour une expérience totalement sans confiance, il faut une preuve pour chaque appel RPC (par exemple, pour un appel eth_call, il faut prouver tous les accès à l’état pendant l’appel).

Tous ces cas d’usage requièrent de nombreuses preuves, mais chaque preuve est petite. Les preuves STARK n’ont donc pas d’intérêt pratique ici ; il est plus réaliste d’utiliser directement des branches Merkle. Un autre avantage des branches Merkle est leur capacité de mise à jour : avec une preuve pour un objet d’état raciné sur le bloc B, si on reçoit un sous-bloc B2 et son témoin, on peut mettre à jour la preuve pour qu’elle soit racinée sur B2. Les preuves Verkle sont aussi nativement mises à jour.

Liens avec la recherche existante :

• Verkle trees
• Article original de John Kuszmaul sur les arbres Verkle
• Starkware
• Poseidon2 paper
• Ajtai (fonction de hachage rapide alternative basée sur la difficulté des réseaux)
• Verkle.info

Que reste-t-il à faire ?

Le travail principal restant est :

1. Plus d’analyse sur les conséquences de l’EIP-4762 (changement du coût en gas sans état)

2. Plus de travail sur la finalisation et le test du programme de transition, qui est la principale complexité de toute implémentation sans état

3. Plus d’analyse de sécurité sur Poseidon, Ajtai et autres fonctions de hachage « STARK-friendly »

4. Développer davantage des protocoles STARK ultra-efficaces pour les fonctions de hachage « conservatrices » (ou « traditionnelles »), par exemple via Binius ou GKR.

En outre, nous devrons bientôt choisir entre trois options : (i) arbre Verkle, (ii) fonction de hachage STARK-friendly, (iii) fonction de hachage conservatrice. Leurs caractéristiques sont résumées dans le tableau ci-dessous :

Outre ces « chiffres principaux », d’autres considérations importantes :

• Aujourd’hui, le code des arbres Verkle est déjà assez mature. Utiliser un autre code que Verkle retarderait le déploiement, probablement un hard fork. Ce n’est pas grave, surtout si on a besoin de plus de temps pour l’analyse des fonctions de hachage ou l’implémentation du validateur, ou si on souhaite intégrer d’autres fonctionnalités importantes plus tôt dans Ethereum.
• Mettre à jour la racine d’état avec des hachages est plus rapide qu’avec un arbre Verkle. Cela signifie que la méthode basée sur les hachages peut réduire le temps de synchronisation des nœuds complets.
• Les arbres Verkle ont des propriétés intéressantes de mise à jour des témoins — les témoins Verkle sont actualisables. C’est utile pour le mempool, les listes d’inclusion et d’autres cas d’usage, et cela peut aussi améliorer l’efficacité : si un objet d’état est mis à jour, on peut actualiser le témoin de l’avant-dernière couche sans lire la dernière couche.
• Les arbres Verkle sont plus difficiles à prouver par SNARK. Si on veut réduire la taille de la preuve à quelques Ko, les preuves Verkle posent problème. Cela vient du fait que la vérification d’une preuve Verkle implique beaucoup d’opérations 256 bits, ce qui exige soit une grande surcharge, soit une structure interne personnalisée dans le système de preuve. Ce n’est pas un problème pour le sans état en soi, mais cela ajoute de la difficulté.

Pour obtenir la mise à jour des témoins Verkle de façon quantique-sûre et raisonnablement efficace, une autre voie possible est l’arbre Merkle basé sur les réseaux (lattice-based).

Si, dans le pire des cas, le système de preuve n’est pas assez efficace, on peut utiliser l’outil inattendu du gas multidimensionnel : fixer des limites séparées pour (i) calldata ; (ii) calcul ; (iii) accès à l’état et d’autres ressources. Le gas multidimensionnel augmente la complexité, mais il limite plus strictement le ratio entre le cas moyen et le pire des cas. Avec le gas multidimensionnel, le nombre maximal de branches à prouver pourrait passer de 12500 à, par exemple, 3000. Cela rendrait BLAKE3 (à peine) suffisant même aujourd’hui.

Le gas multidimensionnel permet de rapprocher les limites de ressources des blocs des limites matérielles sous-jacentes

Un autre outil inattendu est de retarder le calcul de la racine d’état après le slot du bloc. On dispose alors de 12 secondes pour calculer la racine d’état, ce qui signifie que même dans le pire des cas, 60000 hachages par seconde suffisent, ce qui rend BLAKE3 à peine suffisant.

L’inconvénient est d’augmenter la latence des clients légers d’un slot, mais il existe des techniques plus subtiles pour réduire ce délai à la seule latence de génération de preuve. Par exemple, la preuve peut être diffusée sur le réseau dès qu’elle est générée par un nœud, sans attendre le bloc suivant.

Comment cela interagit-il avec le reste de la feuille de route ?

Résoudre le problème du sans état augmente considérablement la difficulté du staking solo. Si des techniques permettent d’abaisser le solde minimum pour le staking solo, comme Orbit SSF ou des stratégies de niveau application comme le staking en escouade, cela devient plus faisable.

Si l’EOF est introduit en même temps, l’analyse du gas multidimensionnel devient plus facile. Car la principale complexité d’exécution du gas multidimensionnel vient du traitement des sous-appels qui ne transmettent pas tout le gas du parent, alors qu’avec EOF, il suffit de rendre ces sous-appels illégaux, ce qui simplifie le problème (et l’abstraction de compte native offrira une alternative protocolaire pour les usages actuels du gas partiel).

Il existe aussi une synergie importante entre la validation sans état et l’expiration de l’historique. Aujourd’hui, les clients doivent stocker près de 1 To de données historiques, soit plusieurs fois la taille des données d’état. Même si le client est sans état, à moins de pouvoir le décharger du stockage de l’historique, le rêve d’un client quasi sans stockage restera hors de portée. La première étape est l’EIP-4444, qui implique de stocker l’historique sur des torrents ou le Portal Network.

Preuve de validité de l’exécution EVM

Quel problème voulons-nous résoudre ?

L’objectif à long terme de la validation des blocs Ethereum est clair : il devrait être possible de valider un bloc Ethereum en (i) téléchargeant le bloc, ou même seulement un petit échantillon de disponibilité des données du bloc ; (ii) vérifiant une petite preuve de validité du bloc. Ce serait une opération très légère, faisable sur un client mobile, un portefeuille navigateur, voire sur une autre chaîne (sans la partie disponibilité des données).

Pour y parvenir, il faut des preuves SNARK ou STARK pour (i) la couche consensus (preuve d’enjeu) et (ii) la couche d’exécution (EVM). La première est un défi en soi, à résoudre au fil des améliorations du consensus (par exemple, pour la finalité à slot unique). La seconde nécessite une preuve d’exécution EVM.

Qu’est-ce que c’est et comment cela fonctionne-t-il ?

Formellement, dans la spécification Ethereum, l’EVM est définie comme une fonction de transition d’état : on a un état initial S, un bloc B, on calcule un état final S' = STF(S, B). Si l’utilisateur utilise un client léger, il ne possède pas S et S' en entier, ni même E ; il a une racine d’état initiale R, une racine d’état finale R' et un hash de bloc H.

• Entrée publique : racine d’état initiale R, racine d’état finale R', hash de bloc H
• Entrée privée : corps du bloc B, objets de l’état accédés par le bloc Q, mêmes objets après exécution Q', preuves d’état (branches Merkle) P
• Assertion 1 : P est une preuve valide que Q contient certaines parties de l’état représenté par R
• Assertion 2 : Si on exécute STF sur Q, (i) le processus n’accède qu’aux objets de Q, (ii) le bloc est valide, (iii) le résultat est Q'
• Assertion 3 : Si on recalcule la racine d’état avec Q' et P, on obtient R'

Si cela existe, on peut avoir un client léger validant complètement l’exécution EVM d’Ethereum. Cela rend déjà les ressources du client très faibles. Pour un client totalement validant, il faut aussi faire la même chose côté consensus.

Des preuves de validité pour le calcul EVM existent déjà et sont massivement utilisées sur L2. Mais pour rendre la preuve de validité EVM faisable sur L1, il reste beaucoup à faire.

Liens avec la recherche existante ?

• EFPSE ZK-EVM (abandonné car il existe de meilleures options)
• Zeth, qui compile l’EVM dans RISC-0 ZK-VM
• Projet de vérification formelle ZK-EVM

Que reste-t-il à faire ?

Aujourd’hui, les preuves de validité des systèmes de comptabilité électronique sont insuffisantes sur deux points : sécurité et temps de vérification.

Une preuve de validité sûre doit garantir que le SNARK vérifie bien le calcul EVM, sans faille. Deux techniques principales pour améliorer la sécurité : multi-vérificateur et vérification formelle. Multi-vérificateur signifie plusieurs implémentations indépendantes de la preuve de validité, comme il existe plusieurs clients ; si un bloc est prouvé par un sous-ensemble suffisamment grand de ces implémentations, le client l’accepte. La vérification formelle consiste à utiliser des outils de preuve mathématique (Lean4, etc.) pour démontrer que la preuve de validité n’accepte que les exécutions correctes de la spécification EVM (par exemple, la sémantique K de l’EVM ou la spécification EELS écrite en python).

Un temps de vérification suffisamment rapide signifie qu’un bloc Ethereum peut être vérifié en moins de 4 secondes. Aujourd’hui, on en est loin, même si on est plus proche qu’il y a deux ans. Pour y arriver, il faut progresser sur trois axes :

• Parallélisation — le vérificateur EVM le plus rapide prouve un bloc Ethereum en 15 secondes en moyenne, en répartissant le travail sur des centaines de GPU puis en agrégeant les résultats. Théoriquement, on sait comment faire un vérificateur EVM prouvant un calcul en O(log(N)) : un GPU par étape, puis un « arbre d’agrégation » :

La difficulté est de gérer les cas extrêmes, où une transaction très grosse occupe tout le bloc, et où la division du calcul doit se faire par opcode (EVM ou RISC-V). Il faut garantir la cohérence de la « mémoire » de la VM entre les différentes parties de la preuve. Mais si on y arrive, au moins la latence du prouveur est résolue.

• Optimisation des systèmes de preuve — de nouveaux systèmes comme Orion, Binius, GRK, etc., pourraient encore réduire le temps de vérification du calcul général.
• Autres changements de coût en gas dans l’EVM — beaucoup de choses dans l’EVM peuvent être optimisées pour les prouveurs, surtout dans le pire des cas. Si un attaquant peut construire un bloc qui bloque le prouveur pendant dix minutes, prouver un bloc normal en 4 secondes ne suffit pas. Les changements nécessaires se répartissent en :
• Changements de coût en gas — si une opération est longue à prouver, même si elle est rapide à calculer, elle doit coûter cher en gas. L’EIP-7667 vise à corriger les cas les plus graves : il augmente beaucoup le coût des fonctions de hachage classiques, car leurs opcodes et précompilés sont peu chers. Pour compenser, on peut baisser le coût des opcodes EVM peu coûteux à prouver, pour garder le débit moyen constant.
• Remplacement de structures de données — outre le remplacement de l’arbre d’état par une méthode plus STARK-friendly, il faut aussi remplacer la liste des transactions, l’arbre des reçus et d’autres structures coûteuses à prouver. L’EIP d’Etan Kissling pour déplacer les transactions et reçus vers SSZ va dans ce sens.

En plus, les deux outils évoqués plus haut (gas multidimensionnel et racine d’état différée) peuvent aussi aider ici. Mais à la différence de la validation sans état, leur utilisation signifie qu’on a déjà la technologie nécessaire pour ce qu’on veut faire, alors que pour la validation complète ZK-EVM, il reste du travail — mais moins.

Un point non évoqué plus haut est le matériel du prouveur : utiliser GPU, FPGA et ASIC pour générer des preuves plus vite. Fabric Cryptography, Cysic et Accseal progressent dans ce domaine. C’est très utile pour L2, mais peu probable que ce soit décisif pour L1, car on veut que L1 reste très décentralisé, donc la génération de preuve doit rester accessible à l’utilisateur Ethereum moyen, sans dépendre d’un matériel propriétaire. L2 peut faire des compromis plus agressifs.

Dans ces domaines, il reste à faire :

• La parallélisation des preuves exige que les différentes parties du système de preuve puissent « partager la mémoire » (par exemple, via des tables de lookup). On connaît la technique, il faut l’implémenter.
• Il faut plus d’analyse pour trouver le meilleur ensemble de changements de coût en gas pour minimiser le temps de vérification dans le pire des cas.
• Il faut plus de travail sur les systèmes de preuve eux-mêmes

Les compromis possibles :

• Sécurité vs temps de vérification : choisir des fonctions de hachage plus agressives, des systèmes de preuve plus complexes ou des hypothèses de sécurité plus risquées peut réduire le temps de vérification.
• Décentralisation vs temps de vérification : la communauté doit s’accorder sur les « specs » du matériel de preuve visé. Peut-on exiger que les prouveurs soient de grands acteurs ? Veut-on qu’un ordinateur portable haut de gamme puisse prouver un bloc Ethereum en 4 secondes ? Un compromis ?
• Rupture de rétrocompatibilité : les autres insuffisances peuvent être compensées par des changements de coût en gas plus agressifs, mais cela risque d’augmenter de façon disproportionnée le coût de certaines applications, forçant les développeurs à réécrire et redéployer leur code pour rester viables. Ces deux outils ont aussi leur propre complexité et inconvénients.

Comment cela interagit-il avec le reste de la feuille de route ?

La technologie clé nécessaire à la preuve de validité EVM sur L1 est largement partagée avec deux autres domaines :

• Preuve de validité sur L2 (« ZK rollup »)
• Méthode « STARK binary hash proof » sans état

Si la preuve de validité est réussie sur L1, on pourra enfin faire du staking solo facilement : même les ordinateurs les plus faibles (y compris téléphones ou montres connectées) pourront staker. Cela renforce la valeur de lever d’autres limites au staking solo (comme le minimum de 32 ETH).

De plus, la preuve de validité EVM sur L1 peut augmenter considérablement la limite de gas sur L1.

Preuve de validité du consensus

Quel problème voulons-nous résoudre ?

Si on veut valider complètement un bloc Ethereum avec un SNARK, l’exécution EVM n’est pas la seule partie à prouver. Il faut aussi prouver le consensus, c’est-à-dire la partie du système qui gère les dépôts, retraits, signatures, mises à jour de soldes des validateurs et autres éléments du proof-of-stake d’Ethereum.

Le consensus est bien plus simple que l’EVM, mais il pose le défi de ne pas avoir de convolution EVM L2, donc la plupart du travail reste à faire. Toute implémentation de preuve du consensus Ethereum doit donc partir de zéro, même si le système de preuve lui-même peut être partagé.

Qu’est-ce que c’est et comment cela fonctionne-t-il ?

La Beacon Chain est définie comme une fonction de transition d’état, comme l’EVM. Elle se compose principalement de trois parties :

• ECADD (pour vérifier les signatures BLS)
• Pairing (pour vérifier les signatures BLS)
• Hachage SHA256 (pour lire et mettre à jour l’état)

À chaque bloc, il faut prouver 1 à 16 ECADD BLS12-381 par validateur (parfois plus, si une signature est dans plusieurs ensembles). On peut compenser cela par des techniques de pré-calcul de sous-ensembles, donc on peut dire qu’il faut prouver un ECADD BLS12-381 par validateur. Actuellement, il y a 30000 signatures de validateurs par slot. À l’avenir, avec la finalité à slot unique, cela pourrait changer : en mode « force brute », on pourrait avoir 1 million de validateurs par slot. Avec Orbit SSF, le nombre resterait à 32768, voire 8192.

Comment fonctionne l’agrégation BLS : la vérification de la signature totale ne nécessite qu’un ECADD par participant, pas un ECMUL. Mais 30000 ECADD restent beaucoup à prouver.

Côté pairing, il y a actuellement jusqu’à 128 preuves par slot, donc 128 pairings à vérifier. Avec l’ElP-7549 et d’autres modifications, cela peut descendre à 16 par slot. Les pairings sont peu nombreux mais très coûteux : chaque pairing prend des milliers de fois plus de temps qu’un ECADD.

Un défi majeur pour prouver les opérations BLS12-381 est qu’il n’existe pas de courbe commode dont l’ordre soit égal à la taille du champ BLS12-381, ce qui ajoute beaucoup de surcharge à tout système de preuve. En revanche, l’arbre Verkle proposé pour Ethereum est construit sur la courbe Bandersnatch, ce qui fait que BLS12-381 est la courbe native pour prouver les branches Verkle dans un système SNARK. Une implémentation simple peut prouver 100 additions G1 par seconde ; pour aller plus vite, il faudra sûrement des techniques comme GKR.

Pour le hachage SHA256, le pire des cas est le bloc de transition d’époque, où tout l’arbre des soldes courts des validateurs et de nombreux soldes sont mis à jour. Chaque arbre court ne fait qu’un octet, donc 1 Mo de données à re-hasher. Cela fait 32768 appels SHA256. Si 1000 validateurs changent de seuil, il faut mettre à jour leur solde effectif, soit 1000 branches Merkle, donc 10000 hachages. Le mécanisme de shuffling nécessite 90 bits par validateur (soit 11 Mo de données), mais cela peut être calculé à tout moment dans l’époque. Avec la finalité à slot unique, ces chiffres peuvent varier. Le shuffling devient inutile, mais Orbit pourrait le réintroduire partiellement.

Un autre défi est de devoir relire tout l’état des validateurs, y compris les clés publiques, pour vérifier un bloc. Pour 1 million de validateurs, lire les clés publiques prend 48 Mo, plus les branches Merkle. Cela fait des millions de hachages par époque. Pour prouver la validité du PoS, une solution réaliste est une forme de calcul incrémental vérifiable : stocker dans le système de preuve une structure de données séparée, optimisée pour la recherche efficace et la preuve de mise à jour.

En résumé, les défis sont nombreux. Pour les relever efficacement, il faudra probablement une refonte profonde de la Beacon Chain, qui pourrait coïncider avec la transition vers la finalité à slot unique. Cette refonte pourrait inclure :

• Changement de fonction de hachage : on utilise actuellement SHA256 « complet », donc chaque appel implique deux appels à la fonction de compression à cause du padding. Passer à la fonction de compression SHA256 donnerait au moins un gain de 2x. Passer à Poseidon donnerait un gain de 100x, résolvant tous nos problèmes (au moins côté hachage) : à 1,7 million de hachages par seconde (54 Mo), même 1 million d’enregistrements validateurs peuvent être « lus » dans la preuve en quelques secondes.
• Avec Orbit, stocker directement les enregistrements validateurs mélangés : si on choisit un nombre fixe de validateurs (8192 ou 32768) pour un comité de slot, on les place côte à côte dans l’état, ce qui permet de lire toutes les clés publiques avec un minimum de hachages. Cela permet aussi de mettre à jour efficacement tous les soldes.
• Agrégation de signatures : tout schéma d’agrégation performant implique une preuve récursive, où différents nœuds du réseau prouvent des sous-ensembles de signatures. Cela répartit naturellement le travail de preuve sur plusieurs nœuds, réduisant beaucoup la charge du « prouveur final ».
• Autres schémas de signature : pour les signatures Lamport+Merkle, il faut 256+32 hachages pour vérifier une signature ; multiplié par 32768 signataires, cela fait 9437184 hachages. On peut améliorer ce résultat par un petit facteur constant en optimisant le schéma. Avec Poseidon, cela se prouve en un slot. Mais en pratique, une agrégation récursive sera plus rapide.

Liens avec la recherche existante ?

• Preuve concise du consensus Ethereum (pour le comité de synchronisation seulement)
• Helios dans SP1 succinct
• Précompilé BLS12-381 succinct
• Vérification d’agrégation de signatures BLS basée sur Halo2

Que reste-t-il à faire et quels compromis ?

En réalité, il nous faudra des années pour obtenir une preuve de validité du consensus d’Ethereum. Cela correspond au temps nécessaire pour la finalité à slot unique, Orbit, la modification des schémas de signature et l’analyse de sécurité, qui doit être suffisante pour utiliser des fonctions de hachage « agressives » comme Poseidon. Il est donc judicieux de résoudre ces autres problèmes, tout en gardant la compatibilité STARK à l’esprit.

Le principal compromis sera probablement dans l’ordre des opérations, entre une approche progressive de la réforme du consensus Ethereum et une approche plus radicale de « tout changer d’un coup ». Pour l’EVM, la méthode progressive est raisonnable car elle minimise la perturbation de la rétrocompatibilité. Pour le consensus, l’impact sur la rétrocompatibilité est moindre, et il peut être bénéfique de repenser plus globalement les détails de la Beacon Chain pour optimiser la compatibilité SNARK.

Comment cela interagit-il avec le reste de la feuille de route ?

Lors de la refonte à long terme du PoS Ethereum, la compatibilité STARK doit être une priorité, en particulier pour la finalité à slot unique, Orbit, les changements de schéma de signature et l’agrégation de signatures.