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

La conception du protocole Ethereum contient de nombreux "détails" importants qui sont cruciaux pour son succès. En réalité, environ la moitié du contenu concerne différents types d'améliorations 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" hautement 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, améliorer l'évolutivité 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 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, rendant difficile la mise en œuvre 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, spécifiant 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 il est impossible d'exécuter ).
• 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 même contraints de se convertir en code EOF (. Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par l'EOF - d'abord par un code byte légèrement réduit grâce aux 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 deviennent plus faciles. Le développement le plus avancé actuellement est l'extension arithmétique du module EVM ) EVM-MAX (. EVM-MAX crée un ensemble de nouvelles opérations spécifiquement pour les calculs modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet 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 en tant que concept d'Ethereum 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 32 bits et la cryptographie basée sur les grilles. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions axées sur la performance un accord naturel.

Une conception générale 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 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 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 de l'EVM), ce qui sera suffisamment puissant pour réaliser la cryptographie à courbe elliptique, la cryptographie de 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 réalisées, mais jusqu'à présent, elles ont reçu moins d'attention.

(# Le travail restant et les compromis

Actuellement, le protocole 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 - certaines fonctionnalités ont été temporairement retirées lors de précédents hard forks, cela représentera cependant un grand défi. Retirer le protocole EOF signifie que toute mise à niveau future de l'EVM devra se faire sans le protocole EOF, ce qui est réalisable, mais pourrait être plus difficile.

Le principal compromis de l'EVM réside dans la complexité de L1 et celle de l'infrastructure. L'EOF nécessite l'ajout d'un grand nombre de codes à 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 d'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 procéder à des tests de performance 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 permettre à L2 d'effectuer des ajustements correspondants plus facilement. Si les deux ne sont pas synchronisés, 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 preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de plus 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 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 de manière : signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de cela, en permettant à la logique de vérification des comptes d'être tout code EVM arbitraire. Cela peut activer une série d'applications :

• Passer à la cryptographie post-quantique
• Le remplacement des anciennes clés ### est largement considéré comme une pratique de sécurité recommandée ###
• Portefeuille multi-signatures 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 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 de nombreux "objectifs pratiques", par exemple, un compte sans ETH mais possédant quelques ERC20 pourrait utiliser des ERC20 pour payer le gas.

(# 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 pour le maintien d'un réseau décentralisé et qui 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 1000 fonctions de validation de comptes dépendent d'une seule valeur S, et que la valeur S actuelle rend toutes les transactions dans la mémoire tampon valides, alors une transaction unique 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 le risque de déni de service ) DoS ###, une solution a finalement été trouvée pour réaliser "l'abstraction de compte idéale" : ERC-4337.

Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : la validation et l'exécution. Toutes les validations sont d'abord traitées, toutes les exécutions sont ensuite traitées. Dans la mémoire tampon, les opérations des utilisateurs ne sont acceptées que lorsque l'étape de validation n'implique que leur propre compte et ne lit pas les variables d'environnement. Cela permet de prévenir les attaques par défaillance multiple. De plus, des limites strictes de gas 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 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 plusieurs milliers de gas supplémentaires pour chaque opération utilisateur.
2. Assurer la nécessité des attributs Ethereum : comme le transfert de garantie créé par la liste d'inclusion qui doit être transféré à l'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, d'où l'introduction d'un traitement spécial pour garantir la sécurité du mécanisme d'agence de paiement.
• Agrégateur ( Agrégateurs ) : prend en charge la fonction d'agrégation des signatures, comme l'agrégation BLS ou l'agrégation basée sur SNARK. Cela est nécessaire pour atteindre l'efficacité maximale des données sur Rollup.

(# 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 EIP-7701, qui a gagné en popularité, met en œuvre cette abstraction au-dessus de l'EOF. Un compte peut avoir une section de code distincte pour la validation ; si cette section de code est définie pour le compte, elle sera exécutée 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 montre clairement les deux perspectives équivalentes de l'abstraction de compte local :

1. Intégrer EIP-4337 en tant que partie du protocole
2. Un nouveau type d'EOA, où 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 vérification - en interdisant l'accès à l'état externe, même les limites de gaz initialement définies étant si basses qu'elles deviennent inefficaces pour les 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 l'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 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 validation soient extrêmement simplistes.

Le principal compromis semble être "écrire rapidement un plan 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 consiste à écrire plus rapidement certains cas d'utilisation et à laisser plus de temps pour explorer d'autres cas d'utilisation. Une autre méthode consiste à 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 une grande confiance dans le travail proposé pour être prête à l'implémenter, surtout pour s'assurer que L1 et/ou d'autres L2 pourront adopter des solutions compatibles à l'avenir.

Une autre application que nous devons également considérer est le compte de stockage de clés, qui stocke l'état associé au compte sur L1 ou sur un L2 dédié, mais peut être utilisé sur L1 et sur tout L2 compatible. Pour y parvenir efficacement, il se peut que le L2 doive prendre en charge des fonctions telles que L1SLOAD ou REMOTESTATI.