Titre original: "Possibles futurs du protocole Ethereum, partie 4: The Verge"

Auteur original: Vitalik Buterin

Traduction originale : Mensh, ChainCatcher

Un grand merci à Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams et Uma Roy pour leurs commentaires et leurs révisions.

L'un des plus grands avantages de Bloc est que n'importe qui peut exécuter un Nœud sur son propre ordinateur et vérifier la validité de la chaîne Bloc. Même si les 9596 Nœuds exécutant le consensus de la chaîne (PoW, PoS) acceptent immédiatement de modifier les règles et commencent à produire des Blocs selon les nouvelles règles, chaque personne exécutant un Nœud de validation complète refusera de reconnaître cette chaîne. Les mineurs qui ne font pas partie de ce groupe de conspirateurs se regrouperont automatiquement sur une chaîne hors-chaîne qui suit toujours les anciennes règles et continueront à construire cette chaîne, tandis que les utilisateurs qui passent la validation complète suivront cette chaîne.

Ceci est la différence clé entre la blockchain et les systèmes centralisés. Cependant, pour que cette caractéristique soit vérifiable, il est effectivement possible de faire fonctionner un nœud entièrement validé pour un nombre suffisant de personnes. Cela s'applique aussi bien aux initiateurs (car s'ils ne valident pas la chaîne, ils ne contribuent pas à l'exécution des règles du protocole) qu'aux utilisateurs ordinaires. Aujourd'hui, il est possible de faire fonctionner un nœud sur des ordinateurs portables grand public (y compris celui utilisé pour écrire cet article), mais c'est difficile à réaliser. The Verge vise à changer cette situation en rendant le coût de calcul d'une chaîne entièrement validée abordable, de sorte que chaque portefeuille de téléphone, de navigateur ou même de montre intelligente effectue une validation par défaut.

La feuille de route de The Verge 2023

Au départ, "Verge" faisait référence au transfert de l'état d'ETH sur Verkle Tree - une structure arborescente permettant une preuve plus compacte, permettant la validation sans état des blocs ETH, sans avoir besoin de stocker l'état d'ETH (solde du compte, code de contrat, espace de stockage, etc.) sur son disque. Un Nœud peut valider un bloc ETH sans avoir besoin de stocker l'état d'ETH (solde du compte, code de contrat, espace de stockage, etc.), moyennant des données de preuve de quelques centaines de Ko et un temps supplémentaire de quelques centaines de millisecondes pour valider une preuve. Aujourd'hui, Verge représente une vision plus vaste, axée sur une validation maximale des ressources de la chaîne ETH, comprenant non seulement la technologie de validation sans état, mais aussi la vérification de toutes les exécutions ETH à l'aide de SNARK.

En plus de suivre à long terme toute la chaîne de vérification SNARK, un autre nouveau problème concerne la question de savoir si l'arbre Verkle est la meilleure technologie. L'arbre Verkle est facilement attaqué par un ordinateur quantique, donc si nous remplaçons l'arbre Verkle dans l'arbre actuel de Merkle Patricia KECCAK, nous devrons le remplacer à nouveau à l'avenir. La méthode d'auto-remplacement de l'arbre Merkle consiste à sauter directement l'utilisation de branches Merkle avec STARK et à les placer dans un arbre binaire. Historiquement, en raison des coûts et de la complexité technique, cette méthode a toujours été considérée comme irréalisable. Cependant, récemment, nous avons vu Starkware prouver 1,7 million de hachages Poseidon par seconde avec les STARKs ckcles sur un ordinateur portable, et avec l'apparition de technologies telles que GKB, le temps de prouver davantage de hachages "traditionnels" se raccourcit rapidement. Par conséquent, au cours de la dernière année, "Verge" est devenu plus ouvert, avec plusieurs possibilités.

The Verge: Objectif clé

• Client sans état: L'espace de stockage requis pour un client entièrement vérifié et étiqueté Nœud ne doit pas dépasser quelques gigaoctets.
• (Long-term) valider complètement la chaîne (Consensus et exécution) sur la montre intelligente. Télécharger des données, vérifier SNARK, terminé.

Dans ce chapitre

• Client sans état : Verkle ou ARKS
• preuve de validité exécutée par EVM
• preuve de validité de Consensus

Vérification d'état sans confiance : Verkle ou STARKs

Quel problème cherchons-nous à résoudre ?

Aujourd'hui, le client Ethereum nécessite le stockage de centaines de gigaoctets de données d'état pour vérifier les Blocs, et cette quantité augmente chaque année. Les données d'état brutes augmentent d'environ 30 Go chaque année, et chaque client doit stocker des données supplémentaires dessus pour mettre à jour efficacement les triplets.

