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

La conception du protocole Ethereum comporte de nombreux "détails" qui 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 le reste est constitué de divers sujets de niche, c'est ce que signifie "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ûr et pratique.
• Optimiser les frais de transaction économiques, améliorer la scalabilité tout en réduisant les risques
• Explorer la cryptographie avancée, pour améliorer significativement Ethereum à long terme.

Amélioration de l'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 validation formelle du code et l'extension ultérieure difficiles. De plus, l'EVM est peu efficace et il est difficile de réaliser de nombreuses formes de cryptographie avancée, sauf par le biais d'un soutien explicite par précompilation.

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

La première étape de la feuille de route d'amélioration d'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 remarquable étant :

• Le code ( est exécutable, mais il est impossible de lire ) à partir de l'EVM et les données ( peuvent être lues, mais il est impossible d'exécuter la séparation entre ).
• Interdiction de redirection dynamique, uniquement les redirections statiques autorisées
• Le code EVM ne peut plus observer d'informations liées au combustible
• 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, et même éventuellement convertis en code EOF (. Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par l'Eof - d'abord grâce à un bytecode légèrement réduit grâce aux fonctionnalités de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à l'Eof ou à la réduction des coûts de 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écialement conçues pour les calculs de reste et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet d'utiliser des optimisations telles que la multiplication de Montgomery.

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

Une idée relativement nouvelle est de combiner EVM-MAX avec la caractéristique SIMD (Single Instruction Multiple Data) ). SIMD, qui est un concept d'Ethereum, existe depuis longtemps, ayant été 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 32 bits et la cryptographie basée sur les réseaux, et la combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers la performance un couple naturel.

Un design général d'un ensemble d'EIP commencera par l'EIP-6690, puis :

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

python 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 les boucles et les non-boucles), au moins pour les puissances de 2. En même temps, ajouter ISZERO( poussera la sortie vers la pile principale EVM), ce qui sera suffisamment puissant pour réaliser la cryptographie à courbe elliptique, la cryptographie sur petits domaines( 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 EVM pourraient également être mises en œuvre, mais jusqu'à présent, elles ont suscité moins d'attention.

(# Le travail restant et les compromis

Actuellement, le plan est d'inclure EOF 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, le faire poserait néanmoins de grands défis. Retirer EOF signifierait que toute mise à niveau future de l'EVM devrait 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 d'autres avantages. On peut dire que la feuille de route qui privilégie l'amélioration continue de l'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.

Une tâche importante à réaliser est de mettre en œuvre 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 s'adapter plus facilement ; si les deux ne s'ajustent pas de manière synchronisée, cela pourrait entraîner des incompatibilités et avoir des conséquences néfastes. De plus, EVM-MAX et SIMD peuvent réduire les coûts en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela rend également plus facile le remplacement de nombreuses précompilations par du code EVM pouvant exécuter les mêmes tâches, sans que cela n'affecte significativement 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 une méthode : la signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de cela, permettant à la logique de vérification du compte d'être n'importe quel code EVM. Cela peut activer une série d'applications :

• Passer à la cryptographie résistante aux quantiques
• Le remplacement de l'ancienne clé ### est largement considéré comme une pratique de sécurité recommandée ###
• Portefeuille à signatures multiples 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 grande 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 des comptes a été proposée en 2015, son objectif s'est également étendu à de nombreux "objectifs de commodité", par exemple, un compte sans ETH mais possédant quelques ERC20 peut utiliser des ERC20 pour payer le gas.

MPC( le calcul multipartite ) est une technologie qui a 40 ans d'histoire, 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és.

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 concernant la fourniture de commodités d'abstraction de compte au bénéfice de tous les utilisateurs (, y compris les utilisateurs EOA ), visant à améliorer l'expérience de tous les utilisateurs à court terme et à é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 offre les "fonctionnalités pratiques" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes détenus aujourd'hui, EOA(, c'est-à-dire des comptes contrôlés par une signature ECDSA ).

Bien que certains défis (, notamment 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 de sécurité principal du projet d'abstraction de compte ne peut être atteint qu'en revenant sur 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é est la mise en œuvre sécurisée, ce qui constitue un défi.

(# 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 mise en œuvre de cela d'une manière qui soit amicale envers le maintien d'un réseau décentralisé et qui se protège contre les attaques par déni de service.

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

Si la fonction de validation de 1000 comptes dépend d'une valeur unique S, et que la valeur actuelle S rend toutes les transactions dans la mémoire tampon valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans la mémoire tampon invalides. Cela permet à un attaquant d'envoyer des transactions indésirables à la mémoire tampon à 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 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 : validation et exécution. Toutes les validations sont traitées en premier, puis toutes les exécutions sont traitées. Dans la mémoire tampon, une opération de l'utilisateur n'est acceptée que si la phase de validation n'implique que son propre compte et ne lit pas les variables d'environnement. Cela permet d'éviter les attaques par invalidation multiple. De plus, des limites strictes de gaz sont également imposées à l'étape de validation.

ERC-4337 a été conçu comme un standard 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 gérer d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise des objets appelés opérations utilisateur, plutôt que des 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 au 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 la liste incluse créée, la garantie de transfert doit être effectuée vers un utilisateur abstrait du compte.

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 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'agence de paiement.
• 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 l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(

)# Le travail restant et les compromis

Actuellement, le principal défi consiste à savoir comment intégrer complètement l'abstraction de compte dans le protocole. Le protocole d'abstraction de compte récemment populaire est l'EIP-7701, qui met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une section de code distincte pour la validation. Si un compte a défini cette section de code, ce code sera exécuté lors de l'étape de validation 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 de compte local :

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

Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la validation - interdisant l'accès à l'état externe, même la limite de gas fixée au départ étant si basse qu'elle rendrait les applications de résistance quantique ou de protection de la vie privée non valables - alors la sécurité de cette approche est très claire : il suffit de remplacer la validation 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'assurer la résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de résoudre les risques de déni de service ( DoS ), sans exiger que les étapes de validation doivent être extrêmement simples.