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

Rédigé par : Vitalik Buterin

Certaines choses sont difficiles à classer dans une seule catégorie. Dans la conception du protocole Ethereum, de nombreux "détails" sont très importants pour le succès d'Ethereum. 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 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 les frais de transaction économiques, améliorer la scalabilité tout en réduisant les risques
• Explorer la cryptographie avancée 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 difficile la création d'implémentations efficaces, la vérification formelle du code et l'expansion ultérieure. De plus, l'efficacité de l'EVM est faible, et il est difficile de mettre en œuvre de nombreuses formes de cryptographie avancée, sauf avec un support explicite par 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. L'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 :

• La séparation entre le code (exécutable, mais non lisible depuis l'EVM) et les données (lisibles, mais non exécutables)
• Interdiction de redirection dynamique, seule la redirection statique est autorisée
• Le code EVM ne peut plus observer d'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 (voire convertis de force 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 les caractéristiques de sous-routine, puis par de nouvelles fonctionnalités spécifiques à l'Eof ou des coûts en gas réduits.

Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles. Le développement le plus abouti à ce jour 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 qui ne peut pas être accédé par d'autres codes d'opération, ce qui rend possible l'utilisation d'optimisations telles que la multiplication de Montgomery.

Une idée plus récente est de combiner EVM-MAX avec les caractéristiques de 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, et la combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers la performance un couplage naturel.

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

• Autoriser (i) tout 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 utilise 7 constantes immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes fonctionnent de manière 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 pourrait ajouter XOR, AND, OR, NOT et SHIFT (y compris cyclique et non cyclique), au moins pour les puissances de 2 comme mod. En même temps, ajouter ISZERO (qui 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 réseaux. D'autres mises à niveau 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, 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 fonctions ont été temporairement retirées lors de précédents hard forks, cela poserait 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é de l'infrastructure. L'EOF nécessite l'ajout d'une grande quantité de code à l'implémentation de l'EVM, et la vérification de code statique 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.

Une tâche importante à réaliser est de mettre en œuvre des fonctionnalités similaires à EVM-MAX avec SIMD et de procéder à 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 afin que L2 puisse également s'ajuster plus facilement. Si les deux ne sont pas synchronisés, cela peut 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 plus de précompilés par du code EVM capable d'exécuter les mêmes tâches, ce qui n'aura probablement pas un impact significatif sur l'efficacité.

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 à dépasser cela, permettant à la logique de vérification des comptes d'être n'importe quel code EVM. Cela pourrait activer une série d'applications :

• Passer à la cryptographie post-quantique
• Rotation des anciennes clés (largement considéré comme une pratique de sécurité recommandée)
• Portefeuille multi-signatures 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 intermédiaire, réduisant ainsi considérablement sa complexité et éliminant un point de dépendance central clé.

Depuis la proposition de l'abstraction des comptes 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 des ERC20 pourrait payer les frais de gas avec des ERC20. Voici un tableau récapitulatif de ces objectifs :

MPC (calcul multipartite) est une technologie qui a 40 ans d'histoire, utilisée pour diviser les clés en plusieurs parties et les stocker sur plusieurs appareils, en utilisant des techniques cryptographiques pour générer des signatures, sans avoir besoin de 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 reconnaissance croissante de la nécessité de fournir une commodité 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 EOA d'aujourd'hui (comptes externes détenus, c'est-à-dire des comptes contrôlés par des signatures ECDSA).

On peut voir sur le graphique que, 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, le principal objectif de sécurité du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant sur le problème original : 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.

Qu'est-ce que c'est et 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 façon de réaliser cela d'une manière qui préserve la convivialité 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 défaillance multiple :

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 la mémoire tampon valides, alors une unique transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans la mémoire tampon invalides. Cela permettrait à 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 d'attaque par 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 phases : validation et exécution. Toutes les validations sont d'abord traitées, puis toutes les exécutions sont traitées ensuite. Dans la mémoire tampon, une opération d'utilisateur ne sera acceptée que si la phase de validation n'implique que son propre compte et ne lit pas les variables d'environnement. Cela peut empêcher les attaques par échec multiple. De plus, des limites strictes de gas 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 traiter d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise un objet appelé opération utilisateur, plutôt que des transactions conventionnelles. Cependant, nous avons récemment 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 du contrat : chaque bundle a un coût fixe d'environ 100 000 gas, ainsi que plusieurs milliers de gas supplémentaires pour chaque opération utilisateur.
2. Assurer la nécessité des attributs Ethereum : comme les garanties créées par la liste doivent être transférées au compte d'utilisateur abstrait.

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

• Agents de paiement (Paymasters) : permettent à 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 de traitements spéciaux pour garantir la sécurité du mécanisme d'agent de paiement.
• Agrégateurs (Aggregators) : 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 la meilleure efficacité des données sur Rollup.

Liens de recherche existants

• Discours sur l'histoire de l'abstraction des comptes :
• ERC-4337 :
• EIP-7702：
• Code BLSWallet (utilisant la fonction d'agrégation) :
• EIP-7562 (abstraction de compte pour le protocole d'écriture) :
• EIP-7701 (protocole d'abstraction de compte basé sur EOF) :