Smart Contracts – Disruptive Technologie der Zukunft oder immer noch nur ein Hype?

Der Autor

 

Ihr Kontakt bei diconium

Alexander Käppler
senior digital consultant

2019-03-28

Mit Smart Contracts ist es wie mit Sex im Teenager-Alter: Jeder spricht darüber. Keiner weiß wirklich, wie es geht. Alle denken, dass die anderen es tun, also behauptet jeder, dass er es auch tut.

Um dem Mysterium oder Hype einmal etwas dichter auf die Spur zu kommen, haben wir selbst ausprobiert, wie schwer es eigentlich ist, einen Smart Contract zu erstellen, zu publizieren und zu betreiben. Dies allerdings mit einem Anspruch, der über langweilige und anspruchslose „Hallo Welt“ Beispiele hinausgeht, sondern mit Logik und in einem eigenen „private Network“. Doch dazu später mehr.

Da wir nach der ersten Korrekturschleife festgestellt haben, dass dieses Thema noch viele Fragen und teilweise Missverständnisse aufwirft, die im Text nicht besprochen sind, haben wir uns entschieden, ein etwas anderes Format für diesen Inhalt zu wählen.

 

Unter jedem Kapitel (manchmal auch zwischendrin) haben wir das Geschriebene hinterfragt bzw. kommentiert. Stellt uns gerne weitere Fragen – wir werden zeitnah auf die Kommentare und Fragen antworten, also schaut immer mal wieder vorbei.
Colorful  powder explosion on black background.Multicolored powder splash cloud isolated on black background

Was ist eigentlich ein Smart Contract?

Ein Smart Contract ist im Grunde nichts weiter als eine Software, ein Programm, ein Stück Code. Ein Smart-Contract kann nur gestartet und ausgeführt werden, wenn dieser auf dem richtigen Medium gespeichert ist – einer Blockchain. Je nach Programmierung kann man in einem Smart Contract einfach nur Daten abspeichern, diese mit dem Programm verändern, oder die der Blockchain zugrunde liegende Währung von einem Nutzer an einen anderen Nutzer transferieren. Man kann sich also einen Smart Contract wie eine App oder eine Windows-Anwendung vorstellen – die macht auch nur, was irgendwer da mal hinein programmiert hat.

 

Frage: Ist es nicht eher wie ein Makro, das in einem anderen Programm abläuft, wenn bestimmte Bedingungen erfüllt sind?
Antwort: Nein, eben nicht, sondern eher wie Java in der „Java Virtual Machine“.


Was ein Smart Contract nicht kann, sind irgendwelche Dinge von allein machen. D.h., um eine Aktion auszuführen (die vorher im Programm programmiert wurde) ist es notwendig, diese Programmfunktion aufzurufen. Das geht nur durch einen „Trigger“. Was daher nicht geht ist, dass sich ein Contract quasi von allein am 04. 09. 2020 um 13:00 Uhr selbst ausführt. Es braucht, für solch eine Aktion, eine Aktion von außerhalb der Blockchain, welche die Aktion anstößt. Im Grunde ist das auch wie bei einem herkömmlichen Programm – wenn es etwas machen soll, dann muss es „getriggert“ werden. Entweder ein Nutzer gibt einen Befehl in das System ein, macht einen Klick irgendwo hin oder hat eine Art Wecker eingerichtet, welcher die Aktion triggert. Im Linux-Umfeld wird hierfür gerne der CRON-Job genutzt. Dieser triggert zeitgesteuert eine Funktion oder ein Programm, welches dann aktiv wird. Genauso ist es auch bei Smart Contracts. Ohne Trigger keine Aktion.
 

Frage: Wieso nicht? Wenn der Trigger das Eintreten des Datums ist?
Antwort: Weil das eben nicht geht. Excel startet sich auch nicht von allein, nur, wenn es dazu getriggert wird (Bsp.: mit einem Klick auf das Icon).
Frage: Ist nicht der eigentliche Charakter eines „Smart Contracts“ der Fakt, dass hier etwas vertraglich zwischen zwei Parteien geregelt ist, was an bestimmte Bedingungen geknüpft ist?
Antwort: Nun, das ist ja das Witzige. Es ist genau nicht so. Es ist nicht zwingend ein Vertrag, sondern ganz banal ein Stück Software, was auch immer Du da rein coden willst – (fast) egal. Das können Vereinbarungen sein, die an bestimmte Bedingungen geknüpft sind, müssen aber nicht. Ebenso kann das einfach „nur Text-speichern“ sein oder eben an Bedingungen geknüpfte Transaktionen von einem Account an einen anderen.
Du hast eine Frage? Her damit!
Colorful  powder explosion on black background.Multicolored powder splash cloud isolated on black background

Wie funktioniert ein Smart Contract?

Um zu verstehen, wie ein Smart Contract funktioniert, werfen wir erst einmal einen Blick auf herkömmliche Software. Normalerweise wird ein Programm, eine App oder Anwendung in einer Programmiersprache geschrieben. Das ist normalerweise menschenlesbarer Code, der in einem Texteditor oder einer Software-Entwicklungsumgebung erstellt wird. Hat man das Programm fertig geschrieben, wird es kompiliert. Das Kompilieren wandelt jetzt den für Menschen lesbaren Code in Maschinen-Code um, dieser ist dann nicht mehr so einfach lesbar für Menschen, dafür aber für die Maschine – und damit ausführbar.

Jetzt gibt es zwei grundlegende Unterschiede der Kompilierung: Zum einen gibt es Programmiersprachen, deren Code direkt in Maschinencode umgewandelt bzw. übersetzt (kompiliert) wird. Diese Programme laufen nach der Übersetzung direkt auf dem Betriebssystem, welches den Code lesen und ausführen kann. Dazu zählen Programmiersprachen wie C oder C++. Der große Nachteil dieser Programmiersprachen besteht darin, dass Anwendungen, die auf unterschiedlichen Betriebssystemen laufen sollen, für jedes Betriebssystem individuell erstellt werden müssen, da jedes Betriebssystem (Linux, iOS, Windows, Android) eine andere Art der Interpretation des Maschinencodes hat. So unterscheidet sich beispielsweise der Zugriff auf Dateien grundsätzlich zwischen Linux und Windows. Möchte das Programm jetzt Dateien lesen oder Schreiben, dann muss die Art und Weise, wie die Daten zu adressieren sind, für beide Systeme individuell programmiert werden. App-Entwickler kennen das Problem, wenn Sie native Anwendungen für iOS und Android quasi parallel entwickeln müssen, da beide Betriebssysteme den erzeugten Maschinencode anders interpretieren würden.

