Zum Inhalt springen
Financial Context Wiki

Proxy-Vertrag

Ein Proxy-Vertrag leitet Aufrufe an Implementierungscode weiter, während Proxy-Adresse und Zustand erhalten bleiben. Erfahren Sie, wie Proxy-Muster funktionieren und welche Upgrade-, Speicher- und Adminrisiken entstehen.

Aktualisiert

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

Direkte Antwort

Ein Proxy-Vertrag ist ein zwischengeschalteter Vertrag, der Aufrufe an einen anderen Vertrag weiterleitet, der gewöhnlich Implementierungs- oder Logikvertrag heißt. In einer üblichen EVM-Konstruktion nutzt der Proxy delegatecall. Dadurch läuft der Code der Implementierung im Kontext des Proxys, während Zustand und Guthaben an der Proxy-Adresse verbleiben.

Diese Indirektion ermöglicht es einem System, eine stabile Adresse für Nutzer beizubehalten und zugleich die Implementierung zu wechseln. Sie kann außerdem Bereitstellungskosten senken, wenn viele Proxys denselben Code verwenden. Ein Proxy ist nicht automatisch aktualisierbar: Manche minimalen Proxys verweisen dauerhaft auf eine Implementierung, während aktualisierbare Proxys einen kontrollierten Wechsel der Implementierung oder des Beacons ermöglichen.

Nutzer müssen daher sowohl die aktive Implementierung als auch die zu Änderungen befugte Stelle beurteilen. Verifizierter Proxy-Bytecode allein sagt nicht aus, welcher Code morgen ausgeführt wird.

Funktionsweise

Wenn ein Aufruf den Proxy erreicht, kopiert oder leitet sein Fallback-Pfad die Aufrufdaten an eine Implementierung weiter. Bei delegatecall ist address(this) der Proxy, Speicherzugriffe betreffen den Proxy und die ursprünglichen Werte von msg.sender und msg.value bleiben erhalten. Anschließend gibt der Proxy die Rückgabedaten der Implementierung zurück oder macht den Aufruf gemeinsam mit ihr rückgängig.

Da Proxy-Metadaten und Anwendungszustand denselben Speicherbereich des Proxys nutzen, helfen standardisierte Speicherplätze gegen unbeabsichtigte Kollisionen. ERC-1967 definiert Plätze für Implementierungsadresse, Beacon-Adresse und einen optionalen Administrator und empfiehlt Ereignisse bei Änderungen dieser Werte. Der Standard erleichtert die Prüfung von Proxys, macht ein Upgrade allein aber nicht sicher.

Gängige Konstruktionen verorten die Upgrade-Befugnis unterschiedlich:

  • Transparenter Proxy: Der Proxy unterscheidet administrative von gewöhnlichen Nutzeraufrufen, üblicherweise über einen separaten Adminvertrag.
  • UUPS-Proxy: Die Upgrade-Logik liegt in der Implementierung, die Änderungen autorisieren und mit der erwarteten Upgrade-Schnittstelle kompatibel bleiben muss.
  • Beacon-Proxy: Der Proxy fragt einen Beacon nach seiner Implementierung; die Änderung eines Beacons kann alle ihm folgenden Proxys betreffen.
  • Minimaler Klon: Viele kleine Proxys delegieren an gemeinsamen Code, häufig ganz ohne Upgrade-Pfad.

Beispiel

Angenommen, ein Vault-Proxy hält Nutzerguthaben und delegiert an Implementierung A. Nutzer zahlen über die Proxy-Adresse ein, und der Code von Implementierung A aktualisiert die Guthabeneinträge im Speicher des Proxys.

Später ändert die Governance den ERC-1967-Implementierungsplatz auf Implementierung B. Proxy-Adresse und erfasste Guthaben werden nicht verschoben, doch künftige Aufrufe führen den Code von B aus. Wenn B die Speicheranordnung beibehält und die vorgesehenen Regeln umsetzt, erhalten Nutzer an derselben Adresse neues Verhalten.

Ordnet B Speichervariablen neu, lässt eine Berechtigungsprüfung aus oder fügt einen vom Upgrader kontrollierten Auszahlungspfad hinzu, kann dasselbe Upgrade die Buchführung beschädigen oder Vermögenswerte gefährden. Operativ ist daher nicht nur wichtig, ob ein Vertrag ein Proxy ist, sondern wer seinen Ausführungspfad mit welcher Verzögerung und Prüfung ändern kann.

Risiken

  • Kompromittierter Upgrade-Schlüssel: Ein Administrator, eine Multisig oder ein Governance-Verfahren kann bösartigen oder fehlerhaften Code installieren.
  • Inkompatible Speicheranordnung: Änderungen an Reihenfolge, Typen oder Vererbung von Variablen können dazu führen, dass neuer Code den bestehenden Zustand falsch liest oder überschreibt.
  • Fehlgeschlagene Initialisierung: Konstruktoren initialisieren den Proxy-Speicher nicht. Fehlender oder wiederholbarer Initialisierungsschutz kann einem anderen Konto privilegierte Rollen verschaffen.
  • Unerwartete Aufrufweiterleitung: Selektorkollisionen, adminspezifische Pfade oder ein unerwarteter Beacon können einen anderen Ausführungspfad als die sichtbare Schnittstelle bewirken.
  • Großer Wirkungsbereich gemeinsamer Upgrades: Eine Entscheidung zu einem Beacon oder einer Implementierung kann viele Vertragsinstanzen gleichzeitig verändern.

Vor Einzahlungen oder Genehmigungen sollten Sie die aktuelle Implementierung oder den Beacon on-chain ermitteln, Upgrade-Befugnis und Timelock feststellen, verifizierten Quellcode und Speicherkompatibilität prüfen sowie gegebenenfalls aktuelle Ereignisse Upgraded, BeaconUpgraded und AdminChanged untersuchen. Da sich der Ausführungspfad ändern kann, bleibt Überwachung auch nach der ersten Prüfung erforderlich.

Häufige Missverständnisse

  • „Der Proxy speichert keinen bedeutsamen Zustand.“ Bei delegatecall gehören Anwendungszustand und häufig auch Vermögenswerte zum Proxy, obwohl die Logik von einer anderen Adresse stammt.
  • „Eine verifizierte Implementierung macht das System vertrauensfrei.“ Upgrade-Schlüssel, Governance, Beacons, Initialisierung und künftige Implementierungen bleiben Teil des Vertrauensmodells.
  • „Jeder Proxy kann aktualisiert werden.“ Klone und andere feste Proxys können dauerhaft delegieren; die Aktualisierbarkeit hängt von der konkreten Konstruktion und dem Autorisierungscode ab.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...