Cela réduit le nombre d'utilisateurs capables d'exécuter un Nœud Ethereum complet : bien que les disques durs suffisent pour stocker tous les états d'Ethereum ainsi que plusieurs années d'historique, les ordinateurs achetés par défaut n'ont souvent que quelques centaines de gigaoctets d'espace de stockage. La taille de l'état pose également de gros problèmes lors de la première création du Nœud : le Nœud doit télécharger l'intégralité de l'état, ce qui peut prendre des heures, voire des jours. Cela entraîne divers effets en chaîne. Par exemple, cela rend beaucoup plus difficile pour les créateurs de Nœuds de mettre à jour leurs paramètres. Techniquement, la mise à jour peut être effectuée sans interruption - en lançant un nouveau client, en attendant qu'il se synchronise, puis en fermant l'ancien client et en transférant la Clé secrète, mais en pratique, cela est très compliqué.

Comment ça marche ?

La validation sans état est une technologie qui permet aux nœuds de vérifier les blocs sans avoir connaissance de l'intégralité de l'état. Au lieu de cela, chaque bloc est accompagné d'un témoin comprenant : (i) la valeur, le code, le solde, le stockage à des emplacements spécifiques de l'état que le bloc accédera ; (ii) la preuve de chiffrement de ces valeurs correctes.

En fait, la réalisation de la vérification sans état nécessite un changement de la structure de l'arbre d'état d'Ethereum. Cela est dû au fait que l'arbre de Merkle Patricia actuel est extrêmement hostile à la mise en œuvre de tout schéma de preuve de chiffrement, en particulier dans le pire des cas. Que ce soit les branches "brutes" de Merkle ou les possibilités "enveloppées" en STARK, c'est le cas. La principale difficulté vient de quelques faiblesses de MPT :

1. C'est un arbre à six branches (c'est-à-dire que chaque Nœud a 16 sous-Nœuds). Cela signifie que dans un arbre de taille N, une preuve nécessite en moyenne 32 * (16-1) * log 16 (N) = 120 * log 2 (N) octets, ou environ 3840 octets dans un arbre de 2 ^ 32 éléments. Pour un arbre binaire, seulement 32 * (2-1) * log 2 (N) = 32 * log 2 (N) octets sont nécessaires, soit environ 1024 octets.

2. Le code n'a pas été merkle-isé. Cela signifie que pour prouver l'accès au compte, il est nécessaire de fournir l'intégralité du code, jusqu'à un maximum de 24000 octets.

Nous pouvons calculer le pire des cas comme suit :

30000000 gas / 2400 (coût de lecture à froid du compte) * （5 * 488 + 24000) = 330000000 octets

Le coût des branches est légèrement Goutte（remplacé 5* 480 par 8* 480）, car lorsque les branches sont nombreuses, leur partie supérieure se répète. Cependant, même dans un intervalle de temps, la quantité de données à télécharger est totalement irréaliste. Si nous essayons de l'encapsuler avec STARK, nous rencontrerons deux problèmes : (i) KECCAK n'est pas très convivial pour STARK ; (ii) 330 Mo de données signifient que nous devons prouver 5 millions d'appels à la fonction de tour KECCAK, ce qui pourrait ne pas être prouvé pour tous les matériels sauf les plus puissants grand public, même si nous pouvons augmenter l'efficacité de STARK pour prouver KECCAK.

Si nous remplaçons directement l'arbre binaire par un arbre hexadécimal et que nous appliquons un traitement Merkle supplémentaire au code, le pire des cas deviendrait à peu près 30000000/2400* 32*( 32-14+ 8) = 10400000 octets (14 est la soustraction des bits redondants pour 2 ^ 14 branches, et 8 est la longueur de la preuve des feuilles dans le bloc de code). Il est important de noter que cela nécessite de modifier le coût du gas, en facturant l'accès à chaque bloc de code individuellement ; c'est ce que fait l'EIP-4762. Une capacité de 10,4 Mo serait bien meilleure, mais pour de nombreux Nœud, le volume de données téléchargé dans un créneau temporel est toujours trop important. Par conséquent, nous devons introduire des technologies plus avancées. À cet égard, il existe deux solutions de pointe : l'arbre Verkle et l'arbre de hachage binaire STARKed.

Arbre Verkle

Verkle utilise des engagements de vecteurs basés sur des courbes elliptiques pour des preuves plus courtes. La clé de déverrouillage est que, quelle que soit la largeur de l'arbre, chaque partie de preuve correspondant à la relation parent-enfant ne fait que 32 octets. La seule limitation de la largeur de l'arbre de preuve est que si l'arbre de preuve est trop large, l'efficacité de calcul de la preuve chutera. La proposition de mise en œuvre pour Ethereum a une largeur de 256.

Par conséquent, la taille de chaque branche dans la preuve devient 32 - 1 og 256(N) = 4* log 2(N) bytes. Par conséquent, la taille maximale théorique de la preuve est d'environ 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 bytes (en raison de la distribution inégale des blocs d'état, les résultats réels de calcul peuvent légèrement différer, mais cela reste une première approximation acceptable).

De plus, il convient de noter que dans tous les exemples ci-dessus, ce "pire des cas" n'est pas vraiment le pire des cas : le pire des cas serait que l'attaquant "mine" délibérément deux adresses, leur donnant une préfixe commun plus long dans l'arbre, et lit les données à partir de l'une des adresses, ce qui pourrait prolonger la longueur de la branche dans le pire des cas de deux fois. Cependant, même dans ce cas, la longueur de preuve pire des arbres Verkle serait de 2,6 Mo, ce qui est à peu près équivalent aux données de vérification actuelles dans le pire des cas.

