Lecture précédente : "Vitalik sur l'avenir possible d'Éther (1) : La Fusion", "Vitalik sur l'avenir possible d'Éther (2) : La Pousée", "Vitalik sur l'avenir possible d'Éther (3) : Le Fléau"

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 puissants fonctionnalités de la Bloc est que n'importe qui peut exécuter un Nœud sur son propre ordinateur et vérifier la validité de la Bloc. Même si les 9596 Nœud 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 complet refusera d'accepter la chaîne. Les créateurs qui ne font pas partie de ce groupe de conspirateurs se rassembleront automatiquement sur une chaîne off-chain qui continue à suivre les anciennes règles et continueront à construire cette chaîne, tandis que les utilisateurs entièrement validés suivront cette chaîne.

C'est là la différence clé entre la blockchain et les systèmes centralisés. Toutefois, pour que cette caractéristique soit effective, il doit être réalisable pour un nombre suffisant de personnes d'exécuter un nœud entièrement validé. Cela s'applique tant aux acteurs majeurs (car s'ils ne valident pas la chaîne, ils ne contribuent pas à l'application des règles du protocole) qu'aux utilisateurs ordinaires. Aujourd'hui, il est possible d'exécuter 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 cherche à 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, portefeuille de navigateur voire même montre intelligente effectuera la validation par défaut.

La feuille de route de The Verge 2023

Au départ, "Verge" désignait le transfert de l'état de compte ETH sur un arbre Verkle - une structure arborescente permettant une preuve plus compacte - pour la validation sans état des blocs ETH. Un nœud peut valider un bloc ETH sans avoir à stocker l'état du compte ETH (solde du compte, code de contrat, espace de stockage, etc.) sur son disque, moyennant le coût de plusieurs centaines de Ko de données de preuve et de quelques centaines de millisecondes de temps supplémentaire pour valider une preuve. Aujourd'hui, Verge représente une vision plus large axée sur l'atteinte d'une efficacité maximale des ressources de la chaîne ETH, comprenant non seulement la technologie de validation sans état, mais également la validation de toutes les exécutions ETH à l'aide de SNARK.

En plus de suivre l'ensemble de la chaîne avec la vérification SNARK à long terme, 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 KECCAK Merkle Patricia actuel, nous devrons le remplacer à nouveau à l'avenir. La méthode d'auto-remplacement de l'arbre Merkle consiste à sauter directement l'utilisation des branches Merkle en faveur des STARK, en les plaçant 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 sur un ordinateur portable avec les ckcle STARKs, et grâce à l'émergence de technologies telles que GKB, le temps de preuve des hachages "traditionnels" a également considérablement diminué. 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 la vérification complète du client et du Nœud de marque ne doit pas dépasser quelques Go.

· (Long term) Valider complètement la chaîne (consensus et exécution) sur une montre intelligente. Télécharger des données, valider SNARK, terminer.

Dans ce chapitre

· Client sans état : Verkle ou STARKs

· EVM 执行的preuve de validité

· Consensus de preuve de validité

Vérification sans état : Verkle ou STARKs

Quel problème devons-nous résoudre?

Aujourd'hui, le client Ethereum doit stocker des 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 par an, 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 complet Ethereum Nœud : bien que les disques durs suffisamment grands pour stocker tous les états d'Ethereum et même plusieurs années d'historique soient courants, les ordinateurs que les gens achètent par défaut n'ont souvent que quelques centaines de gigaoctets de stockage. La taille de l'état crée également de grandes frictions lors de la première mise en place d'un Nœud : le Nœud doit télécharger l'intégralité de l'état, ce qui peut prendre plusieurs heures ou jours. Cela entraîne diverses réactions en chaîne. Par exemple, cela rend beaucoup plus difficile pour les créateurs de Nœuds de mettre à niveau leur configuration de Nœud. Techniquement, la mise à niveau peut être effectuée sans interruption - démarrer un nouveau client, attendre qu'il se synchronise, puis fermer l'ancien client et transférer la Clé secrète - mais cela est très compliqué en pratique.

Comment ça marche?

