De autoria de Kiwi Yao, pesquisador @OKX Ventures
As soluções de abstração de contas (AC) multichain são uma maneira nova e inovadora de interagir com várias blockchains. Elas permitem que os usuários criem e gerenciem contas em várias blockchains sem ter que se preocupar com os detalhes técnicos subjacentes, como ter tokens nativos suficientes para pagamentos de gás. Isso torna muito mais fácil para os usuários começarem a usar a tecnologia blockchain e usarem várias blockchains simultaneamente. Existem dois tipos principais de soluções de AC multichain: suporte nativo e compatibilidade com o ERC-4337.
O suporte nativo ocorre quando uma blockchain oferece suporte direto à AC multichain. A compatibilidade com o ERC-4337 ocorre quando uma solução de escalabilidade de blockchain ou camada 2 usa um contrato inteligente para implementar a AC multichain. Neste artigo, exploraremos o suporte nativo e a compatibilidade com o ERC-4337 para soluções de AC multichain. Também discutiremos as vantagens e desvantagens de cada abordagem.
Redes compatíveis com abstração de conta ERC-4337
Arbitrum
A Arbitrum ativou oficialmente os endpoints de AC no Arbitrum One e no Arbitrum Nova após a adoção da proposta do AIP-2. A proposta introduz um novo endpoint de RPC – eth_sendRawTransactionConditional — projetado especificamente para atender às necessidades dos empacotadores do ERC-4337.
Polygon
O Polygon é compatível com o ERC-4337 e consegue isso aproveitando soluções como Biconomy, Gas Station Network (GSN), Infura e Gelato para metatransações. Além disso, o zkEVM da Polygon suporta AC através do ERC-4337, permitindo aos usuários pagar com qualquer token.
Optimism
Várias infraestruturas de AC estão disponíveis atualmente na mainnet do OP através de projetos como Alchemy, Biconomy, CyberConnect, Pimlico e Stackup, embora informações arquitetônicas detalhadas ainda não tenham sido divulgadas.
BNB
No roteiro técnico da BNB Chain para 2023, a equipe menciona o estabelecimento de infraestrutura de AC. A compatibilidade com o ERC-4337 também está confirmada, com mais detalhes previstos para serem disponibilizados em breve.
Abstração de conta nativa
Starknet
A Starknet oferece suporte nativo a AC, renderizando todas as contas como contas de contrato (CAs) ou contas inteligentes. Os objetivos do suporte nativo à AA incluem abstração de assinatura e abstração de pagamento. O objetivo é permitir que diferentes contratos de contas utilizem diversos esquemas de validação de assinatura e diferentes modelos de pagamento para transações. Ao fazer isso, a experiência de gerenciamento da conta será bastante melhorada, pois os indivíduos agora têm mais opções em relação à validação de assinatura e pagamento de um terceiro ou de um contrato inteligente.
Fluxo de transação da Starknet
Quando uma transação é selecionada para ser adicionada a um bloco, o sequenciador a seleciona e a executa. A execução da transação acontece em duas etapas. Primeiro, o sequenciador solicita ao contrato da conta que valide a transação. Em seguida, solicita ao contrato da conta que o execute. Essas duas etapas são codificadas em duas funções distintas no contrato da conta — validação e execução.
A distinção entre essas etapas permite que a Starknet OS garanta o pagamento ao sequenciador. Para evitar um ataque de negação de serviço (DoS) no pool de transações da Starknet e o seu preenchimento com transações inválidas, a Starknet exige que um nó que aceita uma transação simule localmente contra o estado conhecido antes de adicionar a transação ao pool e transmiti-la para outros nós e sequenciadores. Ao completar a simulação, a transação pode então ser inserida no pool e propagada na rede.
Fonte: StarkNet
AC da Starknet X AC do ERC-4337
A Starknet remove a complexidade adicional introduzida pelo empacotador e designa o sequenciador para cumprir a função do empacotador. Isso é diferente da solução de AC do ERC-4337, que exige que os empacotadores executem as operações do usuário (user ops).
Comparado à solução de AC do ERC-4337, a Starknet não incorpora um protocolo de abstração de taxas de transação semelhante ao do pagador.
A Starknet também não faz distinção entre transações regulares e operações do usuário, simplificando o processo.
Uma diferença notável está na implementação. A Starknet implanta a CA primeiro, antes de poder ser invocada. Essencialmente, a Starknet exige que contas com saldos de tokens criem uma nova CA chamando uma função especializada de “deploy_account”. Este contrato da conta implementada pode pagar gás. Comparativamente, a solução de AC do ERC-4337 não requer implementação antecipada. O empacotador implementa uma CA executando uma transação de operação do usuário com um parâmetro initCode não nulo. Não é necessária uma conta com saldo de token para o processo de implementação e a taxa do gás pode ser paga pelo pagador.
zkSync
O zkSync suporta a AC nativa e oferece compatibilidade com a Máquina Virtual do Ethereum (EVM). Semelhante à Starknet, o zkSync visa a abstração de assinatura e pagamento, suportando diferentes esquemas de verificação de assinatura para vários contratos de conta e diversos modelos de pagamento e formulários de token para transações.
Fluxo de transação do zkSync
O fluxo de transação do zkSync envolve o envio individual da transação assinada ao operador, que é então enviada ao bootloader para validação. Após a validação e aquisição da taxa, o bootloader chama a CA para executar a transação.
AC do zkSync X AC do ERC-4337
Ao contrário da solução de AC do ERC-4337, o zkSync não faz distinção entre contas externas (EOAs) e CAs.
O zkSync permite que a função validTransaction chame contratos externos implementados. Este é um recurso restrito em Ethereum, pois pode criar uma mudança de estado que faz com que a validação da transação seja aprovada e o aspecto de execução da transação falhe.
Outra diferença é que o zkSync permite que a função validTransaction e o pagador chamem o armazenamento externo da CA que emitiu esta transação. Por exemplo, o saldo do token da CA no contrato externo pode ser visualizado graças às funções pagador e activateTransaction. Em contraste, a Ethereum proíbe tal recurso.
Comparação de soluções de AC entre redes compatíveis com zkSync, Starknet e ERC-4337
Semelhanças
As redes compatíveis com zkSync, Starknet e ERC-4337 compartilham processos de AC semelhantes. Eles incluem a fase de verificação, o mecanismo de taxas (pagas por contrato de conta ou pagador) e a fase de execução. Além disso, as interfaces de carteira de contrato inteligente são categorizadas nas funções validTransaction e executeTransaction.
zkSync, Starknet e ERC-4337 lidam com ataques DoS de forma semelhante. A lógica de contrato do zkSync só pode tocar em seus próprios slots e sua lógica de contrato não pode usar variáveis globais. Da mesma forma, o sequenciador da Starknet requer emulação local antes de adicionar transações ao pool de memória e transmiti-las. Por último, a operação do usuário do ERC-4337 coloca um limite de gás na etapa validUserOp e exige que o pagador penhore tokens.
Diferenças
A maior diferença seria que o zkSync e a StarkNet são ambas AA nativas com diferenças arquitetônicas em relação às redes compatíveis com ERC-4337.
Em relação ao consumo de gás on-chain, zkSync e StarkNet são soluções de escalabilidade da camada 2 que precisam considerar os custos de rollup.
Existem diferentes funções relativas à execução de AC. A arquitetura do zkSync possui operador e bootloader (contrato de sistema) trabalhando juntos para cumprir as operações do usuário. Para a StarkNet, o sequenciador lida com as operações do usuário, sem mecanismos de empacotador e pagador. Por último, as redes compatíveis com o ERC-4337 têm arquiteturas diferentes envolvendo empacotadores e contratos de ponto de entrada.
Outra diferença importante é se as transações podem ser enviadas antes da implementação da CA. Tanto na StarkNet quanto no zkSync, o contrato de ponto de entrada não possui um campo initCode que permite implementar a CA para o indivíduo. Isso faz com que nenhum deles possa enviar transações antes da implementação da conta.
Por fim, há uma diferença na chamada de contratos externos é que o zkSync permite que a função validTransaction chame contratos externos implementados. No entanto, tanto as redes compatíveis com ERC-4337 quanto a Starknet não permitem isso.
Diferença no pagador
A Starknet não tem interface de pagador.
Para redes compatíveis com ERC-4337, a interface de pagador define validPaymasterOp. Isso define a lógica para o pagador pagar por uma transação. A interface também usa a função postOp, que garante que o pagador possa extrair a compensação da taxa de gás após a execução da transação. O pagador precisa depositar Ethereum no contrato de ponto de entrada como forma de pagamento de gás e penhorar Ethereum no contrato de ponto de entrada para evitar que bots criem lotes maliciosos.
O zkSync é semelhante às redes compatíveis com ERC-4337, onde a interface define as funções validPaymasterOp e postOp. As definições são semelhantes às do ERC-4337, mas esta parte da função ainda não foi implementada. Ao contrário do pagador do ERC-4337, o pagador do zkSync não iniciará a execução até chamar postTransaction quando tiver gás suficiente. Por outro lado, o pagador do ERC-4337 não chamará postOp se validPaymasterUserOp não retornar um contexto.
Tabela de comparação
Precisa de uma referência rápida para descobrir a diferença entre suporte nativo e redes compatíveis com ERC-4337? Confira nossa tabela abaixo.
Comparação | ERC-4337 | Starknet | zkSync |
|---|---|---|---|
Conta AC | Contrato inteligente | Protocolo nativo | Protocolo nativo |
Lógica de processo | Fase de verificação → Mecanismo de taxas (pagas por contrato de conta ou pagador) → Fase de execução | ||
Processo de execução/invocação | Empacotador → Ponto de entrada | Sequenciador | Operador → Bootloader |
Papel na determinação da ordem da transação | Empacotador | Sequenciador | Operador |
Papel na determinação do gás | Empacotador | Sequenciador | Operador |
Consumo de taxa de gás | Camada 1 | Camada 1 on-chain + Camada 2 | Camada 1 on-chain + Camada 2 |
As transações podem ser enviadas antes da implementação do contrato da conta | Sim | Não | Não |
Regras de validação do pagador | Lógica definida por meio de activatePaymasterOp e postOp, o pagador precisa depositar e fazer staking de Ether | Sem pagador | Lógica definida por meio de activatePaymasterOp e postOp, onde a lógica de chamada de postOp é ligeiramente diferente da Ethereum |
Os contratos externos podem ser chamados | Não | Não | Sim |
Como mitigar ameaças DoS | As operações do usuário impõem limitação de gás na etapa validUserOp, e o pagador precisa fazer staking de tokens. | As transações devem ser adicionadas ao pool de memória e simuladas localmente antes da transmissão. | Só é permitido tocar em seus próprios slots, não é possível usar variáveis globais. |
Conclusão
À medida que o Ethereum introduz a AC, estamos testemunhando muitas outras redes seguirem o exemplo, abordando uma série de problemas que poderiam tornar a adoção em massa mais desafiadora. Com a AC multichain, os ecossistemas concorrentes podem estar mostrando que não estão muito atrás na solução de problemas como inflexibilidade no pagamento do gás e dependência de chaves privadas.
A AC multichain despertou seu interesse em explorar o espaço Web3 conosco? Descubra como a OKX integrará a AC em nossa carteira multichain.
