Ein Immobilienbewertungsausschuss. Drei unabhängige Gutachter bewerten dieselbe Immobilie. Jeder holt sich seine eigenen vergleichbaren Verkaufsdaten, prüft die Marktlage und rechnet seine Ergebnisse aus. Anschließend sitzen sie zusammen. Wenn ein Gutachter sagt, die Immobilie sei eine halbe Million wert, und ein anderer sagt, es seien achthunderttausend, dann sind die Daten von jemandem falsch. Sie mitteln die beiden Werte nicht einfach und machen weiter. Sie identifizieren den Ausreißer, prüfen, wessen Daten falsch waren, und wenn die Abweichung den zulässigen Bereich überschreitet, stoppen sie den Prozess vollständig. Erst wenn alle drei Bewertungen innerhalb eines engen Korridors liegen, unterzeichnen sie den finalen Bericht. Dieser Bericht geht dann in die Konzernzentrale der Bank, wo ein Sachbearbeiter nur eine Sache prüft: ob alle drei Unterschriften vorhanden und gültig sind. Der Sachbearbeiter führt keine Neubewertung erneut durch. Er kennt die Immobilie nicht. Er verifiziert lediglich die Unterschriften anhand der registrierten Liste der autorisierten Gutachter.

Ich habe damit angefangen, mich darüber Gedanken zu machen, als ich versuchte zu verstehen, wie Newtons Prepare-Commit-Konsens funktioniert und wie er mit ihrer Multichain-Architektur zusammenhängt. Die zwei Mechanismen wirken auf den ersten Blick getrennt: einer richtet Orakel-Daten aus, der andere verifiziert Beweise über Chains hinweg. Aber sie teilen ein tieferes Muster, das ich eine Weile brauchte, um es zu bemerken.

Lassen Sie mich mit dem Prepare-Commit-Flow beginnen. Wenn eine Aufgabe auf das Gateway trifft, holen Operatoren nicht einfach die Policy ab und signieren. Sie gehen durch zwei getrennte Phasen. In Prepare ruft jeder Operator unabhängig die externen Datensources auf, die die Policy benötigt: Preis-Feeds, KYC-Orakel, Sanktionslisten. Sie geben ihre rohen, nicht signierten Antworten zurück. Das Gateway sammelt all diese Antworten und berechnet für jedes numerische Feld einen Median. Dann prüft es die Toleranz. Wenn der Wert eines Operators mehr als 10% vom Median abweicht, schlägt der Konsens genau dort mit ToleranceExceeded fehl. Der Ausreißer wird nicht stillschweigend ausgeschlossen. Das Ganze stoppt.

Wenn alle Werte innerhalb der Toleranz liegen, normalisiert das Gateway alles auf den Median und sendet den kanonischen Datensatz für die Commit-Phase aus. Jetzt bewertet jeder Operator die Policy anhand identischer Eingaben. Jeder erzeugt eine BLS-Signatur auf derselben Nachricht. Diese Signaturen werden zu einem einzigen Beweis aggregiert.

Ich finde dieses Zwei-Phasen-Design beachtenswert, weil es ein Problem löst, das man leicht übersehen kann. Operatoren, die externe APIs aufrufen, werden naturgemäß leicht unterschiedliche Antworten bekommen. Ein Preisticker könnte für den einen Operator 100,0 und für den anderen 100,3 zurückgeben, einfach weil zwischen ihren Aufrufen Millisekunden vergangen sind. In den meisten Orakel-Designs wird diese Varianz entweder ignoriert oder durch das Vertrauen in eine einzelne Datenquelle behandelt. Newton erzwingt Konsens über die Daten selbst, bevor irgendjemand etwas signiert. Der Median wird zur Wahrheit, aber nur, wenn die Streuung eng genug ist. Wenn die Streuung zu breit ist, zieht das System vor, zu scheitern, statt ein zweifelhaftes Ergebnis zu signieren.

Der Trade-off ist die Latenz. Zwei vollständige Kommunikationsrunden, bevor die Attestation überhaupt existiert. Und das Gateway hat in diesem Zeitfenster eine privilegierte Position. Es berechnet den Median. Es entscheidet, welche die kanonischen Werte sind. Ein kompromittiertes Gateway könnte theoretisch einen manipulierten Median an die Operatoren einspeisen, und sie würden ihn getreulich signieren, weil die Daten für sie als kanonisch aussehen. Die Schutzmaßnahmen sind eng: Operatoren können wählen, nicht zu signieren, wenn etwas verdächtig wirkt, und wenn genug enthalten, scheitert das Quorum. Das ist jedoch eine reaktive Abwehr, keine kryptografische. Ich weiß nicht, wie gut das einem ausgefeilten Angriff standhält.

