$
Habe heute Morgen wieder einen faulen Trading-Fehler gemacht.
Zum Glück nichts Großes. Ich hatte eine Position, die in die richtige Richtung lief, bin weggegangen, ohne den Stop anzupassen, und bin dann zurückgekommen, um festzustellen, dass von der Bewegung fast nichts mehr übrig war.
Die Order wurde genau so ausgeführt, wie ich es vorgesehen hatte.
Das war das Ärgerliche.
Das System war nicht fehlgeschlagen.
Meine Regel hatte es.
Wie auch immer, ich landete schließlich wieder in der Sicherheitsdokumentation von Newton Protocol, statt nur auf den Chart zu starren. Diesmal versuchte ich, etwas zu beantworten, das ich wahrscheinlich vorher viel zu locker beschrieben hatte:
Was passiert tatsächlich, wenn Neutons Operatoren eine schlechte Compliance-Entscheidung treffen?
Meine erste Annahme war, dass die Antwort subjektiv sein würde.
EigenLayer gibt jedem AVS erheblichen Spielraum, sein Sicherheitsmodell und seine Slashing-Bedingungen zu definieren. Die aktuelle Dokumentation trennt diese Bedingungen in objektive Fehler, subjektive Governance-Entscheidungen und intersubjektive Fehler auf Basis breiter Übereinstimmung unter vernünftigen Beobachtern.
Dadurch erwartete ich, dass Neutons Version chaotisch sein würde.
Compliance ist voller unangenehmer Fragen.
Meldet sich diese Person wirklich als Einwohner in einem genehmigten Land?
Ist ein Wallet-Risikoscore ernst genug, um zu blockieren?
Verstößt eine Transaktion gegen die Intention einer Regulierung, oder nur gegen eine bestimmte Interpretation davon?
Die klingen nicht so sauber, wie zu beweisen, dass ein Operator eine ungültige State-Transition signiert hat.
Aber Neutons dokumentierter Challenge-Mechanismus ist objektiver, als ich erwartet hatte.
Neutons Rego-Policies sind deterministisch. Bei derselben Policy und denselben Policy-Task-Daten sollte die Evaluierungsmaschine jedes Mal dasselbe Ergebnis zurückgeben.
Wenn ein Challenger glaubt, dass eine Onchain-Antwort falsch ist, beschreibt Neutons Whitepaper keine Governance-Abstimmung darüber, ob die Operatoren gutes Urteilsvermögen eingesetzt haben.
Er beschreibt einen Zero-Knowledge-Beweis.
Der Challenger führt Neutons vollständige Rego-Evaluierungsmaschine erneut aus – gegen die Policy-Task-Daten, die in der Antwort enthalten sind. Der Beweis muss zeigen, dass das korrekte Evaluationsergebnis vom Onchain-Ergebnis abweicht.
Neutons Dokumentation ist hier ungewöhnlich konkret zur Grenze:
Der Circuit konzentriert sich darauf zu beweisen, dass die Policy-Evaluierung anhand der attestierten Inputs falsch war.
Diese Frage ist objektiv:
Gegeben sei Policy P und die aufgezeichneten Inputs D: War das deterministische Ergebnis „allow“ oder „deny“?
Für einen Moment schien das das ganze Problem zu lösen.
Dann begann mich die Unterscheidung zu stören.
Newton kann beweisen, dass Operatoren eine Policy falsch angewendet haben.
Das beweist aber nicht automatisch, dass die Policy sinnvoll war, oder dass die in die Policy eingehenden Informationen die Außenwelt korrekt abbildeten.
Stell dir vor, ein Identitätsanbieter meldet, dass jemand in einer genehmigten Jurisdiktion wohnhaft ist.
Neutons Operatoren erhalten dieses Attribut, evaluieren eine Policy, nach der genehmigte Einwohner transagieren dürfen, und geben „allow“ zurück.
Später stellt sich heraus, dass die Person vor Monaten umgezogen ist und der Datensatz des Anbieters nicht aktualisiert wurde.
War die daraus resultierende Autorisierung falsch?
Im Sinne der realen Welt vielleicht.
War Neutons Berechnung falsch?
Nicht unbedingt.
Wenn die Operatoren die Policy treu anhand des Attributs ausgewertet haben, das sie erhalten haben, sollte das erneute Abspielen derselben deterministischen Berechnung dieselbe Antwort liefern. Es gäbe keine widersprüchliche Evaluierung, die der Challenge-Beweis aufdecken könnte.
Neutons eigener Threat Model macht diese Grenze ungewöhnlich klar.
Er behandelt Credential-Aussteller als vertrauenswürdig für die Korrektheit von Attributen, während die Operatoren dafür verantwortlich sind, Policies auszuwerten und Antworten zu signieren.
Neutons VaultKit-Conditions machen die Einschränkung noch direkter: Die Policy-Evaluierung ist nur so genau und aktuell wie die Antwort des Datenanbieters, und die Genauigkeit, Vollständigkeit und Aktualität von Ergebnissen Dritter ist nicht garantiert.
Neutons Persona-Integration zeigt, wie die Trennung in der Praxis funktioniert.
Persona stellt validierte Attribute bereit wie Alter, Nationalität, Wohnsitz und Bundesland. Neutons Operatoren evaluieren dann die Policy der Anwendung gegen diese Attribute und erzeugen die vom Smart Contract geforderte Attestation.
Also kann eine „schlechte Compliance-Entscheidung“ mindestens drei verschiedene Arten von Fehlern beschreiben:
Die Operatoren berechneten das Policy-Ergebnis falsch.
Der externe Anbieter lieferte unzutreffende, manipulierte oder veraltete Informationen.
Die Anwendung, der Curator oder der Policy-Author hat eine Regel ausgewählt, die perfekt ausführbar war, aber schlecht entworfen wurde.
Neutons ZK-Challenge- und Slashing-Design adressiert den ersten Fehler direkt.
Das zweite bleibt teilweise ein Problem der Datenqualität und des Vertrauens in den Anbieter.
Das Dritte bleibt ein Problem für Policy-Design und Governance.
Das ist keine Schwäche in Neutons Architektur – muss es aber nicht sein.
Ganz ehrlich: Wenn man ein Operator-Netzwerk damit beauftragen würde, den wahren rechtlichen Wohnsitz einer Person zu bestimmen, zu entscheiden, ob ein Risikomodell fair ist, oder festzulegen, welche Auslegung einer Regulierung korrekt ist, würde das Ergebnis wahrscheinlich weniger objektiv verifizierbar.
Newton verengt die slashingfähige Behauptung auf etwas, das Rechnen tatsächlich beweisen kann:
Genau diese Policy wurde auf diese attestierten Inputs angewendet, und das von den Operatoren signierte Ergebnis stimmte entweder überein oder widersprach der deterministischen Ausführung.
Die Attestation hält fest, welches Ergebnis die Operatoren für eine bestimmte Intention und Policy signiert haben.
Der Challenge-Mechanismus ist das, was eine widersprüchliche Berechnung beweisbar und wirtschaftlich strafbar macht.
Es gibt eine weitere Einschränkung, die man im Blick behalten sollte.
Neutons Dokumentation sagt, dass eine Attestation verwendet werden kann, sobald sie verfügbar ist. Das Challenge-Window schafft Zeit, damit ein falsches Ergebnis angefochten und die verantwortlichen Operatoren geslashed werden können, aber es verzögert nicht den Verbrauch der Attestation.
So schafft Slashing Verantwortlichkeit nach einem nachweisbaren Evaluierungsfehler.
Das bedeutet nicht zwangsläufig, dass die Transaktion, die die Autorisierung bereits verbraucht hat, automatisch rückgängig gemacht wird.
Es gibt außerdem einen wichtigen Vorbehalt für Mainnet Beta.
Neutons Ankündigung vom 23. Juni sagt, dass das Protokoll live auf Base und Ethereum ist, unter Verwendung von EigenLayer-Operatoren und der Zero-Knowledge-Technologie von Succinct.
Aber Neutons Erklärung vom 1. Juli sagt, dass, sobald Newton aus der Beta heraus ist, viele Operatoren unabhängig jede eingereichte Proposal bewerten, bevor das Netzwerk eine Autorisierung ausstellt.
Das schafft eine wichtige Unterscheidung beim Deployment.
Neutons veröffentlichte Sicherheitsarchitektur beschreibt Multi-Operator-Consensus, Challenge-Windows, ZK-Fraud-Proofs und EigenLayer-Slashing.
Seine öffentlichen Unterlagen geben bislang nicht genug Evidenz auf Deployment-Ebene, um zu behaupten, dass jede Komponente dieses vollständigen Modells bereits in Mainnet Beta genau wie im Whitepaper beschrieben aktiv ist.
Also ist der sorgfältige Weg, es heute zu beschreiben:
Neutons dokumentiertes Sicherheitsdesign erlaubt es, einen Operator zu identifizieren und zu slaschen, der eine nachweisbar falsche Policy-Evaluierung signiert.
Ich würde nicht behaupten, ohne weitere Produktions-Evidenz, dass der vollständige Multi-Operator-Challenge-und-Slashing-Flow bereits Ende-zu-Ende in Mainnet Beta demonstriert wurde.
Trotzdem bleibt die Unterscheidung nützlich.
Newton kann eine Abweichung von einer aufgezeichneten Policy wirtschaftlich strafbar machen.
Ob die daraus resultierende Autorisierung im weiteren Sinne der realen Welt vertrauenswürdig ist, hängt jedoch noch vom Policy-Author und den Datenanbietern ab, die über dieser slashingfähigen Berechnung sitzen.
Das brachte mich zurück zu meinem Handel.
Die Reihenfolge befolgte meine Anweisungen perfekt.
Das Problem war, dass meine Anweisungen falsch waren.
Löst die verifizierbare Durchsetzung das Compliance-Problem, oder macht sie Gehorsam gegenüber einer gewählten Compliance-Version beweisbar?