﻿---
title: "Amostragem de disponibilidade de dados (DAS)"
description: "Guia orientado a verificação de amostragem probabilística de disponibilidade, codificação de apagamento, compromissos, PeerDAS, custódia, independência de pares e limites de reconstrução."
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.

# Amostragem de disponibilidade de dados (DAS)

> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

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

## Resposta direta

A amostragem de disponibilidade de dados permite que um nó solicite um subconjunto definido pelo protocolo de unidades autenticadas e codificadas com redundância e formule um juízo probabilístico local sobre se o objeto comprometido foi publicado o suficiente para ser reconstruído. O nó não baixa o objeto completo. Uma amostra bem-sucedida aumenta a confiança apenas sob a codificação, o limiar de reconstrução, a seleção de amostras, a diversidade de pares, o prazo e o modelo adversarial declarados.

Uma prova KZG ou de célula vincula a unidade recebida a um compromisso; não prova que existam unidades restantes em quantidade suficiente. Uma aprovação local não demonstra automaticamente reconstrução em toda a rede, validade da execução, finalidade do consenso, liquidação do rollup, saída do usuário ou arquivamento permanente. PeerDAS é um projeto concreto do Ethereum com colunas, células, grupos de custódia, rede e fork choice específicos da versão.

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

## Como funciona

1. Fixe objeto e especificação: rede, fork, cliente e revisão; slot, raiz do bloco e compromissos dos blobs; dimensões originais e estendidas; definições de célula, linha, coluna e grupo de custódia; decisão local de disponibilidade.
2. Verifique codificação e reconstrução: algoritmo de extensão, compromisso, unidades originais e codificadas, mínimo recuperável e rejeição de extensões inválidas. A amostragem só é significativa se ocultar o suficiente para impedir a reconstrução criar uma região detectável.
3. Defina universo e procedimento: população, conjunto oculto, número de amostras, seleção com ou sem reposição, aleatoriedade, unicidade, custódia, pares, timeout, tentativas e deduplicação. Custódia determinística e amostragem aleatória são evidências distintas.
4. Declare o modelo antes do cálculo. Para fração fixa `f` e `s` amostras uniformes independentes com reposição, `P_miss = (1 - f)^s`. Sem reposição, use a razão de combinações. Pares correlacionados, aleatoriedade enviesada, eclipse, serviço adaptativo e seleção por repetição invalidam o modelo simples.
5. Obtenha dados de pares diversos dentro do prazo. Verifique cabeçalho canônico, inclusão do blob, compromisso, índice, prova KZG e bytes; registre separadamente respostas ausentes, inválidas e tardias. Repetir uma coluna não oferece nova evidência independente.
6. Aplique as regras locais de disponibilidade e fork choice do protocolo; registre separadamente propagação e reconstrução da rede, validade, estados seguro e finalizado, retenção e arquivo. Não amplie uma conclusão local além da garantia do protocolo.
7. Ensaie retenção de dados, codificação incorreta, provas inválidas, ataques eclipse e Sybil, serviço seletivo, amostras correlacionadas, partições, timeouts, pruning, mudanças de parâmetros, reorganização e divergência entre clientes. Reconstrua efetivamente e preserve solicitações, respostas, provas e versões.

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

## Exemplos resolvidos

- **Amostragem independente com reposição.** Em um modelo didático, `50%` das unidades são retidas e o nó faz `30` amostras uniformes independentes. A probabilidade de não detectar é `0.5^30 = 0.0000000009313225746`; a detecção é `99.9999999069%`. Não é garantia operacional do PeerDAS.
- **Meta de probabilidade.** Com `25%` retido e máximo `0.000001`, são necessárias `ceil(log(0.000001) / log(0.75)) = 49` amostras. Com `48`, obtém-se `0.75^48 = 0.0000010067940558701114`, ainda acima; com `49`, `0.75^49 = 0.0000007550955419025835`.
- **Sem reposição.** Há `128` colunas: `64` disponíveis e `64` retidas. Ao selecionar `8` distintas, a probabilidade de evitar as retidas é `C(64,8) / C(128,8) = 0.0030958642767920487`; a detecção é `99.6904135723%`. Isso difere de `0.5^8 = 0.00390625`.
- **Instantâneo Fulu.** Na especificação consultada em `2026-08-12`, `NUMBER_OF_COLUMNS = 128`, `SAMPLES_PER_SLOT = 8`, `NUMBER_OF_CUSTODY_GROUPS = 128` e `CUSTODY_REQUIREMENT = 4`. As frações mínimas são `8 / 128 = 6.25%` e `4 / 128 = 3.125%`. Se o nó custodia `12` grupos e usa o maior entre `8` e `12`, solicita `12 / 128 = 9.375%`. São parâmetros versionados.

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

## Riscos

- Amostrar rede, fork, slot, bloco ou objeto incorretos.
- Confiar em cabeçalho ou compromisso antigo, não canônico ou reorganizado.
- Usar dados com extensão de apagamento incorreta.
- Aceitar prova KZG, de célula ou inclusão inválida.
- Confundir autenticidade do compromisso com disponibilidade.
- Coletar poucas amostras para o modelo de ameaça.
- Misturar fórmulas com e sem reposição.
- Usar aleatoriedade enviesada, previsível ou manipulável.
- Contar duplicatas ou tentativas como amostras independentes.
- Amostrar pares, sub-redes ou custodians correlacionados.
- Sofrer isolamento eclipse ou Sybil.
- Permitir serviço seletivo ou adaptativo após revelar amostras.
- Confundir timeout, congestionamento ou falha do cliente com retenção.
- Confundir custódia determinística com amostragem aleatória.
- Supor fração retida incompatível com o limiar de reconstrução.
- Falhar na reconstrução por limites de CPU, memória, banda ou software.
- Sofrer falhas de gossip, solicitação-resposta, sub-rede ou cross-seeding.
- Extrapolar aprovação local para disponibilidade em toda a rede.
- Confundir DAS com validade, finalidade, liquidação ou saída.
- Ignorar mudanças de retenção, arquivo, fallback, fork, blobs ou parâmetros.

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

## Erros comuns

- Uma amostra bem-sucedida prova a disponibilidade do objeto completo.
- Uma prova KZG ou de célula é, por si só, prova de disponibilidade.
- Mais solicitações sempre fornecem evidências independentes.
- DAS valida a execução e torna a cadeia final.
- Dados disponíveis agora permanecerão arquivados para sempre.

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

## Tópicos relacionados

- [Disponibilidade de dados](/pt-br/crypto/data-availability/)
- [Cliente leve](/pt-br/crypto/light-client/)
- [Rede ponto a ponto](/pt-br/crypto/peer-to-peer-network/)

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

## Fontes

- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (acessado em: 2026-08-12)
- [PeerDAS](https://ethereum.org/roadmap/fusaka/peerdas/) - Ethereum.org (acessado em: 2026-08-12)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [Fulu -- Data Availability Sampling Core](https://ethereum.github.io/consensus-specs/specs/fulu/das-core/) - Ethereum Consensus Specs (acessado em: 2026-08-12)
- [Fulu -- Networking](https://ethereum.github.io/consensus-specs/specs/fulu/p2p-interface/) - Ethereum Consensus Specs (acessado em: 2026-08-12)
- [Fulu -- Fork Choice](https://ethereum.github.io/consensus-specs/specs/fulu/fork-choice/) - Ethereum Consensus Specs (acessado em: 2026-08-12)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (acessado em: 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 (acessado em: 2026-08-12)

Source: https://wiki.fcontext.com/pt-br/crypto/data-availability-sampling/index.mdx
