Vitalik: L’avenir possible du protocole Ethereum – le verge

Auteur: Vitalik, fondateur d’Ethereum;

Remarque: Cet article est la quatrième partie de la série d’articles récemment publiés par Vitalik, fondateur d’Ethereum.Futures possibles du protocole Ethereum, partie 4: The Verge« . Voir « Vitalik: objectifs clés de l’ethereum la phase du fléau« , Voir la deuxième partie »Vitalik: Comment le protocole Ethereum devrait-il se développer au stade de surtension», Voir la première partie»Quoi d’autre peut être amélioré sur Ethereum pos».

---

Un merci spécial à Justin Drake, Hsiao-Wei Wang, Guillaume Ballet, Ignacio, Josh Rudolf, Lev Soukhanov, Ryan Sean Adams et Uma Roy pour leurs commentaires et examen.

L’une des caractéristiques les plus puissantes de la blockchain est que n’importe qui peut exécuter des nœuds sur ses propres ordinateurs et vérifier que la chaîne est correcte.Même si 95% des nœuds exécutant un consensus sur la chaîne (POW, POS …) acceptent immédiatement de modifier les règles et de commencer à produire des blocs en fonction des nouvelles règles, tous ceux qui exécutent un nœud entièrement validé refuseront d’accepter la chaîne.Les parties prenantes qui n’appartiennent pas à ces groupes convergent automatiquement et continueront de construire une chaîne qui continue de suivre les anciennes règles, et les utilisateurs entièrement vérifiés suivront la chaîne.

Il s’agit de la principale différence entre la blockchain et les systèmes centralisés.Cependant, pour maintenir cette fonctionnalité, l’exécution des nœuds entièrement validés doit être réellement possible pour un nombre critique de personnes.Cela s’applique aux deux stakers (comme si les stakers n’avaient pas de chaîne de vérification, ils ne contribuent pas réellement à l’application des règles de protocole) et aux utilisateurs ordinaires.Aujourd’hui, les nœuds peuvent être exécutés sur des ordinateurs portables grand public, y compris ceux utilisés pour écrire cet article, mais il est difficile de le faire.Le Verge vise à changer cela, ce qui rend le coût informatique d’une chaîne de vérification complète si faible que chaque portefeuille mobile, portefeuille de navigateur et même Smartwatch le fait par défaut.

La feuille de route Verge, 2023.

Initialement, «Verge» fait référence à l’idée de transférer le stockage d’état Ethereum aux arbres Verkle – une structure d’arbre qui permet des preuves plus compactes qui permettent une vérification sans état des blocs Ethereum.Les nœuds peuvent vérifier les blocs Ethereum sans aucun état d’Ethereum (solde du compte, code contractuel, stockage …) sur leur disque dur, mais au prix de dépenser des centaines de kilobytes de données de preuve et des centaines de millisecondes de temps supplémentaire pour vérifier la preuve.Aujourd’hui, Verge représente une vision plus large axée sur la réalisation d’une vérification maximale de l’efficacité des ressources de la chaîne Ethereum, qui comprend non seulement une technologie de vérification sans état, mais également valider toutes les exécutions Ethereum en utilisant Snark.

En plus de l’accent à long terme sur la validation des snark de toute la chaîne, une autre nouvelle question est liée à la question de savoir si les arbres Verkle sont la meilleure technologie.Les arbres Verkle sont vulnérables aux ordinateurs quantiques, donc si nous remplacons les arbres actuels de Keccak Merkle Patricia par des arbres Verkle, nous devrons à nouveau remplacer ces arbres plus tard.Une alternative naturelle aux arbres Merkle est de sauter directement à l’utilisation de la branche Merkle Stark dans l’arbre binaire.Historiquement, cela a été considéré comme inquiet en raison des frais généraux et de la complexité technique.Cependant, récemment, nous avons vu Starkware prouvé 1,7 million de hachages de Poséidon par seconde sur les ordinateurs portables avec Circle Stark, et le temps de preuve pour les hachages plus «traditionnels» se rétrécit également rapidement en raison de technologies telles que GKR.

Ainsi, au cours de la dernière année, Verge est devenue plus ouverte et il y a plusieurs possibilités.

Le verge: objectifs clés

• Client sans état: Vérifiez entièrement que le client et le nœud marqué ne nécessitent pas plus de quelques Go d’espace de stockage.

• (À long terme) chaîne de vérification complète (consensus et exécution) sur les montres intelligentes.Téléchargez certaines données, vérifiez le snark et terminez.

Dans cet article, le contenu suivant est mis en évidence:

• Vérification sans état: Verkle ou Starks

• Preuve de validité de l’exécution EVM

• Preuve de validité du consensus

Vérification sans état: Verkle ou Starks

Quels problèmes voulons-nous résoudre?

Aujourd’hui, les clients Ethereum doivent stocker des centaines de GB de données d’État pour vérifier les blocs, et ce nombre continue d’augmenter chaque année.Les données de l’état brut augmentent d’environ 30 Go par an, et les clients personnels doivent stocker des données supplémentaires en plus de pouvoir mettre à jour efficacement les essais.

