---
title: "Abstração de conta (ERC-4337) vs. transações meta (ERC-2771)"
description: "Saiba por que os desenvolvedores estão adotando abstração de conta em vez de transações meta"
---

# Abstração de conta (ERC-4337) vs. transações meta (ERC-2771)

[Meta Transactions](https://www.alchemy.com/smart-wallets) e Account Abstraction são técnicas para melhorar a experiência do usuário no Ethereum. Meta Transactions exigem uma atualização do smart contract, motivo pelo qual estão sendo descontinuadas.

## Qual a diferença entre account abstraction e meta transactions?

Account Abstraction busca abstrair mais complexidades da Ethereum Account do que apenas as taxas de gas.

De uma perspectiva técnica, a diferença entre meta transactions e Account Abstraction está na estrutura da mensagem e em sua retrocompatibilidade.

## Saiba mais sobre account abstraction

<ExternalVideo
  url="https://youtu.be/Vpk_MhY-EeE?si=jb8KXjjgr51eiNta"
  provider="youtube"
  providerUid="Vpk_MhY-EeE"
/>

### O que são UserOps em account abstraction?

No caso das Meta Transactions, o padrão da indústria era usar mensagens baseadas em EIP712, o que exigia que todos os smart contracts fossem atualizados.

Account Abstraction padroniza um formato especial de transação chamado _UserOperations_.

UserOperation contém todas as informações necessárias para determinar qual transação o usuário pretende realizar, incluindo campos para decidir qual Paymaster usar, quanto o usuário está disposto a pagar \(em caso de autopatrocínio\), e a UserOperation assinada.

### O que são paymasters em account abstraction?

A parte de abstração de Gas do padrão ERC-4337 de Account Abstraction introduz os _Paymasters_.

Paymasters são **smart contracts onchain com lógica de validação arbitrária** que podem ser usados para definir um patrocínio de gas válido. Novamente, a diferença aqui é que *a execução é onchain*.

[DAOs](https://www.alchemy.com/dapps/top/daos), [apps](https://www.alchemy.com/dapps/top/defi-dapps), e outras equipes podem implantar seus próprios paymasters personalizados com recursos como pagamentos de gas em ERC-20 e mais.

Esses Paymasters personalizados podem usar o ERC-4337 para se integrar diretamente com Bundler Services existentes. Isso é diferente das Meta Transactions, que exigem adoção por parte do Provider.

<CardWithCta
  text="Patrocine transações com nossa Gas Manager API"
  ctaLabel="Comece agora"
  ctaHref="#"
  theme="gradient_blue"
/>

### Relayers vs. paymasters

Enquanto os Relayers no conceito de Meta Transaction são chaves privadas sob controle de provedores de infraestrutura, os Bundlers de Account Abstraction são nós padronizados. Trocar entre diferentes Bundlers é tão simples quanto alterar as API keys e as API URLs.

Não existe o conceito de MinimalForwarder em Account Abstraction, já que a validação do patrocínio é feita onchain, dentro do contrato Paymaster.

Em vez de ter apenas uma transação dentro de uma transação nativa, como no caso das Meta Transactions, os Bundlers agrupam múltiplas _UserOperations_ em um único bundle \(uma transação nativa\)!

<CardWithCta
  text="Envie userOps onchain com confiabilidade com nossa Bundler API"
  ctaLabel="Comece agora"
  ctaHref="#"
  theme="gradient_blue"
/>

## 5 benefícios de account abstraction em relação a meta transactions

### 1. Nenhuma alteração de smart contract é necessária

Enquanto as Meta Transactions exigem atualizações em todos os contratos existentes que as adotarem, Account Abstraction se baseia na infraestrutura já existente. Isso significa que todos os smart contracts, por padrão, oferecem suporte a Account Abstraction, o que a torna uma opção preferível em relação às Meta Transactions.

### 2. Troca sem atrito entre serviços de bundler e paymaster

No ERC-4337, todos os Bundlers e Paymasters se comunicam seguindo padrões específicos. As equipes podem até criar seus próprios Paymasters com lógica condicional para sua aplicação.

### 3. Não é necessário adotar relayers proprietários

Relayers proprietários carecem de consistência; cada Relayer pode ter seu próprio formato de mensagem para seu caso de uso. Isso leva à necessidade de alterações nos smart contracts para se tornarem compatíveis com cada Relayer diferente.

### 4. Mais descentralização

À medida que mais provedores disponibilizam seus serviços de Bundler, o desenvolvedor ganha a capacidade de descentralizar seu fluxo de transações. Isso também dá ao desenvolvedor a possibilidade de abandonar Bundlers de qualidade inferior.

### 5. Nenhum vínculo com ferramentas específicas de desenvolvedor

Ao usar Meta Transactions, também é necessário usar o SDK do provedor de infraestrutura. Isso gera um vínculo com ferramentas específicas, o que aumenta o atrito na hora de migrar de Relayers.

No caso de Account Abstraction, toda a funcionalidade padrão é suportada por todos os SDKs, permitindo escolher com base na própria experiência e trocar conforme a preferência!

Além disso, como o padrão UserOperation deve ser adotado por todos os fornecedores, também é viável construir ferramentas como UserOperation Explorers.

## Como migrar de meta transactions para account abstraction?

Se você já fez alterações em seus smart contracts para dar suporte a Meta Transactions, o processo de migração para reverter essas alterações é simples.

Diferentemente das Meta Transactions, msg.sender e msg.data podem ser usados diretamente com Account Abstraction.

Se forem desejados Paymasters ou Account Factories personalizados, o desenvolvimento deles se torna a próxima etapa da migração.

Para implementações padrão, recomendamos usar provedores de AA existentes e bem auditados, a fim de reduzir o tempo de desenvolvimento e evitar bugs autoinduzidos.

[O Gas Manager da Alchemy](https://www.alchemy.com/docs/reference/how-to-sponsor-gas-on-evm) oferece controles granulares como _limites de uso de gas por endereço_, _número máximo de UserOperations a patrocinar_, _lista de permissões de endereços, prazos de patrocínio e lista de permissões em nível de domínio_!

<ImageBlock
  src="https://media.alchemy.com/1703859980-alchemy-gas-manager-spending-rules.jpeg"
  alt="Painel do Alchemy Gas Manager: configurando regras de gastos para patrocínio de gas"
  width={2390}
  height={1028}
  caption="Interface de Regras de Gastos do Alchemy Gas Manager"
/>

<ImageBlock
  src="https://media.alchemy.com/1703860007-alchemy-gas-manager-ui.jpeg"
  alt="Configurações de política do Alchemy Gas Manager para limites de patrocínio e endereços na allowlist"
  width={2382}
  height={564}
  caption="Continuação da Interface do Gas Manager"
/>

[Gas Manager Admin API](https://www.alchemy.com/docs/wallets/api/gas-manager-admin-api/admin-api-endpoints/create-policy) permite criar, ler e atualizar as políticas de Gas de forma programática. Além disso, o desenvolvedor tem acesso a um ótimo painel visual de todas as UserOperations patrocinadas!

<ImageBlock
  src="https://media.alchemy.com/1703860035-alchemy-gas-manager-spending-dashboard.jpeg"
  alt="Painel de Gastos do Gas ManagerVisão de Operações do Gas Manager"
  width={2406}
  height={516}
  caption="Painel de Gastos do Gas ManagerVisão de Operações do Gas Manager"
/>

### **Conclusão**

Account Abstraction \(ERC-4337\) é a forma nova e melhor de incorporar transações sem gas em seus apps, com benefícios como evitar alterações de código em nível de contrato, troca de fornecedor sem atrito, composabilidade com infraestrutura existente, e maior descentralização.