Mein Onkel betrieb früher eine kleine Werkstatt, und er hatte diese Regel: Jede Maschine musste von zwei Personen überprüft werden, bevor sie versendet wurde—eine, die sie gebaut hat, und eine, die sie nie angefasst hat. Er sagte, ein einzelnes Paar Augen übersieht immer den Teil, den es selbst gebaut hat.
Ich habe über diese Regel nachgedacht, während ich gelesen habe, wie Newton die Ausführung von Agenten handhabt. Die meisten Automatisierungstools fordern von dir, dem Code zu vertrauen, der deinen Handel ausführt—voll und ganz. Newton teilt die Aufgabe stattdessen in zwei getrennte Prüfungen. Eine Trusted Execution Environment erledigt die eigentliche Arbeit außerhalb der Kette, abgedichtet, sodass niemand—nicht einmal der Betreiber—während der Ausführung hineinschauen kann. Danach wird ein Zero-Knowledge-Beweis erzeugt, der bestätigt, dass das Ergebnis den Regeln entsprach, ohne das private Eingabeformat, das dafür verwendet wurde, noch einmal abzuspielen oder offenzulegen. Zwei unterschiedliche Technologien, zwei unterschiedliche Fehlermodi—die jeweils die Schwächen des anderen abprüfen.
Das ist keine günstige Design-Entscheidung. TEEs sind zwar schnell, hängen aber davon ab, dass Hardwarehersteller ehrlich handeln und die Firmware unbeschädigt bleibt. ZK-Beweissysteme sind mathematisch wasserdicht, aber teuer in der Erstellung und die Tooling-Landschaft reift noch. Ein Team, das auf einen schnellen Launch optimiert, wählt eines aus und betrachtet es als erledigt. Newton läuft beides—damit übernimmt es weder die Schwächen der einen noch die der anderen Technologie, aber trägt gleichzeitig den Engineering-Aufwand, zwei Verifikations-Stacks parallel zu pflegen.
Hier sind 3 Dinge besonders aufgefallen. Erstens: Die TEE übernimmt vertrauliche Berechnungen wie private Strategieparameter—damit hat ein reines ZK-„Circuit“ heute noch Schwierigkeiten, das effizient umzusetzen. Zweitens: Die ZK-Schicht erzeugt einen Beweis, den Dritte verifizieren können, ohne der Hardware erneut vertrauen zu müssen, und schließt damit die Lücke, die TEEs allein offenlassen. Drittens: Diese Kombination ist unter Automatisierungsprotokollen noch immer selten; die meisten setzen auf eine Methode und erklären sie für ausreichend.
Newton setzt nicht darauf, dass eine einzelne Verifikationstechnologie genügt. Es behandelt TEEs und ZK-Beweise als Ergänzungen, die jeweils das abfangen, was das andere verpasst—und diese geschichtete Redundanz ist das eigentliche Produkt, nicht nur ein Randvermerk in der Architektur.
@NewtonProtocol #Newt $NEWT $LAB $VELVET
Ich habe über diese Regel nachgedacht, während ich gelesen habe, wie Newton die Ausführung von Agenten handhabt. Die meisten Automatisierungstools fordern von dir, dem Code zu vertrauen, der deinen Handel ausführt—voll und ganz. Newton teilt die Aufgabe stattdessen in zwei getrennte Prüfungen. Eine Trusted Execution Environment erledigt die eigentliche Arbeit außerhalb der Kette, abgedichtet, sodass niemand—nicht einmal der Betreiber—während der Ausführung hineinschauen kann. Danach wird ein Zero-Knowledge-Beweis erzeugt, der bestätigt, dass das Ergebnis den Regeln entsprach, ohne das private Eingabeformat, das dafür verwendet wurde, noch einmal abzuspielen oder offenzulegen. Zwei unterschiedliche Technologien, zwei unterschiedliche Fehlermodi—die jeweils die Schwächen des anderen abprüfen.
Das ist keine günstige Design-Entscheidung. TEEs sind zwar schnell, hängen aber davon ab, dass Hardwarehersteller ehrlich handeln und die Firmware unbeschädigt bleibt. ZK-Beweissysteme sind mathematisch wasserdicht, aber teuer in der Erstellung und die Tooling-Landschaft reift noch. Ein Team, das auf einen schnellen Launch optimiert, wählt eines aus und betrachtet es als erledigt. Newton läuft beides—damit übernimmt es weder die Schwächen der einen noch die der anderen Technologie, aber trägt gleichzeitig den Engineering-Aufwand, zwei Verifikations-Stacks parallel zu pflegen.
Hier sind 3 Dinge besonders aufgefallen. Erstens: Die TEE übernimmt vertrauliche Berechnungen wie private Strategieparameter—damit hat ein reines ZK-„Circuit“ heute noch Schwierigkeiten, das effizient umzusetzen. Zweitens: Die ZK-Schicht erzeugt einen Beweis, den Dritte verifizieren können, ohne der Hardware erneut vertrauen zu müssen, und schließt damit die Lücke, die TEEs allein offenlassen. Drittens: Diese Kombination ist unter Automatisierungsprotokollen noch immer selten; die meisten setzen auf eine Methode und erklären sie für ausreichend.
Newton setzt nicht darauf, dass eine einzelne Verifikationstechnologie genügt. Es behandelt TEEs und ZK-Beweise als Ergänzungen, die jeweils das abfangen, was das andere verpasst—und diese geschichtete Redundanz ist das eigentliche Produkt, nicht nur ein Randvermerk in der Architektur.
@NewtonProtocol #Newt $NEWT $LAB $VELVET