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

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" 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 plus pratique.
• Optimiser l'économie des frais de transaction, améliorer la scalabilité tout en réduisant les risques
• Explorer des cryptographies avancées pour améliorer de manière significative 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 vérification formelle du code et l'extension 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, sauf support explicite par des précompilations.

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 d'ê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 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 ) entre la séparation.
• Interdiction de redirection dynamique, seule la redirection statique est autorisée
• 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, et les anciens contrats ( pourraient même être contraints 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 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 en gas.

Après l'introduction d'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, initialement proposé par l'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 32 bits et la cryptographie basée sur des réseaux, la combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers la performance un appariement 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 n'excédant 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 utilise 7 constantes immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes agissent 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 comme moduli. En même temps, ajouter ISZERO) poussera les sorties vers la pile principale de l'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 réseaux. D'autres mises à jour de l'EVM peuvent également être réalisées, mais jusqu'à présent, elles ont reçu moins d'attention.

)# Lien de recherche existant

• 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 représenterait un grand défi. Retirer EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit possible, 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 la vérification 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 privilégiant 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 faire des tests de performance sur la consommation de gaz 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 avoir des conséquences négatives. 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 d'un plus grand nombre de précompilés par du code EVM pouvant exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact significatif sur l'efficacité.

![Vitalik sur le futur possible d'Ethereum (six) : 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 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 permettre une gamme d'applications :

• Passer à la cryptographie post-quantique
• Le remplacement de l'ancienne clé ### est largement considéré comme une pratique de sécurité recommandée (
• Portefeuille multi-signature et portefeuille de récupération sociale
• Utilisez une clé pour des opérations de faible valeur, utilisez une autre clé ) ou un ensemble de clés ( pour des opérations de haute 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 de compte a été proposée en 2015, son objectif s'est également élargi pour inclure de nombreux "objectifs pratiques", par exemple, un compte n'ayant pas d'ETH mais possédant des ERC20 pourrait utiliser des ERC20 pour payer le gaz.

MPC) le calcul multipartite ( est une technologie qui existe depuis 40 ans, utilisée pour diviser une clé en plusieurs parties et les stocker sur plusieurs dispositifs, 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 (, et vise à améliorer l'expérience de tous les utilisateurs à court terme, tout en évitant une division en deux écosystèmes.

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

Bien que certains défis ), en particulier les défis de "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 sur le problème d'origine : permettre au code de contrat intelligent 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 constitue un défi.

(# Qu'est-ce que c'est et comment ça fonctionne ?

Le noyau 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 dont cela est réalisé d'une manière favorable à l'entretien d'un réseau décentralisé et de la prévention des 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 seule valeur S, et que la valeur S actuelle rend toutes les transactions dans le pool de mémoire valides, alors une seule transaction inversant la valeur S pourrait rendre toutes les autres transactions dans le pool de mémoire invalides. Cela permettrait à 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 les risques de déni de service )DoS###, la 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 : la vérification et l'exécution. Toutes les vérifications sont d'abord traitées, suivies de toutes les exécutions. Dans la mémoire tampon, seules les opérations des utilisateurs dont la phase de vérification n'implique que leur propre compte et ne lit pas les variables d'environnement sont acceptées. Cela peut prévenir les attaques par échec multiple. De plus, des limites strictes de gas sont également imposées à l'étape de vérification.

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), n'ayant pas d'énergie supplémentaire pour gérer d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise un objet appelé opération 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 son contenu dans le protocole.

Les 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 d'Ethereum : comme le transfert de garantie créé par la liste doit être transféré au compte abstrait de l'utilisateur.

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, d'où l'introduction d'un traitement spécial 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 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( compte abstrait d'écriture basé sur EOF protocole ) :

(# Le travail restant et les compromis

Actuellement, le principal problème à résoudre est 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 réalise l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une section de code distincte pour la validation. Si le compte a défini cette section de code, celle-ci sera exécutée lors de l'étape de validation des transactions en provenance de ce compte.

Cette méthode de