L'avenir possible du protocole Ethereum ( six ) : The Splurge

Dans la conception du protocole Ethereum, de nombreux "détails" sont cruciaux pour son succès. En fait, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, tandis que le reste est constitué de divers sujets de niche, c'est là que réside le sens de "prospérité".

Prospérité: objectif clé

• Transformer l'EVM en un "état final" performant et stable
• Introduire l'abstraction de compte dans le protocole, permettant à tous les utilisateurs de bénéficier d'un compte plus sûr et plus pratique.
• Optimiser les frais de transaction économiques, améliorer la scalabilité tout en réduisant les risques
• Explorer la cryptographie avancée, permettant à Ethereum de s'améliorer de manière significative à long terme.

amélioration EVM

Quel problème a été résolu?

Actuellement, l'EVM est difficile à analyser statiquement, ce qui rend la création d'implémentations efficaces, la vérification formelle du code et l'expansion ultérieure difficiles. De plus, l'efficacité de l'EVM est faible, rendant difficile la réalisation de nombreuses formes de cryptographie avancée, sauf par un support explicite via des précompilations.

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

La première étape de la feuille de route d'amélioration de l'EVM actuelle est le format d'objet EVM (EOF), prévu pour être inclus dans le prochain hard fork. EOF est une série d'EIP, qui spécifie une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus notable étant :

• Le code ( est exécutable, mais il est impossible de lire ) depuis l'EVM et les données ( peuvent être lues, mais ne peuvent pas exécuter ).
• Interdiction des sauts dynamiques, seuls les sauts statiques sont autorisés
• Le code EVM ne peut plus observer les informations liées au combustible.
• Ajout d'un nouveau mécanisme de sous-routine explicite

Les contrats anciens continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement obsolètes, même être forcés de se convertir en code EOF (. Les nouveaux contrats bénéficieront des gains d'efficacité apportés par l'Eof - d'abord grâce à un bytecode légèrement réduit par la fonctionnalité de sous-routine, puis par les nouvelles fonctionnalités spécifiques à l'Eof ou la réduction des coûts en gas.

Après l'introduction de l'EOF, les mises à niveau ultérieures sont devenues plus faciles. Le développement le plus avancé est l'extension arithmétique du module EVM ) EVM-MAX (. EVM-MAX crée un ensemble de nouvelles opérations spécifiquement conçues pour l'opération modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui rend possible l'utilisation d'optimisations telles que la multiplication de Montgomery.

Une idée relativement récente est de combiner EVM-MAX avec la fonctionnalité SIMD (Single Instruction Multiple Data) ), SIMD étant un concept d'Ethereum qui existe depuis longtemps, proposé pour la première fois par Greg Colvin dans l'EIP-616. SIMD peut être utilisé pour accélérer de nombreuses formes de cryptographie, y compris les fonctions de hachage, les STARKs de 32 bits et la cryptographie basée sur les réseaux, la combinaison d'EVM-MAX et de SIMD faisant de ces deux extensions orientées vers la performance un couple naturel.

(# Liens de recherche existants

• EOF:
• EVM-MAX:
• SIMD:

)# Le travail restant et les compromis

Actuellement, EOF est prévu pour être inclus dans le prochain hard fork. Bien qu'il soit toujours possible de l'enlever à la dernière minute - des fonctionnalités ont été temporairement retirées lors de précédents hard forks, le faire poserait cependant de grands défis. Retirer EOF signifie que toute mise à niveau future de l'EVM devra se faire sans EOF, bien que cela soit faisable, cela pourrait être plus difficile.

Le principal compromis de l'EVM réside dans la complexité de L1 et la complexité des infrastructures. L'EOF nécessite l'ajout d'un grand nombre de lignes de code à l'implémentation de l'EVM, et l'analyse statique du code est également relativement complexe. Cependant, en contrepartie, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et bénéficier d'autres avantages. On peut dire que la feuille de route pour l'amélioration continue de l'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.

Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX avec SIMD et de réaliser des tests de référence sur la consommation de gas des différentes opérations cryptographiques.

Comment interagir avec les autres parties de la feuille de route ?

L1 ajuste son EVM pour que L2 puisse également procéder à des ajustements correspondants plus facilement. Si les deux ne s'ajustent pas de manière synchronisée, cela pourrait entraîner des incompatibilités et avoir des effets néfastes. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de nombreuses précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact significatif sur l'efficacité.

