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.
Para capturar a oportunidade do mercado AA potencialmente multibilionário, a BlockPI planeja integrar o AA em seus serviços de infraestrutura. Por meio da integração e inovação no campo AA, a BlockPI está empenhada em fornecer aos usuários AA uma maneira mais conveniente e eficiente de interagir com contas de carteira de contrato blockchain e espera se tornar líder nesse setor.
Neste artigo, a equipe do BlockPI aprofundará sua compreensão do AA e compartilhará ideias 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 das taxas de gás. Cada transação custará ao usuário uma quantidade considerável de ETH como uma taxa de gás (pegue o preço do gás de 25 Gwei como exemplo, a taxa de gás para uma transferência simples 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 for superior) . Isso torna as pequenas transações muito caras, especialmente durante períodos de forte congestionamento de rede. Além disso, apenas o ETH pode ser usado para pagar o Gas, o que significa que os usuários devem manter o ETH em suas carteiras, o que constitui uma alta barreira de entrada para muitos usuários.
Em segundo lugar, para algumas operações complexas que os usuários desejam realizar, 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 (aprovar), trocar (trocar) e desaprovar tokens (desaprovar token) 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 em 2017 por Vitalik Buterin. Este 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 podem realizar 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 variáveis de ambiente de acordo com a autoridade de assinatura ECDSA. AUTHCALL envia a chamada como uma conta autorizada. Isso permite que contratos inteligentes enviem transações em nome da EOA. Mas esta 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 o usuário perder o acesso ao EOA, ainda não há como recuperar seu patrimônio. 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.
O EIP-4337 é uma proposta disruptiva que introduziria o 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. Essas 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], com alguns comentários úteis.
Principais papéis do ERC-4337 e suas definições
UserOperation—descreve a estrutura de uma transação enviada em nome de um usuário. Para evitar confusão, ele não é denominado "transaction" e será enviado ao Bundler para ser empacotado junto com outras UserOperations como um Bundle. O Bundle é então enviado na cadeia como uma única transação.
Sender—a conta do contrato que envia UserOperation. O contrato de carteira deve seguir o padrão ERC-4337 para configurar a interface IAccount.
EntryPoint - o 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 nó produtor de bloco atual). O serviço Bundler pode ser executado independentemente dos nós de blockchain e enviar UserOperations empacotadas via RPC.
Agregador — Um contrato auxiliar confiável para contas para verificar assinaturas agregadas. Agregadores de assinatura suportados pela lista de permissões de empacotadores/clientes. Os agregadores devem configurar a interface IAggregator seguindo o padrão ERC-4337.
Paymaster—um contrato inteligente que pode pagar Gas em seu nome. Se ele depositar ETH suficiente no contrato EntryPoint, poderá pagar ao remetente o contrato inteligente pela taxa de gás da UserOperation, implementando efetivamente a abstração de gás. Paymaster deve seguir o padrão ERC-4337 para configurar a interface Paymaster. O Pagador pode fazer 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
Símbolo
, incluindo ERC-20
Símbolo
até outras cadeias
Símbolo
。
Wallet Factory—um contrato inteligente que pode criar carteiras de contrato para usuários ERC-4337. A implantação do Wallet Factory é isenta de licença. 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 as taxas do Bundlers Gas com o 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 erros de tempo de execução e outros motivos 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 gás ao Bundler que aciona a função handleOps.
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 de rede. 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], apenas 65k+ UserOperations foram executadas na cadeia, 90% das quais vieram do Polygon. Portanto, o número de UserOperations realizadas atualmente ainda é muito pequeno, a maioria dos quais são testes de desenvolvedores, e apenas uma pequena parte vem de usuários reais. Observamos que os produtos que integraram o AA ainda estão em seus estágios iniciais. No momento, podemos observar que os Bundlers como um todo ainda estão em estado de perda, e a perda atual é de mais de 700 MATIC. Isso é causado principalmente por alguns Bundlers no Polygon que estimam incorretamente o gás necessário, resultando no Gás retornado pelo EntryPoint sendo menor que o gás consumido pelo Bundle enviado. Esse problema precisa ser resolvido no nível do cliente Bundler.
Além disso, há algumas questões que precisam ser abordadas. Um desses 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 para o nó do bloco como uma transação. 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 espaço para lucro e a simulação for bem-sucedida, os Bundlers o comprometem com a cadeia. Neste caso, se uma UserOperation for enviada ao nó 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 para encadear 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 uma rede pública de mempool 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 em AA, os Bundlers podem solicitar UserOps livremente, 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. Este último eliminaria completamente a possibilidade de extrair MEVs 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: no ecossistema 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. Porque quando não é lucrativo empacotar UserOperations do mempool público, ainda é possível empacotar UserOperations no mempool privado. Neste caso, o Empacotador é mais competitivo com 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 conduzirã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 lucros maiores, 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, UserOperations com menos empacotamento é 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 garantir uma boa experiência de usuário para os usuários 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 o 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
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 de AA, os provedores de infraestrutura precisam primeiro fornecer pelo menos dois serviços básicos: serviço Bundler e serviço Paymaster.
No serviço Bundler, o provedor de infraestrutura pode precisar desenvolver um mempool privado junto com os 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, é importante otimizar entre a API do Bundler e o RPC do cliente do nó de origem. O cliente do nó atual não é otimizado para AA. Alguns métodos da API do Bundler exigem um índice em relação aos dados fornecidos 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.
Atualmente, BlockPI está trabalhando duro para atingir os objetivos acima. Além disso, nos comunicamos com quase todos os clientes Bundler e provedores de serviços Paymaster na comunidade e integraremos o AA à rede BlockPI como nossa principal tarefa de desenvolvimento. Ao mesmo tempo, também conduzimos uma comunicação aprofundada com os desenvolvedores de carteiras AA para entender as necessidades do usuário. Sinceramente, damos as boas-vindas a todos os Bundlers, Paymasters e wallets para se comunicarem e cooperarem conosco.
O objetivo do BlockPI é construir e desenvolver o ecossistema AA junto com a comunidade e fazer todo o possível para promover o progresso e a prosperidade do ecossistema AA. Esperamos que, por meio da cooperação com a comunidade, possamos contribuir para toda a indústria AA como líder da indústria e apoiar seu processo de desenvolvimento subsequente, para que os usuários da Web2 possam experimentar a tecnologia blockchain sem barreiras.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Como a infraestrutura oferece suporte a 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.
Para capturar a oportunidade do mercado AA potencialmente multibilionário, a BlockPI planeja integrar o AA em seus serviços de infraestrutura. Por meio da integração e inovação no campo AA, a BlockPI está empenhada em fornecer aos usuários AA uma maneira mais conveniente e eficiente de interagir com contas de carteira de contrato blockchain e espera se tornar líder nesse setor.
Neste artigo, a equipe do BlockPI aprofundará sua compreensão do AA e compartilhará ideias 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 das taxas de gás. Cada transação custará ao usuário uma quantidade considerável de ETH como uma taxa de gás (pegue o preço do gás de 25 Gwei como exemplo, a taxa de gás para uma transferência simples 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 for superior) . Isso torna as pequenas transações muito caras, especialmente durante períodos de forte congestionamento de rede. Além disso, apenas o ETH pode ser usado para pagar o Gas, o que significa que os usuários devem manter o ETH em suas carteiras, o que constitui uma alta barreira de entrada para muitos usuários.
Em segundo lugar, para algumas operações complexas que os usuários desejam realizar, 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 (aprovar), trocar (trocar) e desaprovar tokens (desaprovar token) 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 em 2017 por Vitalik Buterin. Este 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 podem realizar 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 variáveis de ambiente de acordo com a autoridade de assinatura ECDSA. AUTHCALL envia a chamada como uma conta autorizada. Isso permite que contratos inteligentes enviem transações em nome da EOA. Mas esta 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 o usuário perder o acesso ao EOA, ainda não há como recuperar seu patrimônio. 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.
O EIP-4337 é uma proposta disruptiva que introduziria o 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. Essas 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], com alguns comentários úteis.
Principais papéis do ERC-4337 e suas definições
UserOperation—descreve a estrutura de uma transação enviada em nome de um usuário. Para evitar confusão, ele não é denominado "transaction" e será enviado ao Bundler para ser empacotado junto com outras UserOperations como um Bundle. O Bundle é então enviado na cadeia como uma única transação.
Sender—a conta do contrato que envia UserOperation. O contrato de carteira deve seguir o padrão ERC-4337 para configurar a interface IAccount.
EntryPoint - o 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 nó produtor de bloco atual). O serviço Bundler pode ser executado independentemente dos nós de blockchain e enviar UserOperations empacotadas via RPC.
Agregador — Um contrato auxiliar confiável para contas para verificar assinaturas agregadas. Agregadores de assinatura suportados pela lista de permissões de empacotadores/clientes. Os agregadores devem configurar a interface IAggregator seguindo o padrão ERC-4337.
Paymaster—um contrato inteligente que pode pagar Gas em seu nome. Se ele depositar ETH suficiente no contrato EntryPoint, poderá pagar ao remetente o contrato inteligente pela taxa de gás da UserOperation, implementando efetivamente a abstração de gás. Paymaster deve seguir o padrão ERC-4337 para configurar a interface Paymaster. O Pagador pode fazer 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
Símbolo
, incluindo ERC-20
Símbolo
até outras cadeias
Símbolo
。
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 as taxas do Bundlers Gas com o 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 erros de tempo de execução e outros motivos 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 gás ao Bundler que aciona a função handleOps.
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 de rede. 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], apenas 65k+ UserOperations foram executadas na cadeia, 90% das quais vieram do Polygon. Portanto, o número de UserOperations realizadas atualmente ainda é muito pequeno, a maioria dos quais são testes de desenvolvedores, e apenas uma pequena parte vem de usuários reais. Observamos que os produtos que integraram o AA ainda estão em seus estágios iniciais. No momento, podemos observar que os Bundlers como um todo ainda estão em estado de perda, e a perda atual é de mais de 700 MATIC. Isso é causado principalmente por alguns Bundlers no Polygon que estimam incorretamente o gás necessário, resultando no Gás retornado pelo EntryPoint sendo menor que o gás consumido pelo Bundle enviado. Esse problema precisa ser resolvido no nível do cliente Bundler.
Além disso, há algumas questões que precisam ser abordadas. Um desses 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 para o nó do bloco como uma transação. 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 espaço para lucro e a simulação for bem-sucedida, os Bundlers o comprometem com a cadeia. Neste caso, se uma UserOperation for enviada ao nó 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 para encadear 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 uma rede pública de mempool 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 em AA, os Bundlers podem solicitar UserOps livremente, 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. Este último eliminaria completamente a possibilidade de extrair MEVs 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: no ecossistema 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. Porque quando não é lucrativo empacotar UserOperations do mempool público, ainda é possível empacotar UserOperations no mempool privado. Neste caso, o Empacotador é mais competitivo com 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 conduzirã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 lucros maiores, 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, UserOperations com menos empacotamento é 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 garantir uma boa experiência de usuário para os usuários 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 o 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
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 de AA, os provedores de infraestrutura precisam primeiro fornecer pelo menos dois serviços básicos: serviço Bundler e serviço Paymaster.
No serviço Bundler, o provedor de infraestrutura pode precisar desenvolver um mempool privado junto com os 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, é importante otimizar entre a API do Bundler e o RPC do cliente do nó de origem. O cliente do nó atual não é otimizado para AA. Alguns métodos da API do Bundler exigem um índice em relação aos dados fornecidos 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.
Atualmente, BlockPI está trabalhando duro para atingir os objetivos acima. Além disso, nos comunicamos com quase todos os clientes Bundler e provedores de serviços Paymaster na comunidade e integraremos o AA à rede BlockPI como nossa principal tarefa de desenvolvimento. Ao mesmo tempo, também conduzimos uma comunicação aprofundada com os desenvolvedores de carteiras AA para entender as necessidades do usuário. Sinceramente, damos as boas-vindas a todos os Bundlers, Paymasters e wallets para se comunicarem e cooperarem conosco.
O objetivo do BlockPI é construir e desenvolver o ecossistema AA junto com a comunidade e fazer todo o possível para promover o progresso e a prosperidade do ecossistema AA. Esperamos que, por meio da cooperação com a comunidade, possamos contribuir para toda a indústria AA como líder da indústria e apoiar seu processo de desenvolvimento subsequente, para que os usuários da Web2 possam experimentar a tecnologia blockchain sem barreiras.