EIP-4844 y blobs: Ethereum le da carril barato a rollups

Un rollup publica sus lotes en L1 para que cualquiera pueda reconstruir su estado. Hasta 2024 lo hacía en calldata, el campo de datos de una transacción normal. Pero la calldata la procesan todos los nodos y queda en la historia de la cadena para siempre, aunque el rollup solo necesita que los datos estén disponibles el tiempo suficiente para que alguien los descargue y los verifique. ¿Por qué pagar almacenamiento permanente por algo que solo hace falta unas semanas?

EIP-4844, también llamada proto-danksharding, responde con un nuevo tipo de dato: el blob. Es un bloque de datos grande que viaja junto al bloque, que la EVM no puede leer, que tiene su propio mercado de comisiones y que los nodos pueden borrar al cabo de unos 18 días. [1]

Preguntas guía

• ¿Qué contiene una transacción con blobs y qué parte de ella puede leer un contrato?
• ¿Cómo se fija el precio del blob gas y por qué es independiente del gas normal?
• ¿Por qué es aceptable que los blobs se borren?
• ¿Qué cambiaron Pectra y Fusaka sobre la capacidad de blobs?

Conexiones dentro de la serie

• Antes: Rollups desde cero explica por qué un rollup necesita disponibilidad de datos; Berlin, London y EIP-1559 introduce el mecanismo de tarifa base que aquí se reutiliza.
• Después: ERC-4337 abre la parte de experiencia de usuario; MEV y PBS vuelve a la hoja de ruta del protocolo.
• Relacionados: Optimistic rollups y ZK rollups usan los blobs de formas distintas para enlazar datos y pruebas.

Historia: de calldata a blobs, y de Dencun a Fusaka

EIP-4844 se activó con Dencun, en la época 269568, el 13 de marzo de 2024. Sus parámetros iniciales apuntaban a 3 blobs por bloque de media y 6 como máximo, unos 0,375 MB y 0,75 MB. La propia EIP dejaba claro que eran límites pequeños a propósito, pensados para subir cuando la red demostrara que aguanta. [2] [1]

Pectra duplicó el objetivo con EIP-7691, y su anuncio explicaba el límite real: los blobs no se guardan para siempre, así que el disco no es el problema; lo que limita es el ancho de banda, porque cada blob se difunde por la red P2P. [3] Fusaka atacó ese límite con PeerDAS y programó dos bifurcaciones Blob Parameter Only (BPO), que solo cambian parámetros de blobs, para subir la capacidad por pasos. [4]

Traza de ejecución de una transacción con blobs: del sidecar a la EVM

Una transacción con blobs es de tipo 0x03. Tiene los campos de una transacción EIP-1559, más max_fee_per_blob_gas y blob_versioned_hashes. El destino to no puede estar vacío, así que no sirve para crear contratos. Los blobs en sí no van dentro de la transacción que se ejecuta: viajan en un sidecar, una envoltura que existe en la red y en la capa de consenso. [1]

Figura 1

Del blob al hash versionado, y lo que puede ver un contrato

Fuentes:

[1]

Cómo leer esta figura

Diagrama en tres columnas con una línea de tiempo debajo. Primera columna, el sidecar en red y consenso: un blob de 4096 elementos de 32 bytes, es decir 128 KiB, se compromete en un compromiso KZG de 48 bytes, que se convierte con un hash en el hash versionado, formado por el byte 0x01 seguido de sha256 del compromiso sin su primer byte. Segunda columna: la transacción tipo 0x03 contiene los campos de EIP-1559, con un to que no puede ser vacío, más max_fee_per_blob_gas y blob_versioned_hashes, donde llega el hash versionado. Tercera columna, lo que ve la EVM: el opcode BLOBHASH, 0x49, que devuelve el hash i; el precompile 0x0A, que verifica que un polinomio evaluado en z da y; y una nota en rojo que dice que el contenido del blob no es accesible. Abajo, una línea de tiempo: desde la inclusión y durante 4096 épocas, unos 18 días, los nodos deben servir el blob; después pueden podarlo.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Un blob son 4096 elementos de 32 bytes: 128 KiB. Su contenido se interpreta como un polinomio y se resume en un compromiso KZG de 48 bytes, un esquema que permite demostrar después el valor del polinomio en un punto sin revelar el resto. El hash versionado es 0x01 seguido de los últimos 31 bytes del SHA-256 del compromiso. El byte de versión deja espacio para cambiar de esquema en el futuro sin romper contratos. [1]

Un contrato dispone de dos herramientas. El opcode BLOBHASH (0x49, 3 gas) devuelve el hash versionado número i de la transacción actual, o cero si no existe. El precompile de evaluación de puntos en la dirección 0x0A (50000 gas) verifica una prueba KZG de que el blob comprometido vale y en el punto z. Con eso, un optimistic rollup puede cargar unos pocos valores del blob durante una disputa, y un ZK rollup puede demostrar que su prueba usa los mismos datos. [1]

