3 publicaciones etiquetados con "EIP-7702"

El 7 de mayo de 2025, la actualización Pectra de Ethereum (Prague + Electra) llegó a mainnet. Entre sus cambios más visibles para desarrolladores está EIP-7702, que permite a una cuenta de propiedad externa (EOA) "montar" lógica de smart-contract—sin migrar fondos o cambiar direcciones. Si construyes wallets, dapps, o relayers, esto desbloquea un camino más simple hacia la UX de smart-account.

A continuación hay una guía concisa, orientada a implementación: lo que realmente se lanzó, cómo funciona 7702, cuándo elegirlo sobre ERC-4337 puro, y un andamio de copiar y pegar que puedes adaptar hoy.

Lo Que Realmente Se Lanzó​

• EIP-7702 está en el alcance final de Pectra. El meta-EIP para el hard fork Pectra oficialmente lista 7702 entre los cambios incluidos.
• Detalles de activación: Pectra se activó en mainnet en la época 364032 el 7 de mayo de 2025, siguiendo activaciones exitosas en todas las testnets principales.
• Nota de toolchain: Solidity v0.8.30 actualizó su objetivo EVM predeterminado a prague para compatibilidad con Pectra. Necesitarás actualizar tus compiladores y pipelines CI, especialmente si fijas versiones específicas.

EIP-7702—Cómo Funciona (Tuercas y Tornillos)​

EIP-7702 introduce un nuevo tipo de transacción y un mecanismo para que una EOA delegue su lógica de ejecución a un smart contract.

• Nuevo Tipo de Transacción (0x04): Una transacción Tipo-4 incluye un nuevo campo llamado authorization_list. Esta lista contiene una o más tuplas de autorización—(chain_id, address, nonce, y_parity, r, s)—cada una firmada por la clave privada de la EOA. Cuando se procesa esta transacción, el protocolo escribe un indicador de delegación al campo de código de la EOA: 0xef0100 || address. A partir de ese momento, cualquier llamada a la EOA se redirige a la address especificada (la implementación), pero ejecutan dentro del contexto de almacenamiento y balance de la EOA. Esta delegación permanece activa hasta que se cambie explícitamente.
• Alcance de Chain: Una autorización puede ser específica de chain proporcionando un chain_id, o puede aplicar a todas las chains si chain_id se establece en 0. Esto permite desplegar el mismo contrato de implementación en múltiples redes sin requerir que los usuarios firmen una nueva autorización para cada una.
• Revocación: Para revertir una EOA de vuelta a su comportamiento original no programable, simplemente envías otra transacción 7702 donde la address de implementación se establece a la dirección cero. Esto limpia el indicador de delegación.
• Auto-Patrocinado vs. Relayed: Una EOA puede enviar la transacción Tipo-4 ella misma, o un relayer de terceros puede enviarla en nombre de la EOA. Esto último es común para crear una experiencia de usuario sin gas. El manejo de nonce difiere ligeramente dependiendo del método, así que es importante usar bibliotecas que manejen correctamente esta distinción.

Cambio de Modelo de Seguridad: Debido a que la clave privada EOA original aún existe, siempre puede anular cualquier regla de smart contract (como recuperación social o límites de gasto) enviando una nueva transacción 7702 para cambiar la delegación. Este es un cambio fundamental. Los contratos que dependen de tx.origin para verificar que una llamada es de una EOA deben ser re-auditados, ya que 7702 puede romper estas suposiciones. Audita tus flujos en consecuencia.

¿7702 o ERC-4337? (Y Cuándo Combinar)​

Tanto EIP-7702 como ERC-4337 habilitan la abstracción de cuenta, pero sirven necesidades diferentes.

• Elige EIP-7702 cuando…
  • Quieres proporcionar UX de smart-account instantánea para EOAs existentes sin forzar a los usuarios a migrar fondos o cambiar direcciones.
  • Necesitas direcciones consistentes entre chains que puedan actualizarse progresivamente con nuevas características.
  • Quieres escalonar tu transición a la abstracción de cuenta, comenzando con características simples y agregando complejidad con el tiempo.
