---
title: "Riesgo del comite de disponibilidad de datos (DAC)"
description: "Guia orientada a la verificacion de atestaciones DAC, reglas de aceptacion q-de-n, posesion y recuperacion reales de los datos, dominios de fallo correlacionados, rotacion de claves, retencion, mecanismos alternativos y riesgo de salida."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Riesgo del comite de disponibilidad de datos (DAC)

> Solo con fines educativos; no constituye asesoramiento de inversion. Invertir puede ocasionar perdidas.

<a id="answer"></a>

## Respuesta directa

Un comite de disponibilidad de datos es un conjunto acotado de miembros cuyas firmas o atestaciones pueden satisfacer la regla de un protocolo para aceptar una afirmacion de disponibilidad de datos fuera de la cadena. El certificado solo demuestra que el conjunto de claves configurado y el umbral aceptaron un objeto firmado concreto conforme a esas reglas. No demuestra por si solo que cada firmante obtuvo todos los bytes, conservo una copia duradera, atiende ahora a los usuarios, valido la ejecucion o hizo definitivo el asentamiento.

La seguridad y la actividad son distintas. Si el contrato acepta firmas `q-of-n`, el control de `q` claves validas puede satisfacer esa regla para un objeto no disponible, salvo que otra comprobacion lo impida. Con menos de `q` firmantes dispuestos y accesibles normalmente no puede formarse un certificado nuevo, por lo que las actualizaciones se detienen o recurren a un mecanismo alternativo documentado. La recuperacion efectiva tambien depende de comprobaciones honestas previas a la firma, copias independientes, retencion, capacidad de servicio, historial de claves y gobierno, y software ejecutable de reconstruccion y salida.

<a id="mechanism"></a>

## Como funciona

1. Fijar el despliegue: cadena, modo y version del protocolo, contratos de asentamiento y verificacion de disponibilidad, lote y objeto de datos, codificacion, compromiso, conjunto de claves, umbral `q`, numero de miembros `n`, firmantes obligatorios, activacion, vencimiento, revocacion y autoridad de gobierno.
2. Reconstruir la afirmacion firmada exacta y la logica de aceptacion. Verificar dominio, vinculacion con cadena y contrato, identificador del lote, compromiso o raiz de estado, vencimiento, mapa de bits de firmantes o agregacion, proteccion contra repeticion y calculo real del umbral en el contrato. El logotipo de un miembro o una respuesta de API no es la regla de aceptacion.
3. Exigir que cada miembro obtenga el objeto completo antes de firmar, compruebe su compromiso y codificacion, lo decodifique y conserve los datos necesarios para derivar el estado o ejecutar la salida de un usuario de forma independiente. Documentar que atestiguan los miembros y si el protocolo puede probar que esas comprobaciones ocurrieron.
4. Cartografiar dominios de fallo independientes en vez de contar nombres. Identificar entidades juridicas, control efectivo, cuentas y regiones de nube, DNS y redes, software y bases de datos, custodia de claves, almacenamiento, operaciones y jurisdiccion. Espejos o endpoints bajo un mismo plano de control no son miembros independientes.
5. Probar posesion y recuperacion. Obtener lotes recientes e historicos de varios miembros sin la API del operador, verificar hashes y raices, reconstruir el estado o una prueba de retiro, medir retencion y transferencia, y distinguir produccion del certificado, recuperacion presente, validez de ejecucion, finalidad del consenso y durabilidad del archivo.
6. Ejercitar el ciclo de vida y la recuperacion: rotacion de miembros y claves, conjuntos historicos, vencimiento y revocacion, disponibilidad inferior al umbral, compromiso de claves de umbral, servicio selectivo, caida del operador, alternativa con datos completos, modo de congelacion o escape, inclusion forzada, archivos independientes y gas y tiempo reales necesarios para salir.
7. Supervisar mapas de firmantes aceptados, demora del certificado, exito de recuperacion, integridad de bytes, antiguedad del almacenamiento, cambios de conjunto y umbral, actualizaciones, pausas y capacidad alternativa. Archivar certificados, datos y estado contractual, y dejar de aumentar la exposicion si se aceptan certificados pero la recuperacion independiente deja de funcionar.

<a id="example"></a>

## Ejemplos resueltos

