Transacciones Blob EIP-4844: Guía Práctica para Operadores de Rollups y Nodos

Qué cambia EIP-4844 y qué cubre esta guía

EIP-4844 introduce transacciones que transportan blobs: un formato de transacción que adjunta uno o más blobs de datos a una transacción de ejecución normal. La EVM no puede leer el contenido del blob, pero puede leer hashes versionados que comprometen cada blob. Los blobs mismos son propagados y almacenados por nodos de la capa de consenso durante una ventana de retención limitada, y luego se podan. Por eso la propuesta se llama proto-danksharding: implementa el formato de transacción y el mercado de tarifas que el danksharding completo reutilizará, sin fragmentar realmente los datos a través de la red todavía.

La consecuencia práctica para los rollups es un segundo canal de disponibilidad de datos más económico junto a calldata. El gas de ejecución y el gas blob se cotizan por separado, por lo que el costo de un rollup para publicar un lote depende de dos mercados. Este artículo cubre el mecanismo, un procedimiento de inspección ejecutable, un método de medición para costos blob, solución de problemas y compensaciones. Asume que tiene acceso a un endpoint JSON-RPC de Ethereum que expone campos relacionados con blobs y que puede ejecutar curl o Node.js.

• Comportamiento documentado del protocolo: tipo de transacción, compromisos KZG, contabilidad de gas blob, retención.
• Procedimiento operativo: inspeccionar transacciones blob y tarifa base blob vía JSON-RPC.
• Medición: calcular el costo efectivo blob por transacción y por byte en sus propios datos.
• Recomendaciones: dónde tener cuidado y cuándo consultar a un proveedor de endpoints.

Requisitos previos y supuestos

Necesita un endpoint RPC de Ethereum mainnet o testnet que soporte los campos JSON-RPC relacionados con blobs. La mayoría de los clientes de ejecución modernos exponen blobGasUsed y blobGasPrice en los recibos de transacción y un campo blobBaseFee en los bloques, pero debe verificarlo con su proveedor antes de confiar en ello. También necesita una forma de enviar u observar una transacción blob; si no es un operador de rollup, puede inspeccionar transacciones blob existentes desde un explorador de bloques o consultando bloques recientes.

Para los ejemplos de código, reemplace RPC_URL con su propio endpoint. Si aún no tiene un endpoint adecuado, el servicio OnFinality API y la guía de endpoints RPC explican cómo obtener uno; la elección concreta del proveedor es una tarea de recomendación breve que maneja mejor RPC Assistant. No use un endpoint público para mediciones de producción porque los límites de velocidad y el almacenamiento en caché pueden distorsionar los resultados.

export RPC_URL="https://your-endpoint.example"
export BLOCK_NUMBER="latest"

Modelo mental: carga útil de ejecución, carga útil blob y dos mercados de tarifas

Una transacción blob tiene dos partes. La carga útil de ejecución es una transacción normal: remitente, nonce, destinatario, valor, calldata, límite de gas y campos de tarifa máxima. La carga útil blob es una lista de blobs, cada uno de 4096 elementos de campo de 32 bytes, más compromisos KZG y pruebas. La capa de ejecución valida la transacción y cobra gas de ejecución como de costumbre. La capa de consenso valida los blobs contra sus compromisos y los incluye en el bloque beacon. La EVM solo ve los hashes versionados, que se derivan de los compromisos.

El gas blob se contabiliza por separado. Cada blob consume una cantidad fija de gas blob, y la tarifa base blob se ajusta según el mismo estilo de regla de actualización exponencial usada para EIP-1559, pero con su propio objetivo y máximo. Una transacción blob especifica una tarifa máxima por gas blob y una propina, y el precio efectivo del gas blob está limitado por la tarifa base blob y el límite del remitente. Debido a que los blobs se podan después de un período de retención, tienen un precio inferior al calldata, que se almacena indefinidamente. La ventana de retención es lo suficientemente larga para que los participantes del rollup recuperen datos pero lo suficientemente corta para mantener manejable el uso de disco.

• Gas de ejecución: pagado por cómputo y calldata, visible para la EVM.
• Gas blob: pagado por espacio blob, no legible por la EVM, podado después de la retención.
• Compromiso KZG: un compromiso sucinto con los datos del blob, verificado por nodos de consenso.
• Hash versionado: lo que la EVM puede acceder, derivado del compromiso.

Inspeccionar una transacción blob con curl

La forma más rápida de confirmar que su endpoint expone campos blob es obtener un bloque reciente con transacciones completas y buscar transacciones tipo 3. El método JSON-RPC eth_getBlockByNumber con el segundo parámetro establecido en true devuelve objetos de transacción. Las transacciones blob tienen tipo 0x3 e incluyen blobVersionedHashes. El objeto de bloque puede incluir blobGasUsed y excessBlobGas, y el recibo de transacción incluye blobGasUsed y blobGasPrice.

