Beim Lesen der Dokumentation zu „Consensus & Security“ des Newton Protocols ist mir eine Implementierungsdetails sofort aufgefallen: Operatoren beginnen nicht mit dem BLS-Signing, sobald eine Aufgabe eintrifft. Stattdessen fügt Newton eine eigene Konsens-Phase ein, bevor die Policy-Auswertung erfolgt.

Laut der Dokumentation beginnt der Prozess mit der Phase „Prepare“. Operatoren rufen unabhängig externe Policy-Daten ab und geben unsignierte Antworten an das Gateway zurück. In dieser Phase werden keine BLS-Signaturen erzeugt.

Das Gateway berechnet anschließend Medianwerte aus den gesammelten Antworten für numerische Daten und prüft sie gegen die konfigurierte Toleranz. Wenn der Wert eines Operators die Schwellenwerttoleranz überschreitet, schlägt der Konsens mit einem ToleranceExceeded-Fehler fehl. Die Dokumentation stellt ausdrücklich fest, dass Operatoren nicht stillschweigend ausgeschlossen werden, wenn ihre Werte außerhalb des zulässigen Bereichs liegen.

Erst nachdem ein gemeinsamer Datensatz festgelegt wurde, beginnt die Commit-Phase. Das Gateway sendet die kanonischen Konsensdaten an die Operatoren zurück. Da jeder Operator die Policy nun mit identischen Eingaben auswertet, kann er BLS-Signaturen über dieselbe Nachricht erzeugen.

Diese Reihenfolge scheint eng mit einer weiteren dokumentierten Implementierungsdetails zusammenzuhängen: Newtons Zwei-Digest-System. Die Dokumentation erläutert, dass BLS-Aggregation erfordert, dass jeder Operator genau dieselbe Nachricht signiert. Um diese Anforderung zu erfüllen, signieren Operatoren den Consensus Digest per BLS, während der Full Digest, der eindeutige Attestierungen enthält, zur Challenge-Verifikation on-chain gespeichert wird.

Zusammen betrachtet ergeben diese Mechanismen einen kohärenten Workflow. Die Prepare-Phase bringt die Operator-Eingaben in Einklang. Der Median-Konsensprozess legt einen kanonischen Datensatz fest. Die Commit-Phase führt die Policy-Bewertung anhand dieser geteilten Werte aus. Schließlich findet die Aggregation von BLS-Signaturen erst statt, nachdem die Operatoren mit identischen Daten arbeiten.

Ein weiterer Punkt, den es wert ist zu beachten, ist Newtons Umgang mit Uneinigkeit. Anstatt die Mehrheit zu akzeptieren und Ausreißer zu ignorieren, sagt die Dokumentation, dass Werte, die die konfigurierte Toleranz überschreiten, dazu führen, dass der Konsens fehlschlägt. Damit ist der Toleranzparameter Teil des Konsensverhaltens des Protokolls und nicht nur eine Empfehlung.

Die Dokumentation stellt diesen Prozess außerdem in Verbindung mit durch EigenLayer gestützter wirtschaftlicher Absicherung. Operatoren nehmen über neu gestaketes ETH teil, und fehlerhafte Bewertungen können während der Challenge Window angefochten werden, was potenziell zu Slashing führt. In Kombination mit BLS-Aggregation bietet dies sowohl kryptografische Verifikation als auch wirtschaftliche Verantwortlichkeit für Policy-Bewertungen.

Aus Implementierungssicht ist der interessante Aspekt nicht nur, dass Newton BLS-Signaturen verwendet. Die Dokumentation zeigt, dass die BLS-Aggregation bewusst nach einem eigenen Konsensprozess platziert wird. Indem Newton sicherstellt, dass Operatoren Policies aus demselben kanonischen Datensatz auswerten, schafft Newton die Voraussetzungen für eine verifizierbare Aggregatsignaturprüfung und hält dabei die dokumentierten Toleranzregeln für externe Daten ein.

Technische Frage: Wenn externe Daten volatiler werden, welche Überlegungen sollten bei Anpassungen der Konsenstoleranz berücksichtigt werden, damit der Konsens zuverlässig bleibt, ohne unnötig zu häufigen fehlgeschlagenen Bewertungen zu führen @NewtonProtocol #Newt $NEWT