Skip to content

MODELO DE AMEAÇAS

O que o Beyul é projetado para proteger, e o que permanece fora do protótipo atual.

O Beyul é uma cadeia de pagamentos com privacidade em fase de pesquisa. Esta página descreve a postura de segurança alvo e os limites do protótipo atual sem apresentá-los como garantias auditadas.

Protótipo de pesquisa · sem testnet · sem mainnet · não auditado · não é privacidade de nível de produção · não é seguro para fundos

Protegido por design

  • A atividade de transações deveria ser privada por padrão, em vez de visível para a rede pública.
  • A divulgação deveria ser controlada por chaves mantidas pelo usuário, não pelo operador da rede nem pela equipe do Beyul.
  • A divulgação seletiva deveria revelar apenas os campos necessários ao revisor pretendido para um propósito definido.
  • A autoridade de visualização deveria permanecer separada da autoridade de gasto.

Riscos da divulgação seletiva

  • Uma divulgação compartilhada pode expor ao destinatário um contexto comercial ou pessoal sensível.
  • Divulgações repetidas podem criar uma série temporal que revela mais do que uma única prova sugere.
  • Provas de saldo mínimo podem expor a capacidade financeira e podem criar risco de coação.
  • Os artefatos de divulgação deveriam ser enviados por canais separados quando tanto um link quanto um código são necessários.

Limites do protótipo atual

  • Os valores de depósito e saque ainda podem ser públicos dentro do limite do protótipo atual.
  • A verificação de divulgação do lado do servidor ainda não é apresentada como pronta para produção.
  • O protocolo e a implementação não concluíram uma auditoria externa independente.
  • Não se afirma nenhum mainnet, testnet, token sale, listagem em exchange ou adoção institucional.

Pressupostos operacionais

  • Os usuários devem proteger o material de recuperação e o acesso ao dispositivo local.
  • Validadores e operadores de infraestrutura exigirão padrões operacionais documentados antes de uma participação mais ampla.
  • Futuras versões públicas deveriam incluir instruções de compilação reproduzíveis, limitações conhecidas e resumos de cobertura de testes.
  • Afirmações de segurança só deveriam ser atualizadas quando o estado de implementação e revisão mudar.
Voltar à página inicial