smart contracts | arten programmausfuehrung | diconium Unterschiedliche Arten der Programmausführung: Nativ als Maschinencode oder in einer virtuellen Maschine

Die zweite Möglichkeit der Programmierung besteht darin, eine Programmiersprache zu verwenden, deren ausführbarer Code nicht direkt auf dem Betriebssystem läuft, sondern in einer virtuellen Maschine. Diese VM übernimmt die Kommunikation mit dem Betriebssystem. Somit ist es möglich, eine Anwendung nur einmal zu programmieren, zu kompilieren und dann kann jede virtuelle Maschine dieser Art (bspw. Java) diesen Code ausführen. Die unterschiedliche Interpretation der Systembefehle auf Maschinencodebasis übernimmt die Virtuelle Maschine, muss jedoch nicht mehr vom Entwickler implementiert werden – der macht das nur einmal. Diese VM ist zwar jeweils für das Betriebssystem speziell, versteht aber den einmal erstellten Programmcode gleichermaßen, egal, ob sie auf Windows, Linux oder MacOS läuft. Als Entwickler erstellt man einmal seine Java-Anwendung und schreibt einmal den Dateizugriff. Die konkrete Ausführung erledigt dann aber die VM, je nach zugrunde liegendem Betriebssystem.

Die Mechanik der virtuellen Maschine kommt auch bei Smart-Contracts zum Tragen. Ein Ethereum Smart-Contract ist somit ein Stück Software, welches in einer virtuellen Maschine, der Ethereum VM, auf dem Betriebssystem der Ethereum Blockchain läuft. Diese virtuelle Maschine ist Kernbestandteil der Ethereum Blockchain, und sobald man einen eigenen Knoten (eine Node) startet, ist diese VM verfügbar – das ist vergleichbar mit Windows. Sobald Windows (neuere Versionen) installiert ist, ist auch die JVM (Java Virtual Machine) auf diesem Computer verfügbar, und damit ist es möglich, Java Programme zu starten und auszuführen.

Die EVM bildet damit den Container und die Umgebung ab, in welcher die Software ausgeführt wird und liefert alle relevanten Methoden, um mit den Kernfunktionen der Ethereum Blockchain zu interagieren. Das sind Aktionen wie das Erstellen von neuen Accounts, das Transferieren von Währung oder das Speichern von Daten.

Das Erstellen eines Smart Contracts

An dieser Stelle sei erwähnt, dass ich nicht noch einmal die Vor- und Nachteile einer Blockchain diskutieren möchte, das wurde bereits hinlänglich und vielfältig in zahlreichen Foren und News-Seiten und Whitepaper getan. Nur so viel noch grundsätzlich. Alles, was in einer Blockchain gespeichert wird (und das ist auch mit einem Smart-Contract nicht anders) wird an eine Adresse innerhalb der Blockchain gebunden. Sprich, jedes Datum, jede Transaktion, jeder zu speichernde Inhalt - alles ist über die Speicheradresse abrufbar und damit auch öffentlich einsehbar. Die native Anonymität bzw. besser Pseudonymität (einer der großen Blockchain Vorteile) wird dadurch sichergestellt, dass alles nur über kryptische Adressen wie 0x6721ee8ecb8546a052dd1b2f2c160b3edda033a7 abgebildet wird, jedoch zu dieser Adresse per-default keine personenbezogenen Daten vorliegen. Allerdings kann alles, was in einem Smart-Contract hinterlegt ist, perspektivisch auch öffentlich eingesehen werden. Daher auch eben nur Pseudonymität, denn sobald die beiden Vertragsparteien die Hash-Adressen voneinander kennen, ist jede weitere oder jede vorherige Transaktion in der Blockchain nachvollziehbar. Der einzige Weg, dies zu verhindern, besteht darin, bei jeder Transaktion einen neuen Account-Hash zu erzeugen und dann den neuen Hash für die Transaktion zu nutzen. Dabei muss jedoch das Guthaben vom alten auf den neuen Hash transferiert werden, was die Historie nach wie vor nachvollziehbar macht, das Herausfinden jedoch mit weitaus höherem Aufwand verbunden ist. Alternativ kann man auch pro Transaktion einen neuen Account-Hash nutzen, die Verkettung der Accounts jedoch im Hintergrund ohne Blockchain ablaufen lassen, bzw. die Assoziation von altem und neuem Hash über eine Art „Transaktionskonto“ erfolgen lassen.
 

1. Betriebsmodus der Blockchain wählen

Um einen eigenen Smart-Contact zu erstellen und zu nutzen ist im ersten Schritt wichtig, sich über den Betriebsmodus klar zu werden. Die Ethereum Blockchain kann im Grunde auf jedem PC laufen. Dazu muss man sich einfach nur Go-Ethereum (GETH) downloaden und dieses starten. Dabei ist GETH das Interface, also die Eingabe-Konsole, über welche man direkt mit und auf der Blockchain Kommandos und Befehle verarbeiten kann.

smart contracts | geth interface | diconium Screenshot: Go-Ethereum (GETH)

Je nach --networkid kann man entscheiden, ob die gestartete Blockchain zu einer privaten oder öffentlichen Blockchain gehört. Die Netzwerk-ID = 1 wäre die öffentliche Ethereum Blockchain. Jede andere ID (erst recht, innerhalb eines geschlossenen Netzwerkes) ist eine private Blockchain. Um einen ersten Smart-Contract zu erstellen reicht es wahrscheinlich aus, die Blockchain nur auf dem eigenen PC laufen zu lassen. Wie gesagt, das funktioniert vergleichsweise genauso wie die „Java Virtual Machine“, auf welcher sich Java-Programme ausführen lassen.

Im Echtbetrieb würden viele PCs gemeinsam das Netzwerk bilden, dabei agiert dann jeder PC, auf dem eine Blockchain läuft, als eigener Knoten, eigene Node. Um mehrere PCs zu einem Netzwerk zusammenzuführen, muss man im Grunde nur den Befehl addPeer(enode…) auf der Konsole ausführen, und nach kurzer Zeit beginnen sich die einzelnen Nodes selbständig zu synchronisieren. Als Folge dessen liegt die Blockchain dann auf allen angeschlossenen Nodes vor. Mehr dazu später.

 

