Saltar al contenido
Financial Context Wiki

Disponibilidad de datos

Guía basada en la verificación de publicación, recuperabilidad, compromisos, validez, finalidad, muestreo, retención, archivos, derivación de rollups y recuperación ejecutable.

Actualizado

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

Respuesta directa

La disponibilidad de datos significa que se publican y pueden obtenerse suficientes datos definidos por el protocolo, dentro de la ventana exigida, para que los participantes previstos verifiquen, deriven o reconstruyan el estado pertinente. El objeto requerido puede ser entradas de transacciones, diferencias de estado, fragmentos codificados u otro formato de lote definido; no equivale a que un sitio web, endpoint RPC o API del proyecto esté en línea.

Deben separarse cuatro afirmaciones. La disponibilidad trata de la publicación oportuna para los consumidores del protocolo. La recuperabilidad indica si una parte concreta puede obtener los bytes ahora o después. La validez indica si una transición de estado respeta las reglas o restricciones de la prueba. La finalidad indica si el consenso aún puede sustituir el compromiso durante el funcionamiento normal. Un compromiso vinculante, prueba KZG, prueba de validez o inclusión finalizada no demuestra por sí solo las cuatro afirmaciones, y la disponibilidad temporal no es archivo permanente.

Cómo funciona

  1. Defina la afirmación antes de medirla: lote, blob, namespace u objeto codificado exactos; protocolo y versión; consumidor previsto; tarea exigida de derivación, verificación o salida; y ventanas de disponibilidad, impugnación y recuperación. Datos completos significa datos suficientes según ese protocolo, no una copia indefinida de cada transacción.
  2. Fije la ruta y las pruebas de publicación: cadena de liquidación, cadena DA dedicada, calldata, sidecar del blob, compromiso externo o certificado de comité; identificadores de bloque, slot y lote; codificación y compresión; compromiso; y contrato o puente que lo consume. Publicar en un lugar no demuestra que otro verificador lo compruebe.
  3. Pruebe por separado vinculación y reconstrucción. Obtenga los bytes sin la API del proyecto, verifique su hash, compromiso KZG u otro y la referencia de inclusión, valide framing y codificación de borrado, decodifique el lote y reproduzca las entradas necesarias para derivar el estado. Un compromiso válido sin bytes no es una reconstrucción correcta.
  4. Mapee el modelo de aceptación. Registre si los nodos completos descargan el objeto, los nodos ligeros muestrean fragmentos autenticados, los validadores tienen obligaciones de custodia o un comité DA firma un certificado de umbral. Exponga los supuestos de muestreo, borrado, independencia de pares, umbral, stake, claves y eclipse, y qué verifica realmente el contrato de liquidación o puente.
  5. Siga estados y relojes distintos: enviado, incluido, disponible en la ventana del protocolo, recuperable por clientes independientes, decodificado o derivado, válido en ejecución, seguro, finalizado y archivado. Una prueba de validez puede acreditar computación restringida mientras siguen sin estar disponibles los datos necesarios para la derivación u operación independiente.
  6. Mida retención, arranque y economía. Registre mínimo de servicio del protocolo, poda, proveedores de archivos e instantáneas, requisitos de nuevos nodos, bytes brutos y codificados, sobrecarga, precio unitario, costes de pruebas y transacciones, límites de capacidad, subsidios y costes de fallback. La recuperación a largo plazo añade una dependencia cuando vence la DA temporal.
  7. Ensaye fallos. Pruebe ocultación, servicio selectivo, muestras correlacionadas o eclipsadas, pérdida del comité, parada o fork de DA, reorganización de liquidación, frames ausentes, pérdida del archivo, censura del secuenciador y picos de comisiones. Verifique parada segura, inclusión forzada, reintento, fallback, reconstrucción y salida con software, datos y gas reales; conserve compromisos, recibos y pruebas independientes de archivo.