Nous avons également fait une autre chose en utilisant cette note : nous avons rendu le coût d'accès à l'espace de stockage 'voisin' très bas : soit de nombreux blocs de code du même contrat, soit des emplacements de stockage adjacents. L'EIP-4762 fournit une définition d'adjacence et facture seulement 200 gas pour un accès adjacent. Dans le cas d'un accès adjacent, la taille de la preuve dans le pire des cas devient de 30000000 / 200 * 32 - 4800800 octets, ce qui reste approximativement dans la plage de tolérance. Si, par précaution, nous souhaitons réduire cette valeur, nous pouvons légèrement augmenter le coût de l'accès adjacent.

STARKed Arbre de hachage binaire

Le principe de cette technologie est évident : il vous suffit de construire un arbre binaire, d'obtenir une preuve de 10,4 Mo maximum, de prouver la valeur dans le bloc, puis de remplacer la preuve par un STARK. Ainsi, la preuve ne contient que les données à prouver, plus des frais fixes de 100 à 300 ko provenant du STARK réel.

Le principal défi ici est le temps de validation. Nous pouvons faire essentiellement les mêmes calculs que ci-dessus, sauf qu’au lieu du nombre d’octets, nous calculons la valeur de hachage. Un bloc de 10,4 Mo signifie 330 000 hachages. Ajoutez à cela la possibilité qu’un attaquant « mine » l’arborescence d’adresses avec un long préfixe public, alors le hachage le plus défavorable serait d’environ 660 000 hachages. Donc, si nous pouvons prouver que le hachage par seconde est de 200 000, alors c’est bien.

Sur les ordinateurs portables grand public utilisant la fonction de hachage Poseidon, ces chiffres ont déjà été atteints, et la fonction de hachage Poseidon a été spécialement conçue pour la convivialité de STARK. Cependant, le système Poseidon est encore relativement immature et de nombreuses personnes ne lui font pas confiance en termes de sécurité. Par conséquent, il existe deux voies réalistes pour avancer :

1. Effectuez rapidement une analyse de sécurité approfondie de Poseidon et familiarisez-vous suffisamment avec elle pour pouvoir la déployer à L1.
2. Utiliser des fonctions de hachage plus "conservatrices", telles que SHA 256 ou BLAKE

Pour prouver une fonction de hachage conservatrice, le cercle STARK de Starkware ne peut actuellement prouver que 10 à 30k valeurs de hachage par seconde sur un ordinateur portable grand public au moment de la rédaction de cet article. Cependant, la technologie STARK est en constante amélioration. Même aujourd'hui, la technologie basée sur GKR montre qu'elle peut augmenter cette vitesse à une plage de 100 à 200k.

Cas d'utilisation de la preuve en dehors de la validation des blocs

En plus de la validation des blocs, il existe trois autres cas d'utilisation clés qui nécessitent une validation sans état plus efficace :

• Pool de mémoire : Lorsqu'une transaction est diffusée, les nœuds dans le réseau P2P doivent vérifier si la transaction est valide avant de la diffuser à nouveau. Aujourd'hui, cette vérification comprend la vérification de la signature, ainsi que la vérification de la disponibilité des fonds et de la syntaxe correcte. À l'avenir (par exemple, en utilisant l'abstraction de compte native, telle que EIP-7701), cela pourrait impliquer l'exécution de code EVM pour accéder à l'état. Si un nœud est sans état, la transaction doit être accompagnée d'une preuve de l'état de l'objet.
• Contient une liste: Il s'agit d'une fonction proposée qui permet aux attestation (peut-être de petite échelle et non complexe) de forcer le prochain Bloc à contenir des transactions, indépendamment de la volonté des Bloc constructeurs (peut-être à grande échelle et complexe). Cela affaiblirait la capacité des puissants à manipuler la chaîne de Bloc en retardant les transactions. Cependant, cela nécessite que les validateurs aient un moyen de vérifier la validité des transactions contenues dans la liste.
• light client：Si nous voulons que les utilisateurs accèdent à la chaîne via un portefeuille (comme Metamask, Rainbow, Rabby, etc.), ils doivent exécuter un client léger (comme Helios). Le module principal d'Helios fournit aux utilisateurs une racine d'état vérifiée. Pour une expérience entièrement sans confiance, les utilisateurs doivent prouver chaque appel RPC qu'ils font (par exemple, pour les demandes d'appel réseau ETH, les utilisateurs doivent prouver l'accès à tous les états visités lors de l'appel).

Tous ces cas d'utilisation ont un point commun : ils nécessitent tous beaucoup de preuves, mais chaque preuve est très petite. Par conséquent, la preuve STARK n'a pas de sens pour eux ; au contraire, la méthode la plus réaliste est d'utiliser directement les branches Merkle. Un autre avantage des branches Merkle est leur capacité à être mises à jour : avec une preuve d'un état X ayant pour racine le bloc B, si l'on reçoit un sous-bloc B2 et sa preuve, la preuve peut être mise à jour pour avoir pour racine le bloc B2. Les preuves Verkle sont également intrinsèquement mises à jour.

