Die erste Frage, die mir beim Lesen über @NewtonProtocol was überraschend einfach vorkam, war: Was passiert, wenn jede Validator-Instanz eine etwas andere Version der Realität sieht?
Zunächst nahm ich an, dass dies kein großes Problem sei. Die meisten dezentralen Systeme verlassen sich bereits auf viele unabhängige Operatoren, also dachte ich, dass jeder Knoten externe Informationen abrufen, eine Richtlinie auswerten, das Ergebnis signieren und dann weitermachen könne. Je tiefer ich mich jedoch mit dem Newton Mainnet Beta und seiner technischen Dokumentation befasste, desto mehr wurde mir klar, dass diese Annahme leise zerfällt, sobald man eine BLS-Signaturaggregation einführt. BLS-Signaturen sind extrem effizient, weil hunderte Signaturen zu einem kompakten Beweis werden können, aber es gibt einen Haken, der leicht übersehen wird. Jeder Teilnehmer muss exakt dieselbe Nachricht signieren. Schon ein winziger Unterschied in den abgerufenen Daten erzeugt eine vollständig andere Nachricht, wodurch eine Aggregation unmöglich wird.
Diese Einschränkung hat die Art, wie ich Newtons Architektur betrachtete, komplett verändert. Das Schwierige ist nicht das Sammeln von Signaturen. Das Schwierige ist, dass unabhängig arbeitende Maschinen zu einem identischen Bild der externen Informationen gelangen, ohne dass ein einzelner Teilnehmer die vollständige Autorität über die Antwort erhält. Dieses Gleichgewicht zwischen Unabhängigkeit und Einigung scheint eine der interessantesten Ingenieursentscheidungen hinter @NewtonProtocol zu sein.
Das Protokoll geht diesen Weg über einen Streaming-Ansatz für einen zweiphasigen Konsens. In der ersten Phase führen Betreiber unabhängig voneinander die gesandboxten WASM-Datenanbieter aus, und zwar über ihre eigenen Netzwerkverbindungen. Sie könnten z. B. Sanktionsinformationen, Marktpreise oder andere Policy-Eingaben abrufen, ohne sich auf einen gemeinsam genutzten Server verlassen zu müssen. Jeder Betreiber erstellt außerdem eine Bescheinigung (Attestation), die beschreibt, was er tatsächlich beobachtet hat. Anstatt von Anfang an zu verlangen, dass alle einer einzigen Oracle-Quelle vertrauen, erlaubt das Protokoll zunächst unabhängige Beobachtung und danach erst Einigung.
Anfangs fragte ich mich, warum dieser zusätzliche Schritt überhaupt existiert. Wäre es nicht viel schneller, wenn das Gateway einfach nur einen freigegebenen Datensatz an alle verteilt? Aus Ingenieurssicht klingt das sicherlich einfacher. Das Problem ist, dass diese Einfachheit stillschweigend eine zentrale Abhängigkeit einführt. Wenn jeder Validator identische Informationen von einer einzigen Quelle erhält, wird Dezentralisierung eher zu einer Frage der Signatursammlung als unabhängiger Verifikation. Newton scheint diese Abkürzung zu vermeiden, indem es den Betreibern erlaubt, die Informationen selbst einzusammeln, bevor der Konsens den kanonischen Datensatz festlegt.
Erst nach dieser Vorbereitungsphase beginnt die Auswertung. Sobald ein Konsensdatensatz gebildet wurde, lädt jeder Betreiber exakt dieselbe Policy-Version mithilfe seines IPFS-Content-Identifiers, wertet identische Eingaben aus, erstellt dasselbe Digest und erzeugt schließlich eine BLS-Signatur. Ab diesem Zeitpunkt wird Aggregation möglich, weil jeder Teilnehmer schließlich dieselbe Nachricht signiert – und nicht leicht unterschiedliche Beobachtungen.
Was ich besonders interessant fand, ist, dass dieses Design zwei Probleme voneinander trennt, die häufig miteinander vermischt werden. Das eine Problem ist, festzulegen, wie die Außenwelt aktuell aussieht. Das andere ist, deterministische Autorisierungsregeln zu bewerten. Newton scheint zu vermeiden, beides gleichzeitig zu lösen. Zuerst kommt es zu einer Einigung über die Daten, dann wird die Policy ausgewertet. Das klingt nach einer subtilen Unterscheidung, aber verteilte Systeme lassen sich oft viel leichter nachvollziehen, wenn nichtdeterministische Eingaben isoliert werden, bevor eine deterministische Berechnung beginnt.
Ein praktisches Beispiel hat mir geholfen, besser zu verstehen, warum das wichtig ist. Stell dir einen Emittenten von Stablecoins vor, der prüft, ob eine Ziel-Wallet auf einer aktualisierten Sanktionsliste steht, bevor er eine Übertragung freigibt. Verschiedene Betreiber könnten unterschiedliche Spiegel abfragen oder Updates erhalten, die ein paar Sekunden auseinanderliegen. Ohne Koordination könnte ein Betreiber genehmigen, während ein anderer ablehnt. Ihre Signaturen könnten niemals zu einem einzigen Beweis kombiniert werden, was die Transaktion verzögert oder zu inkonsistenter Autorisierung führt. Indem man sich auf einen einzelnen kanonischen Datensatz vor der Auswertung einigt, erzeugt das Betreiber-Netzwerk ein einheitliches Autorisierungsergebnis, das nachgelagerte Smart Contracts effizient verifizieren können.
Beim tieferen Lesen ist mir außerdem eine Abhängigkeit aufgefallen, die sich leicht übersehen lässt. Das Gateway berechnet den Konsensdatensatz, bevor die Evaluationsphase beginnt. Auf den ersten Blick klingt das nach einer erheblichen Verantwortung, und ich fragte mich, ob dadurch eine neue Vertrauensannahme entsteht. Die Dokumentation erklärt, dass Betreiber die von ihnen beobachteten Daten unabhängig attestieren; das Gateway kann Betreiber-Signaturen nicht fälschen, und die Orchestrierungsrolle ist so ausgelegt, dass sie sich im Laufe der Zeit rotiert, statt dauerhaft zentralisiert zu bleiben. Es gibt außerdem Mechanismen zur Erzwingung von Inklusion, die dazu gedacht sind, Gateway-Zensur bei Bedarf zu umgehen. Dennoch bleibt das Gateway operativ wichtig, weil Koordination selbst eine schwierige Aufgabe ist. Das schwächt die Dezentralisierung nicht zwangsläufig, aber es bedeutet, dass die Implementierungsqualität genauso wichtig ist wie die Kryptografie.
Ein weiterer Aspekt, der mich immer wieder beschäftigt hat, betrifft die Latenz. Unabhängige Datenerhebung, Konsensbildung, Bewertung der Richtlinien, Quorum-Erhebung und Signaturaggregation finden alle statt, bevor die Autorisierung abgeschlossen ist. Bei hochdynamischen Informationen wie sich schnell bewegenden Marktpreisen könnte die zeitliche Komponente zunehmend wichtiger werden. Das Protokoll enthält einen vereinfachten Single-Phase-Modus für deterministische oder gecachte Daten, um unnötigen Overhead zu reduzieren. Das deutet darauf hin, dass die Designer erkennen, dass nicht jede Autorisierungsanfrage identische Koordinationskosten verdient. Ob Anwendungen den richtigen Modus wählen, könnte letztlich eine bedeutende Entwicklerverantwortung werden.
Das hebt außerdem ein übergreifendes Ingenieurprinzip hervor, das weit über @NewtonProtocol hinausgeht. Verteilte Systeme scheitern selten, weil die Kryptografie schwach ist. Viel häufiger scheitern sie, weil unabhängige Teilnehmer unterschiedliche Realitäten beobachten. Konsensalgorithmen werden häufig als Methoden beschrieben, um Blöcke oder Transaktionen zu vereinbaren, aber Einigung über externe Informationen kann genauso herausfordernd sein. Oracle-Design, Policy-Evaluation, dezentrale KI, Cross-Chain-Messaging und Autorisierungs-Frameworks stoßen alle früher oder später auf dieselbe Frage: Wie können unabhängige Maschinen zuverlässig auf Daten reagieren, die sich ständig ändern?
Diese Frage wirkt zunehmend relevant, sobald KI-Agenten direkt mit der Blockchain-Infrastruktur interagieren. Menschen vertragen Unklarheit und unvollständige Informationen von Natur aus. Maschinen normalerweise nicht. Wenn ein autonomes System widersprüchliche externe Eingaben erhält, wird deterministische Ausführung überraschend fragil. Eine Infrastruktur, die diese Eingaben standardisiert, bevor wichtige Entscheidungen getroffen werden, könnte am Ende genauso wertvoll sein wie eine schnellere Ausführung selbst.
Ich glaube außerdem nicht, dass dieses Design wirklich alle Trade-offs eliminiert. Medianbasierter Konsens funktioniert gut für viele numerische Werte, aber nicht jede externe Datenquelle passt sauber in dieses Modell. Einige Policy-Eingaben sind qualitativ, andere hängen möglicherweise von schnell wechselnden Datenbanken ab, und eine Dokumentation kann natürlich nicht jede Edge Case vorwegnehmen, die Entwickler über eigene WASM-Datenanbieter einführen könnten. Diese operativen Fragen bleiben genau deshalb interessant, weil es dafür noch keine allgemein akzeptierten Antworten gibt.
Nachdem ich mir Zeit genommen hatte, diesen Teil von Newton Mainnet Beta zu studieren, hörte ich auf, BLS-Aggregation nur als kryptografische Optimierung zu betrachten. Sie formt leise das gesamte Koordinationsmodell des Netzwerks. Sobald identische Nachrichten eine Voraussetzung sind, reicht unabhängige Beobachtung allein nicht mehr aus. Konsens muss existieren, bevor überhaupt Signaturen beginnen.
Ich frage mich, ob die nächste Generation dezentraler Infrastruktur weniger Zeit damit verbringen wird, nachzuweisen, dass Berechnungen korrekt ausgeführt wurden, und mehr Zeit damit, zu beweisen, dass jeder Teilnehmer tatsächlich von derselben gemeinsam geteilten Version der Realität ausgegangen ist.
