---
title: "Risco do comite de disponibilidade de dados (DAC)"
description: "Guia orientado a verificacao de atestacoes DAC, regras de aceitacao q-de-n, posse e recuperacao efetivas dos dados, dominios de falha correlacionados, rotacao de chaves, retencao, contingencia e risco de saida."
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.

# Risco do comite de disponibilidade de dados (DAC)

> Somente para fins educacionais; nao constitui recomendacao nem aconselhamento de investimento. Investir pode causar perdas.

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

## Resposta direta

Um comite de disponibilidade de dados e um conjunto limitado de membros cujas assinaturas ou atestacoes podem satisfazer a regra de um protocolo para aceitar uma alegacao de disponibilidade de dados offchain. O certificado prova apenas que o conjunto de chaves e o limiar configurados aceitaram um objeto assinado especifico segundo essas regras. Nao prova, de forma independente, que cada signatario obteve todos os bytes, manteve uma copia duravel, atende usuarios agora, validou a execucao ou tornou final a liquidacao.

Seguranca e vivacidade sao distintas. Se o contrato aceita assinaturas `q-of-n`, o controle de `q` chaves validas pode satisfazer essa regra para um objeto indisponivel, salvo se outra verificacao impedir isso. Menos de `q` signatarios dispostos e acessiveis normalmente nao formam novo certificado; as atualizacoes param ou usam uma contingencia documentada. A recuperacao efetiva tambem depende de verificacoes honestas antes da assinatura, copias independentes, retencao, capacidade de atendimento, historico de chaves e governanca e software executavel de reconstrucao e saida.

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

## Como funciona

1. Fixe a implantacao: rede, modo e versao do protocolo, contratos de liquidacao e verificacao de disponibilidade, lote e objeto de dados, codificacao, compromisso, conjunto de chaves, limiar `q`, numero de membros `n`, signatarios obrigatorios, ativacao, expiracao, revogacao e autoridade de governanca.
2. Reconstrua a alegacao assinada exata e a logica de aceitacao. Verifique dominio, vinculo a rede e contrato, identificador do lote, compromisso ou raiz de estado, expiracao, bitmap ou agregacao de signatarios, protecao contra replay e calculo efetivo do limiar no contrato. Logotipo de membro ou resposta de API nao e regra de aceitacao.
3. Exija que cada membro obtenha o objeto completo antes de assinar, verifique compromisso e codificacao, decodifique-o e preserve os dados necessarios a derivacao independente do estado ou a saida do usuario. Registre o que os membros atestam e se o protocolo consegue provar que essas verificacoes ocorreram.
4. Mapeie dominios de falha independentes, em vez de contar nomes. Identifique pessoas juridicas, controle beneficiario, contas e regioes de nuvem, DNS e rede, software e bancos de dados, custodia de chaves, armazenamento, operacoes e jurisdicao. Espelhos ou endpoints sob o mesmo plano de controle nao sao membros independentes.
5. Teste posse e recuperacao. Obtenha lotes recentes e historicos de varios membros sem a API do operador, verifique hashes e raizes, reconstrua o estado ou uma prova de saque, meca retencao e transferencia e separe producao do certificado, recuperacao atual, validade da execucao, finalidade do consenso e durabilidade do arquivo.
6. Exercite ciclo de vida e recuperacao: rotacao de membros e chaves, conjuntos historicos, expiracao e revogacao, disponibilidade abaixo do limiar, comprometimento de chaves, atendimento seletivo, indisponibilidade do operador, contingencia com dados completos, modo de congelamento ou escape, inclusao forcada, arquivos independentes e gas e tempo reais para sair.
7. Monitore bitmaps aceitos, atraso do certificado, sucesso da recuperacao, integridade dos bytes, idade do armazenamento, mudancas de conjunto e limiar, upgrades, pausas e capacidade de contingencia. Arquive certificados, dados e estado contratual e pare de aumentar a exposicao quando certificados forem aceitos, mas a recuperacao independente deixar de funcionar.

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

## Exemplos resolvidos

