Wie Smart Contracts zur Digitalisierung beitragen können

Viele Organisationen haben bereits vor einigen Jahren geprüft, ob die Blockchain-Technologie für ihre Zwecke einsetzbar ist. Oftmals wurden Ideen verworfen, da der Aufwand zu hoch war und passende Infrastrukturen fehlten. Doch hat sich in den letzten Jahren viel getan, und passende Infrastrukturen sind vorhanden – auch in Deutschland. Deshalb ist es schade, wenn an alten Ansichten festgehalten wird und viele Anwendungsfälle in den Schubladen verschwinden. Mit diesem Artikel möchte ich Ihren Wissensstand aktualisieren und Sie dazu anregen, erneut die Anwendbarkeit der Blockchain-Technologien zu prüfen.

Ich selbst habe in 2023 eine Machbarkeitsstudie zu Genehmigungsverfahren industrieller Anlagen durchgeführt. Generell fehlt es bei Genehmigungsverfahren in Deutschland an Digitalisierung, da die meisten Anträge aktuell noch analog auf Papier erstellt werden müssen. Selbst wenn eine elektronische Übermittlung erfolgt, werden die Genehmigungsbescheide auf Papier ausgestellt, und alle zugehörigen Unterlagen gestempelt. Der Stempel soll dabei die Manipulationssicherheit erwirken, die eine digitale Lösung nicht gewährleisten kann. Hierbei werden ganze Kopierräume bei Konzernen verschlissen, um die nötigen Dokumente auf analogem Wege bereitzustellen.

Mithilfe der Blockchain-Technologie konnten wir jedoch ein Konzept entwickeln, welches trotz oder Dank der Digitalisierung eine sehr hohe Manipulationssicherheit bietet. Wir setzten dabei auf Smart Contracts, die Hash-Werte der zugehörigen Dokumente mit einem Zeitstempel versehen. Somit ist auch nach vielen Jahren sichergestellt, dass keine Manipulation rückwirkend möglich ist. Die Behörden waren erleichtert und stimmten der Digitalisierung zu. Auch den Industriepartnern konnte die Angst vor dem Verlust von Betriebsgeheimnissen genommen werden. In den Smart Contracts werden keine sensiblen Daten gespeichert, sondern lediglich Hash-Werte und Zeitstempel. Es ist somit unmöglich, über die Blockchain an sensible Daten zu gelangen. Nur wer die Daten bereits besitzt, kann diese validieren.

Zugegeben, der Anwendungsfall ist hier sehr klein gehalten, dennoch löst er zwei schwerwiegende Probleme: den Schutz der Betriebsgeheimnisse und die Angst vor Manipulation. Gerade die Reduktion des Anwendungsfalls auf das Wesentliche macht die Nutzung von Smart Contracts so interessant. Deshalb empfehle ich immer zu Beginn, den Anwendungsfall möglichst klein zu halten. Dadurch bleibt er realisierbar, und die Komplexität der Smart Contracts überschaubar.

