Beim Lesen der Dokumentation zu Consensus & Security des Newton-Protokolls fiel eine Implementierungsdetails auf. Viele verteilte Systeme konzentrieren sich darauf, wie Signaturen verifiziert werden, aber Newton legt gleichermaßen Wert darauf, sicherzustellen, dass jeder Operator bereits im ersten Schritt dieselben Daten signiert.
Die Dokumentation beschreibt einen zweiphasigen Konsensprozess, der aus einer Prepare-Phase und anschließend einer Commit-Phase besteht.
Während der Prepare-Phase bewerten Operatoren Richtlinien nicht sofort oder erzeugen BLS-Signaturen. Stattdessen ruft jeder Operator unabhängig externe Richtliniendaten ab, wie z. B. numerische Werte, die von PolicyData-Orakeln zurückgegeben werden, und sendet unsignierte Antworten an das Gateway.
In diesem Stadium existiert kein Konsensbeweis.
Anstatt zuzulassen, dass jeder Operator mit leicht unterschiedlichen Eingaben fortfährt, berechnet das Gateway für jedes numerische Feld den Medianwert und verifiziert, dass die Antwort jedes Operators innerhalb der konfigurierten Toleranz bleibt. Wenn ein Wert die zulässige Toleranz überschreitet, schlägt der Konsens mit einem Fehler „ToleranceExceeded“ fehl, statt den Ausreißer stillschweigend auszuschließen.
Erst nachdem ein kanonischer Satz von Eingabewerten festgelegt wurde, tritt das Protokoll in die Commit-Phase ein.
Das Gateway sendet die Konsensdaten an die Operatoren zurück. Da nun jeder Operator die Policy mit denselben normalisierten Eingaben auswertet, erzeugen sie BLS-Signaturen über dieselbe Nachricht. Das Gateway aggregiert diese Signaturen dann, sobald ein Quorum erreicht ist.
Die Dokumentation erklärt auch, warum diese Reihenfolge wichtig ist.
Newton verwendet zwei verschiedene Digest-Typen. Operatoren erzeugen einzelne ECDSA-Zertifikate, die sich je nach Teilnehmer natürlicherweise unterscheiden; für die BLS-Aggregation müssen jedoch alle Unterzeichner exakt dieselbe Nachricht signieren. Um diese Anforderung zu erfüllen, signieren Operatoren einen Konsens-Digest mit BLS, der die eindeutigen Zertifikate ausschließt, während ein separater vollständiger Digest, der diese Zertifikate enthält, zur Challenge-Verifizierung auf der Blockchain gespeichert wird.
Aus technischer Sicht reduziert diese Reihenfolge Meinungsverschiedenheiten, bevor überhaupt eine kryptografische Konsensbildung beginnt.
Anstatt die Operatoren zuerst signieren zu lassen und die Unterschiede später abzugleichen, standardisiert Newton zuerst die Bewertungseingaben, führt dann die Policy-Auswertung durch und erzeugt erst danach aggregierte BLS-Signaturen.
Dieser Ansatz trennt den Datenkonsens vom Signaturkonsens und macht den finalen Beweis von einer gemeinsamen Sicht auf externe Daten abhängig, statt von unabhängigen Interpretationen.
Das Ergebnis ist ein Workflow, in dem der Konsens in Stufen aufgebaut wird. Zuerst einigen sich die Operatoren auf die Eingaben, dann bewerten sie die Policy, dann signieren sie denselben Digest und schließlich erstellen sie einen einzelnen aggregierten Beweis zur On-Chain-Verifizierung.
Diese Sequenzierung ist eine der interessantesten technischen Entscheidungen, die im Design „Consensus & Security“ des Newton Protocol dokumentiert sind.
Frage für Entwickler: Wenn externe Daten aus mehreren unabhängigen Quellen stammen, ist es besser, die Eingaben vor der Policy-Auswertung zu standardisieren, oder sollten die Operatoren unabhängig auswerten und den Konsens erst auf der Signaturebene entstehen lassen?@NewtonProtocol #Newt $NEWT