Possibilités futures du protocole Ethereum : 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, 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 les frais de transaction économiques, améliorer l'évolutivité tout en réduisant les risques
Explorer la cryptographie avancée, permettant à Ethereum d'améliorer significativement à 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 par un support explicite via 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), 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 significative étant :
Le code ( est exécutable, mais il n'est pas possible de lire ) à partir de 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 redirection statique autorisée
Le code EVM ne peut plus observer les informations liées au combustible.
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, les anciens contrats ( pouvant 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 caractéristiques des sous-routines, 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 supplémentaires deviennent 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 les opérations modulo 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 relativement nouvelle 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 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-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(
)# Lien de recherche existant
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 l'enlever à la dernière minute - certaines fonctionnalités ont été temporairement retirées lors de précédents hard forks, cela poserait néanmoins de grands défis. Enlever EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, ce qui est faisable, mais 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'un grand nombre de lignes de code à l'implémentation de l'EVM, et la vérification de code statique 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.
Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX + SIMD et de procéder à des tests de référence sur 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 permettre à L2 de procéder également à des ajustements correspondants 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éfastes. De plus, EVM-MAX et SIMD peuvent réduire les coûts en gas de nombreux systèmes de preuve, rendant ainsi 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 pourrait ne 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-e607936b4195e92945aa6ebd5f969276.webp(
) abstraction de compte
Quels problèmes cela a-t-il résolu ?
Actuellement, les transactions ne peuvent être vérifiées que par une seule méthode : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser cela, permettant à la logique de vérification du compte d'être n'importe quel code EVM. Cela peut activer une série d'applications :
Passer à la cryptographie post-quantique
Le remplacement de l'ancienne clé ### est largement considéré comme une pratique de sécurité recommandée (
Portefeuille multi-signatures 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 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 pourrait utiliser des ERC20 pour payer le gaz.
MPC) le calcul multipartite ( est une technologie qui a 40 ans d'histoire, 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 le 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 (. Elle vise à 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 donné naissance à l'EIP-7702. L'EIP-7702 fournit la "fonctionnalité pratique" de l'abstraction des comptes à tous les utilisateurs, y compris les comptes externes possédés 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 telles que le calcul multipartite ou l'EIP-7702, l'objectif principal de sécurité du projet d'abstraction de compte proposé initialement 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 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é provient de la mise en œuvre de cela d'une manière qui soit amicale pour le 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 multiple pannes :
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 permettrait à 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 a finalement été trouvée pour réaliser "l'abstraction de compte idéale": ERC-4337.
Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations utilisateur en deux phases : validation et exécution. Toutes les validations sont d'abord traitées, puis toutes les exécutions sont traitées. Dans la mémoire, seules les opérations utilisateur dont la phase de validation n'implique que leur propre compte et ne lit pas les variables d'environnement seront acceptées. Cela permet de prévenir les attaques par double échec. 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 des objets appelés opérations utilisateur, au lieu de transactions conventionnelles. Cependant, nous avons récemment 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 : comme le besoin de transférer les garanties créées dans la liste vers des utilisateurs abstraits de 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 viole la règle selon laquelle seule le compte de l'expéditeur peut être accessible durant la phase de validation, d'où l'introduction d'un traitement spécial pour garantir la sécurité du mécanisme d'agent de paiement.
Agrégateurs(: support de la fonction d'agrégation de signatures, comme l'agrégation BLS ou l'agrégation basée sur SNARK. Cela est nécessaire pour atteindre la plus grande efficacité des données sur les Rollups.
![Vitalik sur le futur potentiel d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
)# 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) basé sur le protocole d'écriture des comptes abstraits EOF (:
)# 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 récent EIP d'abstraction de compte populaire 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 en provenance 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 de code EVM
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la période de validation --- n'autorisant pas l'accès à l'état externe, et même le plafond de gas initial fixé étant si bas qu'il 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 suffit 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 la résistance quantique. 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 vérification soient extrêmement simplistes.
Le principal compromis semble être "écrire rapidement un plan qui satisfait moins de personnes" contre "attendre plus longtemps pour obtenir une solution potentiellement 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 est confronté est que l'équipe L2 doit avoir confiance dans le travail de la proposition d'adoption pour être prête à l'implémenter, 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 clairement est le compte de stockage de clés, ces comptes stockent l'état lié au compte sur L1 ou un L2 dédié, mais peuvent être utilisés à la fois sur L1 et à d'autres endroits.
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.
Feuille de route de la prospérité d'Ethereum : mise à niveau de l'EVM, abstraction de compte et optimisation EIP-1559
Possibilités futures du protocole Ethereum : 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, 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 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, 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 significative étant :
Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés, les anciens contrats ( pouvant 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 caractéristiques des sous-routines, 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 supplémentaires deviennent 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 les opérations modulo 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 relativement nouvelle 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 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-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(
)# Lien de recherche existant
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 ont été temporairement retirées lors de précédents hard forks, cela poserait néanmoins de grands défis. Enlever EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, ce qui est faisable, mais 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'un grand nombre de lignes de code à l'implémentation de l'EVM, et la vérification de code statique 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.
Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX + SIMD et de procéder à des tests de référence sur 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 permettre à L2 de procéder également à des ajustements correspondants 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éfastes. De plus, EVM-MAX et SIMD peuvent réduire les coûts en gas de nombreux systèmes de preuve, rendant ainsi 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 pourrait ne 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-e607936b4195e92945aa6ebd5f969276.webp(
) abstraction de compte
Quels problèmes cela a-t-il résolu ?
Actuellement, les transactions ne peuvent être vérifiées que par une seule méthode : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser cela, permettant à la logique de vérification du compte d'être n'importe quel code EVM. Cela peut activer une série 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 pourrait utiliser des ERC20 pour payer le gaz.
MPC) le calcul multipartite ( est une technologie qui a 40 ans d'histoire, 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 le 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 (. Elle vise à 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 donné naissance à l'EIP-7702. L'EIP-7702 fournit la "fonctionnalité pratique" de l'abstraction des comptes à tous les utilisateurs, y compris les comptes externes possédés 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 telles que le calcul multipartite ou l'EIP-7702, l'objectif principal de sécurité du projet d'abstraction de compte proposé initialement 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 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é provient de la mise en œuvre de cela d'une manière qui soit amicale pour le 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 multiple pannes :
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 permettrait à 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 a finalement été trouvée pour réaliser "l'abstraction de compte idéale": ERC-4337.
Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations utilisateur en deux phases : validation et exécution. Toutes les validations sont d'abord traitées, puis toutes les exécutions sont traitées. Dans la mémoire, seules les opérations utilisateur dont la phase de validation n'implique que leur propre compte et ne lit pas les variables d'environnement seront acceptées. Cela permet de prévenir les attaques par double échec. 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 des objets appelés opérations utilisateur, au lieu de transactions conventionnelles. Cependant, nous avons récemment 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 :
![Vitalik sur le futur potentiel d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
)# Liens de recherche existants
)# 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 récent EIP d'abstraction de compte populaire 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 en provenance 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 --- n'autorisant pas l'accès à l'état externe, et même le plafond de gas initial fixé étant si bas qu'il 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 suffit 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 la résistance quantique. 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 vérification soient extrêmement simplistes.
Le principal compromis semble être "écrire rapidement un plan qui satisfait moins de personnes" contre "attendre plus longtemps pour obtenir une solution potentiellement 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 est confronté est que l'équipe L2 doit avoir confiance dans le travail de la proposition d'adoption pour être prête à l'implémenter, 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 clairement est le compte de stockage de clés, ces comptes stockent l'état lié au compte sur L1 ou un L2 dédié, mais peuvent être utilisés à la fois sur L1 et à d'autres endroits.