Doch was ist eigentlich mit dem Problem der fehlenden Infrastruktur und den hohen Energiekosten? Je nach benötigter Infrastruktur gibt es aktuell viele Möglichkeiten. Ich empfehle immer Ethereum-basierte Technologien, damit das Problem eines Vendor-Lock-Ins reduziert wird. Ethereum besitzt die größte Community und die meisten Entwickler-Tools, weshalb sehr viele Lösungen für Ethereum-basierte Technologien verfügbar sind. So betreibt beispielsweise die govdigital eG (https://www.govdigital.de/) unter der Leitung von Peter Niehues eine nationale, konsortiale Blockchain basierend auf Ethereum. Die Besonderheit dieser Infrastruktur liegt darin, dass sie bereits über alle Bundesländer verteilt ist und vollkommen von IT-Dienstleistern der öffentlichen Verwaltung betrieben wird. Diese Blockchain haben wir auch für die Smart Contracts der Genehmigungsverfahren verwendet. Somit wäre schon mal ein Problem gelöst, doch hat die Technologie aufgrund der globalen Blockchains wie Bitcoin und Ethereum weiterhin einen schlechten Ruf wegen der hohen Energiekosten. Durch das Mining von neuen Blöcken wurde sehr viel Energie verbraucht. Allerdings haben viele Blockchains – wie beispielsweise Ethereum – bereits auf grünere Konsensmodelle umgestellt, die den Energieverbrauch drastisch reduzieren. In privaten Infrastrukturen wird der Energieverbrauch noch weiter gesenkt, da hier beispielsweise das Konsensmodell Proof-of-Authority möglich ist. Dieses erlaubt es zugelassenen Teilnehmern der Infrastruktur, ohne aufwändige Rechenleistungen einen neuen Block der Blockchain anzuhängen.

Schön und gut, doch was ist mit den hohen Transaktionsgebühren, die bei Bitcoin und Ethereum anfallen? Für jede Speicherung eines Hash-Wertes würden mehrere Euro an Gebühren anfallen. Dieses Problem ist in privaten Infrastrukturen ebenfalls vernachlässigbar. Hier können sich z.B. alle Teilnehmer der Infrastruktur darauf einigen, dass keine Transaktionsgebühren anfallen, da jeder Teilnehmer in etwa die gleichen Hardware- und Energiekosten tragen muss. Da die Tokens der privaten Infrastruktur keinerlei Wert außerhalb dieser besitzen und somit nicht spekuliert wird, entfallen auch die Kosten, die durch Kurssteigerungen entstehen könnten.

Wenn alles so vorteilhaft ist und keine Probleme darstellt, warum nutzen dann nicht mehr Organisationen die Blockchain-Technologie? Natürlich besteht immer noch ein Fachkräfte-Mangel in diesem Bereich. Zudem verlagert sich der Fokus aktuell in Richtung Künstliche Intelligenz, weshalb die Forschung im Bereich Blockchain vernachlässigt wird. Dennoch kann die Blockchain-Technologie in bestimmten Anwendungsfällen zum Erfolg beitragen. An der THWS in Würzburg bilden wir unsere Studierenden im Bereich Blockchain und Smart Contracts weiter aus, sodass immer mehr Entwickler für diese Technologien zur Verfügung stehen. Fehlt also nur noch Ihre Unterstützung, um neue Anwendungsfälle zu identifizieren!

Anwendungsfälle für Smart Contracts identifizieren

Wie bereits erwähnt sollten Sie zu Beginn die Anwendungsfälle für Smart Contracts möglichst klein halten. Dies reduziert die Komplexität und entspricht dem Prinzip der Composability von Smart Contracts. Composability bedeutet, dass Smart Contracts im Idealfall eine Sache sehr gut können und in sich allein nutzbar sind. Dadurch können sie durch weitere Smart Contracts erweitert werden, um zusätzliche Funktionalitäten zu ermöglichen. Aus diesem Grund sollten Sie zunächst den Grundstein für Ihren Anwendungsfall legen und diesen möglichst klein halten. Sobald die notwendige Infrastruktur in Betrieb ist, können immer mehr fachliche Aspekte über Smart Contracts abgebildet werden.

Obwohl die Energiekosten für Blockchain-Technologien weiterhin sinken, sollte immer geprüft werden, ob ihr Einsatz sinnvoll ist. Generell sind traditionelle Technologien meist performanter und leichter zu skalieren. Eine pauschale Empfehlung für die Blockchain-Technologie ist daher nicht angebracht, jedoch steigt die Wahrscheinlichkeit für ihren Nutzen enorm, wenn Manipulationssicherheit eine wichtige Anforderung darstellt. Dabei gilt jedoch zu berücksichtigen, dass nur eine nachträgliche Manipulation der Daten verhindert wird. Dass Menschen lügen und falsche Daten in die Anwendung eintragen, kann weder die Blockchain-Technologie noch eine andere unterbinden. Aussagen wie „die Blockchain hätte den Abgas-Skandal der Automobilhersteller verhindert“ sind somit nicht korrekt. Die Blockchain hätte lediglich verhindern können, dass rückwirkend die Daten geändert werden. Da diese allerdings schon beim Test falsch abgelegt wurden, wären sie auch falsch in der Blockchain hinterlegt gewesen. Natürlich können Daten aktualisiert werden, jedoch wäre jede Aktualisierung transparent nachvollziehbar, und die vorherigen Daten blieben weiterhin in der Historie verfügbar.

In einem weiteren Projekt im Bereich Brückenbau sollen ebenfalls Daten (beispielsweise von Sensoren) über viele Jahrzehnte manipulationssicher gespeichert werden. Auch für diesen Anwendungsfall sind Smart Contracts perfekt geeignet und erhöhen das Vertrauen in vorhandene Daten. Natürlich können digitale Signaturen oder Verschlüsselung ebenfalls helfen, jedoch kann ein Administrator mit genügend Rechten diese immer noch rückwirkend manipulieren. Durch die Verkettung der Blöcke ist dies bei einer Blockchain nicht möglich.

Generell lässt sich sagen, dass Smart Contracts sinnvoll sind, wenn ein Vertrauensproblem besteht. Zusätzlich sollte ein Anwendungsfall mehrere Parteien mit Schreibrechten beinhalten. Die Blockchain nur innerhalb einer einzigen Organisation einzusetzen, ist in den meisten Fällen nicht sinnvoll. Die Sicherheit der Blockchain kann nur durch eine hohe Dezentralität gewährleistet werden, was innerhalb einer Organisation nicht gegeben ist, selbst wenn diese über mehrere Standorte verfügt. So könnte das Management der Organisation trotzdem immer eine Veränderung aller Knoten erzwingen.

In einigen Fällen können Vertrauensprobleme auch durch Trusted Third Parties gelöst werden. Existiert eine solche und alle Parteien eines Anwendungsfalls können dieser Trusted Third Party vertrauen, wäre ein traditionelles System eventuell einer Blockchain vorzuziehen. Die Entscheidung hängt von einer Kosten-Nutzen-Abwägung ab, ob sich der Einsatz einer Blockchain lohnt. Selbst wenn eine existierende Infrastruktur genutzt werden kann, kann es sich trotzdem lohnen, auf Smart Contracts zu setzen, anstatt eine Trusted Third Party zu beauftragen.

Contract-oriented Programming

Um Ihnen bei der Analyse Ihrer Anwendungsfälle zu helfen, möchte ich kurz das Thema Contract-oriented Programming (COP) beleuchten, das sich von traditioneller Anwendungsentwicklung wie beispielsweise Object-oriented Programming (OOP) unterscheidet. Verwechseln Sie COP bitte nicht mit Design-by-Contract, einem Ansatz aus der Software-Entwicklung.

COP basiert auf Smart Contracts und wird oft auch als Web3 Development bezeichnet. Dabei werden häufig Best Practices und Clean-Code-Prinzipien herkömmlicher Programmierung gebrochen, um Transaktionskosten zu minimieren. Daher spielt die Software-Qualitätssicherung eine entscheidende Rolle bei COP. In Tabelle 1 finden Sie die Gemeinsamkeiten zwischen COP und OOP. Contracts repräsentieren die herkömmlichen Klassen und können ebenfalls vererbt werden und Konstruktoren besitzen. Da Contracts nach ihrem Deployment nicht änderbar oder löschbar sind, existieren keine Destruktoren [1]. Die herkömmlichen Attribute einer Klasse werden bei Contracts als Zustandsvariablen bezeichnet. Contracts besitzen eine Adresse in der Blockchain, wohingegen herkömmliche Objekte Adressen im Arbeitsspeicher besitzen.

Diese Ähnlichkeiten führten dazu, dass Entwickler Smart Contracts als objektorientiert bezeichneten. Zusammen mit der Aussage, dass Smart Contracts Turing-vollständig sind, entstand der Eindruck, dass alles mithilfe von Smart Contracts implementiert werden kann. Daraus resultierten im Jahr 2017 vermehrt Falschaussagen, dass Blockchain oder Smart Contracts alle bisherigen Systeme ersetzen würden. Dies ist jedoch nicht korrekt, weshalb im Folgenden die Limitierungen zusammengefasst werden:

Bei COP können keine Anfragen an APIs oder Server außerhalb der Blockchain gesendet werden. Das hängt damit zusammen, dass die Blockchain immer verifizierbar bleiben muss. Externe Abhängigkeiten können sich ändern oder nicht mehr verfügbar sein, was dazu führen würde, dass vergangene Daten nicht mehr verifizierbar sind. Selbst ein simples Update von Daten außerhalb der Blockchain würde die Verifizierung verhindern. Deshalb müssen alle relevanten Daten immer von außen in die Smart Contracts gegeben werden. Ab dem Zeitpunkt der Übergabe sind diese dann unveränderbar. Die Daten können zwar im aktuellen Zustand aktualisiert oder gelöscht werden, doch in der Historie bleiben alle Daten für immer erhalten. Dies gewährleistet die Verifizierbarkeit auch noch nach vielen Jahren.

Zufallsgeneratoren sind eine weitere Herausforderung. Da die Blockchain dezentral verteilt ist, müssten alle Knoten in der Lage sein, denselben Zufall zu berechnen. Dadurch sind alle Algorithmen nur noch Pseudo-Zufallsgeneratoren. Werden echte Zufallszahlen benötigt, müssen diese außerhalb der Blockchain berechnet und anschließend die Ergebnisse in den Smart Contracts gespeichert werden. Andernfalls könnten Angreifer versuchen, Ergebnisse der Pseudo-Zufallsgeneratoren vorab zu berechnen und Anwendungsfälle wie beispielsweise Lotterien damit zu ihren Gunsten ausnutzen.

Eine weitere Limitierung besteht darin, dass Smart Contracts nicht von sich aus aktiv werden können. Sie benötigen immer eine Transaktion von einem Nutzer oder externem System, um eine Funktion auszuführen. So sind beispielsweise Zeitabhängigkeiten nicht von Smart Contracts allein umsetzbar. Ein System außerhalb der Blockchain muss diese Zeitabhängigkeiten überwachen und dann zum gewünschten Zeitpunkt eine Transaktion an den Smart Contract senden, damit die gewünschte Funktionalität durchgeführt werden kann. Ein automatisierter Ablauf einer Deadline, der dann beispielsweise eine Rückzahlung oder ähnliches auslöst, ist somit nicht allein mit Smart Contracts umsetzbar.
Der Umgang mit datenschutzrelevanten Informationen stellt zudem eine Herausforderung dar. Wenn wir diese in der Blockchain speichern, könnte dies das Recht auf informationelle Selbstbestimmung verletzen, da die Daten nicht mehr gelöscht werden können. Innerhalb des Geltungsbereichs der DSGVO ist daher stets ein Zusammenspiel aus traditionellen IT-Systemen und Smart Contracts erforderlich, um passende Anwendungsfälle vollständig umzusetzen.

Da Smart Contracts nach ihrem Deployment nicht mehr geändert werden können, müssen umfassende Tests aller Funktionalitäten im Vorfeld erfolgen. Zusätzlich empfehlen wir, ein Security-Gutachten von Experten durchführen zu lassen, um mögliche Angriffsvektoren zu reduzieren. Heute existieren zudem zahlreiche Standards und Libraries, die bei der Umsetzung wiederverwendet werden können. Dies erhöht die Sicherheit, da viele bekannte Sicherheitslücken durch den Open-Source-Charakter bereits geschlossen wurden.

Die meisten Herausforderungen und Limitierungen lassen sich in konkreten Umsetzungsprojekten beheben. Allerdings müssen diese bekannt sein und bedacht werden, um eine sichere Lösung zu gewährleisten. Deshalb empfiehlt es sich, Anwendungsfälle zu Beginn minimal zu gestalten und die Smart Contracts in bestehende Systeme zu integrieren. Korrekt umgesetzt können Smart Contracts dazu beitragen, bestehende Systeme zu verbessern und vor allem Manipulationssicherheit zu garantieren.

Entwickeln, Deployen und Managen von Smart Contracts

Wenn Sie erste Ideen für Ihre Anwendungsfälle haben, stellt sich oft die Frage, wie Sie mit der Entwicklung beginnen können. Heute gibt es, wie bereits erwähnt, zahlreiche Standards und Libraries, die die Entwicklung vereinfachen, sowie einige Frameworks und Entwicklungsumgebungen (IDEs) für Smart Contracts. Für schnelles Prototyping empfiehlt sich die offizielle IDE von Ethereum: Remix (https://remix.ethereum.org/), welche in Abbildung 1 zu sehen ist.

Remix ist ähnlich zu gängigen Entwicklungsumgebungen aufgebaut. Auf der linken Seite finden Sie den Datei-Explorer und die Projektstruktur. Zudem gibt es dort weitere Menüs zum Kompilieren, Deployen und Interagieren mit Smart Contracts. Der Hauptbereich ist der Editor zum Implementieren der Smart Contracts, und am unteren Rand findet sich eine Konsole, welche alle wichtigen Informationen ausgibt.

Remix unterstützt auch die Entwicklung und Durchführung von Unit Tests für Smart Contracts, Debugging sowie die Ausführung von Skripten für das Deployment und das Management von Smart Contracts. Wenn Sie zum Menüpunkt ‚Deploy & Run Transactions‘ wechseln, müssen Sie zuerst ein Environment auswählen. Standardmäßig ist hier die Remix Virtuelle Maschine (VM) aktiviert, die eine Ethereum-basierte Blockchain im Arbeitsspeicher Ihres Rechners ausführt. Darunter finden Sie eine Liste von verfügbaren Accounts, die auch über 100 Test-Ether verfügen. Hier können Sie alle kompilierten Smart Contracts in der virtuellen Maschine deployen und mit ihnen interagieren. Da alles über die grafische Oberfläche bedient werden kann, eignet sich Remix besonders gut für schnelles Prototyping und manuelle Tests durch den Entwickler. Deshalb ist Remix auch sehr empfehlenswert, um die Entwicklung von Smart Contracts zu erlernen.

In Abbildung 2 ist die Interaktion mit Smart Contracts in Remix dargestellt. Sobald ein Contract deployed wurde, erscheint dieser im Abschnitt ‚Deployed Contracts‘. Dort sind alle lesenden Funktionen mit einem blauen und alle schreibenden Funktionen mit einem orangenen Button gekennzeichnet. Eine lesende Funktion ist gratis und gibt die Inhalte des Smart Contracts zurück. Eine schreibende Funktion löst eine Transaktion aus, für die Transaktionsgebühren anfallen. Solange Sie innerhalb der Remix VM mit ihren Contracts interagieren, erfolgt die Bezahlung dieser Gebühren virtuell über die zur Verfügung gestellten 100 Test-Ether.

Nach ausgiebigen Tests Ihrer Contracts können Sie diese mithilfe von Remix ebenso auf der offiziellen Ethereum Blockchain oder einer privaten Ethereum-basierten Blockchain deployen. Dazu wählen oder konfigurieren Sie einfach das entsprechende Environment. Danach können Sie analog zu den lokalen Tests Ihre Contracts im Menü ‚Deploy & Run Transactions‘ per Knopfdruck deployen.

Nachdem Sie bereits deployte Smart Contracts haben, können Sie diese im gleichen Menü anhand ihrer Adresse laden und ebenfalls mit ihnen interagieren. So ermöglicht Remix ein sehr einfaches manuelles Management. Natürlich kann das Management der Contracts mithilfe von Skripten auch automatisiert werden. Dafür benötigen wir jedoch zunächst ein paar Beispiele.

Einführung in Solidity

Smart Contracts wurden mit der Blockchain-Technologie Ethereum eingeführt, auch wenn sie bereits in den 1980er Jahren konzipiert wurden. Damals basierten alle Lösungen auf Trusted Third Parties, weshalb es nie zu einer wirklichen Umsetzung kam. Mit der Entwicklung der Blockchain-Technologien konnte die Trusted Third Party eliminiert werden, wodurch das Konzept der Smart Contracts wieder attraktiv wurde. Gemeinsam mit Ethereum wurde die erste Contract-oriented Programming Language eingeführt – Serpent. Serpent ähnelte stark Python, wurde jedoch aufgrund diverser Unsicherheiten durch Solidity ersetzt. Solidity ist aktuell die größte Programmiersprache für Smart Contracts und verfügt über die größte Entwickler-Community. Solidity beinhaltet Analogien zu den Programmiersprachen C++, Python und JavaScript. Die Syntax ist der von JavaScript am nächsten, weshalb es vielen Entwicklern leichtfällt, sich darin einzuarbeiten.

Bevor Sie mit der Entwicklung mit Solidity beginnen, sollten wir zunächst die Struktur eines Smart Contracts besprechen. Die erste Zeile eines Contracts ist üblicherweise der Software Package Data Exchange (SPDX) License Identifier. Dieser spezifiziert die Open-Source-Lizenz, die für den Contract gilt. Wenn kein SPDX License Identifier angegeben wird, warnt der Compiler sogar, da Smart Contracts standardmäßig Open-Source-designed sind. Falls Sie dennoch keine Open-Source-Lizenz nutzen möchten, können Sie immer den Default-Wert „UNLICENSED“ verwenden. Die Angabe erfolgt als Kommentar via

//SPDX-License-Identifier: UNLICENSED.

Direkt danach folgt üblicherweise das Versionspragma, das die zulässige und unterstützte Compiler-Version definiert. Dieses können Sie folgendermaßen definieren: pragma solidity ^0.8.26. Nach Festlegung der Version können andere Contracts und Libraries importiert werden, und anschließend können Sie Ihren Contract mit dem Keyword contract definieren. In Listing 1 sehen Sie ein minimalistisches Beispiel eines Contracts, der eine lesende Funktion besitzt, die den String „Hallo Welt!“ zurückgibt. Lesende Funktionen sind an den Keywords pure oder view in der Funktionssignatur erkennbar.

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

contract HalloWelt {
function sagHallo() public pure returns(string memory) {
return „Hallo Welt!“;
}
}

Listing 1: Hallo-Welt-Beispiel in Solidity

Als nächstes erweitern wir den Contract um eine Zustandsvariable (analog zu Attribut einer Klasse), die einen Text abspeichert, den wir später auslesen können. Die Deklaration einer Statusvariablen erfolgt mithilfe der Syntax . Für einen Text verwenden wir den Datentyp string. Anschließend implementieren wir eine Funktion setText, die einen Parameter vom Typ string erwartet und diesen in unserer neuen Zustandsvariablen persistent abspeichert. In der Funktion getText können wir diese Variable dann auslesen und zurückgeben.

In Listing 2 sehen Sie den erweiterten Contract. Immer wenn in Solidity Strings, Arrays oder andere dynamische Datentypen verwendet werden, müssen Sie die Datenlokation angeben. Für jetzt genügt, wenn Sie die Datenlokation memory nutzen, welche definiert, dass der zugehörige Parameter oder die zugehörige Variable im Arbeitsspeicher abgelegt wird. Bei Zustandsvariablen müssen Sie dies nicht angeben, da dort eindeutig ist, dass diese persistent im Storage des Contracts gespeichert werden. Bei der Funktion getText müssen Sie in der Funktionssignatur diesmal view anstelle von pure verwenden, zumal wir in der Funktionssignatur lesend auf den Storage zugreifen. Pure bedeutet, dass wir innerhalb der Funktion gar keine persistenten Daten verwenden.

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

contract HalloWelt {
string private text;

function setText(string memory _text) public {
text = _text;
}

function getText() public view returns(string memory) {
return text;
}

function sagHallo() public pure returns(string memory) {
return „Hallo Welt!“;
}
}

Listing 2: Erweiterung des Hallo-Welt-Beispiels um Getter- und Setter-Funktionen

Sofern Sie den Contract nicht bereits in der Remix IDE entwickelt haben, legen Sie dort nun eine neue Datei an – z.B. HalloWelt.sol. Kopieren Sie den Contract in die Datei und wechseln Sie links zum Menüpunkt ‚Solidity compiler‘, um den Contract zu kompilieren. Im Menüpunkt ‚Deploy & Run Transactions‘ können Sie jetzt in der Liste der kompilierten Contracts den Contract HalloWelt auswählen. Klicken Sie auf den Button ‚Deploy‘. In der Konsole erscheint nun Ihre erste Transaktion, die mit einem grünen Haken als erfolgreich markiert ist. Wenn Sie auf diese klicken, erhalten Sie das komplette Transaction Receipt, das alle Informationen der zugehörigen Transaktion enthält. Diese Receipts sind wichtig, um in einem produktiven System Informationen über Ihre Interaktionen zu erhalten.

Abbildung 3 zeigt, wie das Receipt aussehen sollte. Neben den Informationen zum Status der Transaktion, dem Hash sowie dem Block Hash erhalten Sie hier Auskunft über die neue Adresse Ihres deployten Contracts. Des Weiteren sehen Sie, von welcher Adresse aus der Contract angelegt wurde. Im Feld „to“ ist zu erkennen, dass der Konstruktor des Contracts „HalloWelt“ verwendet wurde. Danach folgt eine Aufschlüsselung der Transaktionskosten. Da für den Konstruktor keine Eingabedaten erforderlich waren, keine Rückgabewerte zurückgegeben wurden und der Konstruktor keine Logs erzeugt hat, sind die restlichen Felder leer. Alle drei Dinge sind im Standardkonstruktor nicht vorhanden und müssten manuell implementiert werden, wenn sie benötigt werden.

Die Logs einer Transaktion können lediglich von Nutzern oder Systemen außerhalb der Blockchain gelesen werden. Der Smart Contract schreibt zwar diese Log-Einträge, kann danach jedoch nicht mehr auf diese zugreifen. Trotzdem sind Log-Einträge wichtig, um in externen Systemen auf bestimmte Zustandsänderungen des Contracts reagieren zu können. Dies nutzen beispielsweise Kryptobörsen, damit sie auf den An- oder Verkauf von Token reagieren können.

Wenn Sie Interesse haben, tiefer in die Welt der Smart-Contract-Programmierung einzusteigen, empfehle ich Ihnen, einen genaueren Blick in die offizielle Dokumentation von Solidity zu werfen. Diese finden Sie unter https://docs.soliditylang.org/en/latest/.

Dezentrale Applikationen

Oftmals können Smart Contracts nur einen Teil der benötigten Funktionalitäten selbst abdecken, weshalb für viele Anwendungsfälle sogenannte Dezentrale Applikationen (DApps) benötigt werden. Doch was genau ist so eine DApp eigentlich?

Die Web3 Community strebt danach, das Web neu zu erfinden und eine Welt voller DApps zu schaffen. Diese DApps basieren alle auf Smart Contracts und sind vollkommen dezentral gehostet. Das bedeutet, dass sowohl die Smart Contracts auf der Blockchain als auch die zugehörigen Backend-Systeme, die Datenbanken sowie das Frontend dezentral gehostet werden. Die Kommunikation zwischen DApps und die Namensauflösung mittels DNS sollte ebenfalls auf dezentraler Basis erfolgen. Aus diesem Grund entwickelt die Web3 Community eine Vielzahl von Tools, um dies langfristig zu ermöglichen. So existiert mittlerweile beispielsweise der Ethereum Name Service (ENS) als dezentrale Variante eines DNS, doch auch das Interplanetary File System (IPFS), welches eine dezentrale Datenhaltung ermöglicht. Zusammen mit der Eigenschaft, dass Smart Contracts von Grund auf als Open Source konzipiert werden sollten, lassen sich für DApps die folgenden Eigenschaften festlegen: dezentral, Open Source, transparent und zensur-resistent. Durch die Dezentralität ist es schwer, Zensur zu ermöglichen, da niemand daran gehindert werden kann, einen eigenen Blockchain-Knoten oder IPFS-Knoten zu betreiben und an den DApps teilzunehmen.

Natürlich ist diese Vision der vollkommenen Dezentralität aktuell noch nicht komplett umsetzbar und für viele Anwendungsfälle ungeeignet, weil sich Gesetze, Vorschriften und Business-Logiken jederzeit ändern können. DApps können daher auch als Web-Anwendungen definiert werden, die Smart Contracts integrieren.

Um eine DApp für einen Anwendungsfall zu entwickeln, gibt es verschiedene Vorgehensweisen. Wir verfolgen aktuell den DApp-Entwicklungs-Prozess aus Abbildung 4. Zunächst müssen die Anforderungen definiert werden. Anschließend kann eine passende Blockchain-Technologie ausgewählt werden, die diese Anforderungen erfüllt. Hierbei kann entweder Ethereum selbst zum Einsatz kommen oder eine andere Technologie, die mit der Ethereum Virtual Machine (EVM) kompatibel ist. Es gibt jedoch auch Technologien, die nicht EVM-kompatibel sind und Smart Contracts anbieten, doch sind sie in der Regel weniger verbreitet und bieten meist nicht den gleichen Umfang an Tools. Nach Auswahl der Technologie werden die Smart Contracts entworfen und implementiert. Aufgrund ihrer Unveränderlichkeit müssen diese permanent getestet werden. Danach wird das Frontend umgesetzt und ggf. auch ein Backend erstellt. Sobald alle Funktionalitäten getestet sind und wie gewünscht funktionieren, empfiehlt es sich, Security Reviews und Audits durchzuführen. Jetzt kann die DApp dezentral bereitgestellt und eine passende ENS-Domain registriert werden. Sollten Sie Ihre DApp lieber zentral betreiben wollen, müssen nur die Smart Contracts dezentral bereitgestellt werden.

Der Prozess ist hier sequenziell dargestellt. Natürlich können Frontend und zugehörige Backend Services auch parallel zu den Contracts entwickelt werden. Da die Integration aber erst möglich ist, wenn die Smart Contracts – oder zumindest Teile der Contracts – fertig sind, ist die Darstellung hier sequenziell gewählt.

Besonders wichtig ist der Aspekt der Security Reviews und Audits, da in der Vergangenheit nicht unerhebliche Mengen an Geld durch Angriffe und Exploits verloren gingen. Natürlich kann kein Review und kein Audit sicherstellen, dass keine zukünftigen Angriffe möglich sind, jedoch werden immer noch zu viele bekannte Fehler begangen, welche unnötig sind.

Wenn Sie Interesse haben zu erfahren, welche DApps bereits großflächig im Einsatz sind, empfiehlt sich ein Blick auf die Website https://dappradar.com/, welche eine Übersicht über DApps liefert, die auf den offiziellen öffentlichen Blockchains laufen. Viele der global verfügbaren DApps sind aktuell im dezentralen Finanzmarkt oder im Bereich von Spielen angesiedelt.

Upgradeability von Smart Contracts

Wenn Sie den Artikel bis hierher gelesen haben, dann bleibt Ihnen bestimmt noch eine Frage im Hinterkopf: Wenn Smart Contracts nicht geändert oder gelöscht werden können, wie kann dann die Business-Logik im Laufe der Jahre angepasst werden? Und sind Blockchain-Technologie oder Smart Contracts dann überhaupt geeignet, wenn mein Anwendungsfall Updates benötigt?

Für diese Fälle gibt es Konzepte und Lösungen. Trotzdem bleiben Smart Contracts unveränderbar, und wenn diese Konzepte der Upgradeability nicht schon bei der Entwicklung berücksichtigt werden, können die Contracts auch nachträglich nicht mehr aktualisiert werden. Es gibt allerdings auch DApps wie beispielsweise die dezentrale Kryptobörse Uniswap, die bewusst auf Upgradeability-Mechanismen verzichten, um Transaktionskosten zu sparen. Dort existieren verschiedene Versionen der DApps, beginnend mit UniswapV2, und aktuell steht UniswapV4 kurz vor der Veröffentlichung. Die alten Versionen sind nach wie vor verfügbar und werden von einigen Tradern weiterhin genutzt. Dies kann nicht verhindert werden. Die Entscheidung, welche Version sie verwenden wollen, bleibt letztendlich bei den Nutzern. Um eine Verwendung alter Versionen zu unterbinden, müssten Funktionen implementiert werden, die einen Contract deaktivieren oder pausieren können. Das war jedoch im Fall von Uniswap nicht gewollt.

Kommen wir nun zu den verschiedenen Upgradeability Patterns. Sie müssen hierbei zwischen Contract-Migrationen und Contract Upgrades unterscheiden. Bei einer Migration wird keinerlei Funktionalität implementiert, welche ein Upgrade ermöglicht, doch es werden genügend Getter-Funktionen bereitgestellt und Log-Einträge erzeugt, um immer den aktuellen Zustand des Contracts sowie alle aktuellen Daten auslesen zu können. Wird eine neue Version benötigt, können der neue Contract deployed und die Daten migriert werden. Dies klingt zunächst gut, doch habe ich die Kosten berechnet, die bei einer Migration der Daten des USD-Token anfallen würden. Allein für die Guthabenverwaltung wären 9,625 Mio € nötig, wenn durchschnittliche Transaktionskosten zugrunde gelegt werden. Dann fehlen jedoch immer noch die anderen Daten des Contracts. Je nach Nutzungsumfang Ihrer Contracts fällt eine Migration als Möglichkeit also weg. Auf privaten Infrastrukturen können die Kosten natürlich anders ausfallen, dennoch wäre dieser Weg nicht sehr nachhaltig. Abgesehen davon ist es nicht trivial, alle Daten eines Contracts zu erheben, um sie in einen neuen Contract zu migrieren.

Deshalb wurden in den vergangenen Jahren verschiedene Upgradeability Patterns entwickelt, welche ein Upgrade von Business-Logiken ermöglichen. Generell basieren alle diese Patterns auf der Trennung von Daten und Logik. Eine der ersten Versionen wurde auch als Data-Separation-Pattern bezeichnet, und später entwickelten sich dann das Proxy-Pattern oder das Diamant-Pattern. Die Idee besteht darin, einen Contract zu deployen, der alle Daten enthält und als zentraler Anlaufpunkt für alle Interaktionen dient. Dieser Contract besitzt einen Pointer auf den zu verwendenden Logik-Contract und delegiert alle Aufrufe an diesen weiter. Bei Smart Contracts erlaubt eine Delegierung, dass ein anderer Contract die Daten des delegierenden Contracts verändern darf. Somit kann der Logik-Contract Daten hinzufügen, ändern oder auch löschen. Wird in Zukunft ein Upgrade der Logik benötigt, muss lediglich der neue Logik-Contract deployed und der Pointer im Daten-Contract aktualisiert werden.

Die Implementierung der einzelnen Patterns erhöht die Komplexität ein wenig, ermöglicht jedoch in Zukunft eine Reaktion auf Änderungen. Auch wenn Sicherheitslücken in der Logik wären, könnte auf die neue Logik gewechselt werden – sofern die Daten nicht kompromittiert wurden. Doch sollten auch in diesem Fall umfassende Tests implementiert werden, welche nicht nur die Logik, sondern auch die Upgradeability prüfen.

Jetzt am Ende des Artikels geistern Ihnen bestimmt viele Ideen im Kopf, und hoffentlich konnte ich Sie motivieren, diese zu erproben. Blockchain-Technologien und Smart Contracts bieten viele spannende Möglichkeiten, die in verschiedensten Anwendungsbereichen zahlreiche Vorteile bringen können. Ich kenne nur die Technologie und könnte Sie bei der Umsetzung Ihrer Ideen unterstützen. Aber es braucht Ihr Wissen und Ihre Fachkenntnisse, um neue Anwendungsfelder zu identifizieren und beispielsweise in Machbarkeitsstudien zu erproben. So kann am Ende wie in der Machbarkeitsstudie zum Genehmigungswesen von Industrieanlagen ein Mehrwert geschaffen werden. BASF und Evonik konnten ebenfalls gemeinsam mit der Commerzbank die Kosten von Finanzflüssen drastisch reduzieren und forschen aktuell an ihrem Ansatz zum programmierbaren Geld weiter (https://www.commerzbank.de/konzern/newsroom/pressemitteilungen/evonik-basf-blockchain.html). Jetzt liegt es an Ihnen, ob Sie mit Ihren Ideen die Reise in eine dezentrale, digitale Welt unterstützen wollen.

Verweise

[1] Vor dem Cancun Update 2024 von Ethereum existierte die Möglichkeit, einen Contract zu löschen.