• Elige ERC-4337 puro cuando…
  • Tu producto requiere programabilidad completa y motores de política complejos (ej. multi-sig, recuperación avanzada) desde el día uno.
  • Estás construyendo para nuevos usuarios que no tienen EOAs existentes, haciendo nuevas direcciones de smart-account y la configuración asociada aceptables.
• Combínalos: El patrón más poderoso es usar ambos. Una EOA puede usar una transacción 7702 para designar una implementación de wallet ERC-4337 como su lógica. Esto hace que la EOA se comporte como una cuenta 4337, permitiéndole ser empaquetada, patrocinada por paymasters, y procesada por la infraestructura 4337 existente—todo sin que el usuario necesite una nueva dirección. Este es un camino hacia adelante compatible explícitamente alentado por los autores del EIP.

Andamio 7702 Mínimo Que Puedes Adaptar​

Aquí hay un ejemplo práctico de un contrato de implementación y el código del lado cliente para activarlo.

1. Un Contrato de Implementación Pequeño y Auditable​

Este código de contrato se ejecutará en el contexto de la EOA una vez designado. Manténlo pequeño, auditable, y considera agregar un mecanismo de actualización.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice Ejecuta llamadas desde el contexto EOA cuando se designa via EIP-7702.
contract DelegatedAccount {
    // Slot de almacenamiento único para evitar colisiones con otros contratos.
    bytes32 private constant INIT_SLOT =
        0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

    event Initialized(address indexed account);
    event Executed(address indexed to, uint256 value, bytes data, bytes result);

    modifier onlyEOA() {
        // Opcional: agregar verificaciones para restringir quién puede llamar ciertas funciones.
        _;
    }

    function initialize() external payable onlyEOA {
        // Establecer una bandera de inicialización única en el almacenamiento de la EOA.
        bytes32 slot = INIT_SLOT;
        assembly {
            if iszero(iszero(sload(slot))) { revert(0, 0) } // Revertir si ya está inicializado
            sstore(slot, 1)
        }
        emit Initialized(address(this));
    }

    function execute(address to, uint256 value, bytes calldata data)
        external
        payable
        onlyEOA
        returns (bytes memory result)
    {
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "CALL_FAILED");
        emit Executed(to, value, data, ret);
        return ret;
    }

    function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
        external
        payable
        onlyEOA
    {
        uint256 n = to.length;
        require(n == value.length && n == data.length, "LENGTH_MISMATCH");
        for (uint256 i = 0; i < n; i++) {
            (bool ok, ) = to[i].call{value: value[i]}(data[i]);
            require(ok, "CALL_FAILED");
        }
    }
}

2. Designar el Contrato en una EOA (tx Tipo-4) con viem​

Clientes modernos como viem tienen helpers incorporados para firmar autorizaciones y enviar transacciones Tipo-4. En este ejemplo, una cuenta relayer paga el gas para actualizar una eoa.

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. Definir el relayer (patrocina gas) y la EOA a ser actualizada
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
  account: relayer,
  chain: sepolia,
  transport: http(),
});

// 2. La EOA firma la autorización apuntando al contrato de implementación
const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress: implementationAddress,
  // Si la EOA misma fuera a enviar esto, agregarías: executor: 'self'
});