Cela réduit le nombre d’utilisateurs qui peuvent exécuter des nœuds Ethereum entièrement vérifiés: bien que le disque dur soit suffisamment grand pour stocker tout l’état d’Ethereum et même des années d’histoire, les ordinateurs achètent par défaut ont tendance à avoir seulement quelques centaines de gigaoctets d’espace de stockage.La taille de l’état peut également causer de grands problèmes au processus de mise en place d’un nœud pour la première fois: le nœud doit télécharger l’ensemble de l’État, ce qui peut prendre des heures ou des jours.Cela produira diverses réactions en chaîne.Par exemple, cela rend plus difficile pour les Stakers de mettre à niveau leurs paramètres de pieu.Techniquement, cela peut être fait sans un temps d’arrêt – démarrer un nouveau client, l’attendre de se synchroniser, puis fermer l’ancien client et transférer la clé – mais en réalité, cela est techniquement complexe.

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

La vérification sans état est une technique qui permet aux nœuds de vérifier les blocs sans avoir un état complet.Au lieu de cela, chaque bloc est livré avec un témoin, qui comprend (i) des valeurs à un emplacement spécifique dans l’état où le bloc accédera (par exemple, code, équilibre, stockage) et (ii) la preuve cryptographique de ces valeurs est correct de.

La mise en œuvre réelle de la vérification sans état nécessite de modifier la structure des arbres d’état Ethereum.En effetCela est vrai pour la branche « originale » Merkle et la possibilité de « emballer » la branche Merkle en Stark.Les principales difficultés proviennent de deux faiblesses dans MPT:

• Il s’agit d’un hexagramme (c’est-à-dire que chaque nœud a 16 nœuds enfants).Cela signifie qu’en moyenne, la preuve dans un arbre de taille n a 32 * (16-1) * log16 (n) = 120 * log2 (n) octets, soit environ 3840 octets dans un arbre de 232 éléments.Pour les arbres binaires, seulement 32 * (2-1) * log2 (n) = 32 * log2 (n) octets sont nécessaires, c’est-à-dire environ 1024 octets.

• Ce code n’est pas merkelisé.Cela signifie que tout accès au code du compte est requis pour fournir le code complet, avec une longueur maximale de 24 000 octets.

Nous pouvons calculer le pire des cas comme suit:

30 000 000 Gas / 2 400 (compte « Cold » Le coût de lecture) * (5 * 480 + 24 000) = 330 000 000 octets

Les coûts de branche sont légèrement inférieurs (5 * 480 au lieu de 8 * 480), car lorsqu’il y a beaucoup de branches, le haut de la branche sera répété.Mais même ainsi, la quantité de données téléchargées dans une fente est complètement irréaliste.Si nous essayons de l’envelopper dans Stark, nous avons deux problèmes: (i) Keccak n’est pas amical par rapport à Stark, (ii) 330 Mo de données signifie que nous devons prouver 5 millions d’appels à la fonction ronde de Keccak, ce qui est un moyen Même si nous pouvons rendre Stark prouver Keccak plus efficace, il y a beaucoup plus de choses qui ne peuvent pas être prouvées sur tout le matériel en plus du matériel de consommation le plus puissant.

Si nous remplaçons simplement l’hexagramme par un arbre binaire et ajoutons le code Merkelize, le pire des cas sera d’environ 30 000 000/2400 * 32 * (32 – 14 + 8) = 10 400 000 octets ~ 214 branches, dont la preuve de la longueur entrante une feuille).Notez que cela nécessite de modifier le coût du gaz pour facturer pour accéder à chaque bloc de code individuel; c’est ce que fait EIP-4762.10.4 MB est bien meilleur, mais pour de nombreux nœuds, il y a encore trop de données à télécharger dans une seule fente.Nous devons donc introduire des technologies plus puissantes.Pour ce faire, il existe deux solutions principales: l’arbre Verkle et l’arbre de hachage binaire au feu.

Verkle

Les arbres Verkle utilisent des engagements vectoriels basés sur des courbes elliptiques pour faire des preuves plus courtes.La clé est que quelle que soit la largeur de l’arbre, le fragment de preuve correspondant pour chaque relation parent-enfant n’est que de 32 octets.La seule limitation de la largeur de l’arbre est que si l’arbre est trop large, l’efficacité de calcul de la preuve sera réduite.La largeur de mise en œuvre recommandée par Ethereum est de 256.

Par conséquent, la taille d’une seule branche dans la preuve devient 32 * log256 (n) = 4 * log2 (n) octets.Théoriquement, la taille maximale de preuve devient environ 30 000 000/2400 * 32 * (32-14 + 8) / 8 = 1 300 000 octets (les calculs mathématiques sont légèrement différents dans la pratique en raison de la distribution inégale des blocs d’État, mais c’est le premier très bon) .

