Aktualisierung von Smart Contracts

Smart Contracts auf Ethereum sind selbstausführende Programme, die in der Ethereum Virtual Machine (EVM) laufen. Diese Programme sind von vornherein unveränderlich, sodass sich die Geschäftslogik nach der Veröffentlichung des Vertrags nicht mehr aktualisieren lässt.

Zwar ist die Unveränderlichkeit für die Vertrauenslosigkeit, Dezentralisierung und Sicherheit von Smart Contracts unabdinglich, sie kann jedoch in bestimmten Fällen ein Nachteil sein. So kann unveränderlicher Code es den Entwicklern unmöglich machen, anfällige Verträge zu reparieren.

Die zunehmende Forschung zur Verbesserung von Smart Contracts hat jedoch zur Einführung verschiedener Upgrade-Muster geführt. Diese Upgrade-Muster ermöglichen es Entwicklern, Smart Contracts zu aktualisieren (unter Beibehaltung der Unveränderlichkeit), indem sie die Geschäftslogik in verschiedenen Verträgen unterbringen.

Voraussetzungen

Sie sollten ein gutes Verständnis von Smart Contracts, der Anatomie von Smart Contracts und der Ethereum Virtual Machine (EVM) haben. In diesem Leitfaden wird außerdem davon ausgegangen, dass die Leser über Kenntnisse in der Programmierung von Smart Contracts verfügen.

Was ist ein Smart-Contract-Upgrade?

Bei einem Smart-Contract-Upgrade wird die Geschäftslogik eines Smart Contracts geändert, wobei der Zustand des Vertrags erhalten bleibt. Es ist wichtig, klarzustellen, dass Aktualisierbarkeit und Veränderbarkeit nicht dasselbe sind, insbesondere im Zusammenhang mit Smart Contracts.

Sie können ein Programm, das auf einer Adresse im Ethereum-Netzwerk veröffentlicht wird, trotzdem nicht ändern. Aber Sie können den Code ändern, der ausgeführt wird, wenn Benutzer mit einem Smart Contract interagieren.

Dies kann mit den folgenden Methoden geschehen:

1. Erstellung mehrerer Versionen eines Smart Contracts und Migration des Zustands (d. h. der Daten) vom alten Vertrag auf eine neue Instanz des Vertrags.

2. Erstellung separater Verträge zur Speicherung der Geschäftslogik und des Status.

3. Verwendung von Proxy-Mustern, um Funktionsaufrufe von einem unveränderlichen Proxy-Vertrag an einen modifizierbaren Logik-Vertrag zu delegieren.

4. Erstellung eines unveränderlichen Haupt-Vertrags, der über Schnittstellen mit flexiblen Satelliten-Verträgen verbunden ist und sich auf diese stützt, um bestimmte Funktionen auszuführen.

5. Verwendung des Diamond-Musters, um Funktionsaufrufe von einem Proxy-Vertrag an Logik-Verträge zu delegieren.

Upgrade-Mechanismus #1: Vertragsmigration

Die Migration von Verträgen basiert auf Versioning – also der Erstellung und Verwaltung eindeutiger Zustände derselben Software. Bei der Vertragsmigration wird eine neue Instanz eines bestehenden Smart Contracts veröffentlicht, wobei Speicher und Guthaben auf den neuen Vertrage übergehen.

Der neu veröffentlichte Vertrag hat einen leeren Speicher, sodass Sie Daten aus dem alten Vertrag wiederherstellen und in die neue Implementierung schreiben können. Danach müssen Sie alle Verträge, die mit dem alten Vertrag interagierten, auf die neue Adresse umstellen.

Der letzte Schritt der Vertragsmigration besteht darin, die Benutzer davon zu überzeugen, den neuen Vertrag zu nutzen. In der neuen Vertragsversion bleiben die Guthaben und Adressen der Benutzer erhalten, so dass die Unveränderlichkeit gewahrt bleibt. Wenn es sich um einen Token-basierten Vertrag handelt, müssen Sie sich auch mit den Börsen in Verbindung setzen, um den alten Vertrag zu verwerfen und mit dem neuen Vertrag zu ersetzen.

Die Migration von Verträgen ist eine relativ einfache und sichere Maßnahme, um Smart Contracts zu aktualisieren, ohne die Interaktionen der Nutzer zu unterbrechen. Die manuelle Migration von Speicher und Guthaben der Benutzer auf den neuen Vertrag ist jedoch zeitaufwändig und kann hohe Gaskosten verursachen.

Mehr über Vertragsmigration. (opens in a new tab)

Upgrade-Mechanismus #2: Datentrennung

