Conecte-se com a gente em afterdarklabs.xyz ou @afterdark_labs
Contexto
A EIP-4337 (Proposta de Melhoria da Ethereum), também conhecida como abstração de contas, surgiu a partir da ideia de separar o mecanismo de verificação do mecanismo de inclusão de transações na Ethereum. A separação ou abstração desses dois mecanismos permite várias melhorias importantes na experiência do usuário, incluindo: patrocínio dos custos de gás, pagamentos de gás em tokens ERC20 e suporte a mecanismos alternativos de verificação além do ECDSA (Elliptic Curve Digital Signature Algorithm ou Algoritmo de assinatura digital de curva elíptica), para citar alguns exemplos. Antes de examinarmos os casos de uso, vamos discutir como a EIP-4337 foi criada.
No lançamento, a Ethereum decidiu que haveria dois tipos de contas:
- Contas de Propriedade Externa (EOAs, ou Externally Owned Accounts)
- Contas de Contratos Inteligentes (contas de contratos)
Imagem da Ethereum developer docs
As EOAs podem ser pensadas como contas de usuário comuns. Elas são controladas por chaves privadas e, o que é importante, podem enviar mensagens criando e assinando transações. Essas são o tipo de contas que a maioria das carteiras usam para iniciar transações. Se você já usou a MetaMask ou a carteira Coinbase para interagir com um dApp, você usou uma EOA.
Em contraste com as EOAs, uma conta de contrato é de natureza reativa. O código da conta de contrato pode ler e escrever no armazenamento interno e até mesmo enviar outras mensagens, mas somente após receber uma mensagem inicial. Essa é uma distinção importante e veremos o motivo mais adiante. Por ora, lembre-se de que as EOAs são essencialmente o único tipo de conta que pode realmente criar e enviar uma transação sem primeiro receber uma mensagem.
Além dessa arquitetura de dois tipos de contas, os criadores da Máquina Virtual Ethereum (EVM) decidiram não incluir a lógica de verificação de transações na própria EVM. Por que eles tomaram essa decisão? Bem, em primeiro lugar, havia preocupações sobre como gerenciar os custos de gás e de computação caso uma transação se mostrasse inválida. Por exemplo, se um minerador tivesse que processar uma transação antes de determinar se ela era válida, essa sobrecarga computacional poderia servir como um vetor de negação de serviço.
EIPs Anteriores
Os potenciais benefícios da abstração de contas foram percebidos desde muito cedo no desenvolvimento da Ethereum. Na verdade, existem propostas desde 2016, sugerindo uma forma de abstração. A linha do tempo abaixo abrange alguns dos principais precursores da EIP-4337:
- EIP-86 e EIP-208 (2016-2017) — A EIP-86 sugeriu a criação de um contrato de encaminhamento. Sob a EIP-86, se a assinatura de uma transação fosse v=r=s=0, então a transação era considerada válida e o endereço de envio era definido como um ponto de entrada específico. As transações poderiam então começar a partir desse ponto de entrada e fazer uma chamada para uma conta de contrato que teria a lógica para enviar outras mensagens. Problematicamente, essas EIPs não preservaram a exclusividade do hash da transação e também criaram um vetor de negação de serviço, onde uma única transação poderia invalidar todo um conjunto de transações no mempool (é uma memória temporária intermediária na qual as transações do usuário são momentaneamente armazenadas).
- Propostas informais de 2017 — Houve várias ideias circulando para implementar a abstração de contas em 2017, algumas das quais começaram a se assemelhar à EIP-4337 (Panic + PAYGAS). Ainda assim, nenhuma delas abordou o vetor de negação de serviço que poderia ser causado por uma única transação inválida.
- Proposta informal de 2018 — Uma ideia de 2018 resolvia principalmente o vetor de negação de serviço, modificando a EVM para verificar durante a parte de verificação da execução da transação se uma conta lê ou escreve o estado das coisas fora de sua própria conta. Se fizesse isso, a transação seria descartada. Isso faria com que a única maneira de uma transação válida no mempool se tornar inválida fosse se a própria transação causasse esse estado inválido.
- EIP-2938 (2020) — A EIP-2938 pegou as ideias anteriores sobre abstração de contas e as reuniu em uma EIP formal. Ela propôs um novo tipo de transação e ponto de entrada, conforme descrito na EIP-86, utilizou as ideias Panic + PAYGAS de 2017 e sugeriu impedir que contas lessem ou escrevessem o estado de outras contas durante a parte de verificação da execução da transação (como proposto em 2018). Embora isso realmente estivesse começando a se parecer com a EIP-4337, a diferença chave aqui é que a EIP-2938 era uma mudança na camada de protocolo. No final, a decisão foi tomada em favor de uma implementação de abstração de contas em uma camada superior.
Resumo da EIP
A ideia central da EIP-4337 era realmente alcançar o mesmo resultado da EIP-2938, mas sem fazer quaisquer mudanças no protocolo base de consenso. Isso foi alcançado permitindo que as contas agrupassem as ações que desejavam executar em uma estrutura chamada UserOperation, em vez de criar um novo tipo de transação na camada de protocolo. O objeto UserOperation pode então ser enviado para um mempool dedicado, onde os empacotadores podem pegar e colocar todos em uma transação agrupada que faz uma única chamada para um contrato de ponto de entrada global. O processo é delineado abaixo:
Diagrama da proposta oficial da EIP-4337
O que temos aqui é um sistema baseado em um contrato de ponto de entrada global e um mercado aberto semelhante ao MEV (Valor Máximo Extraível) que organiza várias operações em uma única transação de encapsulamento, verifica todas essas transações e, em seguida, as executa.
Observe que o contrato de ponto de entrada é colocado na cadeia. As carteiras devem optar individualmente por confiar neste contrato de ponto de entrada para interagir com ele em nome de seus usuários.
Vamos explorar ainda mais o processo passo a passo:
1. Criação do Objeto UserOperation
Usuários que desejam aproveitar a EIP-4337 primeiro criam um objeto UserOperation a partir de uma EOA regular que interagirá com seu contrato de conta. O objetivo deste objeto é substituir uma transação regular e, como resultado, os campos serão relacionados ao contrato da conta, em oposição à EOA. O objeto UserOperation e seus campos podem ser vistos abaixo:
Observe que o remetente é definido como a conta de contrato, que por si só verificará a assinatura, além de receber e executar os dados de chamada (calldata).
2. Agrupamento e execução de UserOperations
Objetos UserOperation são enviados para um mempool dedicado, onde um conjunto de empacotadores é responsável por lidar com esses objetos e incluí-los em uma única transação para o contrato de ponto de entrada.
Antes que uma UserOperation seja elegível para inclusão na transação, um empacotador deve primeiro realizar um conjunto de verificações de integridade para verificar se a UserOperation foi formada adequadamente usando entradas válidas para seus campos. Se essas verificações forem aprovadas, o empacotador executa uma simulação para determinar se a UserOperation é de fato válida e capaz de pagar por sua execução. Isso é feito fazendo uma chamada para EntryPoint.simulateValidation():
Função simulateValidation do contrato de ponto de entrada global
Isso, por sua vez, chama sender.validateUserOp() como parte da verificação. A função validateUserOp() também verifica se a assinatura em si é válida. Uma implementação básica dessa função pode ser vista abaixo:
Função validateUserOp de um contrato de conta básica
Se todas essas verificações forem aprovadas, então a função será revertida com o erro esperado, a UserOperation será considerada válida e o empacotador a adicionará ao mempool dedicado. Essa UserOperation agora estaria apta a ser agrupada e incluída na transação. É aqui que os empacotadores fazem sua mágica, enviando (como calldata) um conjunto de UserOperations para a função EntryPoint.handleOps():
Função handleOps do contrato de ponto de entrada global
Isso, por sua vez, chamará UserOperation.sender com a UserOperation.calldata. Cabe à conta de contrato implementar um fluxo de trabalho para lidar e reagir com esta calldata. Tipicamente, a conta implementará uma função execute() que analisa a calldata como uma série de uma ou mais chamadas que a conta de contrato deve fazer.
Compreendendo o processo de criação e inclusão de uma transação EIP-4337 padrão, vamos discutir algumas funcionalidades extras que podem ser incluídas em uma transação EIP-4337.
Extensões
Existem duas extensões dentro da EIP-4337 que valem a pena mencionar: Patrocinadores (Paymasters) e Agregação de Assinaturas (Signature Aggregation). Patrocinadores são contas de contrato que podem pagar em nome de outros usuários. Isso é usado para patrocinar ou oferecer de outra forma transações sem gás aos usuários. O fluxo de trabalho ligeiramente modificado se parece com isso:
Diagrama da proposta oficial da EIP-4337
Os agregadores de assinaturas também são contas de contrato auxiliares, mas em vez de pagar em nome de outros usuários, eles validam uma assinatura agregada para várias transações, melhorando a eficiência do processo de verificação. Por exemplo, assinaturas BLS geradas por várias chaves únicas podem ser agregadas em uma única assinatura, que pode ser verificada em um único passo. Uma implementação básica de um tal agregador pode ser encontrada aqui.
Casos de Uso
A EIP-4337 traz muitas vantagens tanto para os usuários quanto para os protocolos:
- Os protocolos podem patrocinar pagamentos de gás para oferecer aos usuários uma experiência sem a necessidade de gás;
- Pagamentos de gás podem ser feitos em tokens ERC20, para que os usuários não precisem mais ter ou usar ETH nativo diretamente;
- Mecanismos alternativos de verificação podem ser suportados além do ECDSA. Isso é benéfico para proteger a Ethereum para o futuro caso a computação quântica torne o ECDSA quebrado;
- A experiência do usuário é aprimorada para implementar permissões de conta mais granulares, como acesso a contas baseada em funções;
- Contas de assinatura múltipla podem se tornar cidadãs de primeira classe e podem ver uma adoção mais ampla como resultado.
Falando de maneira geral, a abstração de contas é amplamente vista como um passo importante no caminho da Ethereum em direção à adoção em massa pelos usuários.
Considerações de Segurança
Contrato de Ponto de Entrada
A forma como a EIP-4337 é estruturada faz com que a maior parte do risco de segurança esteja no contrato de ponto de entrada. Isso funciona como um ponto central de confiança para cada conta compatível com a EIP-4337.
Contas de Contratos
Para desenvolvedores de carteiras inteligentes, há algumas coisas a considerar ao implementar contas EIP-4337. Essas contas terão que implementar suas próprias funções de verificação que devem checar com precisão assinaturas (ou mecanismo de autenticação equivalente), incrementar nonces (números de sequência) e pagar taxas. Também é importante ter cuidado especial para garantir que as funções na conta sigam os princípios de privilégio mínimo. Adicionar um modificador que exija que o msg.sender seja o contrato de ponto de entrada é uma boa ideia para garantir que interações sensíveis possam ser chamadas apenas pelo próprio ponto de entrada.
Considerações Finais
A implementação de alto nível da abstração de contas da EIP-4337 oferece várias vantagens para usuários e protocolos. Protocolos podem oferecer aos seus usuários uma experiência melhor, patrocinando taxas de transação, e os usuários até podem aproveitar a EIP-4337 para pagar diretamente em tokens ERC-20. Importante destacar que a EIP-4337 é um dos primeiros passos rumo à criação de transações resistentes a computadores quânticos na Ethereum. Embora grande parte da responsabilidade de segurança recaia sobre o contrato de ponto de entrada, os desenvolvedores de contas também devem estar cientes de que precisam implementar parte da funcionalidade por conta própria. Recomendamos minimizar a superfície de ameaça restringindo o máximo possível das operações sensíveis ao contrato de ponto de entrada.
Se você estiver interessado em uma auditoria de contrato inteligente ou outros serviços de segurança, comece o processo visitando afterdarklabs.xyz ou entre em contato diretamente pelo e-mail [email protected].
Artigo escrito por AfterDark Labs. Traduzido por Marcelo Panegali.
Top comments (0)