2. Code schreiben

Der Code für einen Smart-Contract wird in der Programmiersprache Solidity geschrieben. Diese sieht aus wie JavaScript, ist jedoch um ein paar Parameter und eine gewöhnungsbedürftige Syntax verändert. So braucht es zum Beispiel weiterführende Attribute für einen Contract, wie etwa „memory“ oder „payable“. Hintergrund ist, dass jede schreibende Transaktion auf die Blockchain Rechenleistung kostet und dass jede schreibende Aktion verifiziert werden muss. Das machen normalerweise die sogenannten Miner. Diese berechnen komplexe mathematische Aufgaben, um dadurch zu bestätigen, dass eine Transaktion gültig ist. Da diese Berechnung einiges an Strom benötigt, wird normalerweise diese Arbeit „bezahlt“. Dazu benötigt man eine Währung – im Fall von Ethereum heißt sie Ether. Im Gegensatz zu schreibenden Aktionen benötigt das Lesen keine Verifikation, demnach auch keine extra Rechenleistung, da ja keine Daten verändert oder ergänzt werden.

Den Code für seinen Smart-Contract kann man in einem normalen Texteditor schreiben, oder aber man nutzt eine online Entwicklungsumgebung wie REMIX. Obwohl das Schreiben hier etwas umständlich ist, besteht der große Vorteil darin, dass es einen „instant“ Compiler gibt, der quasi schon während des Schreibens Fehler im Code erkennt und mit Vorschlägen aufwartet, wie Fehler zu korrigieren sind. Ist das Programm, also der Smart-Contract, fertig, entstehen bei Remix ein paar wichtige Dateien, die alle für ein Deployment, also eine Veröffentlichung, notwendig sind.

Alternativ zu dem Online-Compiler kann man auch auf der eigenen Konsole bzw. dem eigenen Rechner den Solidity-Compiler nutzen. Dieser erzeugt ebenso die für die Veröffentlichung notwendigen Daten und Dateien. Eine der besten Anleitungen dazu ist hier zu finden: Smart Contracts für die Ethereum-Blockchain. Nachteil dabei ist eben nur, dass Fehler erst beim Kompilieren erkannt werden und diese dann im Editor korrigiert werden müssen. Ebenso sind die Empfehlungen zur Korrektur nicht ganz so gut, wie in REMIX.
 

3. Programm kompilieren

Da die Ethereum Virtual Machine eben keinen Solidity-Code lesen und ausführen kann, muss der erzeugte Code noch maschinentauglich werden. Dazu wird er kompiliert. Das Ergebnis des Kompilierens besteht aus 2 notwendigen Daten-Einheiten oder Dateien. Diese sind auch die beiden Blöcke, aus denen der Smart-Contract im Wesentlichen besteht.

Struktur eines Smart-Contracts

Die ABI regelt dabei, welche Funktionen und Parameter in einem Smart-Contract vorhanden sind, welche Eingaben und Ausgaben sie erwarten und ob sie öffentlich zugänglich sind, oder nur im Speicher ablaufen sollen (in memory). Ebenso beschreibt die ABI, welche der Methoden „payable“ sind, also Ether empfangen oder senden können oder einfach nur Transaktionskosten (Gas) verbrauchen bei bspw. einem Ändern bereits vorhandener Daten innerhalb des Vertrages.

Der Bytecode ist der von der EVM ausführbare Programmcode. Beide Datenblöcke sind notwendig, um einen Smart-Contract in einer Blockchain zu veröffentlichen.

smart contracts | bytecode | diconium Beispiel eines Bytecodes zu einem kleinen Solidity Smart-Contract
Colorful  powder explosion on black background.Multicolored powder splash cloud isolated on black background

Smart Contract publizieren

Um jetzt den erstellten „Vertrag“ zu veröffentlichen, meldet man sich an der Blockchain mit dem Befehl personal.unlockAccount(„Account-Adresse“, „Passwort“) an. Hat man noch keinen Account, so kann man den einfach mit web3.eth.createAccount(„Passwort“) erstellen. Das Ergebnis der Erstellung eines neuen Nutzer-Accounts ist eine Adresse innerhalb der Blockchain nach dem Format „0x52972c3d3b33a6e6edb3a302479a44156336f001“. Diese Nutzeradresse kann (weil es ein Nutzer-Account ist) Ether empfangen und senden (sofern vorhanden).

Um einen neuen Vertrag jetzt in der Blockchain zu speichern, habe ich den Befehl loadScript(‚Sourcefile.js‘) genutzt. In dem Sourcefile (JavaScript) ist sowohl die ABI enthalten wie auch der Bytecode. Darüber hinaus allerdings noch ein paar Deklarationen von Variablen, die im eigentlichen Programm verwendet werden und bereits bei Veröffentlichung befüllt sein sollen. Das Veröffentlichen eines Smart-Contracts ist eine schreibende Aktion in die Blockchain, folglich fallen, wie bei allen schreibenden Aktionen, Transaktionskosten an. Der Account, mit dem man sich eingeloggt hat, sollte also über ausreichend Ether verfügen, um diese Transaktion auch ausführen zu können. Ist der Account nicht ausreichend gedeckt, so kann man (weil es eine private Blockchain ist) auch eth.default=eth.coinbase vorab in die Kommandozeile eingeben. Dieser Befehl bewirkt, dass alle Transaktionskosten jetzt von der Blockchain an sich „bezahlt“ werden. Ist sicherlich nicht geeignet für den Live-Betrieb, im Test und Entwicklungs-Modus kann das aber so gemacht werden.

