EIP-4844 después de Dencun: impacto real de los blobs en las Layer 2

Los rollups procesan transacciones fuera de la capa base de Ethereum y necesitan publicar datos que permitan comprobar su actividad. El coste de esa publicación influye en la operación de las redes de capa 2. EIP-4844 introdujo un recurso específico para esos datos: los blobs, paquetes que Ethereum conserva temporalmente.

La mejora se activó con Dencun el 13 de marzo de 2024 y permitió separar esa publicación del uso habitual de calldata, que queda en el historial de transacciones. Para entender su efecto hay que distinguir el coste de aportar datos a Ethereum del coste de ejecutar las operaciones dentro de cada rollup.

Qué cambió frente a la calldata

Antes de Dencun, una Layer 2 publicaba gran parte de sus datos como calldata. Ese recurso compite con la ejecución de transacciones de la capa base y forma parte del historial de ejecución, aunque el rollup solo necesita que esté disponible el tiempo suficiente para que cualquiera pueda verificar o reconstruir su estado.

Los blobs separan esos datos del espacio de ejecución y tienen su propio mercado de comisiones. Cuando aumenta la actividad de contratos en Ethereum, el coste de los datos de una Layer 2 ya no tiene por qué subir en la misma proporción. Esa separación, más que una cifra promocional concreta, es el cambio económico duradero de EIP-4844.

Cómo funciona un blob

Una transacción puede adjuntar blobs, pero la EVM no accede a su contenido directamente. El bloque incluye compromisos KZG que vinculan criptográficamente cada blob con la transacción. Los nodos mantienen el dato durante un periodo limitado y después pueden descartarlo, mientras el compromiso sigue formando parte del historial verificable.

El diseño usa compromisos KZG para demostrar que un dato pertenece al polinomio comprometido sin publicar todo el blob dentro de la ejecución. Esto prepara la arquitectura para escalar la disponibilidad de datos sin exigir que cada validador conserve para siempre cada lote de cada rollup.

El impacto real en las Layer 2

Para una Layer 2, publicar datos en Ethereum era uno de los costes dominantes. Los blobs introdujeron un recurso de datos con capacidad y precio propios. El ahorro de una operación concreta depende del precio de ese recurso, de la ocupación del lote y de cómo se reparta el coste entre las transacciones. No se deduce una reducción fija para todos los rollups.

Sin embargo, blob barato no equivale automáticamente a comisión mínima para cada usuario. El precio final también incorpora el coste de ejecución dentro del rollup, la frecuencia y compresión de los lotes, el margen del sequencer, la congestión de la propia Layer 2 y su política de subsidios. Comparar redes exige observar el coste total y no solo la tarifa base del blob.

Qué no resolvió EIP-4844

EIP-4844 no aumentó por sí sola la capacidad de ejecución de Ethereum, no eliminó los puentes ni unificó la liquidez entre redes. Tampoco implementó danksharding completo. Introdujo la primera capa de datos basada en blobs y las primitivas criptográficas necesarias para ampliar esa capacidad en mejoras posteriores.

Cómo medir el efecto sin mezclar costes

Una comparación útil observa el mismo tipo de operación y separa lo cobrado al usuario del coste asumido por el operador. Si el rollup modifica a la vez la compresión, los subsidios y el recurso de datos, atribuir toda la diferencia a EIP-4844 sería una conclusión incompleta.

Como criterio de evaluación, registra el periodo, número de transacciones por lote, datos publicados y comisiones de ejecución y publicación. Incluye lotes poco ocupados y momentos de mayor demanda. Un coste medio favorable puede ocultar operaciones aisladas más caras o una política comercial temporal.

También hay que distinguir conservar un compromiso de conservar los datos necesarios para reconstruir un estado histórico. La política de archivo debe comprobarse mediante recuperación real, con responsabilidades y fuentes disponibles después del periodo de retención exigido por la red. El compromiso criptográfico permite verificar datos recuperados; no permite recrear arbitrariamente un blob que nadie conserva.

Qué debe revisar un equipo que construye sobre rollups

Conviene medir por separado ejecución, publicación de datos y costes del sequencer; decidir cuándo cerrar cada lote; vigilar el mercado de blobs durante picos; y conservar una estrategia propia de indexación y disponibilidad histórica. Que el dato expire en la capa de consenso no exime al protocolo de mantener la información que su producto, sus pruebas o sus usuarios necesitarán después.

En conjunto, EIP-4844 confirma la hoja de ruta centrada en rollups de Ethereum: la capa base aporta consenso y disponibilidad de datos; las Layer 2 concentran la ejecución. Su valor no está en prometer comisiones siempre iguales, sino en haber creado un recurso específico y escalable para los datos que sostienen esos sistemas.