Comme avertissement supplémentaire, notez que dans tous les exemples ci-dessus, ce « pire cas » n’est pas le pire des cas: le pire cas est que l’attaquant « mines » deux adresses pour avoir un long public dans le préfixe d’arbre et lire de L’un d’eux, cela peut étendre la longueur de la branche du pire d’environ 2 fois.Mais même avec un tel avertissement, l’arbre Verkle nous donne environ 2,6 Mo de pire preuves, ce qui correspond à peu près aux données d’appel des pires cas d’aujourd’hui.

Nous utilisons également cet avertissement pour faire une autre chose: nous faisons accès au stockage « adjacent » très bon marché: de nombreux blocs de code du même contrat ou des emplacements de stockage adjacents.L’EIP-4762 fournit la définition de la contiguïté, et l’accès à la contiguïté ne représente que des frais de 200 gaz.Pour l’accès adjacent, la taille de la pire preuve devient 30 000 000/200 * 32 = 4 800 800 octets, ce qui est encore à peu près dans la plage de tolérance.Si nous voulons réduire cette valeur pour la sécurité, nous pouvons légèrement augmenter le coût de l’accès adjacent.

Arbre de hachage binaire avec

La technique ici est très explicite: vous faites un arbre binaire, prenez la preuve Max-10,4-Mb que vous devez prouver la valeur dans un bloc et remplacer la preuve par le brut de cette preuve.Cela nous amène à constater que la preuve elle-même ne contient que les données qui sont prouvées, plus les frais généraux fixes du Stark réel.

Le principal défi ici est de prouver le temps.Nous pouvons faire essentiellement le même calcul que ci-dessus, sauf que nous ne calculons pas les octets, mais calculons la valeur de hachage.Un bloc de 10,4 Mo signifie 330 000 hachages.Si nous ajoutons la possibilité qu’un attaquant « mine » l’adresse avec un long préfixe public dans l’arbre, le pire cas deviendra environ 660 000 hachages.Donc, si nous pouvons prouver environ 200 000 hachages par seconde, alors c’est bien.

Ces chiffres ont été atteints sur les ordinateurs portables grand public avec une fonction de hachage Poséidon conçu spécifiquement pour une convivialité austère.Cependant, Poséidon est relativement immature, donc beaucoup de gens ne font toujours pas confiance à sa sécurité.Par conséquent, il y a deux chemins réalistes:

• Effectuez rapidement beaucoup d’analyses de sécurité sur Poséidon et le familiariser pour le déployer sur L1

• Utilisez une fonction de hachage plus « conservatrice », comme Sha256 ou Blake

Au moment de la rédaction du moment de la rédaction, le prover Stark de Starkware ne peut prouver qu’environ 10 à 30 000 hachages par seconde sur un ordinateur portable grand public s’il veut prouver une fonction de hachage conservatrice.Cependant, la technologie Stark progresse rapidement.Aujourd’hui encore, la technologie basée sur GKR montre un potentiel pour l’augmenter à la plage d’environ 100-200 000.

Des cas d’utilisation des témoins autres que les blocs de vérification

En plus du bloc de vérification, il existe trois autres cas d’utilisation clés qui permettent une vérification sans état plus efficace:

• Pool de mémoire:Lorsqu’une transaction est diffusée, les nœuds du réseau P2P doivent vérifier que la transaction est valide avant la retraite.Aujourd’hui, la vérification comprend non seulement la validation de la signature, mais aussi la vérification que le solde est suffisant et que le nombre aléatoire 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 nécessitera une preuve avec une preuve de l’objet d’état.

• Inclure la liste:Il s’agit d’une fonctionnalité proposée qui permet des validateurs de preuve d’assistance (peut-être petits et simples) à forcer le bloc suivant à contenir des transactions, indépendamment des souhaits du constructeur de blocs (peut-être grand et complexe).Cela réduira la capacité des participants puissants à manipuler des blockchains en retardant les transactions.Cependant, cela nécessite que les validateurs aient un moyen de vérifier la validité des transactions dans la liste incluse.

• Client léger:Si nous voulons que les utilisateurs accédaient à la chaîne via des portefeuilles (par exemple Metamask, Rainbow, Rabby …) sans faire confiance aux participants centralisés, ils doivent gérer un client léger (par exemple Helios).Le module Core Helios fournit aux utilisateurs une racine d’état validée.Cependant, afin d’obtenir une expérience entièrement sans confiance, les utilisateurs doivent fournir une preuve pour chaque appel de RPC individuel qu’ils font (par exemple, pour une demande ETH_CALL, les utilisateurs ont besoin de preuve de tous les états accessibles pendant l’appel);

Une chose que tous ces cas d’utilisation sont courants est qu’ils nécessitent beaucoup de preuves, mais chaque preuve est petite.Par conséquent, Stark prouve que cela n’a pas de sens;Un autre avantage des succursales de Merkle est qu’ils mettent à jour: étant donné une preuve d’objet d’état X enraciné dans le bloc B, vous pouvez mettre à jour cette preuve si vous recevez un sous-bloc B2 avec son témoin.La preuve Verkle elle-même est également à jour.

