L'avenir possible du protocole Ethereum ( six ) : prospérité
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, le reste étant constitué de divers sujets de niche, c'est là que réside le sens de "繁荮".
Prospérité : objectif clé
Transformer l'EVM en un "état final" haute performance et stable
Introduire l'abstraction des comptes dans le protocole, permettant à tous les utilisateurs de bénéficier d'un compte plus sûr et plus pratique.
Optimiser les frais de transaction économiques, améliorer la scalabilité tout en réduisant les risques
Explorer la cryptographie avancée, permettant à Ethereum de s'améliorer considérablement à 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'expansion 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 soutien 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), 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 significative étant :
Le code ( est exécutable, mais il n'est pas possible de lire ) depuis l'EVM et les données ( peuvent être lues, mais il n'est pas possible d'exécuter ) entre la séparation.
Interdiction des redirections dynamiques, uniquement les redirections statiques autorisées
Le code EVM ne peut plus observer les informations liées au carburant.
Ajout d'un nouveau mécanisme de routine explicite des sous-exemples
Les anciens contrats continueront d'exister et pourront être créés, même s'ils pourraient finalement être progressivement abandonnés et convertis de force en code EOF (. Les nouveaux contrats bénéficieront des gains d'efficacité apportés par l'Eof - d'abord grâce à un code byte légèrement réduit par les sous-routines, puis avec les nouvelles fonctionnalités spécifiques à l'Eof ou la réduction des coûts en gas.
Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles, et 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é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 possibles des optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec les caractéristiques SIMD (Single Instruction Multiple Data) ), SIMD en tant que concept pour 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 de 32 bits et la cryptographie basée sur les réseaux. La combinaison d'EVM-MAX et de SIMD rend ces deux extensions orientées vers la performance compatibles.
Un design général d'un EIP combiné commencera par l'EIP-6690, puis:
Autoriser (i) tout nombre impair ou (ii) toute puissance de 2 ne dépassant pas 2768 comme module
Pour chaque opcode EVM-MAX ( addition, soustraction, multiplication ), ajoutez une version qui n'utilise plus 3 constantes immédiates x, y, z, mais utilise 7 constantes immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes fonctionnent de manière similaire :
for i in range(count):
mem[z_start + z_skip * count] = op(
mem[x_start + x_skip * count],
mem[y_start + y_skip * count]
)
Dans la mise en œuvre réelle, cela sera traité de manière parallèle.
Il est possible d'ajouter XOR, AND, OR, NOT et SHIFT(, y compris les boucles et non-boucles), au moins pour les puissances de 2 modulaire. En même temps, ajouter ISZERO( poussera la sortie vers la pile principale de l'EVM), ce qui sera suffisamment puissant pour réaliser la cryptographie par courbes elliptiques, la cryptographie sur petits champs( comme Poseidon, Circle STARKs), les fonctions de hachage traditionnelles( comme SHA256, KECCAK, BLAKE) et la cryptographie basée sur des réseaux. D'autres mises à niveau de l'EVM peuvent également être réalisées, mais elles ont jusqu'à présent reçu moins d'attention.
(# Les travaux restants et les 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, le faire poserait cependant de grands défis. Retirer EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit possible, cela pourrait être plus difficile.
Le principal compromis de l'EVM réside dans la complexité du 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 l'analyse statique du code est également relativement complexe. Cependant, en échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et d'autres avantages. On peut dire que la feuille de route pour 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 performance de 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 être ajusté plus facilement. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et avoir des conséquences négatives. 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 capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact significatif sur l'efficacité.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp###
( abstraction de compte
)# Quel problème a été résolu?
Actuellement, les transactions ne peuvent être vérifiées que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de 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
Le rotation des anciennes clés ### est largement considéré comme une pratique de sécurité recommandée ###
Portefeuille multi-signature et portefeuille de récupération sociale
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 la proposition de l'abstraction de compte en 2015, son objectif s'est également élargi pour inclure un grand nombre de "cibles pratiques", par exemple, un compte qui ne possède pas d'ETH mais qui a quelques ERC20 pourrait utiliser des ERC20 pour payer le gas.
(# 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 favorise 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 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 a finalement été trouvée 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 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, une opération d'utilisateur n'est acceptée que lorsque la phase de validation n'implique que son propre compte et ne lit pas les variables d'environnement. Cela permet d'éviter les attaques de double dépense. 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 étaient concentrés sur la fusion (Merge), n'ayant pas d'é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 ordinaires. Cependant, récemment, nous avons réalisé qu'il était nécessaire d'écrire 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 la liste incluse crée une garantie qui doit être transférée aux utilisateurs d'abstraction 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 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 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 atteindre la meilleure efficacité des données sur Rollup.
![Vitalik sur le futur potentiel d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Le travail restant et les compromis
Actuellement, le principal défi est de savoir comment intégrer complètement l'abstraction de compte dans le protocole. Le protocole d'abstraction de compte récemment populaire est l'EIP-7701, qui 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 code est défini pour le compte, il 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 :
Inclure EIP-4337 comme 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 concernant la complexité du code exécutable pendant la validation - en n'autorisant pas l'accès à l'état externe, même la limite de gas initialement fixée étant si basse qu'elle rendrait inopérants 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 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 d'assurer la résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de gérer les risques de déni de service (DoS), sans exiger que les étapes de vérification soient extrêmement simplifiées.
Le principal compromis semble être "écrire rapidement une solution qui satisfait moins de personnes" contre "attendre plus longtemps, pour peut-être obtenir une solution 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 consiste à déployer d'abord une version plus ambitieuse d'abstraction de compte sur L2. Cependant, le défi auquel cela fait face est que l'équipe L2 doit avoir confiance dans le travail d'adoption de la proposition pour être prête à la mettre en œuvre, en particulier pour s'assurer que L1 et/ou d'autres L2 pourront adopter des solutions compatibles à l'avenir.
Un autre cas d'application que nous devons également considérer clairement est le compte de stockage de clés, ces comptes stockent l'état associé au compte sur L1 ou L2 dédié, mais peuvent être utilisés sur L1 et tout L2 compatible. Réaliser cela de manière efficace peut exiger que 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 des comptes sur L2 prenne en charge ces opérations.
Comment 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 de liste d'inclusions est en réalité très similaire à celle des mémoires tampons décentralisées, bien que sur...
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.
12 J'aime
Récompense
12
5
Partager
Commentaire
0/400
NeverPresent
· 07-25 21:24
Les pros modifient l'evm tous les jours, quand le gas va-t-il baisser ?
Voir l'originalRépondre0
GateUser-00be86fc
· 07-23 01:23
Mettre à niveau l'EVM dessinera des BTC toute la journée.
Voir l'originalRépondre0
MemeCoinSavant
· 07-23 01:22
basé sur des améliorations EVM statistiquement significatives fr fr... haussier sur le potentiel mémétique d'eth tbh
Voir l'originalRépondre0
Deconstructionist
· 07-23 01:16
Ceux qui parlaient de l'état final sont déjà hors jeu.
Voir l'originalRépondre0
ReverseFOMOguy
· 07-23 01:14
Le protocole n'est pas encore assez amusant, tu comprends ?
Feuille de route de la mise à niveau du protocole Ethereum : amélioration de l'EVM, abstraction de compte et optimisation 1559
L'avenir possible du protocole Ethereum ( six ) : prospérité
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, le reste étant constitué de divers sujets de niche, c'est là que réside le sens de "繁荮".
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'expansion 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 soutien 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), 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 significative étant :
Les anciens contrats continueront d'exister et pourront être créés, même s'ils pourraient finalement être progressivement abandonnés et convertis de force en code EOF (. Les nouveaux contrats bénéficieront des gains d'efficacité apportés par l'Eof - d'abord grâce à un code byte légèrement réduit par les sous-routines, puis avec les nouvelles fonctionnalités spécifiques à l'Eof ou la réduction des coûts en gas.
Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles, et 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é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 possibles des optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec les caractéristiques SIMD (Single Instruction Multiple Data) ), SIMD en tant que concept pour 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 de 32 bits et la cryptographie basée sur les réseaux. La combinaison d'EVM-MAX et de SIMD rend ces deux extensions orientées vers la performance compatibles.
Un design général d'un EIP combiné 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.
(# Les travaux restants et les 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, le faire poserait cependant de grands défis. Retirer EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit possible, cela pourrait être plus difficile.
Le principal compromis de l'EVM réside dans la complexité du 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 l'analyse statique du code est également relativement complexe. Cependant, en échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et d'autres avantages. On peut dire que la feuille de route pour 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 performance de 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 être ajusté plus facilement. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et avoir des conséquences négatives. 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 capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact significatif sur l'efficacité.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp###
( abstraction de compte
)# Quel problème a été résolu?
Actuellement, les transactions ne peuvent être vérifiées que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de 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 la proposition de l'abstraction de compte en 2015, son objectif s'est également élargi pour inclure un grand nombre de "cibles pratiques", par exemple, un compte qui ne possède pas d'ETH mais qui a quelques ERC20 pourrait utiliser des ERC20 pour payer le gas.
(# 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 favorise 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 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 a finalement été trouvée 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 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, une opération d'utilisateur n'est acceptée que lorsque la phase de validation n'implique que son propre compte et ne lit pas les variables d'environnement. Cela permet d'éviter les attaques de double dépense. 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 étaient concentrés sur la fusion (Merge), n'ayant pas d'é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 ordinaires. Cependant, récemment, nous avons réalisé qu'il était nécessaire d'écrire 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-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Le travail restant et les compromis
Actuellement, le principal défi est de savoir comment intégrer complètement l'abstraction de compte dans le protocole. Le protocole d'abstraction de compte récemment populaire est l'EIP-7701, qui 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 code est défini pour le compte, il 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 concernant la complexité du code exécutable pendant la validation - en n'autorisant pas l'accès à l'état externe, même la limite de gas initialement fixée étant si basse qu'elle rendrait inopérants 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 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 d'assurer la résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de gérer les risques de déni de service (DoS), sans exiger que les étapes de vérification soient extrêmement simplifiées.
Le principal compromis semble être "écrire rapidement une solution qui satisfait moins de personnes" contre "attendre plus longtemps, pour peut-être obtenir une solution 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 consiste à déployer d'abord une version plus ambitieuse d'abstraction de compte sur L2. Cependant, le défi auquel cela fait face est que l'équipe L2 doit avoir confiance dans le travail d'adoption de la proposition pour être prête à la mettre en œuvre, en particulier pour s'assurer que L1 et/ou d'autres L2 pourront adopter des solutions compatibles à l'avenir.
Un autre cas d'application que nous devons également considérer clairement est le compte de stockage de clés, ces comptes stockent l'état associé au compte sur L1 ou L2 dédié, mais peuvent être utilisés sur L1 et tout L2 compatible. Réaliser cela de manière efficace peut exiger que 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 des comptes sur L2 prenne en charge ces opérations.
Comment 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 de liste d'inclusions est en réalité très similaire à celle des mémoires tampons décentralisées, bien que sur...