Gestern Abend saß ich beim Essen mit Oanh, einer sehr wohlhabenden Dame, die ein Restaurant mit Meeresfrüchten aufmacht. Oanh erzählte, dass sie jede Woche ein paar Gerichte in der Speisekarte austauscht.

Ich bin ziemlich überrascht.

"Ist es nicht beängstigend, dass die Kunden da nicht mehr mitkommen, wenn sich das so häufig ändert?"

Oanh schüttelte den Kopf.

"Ich habe das Menü nicht geändert. Ich probiere jedes Mal nur ein neues Gericht. Wenn die Gäste es nicht mögen, lasse ich es einfach. Die Kosten für das Ausprobieren sind so gering, dass ich keinen Grund habe, mich davor zu fürchten, es weiter zu versuchen."

Dieser Satz bringt mich dazu, an den Abschnitt „Testing Policies & Oracles“ in den Docs des Newton Protocol zu denken.

Am Anfang dachte ich nur, dass es sich um einen detaillierteren Testing-Prozess als üblich handelt. Anstatt allgemein zu sagen „testet, bevor ihr deployed“, @NewtonProtocol wird das in sehr klare Schritte aufgeteilt: Unit Tests für die Rego-Policy, das Testen einzelner WASM-Oracles und erst danach die Simulation der gesamten Policy, bevor sie ins Netzwerk gestellt wird.

Aber je mehr ich lese, desto stärker habe ich das Gefühl, dass sie nicht nur den Testing-Prozess umstrukturieren.

Jede Testsuite bringt das Feedback ein kleines Stück früher. Fehler in einer Rego-Policy werden entdeckt, während die Policy noch für sich allein steht. Fehler im WASM-Oracle werden erkannt, bevor das Oracle mit anderen Komponenten zusammengeführt wird. Erst wenn alle einzelnen Teile korrekt funktionieren, wird die gesamte Decision im Schritt „Simulation“ überprüft.

Dadurch ändern sich die Kosten für jeden Versuch vollständig.

Wenn eine Decision falsch ist, muss der Developer nicht erst bis zum nächsten Deployment warten, um es zu wissen. Die meisten Fehler bleiben im Testing-Layer zurück – mit deutlich geringeren Kosten. Eine kleine Änderung zieht nicht mehr gleich einen ganzen Deployment-Zyklus nach sich, nur um zu dem Ergebnis zu kommen, dass die ursprüngliche Idee doch nicht stimmt.

Wenn die Kosten für jeden Versuch sinken, beginnt sich auch das Verhalten der Developer zu verändern.

Wenn jede neue Idee einen langen Deployment-Zyklus erfordert, neigen alle dazu, nur die Optionen auszuwählen, denen sie am meisten vertrauen. Aber wenn das Feedback fast unmittelbar nach jeder Änderung auftaucht, ist es viel weniger riskant, noch eine andere Rego-Policy oder eine andere Decision auszuprobieren. Nicht, weil die Erfolgswahrscheinlichkeit höher wäre, sondern weil die Kosten eines Fehlschlags deutlich gesunken sind.

Erst da wurde mir klar, dass das, was das Newton Protocol schafft, nicht nur ein besserer Testing-Prozess ist.

Sie schaffen für Developer deutlich mehr „Experimental Optionality“.

Jeder kurze Feedback-Zyklus hilft nicht nur dabei, Bugs schneller zu beheben. Er hält auch über den gesamten Entwicklungsprozess hinweg mehr Optionen offen. Eine Idee kann schon sehr früh mit sehr geringen Kosten verworfen werden, während eine andere Idee direkt danach ausprobiert werden kann, ohne das Projekt nennenswert auszubremsen.

Vielleicht ist das genau das, was ich am Newton Protocol spannend finde.

Meistens bewerten wir einen Testing-Prozess danach, wie gut er Fehler findet. Ich sehe den größeren Wert jedoch in der Anzahl der Optionen, die dieser Prozess den Developern hilft zu behalten. Wenn sich jeder Versuch immer günstiger anfühlt, entwickelt sich das System nicht nur schneller weiter, sondern bietet auch mehr Chancen, bessere Decisions zu entdecken. Wenn man das so betrachtet, ist „Experimental Optionality“ vielleicht genau das, was das Newton Protocol still und heimlich optimiert – nicht einfach die Anzahl der Tests oder die Geschwindigkeit des Deployments.

$EVAA $NEWT #Newt