---
title: "Risque du comité de disponibilité des données (DAC)"
description: "Guide axé sur la vérification des attestations DAC, des règles d’acceptation q-sur-n, de la possession et de la récupération effectives des données, des domaines de défaillance corrélés, de la rotation des clés, de la conservation, du repli et du risque de sortie."
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.

# Risque du comité de disponibilité des données (DAC)

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

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

## Réponse directe

Un comité de disponibilité des données est un ensemble limité de membres dont les signatures ou attestations peuvent satisfaire la règle par laquelle un protocole accepte une affirmation de disponibilité de données hors chaîne. Le certificat prouve uniquement que le jeu de clés et le seuil configurés ont accepté un objet signé précis selon ces règles. Il ne prouve pas indépendamment que chaque signataire a récupéré tous les octets, conservé une copie durable, dessert actuellement les utilisateurs, validé l’exécution ou rendu le règlement définitif.

La sûreté et la vivacité sont distinctes. Si le contrat accepte des signatures `q-of-n`, le contrôle de `q` clés valides peut satisfaire cette règle pour un objet indisponible, sauf si un autre contrôle l’empêche. Avec moins de `q` signataires disponibles et consentants, aucun nouveau certificat ne peut normalement être formé ; les mises à jour s’arrêtent ou utilisent un mécanisme de repli documenté. La récupération effective dépend aussi de contrôles honnêtes avant signature, de copies indépendantes, de la conservation, de la capacité de service, de l’historique des clés et de la gouvernance, ainsi que de logiciels exécutables de reconstruction et de sortie.

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

## Fonctionnement

1. Identifier le déploiement : chaîne, mode et version du protocole, contrats de règlement et de vérification de disponibilité, lot et objet de données, encodage, engagement, jeu de clés, seuil `q`, nombre de membres `n`, signataires obligatoires, activation, expiration, révocation et autorité de gouvernance.
2. Reconstruire l’affirmation signée exacte et la logique d’acceptation. Vérifier le domaine, le rattachement à la chaîne et au contrat, l’identifiant du lot, l’engagement ou la racine d’état, l’expiration, le bitmap ou l’agrégation des signataires, la protection contre le rejeu et le calcul effectif du seuil par le contrat. Le logo d’un membre ou une réponse d’API ne constitue pas la règle d’acceptation.
3. Exiger de chaque membre qu’il récupère l’objet complet avant de signer, vérifie son engagement et son encodage, le décode et conserve les données nécessaires à une dérivation indépendante de l’état ou à la sortie d’un utilisateur. Consigner ce que les membres attestent et si le protocole peut prouver que ces contrôles ont eu lieu.
4. Cartographier les domaines de défaillance indépendants plutôt que compter les noms. Identifier personnes morales, contrôle effectif, comptes et régions cloud, DNS et réseau, logiciels et bases de données, garde des clés, stockage, opérations et juridiction. Des miroirs ou endpoints derrière un même plan de contrôle ne sont pas des membres indépendants.
5. Tester possession et récupération. Récupérer des lots récents et historiques auprès de plusieurs membres sans l’API de l’opérateur, vérifier hachages et racines, reconstruire l’état ou une preuve de retrait, mesurer conservation et transfert, et distinguer production du certificat, récupération actuelle, validité d’exécution, finalité du consensus et durabilité des archives.
6. Tester le cycle de vie et la récupération : rotation des membres et des clés, jeux de clés historiques, expiration et révocation, disponibilité sous le seuil, compromission des clés, service sélectif, panne de l’opérateur, repli vers les données complètes, mode de gel ou d’échappement, inclusion forcée, archives indépendantes et gas et délai réels nécessaires à la sortie.
7. Surveiller les bitmaps acceptés, le délai des certificats, le succès des récupérations, l’intégrité des octets, l’ancienneté du stockage, les modifications du jeu de clés et du seuil, les mises à niveau, les pauses et la capacité de repli. Archiver certificats, données et état contractuel, et cesser d’accroître l’exposition lorsque les certificats sont acceptés mais que la récupération indépendante ne fonctionne plus.

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

## Exemples détaillés