La validation sans état est une technique qui permet aux nœuds de valider des blocs sans avoir accès à l'état complet. Au lieu de cela, chaque bloc est livré avec un témoin contenant : (i) la valeur, le code, le solde et le stockage de l'emplacement spécifique de l'état que le bloc accédera; (ii) une preuve de chiffrement prouvant que ces valeurs sont correctes.

En fait, pour réaliser une validation sans état, il est nécessaire de modifier la structure de l'arbre d'état d'Ethereum. Cela est dû au fait que l'arbre de Merkle Patricia actuel est extrêmement peu convivial pour la mise en œuvre de tout schéma de preuve de chiffrement, en particulier dans le pire des cas. Que ce soit les "branches" originales de Merkle ou les possibilités "enveloppées" en STARK, c'est toujours le cas. La principale difficulté provient de certaines faiblesses du MPT :

1. Il s'agit d'un arbre à six branches (chaque Nœud ayant 16 sous-Nœuds). Cela signifie que dans un arbre de taille N, une preuve nécessite en moyenne 32*(16-1)log16(N) = 120log2(N) octets, ou environ 3840 octets dans un arbre de 2^32 éléments. Pour un arbre binaire, seuls 32*(2-1)log2(N) = 32log2(N) octets sont nécessaires, soit environ 1024 octets.

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

Nous pouvons calculer le pire des cas comme suit :

30000000 gas / 2400 (冷compte阅读成本) *（5 * 488 + 24000) = 330000000 字节

Le coût de la branche est légèrement inférieur (Goutte) (remplacer 5 * 480 par 8 * 480), car la partie supérieure de la branche se répète lorsqu'il y a plusieurs branches. Cependant, il est totalement irréaliste de télécharger la quantité de données dans une fente. Si nous essayons de l'encapsuler avec STARK, nous rencontrerons deux problèmes : (i) KECCAK est relativement hostile à STARK ; (ii) Les 330 Mo de données signifient que nous devons prouver 5 millions d'appels à la fonction de tour KECCAK, ce qui peut être impossible pour tous les matériels autres que les plus puissants disponibles grand public, même si nous pouvons améliorer l'efficacité de la preuve de STARK pour KECCAK.

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

Arbre Verkle

Verkle utilise des engagements vectoriels 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 limite à la largeur de l'arbre de preuve est que si l'arbre de preuve est trop large, l'efficacité de calcul de la preuve sera réduite. La solution proposée pour Ethereum a une largeur de 256.

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

De plus, il convient de noter que, dans tous les exemples ci-dessus, ce "pire cas" n'est pas vraiment le pire cas : le pire scénario serait que l'attaquant "exploite" deux Adresse de manière à ce qu'elles aient un préfixe commun plus long dans l'arbre, et qu'il lise des données à partir d'une de ces Adresse, 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 la plus défavorable de l'arbre Verkle est de 2,6 Mo, ce qui est essentiellement conforme aux données de vérification les pires cas actuelles.

Nous avons également fait quelque chose avec 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 uniquement 200 gas pour un accès adjacent. Dans le cas d'un accès voisin, la taille de la preuve dans le pire des cas devient de 30000000 / 200 * 32 - 4800800 octets, ce qui reste à peu près dans la tolérance. Si nous voulons réduire cette valeur par souci de sécurité, nous pouvons augmenter légèrement le coût de l'accès voisin.

STARKed Binary Hash Tree

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 STARK. Ainsi, la preuve ne contient que les données à prouver, plus les frais fixes de 100 à 300 ko provenant du STARK réel.

Le principal défi ici est de vérifier le temps. Nous pouvons effectuer des calculs essentiellement identiques à ceux ci-dessus, sauf que nous ne calculons pas en octets mais en valeurs de hachage. Un Bloc de 10,4 Mo signifie 330 000 valeurs de hachage. En ajoutant la possibilité pour un attaquant de « miner » une Adresse avec un préfixe public plus long dans l'arbre, le nombre de valeurs de hachage dans le pire des cas atteindra environ 660 000 valeurs de hachage. Par conséquent, si nous pouvons prouver que le nombre de valeurs de hachage par seconde est de 200 000, tout ira 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 est spécifiquement conçue pour la convivialité de STARK. Cependant, le système Poseidon est encore relativement immature, ce qui fait que de nombreuses personnes ne lui font pas confiance en termes de sécurité. Par conséquent, deux voies réalistes s'offrent :

