Der aktuelle Stand der Aktualisierbarkeit von Smart Contracts – Kaden Zipfel


In der Regel werden in der Softwareentwicklung neue Fehler und Sicherheitsrisiken entdeckt, sie werden einfach gepatcht und die aktualisierte Version wird live übertragen. In der intelligenten Vertragsentwicklung ist die Aufrüstbarkeit nicht so einfach. Aus diesem Grund müssen wir einen anderen Ansatz verfolgen.

Ethereum steckt noch in den Kinderschuhen und es gibt viele Debatten darüber, wie Sie Ihre intelligenten Verträge aufrüsten können, aber wir werden uns einige der besten Optionen ansehen, die wir heute haben.

Hinweis: Smart Contract Upgradeability ist nach wie vor ein aktives Forschungsgebiet und sollte als solches behandelt werden. Jeder der folgenden Ansätze kann möglicherweise zum Scheitern intelligenter Verträge führen, entweder durch Missbrauch oder durch neu entdeckte Exploits.

Hier sehen wir uns einige zugänglichere, aber weniger geeignete Lösungen für eine intelligente Vertragsaktualisierung an. Obwohl dies keine optimalen Ansätze sind, bilden sie den Kern dessen, was heute verwendet wird.

Registrierungsverträge

Registrierungsverträge sind wahrscheinlich der einfachste Ansatz zur Aufrüstbarkeit. In diesem Fall weist die Einfachheit jedoch einige schwerwiegende Mängel auf.

Es funktioniert mit zwei Verträgen: dem Registrierungsvertrag und dem Logikvertrag. Der Registrierungsvertrag dient nur dazu, Benutzer auf die aktuelle Version des Logikvertrags zu verweisen. Bei jedem Upgrade des Logikvertrags kann der Eigentümer des Registrierungsvertrags die Adresse aktualisieren, unter der der Logikvertrag aktualisiert wird.

Beispiel aus Consensys

Diese Vorgehensweise ist nachteilig, da ein Benutzer immer dann, wenn er den Vertrag nutzen möchte, zuerst die aktuelle Adresse abrufen muss. Andernfalls kann dies möglicherweise zum Verlust von Geldmitteln führen. Es ist auch sehr schwierig, Daten in den neuen Vertrag zu migrieren. Daher muss dieser Prozess sorgfältig abgewogen werden, um Fehler zu vermeiden.

Proxy-Verträge

Proxy-Verträge werden verwendet, um Daten und Aufrufe an den Logikvertrag weiterzuleiten. Mit einem Proxy-Vertrag können Benutzer immer dieselbe Vertragsadresse anrufen und sie wird einfach an den aktuellen Logikvertrag weitergeleitet.

Dieser Ansatz funktioniert unter Verwendung des DELEGATECALL-Opcodes. DELEGATECALL ist ein vom EVM zur Verfügung gestellter Opcode zur Verwendung in der Montage. Es funktioniert genau wie ein normaler Anruf, außer dass der Code an der Zieladresse im Kontext des aufrufenden Vertrags ausgeführt wird. Dies bedeutet, dass Werte wie "msg.sender" und "msg.value" erhalten bleiben. Im Wesentlichen ermöglicht DELEGATECALL dem Zielvertrag, im Namen des Angerufenen Anrufe zu tätigen.

Beispiel aus Consensys

Dieser Ansatz vermeidet zwar die mit Registrierungsverträgen verbundenen Probleme, hat jedoch eigene Probleme. Beispielsweise kann die Datenspeicherung leicht fehlschlagen, wenn sie nicht ordnungsgemäß verwaltet wird. Wenn neue Verträge ein anderes Speicherlayout aufweisen als der vorherige Vertrag, können die Daten beschädigt werden. Diese Implementierung verhindert auch, dass Sie Rückgabewerte von Funktionen erhalten, was die Anwendungsfälle einschränkt.

Lagerverträge

Wie bei den vorherigen Ansätzen erfordert dieser Ansatz Ihren Logikvertrag zusammen mit einem Sekundärvertrag. In diesem Fall ist der Zweitvertrag ein unbefristeter Speichervertrag. Diese Technik trennt Logik und Daten. Der Logikvertrag kann jederzeit aktualisiert werden, und da die Datenspeicherung unbefristet ist, sind Ihre Daten geschützt.

Natürlich ist dieser Ansatz auch grundlegend mangelhaft. Wenn im Speichervertrag ein Bug oder Exploit gefunden wird, kann kein Upgrade durchgeführt werden, ohne die aktuellen Datenspeicher zu beschädigen. Das andere Problem bei diesem Ansatz ist, dass der Logikvertrag einen externen Anruf tätigen muss, um Daten mit zusätzlichem Gas anzuzeigen oder zu ändern.

Schauen wir uns nun einige komplexere und geeignetere Ansätze für eine intelligente Vertragsaktualisierung an.

Upgradefähigkeit des geerbten Speichers