Quels sont les liens avec les recherches existantes :

• Arbres Verkle
• Document original de John Kuszmaul sur l'arbre Verkle
• Starkware
• Poseidon 2 papier
• Ajtai (fonction de hachage alternative rapide basée sur la dureté de la grille)
• Verkle.info

Que puis-je faire d'autre ?

Le travail principal restant est 01928374656574839201

1. Plus d'analyses sur les conséquences de l'EIP-4762 (variation des coûts de gaz sans état)

2. Complétez et testez davantage le travail de transition, qui est la partie principale de la complexité de tout plan de mise en œuvre sans nationalité.

3. Une analyse de sécurité plus approfondie des fonctions de hachage Poseidon, Ajtai et autres "STARK-friendly"

4. Pour développer davantage la fonctionnalité STARK ultra-efficace pour le "conservateur" (ou "traditionnel") hash, par exemple, sur la base des points de vue de Binius ou GKR.

De plus, nous allons bientôt décider de choisir l'une des trois options suivantes : (i) les arbres Verkle, (ii) les fonctions de hachage compatibles avec STARK et (iii) les fonctions de hachage conservatrices. Leurs caractéristiques peuvent être résumées dans le tableau ci-dessous :

En plus de ces "numéros de titre", il y a d'autres facteurs importants à prendre en compte :

• Aujourd'hui, le code de l'arbre Verkle est déjà assez mature. En dehors de Verkle, l'utilisation de tout autre code retarderait le déploiement, retardant probablement un fork. Ce n'est pas grave, en particulier si nous avons besoin de temps supplémentaire pour analyser les fonctions de hachage ou mettre en œuvre des validateurs, ou si nous avons d'autres fonctionnalités importantes que nous voulons intégrer plus tôt dans Ethereum.
• Mettre à jour la racine de l'état avec la valeur de hachage est plus rapide que d'utiliser un arbre Verkle. Cela signifie que les méthodes basées sur la valeur de hachage peuvent réduire le temps de synchronisation de tous les nœuds complets.
• L'arbre Verkle a des propriétés de mise à jour de témoin intéressantes - le témoin de l'arbre Verkle est renouvelable. Cette propriété est utile pour le mempool, les listes incluses et d'autres cas d'utilisation, et peut également aider à améliorer l'efficacité de la mise en œuvre : si un objet d'état est mis à jour, le témoin de l'avant-dernière couche peut être mis à jour sans avoir à lire le contenu de la dernière couche.
• Verkle arbres plus difficile à réaliser SNARK preuves. Si nous voulons réduire la taille de la preuve à quelques milliers d'octets, les preuves Verkle poseront quelques difficultés. Cela est dû au fait que la vérification des preuves Verkle introduit de nombreuses opérations de 256 bits, ce qui nécessite soit un système de preuve avec des frais élevés, soit une structure interne personnalisée contenant une partie de preuve Verkle de 256 bits. Cela ne pose pas de problème en soi pour l'état sans état, mais cela apporte plus de difficultés.

Si nous voulons obtenir la vérifiabilité renouvelable Verkle de manière sécurisée quantiquement et efficace, une autre approche possible est l'arbre de Merkle basé sur le treillis.

Si dans le pire des cas, il est démontré que l'efficacité du système n'est pas suffisante, nous pouvons encore utiliser l'outil inattendu du gaz multidimensionnel pour compenser cette lacune : en définissant des limites de gaz distinctes pour (i) les données d'appel ; (ii) les calculs ; (iii) l'accès à l'état et d'autres ressources potentiellement différentes. Le gaz multidimensionnel ajoute de la complexité, mais en échange, il limite plus strictement le rapport entre les cas moyens et les pires cas. Avec le gaz multidimensionnel, le nombre maximal de branches à prouver théoriquement pourrait passer de 12500 à 3000 par exemple. Cela permettrait à BLAKE 3 de (à peine) suffire même aujourd'hui.

Le gas multidimensionnel permet des restrictions de ressources plus proches des restrictions de ressources matérielles sous-jacentes pour le Bloc

Un autre outil inattendu est de calculer la latence de la racine d'état jusqu'au Bloc après l'intervalle de temps. De cette façon, nous avons exactement 12 secondes pour calculer la racine d'état, ce qui signifie que même dans les cas extrêmes, le temps de preuve de travail de 60000 hachages par seconde est suffisant, ce qui nous fait penser encore une fois que BLAKE 3 ne répondra qu'à peine aux exigences.

Les inconvénients de cette méthode incluent l'ajout d'une latence du client léger, mais il existe des techniques plus astucieuses pour réduire cette latence à la seule latence de génération de preuve. Par exemple, la preuve peut être diffusée immédiatement sur le réseau après sa génération par n'importe quel nœud, au lieu d'attendre le prochain bloc.

Comment interagit-il avec les autres parties de la feuille de route ?

