---
title: "Échantillonnage de disponibilité des données (DAS)"
description: "Guide axé sur la vérification de l’échantillonnage probabiliste, du codage d’effacement, des engagements, de PeerDAS, de la conservation, de l’indépendance des pairs et des limites de reconstruction."
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.
# Échantillonnage de disponibilité des données (DAS)
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
L’échantillonnage de disponibilité des données permet à un nœud de demander un sous-ensemble défini par le protocole d’unités authentifiées et encodées avec redondance, puis de formuler un jugement probabiliste local sur la publication suffisante de l’objet engagé pour permettre sa reconstruction. Le nœud ne télécharge pas l’objet complet. Un échantillon réussi n’accroît la confiance que sous les hypothèses déclarées d’encodage, de seuil de reconstruction, de sélection, de diversité des pairs, de délai et d’adversaire.
Une preuve KZG ou de cellule rattache l’unité reçue à un engagement ; elle ne prouve pas qu’assez d’autres unités existent. Une validation locale ne prouve pas automatiquement la reconstruction à l’échelle du réseau, la validité de l’exécution, la finalité du consensus, le règlement du rollup, la sortie des utilisateurs ou l’archivage permanent. PeerDAS est une conception Ethereum précise dont les colonnes, cellules, groupes de conservation, règles réseau et fork choice dépendent de la version.
## Fonctionnement
1. Fixer l’objet et la spécification : chaîne, réseau, fork, client et révision ; slot, racine du bloc et engagements des blobs ; dimensions originales et étendues ; définitions de cellule, ligne, colonne et groupe de conservation ; décision locale requise.
2. Vérifier l’encodage et la reconstruction : algorithme d’extension, engagement, unités originales et encodées, minimum récupérable et rejet des extensions mal formées. L’échantillonnage n’est pertinent que si retenir assez d’unités pour bloquer la reconstruction crée une région détectable.
3. Définir univers et procédure : population, ensemble retenu, nombre d’échantillons, sélection avec ou sans remise, source aléatoire, unicité, conservation, pairs, timeout, nouvelles tentatives et déduplication. Conservation déterministe et échantillonnage aléatoire constituent des preuves distinctes.
4. Déclarer le modèle avant le calcul. Pour une fraction fixe `f` et `s` échantillons uniformes indépendants avec remise, `P_miss = (1 - f)^s`. Sans remise, employer le rapport des combinaisons. Pairs corrélés, hasard biaisé, attaque eclipse, service adaptatif et sélection par nouvelle tentative invalident le modèle simple.
5. Récupérer auprès de pairs divers dans le délai. Vérifier en-tête canonique, inclusion du blob, engagement, indice, preuve KZG et octets ; enregistrer séparément réponses absentes, invalides et tardives. Répéter une colonne ne constitue pas une nouvelle preuve indépendante.
6. Appliquer les règles locales de disponibilité et de fork choice ; enregistrer séparément propagation et reconstruction du réseau, validité, états sûr et finalisé, conservation et archivage. Ne pas étendre une conclusion locale au-delà de la garantie du protocole.
7. Simuler rétention des données, mauvais encodage, preuves invalides, attaques eclipse et Sybil, service sélectif, échantillons corrélés, partitions, timeouts, élagage, changement des paramètres, réorganisation et désaccord des clients. Reconstruire effectivement et conserver requêtes, réponses, preuves et versions.
## Exemples détaillés
- **Échantillonnage indépendant avec remise.** Dans un modèle pédagogique, `50%` des unités sont retenues et le nœud effectue `30` tirages uniformes indépendants. La probabilité de non-détection vaut `0.5^30 = 0.0000000009313225746` ; celle de détection est `99.9999999069%`. Ce n’est pas une garantie opérationnelle de PeerDAS.
- **Objectif probabiliste.** Avec `25%` retenu et un maximum de `0.000001`, il faut `ceil(log(0.000001) / log(0.75)) = 49` échantillons. Avec `48`, `0.75^48 = 0.0000010067940558701114` reste supérieur à l’objectif ; avec `49`, on obtient `0.75^49 = 0.0000007550955419025835`.
- **Sans remise.** Sur `128` colonnes, `64` sont disponibles et `64` retenues. En tirant `8` colonnes distinctes, la probabilité d’éviter toutes les colonnes retenues vaut `C(64,8) / C(128,8) = 0.0030958642767920487` ; la détection est `99.6904135723%`. Ce résultat diffère de `0.5^8 = 0.00390625`.
- **Instantané Fulu.** Dans la spécification consultée le `2026-08-12`, `NUMBER_OF_COLUMNS = 128`, `SAMPLES_PER_SLOT = 8`, `NUMBER_OF_CUSTODY_GROUPS = 128` et `CUSTODY_REQUIREMENT = 4`. Les parts minimales sont `8 / 128 = 6.25%` et `4 / 128 = 3.125%`. Si le nœud conserve `12` groupes et retient le maximum entre `8` et `12`, il demande `12 / 128 = 9.375%`. Ces paramètres sont versionnés.
## Risques
- Échantillonner la mauvaise chaîne, le mauvais réseau, fork, slot, bloc ou objet.
- Faire confiance à un en-tête obsolète, non canonique ou réorganisé.
- Utiliser des données dont l’extension par codage d’effacement est incorrecte.
- Accepter une preuve KZG, de cellule ou d’inclusion invalide.
- Confondre authenticité de l’engagement et disponibilité.
- Collecter trop peu d’échantillons pour le modèle de menace.
- Confondre les formules avec et sans remise.
- Employer un hasard biaisé, prévisible ou manipulable.
- Compter doublons ou nouvelles tentatives comme indépendants.
- Échantillonner des pairs, sous-réseaux ou groupes corrélés.
- Subir un isolement par attaque eclipse ou Sybil.
- Permettre un service sélectif ou adaptatif après le choix.
- Confondre timeout, congestion ou panne du client avec rétention.
- Confondre conservation déterministe et échantillonnage aléatoire.
- Supposer une fraction retenue incompatible avec le seuil de reconstruction.
- Échouer à reconstruire par limite de calcul, mémoire, bande passante ou logiciel.
- Subir une panne de gossip, requête-réponse, sous-réseau ou cross-seeding.
- Extrapoler une validation locale à une disponibilité globale.
- Confondre DAS avec validité, finalité, règlement ou sortie.
- Ignorer les changements de conservation, archive, repli, fork, blobs ou paramètres.
## Idées reçues
- Un échantillon réussi prouve la disponibilité de l’objet complet.
- Une preuve KZG ou de cellule constitue à elle seule une preuve de disponibilité.
- Davantage de requêtes fournit toujours des preuves indépendantes.
- DAS valide l’exécution et rend la chaîne définitive.
- Les données disponibles maintenant resteront archivées définitivement.
## Sujets connexes
- [Disponibilité des données](/fr/crypto/data-availability/)
- [Client léger](/fr/crypto/light-client/)
- [Réseau pair à pair](/fr/crypto/peer-to-peer-network/)
## Sources
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consulté le 2026-08-12)
- [PeerDAS](https://ethereum.org/roadmap/fusaka/peerdas/) - Ethereum.org (consulté le 2026-08-12)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consulté le 2026-08-12)
- [Fulu -- Data Availability Sampling Core](https://ethereum.github.io/consensus-specs/specs/fulu/das-core/) - Ethereum Consensus Specs (consulté le 2026-08-12)
- [Fulu -- Networking](https://ethereum.github.io/consensus-specs/specs/fulu/p2p-interface/) - Ethereum Consensus Specs (consulté le 2026-08-12)
- [Fulu -- Fork Choice](https://ethereum.github.io/consensus-specs/specs/fulu/fork-choice/) - Ethereum Consensus Specs (consulté le 2026-08-12)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consulté 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 (consulté le 2026-08-12)
Source: https://wiki.fcontext.com/fr/crypto/data-availability-sampling/index.mdx