Ejecute el siguiente comando curl contra su endpoint. Si el bloque no tiene transacciones blob, elija un bloque de un período en el que los rollups estuvieran activos, o consulte un rango de bloques hasta encontrar uno. El resultado de verificación esperado es un objeto JSON que contiene al menos una transacción con tipo 0x3 y un arreglo blobVersionedHashes no vacío.

curl -s "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["'"$BLOCK_NUMBER"'",true]}' \
  | jq '.result.transactions[] | select(.type == "0x3") | {hash, type, blobVersionedHashes, maxFeePerBlobGas}'

Verificar la contabilidad de gas blob en un recibo

Una vez que tenga un hash de transacción blob, obtenga su recibo con eth_getTransactionReceipt. El recibo debe incluir blobGasUsed y blobGasPrice. Multiplíquelos para obtener la tarifa blob pagada por esa transacción. Compare eso con la tarifa de gas de ejecución, que es gasUsed multiplicado por effectiveGasPrice. Esta comparación es el núcleo de cualquier análisis de costo blob.

El siguiente fragmento de JavaScript usa la API fetch incorporada disponible en Node.js 18 y posteriores. Imprime la tarifa de ejecución, la tarifa blob y la tarifa total en wei y en ether. No asume ningún número en particular; usted proporciona el hash de la transacción. Si su endpoint devuelve null para blobGasPrice, el endpoint o la versión del cliente puede que no exponga el campo, y debe probar otro endpoint o consultar el blobBaseFee del bloque en su lugar.

const RPC_URL = process.env.RPC_URL;
const TX_HASH = process.env.TX_HASH;

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

const receipt = await rpc('eth_getTransactionReceipt', [TX_HASH]);
const gasUsed = BigInt(receipt.gasUsed);
const effectiveGasPrice = BigInt(receipt.effectiveGasPrice);
const blobGasUsed = BigInt(receipt.blobGasUsed ?? '0x0');
const blobGasPrice = BigInt(receipt.blobGasPrice ?? '0x0');

const executionFee = gasUsed * effectiveGasPrice;
const blobFee = blobGasUsed * blobGasPrice;
const totalFee = executionFee + blobFee;

console.log({
  executionFeeWei: executionFee.toString(),
  blobFeeWei: blobFee.toString(),
  totalFeeWei: totalFee.toString(),
  totalFeeEther: Number(totalFee) / 1e18
});

Medir la tarifa base blob y el costo por byte

Para medir los costos blob a lo largo del tiempo, muestree bloques y registre blobBaseFee, blobGasUsed y el número de transacciones blob. La tarifa base blob es un precio por gas blob; cada blob consume una cantidad fija de gas blob, por lo que el costo por blob es blobGasUsed por blob multiplicado por blobBaseFee. Para obtener el costo por byte, divida el costo por blob por el tamaño del blob en bytes. Debido a que el tamaño del blob es fijo por el protocolo, este es un cálculo sencillo una vez que tiene la tarifa base.

Use una tabla para registrar sus mediciones. No complete números de memoria o de otra red; ejecute el procedimiento y registre lo que devuelve su endpoint. La tabla a continuación es una plantilla. El procedimiento es: elija una ventana de muestreo, obtenga cada bloque, extraiga los campos y agregue. Un enfoque simple es consultar cada bloque en un rango y calcular la tarifa base blob media y máxima, luego multiplicar por el gas blob por blob para obtener el costo por blob.

• Ventana de muestreo: un rango de bloques contiguo en la red en la que opera.
• Campos: blobBaseFee del bloque, blobGasUsed del bloque, tipo de transacción y blobVersionedHashes.
• Agregación: tarifa base blob media, mediana y máxima; conteo de transacciones blob.
• Métrica derivada: costo por blob y costo por byte usando el tamaño de blob fijo del protocolo.

| Sample | Block | blobBaseFee (wei) | blobGasUsed | Blob txs | Cost per blob (wei) | Cost per byte (wei) |
|--------|-------|-------------------|-------------|----------|---------------------|---------------------|
| 1      |       |                   |             |          |                     |                     |
| 2      |       |                   |             |          |                     |                     |
| 3      |       |                   |             |          |                     |                     |

Resultados de verificación esperados y qué significan

