Kein zufälliges Feature-Bündel. Drei unabhängige, hardcodierte Module, jedes eine gezielte Antwort auf den stärksten Angriff, den ein kritischer Aufsichtsrat, ein Wirtschaftsprüfer oder ein gegnerischer Anwalt gegen diese Architektur vorbringen könnte.
LOFSL steht für Legal Oriented Formal Specification Language, eine domänenspezifische Sprache, in der Rechtsregeln formal beschrieben werden. Der Compiler erzeugt aus einer Regel ein maschinenprüfbares Proof-Objekt, das drei Eigenschaften belegt: DETERMINISTIC, keine Zufalls- oder Uhrzeit-Logik. TERMINATION_FREE, keine Schleifen, die Regel terminiert immer. SCOPE_CONFORMANT, jeder Check referenziert einen deklarierten Bereich.
Bislang musste sich ein Vorstand darauf verlassen, dass Entwickler einen juristischen Text korrekt in Code übersetzt haben. Mit LOFSL liegt ein Zertifikat vor, das ein externer Auditor prüfen kann, ohne den gesamten Quellcode zu verstehen.
Ein Beweis, dass ein Check gegen einen bestimmten Wert bestanden wurde, ohne den Wert selbst zu offenbaren. Statt einer vollständigen Zero-Knowledge-Proof (SNARK/PLONK), die native Bibliotheken erfordert und auf einer reinen Serverless-Plattform nicht läuft, verwenden wir ein HMAC-Commitment plus Merkle-Proof, die serverless-konforme Variante mit derselben Datenschutzeigenschaft.
Eine Bank muss gegenüber einer Gegenbank nachweisen, dass der wirtschaftlich Berechtigte einer Gesellschaft nicht auf einer Sanktionsliste steht, ohne den Namen preiszugeben, es sei denn, ein Gericht ordnet die Offenlegung an. Bisher gab es nur zwei schlechte Wege: den Namen offenbaren, oder nur „Prüfung bestanden
Die Gegenbank sieht: ein Commitment, das Prädikat, das Ergebnis, einen gültigen Merkle-Beweis. Kein Name. Würde ein Gericht die Offenlegung anordnen, müsste ein 3-von-5-Shamir-Quorum die Freigabe erteilen, erst dann wird das Salz veröffentlicht und der Commitment auflösbar. Ohne Quorum bleibt die PII versiegelt, selbst Plattform-Administratoren können den Wert nicht rekonstruieren.
Ein periodischer Dienst, der die Merkle-Root aller versiegelten Receipts über mehrere unabhängige, nicht-US-Jurisdiktions-Witnesses verankern soll. Bislang lag die Beweiskette rein intern, in der Datenbank der Plattform selbst. Ein Kritiker könnte argumentieren: die Plattformbetreiber könnten die Logs nachträglich manipulieren. Externe, unabhängige Verankerung soll dieses Argument schließen.
Nicht-US-Jurisdiktionen sind bewusst gewählt: Der US Cloud Act erlaubt US-Behörden Zugriff auf Daten US-amerikanischer Cloud-Anbieter. Läge die Verankerung bei einem US-Witness, könnte ein US-Behördenzugriff die Beweiskette beeinflussen. Deutschland, Schweiz und Luxemburg als Jurisdiktionen machen die Kette Cloud-Act-resilient, konzeptionell.
Die drei Module sind architektonisch komplementär, jedes schließt ein anderes Argument. Zusammen ergeben sie technische Nachweisbarkeit, datenschutzrechtliche Konformität und forensische Unabhängigkeit, in einer Kombination, die kapital- und know-how-intensiv zu kopieren ist.