Im dritten Teil unserer dreiteiligen Serie „Blockchain – ein Game-Changer für die Finanzwelt?“ wollen wir anhand des konkreten Beispiels „Kontodesigner“ aufzeigen, wie sich existierende Geschäftsmodelle perfekt mit Blockchain-Technologie kombinieren lassen. Auch geben wir hier einen Ausblick, wie es in Zukunft ganz einfach möglich sein wird, Anwendungen für die Blockchain grafisch zu modellieren.
Die dreiteilige Serie ist ein gemeinschaftliches Projekt von Beckmann & Partner CONSULT und itemis.
Im ersten Teil gaben wir eine allgemeine Einführung und beantworteten die Frage, was Blockchain eigentlich ist – und was es nicht ist.
Der zweite Teil gab einen Überblick, auf welche Branchen die Blockchain in Zukunft Einfluss haben wird und identifizierte potenzielle Anwendungsfälle.
Im letzten Teil unserer Serie wollen wir nicht, wie viele andere, wild spekulieren und mit Theorien um uns werfen. Deswegen haben wir uns ein plastisches Beispiel ausgedacht. Es soll dazu dienen, einen weiteren möglichen Anwendungsbereich dieser Technologie aufzuzeigen und die Theorie mit etwas mehr Leben zu füllen.
Als Beispiel haben wir uns die Funktionsweise von Gemeinschaftskonten bei Banken (hier im Speziellen der Sparkassen) angeschaut und nach einer möglichen Alternative gesucht, welche auf Basis der Blockchain-Technologie funktionieren könnte.
Die folgende Tabelle zeigt die Unterschiede:
| UND-Konto | ODER-Konto | |
|---|---|---|
| Kontoinhaber | Mehrere Personen gemeinschaftlich | Mehrere Personen gemeinschaftlich |
| Verfügungen | Nur gemeinsam und zur gleichen Zeit | Jeder für sich, zeitlich unabhängig |
| Änderung Vertragsbedingungen (zum Beispiel Änderung Verfügungslimit, Ausstellung Verfügungsberechtigung etc.) | Nur gemeinschaftlich im Konsens | Jeder Kontoinhaber kann frei über das Konto und dessen Vertragsbedingungen entscheiden. Entscheidungen brauchen keinen Konsens. |
Das UND-Konto funktioniert also nach dem Prinzip „ganz oder gar nicht“. Kann kein Konsens hergestellt werden, erfolgt keine Verfügung. Die nur von einem Teil der Kontoinhaber angestrebten Aktionen werden nicht ausgeführt.
Bei dem ODER-Konto ist man schon deutlich flexibler, hat jedoch keine Möglichkeit, die Handlungsmacht der einzelnen Kontoinhaber einzuschränken. Da hier kein gemeinsamer Konsens nötig ist, kann jeder Kontoinhaber für sich allein frei entscheiden, auch wenn die Entscheidung/Handlung von den anderen Kontoinhabern nicht gewünscht ist.
Wie die obige Tabelle zeigt, sind die existierenden UND- und ODER-Konten für viele Anwendungsfälle nicht flexibel genug – gerade in der Geschäftswelt, wenn mehrere Parteien, ggf. mit unterschiedlichen Interessen, gemeinsam über Guthaben verfügen und zum Beispiel eine Mehrheitsentscheidung umsetzen wollen. Auch bedarf es komplizierter Regelungen im Innen- und Außenverhältnis.
Wir haben uns daher als Pilotprojekt vorgenommen, einen Kontodesigner zu entwickeln, welcher im nachfolgenden beschrieben ist.
In der Blockchain-Welt gibt es für diesen Fall die sogenannten MultiSig-Wallets. Hier existieren fertige Implementierungen, zum Beispiel die „Ethereum MultiSig Wallet“ von ConsenSys, die bereits dazu genutzt werden, Millionen von ETH zu verwalten.
MultiSig-Wallets lassen sich meist mit etwas Konfigurationsaufwand an die eigenen Anwendungsfälle anpassen. Hat man jedoch speziellere Anforderungen, muss man Anpassungen direkt im Code vornehmen. Hierzu sind natürlich Programmierkenntnisse erforderlich, im konkreten Fall in der Sprache Solidity.
Abgesehen davon, dass nur die wenigsten dazu überhaupt in der Lage sind, ergibt sich die Gefahr, dass unabsichtlich Sicherheitslücken eingebaut werden. Das ist auf der Blockchain ein besonders großes Problem, da diese in der Regel nicht einfach per Update des Smart Contracts geschlossen werden können.
Daher werden Smart Contracts, bevor sie auf der Blockchain veröffentlicht werden, in der Regel von Experten auf Sicherheitsmängel geprüft – ein zeitaufwendiges und kostspieliges Unterfangen.
Daher arbeiten wir seit einiger Zeit an einer Möglichkeit, Smart Contracts grafisch zu modellieren und aus diesem Modell den Quellcode zu generieren. Modellgetriebene Entwicklung bietet signifikante Vorteile:
Das nachfolgende Beispiel des Kontodesigners ist natürlich nur ein konkretes Beispiel dafür, wie man Smart Contracts mit Zustandsautomaten modellieren kann. Das Ziel ist es, eine Werkzeugkette bereitzustellen, mit der beliebige Smart Contracts für eine Reihe verschiedener Blockchains entwickelt werden können.
Schauen wir uns das an einem Beispiel in Bezug auf die Gemeinschaftskonten an:
Wolfgang, Elfriede und Peter wollen zusammen ein Geschäftskonto eröffnen. Sie haben sich überlegt, dass kleinere Transaktionen bis zu 500 € von jedem allein getätigt werden können. Transaktionen bis unter 5.000 € benötigen die Zustimmung von zwei der drei Kontoinhaber, und große Transaktionen ab 5.000 € müssen alle drei Kontoinhaber genehmigen.
Zur grafischen Darstellung der Anforderungen von Wolfgang, Elfriede und Peter verwenden wir sogenannte Zustandsautomaten. Diese eignen sich hervorragend zur Modellierung von Smart Contracts.
Die nachfolgende Tabelle gibt einen kurzen Überblick über die unterschiedlichen Notationselemente von Zustandsautomaten:
| Der Initialzustand gibt an, welcher Zustand aktiv wird, wenn der Zustandsautomat das erste Mal ausgeführt wird. | |
| Zustand, in dem sich der Smart Contract befinden kann. | |
| Eine Transition überführt den Zustandsautomaten von einem Zustand in einen anderen. Eine Transition wird durch ein sogenanntes Event ausgelöst. | |
| Hat eine Transition unterschiedliche Ziele, die von einer Bedingung abhängen, kann ein Entscheidungsknoten verwendet werden. |
Wird der Smart Contract das erste Mal ausgeführt, wird der Zustand Warte auf Überweisung aktiv. Das Event Überweisung führt in einen Entscheidungsknoten. Dieser überprüft, ob der Betrag unter 500 €, unter 5.000 € oder ≥ 5.000 € liegt. Trifft Bedingung 1 zu, wird die Überweisung sofort ausgeführt. Trifft Bedingung 2 zu, wird der Zustand Warte auf 1 Bestätigung betreten. Ist der Betrag größer oder gleich 5.000 €, wird der Zustand Warte auf 2 Bestätigungen betreten.
Natürlich ist dieser Zustandsautomat noch nicht formal genug definiert, um daraus Code zu generieren. Ganz ohne Programmierkenntnisse geht es leider auch hier nicht. Es folgt nun die fertige Ausbaustufe einer mit Zustandsautomaten modellierten MultiSig-Wallet:
Die Implementierung besteht aus zwei unterschiedlichen Teilen. Der erste Teil nimmt Proposals entgegen und rechnet die benötigte Anzahl an Votes aus. Der zweite Teil implementiert das eigentliche Voting und gibt diese Information im Positivfall an die Bank weiter.
Diese formale Beschreibung ermöglicht es uns nun, Smart-Contract-Code zu generieren. Zum Beispiel Solidity für die Ethereum-Blockchain. Und so sieht aktuell der Solidity-Code für Proposals aus. Dieser Code ist noch nicht funktionsfähig und auch noch nicht speicheroptimiert. Vielmehr soll diese erste Implementierung als Diskussionsgrundlage dienen, wie man Zustandsmaschinen optimal als Smart Contracts umsetzen kann.
Die dargestellte MultiSig-Wallet ist ein erster technischer Ansatzpunkt für einen Kontodesigner, der komplexe Verfügungsregelungen über gemeinschaftlich verwaltete Guthaben darstellen kann.
Die technische Implementierung wäre gegenüber den derzeitigen Lösungen der Banken für Gemeinschaftskonten in Sachen Flexibilität und Entscheidungsfreudigkeit klar im Vorteil.
Wolfgang, Elfriede und Peter können mit Hilfe eines funktionierenden Kontodesigners ihre Verfügungen über das gemeinschaftliche Vermögen deutlich flexibler gestalten als mit den derzeit existierenden technischen Möglichkeiten von Gemeinschaftskonten.
Zu klären ist natürlich noch, ob eine solche Funktionalität nach geltendem Recht zulässig wäre. Beispielsweise wäre es denkbar, die Blockchain nur zu nutzen, um den Konsens zwischen den einzelnen Parteien herzustellen. Das verfügbare Geld würde weiterhin auf dem klassischen Wege auf einem Girokonto bei der Bank aufbewahrt werden. Mit dem einzigen Unterschied, dass die Eigentümer des Girokontos nicht mehr Wolfgang, Elfriede und Peter sind, sondern ein Smart Contract mit der beispielhaften Adresse 0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe.
Bis ein Smart Contract als juristische Person am klassischen Geschäftsleben teilnehmen darf, wird aller Voraussicht nach jedoch noch einige Zeit vergehen.
Die Blockchain-Technologie bietet viele interessante und praktisch anwendbare Möglichkeiten, Prozesse zu verschlanken, flexibler zu gestalten oder im Hinblick auf die Sicherheit zu verbessern.
Wie unser Praxisbeispiel Kontodesigner zeigt, kann die Technologie Flexibilität in sonst teilweise sehr eingeschränkte Rahmenbedingungen bringen – vorausgesetzt, die rechtlichen Rahmenbedingungen und die technische Machbarkeit sind gegeben.
Die Identifizierung möglicher und vor allem sinnvoller Usecases sehen wir als erste große Herausforderung, welche bei dem Wunsch der Nutzung der Blockchain-Technologie zu meistern ist. Probleme sehen wir vor allem in der Ineffizienz bezüglich Datenmengen und Energieverbrauch sowie in noch ungeklärten Rechtsfragen. Erst wenn sich diese Dinge verbessern oder klären, wird die Blockchain-Technik massentauglich sein.
Wir sind davon überzeugt, dass diese Technologie ein großes Potenzial birgt und werden die Entwicklungen in diesem Bereich mit großer Freude und Neugier beobachten.