Ich habe heute eine peinlich große Menge Zeit damit verschwendet, ein Python-Skript zu debuggen, das sich einfach nicht ausführen ließ. Ich ging immer davon aus, dass etwas Kompliziertes schiefgelaufen war, um dann festzustellen, dass ich bei einem einzelnen Block die Einrückung verhauen hatte. Eine einzige falsch platzierte Einrückung. Das war’s.
Es ging nicht mal um irgendetwas mit Krypto—nur um ein kleines Trading-Dashboard, das ich gerade für mich selbst baue. Aber nachdem ich stundenlang auf Python gestarrt hatte, konnte ich dieses Gefühl nicht loswerden, dass Programmiersprachen eine bemerkenswerte Fähigkeit haben, einfache Ideen unnötig schwierig wirken zu lassen.
Diese Denkweise setzte sich fort, als ich erneut durch die Dokumentation von Newton Protocol gegangen bin.
Ein Detail, dem ich vorher kaum Beachtung geschenkt hatte, ist mir plötzlich aufgefallen. Die Richtlinien, die Newton antreiben, sind nicht in irgendeiner brandneuen Kryptosprache geschrieben. Sie sind in Rego geschrieben, der Richtliniensprache hinter Open Policy Agent (OPA)—dieselbe Technologie, die seit Jahren Sicherheits- und Governance-Regeln über Kubernetes-Cluster, Cloud-Plattformen, API-Gateways und unternehmensweite Infrastruktur hinweg durchsetzt.
Diese Entscheidung wirkt bedeutender, als sie auf den ersten Blick erscheint.
Viele Krypto-Projekte erfinden domänenspezifische Sprachen, die nur in ihrem eigenen Ökosystem existieren. Newton hat das nicht getan. Stattdessen hat es eine Sprache übernommen, die bereits in Umgebungen getestet wurde, in denen Fehler ernsthafte betriebliche Folgen haben können. OPA hat sich über Jahre in der Produktion bewährt, lange bevor es jemals einen Fuß auf die Blockchain gesetzt hat.
An diesem Ansatz ist etwas Beruhigendes. Statt Entwickler zu bitten, einem weiteren experimentellen Kryptoprimitiv zu vertrauen, baut Newton auf Tools auf, die andernorts bereits Glaubwürdigkeit gewonnen haben.
Je tiefer ich jedoch in Rego selbst eingedrungen bin, desto mehr bemerkte ich ein weiteres Muster.
Unter Cloud-Ingenieuren gibt es einen Witz, der immer wieder aufkommt: Alle finden die Idee von Richtlinien als Code toll, aber nur sehr wenige haben wirklich Spaß daran, Rego zu schreiben.
Der Grund ist nachvollziehbar. Rego ist keine imperative Sprache wie Python oder JavaScript, bei der man eine Abfolge von Schritten beschreibt. Es ist deklarativ. Man beschreibt die Bedingungen, die wahr sein sollen, und die Engine ermittelt die Auswertung. Für Menschen, die noch nie mit logikbasierten Sprachen gearbeitet haben, ist das eine völlig andere Denkweise.
Das lässt mich fragen, ob die technische Herausforderung hier vielleicht nicht die größte ist.
Wenn erfahrene Infrastructure-Engineer Rego regelmäßig als steile Lernkurve beschreiben, was passiert dann, wenn Kryptodeveloper—viele davon verbringen den Großteil ihrer Zeit mit Solidity oder JavaScript—plötzlich erwartet werden, Compliance-Logik darin auszudrücken?
Innerhalb von Newton treffen diese Richtlinien nicht die Entscheidung, ob eine Kubernetes-Bereitstellung einen Sicherheitstest bestehen soll. Sie entscheiden vielmehr, ob Transaktionen die Regeln erfüllen, die von Ausstellern (Issuers) und Kuratoren (Curators) definiert wurden. Ein subtler Logikfehler ist nicht nur eine Unannehmlichkeit; er könnte Aktivitäten freigeben, die eigentlich hätten abgelehnt werden müssen, oder Aktivitäten ablehnen, die eigentlich hätten erlaubt werden können.
Das ist eine ganz andere Dimension der Verantwortung.
Deshalb denke ich, dass die interessanteste Frage nicht die ist, ob Rego technisch in der Lage ist. Nach allem, was man hört, ist es das. Es hat sich bereits in der Unternehmens-Infrastruktur bewährt.
Die Frage ist, ob sie genug zugänglich ist für die Menschen, von denen Newton erwartet, dass sie diese Richtlinien schreiben.
Newtons größere Vision hängt davon ab, dass die Erstellung von Richtlinien zu etwas wird, das Organisationen sich selbstständig zutrauen können, statt auf hart codierte Regeln angewiesen zu sein. Wenn das Verfassen dieser Richtlinien die tiefe Vertrautheit mit einer Sprache erfordert, die viele Ingenieure bereits als wenig intuitiv empfinden, dann könnte nicht Sicherheit, sondern Nutzbarkeit zur echten Einschränkung werden.
Die Entscheidung, Rego statt eine eigene benutzerdefinierte Sprache zu erfinden, erscheint mir als die klügere Weitsicht-Architektur. So wird vermieden, ein komplettes Richtlinien-Ökosystem neu zu erfinden, und man profitiert von Jahren vorhandener Tools und betrieblicher Erfahrung.
Aber Architektur ist nur die halbe Geschichte.
Das Mainnet-Beta ist noch früh, und außerhalb klassischer Cloud-Sicherheitskreise ist die Zahl erfahrener Rego-Entwickler bisher relativ klein. Ich habe noch nicht viel darüber gesehen, wie Newton die Erstellung von Richtlinien für kryptonative Builder, die OPA noch nie benutzt haben, einfacher machen will.
Die Technologie hat bereits einen starken Ruf.
Jetzt ist der spannende Teil zu sehen, ob die menschliche Erfahrung irgendwann mitziehen kann.