Jetzt, wo der Multichain-Teil interessant wird, ist die Frage, wie dieses Konsensergebnis über Chains hinweg weitergegeben wird. Newtons Operatoren leben auf einer Quell-Chain, Ethereum Mainnet oder Sepolia. Aber PolicyClient-Contracts können auf Ziel-Chains wie Base oder Arbitrum bereitgestellt werden. Die auf der Quell-Chain erzeugte Attestation muss auf einer völlig anderen Chain verifiziert werden. Das tun sie mit BN254-Zertifikaten. Die BLS-Aggregat-Signatur wird in ein Zertifikat kodiert, das ein leichter Verifizierer-Contract auf der Ziel-Chain prüfen kann. Die Ziel-Chain führt die Policy nicht erneut aus. Sie stellt keine Fragen an die Operatoren. Sie verifiziert lediglich die Mathematik anhand eines gecachten Snapshots der Operator-Menge.

Hier kommt die Analogie mit dem Bewertungsausschuss wieder. Der Hauptsitz der Bank, die Ziel-Chain, führt die Bewertung nicht erneut durch. Er prüft die Signaturen. Der Operator-Zustand muss von der Quell-Chain über einen Table-Syncer-Dienst mit der Ziel-Chain synchronisiert werden, der periodisch BLS-Schlüssel, Stake-Gewichte und Merkle-Roots pusht. Wenn diese Synchronisierung hinterherhinkt, prüft der Verifizierer gegen veraltete Daten. Wenn die Synchronisierung in mehreren Transaktionen statt in einem einzigen atomaren Batch erfolgt, können Zwischenzustände Merkle-Beweise beschädigen und zu Verifikationsfehlern führen. Die Doku warnt ausdrücklich davor. Das ist eine scharfe Kante, die jemand operativ im Griff haben muss.

Auch der Challenge-Flow ist aufgeteilt. Wenn eine Attestation auf einer Ziel-Chain bestritten wird, wird die Attestation lokal ungültig gemacht. Aber das tatsächliche Slashing, die wirtschaftliche Strafe, passiert zurück auf der Quell-Chain. Dort liegt der Operator-Stake. Die Ziel-Chain kann nicht slashten. Sie kann nur die Ausführung verweigern. Daher entsteht eine Lücke zwischen Ungültigmachung und Bestrafung. Während dieser Lücke könnte ein böswilliger Operator versuchen auszusteigen. Die Sicherheit beruht darauf, dass die Withdrawal Delay von EigenLayer lang genug ist, um dieses Zeitfenster zu schließen.

Ich komme immer wieder darauf zurück, wie diese zwei Mechanismen, Prepare-Commit und die Cross-Chain-Verifizierung, denselben Instinkt teilen. Beide sollen sicherstellen, dass das, was signiert und verifiziert wird, konsistent ist, selbst wenn die Datenquellen und die Durchsetzungspunkte über verschiedene Systeme verteilt sind. Die Prepare-Phase richtet Daten zwischen Operatoren aus. Das BN254-Zertifikat richtet die Verifizierung über Chains hinweg aus. Beide führen Abhängigkeiten ein: das Gateway in Prepare, der Table-Syncer in der Multichain. Beide haben Fehlermodi, die unter normalen Bedingungen handhabbar sind, aber sich unter Stress möglicherweise verstärken könnten.

Ich versuche immer noch herauszufinden, ob diese Abhängigkeiten akzeptable Engineering-Trade-offs sind oder ob sie Vertrauen in einer Weise bündeln, die die Dezentralisierung des restlichen Systems untergräbt. Die Architektur ist clever. Aber clevere Architekturen haben eine Eigenart: Sie scheitern an den Verbindungsstellen zwischen Komponenten. Ich bin mir noch nicht sicher, ob Newtons Verbindungen genug verstärkt sind. Ich schaue sie mir aber weiterhin an.

@NewtonProtocol #Newt $NEWT