Als ich zum ersten Mal in der Dokumentation von Newton Protocol die Erwähnung von Rego gesehen habe, bin ich fast einfach daran vorbeigegangen. Politiksprache. Klingt trocken. Klingt nach etwas, das man einmal liest und sofort wieder vergisst.
Dann habe ich mir das genau angesehen und erkannt, dass es tatsächlich eine der interessanteren technischen Entscheidungen ist, die Newton getroffen hat, und dass das Verständnis dafür verändert, wie man darüber denkt, wozu Newtons Compliance-Layer wirklich in der Lage ist.
Was Rego ist und woher es kommt:
Rego ist keine Sache, die Newton erfunden hat. Es ist eine Open-Source-deklarative Policy-Sprache, die von Styra entwickelt wurde und in Unternehmenssoftware über ein Projekt namens Open Policy Agent, oder OPA, weit verbreitet ist. Wenn du mit Cloud-Infrastruktur, Kubernetes-Sicherheit oder Systemen zur Unternehmenszugriffskontrolle gearbeitet hast, besteht eine gute Chance, dass du Rego bereits begegnet bist, ohne unbedingt den Namen zu kennen.
Es wurde für genau einen Zweck gebaut: Regeln auszudrücken und auszuwerten, ob etwas erlaubt sein sollte. Keine Allzweck-Programmierung. Keine Smart-Contract-Logik. Regeln. Bedingungen. Policies.
Genau dieser Fokus macht es im Kontext von Newton so interessant.
Warum eine speziell entwickelte Policy-Sprache wichtig ist:
Das ist der Punkt beim Schreiben von Compliance-Regeln in einer allgemeinen Programmiersprache. Man kann das tun. Entwickler machen das ständig. Aber Allzwecksprachen wurden für allgemeine Zwecke entwickelt. Das bedeutet: Das Schreiben klarer, auditierbarer und wartbarer Compliance-Regeln in ihnen führt häufig zu Code, der schwerer zu lesen, schwerer zu verifizieren und schwerer zu aktualisieren ist – ohne dabei Fehler einzuführen.
Rego ist genau so entworfen, dass Policy-Logik lesbar und überprüfbar ist. Eine in Rego geschriebene Regel soll so aussehen, wie sie gemeint ist. Wenn ein Compliance Officer oder ein Legal-Team oder ein Auditor prüfen muss, welche Regeln tatsächlich durchgesetzt werden, sollten sie die Policy lesen und verstehen können, ohne Logik aus allgemeinem Code rückwärts entwickeln („reverse engineer“) zu müssen.
Das ist in einem Compliance-Kontext von enormer Bedeutung, in dem die Menschen, die verstehen müssen, welche Regeln existieren, nicht immer Entwickler sind.
So sieht das für Newton konkret aus:
Die Policy-Engine von Newton ermöglicht es Entwicklern, Compliance-Regeln in Rego zu schreiben, die vom dezentralen Operator-Netzwerk ausgewertet werden, bevor sich irgendeine Transaktion finalisiert. Ein Sanktions-Check ist eine Rego-Policy. Ein Spend-Limit ist eine Rego-Policy. Eine Anforderung an den Vertragspartner ist eine Rego-Policy. Ein Risk-Threshold, der an Live-Preisdaten von RedStone gekoppelt ist, ist eine Rego-Policy.
Der Entwickler definiert die Regel in Rego. Das Operator-Netzwerk von Newton bewertet eingehende Transaktionen anhand dieser Regel. Das Ergebnis wird als BLS-Attestation zurückgegeben und belegt, dass die Auswertung korrekt abgelaufen ist.
Was ich daran wirklich überzeugend finde, ist die Kombinierbarkeit. Rego-Policies können geschichtet und kombiniert werden. Eine einzelne Transaktion kann gleichzeitig gegen eine Sanktions-Policy, eine Spend-Limit-Policy und eine Risk-Threshold-Policy ausgewertet werden. Unterschiedliche Policies können von verschiedenen Teams geschrieben und zu einem umfassenden Compliance-Framework zusammengeführt werden.
Für ein Protokoll, das institutionelle Nutzer mit komplexen, mehrschichtigen Compliance-Anforderungen versorgt, ist diese Kombinierbarkeit entscheidend. Du bist nicht an die Regeln gebunden, die das Protokoll ausgeliefert hat. Du schreibst die Regeln, die du tatsächlich brauchst.
Der Enterprise-Aspekt, der meiner Meinung nach wichtiger ist, als ihm Anerkennung zuteilwird:
Hier ist etwas, das man unbedingt verstehen sollte: Warum Newtons Entscheidung für Rego, speziell, für die institutionelle Einführung bedeutsam ist.
Enterprise-Software-Teams kennen Rego bereits. Es wird in Kubernetes Admission Control eingesetzt, in Cloud-Sicherheitsplattformen und in Enterprise-Access-Management-Systemen. Ein Compliance- oder Security Engineer in einer regulierten Institution, der gebeten wird, die Policy-Ebene von Newton zu prüfen, muss keine neue Sprache lernen. Er schaut auf etwas, das in seiner Welt bereits existiert.
Das ist keine bloße Bequemlichkeit. Die Einführung von institutioneller Technologie beinhaltet Sicherheitsüberprüfungen, Compliance-Überprüfungen und Rechtsüberprüfungen. Jedes unbekannte Bauteil im Stack ist ein Gespräch, das geführt werden muss, ein Risiko, das bewertet werden muss, eine Verzögerung im Prozess der Einführung. Eine etablierte, geprüfte und weithin verstandene Policy-Sprache nimmt eines dieser Gespräche weg.
Newton versucht, Infrastruktur zu sein, mit der regulierte Institutionen tatsächlich arbeiten können. Rego statt einer selbst erfundenen proprietären Policy-Sprache zu wählen ist ein konkretes Beispiel dafür, dass diese Absicht in technischen Entscheidungen sichtbar wird – nicht nur in Marketing-Sprache.
Der Aspekt der Auditierbarkeit:
Ein Punkt, zu dem ich immer wieder zurückkomme, wenn ich an Rego im Compliance-Kontext denke, ist die Art, wie es Prüf- bzw. Nachvollziehbarkeit („Auditability“) handhabt.
Wenn ein Regulator oder Auditor fragt: „Welche Regeln wurden durchgesetzt, als diese Transaktion stattfand?“, lautet die Antwort mit Newton: Hier ist die aktive Rego-Policy, hier ist die BLS-Attestation, die belegt, dass sie ausgewertet wurde, und hier ist der kryptografische Nachweis, dass die Auswertung korrekt ablief. Die Regel ist lesbar. Die Auswertung ist überprüfbar. Der Nachweis liegt onchain.
Das ist ein völlig anderes Prüfungserlebnis als „hier sind unsere internen Protokolle darüber, was unser Compliance-System gesagt hat“. Das eine ist von jedermann überprüfbar. Das andere erfordert, dass man der eigenen Dokumentation der Institution vertraut.
Was das in der Produktion bedeutet:
Mit Newtons Mainnet Beta live und VaultKit für Entwickler verfügbar ist das Schreiben und Bereitstellen von Rego-Policies gegen echte Infrastruktur bereits heute möglich.
Entwickler, die mit OPA vertraut sind, können mit der Policy-Ebene von Newton arbeiten – mit Mustern, die sie bereits kennen. Institutionen, die Newtons Integrationen prüfen, können ihre bestehenden Policy- und Security-Teams einsetzen, um die Regeln zu bewerten, ohne ein neues Paradigma zu lernen. Auditoren können Compliance-Policies lesen, ohne dass ein Entwickler sie erst übersetzen muss.
Das ist eine spürbare Verringerung der Reibung für jeden Stakeholder, der mit der Compliance-Ebene interagieren muss.
Mein ehrliches Fazit:
Die Entscheidung für Rego ist eine dieser Entscheidungen, die keine Schlagzeilen macht, aber dir etwas darüber sagt, wie ein Projekt wirklich denkt. Newton hätte eine proprietäre Policy-Sprache erfinden können. Viele Blockchain-Projekte machen genau das.
Stattdessen haben sie sich für eine etablierte, quelloffene, Enterprise-taugliche Sprache entschieden – mit einem bestehenden Ökosystem, bestehenden Tools und bestehender Vertrautheit in den Institutionen, denen sie dienen wollen.
Das ist eine pragmatische Entscheidung. Eine durchdachte. Und sie macht Newtons Compliance-Ebene für den institutionellen Markt, auf den sie abzielt, nutzbarer, besser auditierbar und glaubwürdiger, als es eine maßgeschneiderte Alternative wäre.
Beim Zuschauen
@NewtonProtocol closely as this develops. $NEWT #Newt @NewtonProtocol