Résoudre le problème de l'état sans augmenter considérablement la difficulté du point unique. Si une technologie peut abaisser l'équilibre minimal du point unique, comme Orbit SSF ou des stratégies de la couche d'application, comme des points d'équipe, cela deviendra plus réalisable.

Si l'EOF est introduit en même temps, l'analyse multidimensionnelle du gas deviendra plus facile. Cela est dû au fait que la complexité d'exécution principale du gas multidimensionnel provient principalement du traitement des appels enfants qui ne transmettent pas tout le gas de l'appel parent, tandis que l'EOF n'a besoin que de déclarer ces appels enfants comme illégaux pour rendre ce problème négligeable (et fournir une alternative interne à l'utilisation principale actuelle de gas pour certains comptes natifs).

Il existe 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, ce qui représente plusieurs fois les données d'état. Même si le client est sans état, à moins que nous ne puissions libérer le client de la responsabilité de stocker les données historiques, le rêve d'un client sans stockage sera presque impossible à réaliser. La première étape consiste à utiliser EIP-4444, ce qui signifie également stocker les données historiques dans les torrents ou sur le réseau Portal.

preuve de validité exécutée par l'EVM

Quel problème cherchons-nous à résoudre ?

Le but à long terme de la validation de Bloc sur Éther est très clair - vous devriez être en mesure de valider Bloc sur Éther de la manière suivante : (i) télécharger Bloc, ou même simplement une petite partie des données de validation de Bloc disponibles ; (ii) valider une petite preuve de travail valide de Bloc. Cela nécessitera une utilisation de ressources très faible, pouvant être effectuée sur un client mobile, dans un navigateur Portefeuille, voire sur une autre chaîne (sans la partie des données de validation).

Pour ce faire, il est nécessaire de prouver SNARK ou STARK pour (i) la couche de consensus (c'est-à-dire la preuve de participation) et (ii) la couche d'exécution (c'est-à-dire EVM). Le premier est en soi un défi qui devrait être résolu dans le processus continu d'amélioration de la couche de consensus (par exemple, pour terminer les fentes uniques). Le second nécessite une preuve d'exécution EVM.

Qu'est-ce que c'est, comment ça marche ?

Du point de vue formel, dans la spécification de l'Ethereum, l'EVM est défini comme une fonction de transition d'état : vous avez un état antérieur S, un Bloc B, et vous calculez un état postérieur S' = STF(S, B). Si l'utilisateur utilise un light client, il ne possède pas complètement S et S', voire même E ; au contraire, il possède un état racine antérieur R, un état racine postérieur R' et une valeur de hachage de Bloc H.

• Entrée publique : racine de l'état précédent R, racine de l'état suivant R', hash du bloc H
• Entrée privée : objets dans l'état accédé par le bloc principal B, le bloc de programme Q, les mêmes objets après l'exécution du bloc de programme Q', preuve d'état (comme la branche Merkle) P
• Proposition 1: P est une preuve valide, démontrant que Q contient certaines parties de l'état représenté par R
• Proposition 2: Si STF est exécuté sur Q, (i) le processus d'exécution n'accède qu'aux objets internes de Q, (ii) les blocs de données sont valides, (iii) le résultat est Q'
• Proposition 3: Si les informations de Q' et P sont utilisées pour recalculer la nouvelle racine d'état, on obtient R'.

Si cette situation se produit, un client léger qui exécute complètement l'EVM d'Éther peut être possédé. Cela rend les ressources du client assez faibles. Pour réaliser un véritable client Ethereum entièrement vérifié, un travail similaire doit également être effectué en matière de consensus.

L'implémentation de la preuve de validité pour le calcul EVM existe déjà et est largement utilisée en L2. Cependant, il reste beaucoup de travail à faire pour rendre la preuve de validité EVM réalisable en L1.

Quels sont les liens avec les recherches existantes ?

• EFPSE ZK-EVM (désactivé car il existe de meilleures options)
• Zeth, son fonctionnement consiste à compiler l'EVM dans le RISC-0 ZK-VM
• Projet de Vérification formelle ZK-EVM

Que puis-je faire d'autre ?

如今，电子记账系统的preuve de validité在两个方面存在不足：安全性和验证时间。

Une preuve de validité sécurisée nécessite de garantir que SNARK vérifie effectivement le calcul de l'EVM et qu'il n'y a pas de vulnérabilités. Les deux principales techniques pour améliorer la sécurité sont les multiples validateurs et la vérification formelle. Les multiples validateurs font référence à plusieurs implémentations indépendantes de preuves de validité, tout comme il existe plusieurs clients. Si un bloc est prouvé par un sous-ensemble suffisamment grand de ces implémentations, le client acceptera ce bloc. La vérification formelle implique l'utilisation d'outils couramment utilisés pour prouver des théorèmes mathématiques, tels que Lean 4, pour prouver que la preuve de validité n'accepte que l'exécution correcte de la spécification sous-jacente de l'EVM (par exemple, la sémantique EVM K ou la spécification de la couche d'exécution ETH écrite en python (EELS)).

Un temps de vérification suffisamment rapide signifie que tous les blocs de la chaîne ETH peuvent être vérifiés en moins de 4 secondes. Aujourd'hui, nous sommes encore loin de cet objectif, même si nous en sommes beaucoup plus proches qu'il y a deux ans. Pour atteindre cet objectif, nous devons progresser dans trois directions :

• La parallélisation - Les validateurs EVM les plus rapides actuels peuvent en moyenne prouver un bloc Ethereum en 15 secondes. Cela est réalisé en parallélisant le travail entre des centaines de GPU, puis en agrégeant leur travail à la fin. En théorie, nous savons parfaitement comment fabriquer un validateur EVM capable de prouver les calculs en temps O(log(N)) : laissez un GPU effectuer chaque étape, puis créez un "arbre d'agrégation" :

Réaliser cela présente un défi. Même dans le pire des cas, c'est-à-dire lorsque qu'une transaction très volumineuse occupe tout le Bloc, la division des calculs ne peut pas se faire de manière itérative, mais doit se faire selon les opcodes (opcodes de la Machine virtuelle sous-jacente tels que EVM ou RISC-V). S'assurer que la "mémoire" de la Machine virtuelle reste cohérente entre les différentes parties de la preuve est un défi clé de la mise en œuvre. Cependant, si nous pouvons réaliser cette preuve récursive, alors nous savons que, même sans aucune amélioration par ailleurs, au moins le problème de latence du prouveur est résolu.

• Optimisation du système de preuve - Le nouveau système de preuve, tel que Orion, Binius, GRK et bien d'autres informations, pourrait très probablement entraîner une nouvelle réduction significative du temps de vérification des calculs généraux.
• Autres changements de coûts de gaz EVM - De nombreuses choses dans l'EVM peuvent être optimisées pour être plus favorables aux validateurs, en particulier dans les pires cas. S'il est possible pour un attaquant de construire un bloc qui bloque les validateurs pendant dix minutes, alors prouver un bloc ETH ordinaire en seulement 4 secondes ne suffit pas. Les modifications nécessaires à l'EVM peuvent être grossièrement classées comme suit :

• La variation des coûts de gaz - Si une opération prend beaucoup de temps à prouver, même si sa vitesse de calcul est relativement rapide, le coût du gaz devrait être très élevé. L'EIP-7667 est un EIP proposé pour résoudre ce problème majeur : il augmente considérablement le coût du gaz des fonctions de hash (traditionnelles) car les opcodes de ces fonctions et les précompilations sont relativement bon marché. Pour compenser cette augmentation des coûts de gaz, nous pouvons réduire le coût du gaz des opcodes EVM qui prouvent la goutte, maintenant ainsi le débit moyen constant.

• Remplacement de la structure des données - En plus de remplacer l'arbre d'état par une méthode plus conviviale pour STARK, nous devons également remplacer la liste des transactions, l'arbre des reçus et d'autres structures coûteuses en preuves. Le déplacement des structures des transactions et des reçus vers l'EIP SSZ par Etan Kissling est un pas dans cette direction.

En outre, les deux outils mentionnés dans la section précédente (gas multidimensionnel et latence de l'état racine) peuvent également être utiles à cet égard. Cependant, il convient de noter que contrairement à la vérification sans état, l'utilisation de ces deux outils signifie que nous avons déjà les compétences nécessaires pour accomplir le travail actuel, et même avec l'utilisation de ces compétences, une vérification ZK-EVM complète nécessiterait davantage de travail - juste moins de travail nécessaire.

Un point non mentionné dans le texte ci-dessus est le matériel de preuve : l'utilisation de GPU, FPGA et ASIC pour générer des preuves plus rapidement. Fabric Cryptography, Cysic et Accseal sont trois entreprises qui ont progressé dans ce domaine. Cela est très précieux pour la couche L2, mais il est peu probable que cela devienne un facteur décisif pour la couche L1, car il est fortement souhaité que la L1 maintienne une haute décentralisation, ce qui signifie que la génération de preuves doit se situer dans des limites raisonnables pour les utilisateurs d'ETH, et ne doit pas être limitée par les goulots d'étranglement matériels d'une seule entreprise. La couche L2 peut faire des compromis plus actifs.

Il reste encore beaucoup de travail à faire dans ces domaines:

• La preuve de parallélisation exige que les différentes parties du système de preuve puissent "partager la mémoire" (comme une table de recherche). Nous savons comment faire cela en termes de technologie, mais cela doit être mis en œuvre.
• Nous avons besoin de faire plus d'analyses pour trouver l'ensemble idéal de variations des coûts de gaz afin de réduire au maximum le temps de validation dans le pire des cas.
• Nous devons faire plus de travail dans le domaine des systèmes de preuve

Le coût possible est :

• Sécurité et temps du validateur : en choisissant une fonction de hachage plus agressive, un système de preuve plus complexe, des hypothèses de sécurité plus agressives ou d'autres schémas de conception, il est possible de réduire le temps du validateur.
• La décentralisation et le time-stamping : la communauté doit parvenir à un consensus sur les spécifications du matériel de time-stamping ciblé. Est-ce que les validateurs doivent être des entités de grande envergure ? Voulons-nous que les ordinateurs portables haut de gamme puissent time-stamper un bloc ETH en 4 secondes ? Ou quelque chose entre les deux ?
• Le degré de rupture de la compatibilité arrière : Les autres lacunes peuvent être compensées par des changements de coûts de gaz plus agressifs, mais il est plus probable que cela augmentera de manière disproportionnée les coûts de certaines applications, obligeant les développeurs à réécrire et redéployer du code pour maintenir la viabilité économique. De même, ces deux outils ont leur propre complexité et inconvénients.

Comment interagit-il avec d'autres parties de la feuille de route ?

La technologie centrale requise pour réaliser la preuve de validité L1 EVM est largement partagée avec deux autres domaines :

• preuve de validité L2 ("ZK rollup")
• Méthode de preuve de hachage binaire "STARK" sans état

Une fois que la preuve de validité est réussie sur L1, il sera facile de faire du stake en solo : même les ordinateurs les plus faibles (y compris les téléphones portables ou les montres intelligentes) peuvent faire du stake. Cela augmente encore la valeur de la résolution des autres restrictions du stake en solo (comme le minimum de 32 ETH).

De plus, la preuve de validité EVM de L1 peut considérablement améliorer la limite de gaz de L1.

Consensus的preuve de validité

Quel problème cherchons-nous à résoudre ?

Si nous voulons entièrement vérifier un bloc de chaîne ETH en utilisant SNARK, l'exécution de l'EVM n'est pas la seule partie que nous devons prouver. Nous devons également prouver le consensus, c'est-à-dire certaines parties du système qui traitent des dépôts, des retraits, des signatures, des mises à jour de solde des validateurs et d'autres éléments de la Preuve d'enjeu d'ETH.

Le consensus est beaucoup plus simple que l'EVM, mais le défi est que nous n'avons pas de convolution L2 EVM, donc la plupart du travail doit être fait de toute façon. Ainsi, toute implémentation du consensus de l'ETH nécessite de "repartir de zéro", même si le système de preuve peut être construit dessus en partageant le travail.

Qu'est-ce que c'est, comment ça marche?

La beacon chain est définie comme une fonction de transition d'état, tout comme l'EVM. La fonction de transition d'état est principalement composée de trois parties :

• ECADD (pour vérifier la signature BLS)
• Paire (utilisée pour vérifier la signature BLS)
• Valeur de hachage SHA 256 (utilisée pour lire et mettre à jour l'état)

Dans chaque Bloc, nous devons prouver 1-16 BLS 12-381 ECADD pour chaque validateur (peut-être plus d'un car les signatures peuvent être incluses dans plusieurs ensembles). Cela peut être compensé par une technique de précalcul de sous-ensembles, de sorte que nous pouvons dire que chaque validateur doit simplement prouver un BLS 12-381 ECADD. Actuellement, chaque créneau comporte 30000 signatures de validateurs. À l'avenir, avec la mise en œuvre de la finalité d'un seul créneau, cette situation pourrait évoluer dans deux directions : si nous adoptons la voie de la "force brute", le nombre de validateurs par créneau pourrait augmenter à 1 million. Pendant ce temps, si Orbit SSF est adopté, le nombre de validateurs restera à 32768, voire diminuera à 8192.

Comment fonctionne l'agrégation BLS : la vérification du nombre total de signatures ne nécessite qu'une seule ECADD par participant, au lieu d'une ECMUL. Cependant, 30000 ECADD reste une quantité de preuves considérable.

En ce qui concerne les paires, chaque fente peut actuellement contenir jusqu'à 128 preuves, ce qui signifie qu'il faut vérifier 128 paires. Grâce à ElP-7549 et à des modifications supplémentaires, le nombre de preuves par fente peut être réduit à 16. Il y a peu de paires, mais le coût est extrêmement élevé : le temps d'exécution (ou la preuve) de chaque paire est plusieurs k fois plus long que ECADD.

Un des principaux défis de la preuve de calcul BLS 12-381 est l'absence d'une courbe pratique dont l'ordre correspond à la taille du champ BLS 12-381, ce qui ajoute une charge considérable à tout système de preuve. En revanche, l'arbre Verkle proposé pour Ethereum utilise la courbe Bandersnatch, ce qui fait que BLS 12-381 est lui-même une sous-courbe utilisée pour prouver les branches Verkle dans les systèmes SNARK. Une implémentation relativement simple permet de prouver 100G1 additions par seconde ; pour obtenir une vitesse de preuve suffisamment rapide, des techniques sophistiquées comme GKR sont très probablement nécessaires.

Pour la valeur de hachage SHA 256, le pire scénario actuel est la transition d'époque, où tout l'arbre d'équilibrage court des validateurs et une grande quantité d'équilibrage des validateurs seront mises à jour. Chaque arbre d'équilibrage court des validateurs n'a qu'un seul octet, donc 1 Mo de données seront rehashées. Cela équivaut à 32768 appels SHA 256. Si les soldes de mille validateurs sont supérieurs ou inférieurs à un seuil, les soldes valides doivent être mis à jour dans les enregistrements des validateurs, ce qui équivaut à mille branches de Merkle, donc il peut être nécessaire de hacher dix mille fois. Le mécanisme de mélange nécessite 90 bits pour chaque validateur (donc 11 Mo de données), mais cela peut être calculé à tout moment d'une époque. Dans le cas d'une terminaison de slot unique, ces chiffres peuvent varier en fonction des circonstances spécifiques. Le mélange devient superflu, bien qu'Orbit puisse partiellement rétablir ce besoin.

Un autre défi est de reconstituer l'état de tous les validateurs, y compris la Clé publique, pour valider un Bloc. Pour 1 million de validateurs, la seule lecture de la Clé publique nécessiterait 48 millions d'octets, plus les branches de Merkle. Cela nécessiterait des millions de hachages à chaque époque. Si nous devons prouver la validité de la preuve d'enjeu, une méthode réaliste est une forme de calcul vérifiable incrémental : stocker une structure de données distincte à l'intérieur du système de preuve, optimisée pour une recherche efficace et prouvant les mises à jour de cette structure.

En fin de compte, il y a beaucoup de défis. Pour faire face de la manière la plus efficace à ces défis, il est probablement nécessaire de procéder à une refonte approfondie de la beacon chain, peut-être en même temps que le passage à une finition de tranche unique. Cette refonte pourrait inclure des caractéristiques telles que :

• Changement de la fonction de hashage : maintenant, nous utilisons la fonction de hachage SHA 256 "complète ", donc, en raison du rembourrage, chaque appel doit correspondre à deux appels de fonction de compression sous-jacente. Si nous utilisons la fonction de compression SHA 256, nous pouvons au moins obtenir un gain de 2 fois. Si nous utilisons Poseidon, nous pourrions obtenir un gain de 100 fois, résolvant ainsi complètement tous nos problèmes (du moins en ce qui concerne la valeur de hachage) : à 1,7 million de valeurs de hachage par seconde (54 Mo), même un million de vérifications peut être "lu "dans la preuve en quelques secondes.
• Si c'est Orbit, enregistrez directement les enregistrements de validateurs mélangés : si vous sélectionnez un certain nombre de validateurs (par exemple, 8192 ou 32768) en tant que comité pour une fente donnée, placez-les directement dans l'état à côté de l'autre, de sorte que seul le hashs minimale soit nécessaire pour lire toutes les clés publiques des validateurs dans la preuve. Cela permet également de réaliser efficacement toutes les mises à jour d'équilibre.
• Agrégation de signatures : Tout schéma d'agrégation de signatures à haute performance impliquera une forme de preuve récursive, où différents Nœud dans le réseau feront une preuve intermédiaire pour un sous-ensemble de signatures. Cela délègue naturellement le travail de preuve à plusieurs Nœud dans le réseau, réduisant ainsi considérablement la charge de travail des "validateurs finaux".
• Autres schémas de signature : Pour la signature Lamport+ Merkle, nous avons besoin de 256 + 32 valeurs de hachage pour vérifier la signature ; multipliées par 32768 signataires, cela donne 9437184 valeurs de hachage. Une optimisation du schéma de signature peut améliorer davantage ce résultat par un petit facteur constant. Si nous utilisons Poseidon, cela peut être prouvé dans un seul slot. Cependant, en pratique, l'utilisation d'un schéma d'agrégation récursive sera plus rapide.

Quels sont les liens avec les recherches existantes ?

• Preuve de consensus Ethereum éthérée succincte (réservée au comité de synchronisation)
• Helios dans SP 1 concis
• Précompilé BLS 12-381 concis
• Vérification de la signature collective BLS basée sur Halo 2

Quels autres travaux doivent être effectués et comment faire des choix :

En réalité, il nous faudra plusieurs années pour obtenir la preuve de validité de l'ETH Consensus. Cela prendra à peu près le même temps que la réalisation de la finalité des slots uniques, Orbit, la modification de l'algorithme de signature et l'analyse de sécurité, cette dernière exigeant suffisamment de confiance pour utiliser des fonctions de hachage aussi "radicales" que Poseidon. Par conséquent, la meilleure approche est de résoudre ces autres problèmes tout en tenant compte de la convivialité de STARK.

Le principal compromis est susceptible de se situer dans l'ordre des opérations, entre une approche plus progressive de la réforme de la couche de consensus Ethereum et une approche plus radicale de "changer plusieurs fois". Pour l'EVM, une approche progressive est raisonnable car elle minimise les interférences avec la compatibilité ascendante. Pour la couche de consensus, l'impact sur la compatibilité ascendante est moindre et il est également avantageux de repenser de manière plus globale les détails de la construction de la chaîne de balises afin d'optimiser au mieux la convivialité de SNARKs.

Comment interagit-il avec les autres parties de la feuille de route ?

Lors de la refonte à long terme de la PoS d'Éther, la convivialité de STARK doit être la principale considération, en particulier l'unicité des encoches, Orbit, les changements de schéma de signature et l'agrégation de signatures.