Saltar al contenido
Financial Context Wiki

Comisiones de blob y costes de rollups

Guía basada en la verificación sobre el gas de blobs de Ethereum, los calendarios vigentes, la utilización de lotes, la asignación de comisiones de rollups y la diferencia entre el coste de publicación en L1 y la factura de un usuario de L2.

Actualizado

Solo con fines educativos; no constituye asesoramiento financiero ni de seguridad. Los parámetros de blobs, las fórmulas de comisiones de los rollups, las políticas del secuenciador, los tipos de cambio y los supuestos de disponibilidad de datos pueden cambiar o fallar.

Respuesta directa

Una comisión de blob de Ethereum es el cargo del protocolo por publicar datos en blobs, no la comisión total que paga un usuario de L2. Una transacción con blobs paga blob_count * 131,072 * blob_base_fee_per_blob_gas por el gas de blobs y, por separado, el gas de ejecución ordinario. Después, un rollup puede distribuir ese coste de L1 conforme a sus propias reglas de compresión, escalares, gastos generales y precios del operador; por ello, el recibo del publicador del lote, la estimación de costes del rollup, la cotización del usuario y los ingresos del operador son registros distintos.

Los blobs son datos temporales anexos comprometidos mediante hashes KZG versionados. La EVM puede usar los compromisos, pero no leer directamente los bytes del blob. PeerDAS modifica cómo los nodos de Ethereum distribuyen y muestrean esos datos; no convierte los blobs en archivos permanentes ni universaliza la fórmula de comisiones de un rollup. La capacidad también depende del fork. A 2026-08-13, la red principal de Ethereum después de Fusaka BPO2 tiene como objetivo 14 blobs y permite como máximo 21 blobs por bloque, en sustitución de los calendarios anteriores 3/6 y 6/9.

Cómo funciona

  1. Fija el contexto de medición: red Ethereum, bloque o slot, fork y calendario Blob-Parameter-Only activos, despliegue del rollup y versión de su fórmula, origen L1, token de comisión del usuario y momento del tipo de cambio. No apliques parámetros actuales de mainnet a un bloque antiguo, una testnet o un fork futuro.
  2. Identifica el objeto de publicación mediante evidencia de la cadena. Registra la transacción de tipo 3, remitente, recibo, hashes versionados, número de blobs, blob_gas_used, bytes codificados y útiles, compresión o framing, y si el rollup utilizó blobs, calldata u otra vía de disponibilidad de datos.
  3. Lee ambos mercados de comisiones. El gas de blobs usa 131,072 blob gas per blob; distingue el blob_base_fee_per_blob_gas realizado del límite max_fee_per_blob_gas del remitente. Registra por separado el gas de ejecución consumido, su precio efectivo y la propina. Tras EIP-7918, los precios bajos de blobs mantienen una relación de precio de reserva con el coste de ejecución, aunque ambos recursos conservan contabilidad separada.
  4. Reconstruye el libro L1 efectivo del publicador: comisión de blob quemada, comisión de ejecución y propina, además de las transacciones correspondientes de salida de estado, prueba, puente o publicación. La comisión de blob se cobra incluso si falla la ejecución de la transacción, y un límite no cobrado no es ni coste ni reembolso.
  5. Reproduce la fórmula vigente del rollup concreto. Registra bytes comprimidos u otra unidad medida, escalares, gastos fijos, cargos del operador o de prioridad, reembolsos y reglas de respaldo. La documentación de OP Stack solo sirve como evidencia para un despliegue OP; otro rollup puede asignar los costes de otra manera.
  6. Separa cuatro libros: coste L1 del publicador, coste L1 de datos atribuido por el rollup, débito real del usuario e ingreso o margen del operador. Dividir por igual entre el número de transacciones es solo una asignación analítica. El llenado, padding, mezcla de transacciones, publicación diferida y subsidios cruzados pueden alejarla de la cotización del protocolo.
  7. Concilia contra recibos y somete el resultado a estrés. Prueba alzas del precio de blobs, congestión de ejecución, FX de ETH y del token de comisión, baja utilización, demora del secuenciador, fallback a calldata, cambios de fórmula, reorganización de L1, retención temporal y fallo de archivo. Informa siempre del bloque, unidades, supuestos y costes no conciliados.

