Proxy Contract

Herkunft und Zweck

Smart Contracts auf der Ethereum-Blockchain sind nach ihrer Bereitstellung grundsätzlich unveränderlich (immutable). Der bereitgestellte Bytecode kann nicht mehr geändert werden. Um Fehlerbehebungen oder Funktionserweiterungen zu ermöglichen, ohne den Zustand (etwa Guthaben oder Nutzerdaten) zu verlieren, verbreitete sich ab etwa 2017 bis 2018 das Proxy-Muster in der Ethereum-Entwicklergemeinde.

Der Grundgedanke ist eine Trennung von Speicher und Logik: Der Proxy-Vertrag bleibt unter einer festen Adresse erreichbar und verwaltet alle persistenten Daten, während die eigentliche Programmlogik in einem austauschbaren Implementierungs-Vertrag liegt.

Technische Funktionsweise

Zentrales Element ist die EVM-Operation delegatecall. Ruft ein Nutzer eine Funktion am Proxy auf, führt der Proxy den Code des Implementierungs-Vertrags aus, verwendet dabei jedoch seinen eigenen Speicherkontext (Storage), seine Adresse und sein Guthaben.

• Proxy-Vertrag: hält Zustand, Guthaben und die Adresse des Logik-Vertrags.
• Implementierungs-Vertrag: enthält die ausführbare Logik, aber keinen eigenen Nutzerzustand.
• Fallback-Funktion: fängt nicht direkt zugeordnete Aufrufe ab und leitet sie per delegatecall weiter.

Verbreitete Standards sind das Transparent Proxy Pattern, das UUPS-Muster (Universal Upgradeable Proxy Standard, EIP-1822) sowie EIP-1967, das feste Speicherplätze für die Implementierungsadresse definiert, um Speicherkollisionen zu vermeiden. Die Software-Bibliothek OpenZeppelin stellt hierfür häufig genutzte Referenzimplementierungen bereit.

Risiken und Kritik

Das Proxy-Muster bringt spezifische technische Herausforderungen mit sich. Eine fehlerhafte Anordnung von Variablen zwischen Proxy und Implementierung kann zu Storage-Kollisionen führen, bei denen Daten überschrieben werden. Zudem verlagert das Muster Vertrauen: Wer die Implementierungsadresse ändern darf, kann das Verhalten des Vertrags grundlegend verändern.

Aus diesem Grund werden Proxy-basierte Verträge in der Regel Gegenstand eines Smart-Contract-Audits. Prüfer achten besonders auf die Zugriffskontrolle der Upgrade-Funktion und auf die Initialisierung, da klassische Konstruktoren im Proxy-Kontext nicht wie üblich funktionieren.

Häufige Fragen

Was unterscheidet einen Proxy Contract von einem normalen Smart Contract?

Ein normaler Smart Contract enthält Daten und Logik in einer Einheit und ist nach dem Deployment unveränderlich. Ein Proxy Contract trennt beides und leitet Aufrufe an einen austauschbaren Logik-Vertrag weiter.

Was bedeutet delegatecall?

delegatecall ist eine Low-Level-Operation der Ethereum Virtual Machine, bei der der Code eines anderen Vertrags im Speicher- und Adresskontext des aufrufenden Vertrags ausgeführt wird.

Ist die Adresse eines Proxy Contracts stabil?

Ja. Die Proxy-Adresse bleibt konstant, auch wenn die dahinterliegende Logik ausgetauscht wird. Das ist ein zentraler Vorteil des Musters.

Welche Standards gibt es für Proxy Contracts?

Verbreitet sind das Transparent Proxy Pattern, das UUPS-Muster (EIP-1822) sowie EIP-1967 für standardisierte Speicherplätze der Implementierungsadresse.

Sind Proxy Contracts sicher?

Das Muster ist etabliert, erhöht aber die Komplexität. Fehler bei Storage-Layout, Initialisierung oder Zugriffskontrolle können gravierende Folgen haben, weshalb Audits üblich sind.

Weiterführende Quellen

• OpenZeppelin Dokumentation: Proxy Upgrade Pattern: docs.openzeppelin.com
• EIP-1967: Standard Proxy Storage Slots: eips.ethereum.org

Fachlich verantwortet von David Lüdtke, Finanz Forensik GmbH. Stand: 2026-08-11. Dieser Beitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung im Einzelfall.