1. Effectuer une analyse de sécurité approfondie de Poseidon et se familiariser suffisamment avec elle pour un déploiement sur L1.

2. Utiliser des fonctions de hachage plus "conservatrices", telles que SHA256 ou BLAKE

Pour prouver une fonction de hachage conservatrice, le cercle STARK de Starkware ne peut 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 une vitesse améliorée dans la plage de 100-2O0k.

Cas d’utilisation témoins autres que la validation des blocs

En plus de la validation du Bloc, il existe trois autres cas d'utilisation clés qui nécessitent une validation sans état plus efficace 01928374656574839201.

· Mempool : lorsqu’une transaction est diffusée, les nœuds du réseau P2P doivent vérifier que la transaction est valide avant de la rediffuser. De nos jours, la vérification comprend la vérification de la signature, ainsi que la vérification que le solde est suffisant et que le préfixe est correct. À l’avenir (par exemple, en utilisant des abstractions de compte natives, telles que EIP-7701), cela peut impliquer l’exécution d’un code EVM qui effectue un accès à l’état. Si le nœud est sans état, la transaction doit être accompagnée d’une preuve de l’objet d’état.

· 包含列表：这是一个提议的功能，允许（可能规模较小且不复杂的）Preuve d'enjeuvalidateurs强制下一个Bloc包含交易，而不管（可能规模较大且复杂的）Bloc构建者的意愿。这将削弱有权势者通过latence交易来操纵Bloc链的能力。不过，这需要validateurs有办法验证包含列表中交易的有效性。

· 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 central d'Helios fournit aux utilisateurs une racine d'état vérifiée. Pour une expérience entièrement décentralisée, les utilisateurs doivent fournir une preuve pour chaque appel RPC qu'ils effectuent (par exemple, pour les demandes d'appel réseau ETH (les utilisateurs doivent prouver l'accès à tous les états visités pendant l'appel)).

Tous ces cas d'utilisation ont un point commun : ils nécessitent tous une quantité significative de preuves, mais chaque preuve est très petite. Par conséquent, les preuves STARK n'ont pas de sens pour eux ; au contraire, la pratique la plus réaliste est d'utiliser directement les branches Merkle. Un autre avantage des branches Merkle est leur capacité à être mises à jour : étant donné une preuve d'objet d'état X avec la racine Bloc B, si une sous-branche B2 et son témoin sont reçus, la preuve peut être mise à jour pour avoir B2 comme racine. Les preuves Verkle sont également nativement mises à jour.

Quels sont les liens avec les recherches existantes :

· Arbres Verkle

· L'article original de John Kuszmaul sur l'arbre Verkle

· Starkware

· Poseidon2 papier

· Ajtai (fonction de hachage rapide alternative basée sur la dureté du réseau)

· Verkle.info

Que pouvez-vous faire d'autre ?

Le travail principal restant est

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

2. Effectuer et tester davantage de travaux de transition, c'est la partie principale de la complexité de toute implémentation sans état.

3. Plus d'analyses de sécurité sur les fonctions de hachage Poseidon, Ajtai et autres "STARK-friendly"

4. Développer davantage les fonctionnalités de protocole STARK super efficace pour le hachage "conservateur" (ou "traditionnel"), par exemple, selon les points de vue de Binius ou GKR.

De plus, nous allons bientôt décider de choisir l'une des trois options suivantes : (i) l'arbre Verkle, (ii) une fonction de hachage STARK-friendly et (iii) une fonction de hachage conservatrice. Leurs caractéristiques peuvent être grossièrement résumées dans le tableau ci-dessous :

Outre ces "chiffres clés", il existe d'autres considérations importantes :

· Aujourd'hui, le code de l'arbre Verkle est déjà assez mature. En plus de Verkle, l'utilisation de tout autre code retarderait le déploiement et pourrait très probablement retarder un fork. Ce n'est pas grave, surtout si nous avons besoin de temps supplémentaire pour analyser les fonctions de hachage ou implémenter des validateurs, ou si nous avons d'autres fonctionnalités importantes que nous voulons intégrer plus tôt dans Ethereum.

