Ich komme immer wieder auf diese Frage zurück: Wenn ein @NewtonProtocol Das Protokoll sagt, etwas sei „gesichert“ – was deckt dieses Wort eigentlich ab? Meistens ist es eine Kurzform für eine Sache – ein Audit, eine Bug-Bounty, ein Multisig. Wenn man sich anschaut, wie Newton Protocol seinen Security-Stack strukturiert, ist das eindeutig nicht nur eine Sache. Es sind vier – und jede davon erfüllt eine andere Aufgabe.$NEWT 
EigenLayer an der Basis sitzt. Operatoren im Newton-Netzwerk setzen restaked ETH; genau diese Einsatzmittel stehen auf dem Spiel, falls sie etwas Falsches abzeichnen – die Bestätigung, auf die ein Vault angewiesen ist, um eine Transaktion zu genehmigen oder abzulehnen. Das ist kein Vertrauen auf Basis von Reputation. Das ist eine Anleihe. Mach es falsch, und es wird abgezogen (slashed). Das ist eine ziemlich alte Idee im Finanzwesen – Kapital hinter eine Behauptung stellen – angewandt auf ein ziemlich neues Problem: Wie vertraut man einem dezentralen Netzwerk dabei, eine Regel korrekt zu prüfen, ohne dass eine zentrale Instanz dafür bürgt?
Für mich wird es bei „Succinct“ besonders interessant. N ewtons Streitbeilegungsmechanismus basiert nicht auf Governance-Abstimmungen oder einer Prüfung durch ein Komitee, wenn eine Attestation angefochten wird. Er basiert auf Zero-Knowledge-Beweisen – ein Herausforderer führt die gleiche Policy unabhängig erneut aus und erstellt einen Beweis, der zeigt, dass das ursprüngliche Ergebnis falsch war. Die Rolle von Succinct liegt in der Infrastruktur, die diese Art von Beweiserstellung überhaupt erst in der Größenordnung eines Live-Protokolls praktisch macht, nicht nur als Forschungs-Demo. Der Unterschied ist wichtig: Ein Streit hier ist nicht „Wir haben abgestimmt und entschieden, dass du falsch liegst.“ Es ist „Hier ist ein mathematischer Beweis, dass du falsch liegst.“#Newt
Rhinestone und Octane runden den Stack ab, und soweit ich das beurteilen kann, kümmern sie sich um Bedenken auf der Execution-Layer-Ebene – also um die Mechanik, wie die Policy-Durchsetzung tatsächlich in den Ausführungspfad einer Transaktion eingebunden wird, ohne dabei etwas zu beschädigen oder an der Integrationsstelle eine neue Angriffsfläche einzuführen. Das ist der unansehnliche Teil der Sicherheitsarbeit. Niemand schreibt darüber, aber normalerweise ist es genau dort, wo die Dinge wirklich kaputtgehen.
Was mich an dieser ganzen Struktur auffällt, ist, dass keine dieser vier Parteien das eigene Team von Newton ist, das so tut, als wäre es neutral gegenüber seinem eigenen Protokoll. Sie sind jeweils eigene Spezialisten, die jeweils Bereiche abdecken, die die anderen nicht abdecken. Das ist eine andere Designphilosophie als „Wir haben es gebaut, wir haben es gesichert, glaubt uns.“#NEWT
So, und hier ist, was ich noch nicht gelöst habe: Schichtweise Sicherheit wird normalerweise so dargestellt, als sei sie strikt additiv – mehr Schichten, mehr Sicherheit. Aber mehr Schichten bedeutet auch, dass es mehr Stellen gibt, an denen ein Versagen in den Annahmen eines Systems sich schlecht mit den Annahmen eines anderenystems vertragen könnte. Eine Restaking-Slash-Bedingung und ein Zeitfenster für einen Zero-Knowledge-Streit lösen unterschiedliche Probleme, aber sie müssen beide sich über den Zeitplan einig sein, darüber, was als „final“ gilt, und darüber, was in der Lücke passiert, zwischen dem Signieren einer Attestation und dem Schließen des Challenge-Fensters. Ich glaube nicht, dass dieses Koordinationsproblem schon eine saubere Antwort hat, und bis heute habe ich niemanden gesehen, der das gegen etwas Adversariales und Reales Stresstesten würde. Genau das ist der Teil, den man beobachten sollte, sobald tatsächlich Kapital durch dieses System fließt – nicht die Ankündigung selbst.#newt
