Skip to content

BEDROHUNGSMODELL

Was Beyul schützen soll und was außerhalb des aktuellen Prototyps verbleibt.

Beyul ist eine Privatsphäre-Zahlungskette im Forschungsstadium. Diese Seite beschreibt die angestrebte Sicherheitslage und die Grenzen des aktuellen Prototyps, ohne sie als geprüfte Garantien darzustellen.

Forschungsprototyp · kein Testnet · kein Mainnet · nicht auditiert · keine Privatsphäre auf Produktionsniveau · nicht sicher für Geldmittel

Durch Design geschützt

  • Transaktionsaktivität sollte standardmäßig privat sein, statt für das öffentliche Netzwerk sichtbar zu sein.
  • Die Offenlegung sollte durch vom Nutzer gehaltene Schlüssel gesteuert werden, nicht durch den Netzwerkbetreiber oder das Beyul-Team.
  • Die selektive Offenlegung sollte nur die erforderlichen Felder dem vorgesehenen Prüfer für einen definierten Zweck offenlegen.
  • Die Einsichtsbefugnis sollte von der Ausgabebefugnis getrennt bleiben.

Risiken der selektiven Offenlegung

  • Eine geteilte Offenlegung kann dem Empfänger sensible kommerzielle oder persönliche Zusammenhänge preisgeben.
  • Wiederholte Offenlegungen können eine Zeitreihe erzeugen, die mehr enthüllt, als ein einzelner Nachweis nahelegt.
  • Mindestguthaben-Nachweise können die finanzielle Leistungsfähigkeit offenlegen und ein Nötigungsrisiko schaffen.
  • Offenlegungsartefakte sollten über getrennte Kanäle gesendet werden, wenn sowohl ein Link als auch ein Code erforderlich sind.

Grenzen des aktuellen Prototyps

  • Einzahlungs- und Auszahlungsbeträge können innerhalb der Grenze des aktuellen Prototyps noch öffentlich sein.
  • Die serverseitige Offenlegungsprüfung wird noch nicht als produktionsbereit dargestellt.
  • Protokoll und Implementierung haben kein unabhängiges externes Audit abgeschlossen.
  • Es wird kein Mainnet, Testnet, token sale, keine Börsennotierung und keine institutionelle Übernahme behauptet.

Betriebliche Annahmen

  • Nutzer müssen Wiederherstellungsmaterial und den Zugriff auf das lokale Gerät schützen.
  • Validatoren und Infrastrukturbetreiber werden vor einer breiteren Teilnahme dokumentierte Betriebsstandards benötigen.
  • Künftige öffentliche Releases sollten reproduzierbare Build-Anweisungen, bekannte Einschränkungen und Zusammenfassungen der Testabdeckung enthalten.
  • Sicherheitsaussagen sollten nur aktualisiert werden, wenn sich der Implementierungs- und Prüfstatus ändert.
Zurück zur Startseite