Abstração de conta vs. Abstração de conta nativa

Em termos simples, a Abstração de Conta no ERC-4337 é uma infraestrutura opcional na cadeia de blocos. Pode optar por adoptá-lo ou não. Uma vez adoptada, fornece funcionalidades semelhantes às das Contas de Contrato (CA), tais como multisig, pagamento de taxas de gás com tokens ERC-20, recuperação social e muito mais. Muitos fornecedores de serviços, como a stackup, estão a trabalhar nesta infraestrutura. No entanto, esta infraestrutura não foi amplamente adoptada pelas seguintes razões

• Problema dos agrupadores: Apenas os agrupadores participam na verificação, o que leva a uma dependência excessiva dos agrupadores.
• Lucro insuficiente para os agregadores: Isto deve-se principalmente à pequena escala, o que exige que mais DApps escolham a infraestrutura de Abstração de Contas para poupar taxas de gás.
• Concentração de agregadores: Os agregadores estão concentrados num pequeno número de fornecedores (Alchemy, Pimlico, Stackup), o que representa um risco de centralização.
• Taxa de retenção: Para além dos lançamentos aéreos, a taxa de retenção de utilizadores dos serviços de resumo de contas é muito baixa.

Muitas soluções de camada 2 implementam a abstração de conta diretamente na cadeia nativa para reduzir as taxas de gás. Isto é conhecido como abstração de conta nativa. No entanto, esta abordagem também tem outros problemas, como o facto de os utilizadores que não querem esta funcionalidade não poderem optar por não a utilizar, as capacidades limitadas entre cadeias e uma falta geral de flexibilidade.

Este artigo menciona alguns termos, como a distinção entre EOA e CA (em termos simples, Metamask é EOA, contratos é CA), bem como bundlers (no ecossistema de Abstração de Contas, os utilizadores enviam UserOperations para os bundlers para empacotamento e processamento na cadeia, em vez de as enviarem para validadores de nós/Mempool). Para obter explicações pormenorizadas, pode clicar nas ligações para os dois artigos acima mencionados e consultar os artigos anteriormente publicados sobre a Gate Learn.

O que é o RIP-7560?

O RIP-7560 é uma proposta de melhoria para a abstração de contas (EIP-2938/ERC-4337). A introdução do novo tipo de transação "AA_TX_TYPE" incorpora outras funções para além do comerciante de pacotes (construtor de blocos/validador de nós) nas fases de verificação e execução da transação. Já não depende apenas do comerciante de pacotes para o empacotamento e submissão na cadeia, resolvendo assim as questões de centralização anteriormente mencionadas. Além disso, o RIP-7560 proporciona um design normalizado para garantir uma maior conformidade para os futuros adoptantes. O presente artigo irá aprofundar as normas melhoradas pela proposta RIP-7560 e abordar as preocupações suscitadas.

A mudança mais fundamental

Trata-se de uma alteração do protocolo da camada de consenso \
A proposta mais antiga de abstração de contas foi efetivamente apresentada em setembro de 2020 no EIP-2938. Acabou por ser aceite pela comunidade e implementado no Ethereum. A razão pela qual o ERC-4337 acabou por ser adotado em vez do 2938 é que o 4337 não exige alterações na camada de consenso, tornando-o relativamente mais fácil de aceitar pela comunidade.

Ao contrário do ERC-4337, a proposta RIP-7560 implicará alterações maiores, especificamente ao nível do protocolo da camada de consenso (o prefixo RIP indica que se trata de uma proposta de nível inferior para melhorar a tecnologia Rollup). A vantagem correspondente que traz é a capacidade de evitar depender diretamente da infraestrutura da cadeia nativa L2.

