Seja um mercado em alta ou em baixa, o ecossistema Ethereum está em constante construção e auto-otimização. Entre eles, o Account Abstraction (AA) fez progressos importantes nos últimos anos e penetrou em todas as partes do ecossistema Ethereum, incluindo aplicativos, infraestrutura, usuários e desenvolvedores. Podemos prever que a adoção em larga escala do AA reduzirá o limite de uso do blockchain como um todo e introduzirá a experiência do usuário da web2 na indústria da web3.
Neste artigo, a equipe do BlockPI aprofundará sua compreensão do AA e compartilhará seu pensamento da perspectiva de um provedor de serviços de infraestrutura.
EOA e carteira de contrato
O conceito de AA decorre das limitações das contas EOA. Uma conta EOA (conta de propriedade externa) é uma conta de usuário no Ethereum, representada por uma chave pública (endereço blockchain) e acessada por meio de uma chave privada. É um componente importante do ecossistema Ethereum, permitindo que os usuários transfiram dinheiro no blockchain ou interajam com contratos inteligentes. No entanto, para muitas pessoas, usar um EOA pode ser uma tarefa desafiadora por si só. Além disso, a conta EOA atual ainda apresenta alguns inconvenientes de uso, o que afeta a experiência do usuário.
A primeira é a questão da taxa de gás. Cada transação custará ao usuário uma quantidade considerável de ETH como taxa de gás (pegando o preço do gás de 25 Gwei como exemplo, a taxa de gás para uma simples transferência de ETH é de cerca de 0,5 dólares americanos e será mais cara para a interação do contrato ou quando o preço do gás é mais alto) . Isso torna as pequenas transações muito caras, especialmente durante períodos de forte congestionamento da rede. Além disso, o gás só pode ser pago com ETH, o que significa que os usuários devem manter ETH em suas carteiras, o que constitui uma grande barreira de entrada para muitos usuários.
Em segundo lugar, para algumas operações complexas que os usuários desejam implementar, o EOA deve contar com outros contratos inteligentes. Por exemplo, se um usuário deseja definir uma transferência periódica cronometrada, o usuário precisa transferir ETH para um contrato inteligente com esta função para realizar esta operação.
O terceiro problema com o EOA é o algoritmo de criptografia de assinatura fixa. A rede Ethereum usa um algoritmo de assinatura digital chamado secp256k1 para garantir a autenticidade e segurança das transações. Esse algoritmo é codificado no sistema e os usuários não podem optar por usar outros algoritmos de criptografia.
Além dos três problemas acima, o relacionamento de ligação entre a chave pública e a chave privada do EOA também é um problema. A chave privada é a única maneira de os usuários acessarem o EOA. Se a chave privada for perdida, ela não será recuperada. Isso também significa que todos os ativos dentro do EOA associados a ele serão irrecuperáveis.
Ao mesmo tempo, o EOA também apresenta limitações ao executar determinadas tarefas lineares. Por exemplo, se um usuário deseja aprovar, trocar e desaprovar tokens em uma operação, três transações separadas precisam ser executadas, o que é ineficiente e demorado.
A boa notícia é que as carteiras contratuais podem resolver todos os problemas acima. Uma carteira de contrato é essencialmente um tipo específico de conta de contrato inteligente que implementa AA, que pode ser usada como carteira de usuário no Ethereum. E pode fornecer aos usuários uma maneira mais flexível e personalizada de gerenciar fundos. Contanto que seja a lógica que pode ser realizada pelo contrato inteligente Ethereum, a carteira do contrato pode realizar e fornecer as funções correspondentes.
Especificamente, várias operações de carteira de contrato podem ser empacotadas em uma transação on-chain, e essas operações podem compartilhar o custo do gás dessa transação. Se o terceiro estiver disposto a pagar a taxa de Gás, não há necessidade de pagar Gás para usuários que usam a carteira do contrato. As carteiras de contrato também podem concluir várias tarefas lineares ao mesmo tempo. Além disso, a carteira de contrato também suporta o algoritmo de criptografia de assinaturas personalizadas e define a função de recuperação de carteira e assim por diante.
À medida que a discussão sobre as vantagens das carteiras de contrato continua, a comunidade Ethereum realmente conduziu pesquisas de longo prazo sobre carteiras de contrato. Embora muitos EIPs tenham explorado questões relacionadas à abstração de contas, a partir de 2021, nenhum padrão unificado foi estabelecido. Abaixo estão vários EIPs representativos.
EIP-86
Originalmente proposto por Vitalik Buterin em 2017. O esquema implementa uma série de mudanças com o objetivo comum de "abstrair" a verificação de assinatura e verificação de nonce, permitindo assim que os usuários criem "contratos de conta" que executam verificação arbitrária de assinatura/nonce.
EIP-2938
Apresentado em 2020. O título deste EIP é Account Abstraction. O conceito de AA está bem descrito neste EIP. Ele introduz um novo tipo de transação, a transação AA. A transação é iniciada pelo endereço do ponto de entrada (endereço EntryPoint) e chama a carteira de contrato AA. O EIP-2938 fornece uma especificação unificada e introduz oficialmente a abstração da conta AA no consenso Ethereum. Especificamente, ele apresenta dois novos opcodes, três variáveis globais e uma estrutura de carga diferente para o consenso Ethereum.
EIP-3074
Apresentado em 2020. Este EIP apresenta duas instruções EVM, AUTH e AUTHCALL. AUTH define a variável de ambiente de acordo com a autoridade de assinatura ECDSA. AUTHCALL envia a chamada como a conta autorizada. Isso permite que contratos inteligentes enviem transações em nome do EOA. Mas ainda não é uma solução perfeita para AA. No processo de transação de autorização, o EIP-3074 possui certas restrições na transmissão do valor original. E se um usuário perder o acesso ao EOA, ainda não haverá como recuperar seus ativos. Se a chave privada vazar, o usuário precisará transferir todos os ativos para a nova conta.
Nenhuma das propostas acima foi formalmente incorporada ao protocolo Ethereum devido à necessidade de mudanças na camada de consenso ou porque as propostas não eram suficientemente abrangentes. Portanto, a comunidade Ethereum continuou a explorar como introduzir o AA no protocolo Ethereum sem alterar o consenso e, finalmente, propôs o EIP4337.
ERC - 4337
O EIP-4337 foi originalmente proposto em setembro de 2021 e autorizado como ERC-4337 em março de 2023. Seus autores incluem Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson e Tjaden Hess.
EIP-4337 é uma proposta disruptiva que pode introduzir AA sem alterar o protocolo principal do Ethereum. O EIP-4337 acabou se tornando o padrão ERC-4337, que os construtores podem usar para implementar suas próprias carteiras de contratos inteligentes. Ao mesmo tempo, o padrão também introduz algumas infra-estruturas adicionais, incluindo "Bundlers" e "UserOperation mempool". Dessa forma, ele realmente replica um mempool Ethereum com funções semelhantes na camada superior do sistema blockchain. O que o usuário envia não é mais uma única transação, mas uma UserOperation. Várias UserOperations podem ser empacotadas em uma única transação e enviadas para a Ethereum.
A seguir, uma explicação técnica detalhada do ERC-4337 no Ethereum [documentação oficial] (junto com alguns comentários úteis.
Principais funções e definições do ERC-4337
UserOperation — descreve a estrutura de uma transação enviada em nome de um usuário. Para evitar confusão, ele não é chamado de "transação" e será enviado ao Bundler para ser empacotado como um Bundle com outras UserOperations. O Bundle é então enviado na cadeia como uma única transação.
Sender — conta de contrato que envia UserOperation. O contrato de carteira deve seguir o padrão ERC-4337 para configurar a interface IAccount.
EntryPoint — contrato singleton global que executa o pacote UserOperations. Os Bundlers/Clientes autorizam EntryPoints suportados. O contrato é auditado e aprovado para implantação pela equipe Infinitism e é responsável por lidar com todas as UserOperations e conectar contratos com outras funções, incluindo Wallet Factory, Aggregator e Paymaster. O contrato está todo no mesmo endereço na cadeia compatível com EVM.
Bundler — O nó que empacota várias UserOperations do mempool e cria a transação EntryPoint.handleOps() (o produtor de bloco atual). O serviço Bundler pode ser executado independentemente dos nós de blockchain e enviar UserOperations empacotadas via RPC.
Agregador — Contrato auxiliar confiável por contas para verificar assinaturas agregadas. Agregadores de assinatura suportados pela lista de permissões de empacotadores/clientes. O Aggregator deve seguir o padrão ERC-4337 para configurar a interface do IAggregator.
Paymaster — um contrato inteligente que pode pagar Gas em seu nome. Se ele depositar ETH suficiente no contrato EntryPoint, poderá pagar a taxa de gás pela UserOperation para o remetente, implementando efetivamente a abstração de gás. Paymaster deve seguir o padrão ERC-4337 para configurar a interface Paymaster. O Pagador pode entrar em um acordo com o Remetente. Por exemplo, o Sender paga USDC ao Paymaster e o Paymaster usa ETH para pagar o Gas das UserOperations que envia. Na verdade, o Paymaster pode optar por oferecer suporte a qualquer token, incluindo tokens ERC-20 e até mesmo tokens em outras cadeias.
Wallet Factory — Um contrato inteligente que pode criar carteiras de contrato para usuários ERC-4337. A implantação do Wallet Factory não requer permissão. Como um contrato inteligente on-chain, seu código é aberto ao público e qualquer pessoa pode revisá-lo. Uma Wallet Factory amplamente utilizada deve ser totalmente auditada por profissionais.
O diagrama abaixo explica como o contrato do EntryPoint interage com outros atores.
Os empacotadores chamam a função handleOps do contrato EntryPoint, que aceita uma UserOperation como entrada.
handleOps verificará UserOperation na cadeia, verificará se ele é assinado pelo endereço de carteira de contrato inteligente especificado e confirmará se a carteira possui Gas suficiente para compensar o Bundler.
Se a verificação for aprovada, o handleOps executará a função de carteira de contrato inteligente de acordo com a função e os parâmetros de entrada definidos no calldata de UserOperation.
Por outro lado, quando o Bundler usa o EOA para acionar a função handleOps, uma taxa de Gas será cobrada. A carteira de contrato inteligente pode pagar taxas de gás aos empacotadores a partir do saldo de sua própria conta ou solicitar que o contrato Paymaster pague por isso. UserOperations não pode passar na etapa de verificação off-chain sem Gas suficiente, ou seja, falha antes de executar a transação na cadeia. Mesmo se houver Gas suficiente, UserOperations ainda pode falhar devido a motivos como erros de tempo de execução durante a execução. Para uma UserOperation, independentemente de a execução do contrato ser bem-sucedida ou não, o contrato EntryPoint pagará a taxa de Gas ao Bundler que aciona a função handleOps.
(Trecho da documentação oficial:
Depois que o ERC-4337 entrar em vigor, os usuários agora podem iniciar transações blockchain de duas maneiras. Uma é a forma tradicional, ou seja, o EOA inicia diretamente a transação. A outra é usar o padrão ERC-4337 para iniciar o UserOperation por meio do Bundler e, em seguida, o Bundler irá empacotá-lo com outros UserOperations e enviá-lo para a cadeia. O fluxograma abaixo ilustra a diferença entre uma transação de envio EOA normal e uma carteira de contrato ERC-4337 enviar UserOperation.
A estrada foi pavimentada, mas ainda não há muitos pedestres
O ERC-4337 fornece uma estrutura poderosa para usuários e desenvolvedores usarem e criarem AA no Ethereum. Embora esse quadro seja um avanço importante, ainda existem alguns desafios e incertezas que precisam ser enfrentados e resolvidos.
A adoção de AA ainda está em sua infância. De acordo com o painel de análise Dune ERC-4337 (*[ERC-4337 Account Abstraction](de @niftytable), apenas 65k+ UserOperations foram executadas na cadeia, 90% das quais vieram do Polygon. Portanto, o número de UserOperations atualmente executadas ainda é muito pequeno, e a maioria deles Parte disso é teste do desenvolvedor, e apenas uma pequena parte vem de usuários reais. Percebemos que os produtos que integraram o AA ainda estão em estágio inicial. No momento, podemos observar que Os empacotadores como um todo ainda estão em estado de perda, e a perda atual é de cerca de mais de 700 MATICs. Isso é causado principalmente por alguns empacotadores no Polygon estimarem incorretamente o gás necessário, resultando no gás retornado pelo EntryPoint sendo menor que o gás consumido pelo Bundle enviado. Este problema precisa ser resolvido no nível do cliente Bundler.
Além disso, há algumas questões que precisam ser abordadas. Um dos problemas é como os Bundlers lidam com falhas de transação.
Depois de agrupar várias UserOperations, os Bundlers primeiro simularão a transação, detectarão se haverá falha na execução do contrato e calcularão se a taxa de Gas devolvida pelo Remetente ou Pagador é maior que a taxa de Gas paga.
Se for lucrativo, o Bundler envia esse lote de UserOperations como uma transação para o nó do bloco. No entanto, ainda é possível que a transação falhe, fazendo com que o Bundler pague a taxa de Gás, mas não receba o reembolso de Gás do EntryPoint. Por exemplo, um usuário pode enviar ações para diferentes empacotadores. Se houver margem de lucro e a simulação for bem-sucedida, os Bundlers a comprometerão com a cadeia. Nesse caso, se uma UserOperation for enviada ao nó produtor do bloco por diferentes Bundlers ao mesmo tempo, apenas uma transação será bem-sucedida, o que significa que apenas um Bundler receberá a taxa de gás devolvida pelo EntryPoint e todos os outros Bundlers falharão devido ao encadeamento e perder gás. Embora alguém possa argumentar que esse comportamento deva ser considerado um ataque mal-intencionado e argumentar que o Bundler pode banir o endereço do remetente e rejeitar qualquer solicitação futura desse endereço, essa não é uma solução razoável porque os usuários podem realizar essa ação involuntariamente. Esse problema precisa ser tratado adequadamente no código, talvez por meio de um mempool público que esteja em desenvolvimento. Além disso, os Bundlers podem sofrer perdas devido a flutuações repentinas de gás, mesmo que a transação seja realizada com sucesso e os resultados da simulação mostrem que há espaço para lucro.
Outra questão é o valor máximo extraível (MEV) que pode ser obtido do AA. No contexto do Ethereum, MEV geralmente se refere ao valor que os mineradores ou outros processadores de transações extraem manipulando a ordem das transações em um bloco ou inserindo suas próprias transações em um bloco. Pode-se notar que a lógica do MEV também pode ser aplicada ao AA. Isso ocorre porque no AA, os Bundlers podem sequenciar livremente UserOps, o que lhes dá a possibilidade de adquirir MEV. No entanto, se o Bundler pode extrair MEV depende se UserOperations suficientes podem ser agrupadas. Agora, todo o mercado de AA ainda está em sua infância, então o Bundler MEV também pode ser considerado em sua infância. Pode-se ver que o MEV da AA pode se desenvolver em duas direções: uma é semelhante à rede principal Ethereum, com a participação de participantes como Flashbots, Ultra Sound e BloXroute; a outra direção é formar um consenso Bundler para implementar uma classificação justa. E este último eliminaria completamente a possibilidade de extrair MEV em AA.
desenvolvimento futuro
pool de memórias público
Embora o ecossistema AA já esteja operacional, ainda há muito trabalho de desenvolvimento a ser feito. Olhando para todo o ecossistema AA, a maior peça que falta agora é o mempool público. A equipe Etherspot, desenvolvedores do cliente Skandha Bundler, está atualmente desenvolvendo uma rede p2p com um mempool público. Espera-se que uma rede p2p de mempools públicos seja lançada em agosto deste ano.
Algoritmo de pacote
Ao longo do caminho, a Fundação Ethereum financiou várias equipes de desenvolvimento de AA excelentes. Até agora, vários clientes Bundler foram desenvolvidos e estão atualmente disponíveis. Entre eles, alguns são muito maduros. Eles são Candide (Voltaire Bundler escrito em Python), Pimlico (Alto Bundler escrito em Type), Etherspot (Skandha Bundler escrito em Type), Stackup (Stackup-Bundler escrito em Go), etc.
Aí entra a questão da estratégia de embalagem. Atualmente, devido ao pequeno número de UserOperations, os Bundlers podem adotar uma lógica de empacotamento simples, como um intervalo de tempo fixo ou um determinado número de UserOperations em cada Bundle. No entanto, à medida que o número de UserOperations aumenta, especialmente após a introdução do mempool público, a estratégia para selecionar e empacotar UserOperations torna-se mais complexa. A razão é simples: na ecologia AA, não há mecanismo semelhante ao protocolo de consenso blockchain, e o grupo Bundler tornou-se uma floresta escura.Cada Bundler prioriza tarefas de acordo com seus próprios interesses e compete entre si. Ao contrário dos mempools públicos, os mempools privados podem aparecer antes. Como empacotar UserOperations do mempool público não é lucrativo, ainda é possível empacotar UserOperations no mempool privado. Neste caso, o Empacotador é mais competitivo do que outros Empacotadores na hora de embalar.
Além disso, com a popularização gradual do mempool público, as UserOperations nele possuem várias características, como diferentes expectativas de lucro do Gas e complexidade de execução on-chain. Os empacotadores realizarão simulações off-chain para avaliar a lucratividade de várias combinações de UserOperations para estabelecer suas respectivas estratégias de empacotamento. Empacotar mais UserOperations tem o potencial de gerar maiores lucros, mas também aumenta o risco de falhas de validação. Mesmo que a verificação seja aprovada, o risco de falha na execução da cadeia ainda existe. Em contraste, as UserOperations menos empacotadas fazem o oposto. Os empacotadores precisam definir seus próprios parâmetros de gás de transação, o que afetará a prioridade dos produtores de bloco para executar esta transação. Sob diferentes preços estimados do gás e condições de volatilidade do gás, os empacotadores podem ter diferentes estratégias de embalagem. Ao mesmo tempo, também é necessário considerar o custo de recursos de computação de hardware local e recursos de nó de blockchain para esses cálculos de verificação e política. Além disso, os Bundlers também precisam trabalhar duro para fornecer aos usuários uma boa experiência de usuário e garantir que os usuários não enfrentem atrasos excessivos após o envio de UserOperations.
Embora as soluções para esses desafios ainda não estejam claras, podemos dizer com confiança que o desenvolvimento da indústria de AA e os esforços conjuntos dos desenvolvedores acabarão por resolver esses problemas. Como construtor de infraestrutura, a BlockPI espera desempenhar um papel de solucionador de problemas no desenvolvimento da indústria de AA, seja como desenvolvedor ou para fornecer infraestrutura compatível com AA para outros desenvolvedores.
A infraestrutura deve se adaptar ao AA
A AA abstrai as várias funções envolvidas nas transações on-chain, incluindo Remetente, Bundlers, pagadores de gás, carteiras de contrato e Signatários, para que os usuários tenham um maior grau de liberdade ao usar o blockchain. Ao mesmo tempo, os provedores de infraestrutura podem implantar esses serviços de forma independente, de acordo com seu próprio julgamento no mercado.
Para se adaptar à adoção em larga escala do AA, os provedores de infraestrutura precisam primeiro fornecer pelo menos dois serviços básicos: o serviço Bundler e o serviço Paymaster.
Nos serviços Bundler, os provedores de infraestrutura podem precisar desenvolver mempools privados com Bundlers para fornecer uma boa experiência ao usuário. Especificamente, os provedores de infraestrutura precisam integrar vários clientes Bundler para garantir a estabilidade dos serviços Bundler. Esses clientes Bundler atualmente fornecem aos usuários vários métodos JSON RPC padrão fornecidos pelo grupo de desenvolvimento principal ERC-4337. É previsível que mais métodos RPC estarão disponíveis para os usuários no futuro. Os provedores de serviços de infraestrutura precisam atualizar o suporte para esses métodos em tempo hábil durante esse processo.
Além disso, é muito importante otimizar entre a API do Bundler e o RPC do cliente do nó de origem. Os clientes de nó atuais não são otimizados para AA. Alguns métodos da API do Bundler exigem que o nó forneça um índice de dados para o AA. Por exemplo, quando o cliente atual procura UserOperation por hash, ele precisa verificar os logs de contrato do EntryPoint em todos os blocos. Se não houver índice de dados, o consumo de recursos de hardware dessa solicitação única será bastante grande e o tempo de retorno da solicitação também será muito longo.
Além disso, para fornecer aos usuários uma experiência de usuário sem gás e serviços diversificados, os provedores de infraestrutura precisam cooperar com diferentes provedores de serviços Paymaster para integrar diferentes serviços Paymaster. Ao mesmo tempo, de acordo com a demanda do mercado, os provedores de infraestrutura também podem projetar soluções integradas mais convenientes com base nos serviços Paymaster existentes. Outros serviços, como assinaturas agregadas, fábricas de carteiras, etc., também são direções potenciais para o futuro desenvolvimento e integração da infraestrutura.
Em suma, para se adaptar à aplicação em larga escala de AA, os provedores de infraestrutura precisam melhorar e expandir continuamente seus serviços. Isso inclui otimizar os serviços do Bundler, cooperar com diferentes provedores de serviços Paymaster, integrar várias interfaces de API e desenvolver outros serviços em potencial. À medida que a indústria de AA continua a se desenvolver, esses esforços ajudarão a fornecer uma experiência de blockchain mais eficiente, segura e conveniente.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Como a infraestrutura capacita bilhões de usuários por meio da abstração de contas
Seja um mercado em alta ou em baixa, o ecossistema Ethereum está em constante construção e auto-otimização. Entre eles, o Account Abstraction (AA) fez progressos importantes nos últimos anos e penetrou em todas as partes do ecossistema Ethereum, incluindo aplicativos, infraestrutura, usuários e desenvolvedores. Podemos prever que a adoção em larga escala do AA reduzirá o limite de uso do blockchain como um todo e introduzirá a experiência do usuário da web2 na indústria da web3.
Neste artigo, a equipe do BlockPI aprofundará sua compreensão do AA e compartilhará seu pensamento da perspectiva de um provedor de serviços de infraestrutura.
EOA e carteira de contrato
O conceito de AA decorre das limitações das contas EOA. Uma conta EOA (conta de propriedade externa) é uma conta de usuário no Ethereum, representada por uma chave pública (endereço blockchain) e acessada por meio de uma chave privada. É um componente importante do ecossistema Ethereum, permitindo que os usuários transfiram dinheiro no blockchain ou interajam com contratos inteligentes. No entanto, para muitas pessoas, usar um EOA pode ser uma tarefa desafiadora por si só. Além disso, a conta EOA atual ainda apresenta alguns inconvenientes de uso, o que afeta a experiência do usuário.
A primeira é a questão da taxa de gás. Cada transação custará ao usuário uma quantidade considerável de ETH como taxa de gás (pegando o preço do gás de 25 Gwei como exemplo, a taxa de gás para uma simples transferência de ETH é de cerca de 0,5 dólares americanos e será mais cara para a interação do contrato ou quando o preço do gás é mais alto) . Isso torna as pequenas transações muito caras, especialmente durante períodos de forte congestionamento da rede. Além disso, o gás só pode ser pago com ETH, o que significa que os usuários devem manter ETH em suas carteiras, o que constitui uma grande barreira de entrada para muitos usuários.
Em segundo lugar, para algumas operações complexas que os usuários desejam implementar, o EOA deve contar com outros contratos inteligentes. Por exemplo, se um usuário deseja definir uma transferência periódica cronometrada, o usuário precisa transferir ETH para um contrato inteligente com esta função para realizar esta operação.
O terceiro problema com o EOA é o algoritmo de criptografia de assinatura fixa. A rede Ethereum usa um algoritmo de assinatura digital chamado secp256k1 para garantir a autenticidade e segurança das transações. Esse algoritmo é codificado no sistema e os usuários não podem optar por usar outros algoritmos de criptografia.
Além dos três problemas acima, o relacionamento de ligação entre a chave pública e a chave privada do EOA também é um problema. A chave privada é a única maneira de os usuários acessarem o EOA. Se a chave privada for perdida, ela não será recuperada. Isso também significa que todos os ativos dentro do EOA associados a ele serão irrecuperáveis.
Ao mesmo tempo, o EOA também apresenta limitações ao executar determinadas tarefas lineares. Por exemplo, se um usuário deseja aprovar, trocar e desaprovar tokens em uma operação, três transações separadas precisam ser executadas, o que é ineficiente e demorado.
A boa notícia é que as carteiras contratuais podem resolver todos os problemas acima. Uma carteira de contrato é essencialmente um tipo específico de conta de contrato inteligente que implementa AA, que pode ser usada como carteira de usuário no Ethereum. E pode fornecer aos usuários uma maneira mais flexível e personalizada de gerenciar fundos. Contanto que seja a lógica que pode ser realizada pelo contrato inteligente Ethereum, a carteira do contrato pode realizar e fornecer as funções correspondentes.
Especificamente, várias operações de carteira de contrato podem ser empacotadas em uma transação on-chain, e essas operações podem compartilhar o custo do gás dessa transação. Se o terceiro estiver disposto a pagar a taxa de Gás, não há necessidade de pagar Gás para usuários que usam a carteira do contrato. As carteiras de contrato também podem concluir várias tarefas lineares ao mesmo tempo. Além disso, a carteira de contrato também suporta o algoritmo de criptografia de assinaturas personalizadas e define a função de recuperação de carteira e assim por diante.
À medida que a discussão sobre as vantagens das carteiras de contrato continua, a comunidade Ethereum realmente conduziu pesquisas de longo prazo sobre carteiras de contrato. Embora muitos EIPs tenham explorado questões relacionadas à abstração de contas, a partir de 2021, nenhum padrão unificado foi estabelecido. Abaixo estão vários EIPs representativos.
EIP-86
Originalmente proposto por Vitalik Buterin em 2017. O esquema implementa uma série de mudanças com o objetivo comum de "abstrair" a verificação de assinatura e verificação de nonce, permitindo assim que os usuários criem "contratos de conta" que executam verificação arbitrária de assinatura/nonce.
EIP-2938
Apresentado em 2020. O título deste EIP é Account Abstraction. O conceito de AA está bem descrito neste EIP. Ele introduz um novo tipo de transação, a transação AA. A transação é iniciada pelo endereço do ponto de entrada (endereço EntryPoint) e chama a carteira de contrato AA. O EIP-2938 fornece uma especificação unificada e introduz oficialmente a abstração da conta AA no consenso Ethereum. Especificamente, ele apresenta dois novos opcodes, três variáveis globais e uma estrutura de carga diferente para o consenso Ethereum.
EIP-3074
Apresentado em 2020. Este EIP apresenta duas instruções EVM, AUTH e AUTHCALL. AUTH define a variável de ambiente de acordo com a autoridade de assinatura ECDSA. AUTHCALL envia a chamada como a conta autorizada. Isso permite que contratos inteligentes enviem transações em nome do EOA. Mas ainda não é uma solução perfeita para AA. No processo de transação de autorização, o EIP-3074 possui certas restrições na transmissão do valor original. E se um usuário perder o acesso ao EOA, ainda não haverá como recuperar seus ativos. Se a chave privada vazar, o usuário precisará transferir todos os ativos para a nova conta.
Nenhuma das propostas acima foi formalmente incorporada ao protocolo Ethereum devido à necessidade de mudanças na camada de consenso ou porque as propostas não eram suficientemente abrangentes. Portanto, a comunidade Ethereum continuou a explorar como introduzir o AA no protocolo Ethereum sem alterar o consenso e, finalmente, propôs o EIP4337.
ERC - 4337
O EIP-4337 foi originalmente proposto em setembro de 2021 e autorizado como ERC-4337 em março de 2023. Seus autores incluem Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson e Tjaden Hess.
EIP-4337 é uma proposta disruptiva que pode introduzir AA sem alterar o protocolo principal do Ethereum. O EIP-4337 acabou se tornando o padrão ERC-4337, que os construtores podem usar para implementar suas próprias carteiras de contratos inteligentes. Ao mesmo tempo, o padrão também introduz algumas infra-estruturas adicionais, incluindo "Bundlers" e "UserOperation mempool". Dessa forma, ele realmente replica um mempool Ethereum com funções semelhantes na camada superior do sistema blockchain. O que o usuário envia não é mais uma única transação, mas uma UserOperation. Várias UserOperations podem ser empacotadas em uma única transação e enviadas para a Ethereum.
A seguir, uma explicação técnica detalhada do ERC-4337 no Ethereum [documentação oficial] (junto com alguns comentários úteis.
Principais funções e definições do ERC-4337
UserOperation — descreve a estrutura de uma transação enviada em nome de um usuário. Para evitar confusão, ele não é chamado de "transação" e será enviado ao Bundler para ser empacotado como um Bundle com outras UserOperations. O Bundle é então enviado na cadeia como uma única transação.
Sender — conta de contrato que envia UserOperation. O contrato de carteira deve seguir o padrão ERC-4337 para configurar a interface IAccount.
EntryPoint — contrato singleton global que executa o pacote UserOperations. Os Bundlers/Clientes autorizam EntryPoints suportados. O contrato é auditado e aprovado para implantação pela equipe Infinitism e é responsável por lidar com todas as UserOperations e conectar contratos com outras funções, incluindo Wallet Factory, Aggregator e Paymaster. O contrato está todo no mesmo endereço na cadeia compatível com EVM.
Bundler — O nó que empacota várias UserOperations do mempool e cria a transação EntryPoint.handleOps() (o produtor de bloco atual). O serviço Bundler pode ser executado independentemente dos nós de blockchain e enviar UserOperations empacotadas via RPC.
Agregador — Contrato auxiliar confiável por contas para verificar assinaturas agregadas. Agregadores de assinatura suportados pela lista de permissões de empacotadores/clientes. O Aggregator deve seguir o padrão ERC-4337 para configurar a interface do IAggregator.
Paymaster — um contrato inteligente que pode pagar Gas em seu nome. Se ele depositar ETH suficiente no contrato EntryPoint, poderá pagar a taxa de gás pela UserOperation para o remetente, implementando efetivamente a abstração de gás. Paymaster deve seguir o padrão ERC-4337 para configurar a interface Paymaster. O Pagador pode entrar em um acordo com o Remetente. Por exemplo, o Sender paga USDC ao Paymaster e o Paymaster usa ETH para pagar o Gas das UserOperations que envia. Na verdade, o Paymaster pode optar por oferecer suporte a qualquer token, incluindo tokens ERC-20 e até mesmo tokens em outras cadeias.
Wallet Factory — Um contrato inteligente que pode criar carteiras de contrato para usuários ERC-4337. A implantação do Wallet Factory não requer permissão. Como um contrato inteligente on-chain, seu código é aberto ao público e qualquer pessoa pode revisá-lo. Uma Wallet Factory amplamente utilizada deve ser totalmente auditada por profissionais.
O diagrama abaixo explica como o contrato do EntryPoint interage com outros atores.
Os empacotadores chamam a função handleOps do contrato EntryPoint, que aceita uma UserOperation como entrada.
handleOps verificará UserOperation na cadeia, verificará se ele é assinado pelo endereço de carteira de contrato inteligente especificado e confirmará se a carteira possui Gas suficiente para compensar o Bundler.
Se a verificação for aprovada, o handleOps executará a função de carteira de contrato inteligente de acordo com a função e os parâmetros de entrada definidos no calldata de UserOperation.
Por outro lado, quando o Bundler usa o EOA para acionar a função handleOps, uma taxa de Gas será cobrada. A carteira de contrato inteligente pode pagar taxas de gás aos empacotadores a partir do saldo de sua própria conta ou solicitar que o contrato Paymaster pague por isso. UserOperations não pode passar na etapa de verificação off-chain sem Gas suficiente, ou seja, falha antes de executar a transação na cadeia. Mesmo se houver Gas suficiente, UserOperations ainda pode falhar devido a motivos como erros de tempo de execução durante a execução. Para uma UserOperation, independentemente de a execução do contrato ser bem-sucedida ou não, o contrato EntryPoint pagará a taxa de Gas ao Bundler que aciona a função handleOps.
(Trecho da documentação oficial:
Depois que o ERC-4337 entrar em vigor, os usuários agora podem iniciar transações blockchain de duas maneiras. Uma é a forma tradicional, ou seja, o EOA inicia diretamente a transação. A outra é usar o padrão ERC-4337 para iniciar o UserOperation por meio do Bundler e, em seguida, o Bundler irá empacotá-lo com outros UserOperations e enviá-lo para a cadeia. O fluxograma abaixo ilustra a diferença entre uma transação de envio EOA normal e uma carteira de contrato ERC-4337 enviar UserOperation.
A estrada foi pavimentada, mas ainda não há muitos pedestres
O ERC-4337 fornece uma estrutura poderosa para usuários e desenvolvedores usarem e criarem AA no Ethereum. Embora esse quadro seja um avanço importante, ainda existem alguns desafios e incertezas que precisam ser enfrentados e resolvidos.
A adoção de AA ainda está em sua infância. De acordo com o painel de análise Dune ERC-4337 (*[ERC-4337 Account Abstraction](de @niftytable), apenas 65k+ UserOperations foram executadas na cadeia, 90% das quais vieram do Polygon. Portanto, o número de UserOperations atualmente executadas ainda é muito pequeno, e a maioria deles Parte disso é teste do desenvolvedor, e apenas uma pequena parte vem de usuários reais. Percebemos que os produtos que integraram o AA ainda estão em estágio inicial. No momento, podemos observar que Os empacotadores como um todo ainda estão em estado de perda, e a perda atual é de cerca de mais de 700 MATICs. Isso é causado principalmente por alguns empacotadores no Polygon estimarem incorretamente o gás necessário, resultando no gás retornado pelo EntryPoint sendo menor que o gás consumido pelo Bundle enviado. Este problema precisa ser resolvido no nível do cliente Bundler.
Além disso, há algumas questões que precisam ser abordadas. Um dos problemas é como os Bundlers lidam com falhas de transação.
Depois de agrupar várias UserOperations, os Bundlers primeiro simularão a transação, detectarão se haverá falha na execução do contrato e calcularão se a taxa de Gas devolvida pelo Remetente ou Pagador é maior que a taxa de Gas paga.
Se for lucrativo, o Bundler envia esse lote de UserOperations como uma transação para o nó do bloco. No entanto, ainda é possível que a transação falhe, fazendo com que o Bundler pague a taxa de Gás, mas não receba o reembolso de Gás do EntryPoint. Por exemplo, um usuário pode enviar ações para diferentes empacotadores. Se houver margem de lucro e a simulação for bem-sucedida, os Bundlers a comprometerão com a cadeia. Nesse caso, se uma UserOperation for enviada ao nó produtor do bloco por diferentes Bundlers ao mesmo tempo, apenas uma transação será bem-sucedida, o que significa que apenas um Bundler receberá a taxa de gás devolvida pelo EntryPoint e todos os outros Bundlers falharão devido ao encadeamento e perder gás. Embora alguém possa argumentar que esse comportamento deva ser considerado um ataque mal-intencionado e argumentar que o Bundler pode banir o endereço do remetente e rejeitar qualquer solicitação futura desse endereço, essa não é uma solução razoável porque os usuários podem realizar essa ação involuntariamente. Esse problema precisa ser tratado adequadamente no código, talvez por meio de um mempool público que esteja em desenvolvimento. Além disso, os Bundlers podem sofrer perdas devido a flutuações repentinas de gás, mesmo que a transação seja realizada com sucesso e os resultados da simulação mostrem que há espaço para lucro.
Outra questão é o valor máximo extraível (MEV) que pode ser obtido do AA. No contexto do Ethereum, MEV geralmente se refere ao valor que os mineradores ou outros processadores de transações extraem manipulando a ordem das transações em um bloco ou inserindo suas próprias transações em um bloco. Pode-se notar que a lógica do MEV também pode ser aplicada ao AA. Isso ocorre porque no AA, os Bundlers podem sequenciar livremente UserOps, o que lhes dá a possibilidade de adquirir MEV. No entanto, se o Bundler pode extrair MEV depende se UserOperations suficientes podem ser agrupadas. Agora, todo o mercado de AA ainda está em sua infância, então o Bundler MEV também pode ser considerado em sua infância. Pode-se ver que o MEV da AA pode se desenvolver em duas direções: uma é semelhante à rede principal Ethereum, com a participação de participantes como Flashbots, Ultra Sound e BloXroute; a outra direção é formar um consenso Bundler para implementar uma classificação justa. E este último eliminaria completamente a possibilidade de extrair MEV em AA.
desenvolvimento futuro
pool de memórias público
Embora o ecossistema AA já esteja operacional, ainda há muito trabalho de desenvolvimento a ser feito. Olhando para todo o ecossistema AA, a maior peça que falta agora é o mempool público. A equipe Etherspot, desenvolvedores do cliente Skandha Bundler, está atualmente desenvolvendo uma rede p2p com um mempool público. Espera-se que uma rede p2p de mempools públicos seja lançada em agosto deste ano.
Algoritmo de pacote
Ao longo do caminho, a Fundação Ethereum financiou várias equipes de desenvolvimento de AA excelentes. Até agora, vários clientes Bundler foram desenvolvidos e estão atualmente disponíveis. Entre eles, alguns são muito maduros. Eles são Candide (Voltaire Bundler escrito em Python), Pimlico (Alto Bundler escrito em Type), Etherspot (Skandha Bundler escrito em Type), Stackup (Stackup-Bundler escrito em Go), etc.
Aí entra a questão da estratégia de embalagem. Atualmente, devido ao pequeno número de UserOperations, os Bundlers podem adotar uma lógica de empacotamento simples, como um intervalo de tempo fixo ou um determinado número de UserOperations em cada Bundle. No entanto, à medida que o número de UserOperations aumenta, especialmente após a introdução do mempool público, a estratégia para selecionar e empacotar UserOperations torna-se mais complexa. A razão é simples: na ecologia AA, não há mecanismo semelhante ao protocolo de consenso blockchain, e o grupo Bundler tornou-se uma floresta escura.Cada Bundler prioriza tarefas de acordo com seus próprios interesses e compete entre si. Ao contrário dos mempools públicos, os mempools privados podem aparecer antes. Como empacotar UserOperations do mempool público não é lucrativo, ainda é possível empacotar UserOperations no mempool privado. Neste caso, o Empacotador é mais competitivo do que outros Empacotadores na hora de embalar.
Além disso, com a popularização gradual do mempool público, as UserOperations nele possuem várias características, como diferentes expectativas de lucro do Gas e complexidade de execução on-chain. Os empacotadores realizarão simulações off-chain para avaliar a lucratividade de várias combinações de UserOperations para estabelecer suas respectivas estratégias de empacotamento. Empacotar mais UserOperations tem o potencial de gerar maiores lucros, mas também aumenta o risco de falhas de validação. Mesmo que a verificação seja aprovada, o risco de falha na execução da cadeia ainda existe. Em contraste, as UserOperations menos empacotadas fazem o oposto. Os empacotadores precisam definir seus próprios parâmetros de gás de transação, o que afetará a prioridade dos produtores de bloco para executar esta transação. Sob diferentes preços estimados do gás e condições de volatilidade do gás, os empacotadores podem ter diferentes estratégias de embalagem. Ao mesmo tempo, também é necessário considerar o custo de recursos de computação de hardware local e recursos de nó de blockchain para esses cálculos de verificação e política. Além disso, os Bundlers também precisam trabalhar duro para fornecer aos usuários uma boa experiência de usuário e garantir que os usuários não enfrentem atrasos excessivos após o envio de UserOperations.
Embora as soluções para esses desafios ainda não estejam claras, podemos dizer com confiança que o desenvolvimento da indústria de AA e os esforços conjuntos dos desenvolvedores acabarão por resolver esses problemas. Como construtor de infraestrutura, a BlockPI espera desempenhar um papel de solucionador de problemas no desenvolvimento da indústria de AA, seja como desenvolvedor ou para fornecer infraestrutura compatível com AA para outros desenvolvedores.
A infraestrutura deve se adaptar ao AA
A AA abstrai as várias funções envolvidas nas transações on-chain, incluindo Remetente, Bundlers, pagadores de gás, carteiras de contrato e Signatários, para que os usuários tenham um maior grau de liberdade ao usar o blockchain. Ao mesmo tempo, os provedores de infraestrutura podem implantar esses serviços de forma independente, de acordo com seu próprio julgamento no mercado.
Para se adaptar à adoção em larga escala do AA, os provedores de infraestrutura precisam primeiro fornecer pelo menos dois serviços básicos: o serviço Bundler e o serviço Paymaster.
Nos serviços Bundler, os provedores de infraestrutura podem precisar desenvolver mempools privados com Bundlers para fornecer uma boa experiência ao usuário. Especificamente, os provedores de infraestrutura precisam integrar vários clientes Bundler para garantir a estabilidade dos serviços Bundler. Esses clientes Bundler atualmente fornecem aos usuários vários métodos JSON RPC padrão fornecidos pelo grupo de desenvolvimento principal ERC-4337. É previsível que mais métodos RPC estarão disponíveis para os usuários no futuro. Os provedores de serviços de infraestrutura precisam atualizar o suporte para esses métodos em tempo hábil durante esse processo.
Além disso, é muito importante otimizar entre a API do Bundler e o RPC do cliente do nó de origem. Os clientes de nó atuais não são otimizados para AA. Alguns métodos da API do Bundler exigem que o nó forneça um índice de dados para o AA. Por exemplo, quando o cliente atual procura UserOperation por hash, ele precisa verificar os logs de contrato do EntryPoint em todos os blocos. Se não houver índice de dados, o consumo de recursos de hardware dessa solicitação única será bastante grande e o tempo de retorno da solicitação também será muito longo.
Além disso, para fornecer aos usuários uma experiência de usuário sem gás e serviços diversificados, os provedores de infraestrutura precisam cooperar com diferentes provedores de serviços Paymaster para integrar diferentes serviços Paymaster. Ao mesmo tempo, de acordo com a demanda do mercado, os provedores de infraestrutura também podem projetar soluções integradas mais convenientes com base nos serviços Paymaster existentes. Outros serviços, como assinaturas agregadas, fábricas de carteiras, etc., também são direções potenciais para o futuro desenvolvimento e integração da infraestrutura.
Em suma, para se adaptar à aplicação em larga escala de AA, os provedores de infraestrutura precisam melhorar e expandir continuamente seus serviços. Isso inclui otimizar os serviços do Bundler, cooperar com diferentes provedores de serviços Paymaster, integrar várias interfaces de API e desenvolver outros serviços em potencial. À medida que a indústria de AA continua a se desenvolver, esses esforços ajudarão a fornecer uma experiência de blockchain mais eficiente, segura e conveniente.