El compromiso KZG necesita parámetros públicos generados en una ceremonia. ethereum.org describe la ceremonia de EIP-4844 como una cadena de contribuciones en la que cada participante mezcla aleatoriedad propia y la destruye: basta un participante honesto para que el secreto final sea desconocido. [5]

Invariante de precio: el blob gas como un segundo EIP-1559

Los blobs se pagan con blob gas, una unidad separada del gas de ejecución. Cada blob consume GAS_PER_BLOB = 2**17 unidades. La cabecera del bloque guarda excess_blob_gas, el blob gas acumulado por encima del objetivo, y la tarifa base del blob crece exponencialmente con ese exceso. La comisión se cobra antes de ejecutar, se quema y no se devuelve aunque la transacción falle. [1]

# EIP-4844 (extracto; TARGET_BLOB_GAS_PER_BLOCK era 393216 = 3 blobs en Dencun)
def calc_excess_blob_gas(parent: Header) -> int:
    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        return 0
    else:
        return parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK
 
def get_base_fee_per_blob_gas(header: Header) -> int:
    return fake_exponential(
        MIN_BASE_FEE_PER_BLOB_GAS, header.excess_blob_gas, BLOB_BASE_FEE_UPDATE_FRACTION
    )

El mecanismo se lee como el de EIP-1559: si los bloques usan más blobs que el objetivo, el exceso crece y el precio sube; si usan menos, el exceso baja y el precio cae. Como el mercado es independiente, una congestión de ejecución en L1 no encarece directamente los blobs, ni al revés. Dencun añadió además el opcode BLOBBASEFEE (0x4a, EIP-7516) para que un contrato lea la tarifa vigente, y Fusaka incluyó EIP-7918, que acota la tarifa base del blob en función del coste de ejecución. [6] [4]

Cuello de botella de disponibilidad: por qué los blobs pueden caducar

Los nodos de consenso deben servir los blobs durante MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS = 4096 épocas, unos 18 días. La EIP lo compara con propuestas de rotar la historia de ejecución a un año: es un plazo mucho más corto, y por eso los blobs son baratos. [1]

¿Por qué basta? Porque un rollup necesita que los datos estén disponibles una vez, el tiempo suficiente para que cualquier actor honesto los descargue, reconstruya el estado o construya una prueba de fraude. ethereum.org añade un matiz útil: 18 días es una obligación mínima de servicio, no una fecha de borrado garantizada, y el acceso a largo plazo depende de servicios de archivo. Los datos tampoco son privados: son públicos para que la verificación sea abierta. [7]

Historia en curso: muestreo de disponibilidad y PeerDAS

Con EIP-4844 cada nodo de consenso descarga todos los blobs. Para escalar más hay que romper esa regla sin perder la garantía de que los datos existen. La técnica es el muestreo de disponibilidad de datos (DAS): los datos se extienden con un código de borrado, de modo que con la mitad se puede reconstruir el resto, y cada nodo descarga solo fragmentos aleatorios. Si una parte significativa faltara, sería muy probable que algún nodo lo detectara. [8]

PeerDAS (EIP-7594), activado en Fusaka, es la primera aplicación de esa idea en mainnet: un protocolo de red en el que los nodos custodian y muestrean partes de los blobs en lugar de descargarlos completos. Danksharding completo es el destino de esa línea de trabajo, en el que la verificación de blobs se reparte entre subconjuntos de nodos. [9] [5]

Riesgo operativo y laboratorio: los blobs caducan

Si operas un indexador, un explorador o una auditoría que necesita datos de un rollup de hace meses, no asumas que un nodo de Ethereum te los dará. Tendrás que archivar los blobs tú mismo o depender de un servicio que lo haga. Lo mismo vale para los equipos de rollups: la recuperación tras un incidente largo necesita su propia copia de los datos.

Puedes observar el mercado de blobs con JSON-RPC estándar. Las cabeceras de bloque incluyen blobGasUsed y excessBlobGas, y el método eth_blobBaseFee devuelve la tarifa vigente. [10]

# Requiere un RPC propio en $RPC_URL y jq instalado.
rpc() { curl -s -X POST -H 'Content-Type: application/json' --data "$1" "$RPC_URL"; }
rpc '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}' \
  | jq '.result | {number, blobGasUsed, excessBlobGas}'
rpc '{"jsonrpc":"2.0","method":"eth_blobBaseFee","params":[],"id":2}' | jq -r '.result'

La validación observable es que blobGasUsed es siempre un múltiplo de 131072 (2¹⁷, un blob) y que, si varios bloques seguidos superan el objetivo, excessBlobGas crece y la tarifa sube.

Quédate con esta frase: un blob compra disponibilidad temporal, no almacenamiento. Ethereum garantiza que los datos se pudieron descargar; guardarlos después es responsabilidad de quien los necesita.