// 3. El relayer envía una transacción Tipo-4 para establecer el código de la EOA y llamar initialize()
const hash = await client.sendTransaction({
  to: eoa.address, // El destino es la EOA misma
  authorizationList: [authorization], // El nuevo campo EIP-7702
  data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. Ahora, la EOA puede ser controlada via su nueva lógica sin más autorizaciones
// Por ejemplo, para ejecutar una transacción:
// await client.sendTransaction({
//   to: eoa.address,
//   data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. Revocar Delegación (De Vuelta a EOA Simple)​

Para deshacer la actualización, haz que la EOA firme una autorización que designe la dirección cero como la implementación y envía otra transacción Tipo-4. Después, una llamada a eth_getCode(eoa.address) debería retornar bytes vacíos.

Patrones de Integración Que Funcionan en Producción​

• Actualizar en Sitio para Usuarios Existentes: En tu dapp, detecta si el usuario está en una red compatible con Pectra. Si es así, muestra un botón opcional "Actualizar Cuenta" que activa la firma de autorización única. Mantén caminos de respaldo (ej. approve + swap clásico) para usuarios con wallets más antiguas.
• Onboarding Sin Gas: Usa un relayer (ya sea tu backend o un servicio) para patrocinar la transacción Tipo-4 inicial. Para transacciones sin gas continuas, enruta operaciones de usuario a través de un bundler ERC-4337 para aprovechar paymasters existentes y mempools públicas.
• Despliegues Cross-Chain: Usa una autorización chain_id = 0 para designar el mismo contrato de implementación en todas las chains. Luego puedes habilitar o deshabilitar características por chain dentro de tu lógica de aplicación.
• Observabilidad: Tu backend debería indexar transacciones Tipo-4 y parsear el authorization_list para rastrear qué EOAs han sido actualizadas. Después de una transacción, verifica el cambio llamando eth_getCode y confirmando que el código de la EOA ahora coincide con el indicador de delegación (0xef0100 || implementationAddress).

Modelo de Amenaza y Gotchas (No Te Saltes Esto)​

• La Delegación es Persistente: Trata los cambios al contrato de implementación de una EOA con la misma gravedad que una actualización estándar de smart contract. Esto requiere auditorías, comunicación clara al usuario, e idealmente, un flujo opt-in. Nunca empujes nueva lógica a los usuarios silenciosamente.
• Minas Terrestres de tx.origin: Cualquier lógica que usó msg.sender == tx.origin para asegurar que una llamada vino directamente de una EOA ahora es potencialmente vulnerable. Este patrón debe ser reemplazado con verificaciones más robustas, como firmas EIP-712 o listas de permitidos explícitas.
• Matemáticas de Nonce: Cuando una EOA patrocina su propia transacción 7702 (executor: 'self'), su nonce de autorización y nonce de transacción interactúan de manera específica. Siempre usa una biblioteca que maneje esto correctamente para evitar problemas de replay.
• Responsabilidad de UX de Wallet: La especificación EIP-7702 advierte que las dapps no deberían pedir a los usuarios que firmen designaciones arbitrarias. Es responsabilidad del wallet verificar las implementaciones propuestas y asegurar que son seguras. Diseña tu UX para alinearse con este principio de seguridad mediada por wallet.

Cuándo 7702 es una Victoria Clara​

• Flujos DEX: Un approve multi-paso y swap puede combinarse en un solo clic usando la función executeBatch.
• Juegos y Sesiones: Otorga privilegios similares a session-key por tiempo limitado o alcance sin requerir que el usuario cree y financie una nueva wallet.
• Empresa y Fintech: Habilita transacciones patrocinadas y aplica políticas de gasto personalizadas mientras mantienes la misma dirección corporativa en cada chain para contabilidad e identidad.
• Puentes L2 e Intents: Crea flujos de meta-transacción más suaves con una identidad EOA consistente en diferentes redes.

Estos casos de uso representan los mismos beneficios centrales prometidos por ERC-4337, pero ahora están disponibles para cada EOA existente con solo una autorización única.

Lista de Verificación de Envío​

Protocolo​

• Asegurar que nodos, SDKs, y proveedores de infraestructura soporten transacciones Tipo-4 y EVM "prague" de Pectra.
• Actualizar indexadores y herramientas de analítica para parsear el campo authorization_list en nuevas transacciones.

Contratos​

• Desarrollar un contrato de implementación mínimo y auditado con características esenciales (ej. batching, revocación).
• Probar a fondo los flujos de revocar y re-designar en testnets antes de desplegar a mainnet.

Clientes​

• Actualizar bibliotecas del lado cliente (viem, ethers, etc.) y probar las funciones signAuthorization y sendTransaction.
• Verificar que tanto los caminos de transacción auto-patrocinados como relayed manejen nonces y replays correctamente.

Seguridad​

• Remover todas las suposiciones basadas en tx.origin de tus contratos y reemplazarlas con alternativas más seguras.
• Implementar monitoreo post-despliegue para detectar cambios de código inesperados en direcciones de usuario y alertar sobre actividad sospechosa.

Línea de fondo: EIP-7702 proporciona una rampa de baja fricción hacia la UX de smart-account para los millones de EOAs ya en uso. Comienza con una implementación pequeña y auditada, usa un camino relayed para configuración sin gas, haz la revocación clara y fácil, y puedes entregar el 90% de los beneficios de la abstracción de cuenta completa—sin el dolor de la rotación de direcciones y migración de activos.

Durante años, el mundo cripto ha estado limitado por un problema crítico de usabilidad: la cartera. Las carteras tradicionales, conocidas como Cuentas Externamente Poseídas (EOA), son implacables. Una sola frase semilla perdida significa que tus fondos se van para siempre. Cada acción requiere una firma y las tarifas de gas deben pagarse con el token nativo de la cadena. Esta experiencia torpe y de alto riesgo es una barrera importante para la adopción masiva.

Entra Abstracción de Cuentas (AA), un cambio de paradigma que redefinirá cómo interactuamos con la cadena de bloques. En esencia, AA transforma la cuenta del usuario en un contrato inteligente programable, desbloqueando funciones como recuperación social, transacciones con un clic y pagos de gas flexibles.

El camino hacia este futuro más inteligente se está desarrollando a lo largo de tres rutas distintas: el probado ERC-4337, el eficiente Native AA y el muy esperado EIP-7702. Analicemos qué significa cada enfoque para desarrolladores y usuarios.

💡 Ruta 1: El Pionero — ERC-4337​

ERC-4337 fue el avance que llevó la abstracción de cuentas a Ethereum y a las cadenas EVM sin modificar el protocolo central. Piensa en ello como una capa inteligente añadida sobre el sistema existente.

Introduce un nuevo flujo de transacciones que involucra:

• UserOperations: Un nuevo objeto que representa la intención del usuario (p. ej., “intercambiar 100 USDC por ETH”).
• Bundlers: Actores fuera de la cadena que recogen UserOperations, los agrupan y los envían a la red.
• EntryPoint: Un contrato inteligente global que valida y ejecuta las operaciones agrupadas.

Lo Bueno:

• Compatibilidad Universal: Puede desplegarse en cualquier cadena EVM.
• Flexibilidad: Permite funciones avanzadas como claves de sesión para juegos, seguridad multfirmas y patrocinio de gas mediante Paymasters.

El Compromiso:

• Complejidad y Coste: Introduce una sobrecarga de infraestructura significativa (ejecución de Bundlers) y tiene los costos de gas más altos de los tres enfoques, ya que cada operación pasa por la lógica adicional de EntryPoint. Por eso, su adopción se ha concentrado principalmente en L2s de bajo costo como Base y Polygon.

ERC-4337 abrió el camino para que otras soluciones AA pudieran funcionar. Demostró la demanda y sentó las bases para una experiencia Web3 más intuitiva.

🚀 Ruta 2: El Ideal Integrado — Native Account Abstraction​

Si ERC-4337 es un complemento, Native AA construye funciones inteligentes directamente en la base de la cadena. Cadenas como zkSync Era y Starknet fueron diseñadas desde cero con AA como principio central. En estas redes, cada cuenta es un contrato inteligente.

Lo Bueno:

• Eficiencia: Al integrar la lógica AA en el protocolo, se eliminan capas extra, lo que genera costos de gas significativamente menores en comparación con ERC-4337.
• Simplicidad para los Desarrolladores: No es necesario gestionar Bundlers ni un mempool separado. El flujo de transacciones se asemeja mucho al de una operación estándar.

El Compromiso:

• Fragmentación del Ecosistema: Native AA es específico de cada cadena. Una cuenta en zkSync es distinta de una cuenta en Starknet, y ninguna es nativa de Ethereum mainnet. Esto crea una experiencia fragmentada para usuarios y desarrolladores que operan en múltiples cadenas.

Native AA nos muestra el “juego final” en términos de eficiencia, pero su adopción está ligada al crecimiento de los ecosistemas que la alojan.

🌉 Ruta 3: El Puente Pragmático — EIP-7702​

Programado para incluirse en la actualización “Pectra” de Ethereum en 2025, EIP-7702 es un cambio de juego diseñado para llevar funciones AA a la masa de usuarios de EOAs existentes. Adopta un enfoque híbrido: permite que una EOA delegue temporalmente su autoridad a un contrato inteligente para una única transacción.

Piensa en ello como otorgar superpoderes temporales a tu EOA. No necesitas migrar fondos ni cambiar tu dirección. Tu cartera simplemente añade una autorización a la transacción, permitiendo ejecutar operaciones agrupadas (p. ej., aprobar + intercambiar con un clic) o recibir patrocinio de gas.

Lo Bueno:

• Compatibilidad Retroactiva: Funciona con los miles de millones de dólares asegurados por EOAs actuales. No se requiere migración.
• Baja Complejidad: Utiliza el pool de transacciones estándar, eliminando la necesidad de Bundlers y simplificando drásticamente la infraestructura.
• Catalizador de Adopción Masiva: Al hacer que funciones inteligentes estén al alcance de cualquier usuario de Ethereum de la noche a la mañana, podría acelerar rápidamente la adopción de mejores patrones de UX.

El Compromiso:

• No es “AA Completa”: EIP-7702 no resuelve la gestión de claves de la propia EOA. Si pierdes tu clave privada, sigues sin suerte. Se trata más de mejorar las capacidades de transacción que de rehacer la seguridad de la cuenta.

Comparación Directa: Un Análisis Claro​

El Futuro es Convergente y Centrado en el Usuario​

Estas tres rutas no son mutuamente excluyentes; están convergiendo hacia un futuro donde la cartera deja de ser un punto de fricción.

1. La Recuperación Social se Vuelve Estándar 🛡️: La era de “claves perdidas, fondos perdidos” está terminando. AA permite la recuperación basada en guardianes, haciendo que la auto‑custodia sea tan segura y indulgente como una cuenta bancaria tradicional.
2. UX de Juegos Rediseñada 🎮: Las claves de sesión permitirán una jugabilidad fluida sin constantes ventanas de “aprobar transacción”, logrando que los juegos Web3 se sientan como los juegos Web2.
3. Carteras como Plataformas Programables: Las carteras se volverán modulares. Los usuarios podrán añadir un “módulo DeFi” para farming automatizado o un “módulo de seguridad” que requiera 2FA para transferencias grandes.

Para desarrolladores y proveedores de infraestructura como Blockeden.xyz, esta evolución es increíblemente emocionante. La complejidad de Bundlers, Paymasters y los distintos estándares AA crea una gran oportunidad para ofrecer infraestructura robusta, fiable y abstracta. El objetivo es una experiencia unificada donde el desarrollador pueda integrar fácilmente funciones AA, y la cartera utilice inteligentemente ERC-4337, Native AA o EIP-7702 bajo el capó, según lo que soporte la cadena.

La cartera finalmente recibe la actualización que merece. La transición de EOAs estáticas a cuentas inteligentes dinámicas no es solo una mejora—es la revolución que hará que Web3 sea accesible y segura para el próximo billón de usuarios.

Retiros, ajustes de gas, y lo que vino después—sin la propaganda.

La Versión Corta​

La actualización Shapella, un acrónimo de Shanghai (para la capa de ejecución) y Capella (para la capa de consenso), se activó en Ethereum el 12 de abril de 2023. Su característica principal fue habilitar los retiros de staking por primera vez desde el lanzamiento de la Beacon Chain.

El cambio más destacado, EIP-4895, introdujo un sistema donde los retiros de validadores se "empujan" automáticamente desde la capa de consenso a la capa de ejecución, sin requerir transacciones de usuario ni tarifas de gas. Junto a esto, se implementaron cuatro EIPs menores para ajustar la EVM, incluyendo reducciones en el costo del gas (Warm COINBASE), optimizaciones de bytecode (PUSH0), y límites en la creación de contratos (Initcode metering). La actualización también sirvió como advertencia final a los desarrolladores de que el opcode SELFDESTRUCT estaba siendo descontinuado.

Shapella cerró efectivamente el ciclo del Merge, y la siguiente actualización mayor, Dencun, llegó el 13 de marzo de 2024, cambiando el foco de la red hacia la escalabilidad con los "blobs" de EIP-4844.

Por Qué Shapella Fue un Hito Crítico​

Desde el inicio de la Beacon Chain hasta abril de 2023, hacer staking con ETH era una calle de un solo sentido. Podías depositar 32 ETH para ayudar a asegurar la red y ganar recompensas, pero no podías retirar tu capital principal o esas recompensas de la capa de consenso. Esta liquidez bloqueada representaba un compromiso significativo y una barrera para muchos stakers potenciales.

Shapella cambió todo al abrir la puerta de salida.

El núcleo de la actualización fue EIP-4895, que diseñó ingeniosamente una "operación de retiro" a nivel de sistema. En lugar de requerir que los stakers elaboren una transacción y paguen gas para retirar, el protocolo mismo ahora automáticamente recoge fondos elegibles de la capa de consenso y los empuja a la capa de ejecución. Este diseño limpio, basado en empuje, minimizó la complejidad y el riesgo, haciendo mucho más fácil probar e implementar el cambio de manera segura.

Lo Que Realmente Cambió: Los EIPs en Español Simple​

Shapella fue un paquete de cinco Propuestas de Mejora de Ethereum (EIPs) clave:

• EIP-4895 — Retiros de Beacon Chain (Basados en Empuje) Este fue el evento principal. Habilitó tanto retiros parciales (recompensas) como completos (principal + recompensas) para fluir desde la capa de consenso a la dirección de retiro especificada del staker. La innovación clave es que estas no son transacciones iniciadas por usuario; son operaciones automáticas embebidas en bloques propuestos.

• EIP-3651 — "Warm COINBASE" Este EIP hizo una optimización de gas pequeña pero importante. En la EVM, COINBASE se refiere a la dirección del productor del bloque (el validador), no el exchange. Antes de Shapella, la primera vez que un contrato inteligente accedía a esta dirección dentro de una transacción, incurría en un costo de gas más alto. EIP-3651 hizo que la dirección COINBASE fuera "warm" por defecto, reduciendo el costo de gas para protocolos que interactúan frecuentemente con ella, como aquellos que pagan propinas MEV directamente al constructor de bloques.

• EIP-3855 — Opcode PUSH0 Una adición simple pero elegante a la EVM. Este nuevo opcode, PUSH0, hace exactamente lo que dice: empuja el valor cero al stack. Anteriormente, los desarrolladores tenían que usar opcodes más pesados y costosos para lograr esto. PUSH0 hace el bytecode ligeramente más pequeño y eficiente en gas, especialmente para los numerosos contratos que inicializan variables en cero.

• EIP-3860 — Limitar y Medir initcode Este cambio introdujo dos reglas para el código usado para crear un contrato inteligente (initcode). Primero, estableció un límite máximo en el tamaño del initcode de 49,152 bytes. Segundo, agregó una pequeña tarifa de gas por cada chunk de 32 bytes de este código. Esto previene ataques de denegación de servicio que involucran contratos excesivamente grandes y hace los costos de creación de contratos más predecibles.

• EIP-6049 — Deprecar SELFDESTRUCT (Advertencia) Esto no fue un cambio de código sino una advertencia formal a la comunidad de desarrolladores. Señaló que el opcode SELFDESTRUCT, que permite a un contrato eliminarse a sí mismo y enviar su ETH a una dirección objetivo, tendría su funcionalidad drásticamente cambiada en una actualización futura. Esto dio tiempo a los desarrolladores para eliminar gradualmente su dependencia de él antes de que la actualización Dencun alterara posteriormente su comportamiento con EIP-6780.

Retiros 101: Parciales vs. Completos​

Shapella introdujo dos tipos de retiros automáticos, cada uno con sus propias reglas.

• Retiros Parciales Estos son barridos automáticos de recompensas. Si el balance de un validador crece por encima de 32 ETH debido a recompensas de la capa de consenso, el protocolo automáticamente "descremó" la cantidad excedente y la envía a la dirección de retiro designada. El validador permanece activo y continúa sus deberes. Esto sucede sin acción requerida del staker.

• Retiros Completos (Salida) Esto es para stakers que quieren dejar de validar y recuperar todo su balance. El staker debe primero transmitir un mensaje de salida voluntaria. Después de un período de espera, el validador se vuelve elegible para un retiro completo. Una vez procesado en el barrido, todo el balance se envía a la dirección de retiro, y el validador ya no es parte del conjunto activo.

Rendimiento y Cadencia​

La red está diseñada para procesar retiros suavemente sin causar inestabilidad.

• Hasta 16 retiros pueden incluirse en cada bloque (cada 12 segundos), permitiendo un máximo de aproximadamente 115,200 retiros por día.
• El proponente del bloque escanea la lista de validadores activos e incluye los primeros 16 retiros elegibles. El siguiente proponente de bloque continúa donde el último se quedó, asegurando que cada validador obtenga su turno en la cola.
• Para prevenir un éxodo masivo de desestabilizar la red, el número de validadores que pueden salir por época (cada ~6.4 minutos) está limitado por un límite de rotación. Este límite es dinámico basado en el número total de validadores activos, suavizando las olas de salida.

También es importante notar que las recompensas de la capa de consenso son manejadas por este mecanismo de retiro EIP-4895, mientras que las recompensas de la capa de ejecución (tarifas prioritarias y MEV) se envían directamente a la dirección de destinatario de tarifas configurada del validador y están disponibles inmediatamente.

Lo Que Vino Después: Dencun y el Camino a la Escalabilidad​

Shapella marcó la exitosa finalización de la "era del Merge." Con staking ahora siendo un proceso completamente líquido y bidireccional, los desarrolladores dirigieron su atención al siguiente gran desafío de Ethereum: escalabilidad.

La siguiente actualización mayor, Dencun (Deneb + Cancun), llegó el 13 de marzo de 2024. Su pieza central fue EIP-4844, que introdujo "blobs"—una nueva forma más barata para rollups de Capa 2 de publicar datos de transacciones a la mainnet de Ethereum. Esto redujo dramáticamente las tarifas de transacciones en L2s y fue un paso masivo hacia adelante en la hoja de ruta centrada en rollups. Dencun también cumplió la promesa de EIP-6049 al implementar EIP-6780, que redujo significativamente el poder del opcode SELFDESTRUCT.

El Panorama General​

Shapella fue el hito de confianza esencial para el consenso Proof-of-Stake de Ethereum. Al habilitar retiros, des-arriesgó el staking, restauró la liquidez, y afirmó la capacidad de la red para ejecutar actualizaciones complejas y coordinadas. También entregó un puñado de mejoras pragmáticas de EVM que limpiaron deuda técnica y pavimentaron el camino para optimizaciones futuras.

En resumen, Shapella no solo abrió la puerta de salida para los stakers—solidificó la base de la era post-Merge y despejó la pista para que Ethereum se enfocara en su siguiente frontera: escalabilidad masiva.