- **Vivacité et sûreté du seuil ne se confondent pas.** Dans un comité pédagogique `5-of-7`, deux membres indisponibles laissent `5` signataires et permettent encore un nouveau certificat ; trois en laissent `4`, donc `4 < 5` et la production s’arrête sans repli documenté. Inversement, contrôler `5` clés acceptées satisfait le seuil ; le certificat ne prouve toujours ni la récupération actuelle des octets ni la validité de l’exécution.
- **Modèle de disponibilité indépendante.** Supposons, uniquement comme modèle IID pédagogique, que chacun des `7` membres soit disponible indépendamment avec une probabilité de `0.95` et qu’un certificat exige au moins `5` signatures. Alors `P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570` ; la probabilité modélisée d’arrêt vaut `1 - 0.9962429570 = 0.0037570430`. Des dépendances communes de cloud, logiciel, opérateur, droit ou clés invalident cette estimation binomiale.
- **Copies stockées et service sont distincts.** Un lot mesure `120 MB`. Sept copies complètes indépendantes stockeraient `120 * 7 = 840 MB` ; si seuls trois membres le conservent réellement, le stockage atteint `120 * 3 = 360 MB`, même si cinq clés ont signé. Servir une fois l’objet à `100 clients` transfère `120 * 100 = 12,000 MB` : le nombre de signatures n’est ni un nombre de copies ni une mesure de capacité de transfert.
- **Seuil de reconstruction.** Un objet pédagogique contient `1,024 records`, répartis en `16 chunks` de `64 records`, avec un seuil de récupération déclaré de `12 chunks`. Onze fragments exposent `11 * 64 = 704 records`, mais `11 < 12` ; l’objet ne peut donc pas être reconstruit selon cette règle. Un certificat valide ne remplace pas un fragment manquant et ne modifie pas le seuil.

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

## Risques

- Examiner la mauvaise chaîne, le mauvais contrat, déploiement, lot ou version.
- Reconstruire incorrectement l’affirmation, le domaine, l’engagement ou l’expiration.
- Accepter un rejeu entre chaînes, contrats, versions ou jeux de clés historiques.
- Utiliser un jeu de clés invalide, obsolète, expiré ou révoqué.
- Mal interpréter `q`, `n`, les signataires obligatoires, bitmaps ou signatures agrégées.
- Exploitation d’un défaut du signataire ou de la vérification contractuelle.
- Signer avant récupération, contrôle d’intégrité et conservation des données complètes.
- Accepter des données partielles, mal formées ou mal encodées.
- Perdre la sûreté par compromission ou collusion des clés de seuil.
- Perdre la vivacité parce que moins de membres que le seuil peuvent signer.
- Compter comme indépendants des entités, clouds, régions ou opérateurs corrélés.
- Partager des plans de contrôle DNS, TLS, logiciel, base de données ou stockage.
- Subir une attaque eclipse, un service sélectif ou une dépendance à une passerelle privée.
- Supprimer ou élaguer les données après signature ou avant la fin de la fenêtre de sortie.
- Rompre la récupération historique par changement de membres ou rotation des clés.
- Permettre à la gouvernance de remplacer des membres, réduire le seuil ou contourner un délai.
- Référencer un engagement de règlement obsolète, non sûr ou réorganisé.
- Assimiler une preuve de validité ou une racine finalisée à la récupération actuelle.
- Découvrir que repli, gel, inclusion forcée ou sortie ne sont pas exécutables.
- Sous-estimer stockage, transfert, récupération, repli, frais ou capacité.

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

## Idées reçues

- Davantage de membres signifie automatiquement davantage de domaines de défaillance indépendants.
- `q` signatures prouvent que `q` copies complètes durables sont publiquement récupérables.
- Une preuve de validité dispense de vérifier la disponibilité des données du DAC.
- Un ancien certificat valide garantit récupération actuelle et archivage permanent.
- Un membre honnête ou officiel garantit que chaque utilisateur pourra toujours sortir.

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

## Sujets connexes

- [Disponibilité des données](/fr/crypto/data-availability/)
- [Rollup](/fr/crypto/rollup/)
- [Finalité](/fr/crypto/finality/)

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

## Sources

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

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