Zum Inhalt springen
Financial Context Wiki

Upgradefähiger Smart Contract

Ein upgradefähiger Smart Contract behält Adresse und Zustand eines Proxys bei, während berechtigte Akteure seine Implementierung ersetzen oder umleiten. Diese Flexibilität bringt Speicher-, Initialisierungs-, Governance- und Überwachungsrisiken mit sich.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage- oder Sicherheitsberatung. Upgradefähigkeit kann privilegierten Akteuren erlauben, das Vertragsverhalten zu ändern, und zu Verlusten führen.

Direkte Antwort

Ein upgradefähiger Smart Contract ist ein bereitgestelltes System, dessen wirksame Logik geändert werden kann, ohne Nutzer auf eine neue Hauptadresse zu verschieben oder den dort gespeicherten Zustand aufzugeben. Auf Ethereum-kompatiblen Netzen hält meist ein Proxy den Zustand und leitet Aufrufe per delegatecall an einen Implementierungsvertrag weiter. Ein berechtigtes Upgrade wechselt die Implementierung; Proxyadresse, Speicher und Guthaben bleiben bestehen.

Dabei wird kein unveränderlicher Bytecode umgeschrieben, sondern eine Indirektion vorgeschaltet. Sie kann Fehler beheben und Funktionen ergänzen, schafft aber auch einen privilegierten Pfad, der Auszahlungen, Gebühren, Rechte oder Buchführung ändern kann. Zu bewerten sind daher aktueller Code und Regeln für künftigen Code.

Nicht jeder Proxy ist upgradefähig und nicht jedes veränderliche System nutzt einen Proxy. Manche Projekte stellen neue Verträge bereit und migrieren den Zustand, andere deaktivieren Upgrades dauerhaft. Entscheidend sind die tatsächliche On-Chain-Architektur und Befugnis.

Funktionsweise

Der Aufrufer sendet an den Proxy. Dieser liest eine Implementierungsadresse und führt deren Code per delegatecall im Speicherkontext des Proxys aus. Der Code stammt aus der Implementierung, doch Zugriffe wirken auf den Proxy; ursprünglicher Absender und Wert bleiben erhalten. ERC-1967 normiert Implementierungs-, Beacon- und Admin-Slots.

Transparente Proxys verwalten Upgrades im Proxy und trennen Admin- von Nutzeraufrufen. UUPS-Proxys legen die Upgradelogik in die Implementierung und nutzen ERC-1822-Kompatibilität, weshalb die Autorisierung dort kritisch ist. Beacon-Proxys beziehen ihre Implementierung von einem Beacon; ein Update kann viele Proxys ändern.

Zustandskompatibilität ist die zentrale Einschränkung. Umordnen, Entfernen oder Typänderungen von Variablen sowie geänderte Vererbung können Daten beschädigen. Nur erweiterte Layouts, reservierte Lücken oder ERC-7201-Namensräume helfen, ersetzen aber keine Versionsprüfung.

Konstruktoren initialisieren die Implementierung, nicht den Proxyspeicher. Daher wird gewöhnlich einmal ein Initialisierer wie initialize aufgerufen. Direkte Initialisierung der Implementierung sollte gesperrt sein; spätere Migrationen brauchen eng begrenzte Reinitialisierer. Ein öffentlicher oder wiederholbarer Initialisierer kann Kontrolle übertragen.

Ein belastbarer Ablauf lautet:

  1. Quellen, Compiler, Abhängigkeiten, Layouts, Adressen und erwarteten Bytecode beider Implementierungen fixieren.
  2. Delta, Speicherkompatibilität, Initialisierung oder Migration, Autorisierung, Abhängigkeiten und Rollback prüfen; die gesamte Transaktion auf einem Fork testen.
  3. Vorschlag und Adresse veröffentlichen und angekündigte Multisig-, Governance- und Timelock-Regeln ohne versteckten Bypass durchsetzen.
  4. Ausführen und Implementierungs- oder Beacon-Slot, Ereignisse, Bytecode, initialisierten Zustand, Rollen und Invarianten an einem protokollierten Block prüfen.
  5. Slot-, Rollen- und Parameteränderungen überwachen und Vorfälle planen, ohne einen stets sicheren Rollback anzunehmen.

Beispiel

Ein Kreditprotokoll benötigt eine neue Rückzahlungsfunktion. Sein Proxy delegiert an Implementierung A. Das Team stellt B bereit, bestätigt, dass B Speicher nur anhängt, und bereitet die Migration vor. Die Governance veröffentlicht den Bytecode und stellt das Upgrade hinter einen Timelock von 48 Stunden. Danach delegiert dieselbe Adresse an B; bestehende Salden bleiben im Proxy.

Nutzer sollten prüfen, dass der Slot von A zu B wechselte, die Migration einmal lief und Rollen sowie Salden stimmen. Kann ein Wächter den Timelock umgehen oder ein Unterzeichner B durch beliebigen Code ersetzen, gehört diese Macht trotz regulärem Verfahren zum Vertrauensmodell.

Risiken

  • Privilegierter Austausch: Admin, Multisig, Governor oder kompromittierter Schlüssel können bösartige oder fehlerhafte Logik installieren.
  • Speicherbeschädigung: Ein inkompatibles Layout kann Salden, Eigentümer, Mappings oder Buchungsdaten falsch deuten.
  • Initialisierungsfehler: Ein fehlender, wiederholter oder offener Initialisierer kann das System blockieren oder Kontrolle übertragen.
  • Musterspezifischer Fehler: Transparent-, UUPS-, Beacon- und eigene Proxys scheitern unterschiedlich; der Name beweist keine Korrektheit.
  • Schein-Governance: Timelock oder Abstimmung können Notfall-Bypass, kurze Frist, konzentrierte Stimmen oder schwache Signierer haben.
  • Unsichere Migration oder Rückkehr: Zustand kann irreversibel werden; alter Code stellt nicht zwingend alte Bedeutung her.
  • Verifikationslücke: Verifizierter Implementierungscode beweist weder Proxyziel noch erwarteten Admin oder Initialzustand.
  • Überwachungs- und Integrationsrisiko: Explorer, Oberflächen, Prüfer und Integrationen können einer alten Implementierung folgen oder ein Beacon-Update verpassen.

Häufige Missverständnisse

  • „Der Vertrag an dieser Adresse ist unveränderlich.“ Proxy-Bytecode kann unveränderlich sein, während Implementierungs- oder Beacon-Slot das Verhalten ändern.
  • „Ein Multisig dezentralisiert Upgrades.“ Das gilt nur bei unabhängigen Signierern, tragfähiger Schwelle, sicherem Betrieb und Ersatzregeln.
  • „Ein Timelock verhindert bösartige Upgrades.“ Er schafft Beobachtungs- und Ausstiegszeit, macht Code aber nicht sicher.
  • „Eine bestandene Speicherprüfung beweist Sicherheit.“ Sie deckt Layout ab, nicht Logik, Autorisierung, Orakel, Migration oder Ökonomie.
  • „Upgradeverzicht beseitigt immer die Kontrolle.“ Admin, Beacon, Governor, UUPS-Autorisierung und Alternativpfade müssen on-chain geprüft werden.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...