Quer se trate de um mercado em alta ou em baixa, o ecossistema Ethereum tem se desenvolvido e se auto-otimizado continuamente. Entre eles, a abstração de contas (AA) tornou-se um avanço muito importante nos últimos anos e penetrou em vários componentes do ecossistema Ethereum, incluindo aplicativos, infraestrutura, usuários e desenvolvedores.
Podemos prever que a adoção generalizada de AA pode diminuir as barreiras de entrada para casos de uso de blockchain, trazendo assim a experiência do usuário web2 para a indústria web3.
Para abraçar a possibilidade de formar um mercado multibilionário de AA, a BlockPI planeja dedicar recursos para integrar o AA em seus serviços de infraestrutura. Ao desenvolver a integração do AA, pretendemos fornecer maneiras mais convenientes e eficientes para os usuários do AA interagirem com suas contas de carteira de contrato no blockchain, ao mesmo tempo em que posicionamos o BlockPI como líder do setor.
Nesta postagem, aprofundarei nossa compreensão do AA e compartilharei pensamentos da perspectiva de um provedor de serviços de infraestrutura.
EOA e carteira de contrato inteligente
O conceito de AA decorre das limitações das contas EOA. Uma conta EOA (Externally Owned Account) é uma conta de usuário típica no Ethereum, representada por uma chave pública (endereço blockchain) e acessível por meio de uma chave privada. É um componente importante do ecossistema Ethereum, permitindo que os usuários interajam com contratos inteligentes e executem transações na rede. No entanto, usar o EOA pode ser um desafio para as pessoas e alguns inconvenientes podem afetar a experiência do usuário.
O primeiro inconveniente do EOA está relacionado com a utilização do Gás. Cada transação custará ao usuário uma grande quantidade de ETH como taxa de gás (uma taxa de transferência simples de ETH de 25 Gwei para o preço do gás é de 0,5 USD e mais para interação de contrato ou preço mais alto do gás). Isso torna as taxas de transação muito caras para pequenas transações, especialmente durante os períodos de pico de congestionamento da rede. Além disso, apenas ETH pode ser usado para pagar pelo gás, o que significa que os usuários devem ter ETH em suas carteiras, o que é uma barreira significativa à entrada de muitos usuários.
O segundo inconveniente do EOA é que as transações condicionais não podem ser feitas a menos que alguma lógica seja implementada usando outros contratos inteligentes. Por exemplo, se um usuário deseja definir uma transferência periódica cronometrada, ele deve transferir ETH para um contrato inteligente de terceiros com esta função para conseguir esta função.
O terceiro inconveniente do EOA é o algoritmo de criptografia de assinatura. A rede Ethereum usa um algoritmo de assinatura digital específico chamado secp 256 k 1 para garantir a autenticidade e segurança das transações. Isso é codificado no sistema e o usuário não pode optar por usar outro algoritmo.
Portanto, a partir desses problemas, as pessoas começaram a tentar encontrar soluções. As carteiras de contratos inteligentes, como MetaMask e Argent, são o resultado desses esforços, abordando muitas das limitações da EOA usando contratos inteligentes Ethereum para aprimorar a funcionalidade da conta do usuário. No entanto, essa solução ainda tem algumas desvantagens, principalmente exigindo que os usuários paguem taxas de Gas pelas transações e a popularidade das carteiras de contratos inteligentes.
Com base nesses desafios, a Ethereum começou a tentar introduzir um novo conceito, ou seja, a abstração de contas. O objetivo da abstração de contas é resolver esses problemas no nível do protocolo, em vez de depender de contratos inteligentes ou outro middleware. Isso é o que agora chamamos de abstração de conta (AA).
No restante deste post, vou me aprofundar no conceito de abstração de conta e como podemos usá-lo para otimizar a infraestrutura do BlockPI.
Além dos três inconvenientes do EOA mencionados acima, o relacionamento vinculante entre a chave pública e a chave privada também é um problema. A chave privada é a única maneira de acessar o EOA e, se for perdida, não há como recuperá-la. Isso significa que, se a chave privada for perdida, todos os ativos associados a ela serão irrecuperáveis.
Além disso, o EOA também enfrenta restrições ao executar tarefas lineares em uma única transação. Por exemplo, se um usuário deseja aprovar, trocar e desaprovar tokens em uma ação, ele precisa realizar três transações separadas, o que é ineficiente e demorado.
A boa notícia é que todos os problemas acima podem ser resolvidos com carteiras de contratos inteligentes. Uma carteira de contrato inteligente é um tipo especial de contrato inteligente que implementa AA. Ele foi projetado para atuar como uma carteira do usuário na rede Ethereum e fornecer uma maneira mais adaptável e personalizada de gerenciar seus fundos. Desde que a lógica do contrato inteligente Ethereum possa ser realizada, a carteira de contrato inteligente pode fornecer as funções necessárias.
Especificamente, as transações da carteira de contrato inteligente podem ser empacotadas em uma transação on-chain para compartilhar o custo do gás.Se um terceiro estiver disposto a pagar, pode até não haver custo do gás. Uma operação pode facilitar a execução de tarefas sequenciais dentro de sua carteira de contrato inteligente. A carteira de contrato inteligente pode suportar qualquer algoritmo de criptografia de assinatura e definir códigos de recuperação, etc.
Com toda a conversa sobre os benefícios das carteiras de contrato inteligentes, a comunidade Ethereum tem trabalhado em carteiras de contrato desde o início. Embora muitos EIPs tenham sido propostos para explorar a abstração de contas, nenhum padrão unificado foi estabelecido até 2021. Abaixo estão algumas das propostas mais representativas.
EIP-86
Originalmente criado em 2017 por Vitalik Buterin. Implementado um conjunto de alterações para verificação de assinatura "abstrata" e serviços de verificação de nonce, permitindo que os usuários criem "contratos de conta" que executam qualquer verificação de assinatura/nonce desejada.
EIP-2938
Criado em 2020. O título deste EIP é Account Abstraction. Este EIP detalha o conceito de AA. Ele introduz um novo tipo de transação, a transação AA. Esta transação será inicializada pelo endereço EntryPoint e chamará o contrato de carteira AA. Ao fazer isso, fornece uma especificação unificada e introduz AA no consenso Ethereum. Mais especificamente, ele adiciona dois novos opcodes, três variáveis globais e uma estrutura de carga útil diferente ao consenso Ethereum.
EIP-3074
Criado em 2020. Este EIP apresenta duas instruções EVM, AUTH e AUTHCALL. AUTH define uma variável de contexto chamada autorizada com base na assinatura ECDSA. AUTHCALL envia uma chamada em nome de uma conta autorizada. Isso permite que um contrato inteligente envie transações em nome da EOA. Mas esta não é uma solução perfeita para AA. O EIP-3074 coloca certas limitações nas transferências de valor nativo durante transações de patrocínio. Se você perder o acesso ao EOA, não poderá recuperar seus ativos e, em caso de roubo, todos os ativos deverão ser transferidos para uma nova conta.
Nenhuma das ideias acima foi formalmente adotada no protocolo Ethereum devido a motivos importantes, como exigir mudanças na camada de consenso ou não ser abrangente. Portanto, a comunidade Ethereum continuou a explorar como introduzir o AA no protocolo Ethereum sem alterar o consenso e, finalmente, criou o EIP 4337.
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 revolucionária que introduz o AA sem fazer nenhuma alteração no protocolo principal da Ethereum. O EIP-4337 orienta o padrão ERC-4337, que os construtores podem usar para implementar suas próprias carteiras de contratos inteligentes e inclui algumas infraestruturas adicionais, incluindo "Bundlers" e pools de memória UserOperation. Ao fazer isso, ele basicamente replica a funcionalidade do mempool da transação em um sistema mais avançado. Em vez de enviar transações, os usuários enviam objetos UserOperation, que podem ser empacotados em uma única transação e incluídos na cadeia Ethereum.
A seguir, uma explicação técnica mais específica do ERC-4337 da documentação oficial, bem como alguns comentários para melhor compreensão.
Definição e principais funções do ERC-4337
UserOperation — estrutura que descreve transações enviadas em nome de um usuário. Para evitar confusão, não é chamado de "transação". Ele é enviado ao Bundler para ser empacotado com outras UserOperations. O pacote é então enviado ao criador do bloco como uma única transação.
Remetente — a conta do contrato que envia a nova UserOperation. A carteira de contrato inteligente deve implementar a interface IAccount de ERC-4337.
EntryPoint — um contrato singleton que implementa o pacote UserOperations. Os empacotadores/clientes da lista de permissões suportam EntryPoints. Este contrato é aprovado e revisado pela equipe Infinitism e é responsável por lidar com todas as UserOperations e conectar outros contratos, incluindo Wallet Factory, Aggregator, Paymaster. Ele terá o mesmo endereço na maioria das cadeias compatíveis com EVM.
Bundler — um nó (construtor de blocos) que agrupa várias UserOperations de um mempool e cria transações EntryPoint.handleOps(). Todos os validadores na camada de protocolo não precisam ser empacotadores. O serviço Bundler pode ser executado independentemente do construtor de blocos e usa RPC para enviar UserOperations agrupadas.
Agregador — Um contrato de ajuda confiável para contas para verificar assinaturas agregadas. Agregadores suportados da lista de permissões de empacotadores/clientes. Os agregadores devem implementar a interface ERC-4337 IAggregator.
Paymaster — Um contrato que pode pagar a taxa de gás da UserOperation para o Remetente se ETH suficiente for depositado no contrato do EntryPoint. Paymaster implementa uma abstração de gás eficiente. Paymaster deve implementar a interface Paymaster de ERC-4337. Paymaster pode ter sua própria lógica para fazer um acordo com o Remetente. Por exemplo, o Sender paga USDC ao Paymaster e o Paymaster patrocina suas UserOperations com ETH. Na verdade, qualquer token ERC 20 ou mesmo tokens em outras cadeias podem ser suportados, desde que o Paymaster concorde e seja tecnicamente viável.
Wallet Factory — um contrato que pode ser chamado para criar carteiras de contrato inteligentes para usuários ERC-4337. A implantação de uma fábrica de carteiras não requer permissão. Como um componente on-chain, está aberto à auditoria pública e escrutínio transparente. A 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 usa uma UserOperation como entrada.
handleOps verifica o UserOperation na cadeia, verifica se ele é assinado pelo endereço de carteira de contrato inteligente especificado e se a carteira tem Gas suficiente para compensar o Bundler.
Se a verificação for bem-sucedida, o handleOps executará a função de carteira de contrato inteligente de acordo com a assinatura da função e os parâmetros de entrada definidos no calldata do 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 a taxa de gás aos empacotadores a partir do saldo de sua própria conta ou solicitar que o contrato Paymaster pague em seu nome. UserOperations que não possuem gás suficiente não podem passar no processo de verificação na carteira de contrato inteligente de destino e, portanto, falham antes da execução. Mesmo que haja gás suficiente, UserOperations pode falhar durante a execução, por exemplo, devido a erros de tempo de execução. Independentemente de a execução ser bem-sucedida ou não, o contrato do EntryPoint pagará a taxa de gás ao empacotador que aciona a função handleOps.
(Fonte: Documentação oficial:
Após a entrada em vigor do ERC-4337, os usuários agora têm duas maneiras de iniciar transações de blockchain. Uma é a forma original, onde o EOA inicia 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 iniciá-lo na cadeia. O fluxograma a seguir ilustra a diferença entre a transação de envio EOA normal e a operação de envio da carteira de contrato ERC-4337.
A estrada é asfaltada, mas não há muitos passageiros
O ERC-4337 fornece uma estrutura poderosa para usuários e desenvolvedores usarem e construírem AA na plataforma Ethereum. Embora este quadro seja um importante passo em frente, vários desafios e incertezas ainda precisam ser abordados 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 from @niftytable), apenas 65 k+ UserOperations são executadas na cadeia, 90% das quais vêm do Polygon. Portanto, o número de UserOperations realizadas neste momento ainda é muito pequeno, a maioria dos quais são testes de desenvolvedor e apenas uma pequena parte é atribuída aos usuários. Observamos que os produtos que integraram AA ainda estão em seus estágios iniciais. Ao mesmo tempo, você pode ver que o lucro de Bundler é negativo (-700 em termos MATIC). Isso ocorre porque alguns empacotadores no Polygon não calculam o gás de pré-validação corretamente. Este algoritmo de verificação ainda precisa de otimização.
Além disso, há algumas questões que precisam ser abordadas. Um desses problemas é como os Bundlers lidam com falhas de transação. Depois que o Bundler agrupa várias UserOperations, o Bundler primeiro simula a transação para verificar se ela será revertida e, em seguida, calcula se a taxa de gás retornada pelo remetente ou pelo pagador é maior do que a taxa de gás paga pela transação. Se for lucrativo, o Bundler envia esse lote de UserOperations junto como uma transação para o construtor de bloco. No entanto, a transação ainda pode falhar, resultando no Bundler pagando a taxa de gás, mas não recebendo o gás de volta do EntryPoint. Por exemplo, um usuário pode enviar ações para diferentes empacotadores. Os empacotadores estão dispostos a enviar quaisquer operações na cadeia se forem lucrativas e sua simulação for bem-sucedida. Isso significa que, se uma UserOperation for enviada por diferentes Bundlers ao mesmo tempo. Apenas uma transação terá sucesso, apenas um Bundler receberá a taxa de gás do EntryPoint, todos os outros Bundlers perderão gás devido a falha na cadeia. Embora alguém possa argumentar que os usuários não devem fazer isso, tal comportamento seria considerado um ataque mal-intencionado e que o Bundler poderia banir o endereço do remetente e rejeitar quaisquer solicitações futuras desse endereço, essa não é uma abordagem razoável porque os usuários podem ter esta operação foram enviados inadvertidamente. Essas questões precisam ser abordadas adequadamente no código, possivelmente desenvolvendo uma rede de mempool pública inacabada. Além disso, devido a flutuações repentinas de gás, os Bundlers podem enfrentar perdas, mesmo que as transações tenham sido submetidas com sucesso e simuladas como lucrativas.
Outra coisa é o valor máximo extraível (MEV) que pode ser extraído do AA. No contexto do Ethereum, MEV geralmente se refere ao valor que os mineradores ou outros processadores de transações podem extrair manipulando a ordem das transações em um bloco ou incluindo suas próprias transações em um bloco. Alguém notou que a lógica do MEV também pode ser aplicada ao AA, já que os Bundlers são livres para solicitar UserOperations? No entanto, isso é condicional, UserOperations suficientes precisam ser agrupadas para que os Bundlers extraiam o MEV. 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. Em geral, a indústria de AA pode se desenvolver em duas direções: uma é semelhante à rede principal Ethereum, com participantes como Flashbots, Ultra Sound e BloXroute, e a outra é formar um consenso de Bundler para impor uma ordem justa. A última abordagem eliminaria completamente a possibilidade de MEV em AA.
desenvolvimento futuro
pool de memórias público
Embora o ecossistema AA já esteja funcionando, ainda há muito trabalho de desenvolvimento a ser feito. Olhando para todo o ecossistema AA, a maior lacuna no momento é 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 a rede p2p do mempool público esteja disponível em agosto deste ano.
Algoritmo de empacotamento
Ao longo do caminho, a Ethereum Foundation financiou várias equipes de desenvolvimento AA de desenvolvedores dedicados e esforçados. Até o momento, várias versões do cliente Bundler foram desenvolvidas e agora estão disponíveis. Alguns deles são altamente desenvolvidos em termos de maturidade do produto. 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) e muitos mais.
Agora, vamos nos aprofundar no algoritmo de empacotamento com mais detalhes. Atualmente, devido ao baixo número de UserOperations, os Bundlers podem empregar lógica de empacotamento simples e direta, como intervalos de tempo fixos ou o 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: sem um protocolo de consenso como um blockchain, os Bundlers formam uma floresta escura, cada um priorizando o trabalho de acordo com seus próprios interesses e competindo entre si. Os mempools privados, correspondentemente correspondentes aos mempools públicos, têm maior probabilidade de vir primeiro. Porque quando não é lucrativo empacotar UserOperations do mempool público, pode ser lucrativo empacotar UserOperations juntos no mempool privado. Dessa forma, a Bundler tem uma vantagem competitiva quando o assunto é embalagem.
Além disso, como o mempool público é gradualmente aceito, as UserOperations nele terão características diferentes, como diferentes expectativas de lucro do Gas e complexidade de execução on-chain. Os empacotadores realizarão simulações fora da cadeia para avaliar a lucratividade de várias combinações de UserOperations para estabelecer suas estratégias exclusivas de empacotamento. Empacotar mais UserOperations tem o potencial de render 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. 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 construtores de bloco para executar transações. Sob diferentes preços de gás de mercado e condições de volatilidade do gás, os empacotadores podem ter diferentes estratégias de embalagem. Ao mesmo tempo, esses cálculos de verificação e política precisam consumir recursos de computação de hardware local e recursos de nó de blockchain. Os empacotadores também precisam garantir que os usuários tenham uma boa experiência e que não enfrentem atrasos excessivos após o envio de uma UserOperation.
Embora as soluções para esses desafios permaneçam incertas, podemos ter certeza de que a evolução da indústria de AA e os esforços combinados dos desenvolvedores acabarão por encontrar soluções. Como construtor de infraestrutura, a BlockPI espera resolver problemas no desenvolvimento da indústria de AA, seja como desenvolvedor ou para fornecer infraestrutura de AA amigável para outros desenvolvedores.
A infraestrutura deve se adaptar
AA abstrai vários papéis no comportamento da transação na cadeia, incluindo remetentes, empacotadores, pagadores de gás, carteiras de contrato e assinantes, permitindo que os usuários tenham um maior grau de liberdade ao usar o blockchain. Além disso, os serviços dentro de um AA podem ser implantados separadamente.
Para se adaptar à adoção em larga escala do AA, os provedores de infraestrutura precisam primeiro fornecer pelo menos dois serviços básicos, ou seja, o serviço Bundler e o serviço Paymaster.
No serviço Bundler, o provedor de infraestrutura pode precisar desenvolver um mempool privado com Bundlers para garantir uma boa experiência do usuário. Especificamente, os provedores de infraestrutura precisam integrar vários clientes Bundler para garantir a robustez dos serviços Bundler. Esses clientes Bundler são desenvolvidos em diferentes linguagens de programação, mas todos fornecem um conjunto padrão de métodos JSON RPC especificados pela equipe principal do ERC-4337. Atualmente, não há muitos métodos disponíveis, mas mais métodos serão adicionados no futuro. Os provedores de serviços de infraestrutura devem fornecer suporte contínuo e completo para essas APIs.
Além disso, é importante otimizar e adaptar o relacionamento entre a API do Bundler e o RPC do cliente do nó de origem. Sabemos que o cliente do nó atual não está bem otimizado para a capacidade de resposta e adaptabilidade do AA. Certos métodos da API do Bundler exigem que o índice de dados do AA funcione. Por exemplo, pesquisar uma UserOperation por hash requer a indexação de todas as UserOperations. Caso contrário, o consumo de hardware dessa solicitação única será muito alto e a solicitação demorará muito para retornar.
Além disso, os provedores de infraestrutura também precisam integrar diferentes serviços Paymaster para fornecer aos clientes uma experiência de usuário sem gás e fornecer a eles diferentes opções de serviço. Isso requer boa comunicação e integração com provedores de serviços Paymaster terceirizados.Ao mesmo tempo, de acordo com a demanda do mercado, também podem ser projetadas soluções de integração mais convenientes com base nos serviços existentes do Paymaster. Outros serviços, como assinaturas agregadas, fábricas de carteiras, etc., também são direções possíveis para desenvolvimento e integração futuros.
Atualmente, o BlockPI está realmente tentando atingir todos os objetivos acima. Além disso, estamos nos comunicando com quase todos os clientes Bundler e provedores de serviços Paymaster na comunidade e fizemos da integração do serviço AA na rede BlockPI nossa principal prioridade. Também estamos tendo discussões aprofundadas com os desenvolvedores de carteiras AA para entender as necessidades do usuário. Portanto, damos boas-vindas à cooperação e trocas com todos os Bundlers, Paymasters e carteiras à medida que avançamos. Nosso objetivo geral é construir e desenvolver o ecossistema AA com outros, impulsionando seu crescimento e desenvolvimento da melhor maneira possível. Ao trabalharmos juntos, esperamos fazer uma contribuição significativa para a indústria de AA como um todo e apoiar seu desenvolvimento contínuo. Afinal, nossa missão final é ser pioneira na indústria e promover o desenvolvimento do ecossistema AA para que os usuários da web2 possam desfrutar de sua experiência blockchain sem barreiras.
Resumir
Do ponto de vista de AA, estamos em um novo momento histórico. Embora tenhamos estradas pavimentadas no boulevard, ainda não há muitos pilotos. No momento, a aplicação de AA ainda está em sua infância. O ERC-4337 fornece uma estrutura poderosa para usuários e desenvolvedores usarem e construírem AA na plataforma Ethereum. No entanto, ainda existem muitos desafios e incertezas que precisam ser resolvidos.
O provedor de infraestrutura de AA precisa fornecer o serviço Bundler e o serviço Paymaster para seus usuários e precisa integrar vários clientes Bundler e provedores de serviços Paymaster para garantir a robustez do serviço. Para otimizar a capacidade de resposta entre a API e os clientes do nó, os dados AA podem precisar ser indexados para reduzir o consumo de hardware para uma única solicitação. Para fornecer uma melhor experiência ao usuário, os provedores de infraestrutura também precisam fornecer aos usuários mais opções de serviço.
No futuro, conforme o ecossistema AA continuar a crescer e os mempools públicos surgirem, a estratégia para selecionar e empacotar UserOperations se tornará mais complexa. Cada Bundler prioriza seu trabalho de acordo com seus próprios interesses e compete com outros Bundlers. Os empacotadores precisam definir seus próprios parâmetros de gás de transação, que afetam a prioridade dos construtores de bloco para executar transações. Sob diferentes preços de gás de mercado e condições de volatilidade do gás, os empacotadores podem ter diferentes estratégias de embalagem.
Embora as soluções para esses desafios sejam incertas, podemos ter certeza de que a evolução da indústria de AA e os esforços combinados dos desenvolvedores acabarão por encontrar soluções. Como um construtor de infraestrutura, BlockPI espera ser um solucionador de problemas no desenvolvimento da indústria de AA, seja como desenvolvedor ou fornecendo infraestrutura de AA amigável para outros desenvolvedores. Nossa missão é promover o desenvolvimento do ecossistema AA para que os usuários do Web2 possam desfrutar de sua experiência blockchain sem barreiras.
Ver original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Como abstrair contas para capacitar a infraestrutura e atender bilhões de usuários?
Autor: Albert He, BlockPI Cheif Cientista
Compilação original: MarsBit, MK
Quer se trate de um mercado em alta ou em baixa, o ecossistema Ethereum tem se desenvolvido e se auto-otimizado continuamente. Entre eles, a abstração de contas (AA) tornou-se um avanço muito importante nos últimos anos e penetrou em vários componentes do ecossistema Ethereum, incluindo aplicativos, infraestrutura, usuários e desenvolvedores.
Podemos prever que a adoção generalizada de AA pode diminuir as barreiras de entrada para casos de uso de blockchain, trazendo assim a experiência do usuário web2 para a indústria web3.
Para abraçar a possibilidade de formar um mercado multibilionário de AA, a BlockPI planeja dedicar recursos para integrar o AA em seus serviços de infraestrutura. Ao desenvolver a integração do AA, pretendemos fornecer maneiras mais convenientes e eficientes para os usuários do AA interagirem com suas contas de carteira de contrato no blockchain, ao mesmo tempo em que posicionamos o BlockPI como líder do setor.
Nesta postagem, aprofundarei nossa compreensão do AA e compartilharei pensamentos da perspectiva de um provedor de serviços de infraestrutura.
EOA e carteira de contrato inteligente
O conceito de AA decorre das limitações das contas EOA. Uma conta EOA (Externally Owned Account) é uma conta de usuário típica no Ethereum, representada por uma chave pública (endereço blockchain) e acessível por meio de uma chave privada. É um componente importante do ecossistema Ethereum, permitindo que os usuários interajam com contratos inteligentes e executem transações na rede. No entanto, usar o EOA pode ser um desafio para as pessoas e alguns inconvenientes podem afetar a experiência do usuário.
O primeiro inconveniente do EOA está relacionado com a utilização do Gás. Cada transação custará ao usuário uma grande quantidade de ETH como taxa de gás (uma taxa de transferência simples de ETH de 25 Gwei para o preço do gás é de 0,5 USD e mais para interação de contrato ou preço mais alto do gás). Isso torna as taxas de transação muito caras para pequenas transações, especialmente durante os períodos de pico de congestionamento da rede. Além disso, apenas ETH pode ser usado para pagar pelo gás, o que significa que os usuários devem ter ETH em suas carteiras, o que é uma barreira significativa à entrada de muitos usuários.
O segundo inconveniente do EOA é que as transações condicionais não podem ser feitas a menos que alguma lógica seja implementada usando outros contratos inteligentes. Por exemplo, se um usuário deseja definir uma transferência periódica cronometrada, ele deve transferir ETH para um contrato inteligente de terceiros com esta função para conseguir esta função.
O terceiro inconveniente do EOA é o algoritmo de criptografia de assinatura. A rede Ethereum usa um algoritmo de assinatura digital específico chamado secp 256 k 1 para garantir a autenticidade e segurança das transações. Isso é codificado no sistema e o usuário não pode optar por usar outro algoritmo.
Portanto, a partir desses problemas, as pessoas começaram a tentar encontrar soluções. As carteiras de contratos inteligentes, como MetaMask e Argent, são o resultado desses esforços, abordando muitas das limitações da EOA usando contratos inteligentes Ethereum para aprimorar a funcionalidade da conta do usuário. No entanto, essa solução ainda tem algumas desvantagens, principalmente exigindo que os usuários paguem taxas de Gas pelas transações e a popularidade das carteiras de contratos inteligentes.
Com base nesses desafios, a Ethereum começou a tentar introduzir um novo conceito, ou seja, a abstração de contas. O objetivo da abstração de contas é resolver esses problemas no nível do protocolo, em vez de depender de contratos inteligentes ou outro middleware. Isso é o que agora chamamos de abstração de conta (AA).
No restante deste post, vou me aprofundar no conceito de abstração de conta e como podemos usá-lo para otimizar a infraestrutura do BlockPI.
Além dos três inconvenientes do EOA mencionados acima, o relacionamento vinculante entre a chave pública e a chave privada também é um problema. A chave privada é a única maneira de acessar o EOA e, se for perdida, não há como recuperá-la. Isso significa que, se a chave privada for perdida, todos os ativos associados a ela serão irrecuperáveis.
Além disso, o EOA também enfrenta restrições ao executar tarefas lineares em uma única transação. Por exemplo, se um usuário deseja aprovar, trocar e desaprovar tokens em uma ação, ele precisa realizar três transações separadas, o que é ineficiente e demorado.
A boa notícia é que todos os problemas acima podem ser resolvidos com carteiras de contratos inteligentes. Uma carteira de contrato inteligente é um tipo especial de contrato inteligente que implementa AA. Ele foi projetado para atuar como uma carteira do usuário na rede Ethereum e fornecer uma maneira mais adaptável e personalizada de gerenciar seus fundos. Desde que a lógica do contrato inteligente Ethereum possa ser realizada, a carteira de contrato inteligente pode fornecer as funções necessárias.
Especificamente, as transações da carteira de contrato inteligente podem ser empacotadas em uma transação on-chain para compartilhar o custo do gás.Se um terceiro estiver disposto a pagar, pode até não haver custo do gás. Uma operação pode facilitar a execução de tarefas sequenciais dentro de sua carteira de contrato inteligente. A carteira de contrato inteligente pode suportar qualquer algoritmo de criptografia de assinatura e definir códigos de recuperação, etc.
Com toda a conversa sobre os benefícios das carteiras de contrato inteligentes, a comunidade Ethereum tem trabalhado em carteiras de contrato desde o início. Embora muitos EIPs tenham sido propostos para explorar a abstração de contas, nenhum padrão unificado foi estabelecido até 2021. Abaixo estão algumas das propostas mais representativas.
EIP-86
Originalmente criado em 2017 por Vitalik Buterin. Implementado um conjunto de alterações para verificação de assinatura "abstrata" e serviços de verificação de nonce, permitindo que os usuários criem "contratos de conta" que executam qualquer verificação de assinatura/nonce desejada.
EIP-2938
Criado em 2020. O título deste EIP é Account Abstraction. Este EIP detalha o conceito de AA. Ele introduz um novo tipo de transação, a transação AA. Esta transação será inicializada pelo endereço EntryPoint e chamará o contrato de carteira AA. Ao fazer isso, fornece uma especificação unificada e introduz AA no consenso Ethereum. Mais especificamente, ele adiciona dois novos opcodes, três variáveis globais e uma estrutura de carga útil diferente ao consenso Ethereum.
EIP-3074
Criado em 2020. Este EIP apresenta duas instruções EVM, AUTH e AUTHCALL. AUTH define uma variável de contexto chamada autorizada com base na assinatura ECDSA. AUTHCALL envia uma chamada em nome de uma conta autorizada. Isso permite que um contrato inteligente envie transações em nome da EOA. Mas esta não é uma solução perfeita para AA. O EIP-3074 coloca certas limitações nas transferências de valor nativo durante transações de patrocínio. Se você perder o acesso ao EOA, não poderá recuperar seus ativos e, em caso de roubo, todos os ativos deverão ser transferidos para uma nova conta.
Nenhuma das ideias acima foi formalmente adotada no protocolo Ethereum devido a motivos importantes, como exigir mudanças na camada de consenso ou não ser abrangente. Portanto, a comunidade Ethereum continuou a explorar como introduzir o AA no protocolo Ethereum sem alterar o consenso e, finalmente, criou o EIP 4337.
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 revolucionária que introduz o AA sem fazer nenhuma alteração no protocolo principal da Ethereum. O EIP-4337 orienta o padrão ERC-4337, que os construtores podem usar para implementar suas próprias carteiras de contratos inteligentes e inclui algumas infraestruturas adicionais, incluindo "Bundlers" e pools de memória UserOperation. Ao fazer isso, ele basicamente replica a funcionalidade do mempool da transação em um sistema mais avançado. Em vez de enviar transações, os usuários enviam objetos UserOperation, que podem ser empacotados em uma única transação e incluídos na cadeia Ethereum.
A seguir, uma explicação técnica mais específica do ERC-4337 da documentação oficial, bem como alguns comentários para melhor compreensão.
Definição e principais funções do ERC-4337
UserOperation — estrutura que descreve transações enviadas em nome de um usuário. Para evitar confusão, não é chamado de "transação". Ele é enviado ao Bundler para ser empacotado com outras UserOperations. O pacote é então enviado ao criador do bloco como uma única transação.
Remetente — a conta do contrato que envia a nova UserOperation. A carteira de contrato inteligente deve implementar a interface IAccount de ERC-4337.
EntryPoint — um contrato singleton que implementa o pacote UserOperations. Os empacotadores/clientes da lista de permissões suportam EntryPoints. Este contrato é aprovado e revisado pela equipe Infinitism e é responsável por lidar com todas as UserOperations e conectar outros contratos, incluindo Wallet Factory, Aggregator, Paymaster. Ele terá o mesmo endereço na maioria das cadeias compatíveis com EVM.
Bundler — um nó (construtor de blocos) que agrupa várias UserOperations de um mempool e cria transações EntryPoint.handleOps(). Todos os validadores na camada de protocolo não precisam ser empacotadores. O serviço Bundler pode ser executado independentemente do construtor de blocos e usa RPC para enviar UserOperations agrupadas.
Agregador — Um contrato de ajuda confiável para contas para verificar assinaturas agregadas. Agregadores suportados da lista de permissões de empacotadores/clientes. Os agregadores devem implementar a interface ERC-4337 IAggregator.
Paymaster — Um contrato que pode pagar a taxa de gás da UserOperation para o Remetente se ETH suficiente for depositado no contrato do EntryPoint. Paymaster implementa uma abstração de gás eficiente. Paymaster deve implementar a interface Paymaster de ERC-4337. Paymaster pode ter sua própria lógica para fazer um acordo com o Remetente. Por exemplo, o Sender paga USDC ao Paymaster e o Paymaster patrocina suas UserOperations com ETH. Na verdade, qualquer token ERC 20 ou mesmo tokens em outras cadeias podem ser suportados, desde que o Paymaster concorde e seja tecnicamente viável.
Wallet Factory — um contrato que pode ser chamado para criar carteiras de contrato inteligentes para usuários ERC-4337. A implantação de uma fábrica de carteiras não requer permissão. Como um componente on-chain, está aberto à auditoria pública e escrutínio transparente. A 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 usa uma UserOperation como entrada.
handleOps verifica o UserOperation na cadeia, verifica se ele é assinado pelo endereço de carteira de contrato inteligente especificado e se a carteira tem Gas suficiente para compensar o Bundler.
Se a verificação for bem-sucedida, o handleOps executará a função de carteira de contrato inteligente de acordo com a assinatura da função e os parâmetros de entrada definidos no calldata do 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 a taxa de gás aos empacotadores a partir do saldo de sua própria conta ou solicitar que o contrato Paymaster pague em seu nome. UserOperations que não possuem gás suficiente não podem passar no processo de verificação na carteira de contrato inteligente de destino e, portanto, falham antes da execução. Mesmo que haja gás suficiente, UserOperations pode falhar durante a execução, por exemplo, devido a erros de tempo de execução. Independentemente de a execução ser bem-sucedida ou não, o contrato do EntryPoint pagará a taxa de gás ao empacotador que aciona a função handleOps.
(Fonte: Documentação oficial:
Após a entrada em vigor do ERC-4337, os usuários agora têm duas maneiras de iniciar transações de blockchain. Uma é a forma original, onde o EOA inicia 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 iniciá-lo na cadeia. O fluxograma a seguir ilustra a diferença entre a transação de envio EOA normal e a operação de envio da carteira de contrato ERC-4337.
A estrada é asfaltada, mas não há muitos passageiros
O ERC-4337 fornece uma estrutura poderosa para usuários e desenvolvedores usarem e construírem AA na plataforma Ethereum. Embora este quadro seja um importante passo em frente, vários desafios e incertezas ainda precisam ser abordados 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 from @niftytable), apenas 65 k+ UserOperations são executadas na cadeia, 90% das quais vêm do Polygon. Portanto, o número de UserOperations realizadas neste momento ainda é muito pequeno, a maioria dos quais são testes de desenvolvedor e apenas uma pequena parte é atribuída aos usuários. Observamos que os produtos que integraram AA ainda estão em seus estágios iniciais. Ao mesmo tempo, você pode ver que o lucro de Bundler é negativo (-700 em termos MATIC). Isso ocorre porque alguns empacotadores no Polygon não calculam o gás de pré-validação corretamente. Este algoritmo de verificação ainda precisa de otimização.
Além disso, há algumas questões que precisam ser abordadas. Um desses problemas é como os Bundlers lidam com falhas de transação. Depois que o Bundler agrupa várias UserOperations, o Bundler primeiro simula a transação para verificar se ela será revertida e, em seguida, calcula se a taxa de gás retornada pelo remetente ou pelo pagador é maior do que a taxa de gás paga pela transação. Se for lucrativo, o Bundler envia esse lote de UserOperations junto como uma transação para o construtor de bloco. No entanto, a transação ainda pode falhar, resultando no Bundler pagando a taxa de gás, mas não recebendo o gás de volta do EntryPoint. Por exemplo, um usuário pode enviar ações para diferentes empacotadores. Os empacotadores estão dispostos a enviar quaisquer operações na cadeia se forem lucrativas e sua simulação for bem-sucedida. Isso significa que, se uma UserOperation for enviada por diferentes Bundlers ao mesmo tempo. Apenas uma transação terá sucesso, apenas um Bundler receberá a taxa de gás do EntryPoint, todos os outros Bundlers perderão gás devido a falha na cadeia. Embora alguém possa argumentar que os usuários não devem fazer isso, tal comportamento seria considerado um ataque mal-intencionado e que o Bundler poderia banir o endereço do remetente e rejeitar quaisquer solicitações futuras desse endereço, essa não é uma abordagem razoável porque os usuários podem ter esta operação foram enviados inadvertidamente. Essas questões precisam ser abordadas adequadamente no código, possivelmente desenvolvendo uma rede de mempool pública inacabada. Além disso, devido a flutuações repentinas de gás, os Bundlers podem enfrentar perdas, mesmo que as transações tenham sido submetidas com sucesso e simuladas como lucrativas.
Outra coisa é o valor máximo extraível (MEV) que pode ser extraído do AA. No contexto do Ethereum, MEV geralmente se refere ao valor que os mineradores ou outros processadores de transações podem extrair manipulando a ordem das transações em um bloco ou incluindo suas próprias transações em um bloco. Alguém notou que a lógica do MEV também pode ser aplicada ao AA, já que os Bundlers são livres para solicitar UserOperations? No entanto, isso é condicional, UserOperations suficientes precisam ser agrupadas para que os Bundlers extraiam o MEV. 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. Em geral, a indústria de AA pode se desenvolver em duas direções: uma é semelhante à rede principal Ethereum, com participantes como Flashbots, Ultra Sound e BloXroute, e a outra é formar um consenso de Bundler para impor uma ordem justa. A última abordagem eliminaria completamente a possibilidade de MEV em AA.
desenvolvimento futuro
pool de memórias público
Embora o ecossistema AA já esteja funcionando, ainda há muito trabalho de desenvolvimento a ser feito. Olhando para todo o ecossistema AA, a maior lacuna no momento é 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 a rede p2p do mempool público esteja disponível em agosto deste ano.
Algoritmo de empacotamento
Ao longo do caminho, a Ethereum Foundation financiou várias equipes de desenvolvimento AA de desenvolvedores dedicados e esforçados. Até o momento, várias versões do cliente Bundler foram desenvolvidas e agora estão disponíveis. Alguns deles são altamente desenvolvidos em termos de maturidade do produto. 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) e muitos mais.
Agora, vamos nos aprofundar no algoritmo de empacotamento com mais detalhes. Atualmente, devido ao baixo número de UserOperations, os Bundlers podem empregar lógica de empacotamento simples e direta, como intervalos de tempo fixos ou o 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: sem um protocolo de consenso como um blockchain, os Bundlers formam uma floresta escura, cada um priorizando o trabalho de acordo com seus próprios interesses e competindo entre si. Os mempools privados, correspondentemente correspondentes aos mempools públicos, têm maior probabilidade de vir primeiro. Porque quando não é lucrativo empacotar UserOperations do mempool público, pode ser lucrativo empacotar UserOperations juntos no mempool privado. Dessa forma, a Bundler tem uma vantagem competitiva quando o assunto é embalagem.
Além disso, como o mempool público é gradualmente aceito, as UserOperations nele terão características diferentes, como diferentes expectativas de lucro do Gas e complexidade de execução on-chain. Os empacotadores realizarão simulações fora da cadeia para avaliar a lucratividade de várias combinações de UserOperations para estabelecer suas estratégias exclusivas de empacotamento. Empacotar mais UserOperations tem o potencial de render 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. 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 construtores de bloco para executar transações. Sob diferentes preços de gás de mercado e condições de volatilidade do gás, os empacotadores podem ter diferentes estratégias de embalagem. Ao mesmo tempo, esses cálculos de verificação e política precisam consumir recursos de computação de hardware local e recursos de nó de blockchain. Os empacotadores também precisam garantir que os usuários tenham uma boa experiência e que não enfrentem atrasos excessivos após o envio de uma UserOperation.
Embora as soluções para esses desafios permaneçam incertas, podemos ter certeza de que a evolução da indústria de AA e os esforços combinados dos desenvolvedores acabarão por encontrar soluções. Como construtor de infraestrutura, a BlockPI espera resolver problemas no desenvolvimento da indústria de AA, seja como desenvolvedor ou para fornecer infraestrutura de AA amigável para outros desenvolvedores.
A infraestrutura deve se adaptar
AA abstrai vários papéis no comportamento da transação na cadeia, incluindo remetentes, empacotadores, pagadores de gás, carteiras de contrato e assinantes, permitindo que os usuários tenham um maior grau de liberdade ao usar o blockchain. Além disso, os serviços dentro de um AA podem ser implantados separadamente.
Para se adaptar à adoção em larga escala do AA, os provedores de infraestrutura precisam primeiro fornecer pelo menos dois serviços básicos, ou seja, o serviço Bundler e o serviço Paymaster.
No serviço Bundler, o provedor de infraestrutura pode precisar desenvolver um mempool privado com Bundlers para garantir uma boa experiência do usuário. Especificamente, os provedores de infraestrutura precisam integrar vários clientes Bundler para garantir a robustez dos serviços Bundler. Esses clientes Bundler são desenvolvidos em diferentes linguagens de programação, mas todos fornecem um conjunto padrão de métodos JSON RPC especificados pela equipe principal do ERC-4337. Atualmente, não há muitos métodos disponíveis, mas mais métodos serão adicionados no futuro. Os provedores de serviços de infraestrutura devem fornecer suporte contínuo e completo para essas APIs.
Além disso, é importante otimizar e adaptar o relacionamento entre a API do Bundler e o RPC do cliente do nó de origem. Sabemos que o cliente do nó atual não está bem otimizado para a capacidade de resposta e adaptabilidade do AA. Certos métodos da API do Bundler exigem que o índice de dados do AA funcione. Por exemplo, pesquisar uma UserOperation por hash requer a indexação de todas as UserOperations. Caso contrário, o consumo de hardware dessa solicitação única será muito alto e a solicitação demorará muito para retornar.
Além disso, os provedores de infraestrutura também precisam integrar diferentes serviços Paymaster para fornecer aos clientes uma experiência de usuário sem gás e fornecer a eles diferentes opções de serviço. Isso requer boa comunicação e integração com provedores de serviços Paymaster terceirizados.Ao mesmo tempo, de acordo com a demanda do mercado, também podem ser projetadas soluções de integração mais convenientes com base nos serviços existentes do Paymaster. Outros serviços, como assinaturas agregadas, fábricas de carteiras, etc., também são direções possíveis para desenvolvimento e integração futuros.
Atualmente, o BlockPI está realmente tentando atingir todos os objetivos acima. Além disso, estamos nos comunicando com quase todos os clientes Bundler e provedores de serviços Paymaster na comunidade e fizemos da integração do serviço AA na rede BlockPI nossa principal prioridade. Também estamos tendo discussões aprofundadas com os desenvolvedores de carteiras AA para entender as necessidades do usuário. Portanto, damos boas-vindas à cooperação e trocas com todos os Bundlers, Paymasters e carteiras à medida que avançamos. Nosso objetivo geral é construir e desenvolver o ecossistema AA com outros, impulsionando seu crescimento e desenvolvimento da melhor maneira possível. Ao trabalharmos juntos, esperamos fazer uma contribuição significativa para a indústria de AA como um todo e apoiar seu desenvolvimento contínuo. Afinal, nossa missão final é ser pioneira na indústria e promover o desenvolvimento do ecossistema AA para que os usuários da web2 possam desfrutar de sua experiência blockchain sem barreiras.
Resumir
Do ponto de vista de AA, estamos em um novo momento histórico. Embora tenhamos estradas pavimentadas no boulevard, ainda não há muitos pilotos. No momento, a aplicação de AA ainda está em sua infância. O ERC-4337 fornece uma estrutura poderosa para usuários e desenvolvedores usarem e construírem AA na plataforma Ethereum. No entanto, ainda existem muitos desafios e incertezas que precisam ser resolvidos.
O provedor de infraestrutura de AA precisa fornecer o serviço Bundler e o serviço Paymaster para seus usuários e precisa integrar vários clientes Bundler e provedores de serviços Paymaster para garantir a robustez do serviço. Para otimizar a capacidade de resposta entre a API e os clientes do nó, os dados AA podem precisar ser indexados para reduzir o consumo de hardware para uma única solicitação. Para fornecer uma melhor experiência ao usuário, os provedores de infraestrutura também precisam fornecer aos usuários mais opções de serviço.
No futuro, conforme o ecossistema AA continuar a crescer e os mempools públicos surgirem, a estratégia para selecionar e empacotar UserOperations se tornará mais complexa. Cada Bundler prioriza seu trabalho de acordo com seus próprios interesses e compete com outros Bundlers. Os empacotadores precisam definir seus próprios parâmetros de gás de transação, que afetam a prioridade dos construtores de bloco para executar transações. Sob diferentes preços de gás de mercado e condições de volatilidade do gás, os empacotadores podem ter diferentes estratégias de embalagem.
Embora as soluções para esses desafios sejam incertas, podemos ter certeza de que a evolução da indústria de AA e os esforços combinados dos desenvolvedores acabarão por encontrar soluções. Como um construtor de infraestrutura, BlockPI espera ser um solucionador de problemas no desenvolvimento da indústria de AA, seja como desenvolvedor ou fornecendo infraestrutura de AA amigável para outros desenvolvedores. Nossa missão é promover o desenvolvimento do ecossistema AA para que os usuários do Web2 possam desfrutar de sua experiência blockchain sem barreiras.