- **Vivacidade e seguranca do limiar nao sao iguais.** Em um comite didatico `5-of-7`, dois membros indisponiveis deixam `5` signatarios e ainda permitem novo certificado; tres deixam `4`, portanto `4 < 5` e a producao para sem uma contingencia documentada. Por outro lado, controlar `5` chaves aceitas satisfaz o limiar; o certificado ainda nao prova recuperacao atual dos bytes nem validade da execucao.
- **Modelo de disponibilidade independente.** Suponha, apenas como modelo IID didatico, que cada um dos `7` membros esteja disponivel independentemente com probabilidade `0.95` e que o certificado exija ao menos `5`. Entao `P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570`, logo a probabilidade modelada de parada e `1 - 0.9962429570 = 0.0037570430`. Dependencias comuns de nuvem, software, operador, regime juridico ou chaves invalidam a estimativa binomial.
- **Copias armazenadas e atendimento sao separados.** Um lote tem `120 MB`. Sete copias completas independentes armazenariam `120 * 7 = 840 MB`; se apenas tres membros persistirem o lote, o volume armazenado sera `120 * 3 = 360 MB`, mesmo que cinco chaves tenham assinado. Servir o objeto uma vez a `100 clients` transfere `120 * 100 = 12,000 MB`; numero de assinaturas nao e numero de copias nem medida de capacidade de transferencia.
- **Limiar de reconstrucao.** Um objeto didatico tem `1,024 records` divididos em `16 chunks` de `64 records`, com limiar declarado de recuperacao de `12 chunks`. Onze fragmentos expoem `11 * 64 = 704 records`, mas `11 < 12`; o objeto nao pode ser reconstruido por essa regra. Um certificado valido nao substitui fragmento ausente nem altera o limiar.

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

## Riscos

- Inspecionar rede, contrato, implantacao, lote ou versao errados.
- Reconstruir incorretamente alegacao, dominio, compromisso ou expiracao.
- Aceitar replay entre redes, contratos, versoes ou conjuntos historicos.
- Usar conjunto de chaves invalido, antigo, expirado ou revogado.
- Interpretar mal `q`, `n`, signatarios obrigatorios, bitmaps ou assinaturas agregadas.
- Exploracao de falha no signatario ou na verificacao contratual.
- Assinar antes de obter, verificar e persistir todos os dados.
- Aceitar dados parciais, malformados ou codificados incorretamente.
- Perder seguranca por comprometimento ou conluio das chaves de limiar.
- Perder vivacidade porque menos membros que o limiar conseguem assinar.
- Contar entidades, nuvens, regioes ou operadores correlacionados como independentes.
- Compartilhar planos de controle de DNS, TLS, software, banco de dados ou armazenamento.
- Sofrer ataque eclipse, atendimento seletivo ou dependencia de gateway privado.
- Excluir ou podar dados apos assinar ou antes do fim da janela de saida.
- Romper recuperacao historica por mudanca de membros ou rotacao de chaves.
- Permitir que a governanca substitua membros, reduza o limiar ou ignore atrasos.
- Referenciar compromisso de liquidacao antigo, inseguro ou reorganizado.
- Tratar prova de validade ou raiz finalizada como recuperacao atual dos dados.
- Descobrir que contingencia, congelamento, inclusao forcada ou saida nao e executavel.
- Subestimar armazenamento, transferencia, recuperacao, contingencia, taxas ou capacidade.

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

## Erros comuns

- Mais membros significam automaticamente mais dominios de falha independentes.
- `q` assinaturas provam que existem `q` copias completas duraveis e publicamente recuperaveis.
- Uma prova de validade elimina a necessidade de verificar a disponibilidade do DAC.
- Certificado antigo valido garante recuperacao atual e arquivo permanente.
- Um membro honesto ou oficial garante que todo usuario sempre consiga sair.

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

## Topicos relacionados

- [Disponibilidade de dados](/pt-br/crypto/data-availability/)
- [Rollup](/pt-br/crypto/rollup/)
- [Finalidade](/pt-br/crypto/finality/)

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

## Fontes

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

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