Nachdem der Vertrag bzw. unser Programm jetzt in der Blockchain gespeichert wurde, dauert es eine kleine Weile, bis diese Transaktion gemined, also verifiziert wurde. Als Ergebnis, analog zur Accounterstellung, erhalten wir eine Speicheradresse, unter welcher der Vertrag von nun an „global“ in der Blockchain zu finden ist. Diese Speicheradresse sieht genauso aus wie eine Nutzeradresse. Ab jetzt kann man die Routinen seines Vertrages über die Konsole ansprechen und ausführen, also triggern. Wichtig dabei zu wissen, dass man, um einen gespeicherten Vertrag zu adressieren, sowohl seine ABI braucht als auch den Namen der Funktion, die man ausführen lassen will. Der Befehl würde auf der Konsole etwa so lauten: eth.contract(  [{"constant":false,"inputs":[{"name":"nummer“,"stateMutability":"view","type":"function"}…]).at(„Speicheradresse“).funktionsname().

Als Ergebnis bekommt man angezeigt, was in dem Programm als Ausgabe programmiert wurde. In einfachen Contracts kann das ein „Hello World“ sein, oder, wenn innerhalb des Funktonsaufrufes Transaktionen vollzogen werden, wird hier der Hash-Wert der Transaktion an sich gezeigt. Bei einer Transaktion von Ether wird dann beispielsweise die Transaktions-ID angezeigt, auch wieder im Format „0x8888888888…“.

Stolperfallen bei der Erstellung und Veröffentlichung

Die wichtigsten Clearings und wesentliche Hinweise:

1. Ein Smart Contract ist ein Stück Software. Ist dieses einmal in der Blockchain gespeichert, so ist der Code an sich unveränderbar. Der Code ist zu finden an einer global eindeutigen Adresse und reagiert nur auf Trigger bzw. das Ausführen einer Funktion des „Vertrages“

2. Da ein einmal veröffentlichter Smart Contact codetechnisch nicht mehr änderbar ist, muss man für ein Update des Codes diesen erneut veröffentlichen. Dabei bleibt der alte Vertrag in der Blockchain bestehen, die neue Version ist unter der neuen Speicheradresse erreichbar. Wurde bereits Ether in den „alten“ Vertrag eingezahlt, bleiben diese Ether auch dort.

3. Variablen, die innerhalb eines Vertrages genutzt werden, sind auch nach der Speicherung des Contracts änderbar, sofern die Programmierung eine Änderung vorsieht (Setter). Ist nirgendwo programmiert, dass man eine Variable oder einen bestimmten Wert per Funktionsaufruf ändern kann, dann geht das auch nicht.

4. Jede schreibende Aktion (also das Ändern einer Variablen oder das Transferieren von Währung) benötigt Rechenleistung, das „Gas“. Hat der Besitzer des Vertrages/ der Ausführende der Transaktion nicht ausreichend Gas in seinem Account, kann die Speicherung bzw. Transaktion nicht ausgeführt werden. Dummerweise wird für diesen Zustand keine eindeutige Fehlermeldung zurückgegeben.
 

Frage: Heißt das, dass ich so die Ausführung eines Vertrages verhindern kann?
Antwort: Du nicht, außer, Du bist der Besitzer des Vertrages und hast a) nicht genug GAS und/oder b) es gibt kein Fallback. Normalerweise wird aber in einer privaten Blockchain das GAS aus der Coinbase genommen, damit das genau nicht passiert. In der öffentlichen Blockchain jedoch kann das passieren und der Vertrag, also die Softwareroutine, wird nicht ausgeführt. Lösung ist dann, dem Vertrag ausreichend weiteres GAS zur Verfügung zu stellen, woher auch immer.


5. Will man, durch einen Vertrag geregelt, Ether transferieren, so ist es notwendig, dass der Vertrag auch Ether hat. Es reicht nicht aus, als Besitzer des Vertrages ausreichend Ether zu besitzen, der Vertrag braucht das Ether, welches transferiert werden soll.

6. Man kann an einen Vertrag Ether transferieren. Muss man auch können, falls dieser Transaktionen bezahlen muss. Aber Vorsicht: Wenn in dem Smart Contract keine Möglichkeit programmiert wurde, wie diese Ether wieder irgendwo anders hin transferiert werden können, dann bleibt der eingezahlte Ether für immer auf dem Vertrag und kann nicht mehr wegbewegt werden – ist damit also weg bzw. für immer gebunden.

7. Wenn man einen Vertrag erstellt, der Transaktionen durchführen soll, dann muss ihn in die Lage versetzen, auch Ether zu empfangen. Das erfolgt durch eine anonyme Funktion. Diese kann leer bleiben, muss aber vorhanden sein, um Ether zu empfangen. Die einfachste Umsetzung ist: function() external payable { }. Neben der anonymen Funktion kann alternativ eine explizite Funktion genutzt werden, um Ether zu empfangen. Diese muss dann aber für den Transfer auch explizit aufgerufen werden (contract.receive(uint menge)).

4. Arbeitet man auf einer lokalen Blockchain über die Konsole, so ist das lediglich eine Instanz, also eine Sicht, auf die Blockchain. Es ist möglich, den per loadScript() veröffentlichten Vertrag auch ohne seine konkrete Adresse anzusprechen (myContractObject.getName()). Das funktioniert jedoch nur, solange man die Konsole nicht schließt. Ist die Konsole einmal geschlossen, braucht man die globale Adresse und Ansprache seines Vertrages per eth.contract(„ABI“).at(„Speicheradresse“).funktionsaufruf().

Jeder Smart Contract gibt in der ersten Zeile an, mit welcher Compiler-Version er funktioniert. Stimmen hier die Versionen nicht mit dem genutzten Compiler überein, wird der Vertrag gar nicht erst lokal erstellt (kompiliert), d.h., es erscheinen Fehler und man muss entweder seinen Compiler ändern oder den Code anpassen, um zum genutzten Compiler zu passen.

Colorful  powder explosion on black background.Multicolored powder splash cloud isolated on black background

Aufbau eines private-Blockchain-Networks

Solange man das alles auf seiner lokalen Maschine macht, erscheint vieles plausibel und funktioniert auch. Doch im „echten Leben“ hat man ja bestenfalls mehr als eine Node. Um ein Netzwerk aus privaten Nodes aufzubauen, sind einfach ein paar Rechner notwendig, die über das Internet (oder im lokalen Netzwerk) erreichbar sind.

Als erstes erstellt man eine Blockchain auf der ersten Maschine. Dazu ist eine Initialisierungs-Datei notwendig, das sogenannte Genesis-File. Diese Datei im JSON Format definiert, wie die Blockchain funktionieren soll, wie komplex der Verifizierungsmechanismus ist oder auch, wie die Adresse der Coinbase ist.

Beispiel eines Genesis-Files für die Blockchain Initialisierung

Mit dem GET-Konsolenbefehl geth init genesis.json --datadir „/meine-blockchain/“ initialisiert man diese im Verzeichnis „/meine-blockchain“. Dieses Genesis-File wird anschließend auf alle anderen Computer kopiert, welche als Node in dem Netzwerk fungieren sollen. Dort wird der gleiche Befehl in der GET-Konsole ausgeführt, um auch auf den anderen Rechnern die Blockchain gleichermaßen zu initialisieren.
 

Frage: Muss man das selbst machen oder passiert das durch Blockchain Software?
Antwort: Das kann man selbst machen (manuell) oder man nutzt die --discover Funktion. Damit erfolgt das automatisch (im gleichen Netz).
Du hast eine weitere Frage dazu?

Jetzt startet man die erste Node mit geth --networkid 77 --identity "MeineDevChain" --datadir "meine-blockchain" --port 30303 --rpcport 8543 --rpc --mine --minerthreads 1.  Der Befehl aktiviert die Blockchain und man kann beginnen, Befehle an sie zu senden. Die Optionen --mine und --minerthread 1 definieren, dass auf dieser Blockchain das Minen (das Verifizieren von Transaktionen) stattfinden soll, und zwar mit einem Thread. Den gleichen Befehl führt man auf allen anderen PCs aus. Wichtig bei ist, dass auf allen die gleiche --networkid genutzt wird. Wo die Daten dann gespeichert werden (--datadir) kann von Maschine zu Maschine variieren.

Abschließend werden jetzt die einzelnen PCs miteinander „vernetzt“. Dazu kann man entweder einen Automatismus (--discover) nutzen oder das manuell erledigen. Um manuell die einzelnen Nodes zu einem Verbund zusammenzuschließen, führt man den GET-Konsolenbefehl addPeer(…) aus. Dieser Befehl erfordert die Eingabe einer Blockchain-Adresse inkl. der IP-Adresse und der Portnummer, unter welcher die andere Node zu finden ist. Die Adresse einer Node (als Enode bezeichnet) erhält man, wenn man admin.nodeInfo.enode eingibt. Die Ausgabe zeigt den Identifier der Blockchain sowie deren IP-Adresse und Portnummer an, unter welcher die Node zu finden ist. Das kann bspw. so aussehen: "enode://ddf1f6aaf29f22cb2c0…c20106f90a1d526788f298@127.0.0.1:30303?discport=0". Will man jetzt die Node zu einem Netzwerk hinzufügen, sollte man sinnvoller Weise die IP-Adresse von 127.0.0.1 (localhost) auf die öffentlich erreichbare Adresse ändern. Je nach Netzwerk kann das so was sein 192.178.12.10, dann diese Enoden-Bezeichnung in den addPeer(…)-Befehl eintragen und kurz warten. Ebenso wichtig, den richtigen Port (nach dem „:“) anzugeben, unter welchem die zu ergänzende Node zu finden ist. Nach einer kleinen Weile fangen die beiden Blockchains an, sich zu synchronisieren.

An dieser Stelle wird sichtbar, warum es wichtig ist, sich Speicheradressen von Contracts oder Nutzer-Accounts zu merken. Auf der zweiten Maschine kann man sich zwar auch einloggen, allerdings nur, wenn man die Adresse des Nutzers kennt. Die oft in Tutorials beschriebene Mechanik der Nutzung des Account-Arrays web.eth.account[0-n] funktioniert nur auf der lokalen Instanz der lokalen Maschine, auf welcher der Account initial erstellt wurde. Alle andere Nodes im Netzwerk kennen den lokal erstellten Account nicht, sondern nur die global verfügbare Speicheradresse in der Blockchain.
 

Frage: Wäre ja auch schlimm, oder?
Antwort: Nein, eigentlich nicht, es macht keinen Unterschied. Der Account liegt in der Blockchain (inkl. Passwort), daher kann man sich von überall auch einloggen. @Localhost (also auf der eigenen Maschine) schreibt man nur web3.eth.accounts[1].login() als Konsolenbefehl. Das wäre der erste lokale Account (0x77447665) auf diesem Computer. Auf einer anderen Node würde man eingeben 0x77447665.login(), da hier die Adresse eth.accounts[0] nicht oder anders belegt ist. Das Ergebnis sollte bei Ansprache der globalen Adresse das gleiche sein, da man direkt die Adresse in der Blockchain anspricht, und nicht den lokalen Account mit der ID = 0.


Ist man eingeloggt, kann man seinen vorher veröffentlichten Smart-Contract nur erreichen, wenn man wie beschrieben sowohl ABI wie auch Speicheradresse kennt und diese adressiert. Es wird, wie gesagt, die Blockchain synchronisiert, inklusive allem, was darinsteht.

Colorful  powder explosion on black background.Multicolored powder splash cloud isolated on black background

Welchen Nutzen bringen Smart Contracts?

Ein wesentlicher Nutzen aus meiner Sicht ist der Umstand, dass man für diese sich selbst synchronisierende Datenbank keinen Administrator benötigt. Niemand kann den Programmcode eines Smart-Contracts ändern, wenn dieser einmal veröffentlicht wurde. Gut, das kann auch ein Problem werden, wenn dieser Code Bugs enthält. Erst recht, wenn schon jemand Ether an den Contract überwiesen hat. Grundsätzlich aber braucht so ein Netzwerk aus Nodes keine Datenbank-Administration. Ebenso ist es nur sehr schwer möglich, die Daten innerhalb eines Smart-Contracts zu fälschen. Dadurch, dass alle Nodes eine Kopie der Blockchain speichern, kann jede Node für sich selbst die Validität der aktuellen Transaktion und damit der kompletten Kette prüfen (errechnen). Stimmen die von einer Node selbst errechneten Werte nicht mit denen der Mehrheit der errechneten Werte innerhalb des Netzwerkes überein (jede Node rechnet und kommuniziert ihr eigenes Ergebnis), liegt ein Fehler oder eine Manipulation vor. Es kann reagiert werden. Und auch das passiert automatisch. Erkennt eine Node, dass ihr Ergebnis ein anderes ist, als das mehrheitlich errechnete (von mehr als 50 % der angeschlossenen Nodes), wird das eigene Ergebnis verworfen und das Mehrheitliche als das Richtige betrachtet und übernommen. Sprich, es wird die Blockchain der anderen Nodes übernommen, die eigene lokale damit überschrieben.

Ein weiterer Vorteil liegt in der Geschwindigkeit der Replikation. Je nach Verschaltung des Netzes (addPeer(…)) sind Daten und Änderungen sehr schnell von einer Node auf eine andere und dann im ganzen Netzwerk verteilt.

smart contracts | verschaltung blockchain | diconium Verschaltung in einer privaten Blockchain mit angeschlossenen Web-Clients (Bsp.)

So kann eine Webanwendung auf der einen Seite Daten an das andere Ende sehr schnell transferieren. Gerade bei dem Gedanken an das traditionelle FIAT-Banking scheint hier sehr viel Potenzial zu schlummern. Heutzutage dauert eine Überweisung von Deutschland nach Australien knappe 5 Werktage. Fragwürdig, denn selbst FIAT-Währungen werden digital übermittelt in Zeiten des Online-Bankings. Warum dauert das also 5 Tage? Über eine Blockchain-Anwendung kann die Überweisung in wenigen Minuten am anderen Ende der Welt sein, und das Ganze ohne einen Administrator oder (ggf. parteiischen oder voreingenommenen oder kriminellen) Mittler.

Doch neben den Vorteilen gibt es auch Nachteile. Neben dem Stromverbrauch (der öffentlichen Ethereum Blockchain) und dem teilweise überflüssigen Transfer großer Datenmengen sehe ich auch die Transparenz unter Umständen als Nachteil. Auf der einen Seite als großes Allheilmittel gefeiert besteht doch schon die Frage, was kann man alles in einem Smart-Contact schreiben, und was nicht. Bestimmt gibt es gewisse Daten, die nicht jeder lesen oder sehen können soll. Dabei ist zwar anonym, wer Vertragsgeber und -nehmer ist, der Inhalt ist es jedoch per-se nicht. D.h., wenn wir einen Smart-Contract nutzen würden, um unser Erbe an die Erben zu verteilen, dann kann (wenn man den Funktionsaufruf und die Speicheradresse und die ABI des Vertrages kennt) sehen, welche Blockchain-Adresse wie viel Ether beim Ableben erhält. Damit ist jedoch nicht klar, wer das denn dann genau ist, die Konditionen jedoch sind es.

Anders allerdings, wenn man einen traditionellen Vertrag in Form eines reinen Texts oder Dokumentes speichern will. Das ist innerhalb eines Smart-Contracts problemlos möglich. Gut, auch hier braucht man Kenntnis über Speicheradresse und ABI des Vertrages, aber wenn man diese Daten hat, kann man sich den kompletten schriftlichen Vertrag anzeigen lassen. Das muss nicht unbedingt gewollt sein, erst recht nicht, wenn da dann Namen, Daten, Zahlen und Fakten in Klarform enthalten sind.
 

Frage: Brauche ich dazu einen Smart Contract, wenn ich nur Content speichern möchte?
Antwort: Ja, einen, der Text speichern und ausgeben kann. Hier ist dann beispielsweise kein vertragliches Regelwerk definiert, außer vielleicht Zugriffsrechte (lesen und schreiben).
Haben wir etwas vergessen?

Der Web-Zugriff auf Smart Contracts

Das bisher beschriebene Vorgehen, also über die GETH-Konsole Zugriff auf einen Smart-Contract zu erhalten, scheint jedoch nicht wirklich gut nutzbar zu sein, wenn man nicht unbedingt ein Liebhaber der Konsole ist, und auch nicht alle Befehle kennt, die man so ausführen kann. Das haben auch die Erfinder so gesehen und zum Glück die Zugriffssprache für die Blockchain direkt als JavaScript entwickelt. Das bedeutet, die Befehle, die wir in der GETH-Konsole an die Blockchain senden, sind von Grund her JavaScript-Befehle, die in der Web3j-Bibliothek zusammengefasst sind.

Diese Web3j-Bibliothek kann, weil eben in JavaScript geschrieben, auch vom Browser geladen und interpretiert und damit ausgeführt werden. Als Folge ist es relativ einfach, eine Webanwendung zu erstellen, die sich mit der Blockchain verbindet und dann mit dem Vertrag interagieren kann. Doch auch hier: Das Web-Interface, also die Webseite, ist eine Instanz einer Sicht auf die Blockchain. Alles, was innerhalb der Instanz getan und gespeichert wird ist zwar persistiert in der Blockchain, also wirklich gespeichert, temporäre Variablen wie eth.defaultAccount oder eth.Etherbase werden jedoch gelöscht, sobald die Session des Browsers beendet wird. Die Funktionsweise der JavaScript-Befehle innerhalb der Webanwendung ist demnach genauso zu verstehen und auch genauso anwendbar, wie innerhalb der GETH-Konsole auf einem PC mit instanziierter Interaktion auf der Blockchain.

Colorful  powder explosion on black background.Multicolored powder splash cloud isolated on black background

Anwendungsfälle und deren Herausforderungen

Oft werden im Netz einfache „Hello World“-Beispiele referenziert, um die Funktionsweise der Smart-Contracts zu demonstrieren. Leider ist „Hello-World“ sehr trivial, denn es werden alle notwendigen Variablen bei der Veröffentlichung geschrieben und nichts wird mehr im Laufe der Zeit verändert. So erscheint das ganze Smart-Contract-Thema relativ einfach, wenn man sich mit dem ersten Contract beschäftigt. Doch leider ist die Welt nicht so einfach. Aus diesem Grund haben wir uns ein etwas anspruchsvolleres Szenario überlegt, um einen Vertrag zu erstellen und dann neben der Änderung von Variablen innerhalb des veröffentlichten Vertrages auch Transaktionen durchzuführen.
 

1. Fall: Erbschaftsregelung

Das Szenario sieht vor, dass es einen Menschen gibt, der sein Erbe zu frei definierbaren Anteilen an seine Erben verteilen möchte.

smart contracts | erbschaftsverteilung | diconium Beispielanwendung Erbschaftsverteilung

Dabei sollte so ziemlich alles dynamisch auch nach der Veröffentlichung des Vertrages modifizierbar sein, falls mal ein Erbe enterbt werden soll, oder sich der Betrag des zu vererbenden Vermögens ändert.

Das Ergebnis ist ein Smart Contract, welcher verschiedene Variablen speichern kann. Das sind auf der einen Seite die Blockchain Adressen der Erben, zum anderen die Anteile (in %), die ein Erbe jeweils bekommen soll und natürlich das zu vererbende Vermögen an sich. Im ersten Schritt benötigt der User einen Nutzer-Account. Dieser wird auf der Blockchain erstellt. Anschließend wird der Vertrag im Namen dieses Nutzers veröffentlicht bzw. er veröffentlicht den Vertrag selbst. Die Variablen der Erben und deren Vermögensanteile sind bei Veröffentlichung leer – es wird also nur der Vertrag an sich veröffentlicht, das Rahmenkonstrukt also. Nachdem der Vertrag verifiziert (gemined) wurde bekommt er eine eindeutige Speicheradresse und der Nutzer, der den Vertrag veröffentlicht hat, kann über diese Adresse seine Erben eintragen. Das sind auch jeweils Blockchain-Accounts/Adressen. Ebenso kann die Angabe der Vermögensanteile in Prozent erfolgen, die dem jeweiligen Erbe zuteilwerden sollen. Alle eingegebenen Daten sind jederzeit änderbar (solange ausreichend Ether auf dem Account des Nutzers vorhanden ist, um die Transaktionen/ Änderungen zu bezahlen) – denn jede Transaktion kostet Gas (Ether).

Das Programm, also der Contract, sieht die Funktion der Auszahlung von Ether vor. Damit der Vertrag etwas auszahlen kann, das Erbe, muss dieses erst einmal an den Vertrag übermittelt werden. Das erfolgt entweder von einem anderen Nutzerkonto oder von der Coinbase, je nachdem, wie das Geschäftsmodell des Erbschafts-Verwalters aussieht.

Damit die Erben an das Erbe kommen, müssen diese entweder ihre Blockchain Adresse zur Verfügung stellen, oder aber der Erbgeber erstellt einen neuen Nutzer-Account und teilt den Erben Speicheradresse und Passwort mit. Diese Daten ermöglichen dann den Login in das Nutzerkonto, um im Falle des Todes den Betrag nutzen zu können – denn ein Nutzerkonto ist anders als ein Vertrag. Nutzerkonten können standardmäßig Ether transferieren und empfangen. Der Vertrag, wie beschrieben, leider nicht ohne explizite Programmierung der Geld-Empfangs-Routine.

Einige gute und praxisnahe Beispiele wie Assetmanagement oder Finanztransaktionen sind zu finden unter safehaven.io.


2. Fall: KFZ-Logbuch

Ein oft schon angesprochenes Problem bei jedem Kauf eines Gebrauchtwagens ist die Frage nach den Laufdaten des KFZ. Leider wird auch heutzutage noch zu oft an den Kilometerständen geschraubt und damit die Laufleistung eines Autos reduziert. Oder es werden kleine Unfälle oder Pannen einfach verschwiegen, wohingegen Scheckhefte auch schon mal gepimpt werden. Um all dem entgegen wirken zu können, ist die Nutzung einer privaten Blockchain sinnvoll einsetzbar.

smart contracts | kfz logbuch blockchain | diconium Logbuch eines KFZ unter Nutzung einer privaten Blockchain

In diesem Beispiel wird jedes Auto zu einer Node innerhalb der privaten Blockchain. Dabei gehen wir einfach mal davon aus, dass das neue KFZ internetfähig und online ist. Bei Auslieferung oder Erstbetrieb initialisiert das Auto seine lokale Blockchain, startet einen Miner, wird zum Netzwerk als Node hinzugefügt und veröffentlicht einen Vertrag, dessen Vertragsnummer die FIN des KFZ sein kann.

Den Miner brauchen wir, damit die Blockchain lokal im Auto (auch wenn mal ein Funkloch ist – wir leben in Deutschland, da kommt das gerne mal vor) weiter Transaktionen verarbeiten und diese speichern kann. Da das Auto Teil des Netzwerks ist, synchronisiert es sich ständig (sofern online) mit den anderen KFZ, die ebenfalls alle als minende Node agieren. Dadurch wird es extrem schwer, die Daten zu manipulieren, die ein KFZ über sich selber sammelt, da für eine Manipulation mehr als 50% der Autos/ Nodes gleichzeitig manipuliert werden müssten.

Und das Beste: Als Nutzer ist man nicht mehr zwingend auf die Angabe des Verkäufers bzgl. Unfällen oder Kilometerstand angewiesen. Es reicht, wenn der Hersteller eine Webseite anbietet, welche den Zugang bzw. den Einblick in die Daten der Blockchain zulässt (s. Grafik oben: Die Blockchain ist natürlich auf allen Nodes, diese eine „Blockchain“-Node soll nur den Web-Zugang symbolisieren). Der Interessent für ein KFZ gibt dort lediglich die Speicher-Adresse des KFZ-Logbuchs (des Smart-Contracts) an, und alle Daten, die das Auto in seinem „Leben“ gesammelt hat, werden übersichtlich dargestellt. Sollte man die Speicheradresse des KFZ nicht haben, so kann man ja noch einen ergänzenden Contract (als Hersteller) erstellen, welcher im Grunde alle Speicheradressen und die dazugehörigen FINs speichert. Geht, alles in der Blockchain, weltweit in kürzester Zeit verfügbar, ohne Administration, fälschungssicher.

Denkt man jetzt noch an die Telematik-Daten, die derzeit schon von modernen Fahrzeugen erhoben werden, dann lassen sich sicherlich noch weitaus interessantere und geschäftsfähige Modelle entwickeln, bei denen nicht nur Kilometerstand oder Wartungen, sondern auch G-Kräfte, Geschwindigkeit und weitere Fahrparameter gespeichert und ausgewertet werden. Ob Banken und Versicherungen, Werbetreibende oder Online-Versender – einer möglichen Daten-Nutzung steht im Grunde nur der Nutzer selbst im Wege. Doch stimmt der Nutzer der Verarbeitung seiner Daten zu, weil die angebotenen Dienste und Leistungen für ihn einen spürbaren Mehrwert darstellen, dann ist vieles denkbar.
 

Frage: Warum brauche ich dazu eine private Blockchain?
Antwort: Ich will nicht die Daten der öffentlichen Blockchain (Ethereum) auf meinem Auto haben. Viel zu viele Daten und zu hohe Kosten (jede Transaktion müsste ich mit echtem Ether bezahlen). Daher eine private Blockchain. Das allerdings bedeutet nicht, dass die Blockchain nicht über das normale Internet erreichbar sein muss. Sie kann auch öffentlich erreichbar sein, nur ist es eben nicht die Ethereum Blockchain die echtes Ether kostet und das Einbringen neuer Nodes ist beschränkt bzw. gar nicht zulässig.


Eine private Blockchain ist im Gegensatz zu einer public Blockchain so gesehen nicht weiter als eine einfach aufzusetzende und verteilte Datenbank. Die Rechte an der „Datenbank“ bzw. die Rechtevergabe obliegt jedoch dem Besitzer der Blockchain. Damit ist einer der Kern-Vorteile, Vertrauen ohne Kenntnis des anderen Geschäftspartners, nur bedingt zu heben, denn wie gesagt, die Blockchain an sich unterliegt den Regeln des Besitzers. Die Vorteile jedoch sind nicht zu verachten:

  1. Keine Administration der „Datenbank“ nötig
  2. Schnell aufgesetzt und damit kleine „Time-to-Market“
  3. Damit schnell weltweit verfügbar
  4. Die gespeicherten Daten sind nicht manipulierbar (abgesehen von einer 51% Attacke)

Die handelnden Parteien sind pseudonym, also fast anonym – die persönlichen Daten sind durch den Besitzer auch nicht in Erfahrung zu bringen (außer, man sagt sie ihm).

Alles nachvollziehbar soweit? Falls nicht:

3. Fall: Compliance Management in einem Unternehmen

Ein weiterer Anwendungsfall kann die in jedem größeren Unternehmen vorhandene Compliance-Anwendung sein. Normalerweise besteht dahingehend eine Art Meldepflicht bzw. „Anzeigepflicht“ für Verstöße gegen diese unternehmensinternen Compliance Richtlinien. Das Melden von Verstößen ist aber oft damit verbunden, dass es (abgesehen von einer Selbstanzeige) schwer ist, einen Kollegen anzuzeigen. Erst recht, wenn es ggf. der Vorgesetzte ist. Die oftmals zur Anonymisierung eingesetzten Mechaniken, Mittel und Methoden sind bei genauerer Betrachtung dann doch nicht so anonym oder vertraulich.


Hier könnte die Blockchain mit einem Smart Contract ebenfalls ein hilfreiches Mittel sein.

smart contracts | compliance | diconium Schematischer Ablauf einer anonymen Meldung oder Anzeige

Mitarbeiter erhalten per Webseite Zugriff auf die Blockchain. Nach einer Anmeldung bzw. Erzeugung einer individuellen Hash-Adresse kann der Mitarbeiter seinen Complain oder seine Meldung an das Compliance Team absenden. Diese Meldung wird in Form eines Smart-Contracts in der Blockchain gespeichert, neben dem eigentlichen Text können noch weitere Variablen wie Status der Meldung oder Lese/ Schreibrechte mit verankert werden.

Der Contract wird dann über das Compliance Team einsehbar, aber nur durch dieses. Der Bearbeiter kann den Status der Meldung verändern, nicht aber ihren Inhalt an sich. Loggt sich der Mitarbeiter später wieder über seine Hash-Adresse ein, kann er seinen, und nur seinen, Contract einsehen und damit auch den Bearbeitungsstand verfolgen.

Solange der Mitarbeiter seinen Account-Hash nicht veröffentlicht oder an jemand anderes herausgibt, bleibt er anonym - niemand weiß, wer die Anzeige verfasst hat. Und ja, da kann man sich dann gleich die Frage nach der Vertrauenswürdigkeit stellen – doch diese Frage stellt sich immer bei anonymen Anzeigen.

Auf die beschriebene Weise allerdings könnte man neben der Möglichkeit der auch noch einen Rückkanal einführen. So könnte man neben dem Setzen eines Status auch noch Rückfragen stellen, welche vom Sender beantwortbar sind. Fragen und Antworten wären nur von Compliance Team und Mitarbeiter einseh- und bearbeitbar. Diese erweiterte Funktionalität wahrt immer noch die Anonymität des Senders, bietet jedoch sofort die Möglichkeit, durch Rückfragen des Compliance-Teams, den Gehalt der Meldung zu erhärten oder zu entscheiden, der Meldung nicht weiter nachzugehen, ohne dabei die Identität des Senders zu kompromittieren.

Colorful  powder explosion on black background.Multicolored powder splash cloud isolated on black background

Machbarkeit vs. Sinnhaftigkeit

Es gibt für Smart Contracts viele weitere Anwendungsbeispiele, die man sich gerne der Technologie zuliebe ausdenken kann. Gerne werden da in der Presse und auch in Fachmagazinen UseCases konstruiert, nur um das Buzzword „Blockchain“ oder „Smart-Contract“ nutzen zu können. Dabei sollte man bei der Auswahl einer Technologie nicht von dem Coolness-Faktor oder Hype-Cycle ausgehen, sondern von den rein fachlichen Anforderungen und den Geschäftsprozessen. Danach erst stellt sich die Frage nach der Technologie, die eingesetzt werden sollte, um dem Geschäftszweck bestmöglich zu dienen. Nicht anders herum.

Hat man seine Geschäftsprozesse und -Modelle erfasst und richtig beschrieben, dann erst stellt sich die Frage, ob es denn wirklich ein Smart Contract auf einer Blockchain sein muss, oder ob nicht eine geclusterte Datenbank das gleiche Ergebnis liefern kann. Beide Optionen haben Vor- und Nachteile.

Aus meiner Sicht kommen Smart Contracts (in einer privaten Blockchain) erst ins Spiel, wenn folgende Anforderungen an eine Datenspeicherung erfüllt werden müssen:
 

  1. Schnell aufsetzbar
  2. Schnelle und ggf. weltweite Verfügbarkeit der Daten
  3. Muss ohne Administrator laufen können
  4. Die teilnehmenden Parteien kennen sich ggf. nicht, müssen sich dennoch vertrauen können
  5. Die Einsehbarkeit der gespeicherten Daten kann öffentlich sein, sprich, jeder, der die Adresse kennt, kann sich die Daten, die gespeichert sind, anschauen (soll es vielleicht sogar)
  6. Die Daten, die gespeichert werden, sollen im Nachhinein nicht mehr änderbar sein, so wie bei einer Registrierkasse in Gastronomie oder Handel zum Beispiel
  7. Die teilnehmenden Parteien sollen/ können anonym bleiben, sprich, Schutz der persönlichen Daten der Vertragspartner ist enorm wichtig
  8. Speicherplatz, Netzwerkauslastung, Bandbreite und Stromkosten spielen keine Rolle


Gerne helfen wir Ihnen, den richtigen Weg, die richtige Technologie zu finden und die beste Entscheidung zu treffen, mit der Ihr Anwendungsfall optimal abgebildet werden kann. Egal, ob Datenbank oder Smart Contract – wir wissen, wie es geht und helfen Ihnen gerne, die nächsten Schritte zu gehen.

Der Autor

 

Ihr Kontakt bei diconium

Alexander Käppler
senior digital consultant