Possibles directions de développement futur du protocole Ethereum : Épanouissement

Dans le 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 EVM, le reste étant 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 économiques, améliorer l'évolutivité tout en réduisant les risques
• Explorer la cryptographie avancée, permettant à Ethereum de s'améliorer considérablement à 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 si un support explicite est fourni par des précompilés.

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 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 explicite de sous-routine

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 améliorations d'efficacité apportées par l'Eof - d'abord grâce à un code de byte légèrement réduit par les caractéristiques 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écifiquement pour le calcul modulaire 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 plus 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 réseaux. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers la performance un couple naturel.

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

)# 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 le retirer à 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 signifie que toute mise à niveau future de l'EVM devra 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é du 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 les vérifications de code statique sont également relativement complexes. Cependant, en échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et bénéficier d'autres avantages. On peut dire que la feuille de route pour l'amélioration continue de l'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.

Un travail important à réaliser est de mettre en œuvre des fonctionnalités similaires à EVM-MAX et SIMD, et de réaliser 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 afin que L2 puisse également s'ajuster plus facilement. Si les deux ne s'ajustent pas de manière synchrone, cela pourrait entraîner des incompatibilités et des impacts négatifs. 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 rend également plus facile le remplacement de davantage de précompilations par du code EVM capable d'exécuter les mêmes tâches, sans que cela n'affecte considérablement l'efficacité.

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

) abstraction de compte

Quel problème a été résolu ?

Actuellement, les transactions ne peuvent être vérifiées que de cette manière : signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de cela, permettant à la logique de vérification du compte d'être un code EVM arbitraire. Cela peut activer une série d'applications :

• Passer à la cryptographie résistant aux quantiques
• 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 grande 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 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 sans ETH mais possédant quelques ERC20 pourrait utiliser des ERC20 pour payer les frais de gaz.

)# 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 mise en œuvre de cela d'une manière qui favorise le maintien d'un réseau décentralisé et prévient les attaques par déni de service.

Un défi clé typique est le problème de 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 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 dans le 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 de compte idéale" a finalement été trouvée : ERC-4337.

Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : vérification et exécution. Toutes les vérifications 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 la phase de vérification n'implique que leur propre compte et ne lit pas les variables d'environnement. Cela permet de 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( 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, plutôt que des transactions conventionnelles. Cependant, récemment, nous avons pris conscience de la nécessité d'incorporer 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 Ethereum : comme l'exige la liste, la garantie de transfert doit être effectuée vers l'utilisateur abstrait du compte.

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. Par conséquent, un traitement spécial a été introduit pour garantir la sécurité du mécanisme d'agent 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 l'efficacité maximale des données sur Rollup.

(# Liens de recherche existants

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

(# Le travail restant et les compromis

Actuellement, le principal défi est de savoir comment intégrer complètement l'abstraction des comptes dans le protocole. Le récent EIP sur l'abstraction des comptes, EIP-7701, a gagné en popularité et met en œuvre l'abstraction des comptes au-dessus de l'EOF. Un compte peut avoir une section de code distincte pour la vérification ; si ce code est défini pour le compte, il sera exécuté lors de l'étape de vérification des transactions provenant de ce compte.

L'attrait de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction des comptes locaux :

1. Intégrer l'EIP-4337 comme 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 une limite stricte à la complexité du code exécutable pendant la validation - n'autorisant pas l'accès à l'état externe, même les limites de gaz initialement définies étant si basses qu'elles sont inefficaces pour les applications de résistance quantique 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 validation ECDSA par une exécution de code EVM nécessitant un temps similaire.

Cependant, au fil du 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'être résistant aux quantiques. Pour ce faire, nous devons trouver des moyens plus flexibles de résoudre le risque de déni de service )DoS###, sans exiger que les étapes de vérification soient extrêmement minimales.

Le principal compromis semble être "écrire rapidement une solution 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 hybride. Une approche hybride consiste à écrire plus rapidement certains cas d'utilisation et à laisser plus de temps pour explorer d'autres cas d'utilisation. Une autre méthode est de 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 confiance dans le travail de l'adoption de la proposition pour être prête à mettre en œuvre, en particulier 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 un L2 dédié, mais peut être utilisé sur L1 et tout L2 compatible. Pour y parvenir efficacement, il pourrait être nécessaire que le L2 prenne en charge des codes d'opération tels que L1SLOAD ou REMOTESTATICCALL, mais cela nécessite également que l'implémentation de l'abstraction des comptes sur L2 prenne en charge ces opérations.

(# Comment interagit-il avec les autres parties de la feuille de route ?

La liste d'inclusion doit supporter les transactions d'abstraction de compte. Dans la pratique, la demande de liste d'inclusion est en réalité très similaire à celle des pools de mémoire décentralisés, bien que la flexibilité soit légèrement plus grande pour la liste d'inclusion. De plus, la mise en œuvre de l'abstraction de compte devrait être coordonnée autant que possible entre L1 et L2. Si nous prévoyons que la plupart des utilisateurs utiliseront Rollup de stockage de clé à l'avenir, la conception de l'abstraction de compte devrait être basée sur cela.

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

( amélioration EIP-1559

)# Quel problème cela résout-il?

EIP-1559 a été activé sur Ethereum en 2021, améliorant considérablement le temps moyen d'inclusion des blocs.

Cependant, la mise en œuvre actuelle de l'EIP-1559 n'est pas parfaite à plusieurs égards :

1. La formule présente légèrement des défauts : elle ne vise pas 50 % des blocs, mais environ 50-53 % des blocs pleins, ce qui dépend de la variance ### et cela est lié à ce que les mathématiciens appellent "l'inégalité arithmético-géométrique".