L'avenir possible du protocole Ethereum ( six ) : prospérité
La conception du protocole Ethereum comporte de nombreux "détails" qui 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 ce que signifie "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 coûts de transaction, améliorer l'évolutivité 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, il est difficile de procéder à une analyse statique de l'EVM, ce qui complique la création d'implémentations efficaces, la vérification formelle du code et l'extension ultérieure. De plus, l'efficacité de l'EVM est faible, rendant difficile la mise en œuvre de nombreux algorithmes cryptographiques avancés, sauf s'ils sont explicitement pris en charge 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. 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 la séparation de ).
Les redirections dynamiques sont interdites, seules les redirections statiques sont autorisées
Le code EVM ne peut plus observer les informations liées au combustible.
Ajout d'un nouveau mécanisme de sous-routine explicite
Les contrats anciens continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés ( et même éventuellement convertis de force en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par l'EOF - d'abord grâce à un bytecode légèrement réduit par les caractéristiques des sous-routines, puis grâce aux nouvelles fonctionnalités spécifiques à l'EOF ou à la réduction des coûts en gas.
Après l'introduction de l'EOF, la mise à niveau est devenue plus facile. 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 destinées aux calculs modulaires et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet d'utiliser des optimisations telles que la multiplication de Montgomery.
Une idée plus récente est de combiner EVM-MAX avec les caractéristiques SIMD (Single Instruction Multiple Data) (, SIMD en tant que concept d'Ethereum existe depuis longtemps, ayant été 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 les performances un appariement naturel.
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 - des fonctionnalités ont déjà été temporairement retirées lors de précédents hard forks, faire cela représenterait un grand défi. Enlever EOF signifie que toute mise à niveau future de l'EVM devra être effectuée 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é des infrastructures. L'EOF nécessite l'ajout d'une quantité importante de code dans l'implémentation de l'EVM, et la vérification 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 de l'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Une tâche importante à accomplir est de réaliser des fonctionnalités similaires à EVM-MAX et SIMD, et de faire des tests de référence sur la consommation de gaz 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 s'ajuster plus facilement. Si les deux ne s'ajustent pas de manière synchronisée, cela pourrait entraîner des incompatibilités et des conséquences négatives. De plus, EVM-MAX et SIMD peuvent réduire les coûts de gas de nombreux systèmes de preuve, rendant L2 plus efficace. Cela facilite également le remplacement de plus de précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact majeur sur l'efficacité.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.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 à dépasser cela, permettant à la logique de vérification des comptes d'être n'importe quel code EVM. Cela peut activer une gamme d'applications :
Passer à la cryptographie post-quantique
Faire tourner les 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 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 de commodité", par exemple, un compte qui ne possède pas d'ETH mais qui a quelques ERC20 peut 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 besoin de combiner directement ces parties de clé.
EIP-7702 est une proposition prévue pour être introduite dans la prochaine bifurcation, EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une abstraction de compte pour le 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 les comptes externes contrôlés par des propriétaires (EOA) d'aujourd'hui, c'est-à-dire les comptes contrôlés par des signatures ECDSA ).
Bien que certains défis (, en particulier le défi de la "commodité", puissent être résolus par des technologies progressives comme le calcul multipartite ou l'EIP-7702, l'objectif de sécurité principal du projet d'abstraction de compte proposé à l'origine ne peut être atteint qu'en revenant et en résolvant le problème initial : permettre au code de contrat intelligent 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 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 manière de réaliser cela d'une manière qui soit amicale 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 la fonction de validation de 1000 comptes dépend d'une valeur unique S, et que la valeur actuelle S rend toutes les transactions dans la mémoire tampon valides, alors une seule transaction 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), nous avons finalement abouti à une solution pour réaliser "l'abstraction idéale des comptes": ERC-4337.
Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : la vérification et l'exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions sont traitées par la suite. Dans la mémoire tampon, une opération utilisateur n'est acceptée que lorsque la phase de vérification n'implique que son 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 de gas strictes sont également imposées à l'étape de vérification.
![Vitalik sur le futur possible d'Ethereum (six) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
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 (, sans é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 classiques. Cependant, nous avons récemment réalisé la nécessité d'écrire au moins une partie de cela dans le protocole.
Deux raisons clés sont les suivantes :
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.
Assurer la nécessité des attributs Ethereum : comme la liste incluse exige que la garantie créée soit transférée à des utilisateurs abstraits de compte.
De plus, l'ERC-4337 a également étendu deux fonctionnalités :
Paiement par agent ) 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 de paiement par agent.
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 la plus haute efficacité des données sur Rollup.
(# Le travail restant et les compromis
Le principal problème à résoudre actuellement est de savoir comment intégrer 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 implémente l'abstraction de compte 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 indique clairement les deux perspectives équivalentes de l'abstraction de compte local :
Intégrer l'EIP-4337 en tant que partie du protocole
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 période de validation - interdisant l'accès à l'état externe, même avec une limite de gaz initialement fixée si basse qu'elle rend les applications résistantes aux quantiques ou de protection de la vie privée inefficaces - 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'être résistantes aux quantiques. Pour cela, nous devons trouver des moyens plus flexibles de traiter le risque de déni de service )DoS( sans exiger que les étapes de validation soient extrêmement simplistes.
Le principal compromis semble être "écrire rapidement une solution qui satisfait moins de personnes" contre "attendre plus longtemps, ce qui pourrait aboutir à 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 à consacrer plus de temps à explorer d'autres cas d'utilisation. Une autre méthode serait de déployer d'abord une version d'abstraction des comptes plus ambitieuse sur L2. Cependant, le défi auquel cela fait face est que l'équipe L2 doit avoir confiance dans le travail de proposition d'adoption pour être prête à mettre en œuvre, surtout pour garantir que L1 et/ou d'autres L2 puissent adopter des solutions compatibles à l'avenir.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp###
Une autre application que nous devons également considérer clairement est le compte de stockage de clés, ces comptes stockent des états liés au compte sur L1 ou sur des L2 dédiés, mais peuvent être utilisés sur L1 et tout L2 compatible. Pour y parvenir efficacement, il se peut que L2 doive prendre en charge des opcodes tels que L1SLOAD ou REMOTESTATICCALL, mais cela nécessite également que l'implémentation d'abstraction de compte sur L2 prenne en charge ces opérations.
(# Comment interagit-il avec les autres parties de la feuille de route ?
Les listes d'inclusion doivent prendre en charge les transactions d'abstraction de compte. En pratique, les besoins en matière de listes d'inclusion sont en réalité très similaires aux besoins des pools de mémoire décentralisés, bien que les listes d'inclusion offrent une flexibilité légèrement plus grande. De plus, la mise en œuvre de l'abstraction de compte devrait, dans la mesure du possible, coordonner entre L1 et L2. Si à l'avenir, nous nous attendons à ce que la plupart des utilisateurs utilisent le stockage de clés Rollup, la conception de l'abstraction de compte devrait.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
11 J'aime
Récompense
11
7
Partager
Commentaire
0/400
UnluckyMiner
· Il y a 5h
encore un bull EVM
Voir l'originalRépondre0
AirdropLicker
· Il y a 23h
Au revoir, le pump de Gas arrive.
Voir l'originalRépondre0
ChainWanderingPoet
· 08-05 23:23
Les frais doivent encore être optimisés, je ne peux même pas gérer le BTC.
Voir l'originalRépondre0
LeverageAddict
· 08-03 22:13
shitcoin a déjà couru sur l'EVM, alors que la machine Éther est toujours bloquée.
Voir l'originalRépondre0
FrogInTheWell
· 08-03 22:10
Tout le monde veut vraiment optimiser l'EVM, n'est-ce pas?
Perspectives futures du protocole Ethereum : mise à niveau de l'EVM, abstraction de compte et optimisation des frais de transaction
L'avenir possible du protocole Ethereum ( six ) : prospérité
La conception du protocole Ethereum comporte de nombreux "détails" qui 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 ce que signifie "prospérité".
Prospérité : objectif clé
amélioration de l'EVM
Quel problème a été résolu ?
Actuellement, il est difficile de procéder à une analyse statique de l'EVM, ce qui complique la création d'implémentations efficaces, la vérification formelle du code et l'extension ultérieure. De plus, l'efficacité de l'EVM est faible, rendant difficile la mise en œuvre de nombreux algorithmes cryptographiques avancés, sauf s'ils sont explicitement pris en charge 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. 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 :
Les contrats anciens continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés ( et même éventuellement convertis de force en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par l'EOF - d'abord grâce à un bytecode légèrement réduit par les caractéristiques des sous-routines, puis grâce aux nouvelles fonctionnalités spécifiques à l'EOF ou à la réduction des coûts en gas.
Après l'introduction de l'EOF, la mise à niveau est devenue plus facile. 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 destinées aux calculs modulaires et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet d'utiliser des optimisations telles que la multiplication de Montgomery.
Une idée plus récente est de combiner EVM-MAX avec les caractéristiques SIMD (Single Instruction Multiple Data) (, SIMD en tant que concept d'Ethereum existe depuis longtemps, ayant été 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 les performances un appariement naturel.
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 - des fonctionnalités ont déjà été temporairement retirées lors de précédents hard forks, faire cela représenterait un grand défi. Enlever EOF signifie que toute mise à niveau future de l'EVM devra être effectuée 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é des infrastructures. L'EOF nécessite l'ajout d'une quantité importante de code dans l'implémentation de l'EVM, et la vérification 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 de l'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Une tâche importante à accomplir est de réaliser des fonctionnalités similaires à EVM-MAX et SIMD, et de faire des tests de référence sur la consommation de gaz 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 s'ajuster plus facilement. Si les deux ne s'ajustent pas de manière synchronisée, cela pourrait entraîner des incompatibilités et des conséquences négatives. De plus, EVM-MAX et SIMD peuvent réduire les coûts de gas de nombreux systèmes de preuve, rendant L2 plus efficace. Cela facilite également le remplacement de plus de précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact majeur sur l'efficacité.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.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 à dépasser cela, permettant à la logique de vérification des comptes d'être n'importe quel code EVM. Cela peut activer une gamme d'applications :
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 de commodité", par exemple, un compte qui ne possède pas d'ETH mais qui a quelques ERC20 peut 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 besoin de combiner directement ces parties de clé.
EIP-7702 est une proposition prévue pour être introduite dans la prochaine bifurcation, EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une abstraction de compte pour le 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 les comptes externes contrôlés par des propriétaires (EOA) d'aujourd'hui, c'est-à-dire les comptes contrôlés par des signatures ECDSA ).
Bien que certains défis (, en particulier le défi de la "commodité", puissent être résolus par des technologies progressives comme le calcul multipartite ou l'EIP-7702, l'objectif de sécurité principal du projet d'abstraction de compte proposé à l'origine ne peut être atteint qu'en revenant et en résolvant le problème initial : permettre au code de contrat intelligent 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 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 manière de réaliser cela d'une manière qui soit amicale 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 la fonction de validation de 1000 comptes dépend d'une valeur unique S, et que la valeur actuelle S rend toutes les transactions dans la mémoire tampon valides, alors une seule transaction 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), nous avons finalement abouti à une solution pour réaliser "l'abstraction idéale des comptes": ERC-4337.
Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : la vérification et l'exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions sont traitées par la suite. Dans la mémoire tampon, une opération utilisateur n'est acceptée que lorsque la phase de vérification n'implique que son 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 de gas strictes sont également imposées à l'étape de vérification.
![Vitalik sur le futur possible d'Ethereum (six) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
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 (, sans é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 classiques. Cependant, nous avons récemment réalisé la nécessité d'écrire au moins une partie de cela 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
Le principal problème à résoudre actuellement est de savoir comment intégrer 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 implémente l'abstraction de compte 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 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 période de validation - interdisant l'accès à l'état externe, même avec une limite de gaz initialement fixée si basse qu'elle rend les applications résistantes aux quantiques ou de protection de la vie privée inefficaces - 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'être résistantes aux quantiques. Pour cela, nous devons trouver des moyens plus flexibles de traiter le risque de déni de service )DoS( sans exiger que les étapes de validation soient extrêmement simplistes.
Le principal compromis semble être "écrire rapidement une solution qui satisfait moins de personnes" contre "attendre plus longtemps, ce qui pourrait aboutir à 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 à consacrer plus de temps à explorer d'autres cas d'utilisation. Une autre méthode serait de déployer d'abord une version d'abstraction des comptes plus ambitieuse sur L2. Cependant, le défi auquel cela fait face est que l'équipe L2 doit avoir confiance dans le travail de proposition d'adoption pour être prête à mettre en œuvre, surtout pour garantir que L1 et/ou d'autres L2 puissent adopter des solutions compatibles à l'avenir.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp###
Une autre application que nous devons également considérer clairement est le compte de stockage de clés, ces comptes stockent des états liés au compte sur L1 ou sur des L2 dédiés, mais peuvent être utilisés sur L1 et tout L2 compatible. Pour y parvenir efficacement, il se peut que L2 doive prendre en charge des opcodes tels que L1SLOAD ou REMOTESTATICCALL, mais cela nécessite également que l'implémentation d'abstraction de compte sur L2 prenne en charge ces opérations.
(# Comment interagit-il avec les autres parties de la feuille de route ?
Les listes d'inclusion doivent prendre en charge les transactions d'abstraction de compte. En pratique, les besoins en matière de listes d'inclusion sont en réalité très similaires aux besoins des pools de mémoire décentralisés, bien que les listes d'inclusion offrent une flexibilité légèrement plus grande. De plus, la mise en œuvre de l'abstraction de compte devrait, dans la mesure du possible, coordonner entre L1 et L2. Si à l'avenir, nous nous attendons à ce que la plupart des utilisateurs utilisent le stockage de clés Rollup, la conception de l'abstraction de compte devrait.