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

Dans la conception du protocole Ethereum, de nombreux "détails" sont cruciaux pour son succès. Environ la moitié du contenu concerne différents types d'améliorations de l'EVM, le reste étant constitué de divers sujets de niche, c'est là que réside le sens de la "prospérité".

Prospérité : objectif clé

• Transformer l'EVM en un "état final" 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 la scalabilité tout en réduisant les risques
• Explorer des cryptographies avancées, permettant à Ethereum de s'améliorer significativement à long terme

amélioration de l'EVM

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

L'EVM actuelle 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 par un support explicite via 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 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 notable étant :

• Le code ( peut être exécuté, mais il n'est pas possible de lire ) depuis l'EVM, et les données ( peuvent être lues, mais ne peuvent pas être exécutées entre la séparation de ).
• Interdiction de redirection dynamique, uniquement les redirections statiques autorisées
• 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, même pouvant être convertis de force en code EOF (. Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par EOF - d'abord par un bytecode légèrement réduit grâce à la fonctionnalité de sous-routine, puis par de nouvelles fonctionnalités spécifiques à EOF ou des coûts de gas réduits.

Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles, le développement le plus avancé étant 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 de module 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 caractéristique SIMD (Single Instruction Multiple Data) ), SIMD en tant que concept d'Ethereum existe depuis longtemps, initialement proposé 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 rend ces deux extensions axées sur la performance naturellement compatibles.

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 ne dépassant pas 2768 comme modulaire
• Pour chaque code d'opération 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 codes d'opération ont une fonction 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( incluant des boucles et des 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 de petit domaine( comme Poseidon, Circle STARKs), des fonctions de hachage traditionnelles( comme SHA256, KECCAK, BLAKE) et la cryptographie basée sur les réseaux. D'autres mises à niveau de l'EVM pourraient également être mises en œuvre, mais jusqu'à présent, elles ont reçu 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 - certaines 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.

Les principaux compromis de l'EVM concernent la complexité du L1 et celle des infrastructures. L'EOF nécessite l'ajout d'un grand nombre de lignes de code dans 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 bénéficier 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.

Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX avec 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 pour permettre à L2 de s'ajuster également plus facilement. Si les deux ne s'ajustent pas de manière synchronisée, cela pourrait entraîner des incompatibilités et avoir des effets négatifs. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant 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 (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 seul moyen : la signature ECDSA. À l'origine, l'abstraction des comptes visait à aller au-delà de cela, permettant à la logique de vérification des comptes d'être tout code EVM. 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-signature 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 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 élargi pour inclure de nombreux "objectifs de commodité", par exemple, un compte qui n'a pas d'Éther mais qui possède quelques ERC20 peut utiliser des ERC20 pour payer les frais de gas.

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 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 lors du prochain hard fork. 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 ). L'objectif est d'améliorer l'expérience de tous les utilisateurs à court terme et d'éviter la division en deux écosystèmes.

Ce travail a commencé par l'EIP-3074 et a finalement abouti à l'EIP-7702. L'EIP-7702 offre les "fonctionnalités de commodité" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes détenus (EOA) ( d'aujourd'hui, c'est-à-dire les comptes contrôlés par une signature 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, l'objectif de sécurité principal du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant en arrière 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 l'implémentation 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 favorable au maintien d'un réseau décentralisé et qui se prémunisse 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 seule valeur S, et que la valeur actuelle S 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 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 refus de service ) DoS ###, la solution pour réaliser "l'abstraction idéale de compte" a finalement été atteinte : ERC-4337.

Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : vérification et exécution. Toutes les vérifications sont traitées en premier, suivies de toutes les exécutions. 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 défaillance 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 traiter d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise des objets appelés opérations utilisateur, plutôt que des transactions ordinaires. Cependant, nous avons récemment réalisé qu'il était nécessaire d'écrire au moins une partie de son contenu 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 les garanties créées par la liste incluse doivent être transférées à l'utilisateur de compte abstrait.

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 viole 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é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.

(# 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 protocole d'abstraction de compte récemment populaire est l'EIP-7701, qui implémente 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 configuré cette section de code, celle-ci 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 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 initialement définie étant si basse qu'elle est inefficace 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, 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 solutions plus flexibles pour faire face aux attaques par déni de service )DoS###.