· L'utilisation de la valeur de hachage pour mettre à jour la racine de l'état est plus rapide que l'utilisation de l'arbre Verkle. Cela signifie que la méthode basée sur la valeur de hachage peut réduire le temps de synchronisation de Full Node.

· Les témoins de l'arbre Verkle ont une propriété intéressante de mise à jour - les témoins de l'arbre Verkle sont mis à jour. Cette propriété est utile pour le mempool, les listes de transactions et d'autres cas d'utilisation, et peut également contribuer à améliorer l'efficacité de la mise en œuvre : si un objet d'état est mis à jour, le témoin de l'avant-dernier niveau peut être mis à jour sans avoir à lire le contenu du dernier niveau.

· Il est plus difficile de réaliser une preuve SNARK pour l'arbre Verkle. Si nous voulons réduire la taille de la preuve à quelques milliers d'octets, cela pose quelques difficultés pour la preuve Verkle. Cela est dû à l'introduction de nombreuses opérations de 256 bits dans la vérification de la preuve Verkle, ce qui nécessite soit un coût élevé, soit une structure interne personnalisée de système de preuve avec une partie de preuve Verkle de 256 bits. Cela ne pose pas de problème en soi pour l'état sans état, mais cela crée davantage de difficultés.

Une autre approche possible pour obtenir la vérifiabilité Verkle de manière sécurisée quantiquement et efficace est d'utiliser un arbre de Merkle basé sur une treillis.

Si, dans le pire des cas, il est prouvé que l'efficacité du système n'est pas assez élevée, alors nous pouvons encore utiliser des outils gas multidimensionnels inattendus pour compenser cette insuffisance : (i) les données d'appel ; (ii) le calcul ; (iii) l'accès à l'état et d'autres ressources différentes possibles avec des limites de gas distinctes. Les gas multidimensionnels ajoutent de la complexité, mais en échange, ils limitent plus strictement le ratio entre les cas moyens et les pires cas. Avec les gas multidimensionnels, le nombre maximum de branches à prouver théoriquement pourrait passer de 12500 à 3000, par exemple. Cela permettrait à BLAKE3 de suffire (à peine) même aujourd'hui.

Gas multidimensionnel permet des restrictions de ressources plus proches des restrictions de ressources du matériel sous-jacent Bloc

Un autre outil inattendu est de calculer la latence de la racine d'état jusqu'au Bloc. Ainsi, nous avons exactement 12 secondes pour calculer la racine d'état, ce qui signifie que même dans le cas le plus extrême, le temps de preuve de 60000 hachages par seconde est à peine suffisant, ce qui nous fait penser une fois de plus que BLAKE3 ne peut que difficilement répondre aux exigences.

Un inconvénient de cette méthode est qu'elle ajoute une latence light clientlatence à un créneau horaire, mais il existe également des techniques plus astucieuses pour réduire cette latence à la latence de génération de preuve uniquement. Par exemple, la preuve peut être diffusée sur le réseau immédiatement après sa génération sur n'importe quel Nœud, plutôt que 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 état augmente considérablement la difficulté du point unique de la personne. Si vous avez la technologie pour réduire l'équilibre minimum du point unique de la personne, comme les stratégies Orbit SSF ou de la couche d'application, telles que les points fixes de l'équipe, cela deviendra plus réalisable.

Si EOF est également introduit, l'analyse des gaz multidimensionnels devient plus facile. Cela est dû au fait que la complexité d'exécution principale des gaz multidimensionnels provient du traitement des appels d'enfants qui ne transmettent pas tous les gaz de l'appelant parent, et EOF suffit à rendre ces appels d'enfants illégaux, ce qui rend ce problème insignifiant (et l'abstraction du compte local actuel fournira une alternative interne partielle au protocole de consommation de gaz principal).