Eine weitere Methode zur Aktualisierung von Smart Contracts ist die Aufteilung der Geschäftslogik und des Datenspeichers auf separate Verträge. Das bedeutet, dass die Benutzer mit den Logikverträgen interagieren, die Daten aber im Speichervertrag gesichert werden.

Der Logikvertrag enthält den Code, der ausgeführt wird, wenn Benutzer mit der Anwendung interagieren. Er enthält auch die Adresse des Speichervertrags und interagiert mit diesem, um Daten zu erhalten und einzustellen.

In der Zwischenzeit sichert der Speichervertrag den mit dem Smart Contract verbundenen Status, wie z. B. Benutzerguthaben und Adressen. Beachten Sie dabei, dass der Speichervertrag Eigentum des Logikvertrags ist und bei der Veröffentlichung mit der Adresse des Logikvertrags konfiguriert wird. Dadurch wird verhindert, dass nicht autorisierte Verträge den Speichervertrag aufrufen oder seine Daten aktualisieren.

Standardmäßig ist der Speichervertrag unveränderlich, aber Sie können den Logikvertrag, auf den er verweist, durch eine neue Implementierung ersetzen. Dadurch wird der Code, der in der EVM läuft, verändert, wobei sowohl der Speicher als auch die Guthaben intakt bleiben.

Bei dieser Upgrade-Methode muss die Adresse des Logikvertrags im Speichervertrag aktualisiert werden. Außerdem müssen Sie den neuen Logikvertrag aus den bereits erläuterten Gründen mit der Adresse des Speichervertrags konfigurieren.

Das Muster der Datentrennung ist im Vergleich zur Vertragsmigration einfacher zu implementieren. Allerdings müssen Sie mehrere Verträge verwalten und komplexe Autorisierungssysteme implementieren, um Smart Contracts vor böswilligen Upgrades zu schützen.

Upgrade-Mechanismus #3: Proxy-Muster

Für Proxy-Muster kommt ebenfalls eine Datentrennung zur Anwendung, um die Geschäftslogik und die Daten in getrennten Verträgen zu halten. Bei einem Proxy-Muster hingegen ruft der Speichervertrag (Proxy genannt) den Geschäftsvertrag während der Codeausführung auf. Dies ist eine Umkehrung der Datentrennungsmethode, bei der der Geschäftsvertrag den Speichervertrag aufruft.

Das Folgende geschieht bei einem Proxy-Muster:

1. Die Benutzer interagieren mit dem Proxy-Vertrag, der Daten speichert, aber nicht die Geschäftslogik enthält.

2. Der Proxy-Vertrag speichert die Adresse des Logik-Vertrags und delegiert alle Funktionsaufrufe an den Logik-Vertrag (der die Geschäftslogik enthält), indem er die delegatecall-Funktion verwendet.

3. Nachdem der Aufruf an den Logikvertrag weitergeleitet wurde, werden die vom Logikvertrag weitergegebenen Daten abgerufen und an den Benutzer zurückgegeben.

Die Verwendung der Proxy-Muster erfordert ein Verständnis der delegatecall-Funktion. Im Grunde ist delegatecall ein Opcode, der es einem Vertrag ermöglicht, einen anderen Vertrag aufzurufen, während die eigentliche Codeausführung im Kontext des aufrufenden Vertrags stattfindet. Eine Folge der Verwendung von delegatecall in Proxy-Mustern ist, dass der Proxy-Vertrag seinen Speicher liest und beschreibt und die im Logik-Vertrag gespeicherte Logik so ausführt, als würde er eine interne Funktion aufrufen.

Aus der Solidity-Dokumentation (opens in a new tab):

Es gibt eine spezielle Variante eines Nachrichtenaufrufs namens delegatecall, die mit einem Nachrichtenaufruf identisch ist, abgesehen davon, dass der Code an der Zieladresse im Kontext (d.h. an der Adresse) des aufrufenden Vertrags ausgeführt wird und msg.sender und msg.value ihre Werte nicht ändern. Dies bedeutet, dass ein Vertrag zur Laufzeit dynamisch Code von einer anderen Adresse laden kann. Speicher, aktuelle Adresse und Guthaben beziehen sich weiterhin auf den aufrufenden Vertrag, nur der Code wird von der aufgerufenen Adresse übernommen._

Der Proxy-Vertrag weiß, dass er delegatecall aufrufen muss, wenn ein Benutzer eine Funktion aufruft, da er über eine eingebaute fallback-Funktion verfügt. In der Solidity-Programmierung wird die Fallback-Funktion (opens in a new tab) ausgeführt, wenn ein Funktionsaufruf nicht mit den in einem Vertrag angegebenen Funktionen übereinstimmt.

