@NewtonProtocol Je mehr ich den Upgrade-Pfad von Newton studierte, desto weniger sah ich darin eine einfache Integrationsanleitung und desto mehr erkannte ich es als eine Lektion darüber, wohin sich Vertrauen tatsächlich verlagert.
Auf den ersten Blick wirkt die Architektur elegant. Bestehende upgradebare Verträge müssen nicht aufgegeben werden. Die Geschäftslogik bleibt unverändert, der Speicher bleibt erhalten, und die Autorisierung kann schrittweise eingeführt werden, statt eine teure Migration erzwingen zu müssen.
Das klingt nach modularer Sicherheit, die richtig gemacht ist.
Aber je tiefer ich schaute, desto mehr wurde mir klar: Modularität beseitigt kein Risiko – sie komprimiert es.
Das Proxy-Upgrade, die Storage-Migration und die Initialisierungs-Transaktion werden plötzlich zu den sicherheitskritischsten Momenten im Lebenszyklus des Contracts.
Ein einzelner Fehler im Storage kann den Zustand beschädigen, ohne sofort offensichtliche Ausfälle offenzulegen.
Eine einzige falsche TaskManager-Adresse kann dazu führen, dass jede zukünftige Attestation fehlschlägt.
Ein einzelner falscher Policy-Client-Owner kann die langfristige Governance in die falschen Hände legen.
Das Initialisierungs-Flag ist ein interessantes Beispiel. Es verhindert erfolgreich, dass der Contract zweimal initialisiert wird, aber es schafft auch eine andere Realität: Die allererste erfolgreiche Initialisierung wird in der Praxis unumkehrbar. Das Flag garantiert Eindeutigkeit – nicht Korrektheit.
Diese Unterscheidung ist entscheidend.
Ich habe außerdem noch eine weitere subtile Grenze gefunden, die mehr Aufmerksamkeit verdient.
Wenn man Newton hinzufügt, werden nicht automatisch alle Ausführungspfade abgesichert. Legacy-Funktionen bleiben genau so sicher – oder unsicher – wie zuvor, es sei denn, sie erfordern explizit vor der Ausführung sensibler Logik „_validateAttestation“ oder „_validateAttestationDirect“.
Anders gesagt: Der Contract kann Newton enthalten, während er dennoch älteren Pfaden erlaubt, die Durchsetzung von Richtlinien zu umgehen.
Das ist eine architektonische Nuance, die bei Upgrades leicht übersehen werden kann.
Für mich liegt die größte Stärke von Newton nicht nur in der Autorisierung. Es ist die selektive Übernahme. Teams können kritische Funktionen schützen, ohne ein komplettes Protokoll neu zu entwerfen.
Aber selektive Übernahme erfordert auch selektives Auditing.
Jeder geschützte Pfad muss verifiziert werden.
Jeder Legacy-Pfad muss überprüft werden.
Jeder Initialisierungsparameter verdient eine genaue Prüfung.
Die Technologie macht die Autorisierung einfacher bereitzustellen.
Die Verantwortung, sie korrekt bereitzustellen, wird noch stärker konzentriert.
Manchmal wird Sicherheit nicht durch den neuen Code definiert, den man hinzufügt.
Sie wird durch die Handvoll Entscheidungen definiert, die man nur einmal treffen darf.