La vérification d'état et l'expiration de l'historique ont un rôle de collaboration important. Aujourd'hui, les clients doivent stocker près de 1 To de données d'historique. Ces données sont plusieurs fois supérieures aux données d'état. Même si le client est sans état, à moins que nous ne puissions lever la responsabilité du stockage des données d'historique du client, le rêve de clients sans stockage sera presque impossible à réaliser. La première étape à cet égard est EIP-4444, ce qui signifie également que les données d'historique sont stockées dans des torrents ou sur le réseau de portails Portal Network.

preuve de validité de l'exécution de l'EVM

Quel problème devons-nous résoudre?

L'objectif à long terme de la validation de Bloc dans Ethereum (ETH) est clair - cela devrait pouvoir être vérifié de la manière suivante : (i) télécharger Bloc, ou même seulement une petite partie des échantillons de disponibilité des données dans Bloc ; (ii) vérifier une petite preuve de validité de Bloc. Cela sera une opération à faible consommation de ressources, pouvant être réalisée sur un client mobile, un portefeuille de navigateur ou même sur une autre chaîne (sans la partie de disponibilité des données).

Pour y parvenir, il est nécessaire de fournir des preuves SNARK ou STARK pour (i) la couche de consensus (c'est-à-dire la preuve d'enjeu) et (ii) la couche d'exécution (c'est-à-dire l'EVM). La première est en soi un défi et devrait être résolue dans le cadre d'une amélioration continue de la couche de consensus (par exemple, en ce qui concerne la finalité d'un seul slot). La seconde nécessite une preuve d'exécution de l'EVM.

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

De manière formelle, dans la spécification de l'Éther, l'EVM est défini comme une fonction de transition d'état : vous avez un état précédent S, un Bloc B, et vous calculez un état suivant 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 une racine d'état précédente R, une racine d'état suivante R' et une valeur de hachage de Bloc H.

· Entrée publique: racine d'état antérieure R, racine d'état postérieure R', hachage de bloc H

· Entrée privée : objets dans l'état accédés par le bloc de programme 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

· L'argument 1: P est une preuve valable 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'

· L'argument 3 : Si l'on recalcule le nouvel état racine en utilisant les informations de Q' et P, on obtiendra R'

Si une telle situation se produit, il est possible d'avoir un client léger qui valide entièrement l'exécution de l'EVM d'Éther. Cela rend les ressources du client assez faibles. Pour obtenir un client complet qui valide réellement l'ETH, il est également nécessaire de travailler sur le consensus de la même manière.

La mise en œuvre 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é en raison de choix meilleurs).

· Zeth, son fonctionnement consiste à compiler l'EVM dans le ZK-VM RISC-0

· Projet de Vérification formelle ZK-EVM

Que pouvez-vous faire d'autre ?

Aujourd'hui, le système de comptabilité électronique présente deux lacunes en matière de preuve de validité: la sécurité et le temps de vérification.

Une preuve de validité sécurisée doit garantir que SNARK vérifie effectivement le calcul de l'EVM et qu'il n'y a pas de faille. Les deux principales techniques pour renforcer la sécurité sont les multi-vérificateurs et la vérification formelle. Les multi-vérificateurs font référence à la mise en œuvre de plusieurs preuves de validité indépendantes, tout comme il y a plusieurs clients, et si un bloc est prouvé par un sous-ensemble suffisamment important de ces mises en œuvre, 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 Lean4, 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 d'ETH écrite en python (EELS)).

Un temps de vérification suffisamment rapide signifie que n'importe quel bloc d'ETH peut être vérifié en moins de 4 secondes. Aujourd'hui, nous sommes encore loin de cet objectif, même si nous sommes beaucoup plus proches de ce que nous imaginions il y a deux ans. Pour atteindre cet objectif, nous devons progresser dans trois directions :

· Parallélisation - Le vérificateur EVM le plus rapide actuel peut prouver en moyenne un bloc Ethereum en 15 secondes. Cela est réalisé en parallélisant entre des centaines de GPU, puis en agrégeant leur travail à la fin. En théorie, nous savons parfaitement comment fabriquer un vérificateur EVM capable de prouver les calculs en O(log(N)) temps : laissez un GPU effectuer chaque étape, puis créez un « arbre d'agrégation » :