Damit das Proxy-Muster funktioniert, muss eine benutzerdefinierte Fallback-Funktion verfasst werden, in der beschrieben wird, wie der Proxy-Vertrag mit Funktionsaufrufen umgehen soll, die er nicht unterstützt. In diesem Fall ist die Fallback-Funktion des Proxys so programmiert, dass sie einen Delegatecall initiiert und die Anfrage des Benutzers an die aktuelle Implementierung des Logikvertrags weiterleitet.

Der Proxy-Vertrag ist standardmäßig unveränderlich, aber Logikverträge mit aktualisierter Geschäftslogik können neu erstellt werden. Für das Upgrade muss dann lediglich die Adresse des im Proxy-Vertrag referenzierten Logikvertrags geändert werden.

Nachdem der Proxy-Vertrag auf einen neuen Logikvertrag verwiesen wurde, ändert sich der Code, der ausgeführt wird, wenn Benutzer die Funktion des Proxy-Vertrags aufrufen. Auf diese Weise können wir die Logik eines Vertrags aktualisieren, ohne die Benutzer aufzufordern, mit einem neuen Vertrag zu interagieren.

Proxy-Muster sind eine beliebte Methode für das Aktualisieren von Smart Contracts, da sie die mit der Vertragsmigration verbundenen Schwierigkeiten beseitigen. Proxy-Muster sind jedoch komplizierter in der Anwendung und können bei unsachgemäßer Verwendung kritische Fehler wie Konflikte bei Funktionsselektoren (opens in a new tab) verursachen.

Mehr über Proxy-Muster (opens in a new tab).

Upgrade-Mechanismus #4: Strategiemuster

Diese Technik ist vom Strategiemuster (opens in a new tab) beeinflusst. Es fördert die Erstellung von Softwareprogrammen, die sich mit anderen Programmen verbinden, um bestimmte Funktionen zu implementieren. Die Anwendung von Strategiemustern auf die Ethereum-Entwicklung würde bedeuten, dass ein Smart Contract erstellt wird, der Funktionen aus anderen Verträgen abruft.

Der Hauptvertrag enthält in diesem Fall die zentrale Geschäftslogik, verfügt aber über Schnittstellen zu anderen Smart Contracts („Satellitenverträgen“), um bestimmte Funktionen auszuführen. Dieser Hauptvertrag speichert ebenfalls die Adresse für jeden Satellitenvertrag und kann zwischen verschiedenen Implementierungen des Satellitenvertrags wechseln.

Sie können einen neuen Satellitenvertrag erstellen und den Hauptvertrag mit der neuen Adresse konfigurieren. Dies ermöglicht es Ihnen, Strategien (d. h. eine neue Logik implementieren) für einen Smart Contract zu ändern.

Obwohl das Strategiemuster dem zuvor besprochenen Proxy-Muster ähnelt, unterscheidet es sich von diesem, weil der Hauptvertrag, mit dem die Benutzer interagieren, die Geschäftslogik enthält. Die Verwendung dieses Musters bietet Ihnen die Möglichkeit, begrenzte Änderungen an einem Smart Contract vorzunehmen, ohne die Kerninfrastruktur zu beeinträchtigen.

Der größte Nachteil ist, dass sich dieses Muster hauptsächlich für die Einführung kleinerer Upgrades eignet. Auch können Sie diese Upgrade-Methode bei einem (z. B. durch einen Hack) kompromittierten Hauptvertrag nicht verwenden.

Upgrade-Mechanismus #5: Diamond-Muster

Das Diamond-Muster kann als eine Verbesserung des Proxy-Musters angesehen werden. Diamond-Muster unterscheiden sich von Proxy-Mustern, da der Diamond-Proxy-Vertrag Funktionsaufrufe an mehr als einen Logikvertrag delegieren kann.

Die Logik-Verträge im Diamond-Muster werden als Facets bezeichnet. Damit das Diamond-Muster funktioniert, müssen Sie im Proxy-Vertrag ein Mapping erstellen, das Funktionsselektoren (opens in a new tab) verschiedenen Facet-Adressen zuordnet.

Wenn ein Benutzer eine Funktion aufruft, prüft der Proxy-Vertrag die Zuordnung, um die Facet zu finden, die für die Ausführung dieser Funktion zuständig ist. Dann ruft es delegatecall (mithilfe der Fallback-Funktion) auf und leitet den Aufruf an den entsprechenden Logik-Vertrag weiter.

Das Diamond-Upgrade-Muster hat einige Vorteile gegenüber konventionellen Proxy-Upgrade-Mustern:

1. Damit können Sie einen kleinen Teil des Vertrags aktualisieren, ohne den gesamten Code zu ändern. Die Verwendung des Proxy-Musters für Upgrades setzt die Erstellung eines völlig neuen Logikvertrags voraus, selbst für kleinere Upgrades.

