Ir para o conteúdo
Financial Context Wiki

Disponibilidade de dados

Guia orientado à verificação de publicação, recuperabilidade, compromissos, validade, finalidade, amostragem, retenção, arquivos, derivação de rollups e recuperação executável.

Atualizado

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

Resposta direta

Disponibilidade de dados significa que dados suficientes definidos pelo protocolo são publicados e podem ser obtidos, dentro da janela exigida, para que os participantes previstos verifiquem, derivem ou reconstruam o estado relevante. O objeto exigido pode ser entradas de transações, diferenças de estado, partes codificadas ou outro formato de lote definido; não é simplesmente um site, endpoint RPC ou API do projeto estar online.

Quatro afirmações devem permanecer separadas. Disponibilidade diz respeito à publicação tempestiva aos consumidores do protocolo. Recuperabilidade trata de uma parte específica conseguir obter os bytes agora ou depois. Validade trata de a transição de estado obedecer às regras ou restrições da prova. Finalidade trata de o consenso ainda poder substituir o compromisso durante a operação normal. Compromisso vinculante, prova KZG, prova de validade ou inclusão finalizada não comprovam sozinhos as quatro afirmações; disponibilidade temporária não é arquivamento permanente.

Como funciona

  1. Defina a afirmação antes de medi-la: lote, blob, namespace ou objeto codificado exatos; protocolo e versão; consumidor previsto; tarefa exigida de derivação, verificação ou saída; janelas de disponibilidade, contestação e recuperação. Dados completos significa dados suficientes segundo esse protocolo, não cópia indefinida de toda transação.
  2. Fixe o caminho e as evidências de publicação: chain de settlement, chain DA dedicada, calldata, sidecar do blob, compromisso externo ou certificado de comitê; identificadores de bloco, slot e lote; codificação e compressão; compromisso; e contrato ou ponte que o consome. Publicação em um local não prova que outro verificador a confira.
  3. Teste vinculação e reconstrução separadamente. Obtenha os bytes sem a API do projeto, verifique hash, KZG ou outro compromisso e referência de inclusão, valide framing e codificação de apagamento, decodifique o lote e reproduza as entradas necessárias à derivação do estado. Compromisso válido sem bytes não é reconstrução bem-sucedida.
  4. Mapeie o modelo de aceitação. Registre se full nodes baixam o objeto, light nodes amostram partes autenticadas, validadores têm deveres de custódia ou comitê DA assina certificado de limiar. Declare premissas de amostragem, apagamento, independência de peers, limiar, stake, chaves e eclipse e o que o contrato de settlement ou ponte realmente verifica.
  5. Acompanhe estados e relógios distintos: enviado, incluído, disponível na janela do protocolo, recuperável por clientes independentes, decodificado ou derivado, válido em execução, seguro, finalizado e arquivado. Uma prova de validade pode comprovar computação restrita enquanto dados para derivação ou operação independente continuam indisponíveis.
  6. Meça retenção, inicialização e economia. Registre mínimo de serviço do protocolo, poda, provedores de arquivo e snapshot, requisitos de novos nós, bytes brutos e codificados, overhead, preço unitário, custos de prova e transação, limites de capacidade, subsídios e custos de fallback. Recuperação de longo prazo é dependência adicional após a DA temporária expirar.
  7. Ensaie falhas. Teste retenção indevida, serviço seletivo, amostras correlacionadas ou eclipsadas, perda do comitê, parada ou fork de DA, reorganização do settlement, frames ausentes, perda do arquivo, censura do sequenciador e picos de taxas. Verifique parada segura, inclusão forçada, nova tentativa, fallback, reconstrução e saída com software, dados e gas reais, então preserve compromissos, recibos e evidências independentes de arquivo.

Exemplos resolvidos

  • Unidades corretas do custo de dados. Um lote contém 400,000 bytes, cobre 2,000 transactions e custa $0.00002 per byte. A cobrança DA é 400,000 * $0.00002 = $8 per batch, ou $8 / 2,000 = $0.004 per transaction. Se o preço unitário aumentar dez vezes para $0.00020 per byte, o custo será $80 per batch e $0.040 per transaction, não $0.04 per batch. Execução, prova, overhead de transação, arquivamento e margem são excluídos.
  • A janela de serviço do protocolo não promete arquivo. A janela mínima de solicitação da EIP-4844 é 4,096 epochs; com 32 slots per epoch e 12 seconds per slot, isso equivale a 4,096 * 32 * 12 = 1,572,864 seconds, ou 1,572,864 / 86,400 = 18.2044444444 days. É mínimo do protocolo neste modelo, não garantia de que um provedor preserve determinado blob para sempre.
  • Probabilidade estilizada de amostragem. Suponha, apenas num modelo didático, que o atacante oculte 50% das partes expandidas amostradas uniformemente e que 30 amostras autenticadas sejam independentes e com reposição. A probabilidade de todas evitarem a região oculta é 0.5^30 = 0.0000000009313225746, então a probabilidade de detecção é 99.9999999069%. Não é garantia de serviço do PeerDAS nem de outra rede real; peers correlacionados, viés, parâmetros de codificação e ataques adaptativos alteram o resultado.
  • Limiar do comitê não equivale à recuperação atual. Um comitê DA hipotético exige 5-of-7 assinaturas. Se três membros ficarem indisponíveis, restam apenas 4, logo nenhum certificado novo pode ser formado. Um certificado antigo com 5 signatures comprova que o limiar atestou segundo suas regras; não comprova que um usuário recupere os bytes agora, que a execução seja válida ou que o settlement esteja finalizado.

Riscos

  • Inspecionar chain, lote, blob, namespace ou versão de protocolo errados.
  • Confundir compromisso ou certificado com os bytes subjacentes.
  • Tratar recuperação atual de um endpoint como disponibilidade de todo o protocolo.
  • Tratar disponibilidade de dados como prova de validade de execução.
  • Tratar disponibilidade ou validade como finalidade do consenso.
  • Referenciar bloco de settlement obsoleto, inseguro ou reorganizado.
  • Perder a janela de retenção antes de obter os dados.
  • Depender de um arquivo, snapshot, indexador ou API do projeto.
  • Aceitar framing, compressão ou codificação de apagamento malformados.
  • Não verificar hash, KZG ou outro compromisso.
  • Amostrar poucas partes para o modelo de ameaça declarado.
  • Presumir independentes amostras, peers ou grupos de custódia correlacionados.
  • Sofrer ataques eclipse, seleção enviesada de peers ou serviço seletivo.
  • Usar parâmetros de apagamento ou limiares de reconstrução incompatíveis com o verificador.
  • Depender de comitê DA em conluio ou indisponível.
  • Permitir que o contrato de ponte ou settlement aceite objeto mais fraco que o esperado.
  • Perder dados por retenção indevida ou censura do sequenciador ou frames ausentes.
  • Encontrar parada, fork, reorganização ou upgrade de cliente incompatível de DA.
  • Descobrir que inclusão forçada, fallback, recuperação ou saída não é executável.
  • Subestimar capacidade, picos de taxas, overhead, custo de arquivo ou fim de subsídios.

Equívocos comuns

  • Uma prova de validade elimina a necessidade de disponibilidade de dados.
  • Um compromisso ou prova KZG comprova que todos os bytes podiam ser obtidos.
  • Inclusão finalizada significa que os dados continuarão recuperáveis permanentemente.
  • Rótulos on-chain, blob, DA dedicada ou amostragem fornecem automaticamente a mesma segurança.
  • Mais amostras ou custo menor provam isoladamente que um desenho DA é superior.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...