- Rubrique
39k Popularité
14k Popularité
8k Popularité
16k Popularité
62k Popularité
31k Popularité
3k Popularité
96k Popularité
27k Popularité
27k Popularité
- Épingler
39k Popularité
14k Popularité
8k Popularité
16k Popularité
62k Popularité
31k Popularité
3k Popularité
96k Popularité
27k Popularité
27k Popularité
Perspectives futures du protocole Ethereum : les principales étapes de la mise à niveau de l'EVM et de l'abstraction de compte.
L'avenir possible du protocole Ethereum ( six ) : prospérité
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 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é
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 relativement faible, rendant difficile la réalisation 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), 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 :
Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés au profit des anciens contrats (, et même être contraints de se convertir en code EOF ). Les nouveaux contrats bénéficieront des gains d'efficacité apportés par EOF - d'abord grâce à un code byte légèrement réduit grâce aux fonctionnalités de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la réduction des coûts de gas.
Après l'introduction de l'Eof, les mises à niveau ultérieures deviennent plus faciles. Le développement le plus abouti est l'extension arithmétique du module EVM ( EVM-MAX ). EVM-MAX crée un ensemble de nouvelles opérations spécialement conçues 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 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 de 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 couplage naturel.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Une conception générale d'un ensemble d'EIP commencera par l'EIP-6690, puis :
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.
)# 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 - certaines fonctionnalités ayant été temporairement retirées lors de précédents hard forks, cela 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 réalisable, cela pourrait être plus compliqué.
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 codes à l'implémentation de l'EVM, et la vérification statique du code est également relativement complexe. Cependant, en échange, nous pouvons simplifier le langage de haut niveau, simplifier l'implémentation de l'EVM et d'autres avantages. On peut dire que la feuille de route qui privilégie l'amélioration continue d'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 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 pour que L2 puisse également effectuer des ajustements correspondants plus facilement. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et avoir des conséquences 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 davantage 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é.
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 de compte visait à aller au-delà de cela, permettant à la logique de vérification du compte d'être n'importe quel code EVM. Cela pourrait activer une gamme d'applications :
Permettre au protocole de confidentialité de fonctionner sans relais, réduisant considérablement sa complexité et éliminant un point de dépendance central clé.
Depuis la proposition de l'abstraction de compte en 2015, son objectif s'est également étendu 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 utiliser des ERC20 pour payer le gaz.
MPC) le calcul multipartite ( est une technologie existante 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 à combiner directement ces parties de clé.
EIP-7702 est une proposition prévue pour être introduite lors de la prochaine fourche dure. EIP-7702 est le résultat d'une prise de conscience 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 la "fonctionnalité pratique" de l'abstraction de compte à tous les utilisateurs, y compris aujourd'hui les EOA) comptes externes contrôlés, c'est-à-dire les comptes contrôlés par des signatures ECDSA(.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
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é de la proposition d'abstraction de compte initialement soumise ne peut être atteint qu'en revenant en arrière et en résolvant le problème original : permettre au code des contrats intelligents de contrôler la vérification des transactions. La raison pour laquelle cela n'a pas encore été réalisé est la mise en œuvre sécurisée, ce qui représente 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 manière de réaliser cela d'une manière favorable au maintien d'un réseau décentralisé, tout en prévenant les attaques par déni de service.
Un défi clé typique est le problème de multiples défaillances :
Si une 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 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 du ERC-4337 consiste à diviser le traitement des opérations utilisateur en deux étapes : vérification et exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions. Dans la mémoire tampon, les opérations utilisateur 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 double dépense. De plus, des limites de gas strictes sont également imposées à l'étape de vérification.
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 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.
Deux raisons clés sont les suivantes :
De plus, l'ERC-4337 a également étendu deux fonctionnalités :
)# Le travail restant et les compromis
Il est actuellement nécessaire de résoudre comment introduire complètement l'abstraction de compte dans le protocole. Le récent EIP d'abstraction de compte qui a gagné en popularité est l'EIP-7701, qui met en œuvre 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 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 :
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la validation - empêchant l'accès à l'état externe, même la limite de gas initialement établie étant si basse qu'elle rendrait inopérantes 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 la résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de résoudre les risques de déni de service (DoS), sans exiger que les étapes de vérification soient extrêmement simplifiées.
principal