Skip to content

MODÈLE DE MENACE

Ce que Beyul est conçu pour protéger, et ce qui reste en dehors du prototype actuel.

Beyul est une chaîne de paiement axée sur la confidentialité en phase de recherche. Cette page décrit la posture de sécurité visée et les limites du prototype actuel sans les présenter comme des garanties auditées.

Prototype de recherche · pas de testnet · pas de mainnet · non audité · pas une confidentialité de niveau production · non sûr pour des fonds

Protégé par conception

  • L’activité des transactions devrait être privée par défaut plutôt que visible pour le réseau public.
  • La divulgation devrait être contrôlée par des clés détenues par l’utilisateur, et non par l’opérateur du réseau ni par l’équipe Beyul.
  • La divulgation sélective ne devrait révéler que les champs requis au réviseur prévu, dans un but défini.
  • L’autorité de consultation devrait rester distincte de l’autorité de dépense.

Risques de la divulgation sélective

  • Une divulgation partagée peut exposer au destinataire un contexte commercial ou personnel sensible.
  • Des divulgations répétées peuvent créer une série temporelle qui révèle plus qu’une seule preuve ne le suggère.
  • Les preuves de solde minimal peuvent exposer la capacité financière et créer un risque de coercition.
  • Les artefacts de divulgation devraient être envoyés par des canaux distincts lorsque à la fois un lien et un code sont requis.

Limites du prototype actuel

  • Les montants de dépôt et de retrait peuvent encore être publics dans la limite du prototype actuel.
  • La vérification de divulgation côté serveur n’est pas encore présentée comme prête pour la production.
  • Le protocole et l’implémentation n’ont pas achevé d’audit externe indépendant.
  • Aucun mainnet, testnet, token sale, cotation sur une plateforme d’échange ni adoption institutionnelle n’est revendiqué.

Hypothèses opérationnelles

  • Les utilisateurs doivent protéger leur matériel de récupération et l’accès à leur appareil local.
  • Les validateurs et les opérateurs d’infrastructure exigeront des normes opérationnelles documentées avant une participation plus large.
  • Les futures versions publiques devraient inclure des instructions de compilation reproductibles, les limitations connues et des résumés de couverture des tests.
  • Les affirmations de sécurité ne devraient être mises à jour que lorsque l’état de l’implémentation et de la revue change.
Retour à la page d’accueil