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 réalité, 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é
Transformer l'EVM en un "état final" haute performance et stable
Introduire l'abstraction de compte dans le protocole, permettant à tous les utilisateurs de bénéficier d'un compte plus sécurisé et pratique.
Optimiser l'économie des frais de transaction, améliorer la scalabilité tout en réduisant les risques
Explorer des cryptographies avancées, permettant à Ethereum de s'améliorer de manière significative à long terme
amélioration EVM
Quel problème a été résolu ?
Actuellement, l'EVM rend l'analyse statique difficile, ce qui complique 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écompilés.
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), 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 remarquable étant:
Le code ( peut être exécuté, mais il est impossible de lire la séparation entre ) dans l'EVM et les données ( qui peuvent être lues, mais ne peuvent pas être exécutées ).
Interdiction de redirections dynamiques, seules les redirections statiques sont 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 contrats anciens continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés au profit des contrats anciens ( et même être convertis de force en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par EOF - d'abord grâce à un bytecode légèrement réduit grâce aux caractéristiques de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la réduction des coûts en gas.
Après l'introduction de l'Eof, les mises à niveau supplémentaires sont devenues plus faciles, et 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écifiquement pour les opérations de module, et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, rendant possible l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec la fonctionnalité 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 que ces deux extensions orientées vers la performance s'associent naturellement.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Une conception générale d'un EIP combiné commencera par l'EIP-6690, puis :
Permettre )i( tout nombre impair ou )ii( toute puissance de 2 dont le maximum est 2768 comme modulaire
Pour chaque opcode EVM-MAX ) addition, soustraction, multiplication (, ajoutez une version qui n'utilise plus 3 constantes immédiates x, y, z, mais 7 constantes immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes agissent de manière similaire à :
python
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 des boucles et des non-boucles(, au moins pour les moduli de puissances de 2. En même temps, l'ajout de 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 petits domaines) comme Poseidon, Circle STARKs(, des fonctions de hachage traditionnelles) comme SHA256, KECCAK, BLAKE( et la cryptographie basée sur les réseaux de vecteurs. D'autres mises à niveau de l'EVM pourraient également être mises en œuvre, mais jusqu'à présent, elles ont reçu moins d'attention.
Travail restant et 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, 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 faisable, cela pourrait être plus difficile.
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 lignes de code à 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 pour l'amélioration continue de l'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 tester la consommation de gas pour diverses 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 s'ajustent pas de manière synchronisée, cela peut entraîner une incompatibilité 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 plus de précompilés par du code EVM pouvant exécuter les mêmes tâches, ce qui n'aura probablement pas d'impact significatif sur l'efficacité.
![Vitalik sur l'avenir potentiel d'Ethereum (6) : 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 validées que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser cela, permettant à la logique de validation des comptes d'être n'importe quel code EVM. Cela peut activer une gamme 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 étendu pour inclure de nombreux "objectifs pratiques", par exemple, un compte qui n'a pas d'ETH mais possède quelques ERC20 peut utiliser des ERC20 pour payer le gaz.
Qu'est-ce que c'est, comment ça fonctionne ?
Le cœur de l'abstraction des comptes est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité provient de la manière dont cela est réalisé de manière à être amical pour le maintien d'un réseau décentralisé et à 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 vérification 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 bas, 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 de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : validation et exécution. Toutes les validations sont traitées en premier, puis toutes les exécutions sont traitées. Dans le pool de mémoire, une opération de l'utilisateur n'est acceptée que si la phase de validation n'implique que son propre compte et ne lit pas les variables d'environnement. Cela peut prévenir les attaques par défaillance multiple. De plus, des limites de gas strictes sont également imposées à l'étape de validation.
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 gérer d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise un objet appelé opérations utilisateur, plutôt que les transactions classiques. Cependant, récemment, nous avons réalisé qu'il était nécessaire d'intégrer au moins une partie de son contenu dans le protocole.
Les 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 : par exemple, la garantie de transfert des utilisateurs abstraits de compte créée par la liste d'inclusion.
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 les 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 meilleure efficacité des données sur Rollup.
Travail restant et compromis
La principale question à 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 basé sur le protocole, EIP-7701, est populaire et met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la validation. Si ce compte a défini cette partie de code, alors ce code sera exécuté 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 des comptes locaux :
Intégrer 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 - en n'autorisant pas l'accès à l'état externe, et même les limites de gas établies au départ étant si faibles qu'elles sont inefficaces pour des 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 et d'être résistantes aux attaques quantiques. Pour cela, nous devons trouver des moyens plus flexibles de résoudre 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 pour potentiellement obtenir une solution plus idéale", la méthode idéale pourrait être une sorte de méthode hybride. Une méthode hybride consiste à écrire plus rapidement certains cas d'utilisation et à laisser plus de temps pour explorer d'autres cas d'utilisation. Une autre approche 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 les équipes L2 doivent avoir confiance dans le travail de la proposition d'adoption pour être prêtes à la mettre en œuvre, en particulier pour s'assurer que L1 et/ou d'autres L2 pourront à l'avenir adopter des solutions compatibles.
Une autre application à laquelle nous devons également prêter attention 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 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 de compte sur le L2 supporte ces opérations.
Comment cela interagit-il avec les autres parties de la feuille de route ?
La liste des inclusions doit prendre en charge les transactions d'abstraction de compte. Dans la pratique, la demande pour les listes d'inclusions est en réalité très similaire à celle des pools de mémoire décentralisés, bien que les listes d'inclusions offrent une flexibilité légèrement supérieure. De plus, l'implémentation de l'abstraction de compte devrait viser à réaliser une coordination entre L1 et L2 autant que possible. Si à l'avenir nous nous attendons à ce que la plupart des utilisateurs utilisent un Rollup de stockage de clé, la conception de l'abstraction de compte devrait s'appuyer sur cela.
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
9
Partager
Commentaire
0/400
LayerZeroEnjoyer
· 07-21 03:03
J'attends avec impatience la mise à niveau de l'EVM
Voir l'originalRépondre0
CryptoFortuneTeller
· 07-21 02:41
EVM doit devenir puissant
Voir l'originalRépondre0
LiquidationWizard
· 07-18 18:34
EVM doit encore accélérer.
Voir l'originalRépondre0
DefiSecurityGuard
· 07-18 05:21
Mises à niveau EVM risquées à venir
Voir l'originalRépondre0
LiquidityWizard
· 07-18 05:15
L'optimisation EVM est vraiment délicieuse.
Voir l'originalRépondre0
DeFiGrayling
· 07-18 05:13
La mise à niveau de l'EVM est vraiment nécessaire.
Voir l'originalRépondre0
OnchainHolmes
· 07-18 05:09
Les quatre grands objectifs sont vraiment hardcore.
Direction d'évolution du protocole Ethereum : optimisation de l'EVM, abstraction de compte et innovation des mécanismes de frais.
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 réalité, 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 EVM
Quel problème a été résolu ?
Actuellement, l'EVM rend l'analyse statique difficile, ce qui complique 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écompilés.
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), 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 remarquable étant:
Les contrats anciens continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés au profit des contrats anciens ( et même être convertis de force en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par EOF - d'abord grâce à un bytecode légèrement réduit grâce aux caractéristiques de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la réduction des coûts en gas.
Après l'introduction de l'Eof, les mises à niveau supplémentaires sont devenues plus faciles, et 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écifiquement pour les opérations de module, et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, rendant possible l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec la fonctionnalité 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 que ces deux extensions orientées vers la performance s'associent naturellement.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Une conception générale d'un EIP combiné commencera par l'EIP-6690, puis :
python 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.
Travail restant et 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, 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 faisable, cela pourrait être plus difficile.
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 lignes de code à 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 pour l'amélioration continue de l'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 tester la consommation de gas pour diverses 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 s'ajustent pas de manière synchronisée, cela peut entraîner une incompatibilité 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 plus de précompilés par du code EVM pouvant exécuter les mêmes tâches, ce qui n'aura probablement pas d'impact significatif sur l'efficacité.
![Vitalik sur l'avenir potentiel d'Ethereum (6) : 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 validées que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser cela, permettant à la logique de validation 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 étendu pour inclure de nombreux "objectifs pratiques", par exemple, un compte qui n'a pas d'ETH mais possède quelques ERC20 peut utiliser des ERC20 pour payer le gaz.
Qu'est-ce que c'est, comment ça fonctionne ?
Le cœur de l'abstraction des comptes est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité provient de la manière dont cela est réalisé de manière à être amical pour le maintien d'un réseau décentralisé et à 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 vérification 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 bas, 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 de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : validation et exécution. Toutes les validations sont traitées en premier, puis toutes les exécutions sont traitées. Dans le pool de mémoire, une opération de l'utilisateur n'est acceptée que si la phase de validation n'implique que son propre compte et ne lit pas les variables d'environnement. Cela peut prévenir les attaques par défaillance multiple. De plus, des limites de gas strictes sont également imposées à l'étape de validation.
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 gérer d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise un objet appelé opérations utilisateur, plutôt que les transactions classiques. Cependant, récemment, nous avons réalisé qu'il était nécessaire d'intégrer au moins une partie de son contenu dans le protocole.
Les deux raisons clés sont les suivantes :
De plus, l'ERC-4337 a également étendu deux fonctionnalités :
Travail restant et compromis
La principale question à 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 basé sur le protocole, EIP-7701, est populaire et met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la validation. Si ce compte a défini cette partie de code, alors ce code sera exécuté 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 des comptes locaux :
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la période de validation - en n'autorisant pas l'accès à l'état externe, et même les limites de gas établies au départ étant si faibles qu'elles sont inefficaces pour des 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 et d'être résistantes aux attaques quantiques. Pour cela, nous devons trouver des moyens plus flexibles de résoudre 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 pour potentiellement obtenir une solution plus idéale", la méthode idéale pourrait être une sorte de méthode hybride. Une méthode hybride consiste à écrire plus rapidement certains cas d'utilisation et à laisser plus de temps pour explorer d'autres cas d'utilisation. Une autre approche 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 les équipes L2 doivent avoir confiance dans le travail de la proposition d'adoption pour être prêtes à la mettre en œuvre, en particulier pour s'assurer que L1 et/ou d'autres L2 pourront à l'avenir adopter des solutions compatibles.
Une autre application à laquelle nous devons également prêter attention 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 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 de compte sur le L2 supporte ces opérations.
Comment cela interagit-il avec les autres parties de la feuille de route ?
La liste des inclusions doit prendre en charge les transactions d'abstraction de compte. Dans la pratique, la demande pour les listes d'inclusions est en réalité très similaire à celle des pools de mémoire décentralisés, bien que les listes d'inclusions offrent une flexibilité légèrement supérieure. De plus, l'implémentation de l'abstraction de compte devrait viser à réaliser une coordination entre L1 et L2 autant que possible. Si à l'avenir nous nous attendons à ce que la plupart des utilisateurs utilisent un Rollup de stockage de clé, la conception de l'abstraction de compte devrait s'appuyer sur cela.
![Vitalik sur l'avenir possible d'Ethereum（