Zum Inhalt springen
Financial Context Wiki

Upgrades von Proxy-Verträgen überwachen

Überwachen Sie Implementierungs-, Beacon- und Kontrolländerungen bei aktualisierbaren Proxys und prüfen Sie danach Code, Speicherkompatibilität, Initialisierung, Berechtigungen und kritisches Verhalten.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung. Investitionen können zu Verlusten führen.

Direkte Antwort

Überwachen Sie neben der Proxy-Adresse auch den Kontrollpfad eines aktualisierbaren Systems. Eine Warnung sollte erkennen lassen, wer ein Upgrade genehmigen und ausführen kann, welche Verzögerung gilt, welches die alte und neue Implementierung ist und welche Initialisierungs-Calldata verwendet werden. Lesen Sie nach der Ausführung die On-Chain-Konfiguration unabhängig aus und testen Sie kritisches Verhalten.

Proxy-Adresse und Guthaben können unverändert bleiben, während delegierter Code Berechtigungen, Gebühren, Buchführung, Pausenverhalten oder Auszahlungslogik ändert. Ein früheres Audit deckt eine neue Implementierung oder deren Initialisierung nicht automatisch ab.

Funktionsweise

Bestimmen Sie zuerst das Proxy-Muster. ERC-1967 definiert getrennte Speicher-Slots für eip1967.proxy.implementation, eip1967.proxy.beacon und den optionalen eip1967.proxy.admin. Direkte Implementierungswechsel sollten Upgraded auslösen, Änderungen der Beacon-Adresse BeaconUpgraded und Änderungen des Admin-Slots AdminChanged. Bei einem Beacon-Proxy muss außerdem implementation() am Beacon aufgerufen werden, weil dieser seine Implementierung ändern kann, während der Beacon-Slot des Proxys gleich bleibt.

Leiten Sie das vollständige Berechtigungsmodell nicht aus dem Admin-Slot ab. Ein Transparent-Proxy kann über einen ProxyAdmin gesteuert werden, während die UUPS-Upgrade-Autorisierung im aktuellen Logikvertrag durch _authorizeUpgrade implementiert ist. Verfolgen Sie Eigentümer, Rollen, Multisig-Schwellenwerte, Timelocks, Governance-Verträge, Notfallpfade und die Fähigkeit, diese Kontrollen zu ändern.

Nutzen Sie sowohl Ereignisabonnements als auch regelmäßige Zustandsabfragen. ERC-1967 empfiehlt die Ereignisse, verpflichtet aber nicht jede Implementierung zu deren Ausgabe. Erfassen Sie Chain, Block, Transaktion, Proxy, Implementierung oder Beacon, Laufzeit-Code-Hash, Ausführenden und relevanten Kontrollzustand über unabhängige RPC-Endpunkte. Warnen Sie bei geplanten, abgebrochenen und ausgeführten Vorgängen und warten Sie die gewählte Bestätigungs- oder Finalitätsregel der Chain ab, bevor der Zustand als endgültig gilt.

Beispiel

Ein Lending-Proxy wird von einem 3-aus-5-Multisig über einen 24-Stunden-Timelock kontrolliert. Wird ein Upgrade geplant, erfasst die Überwachung Vorschlagskennung, Ziel, Calldata, frühesten Ausführungszeitpunkt, aktuelle und vorgeschlagene Implementierung sowie den Verifizierungsstatus des Quellcodes. Prüfer vergleichen Code und Speicherlayouts, untersuchen den Initialisierungsaufruf und prüfen Änderungen an Rollen, externen Aufrufen, Gebühren, Pausenregeln und Auszahlungspfaden.

Nach der Ausführung liest die Überwachung den betreffenden ERC-1967-Slot erneut, verifiziert den bereitgestellten Laufzeitcode und prüft erwartete Nachbedingungen wie Implementierungsversion, Administratoren oder Rolleninhaber, Pausenstatus, Vermögensbuchführung und eine schreibgeschützte Auszahlungsvorschau. Eine weitere Warnung wird ausgelöst, wenn Adresse oder Code-Hash vom geprüften Vorschlag abweichen oder regelmäßige Abfragen eine nicht per Ereignis gemeldete Änderung finden.

Risiken

  • Kontrollrisiko: Ein nominelles Multisig kann durch einen anderen Eigentümer, eine Rolle, ein Modul, einen Governor, einen Notfallschlüssel oder einen veränderbaren Timelock umgangen werden. Verfolgen Sie jeden Pfad bis zu den endgültigen Unterzeichnern und der Verzögerung.
  • Code- und Speicherrisiko: Unverifizierter Code, inkompatible Speicherlayouts, unsichere Initialisierung oder geänderte Abhängigkeiten können Zustand beschädigen oder unbeabsichtigte Rechte gewähren. Prüfen Sie das exakt bereitgestellte Artefakt, nicht nur einen Repository-Branch oder Auditnamen.
  • Überwachungsrisiko: Ein einzelner RPC, ein reiner Ereignisindexer, Frontend oder Block-Explorer kann verzögert oder falsch sein. Gleichen Sie Ereignisse, Speicher, Bytecode, Transaktionsbelege und Protokollzustand über unabhängige Datenquellen ab.
  • Reaktionsrisiko: Eine Warnung ohne Verantwortlichen und getesteten Ablauf kann zu spät eintreffen. Legen Sie fest, wer während der Verzögerung prüft, Integrationen pausiert, kommuniziert oder aussteigt, und berücksichtigen Sie zusätzliche Risiken durch übereilte Freigaben und inoffizielle Wiederherstellungslinks.

Mindestablauf:

  1. Erfassen Sie jeden Proxy, Beacon, jede Implementierung, jeden Administrator, jede Rolle und jeden Upgrade-Einstiegspunkt auf jeder Chain.
  2. Speichern Sie eine bekannte, korrekte Basis aus Slots, Code-Hashes, Kontrollzustand und kritischen schreibgeschützten Ergebnissen.
  3. Warnen Sie vor der Ausführung, wenn Governance- oder Timelock-Planung dies ermöglicht, und erneut bei Ausführung oder Abbruch.
  4. Vergleichen Sie ausgeführtes Ziel, Calldata, Implementierung, Bytecode, Speicherlayout und Zustand nach dem Upgrade mit dem geprüften Vorschlag.
  5. Eskalieren Sie unerwartete Änderungen, fehlgeschlagene Nachbedingungen, fehlende Quellcodeverifizierung oder verkürzte beziehungsweise umgangene Verzögerungen; betrachten Sie die unveränderte Proxy-Adresse nicht als Sicherheitsnachweis.

Häufige Missverständnisse

  • Mythos 1: „Upgraded zu überwachen reicht aus.“ Änderungen der Beacon-Implementierung und nicht standardisierte Proxys können die Überwachung eines anderen Vertrags oder Zustandsabfragen erfordern; Ereignisse müssen mit direkten Abfragen abgeglichen werden.
  • Mythos 2: „Der Admin-Slot zeigt, wer jedes Upgrade kontrolliert.“ Der Slot ist optional; Transparent-, UUPS-, Beacon-, Governance- und eigene Designs legen die Berechtigung in unterschiedliche Verträge und Funktionen.
  • Mythos 3: „Verifizierter Quellcode oder ein früheres Audit beweist die Sicherheit.“ Prüfen Sie für die genaue Version bereitgestellten Bytecode, Compiler- und Konstruktorannahmen, Speicherkompatibilität, Initialisierung, Konfiguration und Verhalten.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...