Ejemplos desarrollados

  • Cargo protocolario por blobs. Dos blobs consumen 2 * 131,072 = 262,144 blob gas. A 30 gwei per blob gas, la comisión es 262,144 * 30 * 10^-9 = 0.00786432 ETH. Con $2,500 per ETH, equivale a $19.6608. Se excluye la comisión ordinaria de ejecución.
  • Dos libros de comisiones para una transacción. Si la misma transacción de tipo 3 usa 120,000 execution gas a un precio efectivo de 22 gwei, la ejecución cuesta 120,000 * 22 * 10^-9 = 0.00264 ETH. El cargo L1 total es 0.00786432 + 0.00264 = 0.01050432 ETH, o $26.2608 al FX indicado. El gas de blobs y el de ejecución siguen siendo entradas distintas.
  • Utilización y asignación del lote. Añade $4.0000 de costes de prueba y publicación conciliados: el coste analítico del lote pasa a $30.2608. Entre 2,000 included transactions, la asignación por igual es $30.2608 / 2,000 = $0.0151304 per transaction; entre solo 800, es $30.2608 / 800 = $0.0378260. Ninguna cifra es automáticamente la cotización del usuario ni el margen realizado del operador.
  • Capacidad actual y unidades de bytes. Con el calendario 14/21 específico de la fecha, objetivo y máximo son 14 * 131,072 = 1,835,008 y 21 * 131,072 = 2,752,512 blob-gas units, equivalentes a 1.75 MiB y 2.625 MiB de blobs codificados. Como una carga arbitraria suele usar 31 bytes de cada elemento de campo de 32 bytes, la carga útil es 14 * 126,976 = 1.6953125 MiB en el objetivo y 21 * 126,976 = 2.54296875 MiB en el máximo, antes de compresión y framing.

Riesgos

  • Aplicar un fork o calendario Blob-Parameter-Only obsoleto.
  • Mezclar parámetros de mainnet, testnet u otra cadena.
  • Confundir gas de blobs, gas de ejecución, bytes codificados y bytes útiles.
  • Tratar max_fee_per_blob_gas como la comisión base realizada.
  • Omitir la comisión ordinaria de ejecución y la propina de la transacción de tipo 3.
  • Suponer que una ejecución fallida devuelve la comisión de blob cobrada.
  • Usar una estimación RPC obsoleta en lugar del bloque y recibo incluidos.
  • Atravesar un cambio de tarifa mientras el secuenciador demora la publicación.
  • Infravalorar una subida por congestión o el mecanismo de precio de reserva.
  • Ignorar la congestión de ejecución de L1 porque el gas de blobs sea barato.
  • Asignar lotes incompletos o con padding como si estuvieran llenos.
  • Usar supuestos incorrectos de compresión, framing o mezcla de transacciones.
  • Contar dos veces transacciones de prueba, salida de estado, puente o publicación.
  • Aplicar una fórmula obsoleta de escalares, gastos generales o cargos del operador.
  • Confundir cotización, débito real, reembolso e ingreso del operador.
  • Activar un fallback caro a calldata u otro modelo de seguridad de DA.
  • Convertir ETH y tokens de comisión con precio o momento incorrectos.
  • Perder o atribuir mal un lote tras su sustitución o una reorganización de L1.
  • Tratar la disponibilidad temporal de PeerDAS como recuperación archivística permanente.
  • Ignorar fallos de secuenciador, validez, finalidad, puente o salida porque los blobs estaban disponibles.

Errores comunes

  • La comisión base de blob es toda la comisión L2 pagada por el usuario.
  • max_fee_per_blob_gas es el importe realmente cobrado.
  • Los 131,072 bytes codificados de un blob son todos carga útil arbitraria del usuario.
  • Una comisión base de blob menor reduce de inmediato y en igual porcentaje la comisión de cada usuario de L2.
  • Los blobs se almacenan de forma permanente dentro de la EVM y todo rollup usa una capacidad fija 3/6 o 6/9.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...