Ich habe gerade meine Notizen von diesem Wochenende fertig durchgesehen, und ein Detail lässt mich nicht los. Ich habe eine Transaktion über N ewtons Pre-Transaction-Enforcement-Flow getestet, also den Teil, bei dem eine Policy-Prüfung erst durch sein muss, bevor überhaupt etwas zur Ruhe kommt. Es ist nichts kaputtgegangen. Es saß einfach ein paar Sekunden länger da, als würde es auf etwas warten, das ich nicht sehen konnte.
Meine erste Einschätzung war einfach: Vielleicht war der Operator-Node, der meine Anfrage bearbeitet hat, in genau dieser Minute nur langsam. Netzwerk-Stau, ganz normales Zeug. Diese Annahme wirkte plausibel—bis ich aktualisiert habe und gesehen habe, dass derselbe Node fast augenblicklich auf die Transaktion von jemand anderem geantwortet hat, mitten in meiner Wartezeit.
Das war die erste Unstimmigkeit. Wenn es reines Laden (Pure Load) gewesen wäre, hätte die Verzögerung jeden getroffen, der dorthin geroutet wurde—nicht nur mich.
Also habe ich angefangen mir Gedanken darüber zu machen, was zwischen „Ich sende eine Transaktion“ und „sie wird auf Newton abgewickelt (settles)“ wirklich passieren muss. Das ist kein einziger Schritt. Es ist: Anfrage → Routing zu einem verfügbaren Operator → Policy-Auswertung anhand der OPA/Rego-Regeln, die an diesen Transaktionstyp gekoppelt sind → Verifikation über den zk-Beweis → Settlement onchain. Jeder dieser Schritte ist eine eigene Stelle, an der Dinge stillstehen können, und von außen sehen sie alle identisch aus: „pending“ (ausstehend).
Genau das ist der Punkt, zu dem ich immer wieder zurückkomme. Präsenz im Netzwerk ist nicht dasselbe wie Zuverlässigkeit für eine konkrete Anfrage. Ein Operator kann online sein, gestakt (staked) und technisch Teil des AVS-Sets, und trotzdem nicht der schnellste oder bereitwilligste Responder für deine spezifische Policy-Prüfung. Verifikation ist auch kein Vertrauen—sie ist nur der Beleg, dass eine Regel korrekt ausgewertet wurde, nicht dass sie schnell ausgewertet wurde.
Das versteckte Element, das ich vorher nicht wirklich bedacht hatte, ist die Anreizstruktur der Operatoren. Das sind durch EigenLayer neu gestakte Nodes, die Policy-Enforcement-Arbeit leisten, die nicht immer gleich komplex ist. Eine regelbasierte Prüfung für einen institutionellen Flow könnte mehr Rechenleistung oder eine sorgfältigere Bewertung erfordern als eine einfache Permission-Prüfung. Wenn sich die Belohnung dafür nicht wirklich unterscheidet, gibt es keinen naheliegenden Grund, dass ein Operator die schwerere Aufgabe schnell priorisiert. Ich weiß nicht, ob das tatsächlich mit meiner Transaktion passiert ist. Vielleicht war es nur Routing. Vielleicht war es die Position in der Warteschlange. Ich kann das nicht vollständig von dem trennen, was an dem Ort passiert, an dem ich stehe, und das ist der unangenehme Teil: Das System zeigt nicht genug, um den Unterschied zwischen „beschäftigt“ und „zurückgestellt“ zu erkennen.
Was mich immer wieder beschäftigt, ist, wie sich das unter echter Last zeigt—nicht in einem ruhigen Wochenendtest. Wenn eine Welle institutioneller Mittel Newton gleichzeitig erreicht, alle mit unterschiedlichen Regelbewertungen auf verschiedenen Komplexitätsstufen: Hält die Policy-Schicht dann ihr Tempo gleichmäßig über alle hinweg, oder werden bestimmte Transaktionstypen nach hinten gedrückt, ohne dass jemand außerhalb des Operator-Sets jemals erfährt, warum?
Ich habe ehrlich gesagt keine Antwort. Weiß jemand, ob Newton eine Pro-Operator-Latenz nach Policy-Typ veröffentlicht, oder ist das per Design unsichtbar? 👍