Eine rechtzeitige Reparatur spart neunmal so viel.
Beim ersten Mal, als mir klar wurde, dass ein Upgrade ein einzelner Punkt für Ausfälle sein kann, war ich nicht einmal die Person, die den Button gedrückt hat. Ich war um 2 Uhr morgens in einem Call und habe zugesehen, wie ein Team auf einem Fork ein Proxy-Upgrade simulierte. Alles verlief erfolgreich. Dann bemerkte jemand, dass die Abbildung des Governance-Token-Balancestands für jeden Holder `0` zurückgab. Eine Verschiebung in einem Storage-Slot – und sechs Monate Zustand wirkten wie eine Geisterkette. Wir haben diese Nacht nichts ausgeliefert. Diese Erinnerung ist der Grund, warum ich Newtons Integrationsanleitung heute anders lese.
Ich habe darüber nachgedacht, was es im Grunde bedeutet, einer bereits live geschalteten Anwendung eine Autorisierungsebene hinzuzufügen. Ich erinnere mich daran, als ich das erste Mal ein Proxy-Upgrade im Mainnet in die Warteschlange gestellt habe. Der Vorschlag wurde angenommen, der Timelock lief herunter, und plötzlich hingen alle zukünftigen Aufrufe an einem 20-zeiligen Diff und einer einzigen `initialize()`-Tx. Dieses Gefühl ist mir geblieben.
Das Integrationshandbuch von Newton zeigt, wie ein bestehender upgradefähiger Vertrag `NewtonPolicyClient` über ein Proxy-Upgrade übernehmen kann, während bestehender Storage und Geschäftslogik erhalten bleiben. Nach dem Upgrade kann eine eigentümerkontrollierte Funktion den Newton-Client initialisieren, und ausgewählte Ausführungspfade können damit beginnen, gültige Attestierungen anzufordern, bevor sie fortfahren.
Zuerst sah das aus wie saubere Modularität.
Die Anwendung muss nicht von Anfang an rund um Newton neu aufgebaut werden. Durchsetzung von Richtlinien kann später eingeführt werden, was für Verträge relevant ist, die bereits Zustand halten und nicht einfach von Null aus neu bereitgestellt werden können.
Aber das Handbuch macht die Migrationsbedingungen ungewöhnlich spezifisch. Neue Storage-Variablen müssen an das bestehende Storage-Layout angehängt werden, anstatt in es hineingeschoben zu werden. Ich habe gesehen, wie ein Team einen Fork „bricked“, indem es ein neues `uint256` in die Mitte eines gepackten Slots schob — die Tests waren grün, die Autorisierung sah in Ordnung aus, und zwei Variablen weiter unten lieferte eine Mapping-Struktur plötzlich Müll zurück. Das Beispiel von Newton führt außerdem ein spezielles `_newtonPolicyClientInitialized`-Flag ein, um zu verhindern, dass die Post-Upgrade-Initialisierungsfunktion mehr als einmal aufgerufen wird. Das Handbuch empfiehlt, das Upgrade gründlich auf einem Fork zu testen und für den Initialisierungsaufruf einen Timelock oder ein Multisig in Betracht zu ziehen.
Auffällig war nicht nur die Möglichkeit, Richtlinienprüfungen nachträglich einzubauen.
Es war, wie stark sich die Sicherheit um den Upgrade- und Initialisierungsprozess konzentriert.
Vor der Initialisierung kann der upgradefähige Vertrag zwar die Autorisierungslogik von Newton enthalten, aber sein Policy-Client ist noch nicht mit dem vorgesehenen TaskManager verbunden oder dem vorgesehenen Policy-Client-Owner zugewiesen. Newton weist darauf hin, dass die Verwendung der falschen TaskManager-Adresse dazu führen kann, dass die Attestation-Validierung fehlschlägt, während der Policy-Client-Owner wichtige Policy-Management-Funktionen kontrolliert. Deshalb ist das One-Time-Flag so entscheidend.
Es verhindert, dass die Beispiel-Initialisierungsfunktion wiederholt ausgeführt wird, aber es macht auch den ersten erfolgreichen Aufruf besonders empfindlich. Ein Flag kann eine Reinitialisierung stoppen; es kann nicht bestätigen, dass die Adressen, die im ursprünglichen Aufruf angegeben wurden, korrekt waren. Ich habe das selbst gesehen: Ein falsches Byte in einem Multisig-Payload, und das „initialized“-Flag springt in einem fehlkonfigurierten System um. Kein Revert. Keine zweite Chance.
Gleichzeitig friert die Initialisierung nicht dauerhaft jede Komponente der Newton-Konfiguration ein. Der Eigentümer des Policy-Clients kann später die Policy-Konfiguration setzen oder aktualisieren, die Adresse des Policy-Vertrags ändern und die Ownership des Policy-Clients über die von `NewtonPolicyClient` bereitgestellten Funktionen übertragen. Die Storage-Regel birgt ein anderes Risiko.
Newton kann hinzugefügt werden, ohne die gesamte Geschäftslogik der Anwendung zu ersetzen, aber das Proxy-Upgrade muss trotzdem das vorherige Storage-Layout beibehalten. Fügt man neue Variablen an der falschen Stelle ein, kann der Autorisierungscode korrekt integriert erscheinen, während darunter ein verwandter Zustand des Vertrags beschädigt wird.
Es gibt noch eine andere Grenze, die wichtig ist.
Das Hinzufügen einer neuen Newton-geschützten Funktion sichert nicht automatisch eine ältere Funktion ab, die weiterhin dieselbe Aktion ohne Validierung des Attestations offenlegt. Der relevante Ausführungspfad muss tatsächlich `validateAttestation` oder `validateAttestationDirect` anfordern, bevor die geschützte Geschäftslogik läuft. Newton warnt ausdrücklich, dass die Validierung vor der Ausführung stattfinden muss. Ich habe Verträge geprüft, bei denen die neue „admin only“-Funktion vollständige Policy-Checks hatte, während die alte legacy emergencyWithdraw() aus v1 dort ungeschützt herumlag. Gleicher Proxy, zwei Realitäten.
Die Designstärke ist weiterhin real. Die Trennung von NewtonPolicyClient von der ursprünglichen Anwendungslogik macht eine schrittweise Einführung möglich. Bestehende Geschäftslogik kann weitgehend beibehalten werden, während ausgewählte Ausführungspfade so geändert oder erweitert werden, dass eine Policy-Genehmigung erforderlich ist.
Das ist weniger störend, als jede Anwendung in eine völlig neue Vertragsarchitektur zu zwingen.
Der Teil, der noch nicht geklärt ist, ist, ob diese Modularität das Upgrade-Risiko reduziert oder die Aufmerksamkeit auf eine kleinere Anzahl ungewöhnlich sensibler Schritte bündelt.
Newton erleichtert die Einführung der Autorisierung in einen bestehenden upgradefähigen Vertrag.
Aber macht das auch das Proxy-Upgrade, die Storage-Migration und den ersten Initialisierungsaufruf zu den folgenreichsten Autorisierungsentscheidungen in der gesamten Integration?
#Newt #Newt @NewtonProtocol $NEWT
