Testing bei Blockchain-Projekten: besonders wichtig

Testing gehört fest in den Entwicklungsprozess von Software, das gilt auch für Blockchain-Projekte. Aufgrund der Spezifika der Blockchain sagen wir sogar: Testing ist für die Blockchain-Anteile von Software-Projekten noch wichtiger als für die Code-Stücke ohne DLT-Anteil.

Ähnliches Setup

Beim Testen von Software werden verschiedene Arten von Tests eingesetzt: Unit Test werden nah am Source Code der Anwendung ausgeführt. Sie dienen dem Test einzelner Funktionen. Bei Integrationstests wird sichergestellt, dass verschiedene Komponenten der Anwendung wie geplant miteinander interagieren. So wird zum Beispiel getestet, ob verschiedene Microservices miteinander klarkommen. Der Integrationstests ist aufwändiger als Unit Tests, da hier mehrere Komponenten einer Anwendung bereits funktionsfähig sein sollten. Unit Tests und Integrationstests werden in vielen Projekten automatisiert und von einem Continuous-Integration-Server durchgeführt. Außerdem werden Schwachstellen im Code, Architekturverletzungen und ähnliches durch verschiedene Verfahren ausgeräumt.  

Das Entwickeln von Blockchain-Anwendungen unterscheidet sich in diesem Punkt nicht vom Entwickeln von klassischen Anwendungen. Auch für Blockchain-Anwendungen können Unit- und Integrationstests automatisiert von einem Continuous-Integration-Server durchgeführt werden. Allerdings verwenden wir ein etwas anderes Wording und andere Tools.

Auch hier sind wir auf den drei Ebenen unterwegs:  

• Interaktion mit Smart Contract aus der Web3-Perspektive: Um Smart Contracts aus der Web3-Perspektive zu testen, schreiben wir Unit Tests. Dazu benutzen wir Tools wie Embark oder Truffle.  
• Interaktion zwischen Komponenten: Um die Interaktion zwischen Smart Contracts und weiteren Komponenten (z.B. Frontend, Backend, App, weiteren Smart Contracts) zu testen, schreiben wir Integrationstests. Die Tools, die verwendet werden, hängen von der jeweiligen Architektur ab. So reicht es aus, wenn man Embark oder Truffle für Tests zwischen Smart Contracts verwendet. Muss jedoch die Kommunikation zwischen Smart Contract und einem Frontend oder Backend getestet werden, müssen andere Tools verwendet werden.
• Schwachstellen in Smart Contracts: Die vorherigen Tests überprüfen, ob sich die Smart Contracts wie gewünscht verhalten, decken jedoch keine Schwachstellen auf. Da Smart Contracts in einem transparenten Netzwerk liegen und der Code von jedem eingesehen werden kann, ist es hier besonders wichtig, den Smart Contract auf bekannte Schwachstellen überprüfen zu lassen. Hier kommen zum Beispiel MythX oder Securify zum Einsatz.

Bugfixing nur mit Hindernissen 

Es werden also beim Entwickeln von Blockchain Anwendungen dieselben Testarten verwendet wie bei der klassischen Softwareentwicklung. Allerdings wird das Testing des Smart Contracts hier noch wichtiger. Warum das so ist, erklärt der Blick auf die Unterschiede zwischen Client-Server-Architektur und Blockchain.  

Bei der Client-Server-Architektur werden Server in Serverfarmen bereitgestellt oder bei Firmen vor Ort installiert. Auf diesen Servern wird dann der Dienst, den die Firma zur Verfügung stellt, ausgeführt. Die Firma hat so Kontrolle über die Server. Damit kann sie auf Bugs im Code reagieren, sie beheben und die Anwendung auf dem Server relativ zügig aktualisieren. Davon werden die Anwender wahrscheinlich nicht mal etwas mitbekommen.  

Bei der Blockchain sieht das anders aus. Sie ist eine dezentrale Infrastruktur, wird also nicht in einer oder zwei (oder mehr, aber dezidierten) Serverfarmen ausgeführt. Stattdessen werden über den Globus verteilt Computer und Server von Anwendern zur Verfügung gestellt, auf denen die Blockchain dann läuft. Daran kann im Prinzip jeder Anwender teilnehmen. Der Code eines DLT-Projekts wird auf alle diese Knoten verteilt.  

Da bei der Blockchain die Server, auf denen die Infrastruktur ausgeführt wird, weltweit verteilt sind, stellt sich die Frage: Wie können wir einen Smart Contract aktualisieren, wenn dieser einen Bug enthält? Und genau da liegt das Problem: Wir können einen Smart Contract nicht aktualisieren, da die Blockchain unveränderbar ist. Sobald etwas auf die Blockchain geschrieben und von allen Teilnehmern angenommen wird, gibt es kein Zurück mehr.  

Sind wir damit einem Bug hilflos und können gar nichts ändern? Nein. Der Bug muss natürlich behoben werden. Aber: Wir aktualisieren nicht den alten Smart Contract sondern deployen einen aktualisierten Smart Contract neu! Dazu gehört auch, den Zustand des alten Smart Contract zu übernehmen. Das Aktualisieren eines Smart Contracts ist vergleichsweise komplex, selbst dabei kann etwas schief gehen. Deswegen ist das Testen der Funktionalität und auf Schwachstellen von Smart Contracts so wichtig. 

Hinzu kommt: Dadurch wird der Bug für Jede_n sichtbar. Denn im Unterschied zu einer Client-Server-Anwendung fungiert die Blockchain nicht als Black-Box für den Anwender. Im Gegenteil: Ihre Transparenz macht sie (für manche Anwendungsfälle) so attraktiv. Denn so kann Jede_r nachvollziehen, mit welchem Input ein Smart Contract gefüttert wurde und wie das Ergebnis zustande kommt. Wenn ein Bug drin ist und das Jede_r sehen kann, auch nachdem der Smart Contract neu deployed wird, ist das natürlich peinlich.  

Smart Contracts: Testing besonders empfohlen

Von der Entwickler_innen-Ehre mal abgesehen: Die Unveränderbarkeit des Smart Contracts macht das Testing in Blockchain-Projekten noch mal wichtiger als in Client-Server-Anwendungen. Denn wie gezeigt muss fürs Beheben von Bugs im Smart Contract ein komplexer Prozess angestoßen werden.

Die CI-Pipeline dafür ist mit heutigen Werkzeugen schon machbar. Fürs Aufsetzen der Toolkette braucht es allerdings noch etwas Fingerspitzengefühl; daran merkt man, dass die Technologie zu den jüngeren gehört.

---

Über den Autor