---
title: "Abstracción de cuentas (ERC-4337) vs. transacciones meta (ERC-2771)"
description: "Conoce las razones por las que los desarrolladores están adoptando Account Abstraction en lugar de meta transactions"
---

# Abstracción de cuentas (ERC-4337) vs. transacciones meta (ERC-2771)

[Meta Transactions](https://www.alchemy.com/smart-wallets) y Account Abstraction son técnicas para mejorar la experiencia de usuario de Ethereum. Las Meta Transactions requieren una actualización del contrato inteligente, razón por la cual están siendo reemplazadas.

## ¿En qué se diferencia account abstraction de las meta transactions?

Account Abstraction busca abstraer más complejidades de la cuenta de Ethereum, no solo las tarifas de gas.

Desde una perspectiva técnica, la diferencia entre las meta transactions y Account Abstraction radica en la estructura del mensaje y su compatibilidad con versiones anteriores.

## Más información sobre account abstraction

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

### ¿Qué son los UserOps en account abstraction?

En el caso de las Meta Transactions, el estándar de la industria era usar mensajes basados en EIP712, lo cual requería actualizar todos los contratos inteligentes.

Account Abstraction estandariza un formato especial de transacción llamado _UserOperations_.

UserOperation contiene toda la información necesaria para determinar qué transacción quiere realizar el usuario, incluyendo campos para decidir qué Paymaster usar, cuánto está dispuesto a pagar el usuario (en caso de autopatrocinio) y la UserOperation firmada.

### ¿Qué son los paymasters en account abstraction?

La parte de gas abstraction del estándar ERC-4337 de Account Abstraction introduce los _Paymasters_.

Los Paymasters son **contratos inteligentes onchain con lógica de validación arbitraria** que pueden usarse para definir un patrocinio de gas válido. De nuevo, la diferencia aquí es que *la ejecución es onchain*.

Las [DAOs](https://www.alchemy.com/dapps/top/daos), las [apps](https://www.alchemy.com/dapps/top/defi-dapps) y otros equipos pueden desplegar sus propios paymasters personalizados con funciones como pagos de gas en ERC-20, entre otras.

Estos Paymasters personalizados pueden usar ERC-4337 para integrarse directamente con los Bundler Services existentes. Esto es distinto de las Meta Transactions, que requieren adopción por parte del proveedor.

<CardWithCta
  text="Patrocina transacciones con nuestra Gas Manager API"
  ctaLabel="Comenzar"
  ctaHref="#"
  theme="gradient_blue"
/>

### Relayers vs. paymasters

Mientras que los Relayers en el concepto de Meta Transaction son claves privadas bajo el control de proveedores de infraestructura, los Bundlers de Account Abstraction son nodos estandarizados. Cambiar entre distintos Bundlers es tan simple como cambiar las API keys y las URLs de la API.

No existe el concepto de MinimalForwarder en Account Abstraction, ya que la validación del patrocinio se hace onchain dentro del contrato Paymaster.

En lugar de tener una sola transacción dentro de una transacción nativa, como en el caso de Meta Transaction, ¡los Bundlers agrupan múltiples _UserOperations_ en un solo bundle (una transacción nativa)!

<CardWithCta
  text="Envía userOps onchain de forma confiable con nuestra Bundler API"
  ctaLabel="Comenzar"
  ctaHref="#"
  theme="gradient_blue"
/>

## 5 beneficios de account abstraction sobre las meta transactions

### 1. No se requieren cambios en los contratos inteligentes

Mientras que las Meta Transactions requieren actualizaciones en todos los contratos existentes que las adopten, Account Abstraction se construye sobre la infraestructura existente. Esto significa que todos los contratos inteligentes son compatibles con Account Abstraction por defecto, lo que la convierte en la opción preferida sobre las Meta Transactions.

### 2. Cambio sin fricción entre servicios de bundler y paymaster

Bajo ERC-4337, todos los Bundlers y Paymasters se comunican siguiendo estándares específicos. Los equipos incluso pueden crear sus propios Paymasters con lógica condicional para su aplicación.

### 3. No es necesario adoptar relayers propietarios

Los Relayers propietarios carecen de consistencia; cada Relayer puede tener su propio formato de mensaje para su caso de uso. Esto hace necesario modificar los contratos inteligentes para volverlos compatibles con cada Relayer distinto.

### 4. Mayor descentralización

A medida que más proveedores ofrecen sus servicios de Bundler, el desarrollador gana la capacidad de descentralizar su flujo de transacciones. Esto también le da al desarrollador la posibilidad de abandonar cualquier Bundler de bajo rendimiento.

### 5. Sin dependencia de herramientas de un proveedor específico

Al usar Meta Transactions también se necesita usar el SDK del proveedor de infraestructura. Esto genera una dependencia de herramientas que añade fricción al momento de migrar de Relayers.

En el caso de Account Abstraction, toda la funcionalidad estándar es compatible con todos los SDKs, lo que permite elegir según la experiencia propia y cambiar según preferencia.

Además, dado que el estándar UserOperation debe ser adoptado por todos los proveedores, también es factible construir herramientas como exploradores de UserOperation.

## ¿Cómo actualizar de meta transactions a account abstraction?

Si ya realizaste cambios en tus contratos inteligentes para dar soporte a Meta Transactions, el proceso de migración para revertir esos cambios es simple.

A diferencia de las Meta Transactions, msg.sender y msg.data pueden usarse tal cual con Account Abstraction.

Si se desean Paymasters o Account Factories personalizados, su desarrollo se convierte en el siguiente paso de la migración.

Para implementaciones estándar, recomendamos usar proveedores de AA existentes y bien auditados, con el fin de reducir el tiempo de desarrollo y los errores autoinducidos.

[Alchemy’s Gas Manager](https://www.alchemy.com/docs/reference/how-to-sponsor-gas-on-evm) ofrece controles granulares como _límites de uso de gas por dirección_, _número máximo de UserOperations a patrocinar_, _lista blanca de direcciones, plazos de patrocinio y lista blanca a nivel de dominio_!

<ImageBlock
  src="https://media.alchemy.com/1703859980-alchemy-gas-manager-spending-rules.jpeg"
  alt="Panel de Alchemy Gas Manager: configuración de reglas de gasto para patrocinio de gas"
  width={2390}
  height={1028}
  caption="Interfaz de reglas de gasto de Alchemy Gas Manager"
/>

<ImageBlock
  src="https://media.alchemy.com/1703860007-alchemy-gas-manager-ui.jpeg"
  alt="Configuración de políticas de Alchemy Gas Manager para límites de patrocinio y direcciones permitidas"
  width={2382}
  height={564}
  caption="Continuación de la interfaz de Gas Manager"
/>

[Gas Manager Admin API](https://www.alchemy.com/docs/wallets/api/gas-manager-admin-api/admin-api-endpoints/create-policy) permite crear, leer y actualizar las políticas de Gas de forma programática. Además de todo esto, el desarrollador obtiene un panel visual completo de cada UserOperation patrocinada.

<ImageBlock
  src="https://media.alchemy.com/1703860035-alchemy-gas-manager-spending-dashboard.jpeg"
  alt="Panel de gastos de Gas ManagerVista de operaciones de Gas Manager"
  width={2406}
  height={516}
  caption="Panel de gastos de Gas ManagerVista de operaciones de Gas Manager"
/>

### **Conclusión**

Account Abstraction (ERC-4337) es la forma nueva y mejor de incorporar transacciones sin gas en tus apps, con beneficios como evitar cambios de código a nivel de contrato, cambio de proveedor sin fricción, composabilidad con la infraestructura existente y mayor descentralización.