Das aktuelle Buzz-Thema in der Blockchain Community ist das Thema Smart Contracs. Um was es sich dabei genau handelt und wozu es nutzen soll, bleibt oft unscharf. Das liegt zum einen daran, dass die Definitionen unterschiedlich sind, aber auch weil die möglichen Use Cases sehr vielfältig sein können. Hier ein kleiner Versuch, das spannende Thema zu ordnen, seine verschiedenen Aspekte herauszuarbeiten, Anwendungspotentiale aufzuzeigen und mögliche Umsetzungstechnologien zu benennen.
Definition
Diese drei Definitionen zeigen beispielhaft, wie unterschiedlich man das Thema angehen kann (Hervorhebungen von mir, um die wichtigen Elemente herauszustellen):
Smart contracts are small programs or scripts that run on a blockchain and govern legal or contractual terms on their own. They represent a simple form of decentralization. They will become available in a variety of application areas, such as for wagers, family trusts, escrow, time stamping, proofs of work delivery, etc. In essence, they are about moving certain assets or value from one owner to another, based on some condition or event, between people or things. Smart contracts represent an “intermediate state” between parties, and we will trust these smart programs to verify and take action based on the logic behind these state changes.
Smart Contracts sind Computerprotokolle, die Verträge abbilden oder überprüfen oder die Verhandlung oder Abwicklung eines Vertrags technisch unterstützen. Eine schriftliche Fixierung des Vertrages wird damit unter Umständen überflüssig. […] Befürworter von Smart Contracts behaupten, dass viele Arten von Vertragsklauseln somit teilweise oder vollständig selbst ausführbar oder selbst durchsetzbar oder beides werden. Smart Contracts versuchen, eine höhere Vertragssicherheit gegenüber traditionellem Vertragsrecht bei gleichzeitiger Reduktion der Transaktionskosten zu erreichen.
Quelle: Wikipedia
Blockchains can run code. While the first blockchains were designed to perform a small set of simple operations – mainly, transactions of a currency-like token – techniques have been developed to allow blockchains to perform more complex operations, defined in full-fledged programming languages.
Because these programs are run on a blockchain, they have unique characteristics compared to other types of software. First, the program itself is recorded on the blockchain, which gives it a blockchain’s characteristic permanence and censorship resistance. Second, the program can itselfcontrol blockchain assets – i.e., it can store and transfer amounts of cryptocurrency. Third, the program is executed by the blockchain, meaning it will always execute as written and no one can interfere with its operation.
Quelle: Josh Stark: Making Sense of Blockchain Smart Contracts
Smart contracts sind
- technische Protokolle, die
- dezentral
- autonom (ohne Eingriff von Menschen)
- mindestens einen Teil des Vertragslebenszyklus abbilden.
Da Verträge selbst ein komplexes Thema sind, müssen wir auch genauer sagen, was der Vertragslebenszyklus alles umfasst.
Vertrags-Lebenszyklus:
- Vertragspartnerwahl (z.B. Ausschreibung)
- Vertragsverhandlung
- Vertragsformulierung
- Vertragspartner-Authentifizierung
- Vertragspartner-Autorisierung
- Vertragsschluss / -unterzeichnung
- Vertragscontrolling
- Vertragshonorierung/-bestrafung
- Vertragsbewertung (Rechtsstreit / Schiedsverfahren)
- Vertragskündigung
- Vertragsabwicklung
- Vertragsende
- Vertrags(daten)archivierung
Da die Diskussion aus der Blockchain-Ecke kommt und diese durch deren Hauptanwendung Bitcoin stark monetär gedacht wird, beschränken sich die meisten für Smart Contracts in der Literatur genannten Beispiele auf die Themen Vertragscontrolling und Vertragshonorierung/-bestrafung (aka „Bezahlung“). Um das volle Potential zu erfassen, ist es aber wichtig, den gesamten Vertragslebenszyklus im Auge zu behalten.
Anforderungen
Verträge sind rechtliche Konstrukte, die eine Übereinkunft dokumentieren, damit diese im (meist späteren) Streitfall nachvollzogen und so die Uneinigkeit im Sinne der Intention zum Zeitpunkt des Vertragsschlusses gelöst werden kann. Nach deutschem Recht können Verträge mündlich und schriftlich geschlossen werden, wobei beides einen Austausch von Willensbekundungen in Normalsprache (in Abgrenzung zu Programmiersprachen) als Grundlage erfordert. In einigen Fällen werden abhängig vom Vertragsobjekt (Immobilien, Fernabsatzgesetz, …) und / oder von den Vertragsschließenden (Minderjährige, … ) gesetzlich noch weitere Anforderungen an einen gültigen Vertragsschluss gestellt.
Vor Gericht anerkannte Vertragsschlüsse ausschließlich durch Programmcode, eine Anerkennung von Willensbekundungen, denen zufolge Programmcode oder ein technisches Protokoll die gültigen Vertragsbedingungen darstellt, sind selten, aber bereits existent. Automatisierte Wertpapier(ver)käufe bei bestimmten Kurszielen oder Kursmustern sind ein bereits praktiziertes Beispiel.
Es gibt Fälle, in denen Verträge ganz oder teilweise (auch rückwirkend) ungültig oder unwirksam sein können, weil sie gegen geltendes Recht verstoßen.
Um Verträge nach deutschem Recht in Protokolle oder Code umsetzen zu können, müssen diese meiner Meinung (als Nicht-Jurist) folgende Mindestkriterien erfüllen:
- Vollständige Präzision
- Transaktionssicherheit
- sehr hohe Ausfallsicherheit (Verträge haben keine Wartungsfenster, sondern gelten 365/24)
- Nachvollziehbarkeit
- Identifizierbarkeit der Vertragspartner
- Korrekturmechanismen
(ohne Anspruch auf Vollständigkeit – Anregungen gern gesehen).
Vorteile
Das Thema ist also nicht ganz einfach. Warum also sollte man also den Aufwand betreiben? Die Smart Contract Enthusiasten sehen folgende mögliche Vorteile:
- Kostenreduktion
- Geschwindigkeit
- Anonymität
- Orts-unabhängig
- Arbeitszeit-unabhängig
- Verbesserung der Transparenz
- Kontrollverbesserung
- Unabhängigkeit von menschlichen Fehlern
- Unbestechlichkeit
Nicht alle diese Vorteile werden bei allen Smart Contracts eintreffen.
Gefahren
Keine Chance ist ohne Risiko. Folgende direkte Risiken sehen ich:
- Fehlerhafte Inputs (Messungen, Eingabefehler)
- Software Fehler
- Hacking
- Keine menschliche Plausibilitätskontrolle
- Dramatische Fehlentwicklungen können (aufgrund der Geschwindigkeit) erst spät gestoppt werden
Jeder Stakeholder sollte sich (insbesondere solange es hierfür keine standardisierten Lösungen gibt) überlegen, wie er/sie mit diesem Risiken umgehen will und wie sie ggf. im Smart Contract gemanaged werden sollen.
Eine tiefer gehende Technikfolgeabschätzung ist dringend notwendig, um eine vollständige Liste von Gefahren und Auswirkungen auf einzelne Menschen, Gruppen und die Gesellschaft beurteilen zu können. Nicht um für oder gegen diese Technologie zu entscheiden (sie ist praktisch nicht aufzuhalten), sondern um sie – über ihre Stakeholder und ggf. auch gesetzliche Rahmenbedingungen – aktiv gestalten zu können.
Potential Use Cases
Wozu nun das Ganze? Smart Contracts keine Großtechnologie, die eine oder zwei Mega-Anwendung ermöglich (wie die Atomspaltung). Sondern eher so etwas wie der Buchdruck, der auf sehr vielen Ebenen und in den verschiedensten Anwendungen wirksam wurde. Um wirklich verstehen zu können, was mit Smart Contracts möglich werden kann / könnte, muss man in die Details gehen. Mir scheint eine Gliederung anhand des Vertragslebenszykluses am erhellendsten:
Gebiet | Beispiel | Beispiele / Ideen für mögl. Smart Contract Einsatz |
Vertragspartnerwahl | Ausschreibung |
|
Vertragsverhandlung | pers. Verhandlung | automatisierte, dezentrale Auktionen |
Vertragsformulierung | Juristen schreiben einen Vertrag / AGB |
|
Vertragspartner-Authentifizierung | Vorlage des Personalausweises | Vertragspartner-Identifizierung ohne Preisgabe von persönlichen Daten (quasi-anonym) (Beispiel) |
Vertragspartner-Autorisierung |
|
|
Vertragsschluss |
|
|
Vertragscontrolling |
|
Automatisierte Prüfung und Dokumentation von vertraglich spezifizierten Leistungsparametern (Verfügbarkeiten, Raten- & Miet-Zahlungen, Qualitätsparameter, … ) |
Vertragshonorierung/-bestrafung |
|
|
Vertragsbewertung | Rechtsstreit / Schiedsverfahren | automatischer Check von Smart Contract code auf Vollständigkeit, Wiederspruchslosigkeit, Gesetzeskonformität, Wirtschaftlichkeit, … |
Vertragskündigung | begrenzte Laufzeit / ausdrückliche Kündigung (ggf. mit Frist) | Kriterien-basierte Kündigung |
Vertragsabwicklung | Abwickelungsaktivitäten, Roll back, etc. | (automatisiertes) Opt-Out und Auszahlungsmechanismen |
Vertragsende | Leistungseinstellung | automatisierte Leistungseinstellung |
Vertrags(daten)archivierung |
|
|
Das DAO-Projekt war ein Versuch einer „smarten“ Risiko-Kapitalgesellschaft, die die Aspekte Vertragspartner-Authentifizierung, Vertragspartner-Autorisierung, Vertragschluss, Vertragshonorierung, Vetragskündigung, Vertragsabwickelung, Vertragsende automatisiert. Das Projekt ist jedoch an Softwarefehlern der zugrunde liegenden Ethereum-Plattform gescheitert. Als Prototyp betrachtet hat das Projekt jedoch tatsächlich belegt, dass die DAO-Idee funktionieren kann.
Auch andere Projekte (wie Augur, Slock.it, oder Boardroom) – behaupten, bereits Smart Contracts zu benutzen (Quelle). Wie weit das stimmt, kann ich im Gegensatz zum DAO-Projekt (noch) nicht beurteilen.
Technologien
Für solche Smart Contracts braucht es mindestens zwei Komponenten – einen Datenspeicher und eine Anwendungslogik.
Datenspeicher
Wie bereits oben beschrieben wird die Blockchain Technologie als idealer Datenspeicher gefeiert. Sie bietet Dezentralität, Währung, hohe Sicherheit, Anonymität, geringe Dateigröße und andere Eigenschaften, die nicht nur für DigiCoins für wertvoll gehalten werden, sondern auch für Smart Contracts.
Grundsätzlich ist jedoch jede (dezentrale) Datenspeichertechnologie mehr oder weniger geeignet, um als Basis für Smart Contract zu dienen. Möglich wären z.B. auch verteile MySQL Datenbanken, P2P Technologien oder XML-Files. Im Zweifel kommt es auf den Use Case an: Welche Eigenschaften braucht er, welche Performance braucht er, welche DB-Größe erzeugt er? Gideon Greenspan beschreibt hier sehr gut, was mit der Blockchain-Technologie möglich ist und was nicht.
Eine Einzelfall-Analyse ist jedoch immer angebracht. Auch, weil es ja inzwischen sehr viele verschiedene Blockchain-Protokolle gibt.
Anwendungslogik
Grundsätzlich lässt sich die Anwendungslogik (also auch Smart Contracts) Server-basiert oder Client-basiert ausführen. Im Bitcoin Protokoll verschmelzen diese Rollen zwar (da im dezentralen Netzt eigentlich alle Clients auch Nodes [vollständige Kopien der Blockchain] sein sollen), aber mit dem Aufkommen von Lite-Clients läuft auch dieses wieder auseinander.
Smart Contracts, die mit der Bitcoin Blockchain arbeiten wollen, müssen jedoch immer außerhalb der Blockchain aktiv werden (theoretisch mit jeder existierenden Programmiersprache) und können diese nur über die im Bitcoin Protokoll spezifizierten Schnittstellen lesen und Änderungen in die Bitcoin Blockchain schreiben. Die Möglichkeiten sind jedoch sehr limitiert. Um jedoch die Bedingung echter Dezentralität erfüllen zu können, müssten Bitcoin Blockchain Smart Contracts nicht nur in einer Betriebsystemunabhängigen Sprache geschrieben werden, sondern es muss zudem eine Verteilungslogik entwickelt werden.
Daneben gibt es mit Ethereum eine weitere Blochchain mit erweiterten Möglichkeiten:
Auf der einen Seite unterscheidet sich Ethereum nicht so sehr vom Bitcoin: Es gibt eine Blockchain, die alle Transaktionen speichert, es gibt Miner, die Transaktionen bestätigen, und es gibt eine Art Währung – der Ether – die die Miner als Belohnung bekommen. Der eine Unterschied ist, dass jeder in die Transaktionen Codes hineinschreiben bzw. diese als Miniaturprogramm gestalten kann. Zum Beispiel dass eine bestimmte Menge Coins freigesetzt wird, wenn jemand eine Primzahl liefert. Oder dass Empfänger B eine Anzahl Coins erhält, wenn der Bitcoin-Preis auf bitcoin.de über 350 Euro geht. Oder dass jemand Coins erhält, wenn er eine Datei speichert.
Quelle: Christoph Bergmann
Ethereum will eine komplette Smart Contract Infrastruktur aufbauen: Es gibt bereits sechs Zentralen, in Baar (Schweiz), New York, Berlin, Amsterdam, Toronto und London sowie Ethereum-Meetups auf der ganzen Welt. Der Plan ist, ein Netzwerk aufzubauen, dass alles dezentralisiert.
Es gibt mehrere Implementierungen von Ethereum:
Mehr zu Ethereum im Yellow Paper und (noch rudimentär, aber sich entwickelnd) in meiner Info-Sammlung „all about ether„. Für Entwickler evtl. interessant: Building a smart contract using the command line.
Daneben gibt es mit Lisk ein ähnliches Projekt, dass die Entwicklung von Smart Contracts auf Basis Javascript ermöglicht:
Mit dem Thema Lisk will ich mich in einem gesonderten Artikel befassen.
Update 14.2.2017: Die Smart Contract Fähigkeit der Bitcoin Blockchain soll erweitert werden: MAST – Die unbekannten Pläne zu Bitcoin Smart Contracts
Update 16.2.2017: BOScoin, a New Cryptocurrency, Introduces “Trust Contracts” to Overcome the Shortcomings of Ethereum Smart Contracts
Update 25.12.2017: IOTA hat sich inzwischen als eine spannende Alternative für Smart Contracts etabliert. Hoffe in Kürze dazu einen Artikel liefern zu können.
Update 22.8.2019: Miniscript: Eine neue Programmiersprache für Bitcoin Smart Contracts
Disclaimer – Hinweis auf Interessenskonflikt: Der Autor ist in den oben erwähnten Kryptowährungen selbst investiert
Alle Bilder: Carsten Buchholz
Weiterlesen:
Manfred Neidel: Blockchain & Smart Contracts (mit realen Anwendungsbeispielen und weiterführenden Links)
Dieser Artikel ist Teil meines Projektes „Blockchain Exploration“.
Siehe in diesem Kontext auch:
Mein DAO Blockchain Experiment (Tagebuch ongoing, [un-]regelmäßig aktualisiert)
Mein Digi Coin Mining Experiment (Tagebuch ongoing, [un-]regelmäßig aktualisiert)
Betrachtungen zur Bitcoin-Kursentwicklung
Keinen Neun-mal-Sechs Beitrag mehr verpassen: Das E-Mail Abo nutzen.
Siehe auch:
Pingback: The State of Bitcoin | Neun Mal Sechs