Réaliser cela présente des défis. Même dans le pire des cas, où une transaction très volumineuse occupe tout le bloc, la division du calcul ne peut pas se faire de manière séquentielle, mais doit être effectuée selon les codes opérationnels (codes opérationnels de la machine virtuelle sous-jacente, tels que EVM ou RISC-V). Assurer la cohérence de la "mémoire" de la machine virtuelle 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, nous savons que même sans aucune autre amélioration, 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 permettre une réduction considérable du temps de vérification du calcul général.

· Autres changements de coût de gaz EVM - Beaucoup de choses dans EVM peuvent être optimisées pour rendre la vie plus facile aux validateurs, surtout dans les pires cas. Si un attaquant peut construire un bloc qui bloque les validateurs pendant dix minutes, il ne suffit pas de prouver un bloc ETH normal en seulement 4 secondes. Les modifications EVM nécessaires peuvent être grossièrement divisées en plusieurs catégories :

• Changement des coûts de gaz - Si une opération nécessite beaucoup de temps pour être prouvée, même si sa vitesse de calcul est relativement rapide, elle devrait avoir un coût de gaz élevé. L'EIP-7667 est une proposition d'EIP pour résoudre ce problème grave : elle augmente considérablement les coûts de gaz des fonctions de hachage (traditionnelles) car les opcodes et les précompilations de ces fonctions sont relativement bon marché. Pour compenser cette augmentation des coûts de gaz, nous pouvons réduire les coûts de gaz des opcodes de l'EVM prouvant avoir des coûts de preuve relativement bas, tout en maintenant le débit moyen constant.

• Remplacement de la structure de 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 de transactions et de reçus vers l'EIP de SSZ est un pas dans cette direction, fait par Etan Kissling.

En plus de cela, les deux outils mentionnés dans la section précédente (le gaz multidimensionnel et l'état racine de latence) peuvent également être utiles à cet égard. Cependant, il convient de noter qu'à la différence de la vérification sans état, l'utilisation de ces deux outils signifie que nous disposons déjà des compétences techniques nécessaires pour réaliser le travail actuel, et même si ces compétences sont utilisées, une vérification ZK-EVM complète nécessitera également plus de travail - seulement moins de travail est nécessaire.

Un point qui n'a pas été mentionné précédemment 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 L2, mais il est peu probable que cela soit un facteur décisif pour L1, car il est fortement souhaité que L1 reste hautement décentralisé, ce qui signifie que la génération de preuves doit rester raisonnablement accessible aux utilisateurs de l'ETH, sans être limitée par les contraintes matérielles d'une seule entreprise. L2 peut faire des compromis plus positifs.

Dans ces domaines, il reste encore beaucoup de travail à faire :

· Les preuves parallélisées nécessitent la preuve que différentes parties du système peuvent « partager la mémoire » (telles que les tables de correspondance). Nous connaissons la technologie pour le faire, mais nous devons la mettre en œuvre.

· Nous avons besoin d'effectuer plus d'analyses pour identifier l'ensemble idéal de variations des coûts de gas, afin de minimiser au maximum le temps de validation dans le pire des cas.

Nous avons besoin de faire plus de travail dans le système de preuve.

Le coût potentiel est:

· Sécurité et temps des validateurs: si vous choisissez une fonction de hachage plus agressive, un système de preuve plus complexe ou des hypothèses de sécurité plus audacieuses ou d'autres schémas de conception, il est possible de réduire le temps des validateurs.

· Décentralisation et temps de preuve d'identité : la communauté doit parvenir à un consensus sur les "spécifications" du matériel de preuve d'identité ciblé. Les preuves doivent-elles être effectuées par des entités à grande échelle ? Voulons-nous que les ordinateurs portables haut de gamme puissent prouver un bloc de la chaîne ETH en 4 secondes ? Ou quelque part entre les deux ?

· Le degré de rupture de la compatibilité arrière : les lacunes dans d'autres domaines peuvent être compensées par des changements de coût du gaz plus actifs, mais cela risque davantage d'augmenter de manière disproportionnée les coûts de certaines applications, forçant les développeurs à réécrire et à redéployer du code pour maintenir la viabilité économique. De même, ces deux outils présentent leur propre complexité et leurs inconvénients.

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

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

· L2 的preuve de validité（即「ZK rollup」）

· Méthode de preuve de hachage binaire "STARK" sans état

Une preuve de validité réussie sur L1 permettra finalement un stake individuel facile : même les ordinateurs les plus faibles (y compris les téléphones portables et les montres intelligentes) pourront stake. Cela permettra de surmonter davantage les autres restrictions liées au stake individuel (comme le minimum de 32ETH).

De plus, la preuve de validité EVM de L1 peut grandement augmenter la limite de gas de L1.

Consensus的preuve de validité

Quel problème devons-nous résoudre?

Si nous voulons vérifier complètement un bloc de la 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 la partie du système qui traite les dépôts, les retraits, la signature, la mise à jour des soldes des validateurs et d'autres éléments de la preuve d'enjeu d'ETH.

Consensus est beaucoup plus simple que l'EVM, mais le défi auquel il est confronté 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 de consensus Ethereum nécessite une "reconstruction" complète, bien que le système de preuve lui-même puisse être construit sur un travail partagé.

Qu'est-ce que c'est et 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 la vérification des signatures BLS)