Introdução de um novo tipo de transação \
Foi introduzido um novo tipo de transação: o quarto tipo de transação, também conhecido como "AA_TX_TYPE" (que foi efetivamente proposto no antigo EIP-2938). Não só suporta todas as funcionalidades de uma AC típica (como o pagamento da taxa de gás e as funções de pagamento automático recorrente mencionadas no artigo da Visa), mas, ao contrário do ERC-4337, também permite que as EOAs existentes apresentem transacções. Isto significa que a presente proposta visa promover uma adoção mais ampla.

Lógica de execução da transação

Esta proposta é compatível com a norma ERC-4337 e adopta a lógica de transação que separa a execução e a verificação, o que exige mais gás. Além disso, de acordo com a documentação, a execução da transação é idêntica à do ERC-4337, em que todos os passos da fase de verificação devem ser concluídos sem reverter. Após a verificação, os dados da chamada serão enviados para a conta para execução. Após a execução, o Paymaster pode efetuar a lógica pós-transação. O processo de execução completo é ilustrado no diagrama seguinte.

Fluxograma de execução (Fonte: Documento GitHub do RIP-7560)

Principais preocupações relativas à proposta

O autor levantou as seguintes questões durante a discussão no fórum Ethereum Magicians: RIP-7560: Abstração da conta nativa

Irá restringir o desenvolvimento de serviços de abstração de contas baseados na intenção?

Prevê-se que os principais intervenientes nos serviços baseados na intenção sejam a Uniswap V4 e a UniswapX, com a UniswapX a planear desenvolver serviços de abstração de contas. Além disso, foi proposta uma direção semelhante pelo ERC-7521. Em resposta aos debates na comunidade, um dos autores desta proposta, Yoav Weiss, referiu que, juntamente com a RIP-7560, existe também uma regra de verificação da abstração de contas denominada ERC-7562. A conceção do sistema de intenções só pode ser tornada compatível com o RIP-7560 e não com a regra de verificação. Assim, poderia ser utilizada uma rede de intent solver separada, permitindo usufruir das vantagens do RIP-7560 sem entrar em conflito com a conceção do intent.

Risco de Irreversibilidade

Alguns membros da comunidade questionaram se esta proposta é semelhante a "tentar incorporar um sistema operativo em bare metal", apresentando riscos significativos. A isto, Yoav Weiss respondeu: Esta proposta destina-se a cadeias que optam por incorporar um sistema operativo (como o ERC-4337) em bare metal, nomeadamente cadeias L2 que optam por implementar uma abstração de conta nativa. Existem escolhas suficientes no ecossistema Ethereum, e os utilizadores podem optar por outras cadeias L2 que não tenham implementado a abstração de conta nativa.

Considerações sobre complexidade e custos

Relativamente às preocupações sobre a complexidade e os elevados custos resultantes da proposta, Dror Tirosh, um dos autores, respondeu que tal é inerente à própria abstração da conta. A abstração da conta resulta do facto de querermos validar dados externos utilizando um código EVM genérico. A eliminação desta complexidade exporia os produtores de blocos a ataques DoS ou exigiria a eliminação da utilização geral do código EVM, o que anula o objetivo do desenvolvimento da tecnologia de abstração de contas.

Conclusão

Atualmente, pelo menos os fornecedores de infra-estruturas de abstração de contas, como o fundador da Stackup, acolhem com agrado essas alterações na camada de consenso, o que indica que as questões fundamentais dos actuais serviços de abstração de contas ainda prevalecem. Se um número insuficiente de dApps não adotar esta solução para reduzir as taxas de gás e introduzir funcionalidades semelhantes às da CA de fácil utilização, os fornecedores de pacotes não lucrarão e as taxas de retenção de utilizadores nunca aumentarão. No entanto, se os serviços desenvolvidos com base nesta proposta puderem suportar sem problemas os EOAs existentes na cadeia para suportar nativamente a abstração de contas, estaremos mais perto do objetivo final (adoção em massa, Metamask que suporta a abstração de contas, etc.) e a experiência do utilizador na interação com DApps melhorará progressivamente.