---
title: "Disponibilite des donnees"
description: "Guide axe sur la verification de la publication, de la recuperabilite, des engagements, de la validite, de la finalite, de l'echantillonnage, de la conservation, des archives, de la derivation des rollups et de la recuperation executable."
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.
# Disponibilite des donnees
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Reponse directe
La disponibilite des donnees signifie qu'une quantite suffisante de donnees definies par le protocole est publiee et recuperable pendant la fenetre requise, afin que les participants vises puissent verifier, deriver ou reconstruire l'etat pertinent. L'objet requis peut comprendre les entrees des transactions, des differences d'etat, des fragments encodes ou un autre format de lot defini ; il ne suffit pas qu'un site web, un point d'acces RPC ou l'API du projet soit en ligne.
Quatre affirmations doivent rester distinctes. La disponibilite porte sur la publication en temps utile aux utilisateurs du protocole. La recuperabilite indique si une partie donnee peut obtenir les octets maintenant ou plus tard. La validite indique si une transition d'etat respecte les regles ou les contraintes de preuve. La finalite indique si le consensus peut encore remplacer l'engagement dans le fonctionnement normal du protocole. Un engagement contraignant, une preuve KZG, une preuve de validite ou une inclusion finalisee ne demontre pas a lui seul ces quatre proprietes, et une disponibilite temporaire ne constitue pas un archivage permanent.
## Fonctionnement
1. Definir l'affirmation avant de la mesurer : lot, blob, espace de noms ou objet de donnees encode exact ; protocole et version ; utilisateur vise ; operation de derivation, de verification ou de sortie requise ; fenetres de disponibilite, de contestation et de recuperation. Des donnees completes sont celles qui suffisent selon ce protocole, et non une copie indeterminee de chaque transaction.
2. Fixer le chemin de publication et les preuves : chaine de reglement, chaine DA dediee, calldata, sidecar de blob, engagement externe ou certificat de comite ; identifiants de bloc, de slot et de lot ; encodage et compression ; engagement ; contrat ou pont qui le consomme. Une publication a un endroit ne prouve pas qu'un autre verificateur la controle.
3. Tester separement la liaison et la reconstruction. Recuperer les octets sans passer par l'API du projet, verifier leur hachage, leur preuve KZG ou autre engagement ainsi que la reference d'inclusion, valider le formatage et le codage d'effacement, decoder le lot et reproduire les entrees necessaires a la derivation de l'etat. Un engagement valide sans les octets ne constitue pas une reconstruction reussie.
4. Cartographier le modele d'acceptation. Indiquer si les noeuds complets telechargent l'objet, si les noeuds legers echantillonnent des fragments authentifies, si les validateurs ont des obligations de conservation ou si un comite de disponibilite des donnees signe un certificat a seuil. Expliciter les hypotheses relatives a l'echantillonnage, a l'effacement, a l'independance des pairs, au seuil, au stake, aux cles et aux attaques eclipse, ainsi que ce que le contrat de reglement ou de pont verifie effectivement.
5. Suivre des etats et des horloges distincts : soumis, inclus, disponible pendant la fenetre du protocole, recuperable par des clients independants, decode ou derive, valide a l'execution, sur, finalise et archive. Une preuve de validite peut etablir qu'un calcul respecte les contraintes alors que les donnees necessaires a une derivation ou a un fonctionnement independants restent indisponibles.
6. Mesurer la conservation, l'amorcage et l'economie. Consigner la duree minimale de service du protocole, le comportement d'elagage, les fournisseurs d'archives et de snapshots, les besoins des nouveaux noeuds, les volumes d'octets bruts et encodes, la surcharge, le prix unitaire, les couts de preuve et de transaction, les limites de capacite, les subventions et les couts de repli. La recuperation a long terme est une dependance supplementaire apres l'expiration de la DA temporaire.
7. Repeter les scenarios de defaillance. Tester la retention des donnees, le service selectif, les echantillons correles ou soumis a une attaque eclipse, la perte du comite, l'arret ou le fork de la DA, la reorganisation du reglement, les trames manquantes, la perte des archives, la censure du sequenceur et les pics de frais. Verifier l'arret sur, l'inclusion forcee, la nouvelle tentative, le repli, la reconstruction et la sortie avec les logiciels, les donnees et le gas reels, puis conserver les engagements, les recus et les preuves d'archives independantes.
## Exemples detailles
- **Unites correctes du cout des donnees.** Un lot contient `400,000 bytes`, couvre `2,000 transactions` et coute `$0.00002 per byte`. Les frais de donnees DA sont de `400,000 * $0.00002 = $8 per batch`, soit `$8 / 2,000 = $0.004 per transaction`. Si le prix unitaire est multiplie par dix et atteint `$0.00020 per byte`, le cout devient `$80 per batch` et `$0.040 per transaction`, et non `$0.04 per batch`. L'execution, les preuves, la surcharge de transaction, l'archivage et la marge sont exclus.
- **La fenetre de service du protocole n'est pas une promesse d'archivage.** La fenetre minimale de requete de l'EIP-4844 est de `4,096 epochs` ; avec `32 slots per epoch` et `12 seconds per slot`, cela donne `4,096 * 32 * 12 = 1,572,864 seconds`, soit `1,572,864 / 86,400 = 18.2044444444 days`. Il s'agit d'un minimum du protocole dans ce modele, et non de la garantie qu'un fournisseur conservera indefiniment un blob particulier.
- **Probabilite d'echantillonnage stylisee.** Supposons, uniquement pour un modele pedagogique, qu'un attaquant retienne `50%` des fragments etendus echantillonnes uniformement, et que `30` echantillons authentifies soient independants et tires avec remise. La probabilite que tous les echantillons evitent la region retenue est de `0.5^30 = 0.0000000009313225746` ; la probabilite de detection est donc de `99.9999999069%`. Ce resultat ne garantit pas le service de PeerDAS en production ni celui d'un autre reseau : des pairs correles, un echantillonnage biaise, les parametres de codage et les attaques adaptatives le modifient.
- **Le seuil d'un comite n'equivaut pas a la recuperabilite actuelle.** Un comite DA hypothetique exige des signatures `5-of-7`. Si trois membres sont indisponibles, il n'en reste que `4` ; aucun nouveau certificat a seuil ne peut donc etre forme. Un ancien certificat comportant `5 signatures` prouve que le seuil a atteste selon ses propres regles ; il ne prouve ni qu'un utilisateur donne peut maintenant recuperer les octets, ni que l'execution etait valide, ni que le reglement est finalise.
## Risques
- Examiner une chaine, un lot, un blob, un espace de noms ou une version du protocole incorrects.
- Confondre un engagement ou un certificat avec les octets sous-jacents.
- Assimiler une recuperation actuelle depuis un seul point d'acces a une disponibilite a l'echelle du protocole.
- Assimiler la disponibilite des donnees a une preuve de validite de l'execution.
- Assimiler la disponibilite ou la validite a la finalite du consensus.
- Se referer a un bloc de reglement perime, non sur ou reorganise.
- Manquer la fenetre de conservation du protocole avant de recuperer les donnees.
- Dependre d'une seule archive, d'un seul snapshot, indexeur ou API du projet.
- Accepter un formatage, une compression ou un codage d'effacement mal formes.
- Ne pas verifier le hachage, la preuve KZG ou un autre engagement.
- Echantillonner trop peu de fragments au regard du modele de menace annonce.
- Supposer independants des echantillons, des pairs ou des groupes de conservation qui sont correles.
- Subir une attaque eclipse, une selection biaisee des pairs ou un service selectif.
- Utiliser des parametres d'effacement ou des seuils de reconstruction incompatibles avec le verificateur.
- Dependre d'un comite de disponibilite des donnees collusoire ou indisponible.
- Laisser le contrat de pont ou de reglement accepter un objet plus faible que celui attendu par les utilisateurs.
- Perdre des donnees en raison de leur retention, de la censure du sequenceur ou de trames de lot manquantes.
- Subir un arret, un fork, une reorganisation de la DA ou une mise a niveau incompatible du client.
- Decouvrir que l'inclusion forcee, le repli, la recuperation ou la sortie ne sont pas executables.
- Sous-estimer la capacite, les pics de frais, la surcharge, le cout des archives ou la fin des subventions.
## Idees recues
- Une preuve de validite supprime le besoin de disponibilite des donnees.
- Un engagement ou une preuve KZG prouve que tous les octets etaient recuperables.
- Une inclusion finalisee signifie que les donnees restent recuperables en permanence.
- Les etiquettes on-chain, blob, DA dediee ou echantillonnage procurent automatiquement la meme securite.
- Un plus grand nombre d'echantillons ou un cout inferieur suffit a prouver la superiorite d'une architecture DA.
## Sujets connexes
- [Blockchain modulaire](/fr/crypto/modular-blockchain/)
- [Rollup](/fr/crypto/rollup/)
- [ZK Rollup](/fr/crypto/zk-rollup/)
## Sources
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consulte le 2026-08-12)
- [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org (consulte le 2026-08-12)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consulte le 2026-08-12)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consulte le 2026-08-12)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (consulte le 2026-08-12)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (consulte le 2026-08-12)
- [Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities](https://arxiv.org/abs/1809.09044) - arXiv (consulte le 2026-08-12)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (consulte le 2026-08-12)
Source: https://wiki.fcontext.com/fr/crypto/data-availability/index.mdx