L'avenir possible du protocole Ethereum (6) : prospérité

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

Prospérité : Objectif clé

• Transformer l'EVM en un "état final" haute performance et stable
• Introduire l'abstraction de compte dans le protocole, permettant à tous les utilisateurs de bénéficier d'un compte plus sécurisé et pratique.
• Optimiser les frais de transaction, améliorer l'évolutivité tout en réduisant les risques
• Explorer la cryptographie avancée pour améliorer significativement Ethereum à long terme

Améliorations de l'EVM

a résolu quel problème ?

L'EVM actuelle est difficile à analyser statiquement, ce qui rend la création d'implémentations efficaces, la validation formelle du code et l'expansion ultérieure difficiles. De plus, l'efficacité de l'EVM est faible, rendant difficile la mise en œuvre de nombreuses formes de cryptographie avancée, à moins qu'un soutien explicite via des précompilés ne soit fourni.

Qu'est-ce que c'est et 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), qui est prévu pour être inclus dans le prochain hard fork. EOF est une série d'EIP, spécifiant une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus significative étant :

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

Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés au profit des anciens contrats (, voire être obligatoirement convertis en code EOF ). Les nouveaux contrats bénéficieront des gains d'efficacité apportés par l'EOF - d'abord grâce à un code byte légèrement réduit par les caractéristiques des sous-programmes, puis grâce aux 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 pour les opérations 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 nouvelle est de combiner EVM-MAX avec la fonctionnalité SIMD (Single Instruction Multiple Data) (, SIMD en tant que concept d'Ethereum existe depuis longtemps, introduit pour la première fois par EIP-616 de Greg Colvin. 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 rend ces deux extensions orientées vers la performance un accord naturel.

Une conception générale d'un EIP combiné commencera par l'EIP-6690, puis :

• Autoriser )i( tout nombre impair ou )ii( toute puissance de 2 ne dépassant pas 2768 comme modulaire
• Pour chaque opcode EVM-MAX ) addition, soustraction, multiplication (, ajoutez une version qui n'utilise plus 3 constantes immédiates x, y, z, mais 7 constantes immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes ont un effet similaire à :

for i in range)count(: mem[z_start + z_skip * count] = op) mem[x_start + x_skip * count], mem[y_start + y_skip * count] (

Dans la mise en œuvre réelle, cela sera traité de manière parallèle.

• Il est possible d'ajouter XOR, AND, OR, NOT et SHIFT) y compris des boucles et des non-boucles(, au moins pour les puissances de 2. Ajoutons également ISZERO) qui poussera la sortie sur la pile principale de l'EVM(, ce qui sera suffisamment puissant pour réaliser la cryptographie à courbe elliptique, la cryptographie à petit domaine) comme Poseidon, Circle STARKs(, les fonctions de hachage traditionnelles) comme SHA256, KECCAK, BLAKE( et la cryptographie basée sur les grilles. D'autres mises à niveau de l'EVM pourraient également être mises en œuvre, mais jusqu'à présent, elles ont reçu moins d'attention.

) Liens de recherche existants

• EOF:
• EVM-MAX:
• SIMD:

le travail restant et les compromis

Actuellement, le plan EOF est intégré dans le prochain hard fork. Bien qu'il soit toujours possible de le retirer à la dernière minute - des fonctionnalités ont été temporairement retirées lors de précédents hard forks, cela représenterait un grand défi. Retirer l'Eof signifierait que toute mise à niveau future de l'EVM devrait être effectuée sans l'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é de l'infrastructure. 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 échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et d'autres avantages. On peut dire que la feuille de route priorisant 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 et 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 effectuer 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 des effets néfastes. De plus, EVM-MAX et SIMD peuvent réduire les coûts en gas de nombreux systèmes de preuves, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de davantage de précompilés par du code EVM pouvant exécuter les mêmes tâches, sans 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

) a résolu quel problème ?

Actuellement, les transactions ne peuvent être vérifiées que par une seule méthode : la signature ECDSA. À l'origine, l'abstraction des comptes visait à dépasser 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ésistante aux quantum
• Faire tourner les anciennes clés ### est largement considéré comme une pratique de sécurité recommandée (
• Portefeuille multisignature et portefeuille de récupération sociale
• Utiliser une clé pour des opérations de faible valeur, utiliser une autre clé ) ou un groupe de clés ( pour des opérations de grande valeur

Permettre aux protocoles de confidentialité de fonctionner sans relais, réduisant ainsi considérablement leur complexité et éliminant un point de dépendance central clé.

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

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

MPC) le calcul multipartite ( est une technologie existante depuis 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 une signature, sans avoir à combiner directement ces parties de clé.

EIP-7702 est une proposition prévue pour être introduite dans le prochain hard fork. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir des commodités d'abstraction de compte au bénéfice de tous les utilisateurs ), y compris les utilisateurs EOA (. Elle vise à améliorer l'expérience de tous les utilisateurs à court terme et à éviter la division en deux écosystèmes.

Ce travail a commencé par l'EIP-3074 et a finalement abouti à l'EIP-7702. L'EIP-7702 offre les "fonctionnalités pratiques" de l'abstraction de compte à tous les utilisateurs, y compris les comptes EOA) externes contrôlés par une signature ECDSA, c'est-à-dire les comptes (.

Bien que certains défis ), en particulier le défi de la "commodité" (, puissent être résolus par des technologies progressives telles que le calcul multipartite ou l'EIP-7702, l'objectif principal de sécurité du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant en arrière et en résolvant le problème d'origine : permettre au code des contrats intelligents de contrôler la validation des transactions. La raison pour laquelle cela n'a pas encore été réalisé réside dans la mise en œuvre sécurisée, ce qui représente un défi.

![Vitalik sur le futur possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.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é provient de la manière de réaliser cela d'une manière qui soit amicale pour le maintien d'un réseau décentralisé et de prévenir les attaques par déni de service.

Un défi clé typique est le problème de multiples défaillances:

Si 1000 fonctions de validation de comptes dépendent 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 qui inverse 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 faible, 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 le risque de déni de service ### DoS (, une solution a finalement été trouvée pour réaliser "l'abstraction idéale des comptes": ERC-4337.

Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : validation et exécution. Toutes les validations sont d'abord traitées, puis toutes les exécutions. Dans la mémoire, une opération d'utilisateur n'est acceptée que lorsque la phase de validation n'implique que son propre compte et ne lit pas les variables d'environnement. Cela permet de prévenir les attaques par double défaillance. De plus, des limites de gas strictes sont également imposées à l'étape de validation.

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

Deux raisons clés sont les suivantes :

1. EntryPoint en tant qu'inefficacité inhérente du contrat : 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 attributs Ethereum : comme garanti par la liste créée, le transfert doit être effectué vers les utilisateurs abstraits de compte.

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

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

• Agence de paiement ) Paymasters ( : permet à un compte de payer des frais au nom d'un autre compte, ce qui enfreint la règle selon laquelle seule le compte de l'expéditeur peut être accessible pendant la phase de validation, c'est pourquoi un traitement spécial a été introduit pour garantir la sécurité du mécanisme d'agence de paiement.
• Agrégateur ) Agrégateurs ( : prend en charge la fonction d'agrégation de signatures, comme l'agrégation BLS ou l'agrégation basée sur SNARK. Cela est nécessaire pour réaliser l'efficacité maximale des données sur Rollup.

) 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) écrit dans le protocole d'abstraction de compte (:
• EIP-7701) basé sur le protocole d'écriture EOF abstraction de compte (:

) Le travail restant et les compromis

Actuellement, le principal défi consiste à savoir comment introduire 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.