Si su endpoint está saludable y es consciente de blobs, la consulta de bloque devuelve transacciones tipo 3 con blobVersionedHashes, y la consulta de recibo devuelve blobGasUsed y blobGasPrice no nulos. La tarifa base blob debe estar presente en los bloques después de que la red activó las transacciones blob. Si ve transacciones tipo 3 pero campos blob nulos, el endpoint puede estar retrasado o usando un cliente que no expone los campos; pruebe un endpoint diferente antes de concluir que la red tiene la culpa.

Una ejecución de medición exitosa produce una tabla sin vacíos en los campos muestreados y una cifra de costo por blob que es consistente con la tarifa base blob que observó. Si el costo por blob varía enormemente dentro de una ventana corta, verifique si está mezclando bloques de diferentes redes o si su endpoint está devolviendo datos en caché. Para monitoreo de producción, use un endpoint dedicado en lugar de uno público compartido, y considere un nodo dedicado si necesita un muestreo consistente.

Solución de problemas operativos comunes de EIP-4844

Las transacciones blob introducen modos de falla que no existían para las transacciones heredadas. Los más comunes están relacionados con tarifas: una transacción cuya tarifa máxima por gas blob está por debajo de la tarifa base blob actual no será incluida. A diferencia del gas de ejecución, no puede simplemente aumentar la tarifa de prioridad; debe asegurarse de que el límite de tarifa blob sea lo suficientemente alto. Otro problema común es la gestión de nonces al enviar múltiples transacciones blob, porque cada transacción consume un nonce y una transacción blob fallida aún consume el nonce si se incluye.

Una segunda clase de problemas es la recuperación de datos. Los blobs se podan después de la ventana de retención, por lo que cualquier sistema que necesite datos históricos de blobs debe archivarlos antes de la poda. Si la disponibilidad de datos de su rollup depende de blobs, necesita una estrategia de recuperación que no asuma que los blobs son permanentes. Una tercera clase es el soporte del endpoint: algunos proveedores RPC no exponen campos blob o no retransmiten transacciones blob. Verifique el soporte antes de construir un flujo de trabajo alrededor de un endpoint específico.

• Límite de tarifa blob demasiado bajo: transacción no incluida; aumente maxFeePerBlobGas.
• Brechas de nonce: múltiples transacciones blob enviadas sin esperar recibos.
• Blobs podados: datos históricos no disponibles; archive antes de que expire la retención.
• Brechas en el endpoint: campos blob nulos o transacciones blob rechazadas; cambie de endpoint.
• Versión del cliente: clientes más antiguos pueden no exponer campos blob; actualice o cambie de proveedor.

Limitaciones y compensaciones del proto-danksharding

EIP-4844 es un trampolín, no sharding completo. Los datos blob no se fragmentan a través de la red de la manera en que lo hará el danksharding completo, y el número de blobs por bloque está limitado. Ese límite significa que el espacio blob puede volverse disputado durante períodos de alta actividad de rollups, y la tarifa base blob puede subir. El mercado de tarifas está diseñado para manejar esto, pero significa que los costos blob no son fijos y deben monitorearse.

Los blobs tampoco son legibles por la EVM, lo cual es una elección de diseño deliberada pero una limitación para contratos que necesitan inspeccionar datos directamente. Los rollups deben diseñar en torno a hashes versionados y recuperación fuera de cadena. Finalmente, la retención es finita. Cualquier aplicación que trate a los blobs como almacenamiento permanente está haciendo un uso indebido de la característica. Estas compensaciones son aceptables para disponibilidad de datos, pero no son un sustituto de una capa de disponibilidad de datos completa.

Próximos pasos: de la inspección al monitoreo de producción

Una vez que pueda inspeccionar transacciones blob y medir tarifas base blob, el siguiente paso es construir un pequeño bucle de monitoreo. Muestree bloques según un horario, registre la tarifa base blob y los conteos de transacciones blob, y alerte cuando la tarifa exceda un umbral relevante para la economía de su rollup. Combine esto con monitoreo de gas de ejecución para que pueda ver el costo combinado de publicar un lote.

Para la selección de endpoints, use RPC Assistant para una recomendación breve sobre un endpoint de Ethereum consciente de blobs, y revise los precios de OnFinality para RPC para entender los límites de velocidad y las opciones dedicadas. Si opera un rollup o un servicio de disponibilidad de datos, un nodo dedicado le brinda acceso consistente y evita la variabilidad de endpoints compartidos. El directorio de redes lista las redes soportadas, y la sección Learn tiene guías relacionadas sobre endpoints RPC y alojamiento de nodos.

• Construya un muestreador programado para blobBaseFee y conteos de transacciones blob.
• Alerte sobre umbrales de tarifa blob y sobre campos blob faltantes de su endpoint.
• Archive datos blob antes de que expire la retención si su aplicación necesita historial.
• Elija un endpoint consciente de blobs y considere un nodo dedicado para producción.