2. Alle Smart Contracts (einschließlich Logikverträge, die im Proxy-Muster verwendet werden) unterliegen einer Größenbeschränkung von 24 KB, was vor allem bei komplexen Verträgen, für die mehr Funktionen erforderlich sind, eine Einschränkung darstellen kann. Mit dem Diamond-Muster lässt sich dieses Problem leicht lösen, indem Funktionen auf mehrere Logikverträge aufgeteilt werden.

3. Proxy-Muster verfolgen bei der Zugangskontrolle einen allumfassenden Ansatz. Eine Entität mit Zugriff auf Upgrade-Funktionen kann den gesamten Vertrag ändern. Das Diamond-Muster ermöglicht jedoch einen modularen Berechtigungsansatz, bei dem Sie Entitäten darauf beschränken können, bestimmte Funktionen innerhalb eines Smart Contracts zu aktualisieren.

Mehr über das Diamond-Muster (opens in a new tab).

Vor- und Nachteile der Aktualisierung von Smart Contracts

Überlegungen zur Aktualisierung von Smart Contracts

1. Benutzen Sie sichere Zugriffskontroll-/Autorisierungsmechanismen, um unbefugte Smart-Contract-Upgrades zu verhindern, insbesondere bei Verwendung von Proxy-Mustern, Strategiemustern oder Datentrennung. Ein Beispiel ist die Einschränkung des Zugriffs auf die Upgrade-Funktion, sodass nur der Eigentümer des Vertrags sie aufrufen kann.

2. Die Aktualisierung von Smart Contracts ist ein komplexer Vorgang und erfordert ein hohes Maß an Sorgfalt, um die Einführung von Schwachstellen zu verhindern.

3. Verringern Sie Vertrauensannahmen, indem Sie den Prozess der Implementierung von Upgrades dezentralisieren. Mögliche Strategien sind die Verwendung eines Multi-Sig-Wallet-Vertrags zur Steuerung von Upgrades oder die Aufforderung an Mitglieder einer DAO, über die Genehmigung des Upgrades abzustimmen.

4. Seien Sie sich der Kosten bewusst, die mit der Aktualisierung von Verträgen verbunden sind. So kann beispielsweise das Kopieren von Zuständen (z. B. Benutzerguthaben) von einem alten auf einen neuen Vertrag während der Vertragsmigration mehr als eine Transaktion erfordern, was zu höheren Gasgebühren führt.

5. Erwägen Sie die Implementierung von Timelocks, um Benutzer zu schützen. Ein Timelock bezieht sich auf eine Verzögerung, die bei Änderungen an einem System erzwungen wird. Timelocks können mit einem Multi-Sig-Verwaltungssystem kombiniert werden, um die Upgrades zu kontrollieren: Erreicht eine vorgeschlagene Aktion den erforderlichen Schwellenwert für die Genehmigung, wird sie erst nach Ablauf der vordefinierten Verzögerungszeit ausgeführt.

Timelocks geben den Benutzern eine gewisse Zeitspanne, um das System zu verlassen, wenn sie mit einer vorgeschlagenen Änderung nicht einverstanden sind (z. B. mit einem Logik-Upgrade oder neuen Gebührenregelungen). Ohne Timelocks müssen die Benutzer darauf vertrauen, dass die Entwickler keine willkürlichen Änderungen an einem Smart Contract ohne vorherige Ankündigung vornehmen. Der Nachteil dabei ist, dass die Möglichkeit, Schwachstellen schnell zu beheben, durch die Timelocks eingeschränkt wird.

Ressourcen

OpenZeppelin Upgrades Plugins - Eine Suite von Tools für die Bereitstellung und Absicherung von aktualisierbaren Smart Contracts.

• GitHub (opens in a new tab)
• Dokumentation (opens in a new tab)

Tutorials

• Upgrading your Smart Contracts | YouTube-Tutorial (opens in a new tab) von Patrick Collins
• Ethereum Smart Contract Migration Tutorial (opens in a new tab) von Austin Griffith
• Using the UUPS proxy pattern to upgrade smart contracts (opens in a new tab) von Pranesh A.S
• Web3 Tutorial: Write upgradeable smart contract (proxy) using OpenZeppelin (opens in a new tab) von fangjun.eth

Weiterführende Lektüre

• The State of Smart Contract Upgrades (opens in a new tab) von Santiago Palladino
• Multiple ways to upgrade a Solidity smart contract (opens in a new tab) – Crypto Market Pool Blog
• Learn: Upgrading Smart Contracts (opens in a new tab) – OpenZeppelin Docs
• Proxy Patterns For Upgradeability Of Solidity Contracts: Transparent vs UUPS Proxies (opens in a new tab) von Naveen Sahu
• How Diamond Upgrades Work (opens in a new tab) von Nick Mudge