· Paire (utilisée pour vérifier la signature BLS)

· Valeur de hachage SHA256 (utilisée pour lire et mettre à jour l'état)

Dans chaque bloc, nous devons prouver 1 à 16 ECADD BLS12-381 pour chaque validateur (éventuellement plus d’un, car les signatures peuvent être contenues dans plusieurs collections). Cela peut être compensé par des techniques de précalcul de sous-ensembles, de sorte que nous pouvons dire que chaque validateur n’a besoin de prouver qu’un seul ECADD BLS12-381. Actuellement, il y a 30 000 signatures de validateurs par emplacement. À l’avenir, cela pourrait changer dans deux directions au fur et à mesure de la mise en œuvre de la finalité de l’emplacement unique : si nous empruntons la voie de la « force brute », le nombre de validateurs par emplacement pourrait passer à 1 million. Dans le même temps, si Orbit SSF est adopté, le nombre de validateurs restera à 32 768, voire diminuera à 8 192.

Comment fonctionne l'agrégation BLS : la vérification de la signature totale ne nécessite qu'un ECADD par participant, au lieu d'un ECMUL. Cependant, 30000 ECADD reste une quantité de preuve 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 ultérieures, chaque fente peut être réduite à 16. Le nombre de paires est faible, mais le coût est extrêmement élevé : le temps d'exécution (ou de preuve) de chaque paire est plusieurs k fois plus long que ECADD.

Un défi majeur pour la preuve de calcul BLS12-381 est l'absence d'une courbe pratique dont l'ordre est égal à la taille du champ BLS12-381, ce qui ajoute un coût considérable à tout système de preuve. D'autre part, l'arbre Verkle proposé pour Ethereum est construit avec la courbe Bandersnatch, ce qui fait de BLS12-381 lui-même une sous-courbe utilisée pour prouver les branches Verkle dans les systèmes SNARK. Une implémentation relativement simple peut prouver 100 ajouts G1 par seconde ; pour obtenir une vitesse de preuve suffisamment rapide, il est presque certain qu'il faudra des techniques ingénieuses comme GKR.

Pour la valeur de hachage SHA256, le pire scénario actuel est la conversion d'époque de bloc, tout l'arbre court d'équilibrage du validateur et une grande quantité de validateurs d'équilibrage seront mis à jour. Chaque arbre court d'équilibrage d'un validateur n'a qu'un octet, donc 1 Mo de données sera rehashé. Cela équivaut à 32768 appels de hachage SHA256. Si le solde de mille validateurs est supérieur ou inférieur à un seuil, il est nécessaire de mettre à jour les soldes valides dans l'enregistrement 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 par validateur (donc 11 Mo de données), mais cela peut être calculé à tout moment au cours d'une époque. Dans le cas d'une terminaison de fente unique, ces chiffres peuvent varier en fonction de la situation spécifique. Le mélange devient inutile, bien que Orbit puisse rétablir partiellement ce besoin.

Une autre difficulté réside dans la nécessité de récupérer l'ensemble de l'état des validateurs, y compris la clé publique, afin de vérifier un bloc. Pour 1 million de validateurs, la simple lecture de la clé publique nécessite 48 millions d'octets, sans compter la branche Merkle. Cela nécessite donc des millions de valeurs de hachage par époque. Si nous devons prouver la validité de PoS, une méthode réaliste serait 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 prouver les mises à jour de cette structure.

En somme, il y a beaucoup de défis. Pour faire face le plus efficacement possible à ces défis, il sera très probablement nécessaire de procéder à une refonte approfondie de la beacon chain, peut-être en même temps que le passage à la fin de l'unique slot. Cette refonte pourrait inclure les caractéristiques suivantes :

· Variation de la fonction de hachage : nous utilisons maintenant la fonction de hachage SHA256 "complète", ce qui signifie qu'en raison du rembourrage, chaque appel nécessite deux appels à la fonction de compression sous-jacente correspondante. Si nous utilisons la fonction de compression SHA256, nous pourrions obtenir au moins le double des gains. Si nous utilisons Poseidon, nous pourrions obtenir un gain de 100 fois, ce qui résoudrait complètement tous nos problèmes (au moins en ce qui concerne les valeurs de hachage) : nous pourrions "lire" jusqu'à un million d'enregistrements de vérification en quelques secondes, même à raison de 1,7 million de valeurs de hachage par seconde (54 Mo).

· Si c'est Orbit, enregistrez directement les enregistrements des validateurs une fois qu'ils sont mélangés : si vous choisissez un certain nombre de validateurs (comme 8192 ou 32768) pour former un comité pour une fente donnée, placez-les directement dans l'état à côté de l'autre, de sorte qu'il faut un minimum de hash pour lire toutes les clés publiques des validateurs dans la preuve. Cela permet également de finaliser efficacement toutes les mises à jour d'équilibre.

· Signature agrégée: Tout schéma d'agrégation de signatures à haute performance implique inévitablement une preuve récursive, où différents nœuds du réseau effectuent une preuve intermédiaire sur un sous-ensemble de signatures. Cela décharge naturellement la tâche de preuve sur plusieurs nœuds du réseau, réduisant ainsi considérablement la charge de travail du « proof-of-finally ».

· 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é par 32768 signataires, cela donne 9437184 valeurs de hachage. Après l'optimisation du schéma de signature, cette valeur peut être améliorée par un petit facteur constant. Si nous utilisons Poseidon, cela peut être prouvé dans un seul slot. Mais en réalité, l'agrégation récursive est plus rapide.

Quels sont les liens avec les recherches existantes ?

· Preuve de consensus Ethereum (uniquement pour le comité de synchronisation)

· Helios dans SP1 de la simplicité

· Précompilation concise BLS12-381

· Vérification de signature de groupe BLS basée sur Halo2

Quels autres travaux doivent être effectués et comment choisir:

En fait, il nous faudra plusieurs années pour obtenir la preuve de validité du consensus ETH. Cela prendra à peu près le même temps que la réalisation de la finalité d'un seul slot, Orbit, la modification de l'algorithme de signature et l'analyse de sécurité nécessitent. L'analyse de sécurité nécessite suffisamment de confiance pour utiliser des fonctions de hachage "agressives" telles que Poseidon. Par conséquent, la meilleure approche consiste à résoudre ces autres problèmes tout en tenant compte de la convivialité de STARK.

Le principal compromis est probablement dans l'ordre des opérations, entre une approche plus progressive de la réforme de la couche de consensus d'Ethereum et une approche plus radicale de "changer beaucoup en une seule fois". Pour l'EVM, une approche progressive est raisonnable car elle minimise les perturbations de la compatibilité ascendante. Pour la couche de consensus, les effets sur la compatibilité ascendante sont moindres, et il est également avantageux de repenser de manière plus globale les divers détails de la construction de la beacon chain pour optimiser de la meilleure façon possible la convivialité de SNARK.

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

Lors de la refonte à long terme de PoS d'Éther, la convivialité de STARK doit être la principale considération, en particulier la finalité unique de la fente, l'Orbit, les modifications du schéma de signature et l'agrégation de signatures.

Lien vers l'article original