- **Actividad y seguridad del umbral no son lo mismo.** En un comite didactico `5-of-7`, dos miembros no disponibles dejan `5` firmantes y aun puede formarse un certificado nuevo; tres dejan `4`, por lo que `4 < 5` y la produccion se detiene salvo que exista una alternativa documentada. A la inversa, controlar `5` claves aceptadas permite satisfacer el umbral; el certificado sigue sin demostrar recuperacion actual de bytes ni validez de ejecucion.
- **Modelo de disponibilidad independiente.** Supongase, solo como modelo IID didactico, que cada uno de `7` miembros esta disponible de forma independiente con probabilidad `0.95` y el certificado exige al menos `5`. Entonces `P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570`, de modo que la probabilidad modelizada de parada es `1 - 0.9962429570 = 0.0037570430`. Dependencias compartidas de nube, software, operador, regimen juridico o claves invalidan esta estimacion binomial.
- **Copias almacenadas y servicio son conceptos distintos.** Un lote ocupa `120 MB`. Siete copias completas e independientes almacenarian `120 * 7 = 840 MB`; si solo tres miembros lo conservan realmente, se almacenan `120 * 3 = 360 MB` aunque hayan firmado cinco claves. Servir una vez el objeto a `100 clients` transfiere `120 * 100 = 12,000 MB`: el numero de firmas no es ni numero de copias ni medida de capacidad de transferencia.
- **Umbral de reconstruccion.** Un objeto didactico contiene `1,024 records` divididos en `16 chunks` de `64 records`, con umbral declarado de recuperacion de `12 chunks`. Once fragmentos exponen `11 * 64 = 704 records`, pero `11 < 12`, por lo que el objeto no puede reconstruirse conforme a esa regla. Un certificado valido del comite no sustituye un fragmento ausente ni cambia el umbral.

<a id="risks"></a>

## Riesgos

- Examinar una cadena, contrato, despliegue, lote o version de protocolo incorrectos.
- Reconstruir mal la afirmacion firmada, el dominio, el compromiso o el vencimiento.
- Aceptar repeticiones entre cadenas, contratos, versiones o conjuntos historicos.
- Usar un conjunto de claves invalido, obsoleto, vencido o revocado.
- Interpretar mal `q`, `n`, los firmantes obligatorios, mapas de bits o firmas agregadas.
- Explotacion de un fallo del firmante o de la verificacion contractual.
- Firmar antes de obtener, comprobar y conservar todos los datos.
- Aceptar datos parciales, mal formados o codificados incorrectamente.
- Perder seguridad por compromiso o colusion de claves de umbral.
- Perder actividad porque menos miembros que el umbral pueden firmar.
- Contar como independientes entidades, nubes, regiones u operadores correlacionados.
- Compartir planos de control de DNS, TLS, software, bases de datos o almacenamiento.
- Sufrir ataques eclipse, servicio selectivo o dependencia de una pasarela privada.
- Borrar o podar datos despues de firmar o antes de terminar la ventana de salida.
- Romper la recuperacion historica por cambios de miembros o rotacion de claves.
- Permitir que el gobierno sustituya miembros, reduzca el umbral o eluda demoras.
- Referirse a un compromiso de asentamiento obsoleto, inseguro o reorganizado.
- Tratar una prueba de validez o una raiz finalizada como recuperacion actual.
- Descubrir que la alternativa, congelacion, inclusion forzada o salida no es ejecutable.
- Subestimar almacenamiento, transferencia, recuperacion, alternativa, tarifas o capacidad.

<a id="misconceptions"></a>

## Errores comunes

- Mas miembros implican automaticamente mas dominios de fallo independientes.
- `q` firmas prueban que existen `q` copias completas duraderas y publicamente recuperables.
- Una prueba de validez elimina la necesidad de verificar la disponibilidad del DAC.
- Un certificado antiguo valido garantiza recuperacion actual y archivo permanente.
- Un miembro honesto u oficial garantiza que todo usuario siempre pueda salir.

<a id="related"></a>

## Temas relacionados

- [Disponibilidad de datos](/es/crypto/data-availability/)
- [Rollup](/es/crypto/rollup/)
- [Finalidad](/es/crypto/finality/)

<a id="sources"></a>

## Fuentes

- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultado: 2026-08-13)
- [Validium](https://ethereum.org/developers/docs/scaling/validium/) - Ethereum.org (consultado: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consultado: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultado: 2026-08-13)
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (consultado: 2026-08-13)
- [starkex-data-availability-committee](https://github.com/starkware-libs/starkex-data-availability-committee) - StarkWare Industries Ltd. (consultado: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultado: 2026-08-13)
- [SequencerInbox.sol](https://github.com/OffchainLabs/nitro-contracts/blob/main/src/bridge/SequencerInbox.sol) - Offchain Labs (consultado: 2026-08-13)

Source: https://wiki.fcontext.com/es/crypto/data-availability-committee-risk/index.mdx