Ich habe immer geglaubt, dass das Wichtigste an einem dezentralen System die Deterministik ist. Solange sich das Netzwerk einig wird, sollte alles erledigt sein. Der Operator führt die Policy Evaluation aus, generiert eine BLS-Atestation, die Transaktion erhält die Authorization und geht anschließend in die Ausführung über. Das sollte ein vollständiger Ablauf sein.
Als ich dann am Anfang das Whitepaper mit @NewtonProtocol durchblätterte, konnte ich lange nicht verstehen, warum später noch ein Challenge Protocol entworfen werden sollte. Ich war sogar zeitweise der Meinung, es diene nur dazu, dass, wenn der Operator einen Fehler macht, eine zusätzliche Fehlerkorrekturmechanik greift.
Später habe ich den Challenge-Teil gezielt noch einmal neu gelesen. Je mehr ich las, desto mehr wirkte es nicht stimmig. Der Challenger entscheidet nicht erneut darüber, ob die Transaktion ausgeführt werden soll. Stattdessen erhält er dieselbe Transaction Intent, denselben Policy CID und denselben Policy Hash. Dann führt er die Authorization ein einziges Mal nochmals nach derselben Rego-Policy-Replay-Logik aus. Nur wenn das Replay-Ergebnis nicht mit der ursprünglichen BLS-Atestation übereinstimmt, reicht er ein ZK Proof ein und löst Slashing aus. Bei der erneuten Prüfung wird also nicht die Transaktion selbst verifiziert, sondern ob diese Authorization strikt gemäß den festgelegten Policies erzeugt wurde.
Als ich das sah, blieb ich gedanklich stecken.
Wenn der Operator bereits Konsens erzielt hat, warum lässt Newton dann überhaupt andere erneut neu berechnen? Ich hatte immer angenommen, dass Konsens bedeutet, dass die Antwort bereits entstanden ist, und dass Challenge nur dazu da ist, Fehler zu korrigieren. Aber das, was das Whitepaper mit Challenge wirklich ausdrückt, ist nicht, das Ergebnis zu verwerfen, sondern niemandem die endgültige Deutung irgendeines Konsenses zu erlauben.
Erst da habe ich gemerkt, dass ich anfangs falsch verstanden hatte.
$NEWT will nicht beweisen, dass eine bestimmte Authorization richtig ist, sondern sicherstellen, dass jede Authorization von anderen Teilnehmern anhand derselben Regeln erneut verifiziert werden kann.
Wenn ich jetzt zurückblicke, ist das Faszinierendste am Challenge nicht, dass es ein Streit-/Kontroversen-Mechanismus hinzufügt, sondern dass es das Vertrauen neu definiert.
Früher dachte ich immer, dass Vertrauen aus dem bereits entstandenen Konsens kommt.
Aber #newt klingt eher so, als würde es sagen: Was es wirklich wert ist, zu vertrauen, ist nicht ein bereits entstandenes Ergebnis, sondern dass jeder dieses Ergebnis mit derselben Intent, derselben Policy und genau denselben Regeln erneut beweisen kann.
Als ich dann am Anfang das Whitepaper mit @NewtonProtocol durchblätterte, konnte ich lange nicht verstehen, warum später noch ein Challenge Protocol entworfen werden sollte. Ich war sogar zeitweise der Meinung, es diene nur dazu, dass, wenn der Operator einen Fehler macht, eine zusätzliche Fehlerkorrekturmechanik greift.
Später habe ich den Challenge-Teil gezielt noch einmal neu gelesen. Je mehr ich las, desto mehr wirkte es nicht stimmig. Der Challenger entscheidet nicht erneut darüber, ob die Transaktion ausgeführt werden soll. Stattdessen erhält er dieselbe Transaction Intent, denselben Policy CID und denselben Policy Hash. Dann führt er die Authorization ein einziges Mal nochmals nach derselben Rego-Policy-Replay-Logik aus. Nur wenn das Replay-Ergebnis nicht mit der ursprünglichen BLS-Atestation übereinstimmt, reicht er ein ZK Proof ein und löst Slashing aus. Bei der erneuten Prüfung wird also nicht die Transaktion selbst verifiziert, sondern ob diese Authorization strikt gemäß den festgelegten Policies erzeugt wurde.
Als ich das sah, blieb ich gedanklich stecken.
Wenn der Operator bereits Konsens erzielt hat, warum lässt Newton dann überhaupt andere erneut neu berechnen? Ich hatte immer angenommen, dass Konsens bedeutet, dass die Antwort bereits entstanden ist, und dass Challenge nur dazu da ist, Fehler zu korrigieren. Aber das, was das Whitepaper mit Challenge wirklich ausdrückt, ist nicht, das Ergebnis zu verwerfen, sondern niemandem die endgültige Deutung irgendeines Konsenses zu erlauben.
Erst da habe ich gemerkt, dass ich anfangs falsch verstanden hatte.
$NEWT will nicht beweisen, dass eine bestimmte Authorization richtig ist, sondern sicherstellen, dass jede Authorization von anderen Teilnehmern anhand derselben Regeln erneut verifiziert werden kann.
Wenn ich jetzt zurückblicke, ist das Faszinierendste am Challenge nicht, dass es ein Streit-/Kontroversen-Mechanismus hinzufügt, sondern dass es das Vertrauen neu definiert.
Früher dachte ich immer, dass Vertrauen aus dem bereits entstandenen Konsens kommt.
Aber #newt klingt eher so, als würde es sagen: Was es wirklich wert ist, zu vertrauen, ist nicht ein bereits entstandenes Ergebnis, sondern dass jeder dieses Ergebnis mit derselben Intent, derselben Policy und genau denselben Regeln erneut beweisen kann.