Diese Technik verwendet drei verschiedene Verträge: einen Proxy-Vertrag zum Delegieren von Anrufen und als ewiger Speicher; den Logikvertrag, der die Datenverarbeitung übernimmt; und der Lagervertrag für die Lagerung, wie Sie es erraten haben. Sowohl der Proxy-Vertrag als auch der Logikvertrag erben vom Speichervertrag, sodass ihre Speicherreferenzen aufeinander abgestimmt sind.

Wenn der Logikvertrag aktualisiert wird, müssen wir lediglich die Stelle ändern, auf die der Proxy-Vertrag verweist, und zwar mithilfe einer Nur-Administrator-Funktion. Da der Proxy- und der Logikvertrag dieselben Speicherzeiger haben, müssen keine externen Anrufe getätigt werden, um Daten anzuzeigen und zu ändern.

Leider hat diese Methode auch ihre eigenen Tücken. Da sowohl der Proxy-Vertrag als auch der Speichervertrag unbefristet sind, kann ein Fehler oder eine Schwachstelle in beiden Verträgen nicht behoben werden. Aus diesem Grund ist es wichtig, Ihre Proxy- und Speicherstruktur sorgfältig zu prüfen.

Unstrukturierter Speicher Erweiterbarkeit

Unstrukturierter Speicher ist möglicherweise der derzeit größte Ansatz zur Aufrüstbarkeit und ermöglicht es uns, das Layout von Statusvariablen im Speicher zu nutzen. Diese Methode erfordert nur zwei Verträge, den Proxy-Vertrag und den Implementierungsvertrag, wobei der Implementierungsvertrag sowohl die Daten als auch die Speicherung enthält.

Bei dieser Technik werden die für die Aufrüstbarkeit erforderlichen Daten an festen Speicherpositionen gespeichert, um zu verhindern, dass sie durch neue Daten überschrieben werden. Wir können dies in Assembler mit den SLOAD- und SSTORE-Opcodes tun. Da die Speichersteckplätze ab 0x0 einfach inkrementiert werden, verwenden wir einen sehr hohen Speichersteckplatz, um ein Überschreiben zu verhindern. Wir können unseren Speicherplatz durch Hashing einer konstanten Variablen generieren. Da konstante Statusvariablen keine Speicherplätze belegen, müssen wir uns keine Sorgen machen, dass sie überschrieben werden.

Beispiel aus OpenZeppelin

Da der Proxy nicht mehr von einem Speichervertrag erbt, können wir jetzt auch unseren Speicher aktualisieren, um zu verhindern, dass Speicherfehler / Exploits katastrophal werden. Wir müssen jedoch den vorherigen Vertrag erben, wenn wir unseren Implementierungsvertrag aktualisieren. Da der Implementierungsvertrag nicht geändert werden muss, kann diese Methode auch für bestehende Verträge verwendet werden.

OpenZeppelins Übernahme der Upgradefähigkeit für unstrukturierten Speicher

Obwohl dies der derzeit beste Ansatz für die Aufrüstbarkeit ist, wird er häufig kritisiert. Der Proxy-Inhaber verfügt über beträchtliche Macht und es ist ein gewisses Maß an Vertrauen erforderlich. Dies ist möglicherweise auch keine geeignete Lösung für komplexere Systeme.

Bei Verträgen, bei denen der Konstruktor einen bestimmten Anfangszustand festlegen muss, ist die Arbeit mit Proxys nicht ganz so einfach. Da der Konstruktor nur einmal ausgeführt wird und der Proxy die im Logikvertragskonstruktor festgelegten Werte nicht kennt, müssen einige dieser Werte im Proxy initialisiert werden.

Nachdem der Logikvertrag erstellt wurde, wird der Konstruktor vom EVM verworfen, sodass wir den Code nicht einfach wiederverwenden können. Stattdessen müssen wir einen einzigartigen Ansatz verfolgen, um dies zu lösen.

Initialisierungsfunktionen

Ein möglicher alternativer Ansatz besteht darin, den Konstruktorcode in einer regulären Funktion zu verwenden. Wir müssen nur sicherstellen, dass diese Funktion, die wir als Initialisierungsfunktion bezeichnen, nur einmal ausgeführt werden kann.

OpenZeppelins Ansatz zur Erstellung einer Initialisierungsfunktion.

Bei der Arbeit mit Initialisierungsfunktionen ist es wichtig, dass diese sorgfältig erstellt werden. Wenn sie mehrmals ausgeführt werden können, kann dies katastrophal sein. Es ist auch wichtig, die Basisverträge zu berücksichtigen, von denen der Logikvertrag erbt. Dieser Teil ist besonders komplex, da Solidity Mehrfachvererbung unterstützt. OpenZeppelin erwägt eine [alternative approach](https://blog.openzeppelin.com/towards-frictionless-upgradeability/) einen Blick wert.

Es ist wichtig sicherzustellen, dass Smart Contracts aktualisierbar sind und dass der Aktualisierungsprozess sorgfältig abgewogen wird. Dies ist zwar keine erschöpfende Liste der Optionen, die wir in Bezug auf die Aktualisierbarkeit intelligenter Verträge haben, sie sollten jedoch als geeignete Anleitung zu diesem Thema dienen.

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining

Werbung: Immobilienmakler HeidelbergMakler Heidelberg

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close