Quelles sont les liens avec la recherche existante?

Verkle Tree:https://vitalik.eth.limo/general/2021/06/18/verkle.html

Le papier Verkle Tree original de John Kuszmaul:https://math.mit.edu/research/highschool/primes/materials/2018/kuszmaul.pdf

Données de preuve de Starkware:https://x.com/starkwareltd/status/180776563188162562

POSEIDON2 PAPIER:https://eprint.iacr.org/2023/323

Ajtai (fonction de hachage rapide alternative basée sur la dureté de la grille):https://www.wisdom.weizmann.ac.il/~oded/col/cfh.pdf

Verkle.info:https://verkle.info/

Que faut-il faire d’autre et quels compromis doivent être pesés?

Les principales tâches principales à effectuer sont:

• Plus d’analyse des conséquences de l’EIP-4762 (changements de coût du gaz sans état)

• Plus de procédures de transition d’achèvement et de test, qui fait partie de toute complexité EIP sans état

• Plus d’analyse de sécurité des fonctions de hachage « 

• Développez davantage des protocoles Stark ultra-efficaces pour les fonctions de hachage « conservatrices » (ou « traditionnelles »), telles que l’idée basée sur Binius ou GKR.

Nous allons bientôt faire un point de décision pour choisir les trois options suivantes: (i) Tree Verkle, (ii) fonction de hachage conviviale et (iii) fonction de hachage conservatrice.Leurs propriétés peuvent être résumées à peu près comme suit:

En plus de ces « numéros de titre », il existe d’autres considérations importantes:

• maintenant,Le code d’arbre Verkle est assez mature.Utiliser autre chose que Verkle retardera en fait le déploiement, très probablement via des fourches dures.Cela peut être OK, surtout si nous avons besoin de temps supplémentaire pour effectuer une analyse de fonction de hachage ou une implémentation de prover, et si nous avons d’autres fonctionnalités importantes que nous voulons inclure dans Ethereum dès que possible.

• Mettez à jour la racine de l’état avec le hachage est plus rapide que l’utilisation d’arbres Verkle.Cela signifie que l’approche basée sur le hachage peut raccourcir le temps de synchronisation du nœud complet.

• VL’arbre Erkle a des propriétés de mise à jour des témoins intéressants– Verkle Tree Witness est à jour.Cette propriété est utile pour les pools de mémoire, inclut les listes et d’autres cas d’utilisation, et il peut également aider à atteindre l’efficacité: si vous mettez à jour l’objet d’état, vous pouvez mettre à jour le témoin au niveau de l’avant-dernier sans même lire le dernier niveau.

• Les arbres Verkle sont plus difficiles à prouver par Snark.Si nous voulons réduire la taille de la preuve jusqu’à quelques kilobytes, les preuves Verkle peuvent apporter des difficultés.En effet, Verkle Proof Vérification introduit un grand nombre d’opérations 256 bits, ce qui nécessite que le système de preuve ait beaucoup de frais généraux ou lui-même a une structure interne personnalisée qui contient la partie 256 bits pour Verkle Proof.

Une autre approche possible est l’arbre Merkle basé sur le maillage si nous voulons que la mise à jour observée par Verkle soit réalisée de manière très sûre et assez efficace.