Ejemplos desarrollados

  • Unidades correctas del coste de datos. Un lote contiene 400,000 bytes, cubre 2,000 transactions y cuesta $0.00002 per byte. El cargo DA es 400,000 * $0.00002 = $8 per batch, o $8 / 2,000 = $0.004 per transaction. Si el precio unitario se multiplica por diez hasta $0.00020 per byte, pasa a $80 per batch y $0.040 per transaction, no $0.04 per batch. Se excluyen ejecución, prueba, sobrecarga de transacción, archivo y margen.
  • La ventana de servicio del protocolo no promete archivo. La ventana mínima de solicitudes de EIP-4844 es 4,096 epochs; con 32 slots per epoch y 12 seconds per slot, son 4,096 * 32 * 12 = 1,572,864 seconds, o 1,572,864 / 86,400 = 18.2044444444 days. Es un mínimo del protocolo en este modelo, no garantía de que un proveedor conserve para siempre un blob concreto.
  • Probabilidad de muestreo estilizada. Suponga, solo como modelo didáctico, que un atacante oculta 50% de los fragmentos expandidos muestreados uniformemente y que 30 muestras autenticadas son independientes y con reemplazo. La probabilidad de que todas eviten la zona oculta es 0.5^30 = 0.0000000009313225746, por lo que la detección es 99.9999999069%. No es garantía de servicio de PeerDAS ni de otra red real; pares correlacionados, sesgo, parámetros de codificación y ataques adaptativos cambian el resultado.
  • El umbral del comité no equivale a recuperabilidad actual. Un comité DA hipotético exige firmas 5-of-7. Si tres miembros no están disponibles, quedan 4, por lo que no puede formarse un certificado nuevo. Un certificado antiguo con 5 signatures demuestra que el umbral atestiguó conforme a sus reglas; no demuestra que un usuario pueda recuperar ahora los bytes, que la ejecución sea válida o que la liquidación sea final.

Riesgos

  • Examinar cadena, lote, blob, namespace o versión de protocolo equivocados.
  • Confundir un compromiso o certificado con los bytes subyacentes.
  • Tratar la recuperación actual desde un endpoint como disponibilidad de todo el protocolo.
  • Tratar la disponibilidad de datos como prueba de validez de ejecución.
  • Tratar disponibilidad o validez como finalidad del consenso.
  • Referenciar un bloque de liquidación obsoleto, inseguro o reorganizado.
  • Perder la ventana de retención antes de obtener los datos.
  • Depender de un archivo, snapshot, indexador o API del proyecto.
  • Aceptar framing, compresión o codificación de borrado mal formados.
  • No verificar hash, KZG u otro compromiso.
  • Muestrear pocos fragmentos para el modelo de amenaza declarado.
  • Suponer independientes muestras, pares o grupos de custodia correlacionados.
  • Sufrir ataques eclipse, selección sesgada de pares o servicio selectivo.
  • Usar parámetros de borrado o umbrales de reconstrucción incompatibles con el verificador.
  • Depender de un comité DA coludido o no disponible.
  • Permitir que el contrato de puente o liquidación acepte un objeto más débil de lo esperado.
  • Perder datos por ocultación o censura del secuenciador o frames ausentes.
  • Encontrar una parada, fork, reorganización o actualización de cliente incompatible de DA.
  • Descubrir que la inclusión forzada, fallback, recuperación o salida no es ejecutable.
  • Subestimar capacidad, picos de comisiones, sobrecarga, coste de archivo o fin de subsidios.

Errores comunes

  • Una prueba de validez elimina la necesidad de disponibilidad de datos.
  • Un compromiso o prueba KZG demuestra que podían obtenerse todos los bytes.
  • La inclusión finalizada significa que los datos seguirán siendo recuperables para siempre.
  • Las etiquetas on-chain, blob, DA dedicada o muestreo proporcionan automáticamente la misma seguridad.
  • Más muestras o menor coste demuestran por sí solos que un diseño DA es superior.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...