Je mehr ich Newtons Integrationsanleitung lese, desto mehr wurde mir klar, dass das Hinzufügen einer Autorisierungsebene nicht wirklich der schwierige Teil ist.
Der kritische Teil ist alles, was rund um das Upgrade selbst passiert.
Einer Sache, die ich schätze, ist, dass Newton Entwickler nicht zwingt, eine Anwendung von Grund auf neu aufzubauen. Ein bestehender upgradebarer Vertrag kann NewtonPolicyClient über ein Proxy-Upgrade vererben und dabei seinen bestehenden Speicher und seine Geschäftslogik intakt halten. Nach dem Upgrade kann der Besitzer den Newton-Client initialisieren und nach und nach Attestierungsprüfungen nur dort einführen, wo sie tatsächlich benötigt werden.
Diese Art von Flexibilität ist wertvoll.
Für Anwendungen, die bereits Assets verwalten oder lang laufenden Zustand haben, ist es oft nicht realistisch, einen komplett neuen Vertrag neu bereitzustellen. Die Möglichkeit, später Policy-Durchsetzung hinzuzufügen, macht eine Einführung viel praktikabler.
Aber der Migrationsprozess ist überraschend streng.
Das Storage-Layout muss unangetastet bleiben. Alle neuen Variablen müssen angehängt werden, nicht eingefügt. Newton empfiehlt außerdem ein dediziertes Initialisierungs-Flag, damit die Setup-Funktion nur einmal ausgeführt werden kann, zusammen mit gründlichen Tests auf einem Fork sowie der Verwendung eines Timelocks oder Multisigs für die Initialisierungs-Transaktion.
Diese Empfehlungen haben mich innehalten lassen.
Der eigentliche Sicherheitsfokus liegt nicht nur in der Autorisierungslogik, sondern auch in dem Upgrade- und Initialisierungsprozess darum herum.
Vor der Initialisierung kann der aktualisierte Vertrag bereits Newtons Code enthalten, aber er ist dennoch nicht mit dem beabsichtigten TaskManager verbunden oder mit dem richtigen Policy-Client-Owner konfiguriert. Wenn eine der Adressen falsch ist, kann die Attestierungsvalidierung fehlschlagen oder die Policy-Verwaltung könnte unter die falsche Kontrolle geraten.
Deshalb ist das One-Time-Initialisierungs-Flag so wichtig.
Es schützt davor, dass das Setup zweimal ausgeführt wird, garantiert aber nicht, dass die erste Ausführung korrekt war. Wenn im Rahmen dieses ersten Calls falsche Adressen bereitgestellt werden, kann das Verhindern einer erneuten Initialisierung den ursprünglichen Fehler nicht beheben.
Interessant ist, dass die Initialisierung nicht alles dauerhaft sperrt.
Der Policy-Client-Owner kann weiterhin Policy-Einstellungen aktualisieren, den Policy-Vertrag ändern oder später den Ownership-Status übertragen – über die von NewtonPolicyClient freigegebenen Funktionen. Daher ist die Initialisierung zwar entscheidend, aber nur der Beginn des gesamten Autorisierungs-Lifecycle des Vertrags.
Ein weiterer Punkt, der auffiel, ist die Storage-Sicherheit.
Newton erlaubt Entwicklern, bestehende Verträge zu erweitern, statt sie zu ersetzen, aber Proxy-Upgrades setzen dennoch auf das Beibehalten des exakten Storage-Layouts. Eine falsch platzierte Storage-Variable kann den bestehenden Vertragszustand still und heimlich beschädigen, selbst wenn die Autorisierungsebene selbst so aussieht, als würde sie perfekt funktionieren.
Da gibt es noch einen weiteren subtilen Punkt.
Das bloße Hinzufügen einer neuen Newton-geschützten Funktion sichert nicht automatisch ältere Ausführungspfade ab, die dieselbe Aktion ausführen. Jeder sensible Pfad muss explizit validateAttestation oder validateAttestationDirect aufrufen, bevor Geschäftslogik ausgeführt wird. Autorisierung funktioniert nur dort, wo die Validierung tatsächlich durchgesetzt wird.
Insgesamt denke ich, dass Newtons modulares Design eine seiner größten Stärken ist.
Es ermöglicht Entwicklern, die Policy-Durchsetzung schrittweise einzuführen, statt eine vollständige Architektur-Neufassung erzwingen zu müssen. Bestehende Anwendungen können die meiste ihrer Logik beibehalten und gleichzeitig gezielt höher riskante Operationen schützen.
Was ich noch im Kopf habe, ist der Trade-off.
Reduziert dieser modulare Ansatz tatsächlich das Upgrade-Risiko, oder bündelt er eine enorme Menge an Vertrauen in nur wenige kritische Momente – das Proxy-Upgrade, die Storage-Migration und diese allererste Initialisierungs-Transaktion?
Newton macht die Einführung von Autorisierung deutlich einfacher.
Die größere Frage ist, ob diese wenigen Setup-Schritte zu den wichtigsten Sicherheitsentscheidungen in der gesamten Integration werden.
#Newt @NewtonProtocol $NEWT #NEWT