S’il est prouvé que le système n’est pas suffisamment efficace dans le pire des cas, nous pouvons compenser cette lacune avec un autre « lapin dans le chapeau », qui est le gaz multidimensionnel: l’accès à (i) calldata, (ii) l’informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) informatique ((ii) Computing, ((ii) Computing, ((ii) Computing, ((ii) Computing ((ii) Computing ((II) (II) Compose iii) L’état et éventuellement les autres ressources différentes ont des restrictions de gaz distinctes.Le gaz multidimensionnel ajoute de la complexité, mais en échange, il limite plus strictement le rapport entre le scénario moyen et le pire des cas.Pour le gaz multidimensionnel, le nombre maximal théorique de branches à prouver peut être réduit de 30 000 000/2400 = 12 500 à 3000.Cela rendra Blake3 (à peine) suffisant même aujourd’hui, sans autre amélioration de preuve.

Le gaz multidimensionnel permet de bloquer les limitations des ressources pour reproduire les limitations de ressources matérielles sous-jacentes plus près des limitations des ressources.

Une autre «respiration qui apparaît» est la proposition de retarder le calcul de la racine de l’état jusqu’à la suite du bloc.Cela nous donnera 12 secondes pour calculer la racine de l’État, ce qui signifie que même dans les cas les plus extrêmes, seulement environ 60 000 hachages / secondes sont suffisants, ce qui nous met à nouveau dans Blake3 à peine assez dans la plage d’utilisation.

L’inconvénient de cette approche est qu’elle augmente la latence légère des clients d’une période, bien qu’il existe des versions plus intelligentes de la technologie qui peuvent réduire cette latence à la latence de génération juste.Par exemple, tant que tout nœud génère une preuve, la preuve peut être diffusée sur le réseau au lieu d’attendre le bloc suivant.

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

La résolution du problème apatride augmente considérablement la commodité des promesses séparées.Cela deviendra plus précieux si des technologies qui peuvent réduire l’équilibre minimum des participations individuelles, telles que les politiques en orbite SSF ou en couches d’application, telles que les enjeux d’escouade, sont disponibles.

Le gaz multidimensionnel sera plus facile si l’EOF est introduit en même temps.En effet, une complexité clé du gaz multidimensionnel pour l’exécution est de gérer les appels d’enfants qui ne passent pas l’appel parent au gaz complet, et l’EOF rend simplement un tel appel d’enfant illégal (et l’abstraction du compte indigène fournira à un courant Alternatives de protocole de sous-appel de gaz pour les principaux cas d’utilisation).

Une autre synergie importante est la synergie entre la vérification apatride et l’expiration historique.Aujourd’hui, les clients doivent stocker presque des téraoctets de données historiques; ces données sont plusieurs fois plus importantes que les données nationales.Même si le client est apatride, le rêve du client de presque aucun stockage ne peut être réalisé que si nous pouvons également atténuer la responsabilité de l’historique de stockage du client.La première étape à cet égard est EIP-4444, ce qui signifie également stocker des données historiques dans un réseau torrent ou portail.

Preuve de validité de l’exécution EVM

Quels problèmes voulons-nous résoudre?

L’objectif à long terme de la vérification du bloc Ethereum est clair: vous devriez être en mesure de vérifier un bloc Ethereum par: (i) télécharger le bloc, peut-être même juste une petite partie du bloc et l’échantillonnage de la disponibilité des données, et (ii) vérifier un petite partie pour prouver que le bloc est valide.Ce sera une opération avec une consommation de ressources minimale qui peut être effectuée dans une autre chaîne du client mobile, dans le portefeuille du navigateur, ou même (sans section de disponibilité des données).

Pour y parvenir, des preuves Snark ou Stark sont nécessaires avec (i) la couche consensus (c’est-à-dire la preuve de la participation) et (ii) la couche d’exécution (c’est-à-dire EVM).Le premier est un défi en soi et doit être abordé dans le processus d’amélioration supplémentaire de la couche consensuelle (par exemple, la finalité à emplacement unique).Ce dernier nécessite une preuve de l’exécution EVM.

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

Formellement, dans la spécification Ethereum, EVM est défini comme une fonction de transition d’état: vous avez des S pré-états, un bloc B et vous calculez un S ‘= STF (S, B) après l’état.Si l’utilisateur utilise un client léger, il n’a pas S et S ‘, ni même B;La déclaration complète qui doit être prouvée est approximativement:

• Contrainte du public:L’état précédent root r, ce dernier état root r ‘, et le bloc hash H.

• Entrée privée:Bloc B, objets à l’état accessibles par le bloc Q, le même objet après l’exécution du bloc Q ‘, preuve d’état (comme la branche de Merkle) P.

• Proposition 1:P est une preuve valable que Q contient certaines parties de l’État représentées par R.

• Proposition 2:Si vous exécutez STF sur Q, (i) Exécuter les objets d’accès uniquement à l’intérieur Q, (ii) le bloc est valide et (iii) le résultat est q ‘.

• Proposition 3:Si vous recalculez la nouvelle racine d’état à l’aide des informations dans Q ‘et P, vous obtiendrez R’.

S’il existe, vous pouvez avoir un client léger qui peut pleinement vérifier l’exécution de Ethereum EVM.Cela rend les ressources du client assez faibles.Pour obtenir un client Ethereum vraiment entièrement validé, vous devez également faire de même pour la partie consensuelle.

La mise en œuvre de la preuve de validité de l’informatique EVM existe déjà et est largement utilisée par L2.Cependant, il reste encore beaucoup de travail à faire pour rendre le travail de preuve de validité EVM applicable à L1.

Quelles sont les liens avec la recherche existante?

EC PSE ZK-EVM (maintenant déprécié car il y a de meilleures options):https://github.com/privacy-scaling-explorations/zkevm- circuits

Zeth, qui fonctionne en compilant EVM dans RISC-0 ZK-VM:https://github.com/risc0/zeth

Projet de vérification formelle ZK-EVM:https://verified-zkevm.org/

Que faut-il faire d’autre et quels compromis doivent être pesés?

maintenant,La preuve de validité de l’EVM n’est pas suffisante en deux aspects: la sécurité et le temps de preuve.

La preuve d’efficacité de la sécurité doit s’assurer que Snark vérifie les calculs EVM et qu’il n’y a pas d’erreurs.Les deux principales techniques pour améliorer la sécurité sont les proverbes multiples et la vérification formelle.Multi-provente signifie avoir plusieurs implémentations de preuve de validité écrites de plusieurs implémentations, tout comme avoir plusieurs clients, et si un sous-ensemble suffisamment important de ces implémentations prouve un bloc, le client accepte ce bloc.La validation formelle consiste à utiliser des outils couramment utilisés pour prouver les théorèmes mathématiques (tels que Lean4) pour prouver que les preuves de validité acceptent uniquement l’entrée qui est correctement exécutée par la spécification EVM sous-jacente écrite en python.

Un temps de preuve suffisamment rapide signifie qu’un bloc Ethereum peut être prouvé en moins de 4 secondes.Aujourd’hui, nous sommes encore loin de cet objectif, même si nous sommes beaucoup plus proches que nous ne le pensions il y a deux ans.Pour y parvenir, nous devons avancer sous trois aspects:

• Parallélisation – Le prover EVM le plus rapide d’aujourd’hui peut prouver le bloc Ethereum moyen en environ 15 secondes.Il le fait en parallélisant des centaines de GPU, puis en mettant enfin leur travail ensemble.En théorie, nous savons exactement comment faire un prover EVM qui peut prouver le calcul du temps o (log (n)): laissez un GPU effectuer chaque étape, puis effectuer « l’arbre d’agrégation »:

Il y a des défis dans la mise en œuvre de cela.Même dans le pire des cas (c’est-à-dire que de très grandes transactions occupent l’ensemble du bloc), la scission calculée ne peut pas être effectuée par transaction;Un défi de mise en œuvre clé qui rend cela non entièrement trivial est la nécessité de garantir que la «mémoire» de la machine virtuelle est cohérente dans différentes parties de la preuve.Cependant, si nous pouvons faire cette preuve récursive, nous savons qu’au moins le problème de retard du prover a été résolu, même s’il n’y a aucune amélioration par rapport à aucun autre axe.

• Optimisation du système de preuve –De nouveaux systèmes d’épreuves tels que Orion, Binius, GKR peuvent entraîner une réduction significative du temps de preuve pour les produits généraux.

• Le gaz d’EVM consomme d’autres changements –Beaucoup de choses dans l’EVM peuvent être optimisées pour les rendre plus amicales, en particulier dans le pire des cas.Si un attaquant peut construire un bloc qui prend dix minutes pour le prover, il ne suffit pas de prouver un bloc Ethereum moyen en 4 secondes.Les modifications EVM requises peuvent être divisées en deux catégories:

• Changements de coût de gaz –Si une opération prend beaucoup de temps à prouver, elle devrait avoir un coût de gaz plus élevé même si le calcul est relativement rapide.L’EIP-7667 est un EIP proposé pour faire face au problème le plus grave à cet égard: il augmente considérablement le coût du gaz en opcodes relativement bon marché et précompilant les fonctions de hachage exposées (traditionnelles).Pour compenser ces coûts de gaz accrus, nous pouvons réduire les coûts de gaz pour prouver des opcodes EVM relativement bon marché, gardant ainsi le débit moyen identique.

• Remplacement de la structure des données –En plus de remplacer l’arbre d’État par une alternative plus adaptée à Stark, nous devons également remplacer les listes de transactions, les arbres de réception et d’autres structures qui s’avèrent coûteuses.EIP d’Ethan Kissling déplace la structure de transaction et de réception à SSZ ([1] [2] [3]), un pas dans cette direction.

De plus, les deux « lapins sortant du chapeau » mentionnés dans la section précédente (gaz multidimensionnel et racines d’État retardé) peuvent également aider ici.Il convient de noter, cependant, que contrairement à la vérification sans état, la vérification sans état signifie que nous avons suffisamment de technologie pour faire ce dont nous avons besoin aujourd’hui, et même avec ces technologies, une vérification complète de ZK-EVM nécessitera plus de travail – – cela nécessite simplement moins de travail.

Une chose non mentionnée ci-dessus est le matériel de preuve: générer une preuve plus rapidement à l’aide de GPU, FPGA et ASIC.La cryptographie en tissu, Cysic et AccSeal sont les promoteurs de ces trois sociétés.Ceci est très précieux pour le niveau 2, mais il est peu probable qu’il s’agisse d’une considération décisive pour le niveau 1, car il existe un fort désir de garder le niveau 1 hautement décentralisé, ce qui signifie que la génération d’épreuves doit être dans un sous-ensemble considérable dans le cadre de la capacité .Les utilisateurs d’Ethereum ne devraient pas rencontrer des goulots d’étranglement dans le matériel d’une seule entreprise.La couche 2 permet des compromis plus radicaux.

Il y a plus de travail à faire dans ces domaines:

• La preuve parallèle nécessite un système de preuve où différentes parties de la preuve peuvent être une «mémoire partagée» (comme les tables de recherche).Nous connaissons les techniques pour ce faire, mais elles doivent être mises en œuvre.

• Nous avons besoin de plus d’analyses pour trouver l’ensemble idéal de variations de coûts de gaz pour minimiser le temps de preuve le plus des cas.

• Nous devons en faire plus sur le système de preuve

Les compromis possibles ici comprennent:

• Sécurité et temps de prover:Des choix actifs utilisant des fonctions de hachage, des systèmes de preuve avec des hypothèses de sécurité plus complexes ou plus actives ou d’autres choix de conception peuvent réduire le temps de proverage.

• Temps décentralisé et prover:La communauté doit s’entendre sur la «normative» de son matériel de prover cible.Est-il acceptable de demander à la preuve d’être une entité à grande échelle?Espérons-nous que les ordinateurs portables grand public haut de gamme pourront prouver le bloc Ethereum en 4 secondes?Quelque chose entre les deux?

• Le degré auquel la compatibilité en arrière est brisée:Les insuffisances dans d’autres domaines peuvent être compensées en effectuant des changements plus agressifs sur les coûts du gaz, mais cela est plus susceptible d’augmenter le coût de certaines applications de manière disproportionnée et de forcer les développeurs à réécrire et à redéployer le code afin de les garder économiquement viables.De même, le « lapin dans le chapeau » a également sa propre complexité et ses inconvénients.

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

Les technologies de base nécessaires pour mettre en œuvre une preuve de validité EVM à la couche 1 sont largement partagées avec deux autres domaines:

• Preuve de validité de la couche 2 (c’est-à-dire « ZK Rollups »)

• Méthode sans état « Stark Binary Hash Proof »

La mise en œuvre réussie de la validité au niveau 1 prouve que finalement un exercice séparé facile: même les ordinateurs les plus faibles, y compris les téléphones portables ou les montres intelligentes, peuvent être des jalonneurs.Cela augmente encore la valeur de la lutte contre les autres restrictions pour la mise en œuvre individuellement (par exemple, minimum 32 ETH).

De plus, la validité EVM de L1 s’est avérée augmenter considérablement la limite de gaz de L1.

Preuve de validité du consensus

Quels problèmes voulons-nous résoudre?

Si nous voulons être en mesure de vérifier complètement les blocs Ethereum avec Snark, l’exécution EVM n’est pas la seule partie que nous devons prouver.Nous devons également prouver le consensus: les parties du système qui gèrent les dépôts, les retraits, les signatures, les mises à jour de l’équilibre des validateurs et d’autres éléments de la section de la preuve Ethereum.

Le consensus est beaucoup plus simple que l’EVM, mais le défi auquel il est confronté est que nous n’avons pas de résumé EVM de la couche 2, c’est pourquoi la plupart du travail doit être fait de toute façon.Par conséquent, toute mise en œuvre du consensus de l’épreuve Ethereum doit être effectuée «à partir de zéro», bien que le système de preuve lui-même soit un travail partagé qui peut y être construit.

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

Une chaîne de balises est définie comme une fonction de transition d’état, tout comme un EVM.La fonction de transfert d’état est déterminée par trois facteurs:

• ECADD (pour la vérification des signatures BLS)

• Appariement (pour la vérification des signatures BLS)

• SHA256 Hash (pour la lecture et la mise à jour du statut)

Dans chaque bloc, nous devons prouver 1-16 BLS12-381 ECADD pour chaque validateur (probablement plus d’un, car la signature peut être incluse dans plusieurs agrégats).Cela peut être compensé par des techniques de pré-ordinateur sous-ensemble, nous pouvons donc dire que chaque validateur est un ECADD BLS12-381.Aujourd’hui, il y a environ 30 000 signatures de validateurs par période.À l’avenir, pour la finalité des machines à sous unique, cela peut changer dans l’une ou l’autre direction(Voir les instructions ici): Si nous prenons la route « forte », chaque créneau peut passer à 1 million de validateurs.Pendant ce temps, avec Orbit SSF, il restera à 32 768, voire réduira à 8,1.

Comment fonctionne l’agrégation BLS.La vérification de la signature agrégée ne nécessite que ECADD pour chaque participant, pas ECMUL.Mais il y a encore beaucoup à prouver à 30 000 ECADD.

Pour l’appariement, il y a actuellement jusqu’à 128 preuves par emplacement, ce qui signifie que 128 paires doivent être vérifiées.Avec EIP-7549 et d’autres changements, cela peut être réduit à 16 par emplacement.Le nombre de paires est faible, mais le coût est extrêmement élevé: chaque paire fonctionne (ou prouve) des milliers de fois plus longue que ECADD.

Un défi majeur dans l’opération BLS12-381 de preuve est le manque de courbes pratiques dont l’ordre de courbe est égal à la taille du champ BLS12-381, ce qui ajoute des frais généraux considérables à tout système de preuve.D’un autre côté, l’arbre Verkle proposé pour Ethereum est construit avec des courbes de Bandersnatch, ce qui fait de BLS12-381 lui-même une courbe naturelle utilisée dans le système de snark pour prouver les branches de Verkle.Une implémentation assez simple peut fournir environ 100 ajouts G1 par seconde;

Pour le hachage SHA256, le pire des cas est le bloc de conversion de l’époque, où l’ensemble de l’arborescence de l’équilibre court validateur et un grand nombre de soldes de validateur sont mis à jour.Validator Balance Balance Arbre Il n’y a qu’un seul octet par validateur, donc environ 1 Mo de données sera remanié.Cela équivaut à 32 768 appels SHA256.Si le solde de mille validateurs est au-dessus ou en dessous du seuil, l’équilibre valide dans l’enregistrement du validateur doit être mis à jour, ce qui correspond à mille branches de Merkle, il peut donc y avoir dix mille hachages.Le mécanisme de mélange nécessite 90 bits par validateur (et donc 11 Mo de données), mais cela peut être calculé à tout moment dans un processus d’époque.Pour la finalité des emplacements uniques, ces nombres peuvent augmenter ou diminuer à nouveau en fonction des détails.Un shuffle devient inutile, bien que la piste puisse rétablir la nécessité d’un shuffle.

Un autre défi est que vous devez lire tous les États validateurs (y compris les clés publiques) pour vérifier le bloc.Pour 1 million de validateurs, plus la succursale de Merkle, 48 millions d’octets sont tenus de lire la clé publique seule.Cela nécessite des millions de hachages par époque.Si nous devons prouver la preuve de la vérification des parties aujourd’hui, une approche réaliste est une forme de calcul vérifiable incrémental: une structure de données distincte est stockée dans le système de preuve optimisé pour des recherches efficaces et fournit les mises à jour de cette structure.

Dans l’ensemble, il y a beaucoup de défis.

La solution la plus efficace à ces défis est susceptible de nécessiter une refonte profonde de la chaîne de balises, qui peut se produire simultanément avec le passage à une finalité à emplacement unique.Les caractéristiques de cette refonte peuvent inclure:

• Changements de fonction de hachage:Aujourd’hui, la fonction de hachage SHA256 « complète » est utilisée, donc en raison du rembourrage, chaque appel correspond à deux appels de fonction compressés sous-jacents.Au moins, nous pouvons obtenir un gain 2x en passant à la fonction de compression SHA256.Si nous utilisons Poséidon à la place, nous pouvons obtenir un gain d’environ 100 fois, ce qui résout complètement tous nos problèmes (au moins pour les hachages): 1,7 million de hachages par seconde (54 Mo) et même « Lire un million de » enregistrements de vérification «  » peuvent le prouver en quelques secondes.

• S’il est en orbite, l’enregistrement du vérificateur perturbé sera stocké directement:Si vous choisissez un certain nombre de validateurs (par exemple 8 192 ou 32 768) comme comité pour un créneau donné, mettez-les directement dans l’État adjacent les uns aux autres afin que le hachage minimum soit tenu de lire toutes les clés publiques de validateur dans la preuve.Cela permettra également de terminer toutes les mises à jour de l’équilibre.

• Agrégation de signature:Tout schéma d’agrégation de signature haute performance impliquera en fait une sorte de preuve récursive, où la preuve intermédiaire du sous-ensemble de signatures sera effectuée par des nœuds individuels dans le réseau.Cela distribue naturellement la charge de preuve sur de nombreux nœuds du réseau, ce qui rend le « prover final » beaucoup moins de travail.

• Autres schémas de signature:Pour les signatures de Lamport + Merkle, nous avons besoin de 256 + 32 hachages pour vérifier la signature;L’optimisation du schéma de signature peut être encore améliorée par un petit facteur constant.Si nous utilisons Poseidon, cela se situe dans le cadre de la preuve dans une seule fente.Mais en réalité, avec un schéma d’agrégation récursif, cela devient plus rapide.

Quelles sont les liens avec la recherche existante?

Concis, Ethereum consensus Proof (Comité synchrone uniquement):https://github.com/sucinctLabs/eth-proffof-sonsensus

Simple, Helios en SP1:https://github.com/sucinctlabs/sp1-helios

Concis BLS12-381 précompilé:https://blog.succinct.xyz/sucincshipsprecompiles/

Vérification de la signature d’agrégation BLS basée sur HALO2:https://ethreear.ch/t/zkpos-with-halo2-pairing-for-verrifiant-ggregate-blls-signatures/14671

Que faut-il faire d’autre et quels compromis doivent être pesés?

En fait, il faudra des années pour obtenir la validité du consensus Ethereum.Il s’agit à peu près du même calendrier que nous devons implémenter une finalité à emplacement unique, des pistes, des modifications des algorithmes de signature et une analyse de sécurité potentielle pour avoir suffisamment de confiance pour utiliser une fonction de hachage « radicale » comme Poseidon.Par conséquent, il est le plus judicieux de résoudre ces autres problèmes et de garder à l’esprit le plus amical lorsqu’ils effectuent ces tâches.

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 Ethereum et une approche plus radicale pour «faire de nombreux changements à la fois».Pour l’EVM, l’approche incrémentielle est logique car elle minimise les dommages à la compatibilité vers l’arrière.Pour la couche de consensus, les problèmes de compatibilité vers l’arrière sont moins problématiques et plus «complets» repenser les différents détails de la façon dont les chaînes de balises sont conçues pour optimiser au mieux la convivialité Snark.

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

STARK Friendly doit être le principal objectif de la refonte à long terme du consensus de la preuve d’Ethereum, notamment une finalité à emplacement unique, une orbite, des changements de schéma de signature et une agrégation de signature.