Actualización Pectra de Ethereum explicada: Lo que la Account Abstraction cambia realmente para desarrolladores y usuarios

Pectra — abreviatura de Prague/Electra — aterrizó en la mainnet de Ethereum a principios de 2025, combinando cambios en la capa de ejecución (Prague) con mejoras en la capa de consenso (Electra). Es la actualización con más impacto para desarrolladores desde The Merge, y su pieza central es EIP-7702, que introduce una forma práctica e incremental de Account Abstraction para externally owned accounts (EOAs) sin obligar a los usuarios a migrar a nuevos Smart Contract wallets.

Las tres EIPs que definen Pectra

Pectra agrupa decenas de EIPs, pero tres son las que impulsan la mayoría del impacto real:

EIP-7702 — Set Code para EOAs: Permite que cualquier EOA adopte temporalmente código de Smart Contract durante la duración de una transacción. Este es el desbloqueo de Account Abstraction que más importa a los desarrolladores.
EIP-7251 — Aumento del saldo efectivo máximo de validadores: Eleva el saldo efectivo máximo de los validadores de 32 ETH a 2.048 ETH. Las grandes operaciones de staking pueden ahora consolidar validadores en lugar de levantar cientos de nodos de 32 ETH, reduciendo drásticamente la sobrecarga de p2p y la complejidad operativa.
EIP-7549 — Mover el índice del comité fuera de la atestación: Una mejora de eficiencia en la capa de consenso que reduce el número de hashes necesarios para procesar atestaciones, soportando mayor throughput y sentando las bases para el futuro escalado de blobs mediante el aumento del recuento de blobs de Pectra (de 3/6 a 6/9 target/max por bloque).

Qué significa realmente la Account Abstraction

El término "Account Abstraction" ha circulado en el discurso de Ethereum desde al menos 2016. En términos simples, significa dotar a los wallets de usuario normales (EOAs) de las capacidades programables que siempre han tenido los Smart Contracts. Antes de Pectra, las EOAs eran rígidas: solo podían firmar transacciones con su clave privada, siempre pagaban gas en ETH y cada acción requería una transacción firmada separada del propietario del wallet.

EIP-7702 rompe esa rigidez al permitir que una EOA delegue su ejecución en un fragmento de código de Smart Contract — un code pointer — que vive en la cadena. La delegación se establece mediante un nuevo tipo de transacción (SET_CODE_TX_TYPE = 0x04) y se mantiene hasta que se revoca. Esto habilita cuatro capacidades que antes eran imposibles o requerían soluciones engorrosas:

Pago de gas en cualquier token: Un contrato paymaster puede cubrir los costes de gas en ETH en nombre del usuario, permitiendo que las aplicaciones patrocinen el gas o acepten USDC para las comisiones. Los usuarios ya no necesitan ETH para interactuar con aplicaciones de ETH.
Transacciones por lotes: Múltiples operaciones — approve + swap, approve + deposit + stake — se agrupan en una única transacción atómica. Una firma, una confirmación, un bloque.
Session keys: Una DApp puede recibir una clave con ámbito y duración limitada que autoriza acciones específicas (p. ej., "gastar hasta 50 USDC en este juego durante las próximas 24 horas") sin exponer la clave privada raíz.
Social recovery: El código delegado puede implementar lógica de recuperación multifirma, permitiendo que contactos de confianza restauren el acceso al wallet si se pierde la clave privada.

Antes y después: una comparación concreta

Intercambio en un DEX

Antes de Pectra: El usuario abre MetaMask, aprueba el token (transacción 1, gas en ETH, ~15 segundos), espera la confirmación, luego ejecuta el swap (transacción 2, más gas en ETH, otros ~15 segundos). Dos confirmaciones separadas, dos pagos de gas, dos posibles puntos de fallo.

Después de Pectra: El usuario hace clic en "Swap". El wallet delega en un contrato de batching, envía una transacción que atómicamente aprueba e intercambia, y el paymaster de la DApp cubre el gas en USDC si el usuario no tiene ETH. Un clic, una confirmación.

Incorporación de un nuevo usuario

Antes de Pectra: El nuevo usuario compra ETH en un exchange, lo retira a su wallet, espera a que llegue el ETH y luego puede interactuar con DApps. El requisito de gas era una barrera de entrada que mataba las tasas de conversión.

Después de Pectra: La DApp patrocina las primeras transacciones mediante un paymaster. El usuario puede incorporarse solo con una stablecoin o incluso una primera transacción sin gas. El wallet genera una EOA estándar — sin migración a Smart Contract wallet, sin complejidad adicional de seed phrase más allá de lo habitual.

Implicaciones para los protocolos DeFi

Los protocolos DeFi obtienen una mejora sustancial de UX sin necesidad de reescribir contratos. Los protocolos que implementen frontends conscientes de EIP-7702 pueden:

Ofrecer flujos "zap" de un solo clic que agrupen múltiples operaciones DeFi (p. ej., ETH a liquid staking token y luego depósito en un vault de rendimiento) sin flujos de aprobación de varios pasos.
Implementar patrocinio de gas para usuarios que califiquen (p. ej., usuarios con más de $1.000 en TVL del protocolo obtienen transacciones sin gas).
Usar session keys para bots de órdenes limitadas y estrategias automatizadas: los usuarios autorizan a un contrato específico a actuar en su nombre dentro de parámetros definidos, sin una entrega custodial.

El punto crítico para los desarrolladores de protocolos: no necesitan redesplegar sus contratos. EIP-7702 opera a nivel de cuenta. Sus contratos Solidity existentes reciben llamadas de lo que parece una EOA comportándose como un Smart Contract — la interfaz no cambia.

Qué necesitan cambiar los desarrolladores

Para los desarrolladores de wallets, EIP-7702 introduce un nuevo tipo de transacción que debe ser soportado en los flujos de firma. El campo authorization_list en las transacciones tipo 0x04 contiene tuplas firmadas de (chain_id, address, nonce) que establecen la delegación de código. Los wallets deben mostrar esto claramente a los usuarios — una delegación a un contrato malicioso es funcionalmente equivalente a darle control total de la EOA durante esa transacción.

Para los desarrolladores de DApps, la nueva primitiva principal es la interfaz de paymaster (estandarizada en ERC-4337 y ahora usable con EOAs mediante 7702). Integrar un paymaster requiere seleccionar un proveedor de bundler (Pimlico, Alchemy, Biconomy y Stackup lo soportan), implementar la lógica validatePaymasterUserOp y actualizar el frontend para construir el nuevo tipo de transacción en lugar de una transacción EOA simple.

Las implementaciones de session keys suelen seguir un patrón donde: (1) el usuario firma una delegación a un contrato de session key, (2) el backend de la DApp almacena la clave y los parámetros con ámbito, (3) las acciones posteriores se envían como transacciones firmadas por la session key en lugar de la EOA raíz. Librerías como permissionless.js y el módulo de Account Abstraction de Viem ya han lanzado soporte para EIP-7702.

Las brechas restantes

EIP-7702 es una mejora incremental, no la visión completa de Account Abstraction. Quedan varias limitaciones:

La delegación es por cuenta, no global: Cada EOA debe optar individualmente por una delegación de código. No hay una actualización de wallet a nivel de red; la adopción depende de que los wallets implementen soporte y los usuarios realicen al menos una transacción para establecer la delegación.
El código se reinicia con transacciones EOA simples: Si la EOA envía una transacción simple (no delegada), el puntero de código puede limpiarse. Los wallets deben manejar esto con cuidado para evitar estados confusos para los usuarios que mezclan tipos de transacción antiguos y nuevos.
No hay sesiones nativas entre cadenas: Las session keys y delegaciones son específicas de cada cadena. Una delegación en la mainnet de Ethereum no se propaga a Arbitrum o Base. La Account Abstraction entre cadenas sigue siendo un problema abierto.
La EOA no es un Smart Contract wallet completo: Las EOAs con delegación EIP-7702 no pueden recibir ETH mediante selfdestruct, no pueden ser el destino de despliegues CREATE2 de la misma manera y tienen supuestos de seguridad sutilmente diferentes a los de un Smart Contract wallet nativo como Safe.

La hoja de ruta de Ethereum aborda estas brechas en futuras actualizaciones. EIP-7701 (Account Abstraction nativa mediante un nuevo tipo de transacción) y la maduración continua de la infraestructura ERC-4337 son los siguientes pasos. Pectra se entiende mejor como la forma de hacer práctica la Account Abstraction para la base de usuarios actual — más de 500 millones de EOAs — sin forzar la migración.

Conclusiones clave para desarrolladores

Si construyes wallets: implementa soporte para el tipo de transacción EIP-7702, muestra claramente los objetivos de delegación e integra paymaster con al menos un proveedor de bundler.
Si construyes DApps: puedes añadir patrocinio de gas y batching de transacciones sin redesplegar contratos. El ROI de reducir los pasos de aprobación se mide en tasas de conversión.
Si gestionas una operación de staking: EIP-7251 te permite consolidar 64 validadores de 32 ETH en un único validador de 2.048 ETH, reduciendo la sobrecarga de p2p y operativa en aproximadamente un 98%.
Si construyes entre cadenas: no asumas que las delegaciones de EOA se transfieren entre cadenas. Diseña tu arquitectura de session keys para manejar autorizaciones por cadena de forma explícita.

Pectra no reinventa Ethereum — elimina la fricción que ha hecho que Ethereum sea difícil de usar durante una década. El doble paso de aprobación de tokens, el requisito de ETH para gas, la imposibilidad de automatizar acciones del wallet de forma segura: no eran limitaciones fundamentales de las blockchains, eran limitaciones del modelo EOA. EIP-7702 cierra la mayoría de ellas. Lo que queda es un problema de ejecución para los equipos de wallets y los desarrolladores de DApps, no una brecha de protocolo.