O futuro possível do protocolo Ethereum(seis): prosperidade
O design do protocolo Ethereum contém muitos "detalhes" que são cruciais para seu sucesso. Cerca de metade do conteúdo envolve diferentes tipos de melhorias no EVM, enquanto o restante é composto por vários tópicos de nicho, que é o que significa "prosperidade".
Prosperidade: Objetivo-chave
Transformar o EVM em um "estado final" de alto desempenho e estabilidade
Introduzir a abstração de contas no protocolo, permitindo que todos os usuários desfrutem de contas mais seguras e convenientes.
Otimizar a economia das taxas de transação, aumentar a escalabilidade enquanto reduz o risco
Explorar a criptografia avançada, para que o Ethereum melhore significativamente a longo prazo
melhoria do EVM
Que problema foi resolvido?
Atualmente, é difícil realizar análises estáticas no EVM, o que torna difícil criar implementações eficientes, validar formalmente o código e expandir ainda mais. Além disso, a eficiência do EVM é baixa, dificultando a implementação de muitas criptografias avançadas, a menos que haja suporte explícito através de pré-compilações.
O que é, como funciona?
O primeiro passo do atual roteiro de melhorias do EVM é o formato de objeto EVM (EOF), planejado para ser incluído na próxima bifurcação dura. EOF é uma série de EIPs que especificam uma nova versão do código EVM, com muitas características únicas, sendo a mais notável:
O código ( é executável, mas não pode ser lido a partir do EVM. ) e os dados ( podem ser lidos, mas não podem ser executados a separação de ).
Proibido redirecionamento dinâmico, apenas redirecionamento estático permitido
O código EVM não pode mais observar informações relacionadas ao combustível
Adicionada uma nova mecânica de sub-rotina explícita
Os contratos antigos continuarão a existir e poderão ser criados, embora possam eventualmente ser gradualmente descontinuados ( e até mesmo forçados a serem convertidos para código EOF ). Os novos contratos beneficiarão do aumento de eficiência trazido pelo EOF – primeiro através de um bytecode ligeiramente reduzido devido à funcionalidade de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou custos de gas reduzidos.
Após a introdução do EOF, a atualização adicional tornou-se mais fácil, atualmente o desenvolvimento mais avançado é a extensão aritmética do módulo EVM ( EVM-MAX ). O EVM-MAX cria um conjunto de novas operações especificamente para operações de módulo e as coloca em um novo espaço de memória que não pode ser acessado por outros códigos de operação, o que torna possível a utilização de otimizações como a multiplicação de Montgomery.
Uma ideia mais recente é combinar o EVM-MAX com características de SIMD (Single Instruction Multiple Data) (, sendo que SIMD como um conceito do Ethereum já existe há muito tempo, sendo proposto pela primeira vez por Greg Colvin no EIP-616. SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes, e a combinação do EVM-MAX com SIMD torna essas duas escalabilidades orientadas ao desempenho uma combinação natural.
Na prática, isso será tratado de forma paralela.
)# Trabalho restante e ponderações
Atualmente, o EOF está programado para ser incluído no próximo hard fork. Apesar de sempre haver a possibilidade de ser removido na última hora — funcionalidades foram temporariamente removidas em forks anteriores, fazê-lo enfrentará grandes desafios. Remover o EOF significa que qualquer atualização futura ao EVM deverá ser feita sem o EOF, embora isso seja possível, pode ser mais difícil.
O principal compromisso do EVM está na complexidade do L1 e na complexidade da infraestrutura. O EOF é uma grande quantidade de código que precisa ser adicionada à implementação do EVM, e a verificação de código estático também é relativamente complexa. No entanto, em troca, podemos simplificar as linguagens de alto nível, simplificar a implementação do EVM e obter outros benefícios. Pode-se dizer que a prioridade na melhoria contínua da Ethereum L1 deve incluir e construir sobre o EOF.
Uma tarefa importante a realizar é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark sobre o consumo de gas de várias operações criptográficas.
Como interagir com as outras partes do roteiro?
A L1 ajusta seu EVM para que o L2 também possa fazer ajustes correspondentes com mais facilidade. Se ambos não realizarem ajustes sincronizados, isso pode causar incompatibilidades e trazer impactos negativos. Além disso, o EVM-MAX e o SIMD podem reduzir significativamente o custo de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Ele também facilita a substituição de mais pré-compilados por código EVM que pode executar a mesma tarefa, o que pode não afetar drasticamente a eficiência.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) abstração de conta
Que problema foi resolvido?
Atualmente, as transações só podem ser validadas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de conta foi projetada para ir além disso, permitindo que a lógica de validação da conta fosse qualquer código EVM. Isso pode habilitar uma série de aplicações:
Mudar para criptografia quântica resistente
Rotacionar a chave antiga ### é amplamente considerado uma prática de segurança recomendada (
Carteira de múltiplas assinaturas e carteira de recuperação social
Usar uma chave para operações de baixo valor, usar outra chave ) ou um conjunto de chaves ( para operações de alto valor
Permitir que o protocolo de privacidade funcione sem intermediários, reduzindo significativamente sua complexidade e eliminando um ponto de dependência central crucial.
Desde que a abstração de contas foi proposta em 2015, seu objetivo também se expandiu para incluir uma grande variedade de "objetivos convenientes", por exemplo, uma conta que não possui ETH mas tem alguns ERC20 pode usar ERC20 para pagar o gás.
MPC) computação multipartidária( é uma tecnologia com 40 anos de história, utilizada para dividir chaves em várias partes e armazená-las em vários dispositivos, utilizando técnicas de criptografia para gerar assinaturas, sem a necessidade de combinar diretamente essas partes da chave.
O EIP-7702 é uma proposta que está prevista para ser introduzida no próximo hard fork. O EIP-7702 é o resultado de um reconhecimento crescente da conveniência de abstração de contas para beneficiar todos os usuários ), incluindo usuários EOA (, com o objetivo de melhorar a experiência de todos os usuários a curto prazo e evitar a divisão em dois ecossistemas.
Este trabalho começou com o EIP-3074 e acabou formando o EIP-7702. O EIP-7702 fornece a "funcionalidade conveniente" da abstração de contas a todos os usuários, incluindo as contas externas EOA) de hoje, ou seja, contas controladas por assinaturas ECDSA(.
Embora alguns desafios ), especialmente o desafio da "conveniência" (, possam ser resolvidos por tecnologias progressivas como computação multipartidária ou EIP-7702, o principal objetivo de segurança da proposta de abstração de contas inicialmente apresentada só pode ser alcançado retrocedendo e resolvendo o problema original: permitir que o código de contrato inteligente controle a validação de transações. A razão pela qual isso ainda não foi realizado é a implementação segura, que é um desafio.
)# O que é, como funciona?
O núcleo da abstração de contas é simples: permite que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade vem de implementar isso de uma maneira que seja amigável à manutenção de uma rede descentralizada e prevenir ataques de negação de serviço.
Um desafio chave típico é o problema da falha múltipla:
Se houver 1000 funções de verificação de contas que dependem de um único valor S, e o valor atual S torna todas as transações no pool de memória válidas, então uma única transação que inverta o valor de S pode invalidar todas as outras transações no pool de memória. Isso permite que um atacante envie transações inúteis para o pool de memória a um custo muito baixo, bloqueando assim os recursos dos nós da rede.
Após anos de esforço, visando expandir funcionalidades enquanto limita o risco de negação de serviço ### DoS (, chegou-se finalmente à solução para alcançar a "abstração ideal de conta": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações dos usuários em duas etapas: verificação e execução. Todas as verificações são processadas primeiro, e todas as execuções são processadas em seguida. No pool de memória, as operações dos usuários são aceitas apenas quando a fase de verificação envolve apenas a sua própria conta e não lê variáveis de ambiente. Isso pode prevenir ataques de falha múltipla. Além disso, limites rigorosos de gas são impostos à etapa de verificação.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 foi projetado como um padrão de protocolo adicional )ERC(, porque na época os desenvolvedores de clientes Ethereum estavam focados na fusão )Merge(, sem energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 usa um objeto chamado operação do usuário, em vez de transações convencionais. No entanto, recentemente percebemos a necessidade de escrever pelo menos parte disso no protocolo.
Duas razões principais são as seguintes:
EntryPoint como a ineficiência inerente ao contrato: cada bundle tem um custo fixo de cerca de 100.000 gas, além de milhares de gas adicionais para cada operação do usuário.
Garantir a necessidade das propriedades do Ethereum: como a lista incluída criada que garante a necessidade de transferência para a conta do usuário abstrato.
Além disso, o ERC-4337 também expandiu duas funcionalidades:
Agente de pagamento ) Paymasters (: permite que uma conta pague as taxas em nome de outra conta, o que viola a regra de que apenas a conta do remetente pode ser acessada na fase de validação. Portanto, foi introduzido um tratamento especial para garantir a segurança do mecanismo de agente de pagamento.
Agregadores): suporta funções de agregação de assinaturas, como agregação BLS ou agregação baseada em SNARK. Isso é necessário para alcançar a eficiência máxima de dados em Rollup.
(# Trabalho restante e ponderações
Atualmente, a principal questão a resolver é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem recebido atenção recentemente é o EIP-7701, que implementa a abstração de contas sobre o EOF. Uma conta pode ter uma parte de código separada para validação; se a conta tiver essa parte de código configurada, essa parte será executada no passo de validação das transações provenientes dessa conta.
O fascínio deste método reside no fato de que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:
Incorporar o EIP-4337 como parte do protocolo
Um novo tipo de EOA, onde o algoritmo de assinatura é a execução de código EVM
Se começarmos a estabelecer limites rigorosos para a complexidade do código executável durante a verificação - não permitindo o acesso a estados externos, e mesmo o limite de gas estabelecido inicialmente sendo tão baixo que se torna inválido para aplicações de resistência quântica ou proteção de privacidade - a segurança desse método se torna muito clara: é apenas substituir a verificação ECDSA por uma execução de código EVM que requer um tempo semelhante.
No entanto, com o passar do tempo, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários, assim como a resistência quântica, são extremamente importantes. Para isso, precisamos encontrar maneiras mais flexíveis de abordar o risco de negação de serviço )DoS###, sem exigir que os passos de verificação sejam extremamente simplistas.
A principal compensação parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" versus "esperar mais tempo para possivelmente obter uma solução mais ideal", sendo o método ideal uma espécie de abordagem híbrida. Uma abordagem híbrida é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é implantar primeiro uma versão de abstração de conta mais ambiciosa na L2. No entanto, o desafio que isso enfrenta é que a equipe da L2 precisa estar confiante no trabalho de adoção da proposta para estar disposta a implementá-la, especialmente para garantir que L1 e/ou outras L2 possam adotar soluções compatíveis no futuro.
Outra aplicação que precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado relacionado à conta na L1 ou em L2 dedicado, mas pode ser usada na L1 e em qualquer L2 compatível. Fazer isso de forma eficaz pode exigir que a L2 suporte opcodes como L1SLOAD ou REMOTESTATICCALL, mas isso também requer que a implementação da abstração de contas na L2 suporte essas operações.
(# Como interage com as outras partes do roteiro?
A lista de inclusão precisa suportar transações de abstração de conta. Na prática, a necessidade de listas de inclusão é na verdade muito semelhante à necessidade de pools de memória descentralizados, embora a flexibilidade seja um pouco maior para listas de inclusão. Além disso, a implementação da abstração de conta deve ser coordenada tanto quanto possível entre L1 e L2. Se no futuro esperamos que a maioria dos usuários utilize Rollup de armazenamento de chaves, o design da abstração de conta deve
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
11 gostos
Recompensa
11
7
Republicar
Partilhar
Comentar
0/400
UnluckyMiner
· 08-06 21:50
ainda é o bull EVM
Ver originalResponder0
AirdropLicker
· 08-06 03:35
Adeus, bombear Gas chegou.
Ver originalResponder0
ChainWanderingPoet
· 08-05 23:23
Os custos precisam ser otimizados, nem o BTC consegue resolver isso.
Ver originalResponder0
LeverageAddict
· 08-03 22:13
shitcoin já corre EVM, enquanto a máquina Éter ainda está travada
Ver originalResponder0
FrogInTheWell
· 08-03 22:10
Afinal, quem não quer otimizar um pouco o EVM?
Ver originalResponder0
Ser_This_Is_A_Casino
· 08-03 22:09
Aprimorar brutalmente, já era hora de tomar conta disso.
Perspectivas futuras do protocolo Ethereum: atualização do EVM, abstração de contas e otimização das taxas de transação
O futuro possível do protocolo Ethereum(seis): prosperidade
O design do protocolo Ethereum contém muitos "detalhes" que são cruciais para seu sucesso. Cerca de metade do conteúdo envolve diferentes tipos de melhorias no EVM, enquanto o restante é composto por vários tópicos de nicho, que é o que significa "prosperidade".
Prosperidade: Objetivo-chave
melhoria do EVM
Que problema foi resolvido?
Atualmente, é difícil realizar análises estáticas no EVM, o que torna difícil criar implementações eficientes, validar formalmente o código e expandir ainda mais. Além disso, a eficiência do EVM é baixa, dificultando a implementação de muitas criptografias avançadas, a menos que haja suporte explícito através de pré-compilações.
O que é, como funciona?
O primeiro passo do atual roteiro de melhorias do EVM é o formato de objeto EVM (EOF), planejado para ser incluído na próxima bifurcação dura. EOF é uma série de EIPs que especificam uma nova versão do código EVM, com muitas características únicas, sendo a mais notável:
Os contratos antigos continuarão a existir e poderão ser criados, embora possam eventualmente ser gradualmente descontinuados ( e até mesmo forçados a serem convertidos para código EOF ). Os novos contratos beneficiarão do aumento de eficiência trazido pelo EOF – primeiro através de um bytecode ligeiramente reduzido devido à funcionalidade de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou custos de gas reduzidos.
Após a introdução do EOF, a atualização adicional tornou-se mais fácil, atualmente o desenvolvimento mais avançado é a extensão aritmética do módulo EVM ( EVM-MAX ). O EVM-MAX cria um conjunto de novas operações especificamente para operações de módulo e as coloca em um novo espaço de memória que não pode ser acessado por outros códigos de operação, o que torna possível a utilização de otimizações como a multiplicação de Montgomery.
Uma ideia mais recente é combinar o EVM-MAX com características de SIMD (Single Instruction Multiple Data) (, sendo que SIMD como um conceito do Ethereum já existe há muito tempo, sendo proposto pela primeira vez por Greg Colvin no EIP-616. SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes, e a combinação do EVM-MAX com SIMD torna essas duas escalabilidades orientadas ao desempenho uma combinação natural.
Na prática, isso será tratado de forma paralela.
)# Trabalho restante e ponderações
Atualmente, o EOF está programado para ser incluído no próximo hard fork. Apesar de sempre haver a possibilidade de ser removido na última hora — funcionalidades foram temporariamente removidas em forks anteriores, fazê-lo enfrentará grandes desafios. Remover o EOF significa que qualquer atualização futura ao EVM deverá ser feita sem o EOF, embora isso seja possível, pode ser mais difícil.
O principal compromisso do EVM está na complexidade do L1 e na complexidade da infraestrutura. O EOF é uma grande quantidade de código que precisa ser adicionada à implementação do EVM, e a verificação de código estático também é relativamente complexa. No entanto, em troca, podemos simplificar as linguagens de alto nível, simplificar a implementação do EVM e obter outros benefícios. Pode-se dizer que a prioridade na melhoria contínua da Ethereum L1 deve incluir e construir sobre o EOF.
Uma tarefa importante a realizar é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark sobre o consumo de gas de várias operações criptográficas.
Como interagir com as outras partes do roteiro?
A L1 ajusta seu EVM para que o L2 também possa fazer ajustes correspondentes com mais facilidade. Se ambos não realizarem ajustes sincronizados, isso pode causar incompatibilidades e trazer impactos negativos. Além disso, o EVM-MAX e o SIMD podem reduzir significativamente o custo de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Ele também facilita a substituição de mais pré-compilados por código EVM que pode executar a mesma tarefa, o que pode não afetar drasticamente a eficiência.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) abstração de conta
Que problema foi resolvido?
Atualmente, as transações só podem ser validadas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de conta foi projetada para ir além disso, permitindo que a lógica de validação da conta fosse qualquer código EVM. Isso pode habilitar uma série de aplicações:
Permitir que o protocolo de privacidade funcione sem intermediários, reduzindo significativamente sua complexidade e eliminando um ponto de dependência central crucial.
Desde que a abstração de contas foi proposta em 2015, seu objetivo também se expandiu para incluir uma grande variedade de "objetivos convenientes", por exemplo, uma conta que não possui ETH mas tem alguns ERC20 pode usar ERC20 para pagar o gás.
MPC) computação multipartidária( é uma tecnologia com 40 anos de história, utilizada para dividir chaves em várias partes e armazená-las em vários dispositivos, utilizando técnicas de criptografia para gerar assinaturas, sem a necessidade de combinar diretamente essas partes da chave.
O EIP-7702 é uma proposta que está prevista para ser introduzida no próximo hard fork. O EIP-7702 é o resultado de um reconhecimento crescente da conveniência de abstração de contas para beneficiar todos os usuários ), incluindo usuários EOA (, com o objetivo de melhorar a experiência de todos os usuários a curto prazo e evitar a divisão em dois ecossistemas.
Este trabalho começou com o EIP-3074 e acabou formando o EIP-7702. O EIP-7702 fornece a "funcionalidade conveniente" da abstração de contas a todos os usuários, incluindo as contas externas EOA) de hoje, ou seja, contas controladas por assinaturas ECDSA(.
Embora alguns desafios ), especialmente o desafio da "conveniência" (, possam ser resolvidos por tecnologias progressivas como computação multipartidária ou EIP-7702, o principal objetivo de segurança da proposta de abstração de contas inicialmente apresentada só pode ser alcançado retrocedendo e resolvendo o problema original: permitir que o código de contrato inteligente controle a validação de transações. A razão pela qual isso ainda não foi realizado é a implementação segura, que é um desafio.
)# O que é, como funciona?
O núcleo da abstração de contas é simples: permite que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade vem de implementar isso de uma maneira que seja amigável à manutenção de uma rede descentralizada e prevenir ataques de negação de serviço.
Um desafio chave típico é o problema da falha múltipla:
Se houver 1000 funções de verificação de contas que dependem de um único valor S, e o valor atual S torna todas as transações no pool de memória válidas, então uma única transação que inverta o valor de S pode invalidar todas as outras transações no pool de memória. Isso permite que um atacante envie transações inúteis para o pool de memória a um custo muito baixo, bloqueando assim os recursos dos nós da rede.
Após anos de esforço, visando expandir funcionalidades enquanto limita o risco de negação de serviço ### DoS (, chegou-se finalmente à solução para alcançar a "abstração ideal de conta": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações dos usuários em duas etapas: verificação e execução. Todas as verificações são processadas primeiro, e todas as execuções são processadas em seguida. No pool de memória, as operações dos usuários são aceitas apenas quando a fase de verificação envolve apenas a sua própria conta e não lê variáveis de ambiente. Isso pode prevenir ataques de falha múltipla. Além disso, limites rigorosos de gas são impostos à etapa de verificação.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 foi projetado como um padrão de protocolo adicional )ERC(, porque na época os desenvolvedores de clientes Ethereum estavam focados na fusão )Merge(, sem energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 usa um objeto chamado operação do usuário, em vez de transações convencionais. No entanto, recentemente percebemos a necessidade de escrever pelo menos parte disso no protocolo.
Duas razões principais são as seguintes:
Além disso, o ERC-4337 também expandiu duas funcionalidades:
(# Trabalho restante e ponderações
Atualmente, a principal questão a resolver é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem recebido atenção recentemente é o EIP-7701, que implementa a abstração de contas sobre o EOF. Uma conta pode ter uma parte de código separada para validação; se a conta tiver essa parte de código configurada, essa parte será executada no passo de validação das transações provenientes dessa conta.
O fascínio deste método reside no fato de que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:
Se começarmos a estabelecer limites rigorosos para a complexidade do código executável durante a verificação - não permitindo o acesso a estados externos, e mesmo o limite de gas estabelecido inicialmente sendo tão baixo que se torna inválido para aplicações de resistência quântica ou proteção de privacidade - a segurança desse método se torna muito clara: é apenas substituir a verificação ECDSA por uma execução de código EVM que requer um tempo semelhante.
No entanto, com o passar do tempo, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários, assim como a resistência quântica, são extremamente importantes. Para isso, precisamos encontrar maneiras mais flexíveis de abordar o risco de negação de serviço )DoS###, sem exigir que os passos de verificação sejam extremamente simplistas.
A principal compensação parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" versus "esperar mais tempo para possivelmente obter uma solução mais ideal", sendo o método ideal uma espécie de abordagem híbrida. Uma abordagem híbrida é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é implantar primeiro uma versão de abstração de conta mais ambiciosa na L2. No entanto, o desafio que isso enfrenta é que a equipe da L2 precisa estar confiante no trabalho de adoção da proposta para estar disposta a implementá-la, especialmente para garantir que L1 e/ou outras L2 possam adotar soluções compatíveis no futuro.
Outra aplicação que precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado relacionado à conta na L1 ou em L2 dedicado, mas pode ser usada na L1 e em qualquer L2 compatível. Fazer isso de forma eficaz pode exigir que a L2 suporte opcodes como L1SLOAD ou REMOTESTATICCALL, mas isso também requer que a implementação da abstração de contas na L2 suporte essas operações.
(# Como interage com as outras partes do roteiro?
A lista de inclusão precisa suportar transações de abstração de conta. Na prática, a necessidade de listas de inclusão é na verdade muito semelhante à necessidade de pools de memória descentralizados, embora a flexibilidade seja um pouco maior para listas de inclusão. Além disso, a implementação da abstração de conta deve ser coordenada tanto quanto possível entre L1 e L2. Se no futuro esperamos que a maioria dos usuários utilize Rollup de armazenamento de chaves, o design da abstração de conta deve