Der 处暑 (Spät-Herbst): Ein Freund, der bei der Ethereum Foundation an formaler Verifikation arbeitet, kam in mein Atelier, um Tee zu trinken. Er beißt sich gerade richtig fest an der logischen Korrektheit von Governance-Contracts auf der Chain – mit TLA+ und Coq, zwei Beweis-Sprachen, die ich nicht einmal flüssig buchstabieren kann. In der Mitte des Gesprächs stellte er plötzlich die Teetasse auf den Tisch und sagte einen Satz, den ich so nicht erwartet hatte.
„Weißt du, welche Art von Entwickler ich jetzt am meisten beneide? Die, die Rego-Strategien schreibt.“
Ich war kurz perplex. Rego ist die Programmiersprache, die Newton verwendet hat, um Compliance-Strategien zu formulieren; im Whitepaper wurde in Abschnitt 7.2 auch speziell darauf eingegangen. Es ist eine deklarative Sprache – du sagst einfach, „unter welchen Bedingungen etwas erlaubt ist“, ohne dich darum zu kümmern, „wie es ausgeführt wird“. Das ist ein komplett anderer Kosmos als Solidity, diese Smart-Contract-Sprache, in der man manuell den Zustand und die Kontrollflüsse managen muss, dazu noch die Gas-Tabelle im Blick hat und sich die Finger verkneift.
„Wieso beneidest du?“ fragte ich.
„Weil die Leute, die deklarative Sprachen schreiben, in den ersten drei Monaten so glücklich sind wie ein Trottel. Sie glauben, sie schreiben Regeln, nicht Code. Sie glauben, jeder einzelne Satz, den sie eintippen, ist lesbar, auditierbar und kann vor Gericht als Beweis auf den Tisch gelegt werden.“ Er drehte die Tasse einmal im Kreis, und die Pointe schlug schlagartig um: „Aber ab dem vierten Monat, wenn sie die zehn Regeln zusammen würfeln lassen müssen, um sie laufen zu lassen, nimmt der Albtraum die Decke und zieht sie ihnen weg.“
Er holte einen Laptop aus der Tasche und zog eine Rego-Strategie-Datei hervor, die ich mir ansehen sollte. Das war eine Compliance-Strategie für eine RWA-Emissionsplattform: fünf Module, alles zusammengeschweißt – Sanktions-Screening, KYC-Verifikation, Prüfung „zugelassene Investoren“, Tageslimits und die Nachverfolgung der Mittelherkunft. Jedes Modul für sich genommen war so sauber wie ein Übungsbeispiel aus dem Lehrbuch – wer es liest, fühlt sich wohl. Aber sobald die fünf zusammengefügt waren, begannen die Prioritäten zwischen den Regeln, sich gegenseitig anzubeißen. Eine Adresse liegt gleichzeitig in der Trefferzone am Rand der Sanktionsliste und in den historischen Interaktionen der Whitelist – freigeben oder blocken? Ein Nutzer wird im A-Modul als qualifizierter Investor eingestuft, aber in Modul B ist sein Kredit-Score so niedrig, dass er unter den Schwellenwert fällt – was gilt dann?
„Schau dir das hier an.“ Er zeigte auf einen Ausschnitt mit sieben Ebenen verschachtelter Bedingungsprüfungen – sieben Ebenen, wie eine unterirdische Parkgarage. „Der, der diesen Code geschrieben hat, ist ein Compliance-Prüfer, kein Programmierer. Er hat die ganze Zeit geglaubt, er schreibe nicht Code, sondern eine vollstreckbare Version von Gesetzestexten. Er hackt Rechtssprache ein. Aber Gesetzestexte haben Richter, die in Grauzonen Argumente hin- und herbiegen; es gibt Fallrecht, das in Lücken nachfüllt. Seine Rego-Strategie hat nichts davon. Unklarheit heißt Fehler. Widerspruch heißt Ablehnung. Keine Zwischenzone, keine gerichtliche Auslegung, kein Luftpolster.“
Ich starrte auf diesen Ausschnitt mit sieben Ebenen verschachtelt und merkte plötzlich, dass der Abschnitt „Policy Authoring in Rego“ im Newton-Whitepaper (Abschnitt 7.2) – so elegant wie ein Gedicht – die ganze Branche in eine Falle locken könnte, über die niemand ernsthaft diskutieren will. Wenn die Regeln simpel sind, ist es so elegant, dass man am liebsten den Tisch zusammenschlägt. Wenn die Regeln komplex werden, entgleitet es – ohne auch nur ein Hallo zu sagen.
@NewtonProtocol Das Beispiel aus Abschnitt 7.2 im Whitepaper ist wirklich schön. Zehn bis ein paar Zeilen Code, ein „default allow := false“, ein paar „allow if“-Bedingungen – so geschrieben, dass die Strategie sich liest wie ein englischer Satz; Recht und Entwicklung können gemeinsam vor einem Bildschirm nicken. Das Whitepaper ergänzt sogar eine Passage in der Erklärung zur technischen Auswahl, warum Rego dafür von Natur aus gemacht ist: „Rego is a pure functional language: given the same inputs and rules, evaluation always produces the same result, with no side effects, no external state, and no non-determinism.“ Reine Funktionalität, keine Nebeneffekte, kein externer Zustand, keine Nicht-Deterministik. Gleiche Inputs, gleiche Regeln – das Ergebnis ist immer identisch. Das ist das Fundament für verifizierbare Zero-Knowledge-Beweise, die mathematische Geheimwaffe für den ZK-Challenge-Mechanismus in Abschnitt 9.4. Ohne diese Grundlage lassen sich die ganzen kryptografischen „Pakete“ dahinter nicht fest genug verschnüren.
Aber das ist der Vorteil von Rego. Ein Vorteil heißt nicht, dass es keine schlechten Strategien schreiben kann. Ein Vorteil heißt nicht, dass bei fünf zusammen gedrehten Regelsets die Logik automatisch klar bleibt.
In der klassischen Softwareentwicklung gibt es einen längst veralteten Begriff, „das Gesetz der Erhaltung der Komplexität“: Die Komplexität, die in ein System hineingezimmert ist, ist fest eingeschweißt – sie verdampft nicht einfach, nur weil du die Sprache oder das Framework wechselst. Du kannst sie nur von einem Ort an einen anderen verschieben: entweder aus den Details der Ausführung im Unterbau herausziehen und in die Kombinationsregeln der oberen Ebene einsetzen; oder aus dem expliziten, unvermeidlichen Logik-Gepäck des Zustandsmanagements – das du selbst schreiben musst, das dir in die Augen springt und dem du nicht ausweichen kannst – implizite Abhängigkeiten zwischen Strategien machen, die unter der Oberfläche liegen und kein Wort dazu sagen. Rego versteckt all diese sichtbaren Zustands-Übergangslogiken, die es in Solidity gibt. Entwickler müssen sich dann nicht mehr darum kümmern, „wann sich diese Variable ändert“, „ob diese Schleife das Gas zerbeißt“, oder „ob diese Bedingungsprüfung von der Short-Circuit-Logik ausgetrickst wird“. All das wird dem Rego-Interpreter überlassen, der es dann „kauen“ muss.
Der Preis liegt unter Wasser. Wenn eine Strategie so komplex wird, dass sie über jede Linie klettert – Dutzende Regeln, die sich gegenseitig anziehen; mehrere Datenquellen, die sich querprüfen; mehrere Strategiemodule, die sich wie Babuschkas ineinander verschachteln – dann verliert der Entwickler allmählich ganz sichtbar das Gefühl dafür, was diese Strategie überhaupt entscheidet. Eine Adresse wird zurückgeworfen, und im Log steht nur kalt und knapp „allow-Bedingung erfüllt nicht“. Aber welche Bedingung war nicht erfüllt? Wurde ein Randstück der Sanktionsliste angekratzt? Hat ein KYC-Level um eine halbe Stufe zu niedrig gezündet, sodass man vor der Tür abgewiesen wurde? Oder ist der Eimer der täglichen aufsummierten Limits längst voll? Und wenn alle drei Bedingungen nur gestreift wurden, aber keine einzeln auslöst, dann kommt die finale Ablehnung daher, dass sich drei Pfade an einer Ecke still miteinander verweben – dieses „Falsch“: Wem gehört diese Entscheidung überhaupt?
Im Whitepaper, Abschnitt 7.3, Newton Rego: die kryptografische Erweiterung. In Wahrheit schiebt sie das Problem nur noch einen Schritt weiter nach vorn. Sie packt Dinge, die so komplex sind, dass selbst Kryptografie-Ingenieure mit dem Kopf kratzen: On-Chain-Signaturverifikation, das Umschalten von Cross-Chain-Algorithmen, das Zurückverfolgen von Delegationsketten – alles in die eingebauten Funktionen von Rego. Der Aufruf ist so elegant, dass es süchtig macht: Ein einziger newton.crypto.ecdsa_recover_signer zieht aus einer Signatur die Adresse heraus, und ein newton.crypto.verify_signature prüft die Logik gleich nach dem Algorithmusnamen. Das Whitepaper nennt das „a unified interface for verifying signatures across different blockchain schemes“. So elegant, dass Autoren von Strategien nicht wissen müssen, wie die Parameter der Ellipsenkurve aussehen, nicht wissen müssen, ob die Hash-Funktion SHA-512 oder SHA-256 „bissen“ soll, und nicht diese hartnäckigen Unterschiede zwischen den Kodierungsformaten kennen müssen. Aber so elegant auch, dass die Autoren vielleicht gar nicht merken: Wenn sie genau diese verify_signature, die sie einfach so heranziehen, stillschweigend zwischen Ed25519 und secp256k1 den Kurs wechseln lassen, dann gibt es eine subtile Abzweigung in der zugrunde liegenden Verifikationslogik, die in Extremfällen zwei unterschiedliche „Geschmacksrichtungen“ ausspuckt.
Das ist nicht Regos Narbe, und nicht Newtons Kessel. Es ist die abstrakte Miete, die dieser Himmelsturm von sich aus mitbringt. Je höher man ihn aufbaut, desto niedriger werden die Schwellen, und die Details der Basis werden immer tiefer vergraben. Je tiefer sie vergraben sind, desto schwieriger ist es, das Verhalten intuitiv festzunageln, wenn die Strategie an die Grenzbedingungen gedrückt wird. Formale Verifikation kann wieder ein Stück zurückziehen – genau das macht mein Freund. Aber der Talentpool für formale Verifikation ist flacher als der der Autoren von Rego-Strategien: flach genug, dass man ihn auf der ganzen Welt mit den Fingern abzählen könnte. Ein gerade erst keimendes Ökosystem – wenn man nicht frühzeitig die Verifizierbarkeit und die Auditierbarkeit von Strategien aus dem „später mal“ herauszieht und auf den Tisch stellt, könnte es in fünf Jahren eine Menge Strategie-Module ansammeln, die niemand mehr anzufassen wagt: Sie laufen ganz brav, jeden Tag werden sie zigtausend Mal umgeschaltet, aber niemand kann mit einem Finger auf eine einzige Codezeile zeigen und erklären, woran sie wirklich entscheidet, wo genau die Grenzen liegen, und wo die blinden Flecken verborgen sind.
$NEWT Die Token hocken in genau dieser unangenehmen Ecke, und dort gibt es einen natürlichen kleinen Peitschenknall, der etwas Gleichgewicht schafft. Das Kostenmodell aus Abschnitt 10.1 rechnet im Whitepaper die Ausgaben nach der Anzahl der WASM-Instruktionen ab. Je fetter die Strategie, desto höher die Instruktionszahl, desto dicker die Ausführungsgebühr. Damit hängt über jedem, der Strategien aufbläht, eine natürliche „Komplexitätssteuer“. Wenn die Anwendung neue Module in ein Strategiepakket stopft, muss sie abwägen: Nicht nur steigen die Wartungskosten, auch das Geld, das bei jeder Ausführung aus der Wallet abgebucht wird, steigt mit. Welches Modul mit übermäßiger Verschachtelung, redundanten Prüfungen und überflüssigen Abfragen vollgestopft ist, dessen WASM-Verbrauch wird auf der Gebührenrechnung so heiß wie am Fieber gemessen. Transparente Abrechnung – in gewissem Sinne – peitscht die Strategieautoren sanft an den Fersen der Wirtschaft, zwingt sie, Regeln nicht zu einem Strick zu schreiben, den niemand auseinandernehmen möchte: Aufgeblasenheit wird abgerechnet.
Aber das ist nur die unsichtbare Hand der Wirtschaft, die dir auf die Schulter klopft – nicht der Sicherheitsgurt, den die Technik festschraubt. Ob eine komplexe Strategie am Ende wirklich stimmt, ob das letzte Schloss sitzt, muss am Ende mit formalen Werkzeugen und Audit-Prozessen fest umklammert werden. Die ZK-Verifizierbarkeit aus Newton, Abschnitt 9.4, beweist, dass „die Strategie ehrlich einmal durchgelaufen ist“, nicht dass „die Strategie selbst korrekt geschrieben wurde“. Der erste Beweis ist mathematisch vollständig: Gegeben ist diese Strategie, gegeben ist genau dieser Input-Block – der Output kann nicht falsch sein. Der zweite Beweis ist eine völlig andere, viel schwierigere Schiene: Gegeben ist diese Strategie, und unter allen Inputs, die man hineinstopfen kann, ist der Output dann immer noch aus sicheren Bahnen – also fällt er niemals in eine Falle. Diese Aufgabe kann aktuell nur formale Verifikation knacken. Und formale Verifikation ist noch mindestens zehn Jahre davon entfernt, großflächig ausgerollt zu werden.
Mein Freund, der formale Verifikation macht, ging, während er an der Tür seine Schuhe wechselte. Er ließ nur einen Satz fallen, den ich bis heute im Kopf habe: „Der romantische Teil deklarativer Sprachen ist, dass du glaubst, die Regeln seien so einfach wie Origami. Der brutale Teil ist, dass Regeln untereinander selbstständig anfangen zu streiten – und wenn sie dann streiten, gibt es nicht mal einen Richter, der schlichtet.“
Newton hat Rego eine Ausführungsmaschine gegeben, an der man sich nicht die Zähne ausbeißen kann; eine integrierte Schnittstelle für kryptografische Erweiterungen; und darunter eine Verifizierbarkeit auf Basis von Zero-Knowledge-Beweisen. Aber es hat den Leuten, die sich still an die Strategien setzen, noch nicht „den Scheinwerfer“ mitgegeben, der ihnen die Wege zeigt, wenn die Komplexität Feuer fängt. Vielleicht ist es ein Strategie-Debugger, vielleicht eine formale Verifikationsstruktur für Komponierbarkeit, vielleicht ein Glas, in dem man Konflikte zwischen Regeln farblich markiert, ausrollt und mit einem Blick durchschaut. #Newt
Die Technik rast, und die Leute, die Regeln schreiben, hocken noch am Straßenrand und schwenken eine Taschenlampe in die dunklen Stellen.
Mach deine Recherche selbst. Beim nächsten Mal, wenn du ein Paket mit Compliance-Strategien ausrollst, teste nicht nur im Normalfall „ob es durchgeht“. Drehe alle Module auf, schiebe alle Constraints gleichzeitig bis an den Anschlag, und schleudere dann bewusst eine Ladung schiefen Datenmix hinein – ganz gezielt, um die Ritzen zwischen Regeln zu füttern. Schau, ob es zögert, ob es still wird, ob es in genau der Ecke auftaucht, die du nicht im Blick hattest, und leise die falschen Personen ablehnt – oder die falschen zulässt. Der schlimmste Leak bei einer Transaktion, die durchrutscht, ist oft nicht, dass es zu wenige Regeln gab, um abzufangen, sondern dass es zu viele gab: Sie drücken sich zusammen, spannen einen unscharfen Spalt auf, den niemand erklären kann, wer ihn übernehmen müsste.