Ich habe Zeit damit verbracht, in den Integrationsablauf einzutauchen, statt nur die Architektur zu betrachten.
Ein Detail hat meine Sicht auf das Protokoll verändert.
Ich ging davon aus, dass das Hinzufügen der Newton-Autorisierungsebene zu einem bestehenden Vertrag hauptsächlich darum geht, NewtonPolicyClient zu erben und Richtlinienprüfungen zu aktivieren.
Stattdessen ist der sensible Moment nicht das Upgrade selbst. Es ist die erste Initialisierung.
Dieser eine Aufruf entscheidet, welcher TaskManager Attestationen verifiziert und wer die zukünftige Verwaltung der Richtlinien kontrolliert.
Das Flag newtonPolicyClientInitialized verhindert, dass die Funktion zweimal ausgeführt wird, kann aber nicht garantieren, dass die ursprüngliche Konfiguration korrekt war.
Das hat mich darüber nachdenken lassen, wo sich Vertrauen tatsächlich konzentriert.
Die TEE-zu-ZKP-Pipeline stellt sicher, dass die private Richtlinienauswertung einen überprüfbaren Beweis liefert, ohne sensible Eingaben offenzulegen, aber die Kryptografie beginnt erst zu funktionieren, nachdem der Vertrag mit den richtigen Komponenten verbunden ist.
Ein sauberer Beweis kann eine falsche Initialisierung nicht beheben.
Am Ende habe ich weniger auf die Eleganz der Verifikations-Pipeline geachtet und mehr auf die operative Disziplin.
Die Empfehlung des Leitfadens, Upgrades auf einem Fork zu testen und für die Initialisierung einen Multisig oder einen Timelock zu verwenden, fühlte sich plötzlich weniger wie bewährte Praxis an und mehr wie die tatsächliche Sicherheitsgrenze.
