Explorando soluções de abstração de contas multichain: suporte nativo e compatibilidade com o ERC-4337

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.

Starknet transaction flow
An illustration outlining the flow of a Starknet transaction

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.

Aviso legal
Este artigo pode ter conteúdo sobre produtos que não estão disponíveis na sua região. É fornecido apenas para fins informativos gerais e nenhuma responsabilidade ou obrigação é aceita por qualquer erro de fato ou omissão aqui expressos. Representa as opiniões pessoais dos autores e não representa as opiniões da OKX. Não se destina a fornecer aconselhamento de qualquer tipo, incluindo, mas não se limitando a: (i) aconselhamento de investimento ou recomendação de investimento; (ii) uma oferta ou solicitação para comprar, vender ou manter ativos digitais, ou (iii) aconselhamento financeiro, contábil, jurídico ou fiscal. As participações em ativos digitais, incluindo stablecoins e NFTs, envolvem um alto grau de risco, podem flutuar muito e podem até se tornar inúteis. Você deve considerar cuidadosamente se negociar ou manter ativos digitais é adequado para você, tendo em conta a sua condição financeira. Consulte seu profissional jurídico/fiscal/de investimentos para tirar dúvidas sobre suas circunstâncias específicas. Os recursos da OKX Web3, incluindo a OKX Web3 Wallet e a OKX NFT Marketplace estão sujeitas a termos de serviço separados em www.okx.com.
© 2023 OKX. Este artigo pode ser reproduzido ou distribuído em sua totalidade, ou trechos de 100 palavras ou menos deste artigo podem ser usados, desde que tal uso não seja comercial. Qualquer reprodução ou distribuição do artigo inteiro também deve indicar em destaque: "Este artigo é © 2023 OKX e é usado com permissão". Os trechos permitidos devem citar o nome do artigo e incluir atribuição, por exemplo "Nome do artigo, [nome do autor é aplicável], © 2023 OKX". Não são permitidos trabalhos derivados ou outros usos deste artigo.
Expandir
Artigos relacionados
Ver mais
Ver mais