Saltar al contenido
Financial Context Wiki

Espacio de blobs

Guía basada en la verificación del espacio de blobs de Ethereum, su capacidad codificada y útil, el muestreo y la custodia de PeerDAS, la retención temporal, la derivación de rollups y los límites vigentes según el fork.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

El espacio de blobs es la capacidad limitada y temporal de Ethereum para la disponibilidad de datos en blobs comprometidos junto a los bloques. No es espacio de ejecución de la EVM, almacenamiento de contratos, un sistema de archivos permanente ni un token. Una transacción de tipo 3 contiene hashes versionados; los datos autenticados del blob viajan en sidecars de la capa de consenso o en columnas de datos de PeerDAS. La EVM puede consultar un hash versionado y verificar un punto abierto, pero no leer directamente la carga del blob.

PeerDAS amplía los blobs mediante codificación de borrado, divide la matriz extendida en 128 columns y permite que los nodos custodien y muestreen subconjuntos, sin exigir que cada nodo descargue cada blob completo. Esto sustenta un juicio probabilístico local de disponibilidad, no una prueba de validez de la ejecución del rollup, finalidad de Ethereum, seguridad del puente ni recuperación permanente. La capacidad cambia con el fork. A 2026-08-13, el mainnet de Ethereum tras Fusaka BPO2 tiene como objetivo 14 blobs per block y permite como máximo 21; cada transacción de blobs está limitada a 6 blobs.

Cómo funciona

  1. Fija la red, el bloque o slot, el fork y calendario Blob-Parameter-Only activos, además del rollup y la versión de derivación. Los parámetros históricos 3/6, los de Pectra 6/9, los actuales 14/21, los de testnet y los futuros no son intercambiables.
  2. Identifica el objeto publicado: transacción de tipo 3, hashes versionados, compromisos y pruebas KZG, índices de blobs, origen L1 y si el rollup utilizó realmente blobs de Ethereum en vez de calldata o DA alternativa. Un compromiso vincula datos, pero por sí solo no prueba que los bytes estuvieran disponibles.
  3. Separa las unidades. Un blob tiene 4,096 field elements * 32 bytes = 131,072 encoded bytes; la carga sin restricciones suele usar 31 bytes por elemento de campo, o 126,976 usable bytes. Compresión, framing, padding, gas de blob, celdas ampliadas por codificación de borrado y bytes de aplicación son cantidades distintas.
  4. Verifica los límites del calendario. El objetivo orienta la respuesta del precio; no es capacidad reservada. El máximo de bloque es un techo de consenso, no el rendimiento esperado. El límite PeerDAS de 6 blobs per transaction es distinto del máximo actual de 21 blobs per block.
  5. Verifica la vía de disponibilidad. PeerDAS usa extensión de borrado unidimensional, celdas y columnas autenticadas, gossip y solicitudes a pares. Con los parámetros actuales, un nodo muestrea al menos 8 columns y tiene deberes de custodia; obtener al menos 64 of 128 columns permite reconstruir la matriz extendida.
  6. Sigue estados separados del ciclo de vida: compromiso incluido, columnas obtenidas y verificadas, comprobación DA local superada, bloque L1 seguro o finalizado, lote del rollup decodificado y derivado, ventana mínima de servicio activa y archivo independiente probado. La disponibilidad no vuelve verdaderos todos los estados posteriores.
  7. Ensaya columnas ausentes, eclipse o partición, propagación tardía, reorganización L1, discrepancias de calendario o cliente, actualización del formato del rollup y pérdida del archivo. Recupera, reconstruye y conserva los datos necesarios antes de que venza la ventana del protocolo; para la contabilidad de costes del batcher y del usuario, usa el tema separado sobre comisiones de blobs.

Ejemplos desarrollados

  • Unidades de bytes de un blob. La capacidad codificada es 4,096 * 32 = 131,072 bytes = 128 KiB. La carga arbitraria general es 4,096 * 31 = 126,976 bytes = 124 KiB. La diferencia es 4,096 bytes, o 3.125% de la capacidad codificada; la compresión y el framing del rollup reducen aún más la carga de aplicación.
  • Capacidad actual por bloque. En el objetivo, 14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB y 14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB. En el máximo, 21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB y 21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB. Son límites de mainnet específicos de la fecha y previos a compresión y framing.
  • Límites de transacción y bloque. Una transacción con 6 blobs transporta 786,432 encoded bytes = 0.75 MiB y 761,856 usable bytes = 0.7265625 MiB. Un bloque máximo de 21-blob necesita al menos 4 transactions, por ejemplo 6 + 6 + 6 + 3; un bloque objetivo de 14-blob puede ser 6 + 6 + 2. Ninguna distribución reserva capacidad para un rollup.
  • Ventana de servicio y volumen nominal. 4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days. Con 7,200 slots per day nominales y objetivo de 14-blob, el volumen codificado es 100,800 blobs per day = 12.3046875 GiB per day, mientras que el volumen generalmente utilizable es 11.920166015625 GiB per day. Los slots perdidos y la inclusión real cambian el total, y la ventana de servicio no promete archivo permanente.

Riesgos

  • Aplicar un fork o calendario Blob-Parameter-Only obsoleto.
  • Mezclar límites de mainnet, testnet u otra red.
  • Tratar el objetivo como capacidad garantizada o reservada.
  • Tratar el máximo como rendimiento normal esperado.
  • Confundir el límite de seis blobs por transacción con el límite de bloque.
  • Mezclar unidades codificadas, útiles, comprimidas, enmarcadas y de gas de blob.
  • Omitir padding o gastos generales del formato del rollup.
  • Etiquetar calldata o DA alternativa como espacio de blobs de Ethereum.
  • Aceptar un hash versionado que no corresponda al compromiso del blob.
  • Tratar una apertura KZG válida como prueba de que los bytes estuvieron disponibles.
  • Tratar el muestreo como descarga local completa de cada blob.
  • Confundir disponibilidad de datos con validez de transición de estado.
  • Confundir una comprobación DA local con finalidad L1 o del rollup.
  • Perder columnas por retraso, eclipse, partición o pares correlacionados.
  • No poder reconstruir o solicitar a pares pese a la capacidad nominal.
  • Perder o reordenar el compromiso en una reorganización L1.
  • Dejar vencer la ventana mínima antes de la derivación o impugnación.
  • Depender de un archivo o indexador no disponible, corrupto o incompleto.
  • Fallar la derivación tras actualizar compresión o protocolo del rollup.
  • Suponer que puente o salida son seguros solo porque los blobs estuvieron disponibles.

Errores comunes

  • El espacio de blobs es almacenamiento permanente que los contratos leen como calldata.
  • Cada byte de un blob de 128 KiB es carga de aplicación sin restricciones.
  • Con PeerDAS, cada nodo de Ethereum descarga y guarda para siempre cada blob completo.
  • Un compromiso KZG, un muestreo satisfactorio o una inclusión finalizada prueba que el estado del rollup es correcto y que los usuarios pueden salir.
  • La capacidad de mainnet está fijada para siempre en 3/6, 6/9 o el calendario actual 14/21.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...