![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###

( abstraction de compte

)# Quel problème a été résolu ?

Actuellement, les transactions ne peuvent être vérifiées que par un seul moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de cela, permettant à la logique de vérification des comptes d'être n'importe quel code EVM. Cela peut activer une série d'applications :

• Passer à la cryptographie résistant aux quantiques
• Le remplacement des anciennes clés ### est largement considéré comme une pratique de sécurité recommandée ###
• Portefeuille multi-signature et portefeuille de récupération sociale
• Utiliser une clé pour des opérations de faible valeur, utiliser une autre clé ( ou un ensemble de clés ) pour des opérations de haute valeur.

Permettre au protocole de confidentialité de fonctionner sans relais, réduisant ainsi considérablement sa complexité et éliminant un point de dépendance central clé.

Depuis que l'abstraction de compte a été proposée en 2015, son objectif s'est également élargi pour inclure un grand nombre de "cibles de commodité", par exemple, un compte qui n'a pas d'ETH mais qui possède quelques ERC20 pourrait payer le gaz avec des ERC20.

MPC( le calcul multipartite ) est une technologie vieille de 40 ans, utilisée pour diviser une clé en plusieurs parties et les stocker sur plusieurs appareils, en utilisant des techniques cryptographiques pour générer des signatures sans avoir à combiner directement ces parties de clé.

EIP-7702 est une proposition prévue pour être introduite dans la prochaine fourche dure. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une abstraction de compte pour bénéficier à tous les utilisateurs (, y compris les utilisateurs EOA ). L'objectif est d'améliorer l'expérience de tous les utilisateurs à court terme et d'éviter la division en deux écosystèmes.

Ce travail a commencé avec l'EIP-3074 et a finalement abouti à l'EIP-7702. L'EIP-7702 fournit la "fonctionnalité pratique" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes détenus aujourd'hui, c'est-à-dire les comptes contrôlés par des signatures ECDSA (.

![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(

)# Qu'est-ce que c'est, comment ça fonctionne?

Le cœur de l'abstraction de compte est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité vient de la manière de réaliser cela d'une manière qui favorise le maintien d'un réseau décentralisé et protège contre les attaques par déni de service.

Un défi clé typique est le problème de défaillance multiple :

Si la fonction de validation de 1000 comptes dépend d'une seule valeur S, et que la valeur actuelle S rend toutes les transactions dans le pool de mémoire valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans le pool de mémoire invalides. Cela permet à un attaquant d'envoyer des transactions indésirables au pool de mémoire à un coût très bas, bloquant ainsi les ressources des nœuds du réseau.

Après des années d'efforts, visant à étendre les fonctionnalités tout en limitant les risques de déni de service ( DoS ), une solution pour réaliser "l'abstraction idéale des comptes" a finalement été trouvée : ERC-4337.

Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : vérification et exécution. Toute vérification est d'abord traitée, suivie de l'exécution. Dans la mempool, une opération utilisateur n'est acceptée que si la phase de vérification n'implique que son propre compte et ne lit pas les variables d'environnement. Cela permet de prévenir les attaques de double dépense. De plus, des limites strictes de gas sont également appliquées à l'étape de vérification.

ERC-4337 a été conçu comme une norme de protocole supplémentaire ###ERC(, car à l'époque, les développeurs de clients Ethereum étaient concentrés sur la fusion )Merge(, sans énergie supplémentaire pour traiter d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise des objets appelés opérations utilisateur, plutôt que des transactions conventionnelles. Cependant, nous avons récemment réalisé qu'il était nécessaire d'intégrer au moins une partie de cela dans le protocole.

Les deux raisons clés sont les suivantes :

1. EntryPoint comme inefficacité inhérente des contrats : chaque bundle a un coût fixe d'environ 100 000 gas, ainsi que des milliers de gas supplémentaires pour chaque opération utilisateur.
2. Assurer la nécessité des propriétés d'Ethereum : comme la liste incluse qui crée des garanties nécessitant un transfert vers des utilisateurs de compte abstrait.

De plus, l'ERC-4337 a également étendu deux fonctionnalités :

• Agents de paiement ) Paymasters ( : permet à un compte de payer des frais au nom d'un autre compte, ce qui enfreint la règle selon laquelle la phase de validation ne peut accéder qu'au compte de l'expéditeur lui-même. Par conséquent, un traitement spécial a été introduit pour garantir la sécurité du mécanisme d'agent de paiement.
• Agrégateur ) Agrégateurs ( : prend en charge des fonctionnalités d'agrégation de signatures, telles que l'agrégation BLS ou l'agrégation basée sur SNARK. Cela est nécessaire pour réaliser la meilleure efficacité des données sur Rollup.

![Vitalik sur le futur possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(

)# Lien de recherche existant

• Discours sur l'histoire de l'abstraction de compte:
• ERC-4337:
• EIP-7702:
• Le code BLSWallet ( utilise la fonction d'agrégation ) :
• EIP-7562### écriture du protocole d'abstraction de compte (:
• EIP-7701) compte abstrait d'écriture basé sur le protocole EOF (:

)# Le travail restant et les compromis

Actuellement, le principal défi est de savoir comment intégrer complètement l'abstraction de compte dans le protocole. Le récent EIP d'abstraction de compte, qui a gagné en popularité, est l'EIP-7701, cette proposition met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une section de code distincte pour la vérification. Si le compte a cette section de code définie, ce code sera exécuté lors de l'étape de vérification des transactions provenant de ce compte.

Le charme de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction des comptes locaux :

1. Intégrer EIP-4337 comme partie du protocole
2. Un nouveau type d'EOA, où l'algorithme de signature est l'exécution de code EVM.

Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la période de validation - en n'autorisant pas l'accès à des états externes, et même avec une limite de gas initialement fixée si basse qu'elle est invalide pour des applications résistantes aux quantiques ou de protection de la vie privée - alors la sécurité de cette approche est très claire : il s'agit simplement de remplacer la vérification ECDSA par une exécution de code EVM nécessitant un temps similaire.

Cependant, avec le temps, nous devons assouplir ces limites, car il est très important de permettre aux applications de protection de la vie privée de fonctionner sans relais, ainsi que d'avoir une résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de traiter les risques de déni de service (DoS), sans exiger que les étapes de vérification doivent être extrêmement simplistes.

Le principal compromis semble être "écrire rapidement une solution qui satisfait moins de personnes" contre "attendre plus longtemps pour peut-être obtenir une solution plus idéale", la méthode idéale pourrait être une sorte d'approche mixte. Une approche mixte consisterait à écrire plus rapidement certains cas d'utilisation et à consacrer plus de temps à explorer d'autres cas d'utilisation. Une autre méthode serait de déployer d'abord une version d'abstraction de compte plus ambitieuse sur L2. Cependant, le défi auquel cela fait face est que l'équipe L2 doit avoir confiance dans le travail de la proposition d'adoption pour être prête à la mettre en œuvre, surtout pour s'assurer que L1 et/ou d'autres L2 pourront adopter des solutions compatibles à l'avenir.

Nous devons également prendre en compte une autre application importante, qui est le compte de stockage de clés, ce