Ir para o conteúdo
Financial Context Wiki

Risco do comite de disponibilidade de dados (DAC)

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.

Atualizado

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

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.

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.

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.

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.

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.

Topicos relacionados

Fontes

Navegação

Pesquisar na wiki...