Machbarkeitsstudie zur Verwendung von Smart Contracts zur Realisierung komplexer Versicherungsprodukte

Inhaltsverzeichnis

Zusammenfassung

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Akronyme

1 Einleitung
1.1 Einleitung
1.1.1 Eingrenzung des Untersuchungsgebiets .
1.1.2 Forschungsfrage
1.1.3 Vorgehensweise

2 Grundlagen Blockchain und Smart Contracts
2.1 Literatur
2.2 Smart Contracts
2.3 Blockchain
2.3.1 Entstehungsgeschichte
2.3.2 Bitcoin
2.3.2.1 Grundlagen
2.3.2.2 51%-Attacken
2.3.2.3 Asymmetrische Kryptographie
2.3.2.4 Hashfunktionen
2.3.3 Ethereum
2.3.3.1 Grundlagen
2.3.3.2 Transaktionen
2.3.3.3 Smart Contracts 16
2.3.3.4 Gas
2.3.3.5 Ethereum Virtual Machine (EVM)
2.3.4 Differenzierung von Blockchains nach Lese- und Schreibrechten 19
2.3.5 Hyperledger 20
2.4 Orakel
2.5 Bestehende Produkte Smart Contract-basierte Produkte
2.5.1 Etherisc 24
2.5.2 B3i Catastrophe XoL Reinsurance 28
2.5.3 Axa Fizzy

3 Anforderungen an Smart Contracts für Versicherungsprodukte
3.1 SWOT-Analyse 31
3.1.1 Hintergrund 31
3.1.2 Chancen und Risiken
3.1.2.1 Politische Faktoren
3.1.2.2 Ökonomische Faktoren
3.1.2.3 Soziokulturelle Faktoren
3.1.2.4 Technologische Faktoren
3.1.2.5 Ökologische Faktoren
3.1.2.6 Rechtliche Faktoren 38
3.1.2.7 Zusammenfassung
3.1.3 Stärken und Schwächen
3.1.3.1 Vorgehensweise 48
3.1.3.2 Marketing
3.1.3.3 Product Development / Produktentwicklung
3.1.3.4 Sales / Vertrieb
3.1.3.5 Underwriting 51
3.1.3.6 Contract Administration & Customer Service / Vertragsver- waltung und Kundenservice
3.1.3.7 Claims Management / Schadenregulierung 52
3.1.3.8 Asset & Risk Management
3.1.3.9 Unternehmensführung
3.1.3.10 IT
3.1.3.11 Human Resources / Personalabteilung
3.1.3.12 Controlling
3.1.3.13 Legal Department / Rechtsabteilung
3.1.3.14 Public Relations 56
3.1.3.15 Zusammenfassung
3.1.4 SWOT-Strategien
3.2 Zwischenfazit

4 Entwurf eines Versicherungskonzeptes auf Basis von Smart Contracts
4.1 Grundsätzlicher Aufbau und Vorgehensweise
4.2 Smartphoneversicherung auf Basis von Ethereum 64
4.2.1 Administrative Funktionen 70
4.2.2 Verwendetes Orakel
4.2.3 Einschränkungen des Programms
4.3 Lösungsansätze 72
4.3.1 Sicherheit des Programms
4.3.2 Dezentrale Versicherung und Schadenregulierung 74
4.3.2.1 Moral Hazard durch fehlende Durchgriffsmöglichkeiten des Versicherers
4.3.2.2 Beteiligung des Versicherungsnehmers 75
4.3.2.3 Ausschnittsdeckungen
4.3.2.4 Schadenregulierung durch dezentrale Orakel
4.3.2.5 Kooperation mit Erst- oder Führungsversicherer

5 Diskussion
5.1 Dunkelverarbeitung 79
5.2 Rechtliche Rahmenbedingungen
5.2.1 Versicherungsaufsichtsgesetz
5.2.2 Versicherungsvertragsgesetz
5.2.3 Kreditwesengesetz 82
5.2.4 Datenschutz 83
5.2.5 Geldwäschegesetz
5.3 Umgang mit rechtlichen Unsicherheiten
5.4 Ausblick 86

Fazit

A Geschäftsentwicklung der Sachversicherung in Deutschland im Jahr

B §1 der Informationspflichtenverordnung - Informationspflichten der Versicherungs-

unternehmen

Literaturverzeichnis

Sachregister

Quellcodeverzeichnis

Inhaltsverzeichnis

Eidesstattliche Erklärung

Zusammenfassung

Masterthesis

Machbarkeitsstudie zur Verwendung von Smart Contracts zur Realisierung komplexer

Versicherungsprodukte

von Robert Jost MICKEL

Smart Contracts bieten als Teil der Blockchain-Technologie die Möglichkeit, Verträge automa-

tisch zu erfüllen und durchzusetzen. Dies ist für Versicherungsanwendungen relevant, da sich

hieraus möglicherweise Kostensenkungspotentiale und Geschwindigkeitsgewinne in der Ver-

tragsbearbeitung ergeben. Die vorliegende Arbeit beschäftigt sich mit der Fragestellung, welche

Anforderungen Blockchain-basierte Smart Contracts erfüllen müssen, um für komplexe Sach-

versicherungen geeignet zu sein und ob diese Anforderungen durch die derzeit bestehenden

Blockchain-Technologien erfüllt werden. Der erste Teil der Forschungsfrage wird durch die Er-

stellung eines Anforderungskataloges auf Grundlage einerSWOT-Analyse von Smart Contracts

beantwortet. Zur Beantwortung des zweiten Teils wird ein Versicherungsprodukt entwickelt, das

versucht, die aus der SWOT-Analyse abgeleiteten Anforderungen umzusetzen.

Das vorgestellte Produkt ist nicht vollkommen dezentral aufgebaut. Dies ist darin begründet,

dass ein komplett dezentrales Konzept mit rechtlichen Unsicherheiten verbunden wäre, die

aus der automatischen Durchsetzung der Verträge resultieren. Außerdem kann eine dezentra-

le Regulierung komplexer Schäden mit der aktuellen Blockchain-Technologie noch nicht umge-

setzt werden. Die formalrechtlichen Anforderungen an ein Versicherungsprodukt werden jedoch

durch das entwickelte Konzept erfüllt. Diese Arbeit kommt deshalb zu dem Ergebnis, dass Smart

Contracts gegenwärtig die Voraussetzungen für die Nutzung für komplexe Sachversicherungen

nur teilweise erfüllen. Ein Produkt, das die bestehenden Einschränkungen berücksichtigt, kann

für Versicherungsunternehmen aber dennoch einen Mehrwert bieten.

Abbildungsverzeichnis

2.1 Transaktionshistorie von Bitcoins (Nakamoto, 2008)

2.2

Inhalt der Blöcke in der Bitcoin-Blockchain (Nakamoto, 2008)

2.3 Aufbau der Bitcoin-Blockchain (Okupski, 2014, S. 35)

2.4 Asymmetrische Kryptographie, schematische Darstellung (Drescher, 2017, S. 97) 13

2.5 Anfrage und Bereitstellung externer Daten durch Orakel

2.6 Aufbau der Etherisc Versicherungsplattform (Mussenbrock, 2017a, S. 28)

2.7 Datenstruktur in der B3i-Blockchain (B3i, 2018)

3.1 Vertriebswege von Versicherungen 2015 (GDV, 2015b)

3.2 Vereinfachte Darstellung der Kapitalausstattung eines Versicherungsunterneh-

mens (GDV, 2015a) 39

3.3 Generische Wertkette von Porter (Porter und Millar, 1985, S. 3)

3.4 Wertkette von Versicherungsunternehmen nach Porter und Rahlfs (Eling und

Lehmann, 2017, S. 4)

4.1 Aufbau einer Versicherungsplattform für Pay-as-you-go KFZ-Versicherungen

(Vo u. a., 2017)

4.2 Konditionen der Smartphone-Versicherung be-relaxed (DeTeAssekuranz, 2017b) 63

4.3 Aufbau einer Ethereum-basierten Versicherung für Smartphones, eigene Dar-

stellung

4.4 Prüfung von Solidity Code durch Übersetzung in F* (Bhargavan u. a., 2016) 73

5.1 Versicherungsprozess aus Sicht des Versicherers und des Dienstleisters

5.2 Langfristige Ziele bei der Entwicklung von Ricardian Contracts (Clack u. a.,

2016b)

Tabellenverzeichnis

1.1 Meilensteine bei der Erstellung dieser Masterarbeit .

2.1 Themenbezogene Schlagworte auf den Plattformen Springer Link, GKV, EBS- CO host und ACM

3.1 Chancen-/Risikenprofil von Smart Contracts für Versicherungsanwendungen 47

3.2 Zusammenfassung der wichtigsten Stärken und Schwächen von Smart Contracts im Vergleich zur herkömmlichen Vertragsbearbeitung 57

3.3 SWOT-Stragien für Smart Contracts als Grundlage für Versicherungsprodukte

5.1 Gaskosten der Smartphone-Versicherung

A.1 Geschäftsentwicklungen der Sachversicherung in Deutschland im Jahr 2016,

Quelle: http://www.gdv.de/2017/01/geschaeftsentwicklung-2016-alle-zahlen-im-

ueberblick/

Akronyme

Abbildung in dieser leseprobe nicht enthalten

Kapitel 1

Einleitung

1.1 Einleitung

Der Begriff Blockchain wird derzeit vor allem im Zusammenhang mit Kryptowährungen wie Bitcoin häufig genannt und ist Gegenstand der öffentlichen und wissenschaftlichen Debatte. Neben virtuellen Währungen bietet die Blockchain mit Smart Contracts eine weitere Innovati- on, die weniger im Fokus der Öffentlichkeit steht. Smart Contracts bestehen im Unterschied zu herkömmlichen Verträgen aus Programmen, die bestimmte vertraglich vereinbarte Handlungen selbstständig ausführen können, wenn die dafür vorgegebenen Voraussetzungen erfüllt werden. Diese Funktion stellt einen wesentlichen Kern der Blockchain-Technologie dar, der primär für die Finanzindustrie von Interesse ist ,¹ in abgewandelter Form bzw. in Teilen der Wertschöp- fungskette jedoch auch in der Versicherungsindustrie angewendet werden kann.

Die erhofften Vorteile durch den Einsatz von Smart Contracts gegenüber der herkömmlichen Vertragsgestaltung liegen dabei aus Sicht der Versicherer in einer vollständig digitalen und automatisierten Abwicklung von Versicherungsverträgen und dem daraus resultierenden Ko- stensenkungspotential. Des Weiteren ermöglicht eine voll digitale Regulierung von Schadenfäl- len Geschwindigkeitsvorteile in der Abwicklung, die zu höherer Kundenzufriedenheit führen. Außerdem lassen sich durch geringere Verwaltungskosten möglicherweise Marktsegmente er- schließen, die vorher aufgrund verhältnismäßig hoher Kosten nicht rentabel waren (vgl. Mus- senbrock, 2017a).

Die Kostenreduzierung und die Erhöhung der Kundenzufriedenheit bilden die derzeit wich- tigsten Themen der Versicherungsbranche; die Digitalisierung wird dabei als ein wesentliches Werkzeug angesehen (vgl. Eling und Lehmann, 2017, S. 6). Daher ist das Thema Smart Con- tracts beziehungsweise die Frage nach deren Eignung als Werkzeug für die Versicherungsbran- che äußerst relevant.

Bei den bestehenden Versicherungsprodukten auf Basis von Blockchain-Technologien handelt es sich ausschließlich um parametrische Versicherungen, in denen die Schadenregulierung voll- ständig auf Parametern wie Wetterdaten oder Flugverspätungen basiert, die frei verfügbar sind und auf die der Versicherungsnehmer keinen Einfluss hat. Die vorliegende Arbeit hat daher das Ziel zu bewerten, ob auch eine klassische Sachversicherung über die Blockchain-Technologie realisierbar ist. In den folgenden Abschnitten wird erläutert, wie sich die vorliegende Arbeit mit dieser Fragestellung auseinandersetzen wird.

1.1.1 Eingrenzung des Untersuchungsgebiets

Die vorliegende Arbeit untersucht die Nutzbarkeit von Smart Contracts ausschließlich für Ver- sicherungsanwendungen. Dabei wird das Untersuchungsgebiet noch weiter eingegrenzt auf pri- vate und gewerbliche Sachversicherungen, da Lebens- und Krankenversicherungen jeweils ei- gene, komplexe Märkte mit anderen Anforderungen darstellen. Die Bewertung der rechtlichen Anforderungen sowie die Betrachtung des Wettbewerbes erfolgen anhand des deutschen Versi- cherungsmarktes.

Zur Realisierung des eigenen Konzeptes werden aus praktischen Gründen ausschließlich Block- chains in Betracht gezogen, zu denen Informationen frei verfügbar sind. Die Untersuchung der Blockchain-Technologie erfolgt anhand des derzeitigen Standes der jeweiligen Technologie.² Der Anforderungskatalog an Smart Contracts soll möglichst umfassend sein, um ein vollstän- diges Bild über die Nutzbarkeit von Smart Contracts für Versicherungsanwendungen zu ge- ben. Deshalb werden darin technische, wirtschaftliche, versicherungstechnische und rechtliche Aspekte sowie die IT-Sicherheit betrachtet.

Der wesentliche Unterschied von klassischen Sachversicherungen gegenüber den bereits existie- renden parametrischen Versicherungen auf Basis von Smart Contracts liegt in der Komplexität der Schadenregulierung. Die Frage, inwiefern diese erhöhte Komplexität durch Smart Contracts beherrscht werden kann, ist deshalb ein zentraler Punkt bei der Entwicklung eines Versiche- rungskonzeptes auf der Basis von Smart Contracts. Die Bewertung des entwickelten Konzeptes erfolgt anhand des zuvor entwickelten Anforderungskataloges. Dabei werden vor allem qualita- tive Merkmale betrachtet.

1.1.2 Forschungsfrage

Innerhalb des zuvor eingegrenzten Untersuchungsgebietes hat diese Arbeit das Ziel, die folgen- de Forschungsfrage zu beantworten, die in zwei Teile gegliedert ist:

- Welche Anforderungen müssen Blockchain-basierte Smart Contracts erfüllen, damit sie für komplexe Sachversicherungen genutzt werden können? - Werden diese Anforderungen durch die derzeit bestehenden Blockchain-Technologien er- füllt? Der erste Teil der Forschungsfrage wird durch einen Anforderungskatalog beantwortet, der in den folgenden Kapiteln entwickelt wird. Im Anschluss daran wird ein konkretes Konzept ent- wickelt für eine Sachversicherung auf Basis von Smart Contracts. Die darauf folgende Unter- suchung dieses Konzeptes anhand der zuvor definierten Anforderungen liefert die Antwort auf den zweiten Teil der Forschungsfrage.

1.1.3 Vorgehensweise

Die Fachliteratur zu den behandelten Themengebieten bildet die Grundlage für diese Arbeit. Diese enthält vor allem in den technischen Themenfeldern Blockchain und Smart Contracts neben publizierten Artikeln und Büchern auch graue Literatur in Form von Whitepapers und technischer Dokumentation.

Der Anforderungskatalog wird anhand einer SWOT-Analyse entwickelt. Dabei handelt es sich um ein etabliertes Werkzeug des strategischen Managements, das auch außerhalb eines Unter- nehmenskontexts eingesetzt werden kann, um Strategien aus internen und externen Faktoren abzuleiten. Dazu werden zunächst die Grundlagen der Blockchain-Technologie beschrieben, sowie die Blockchains Ethereum und Hyperledger dargestellt, die mit einem Fokus auf Smart

Abbildung in dieser leseprobe nicht enthalten

TABELLE 1.1: Meilensteine bei der Erstellung dieser Masterarbeit

Contracts entwickelt wurden und die die technische Grundlage für die aktuellen Versicherungs- produkte auf Basis der Blockchain-Technologie bilden (vgl. Eling und Lehmann, 2017, S. 6). Einige dieser Produkte werden im Anschluss ebenfalls vorgestellt.

Auf Grundlage der Erkenntnisse aus der SWOT-Analyse wird ein eigenes Produktkonzept für eine Sachversicherung auf Basis von Smart Contracts entwickelt. Einer der zentralen Punkte ist dabei die Regulierung komplexer Schäden durch Smart Contracts. Der Begriff komplexe Schäden bezeichnet dabei diejenigen Schäden, die nicht durch einzelne Parameter dargestellt werden können. Für die Erstellung des Versicherungskonzeptes auf Basis von Smart Contracts werden die bestehenden parametrischen Versicherungen, die diese Technologie bereits nutzen, als Grundlage verwendet. Das entwickelte Konzept wird im Anschluss anhand der Kriterien des Anforderungskataloges bewertet.

Die allgemeine Vorgehensweise bei der Erstellung der Arbeit besteht darin, die Kapitel ent- sprechend ihrer Gliederung zu erstellen, da diese inhaltlich aufeinander aufbauen. Während des Bearbeitungszeitraumes von fünf Monaten wird dabei der in Tabelle 1.1 dargestellte Plan ver- folgt.

Kapitel 2 Grundlagen Blockchain und Smart Contracts

2.1 Literatur

Eine Auswertung der Plattformen Springer Link, des Gemeinsamen Verbundkataloges GKV (ohne Online-Contents), EBSCO host und ACM zu den relevantesten Schlagworten für die vorliegende Masterarbeit liefert die in Tabelle 2.1 dargestellten Ergebnisse. Die mit Stern(*) markierten neuen Ergebnisse beinhalten Quellen, die im Jahr 2016 oder später veröffentlicht wurden. Viele der wissenschaftlichen Publikationen zum Thema Blockchain widmen sich den Themen Sicherheit (Luu u. a., 2016), Performance der Blockchains sowie Privacy (Ben-Sasson

Abbildung in dieser leseprobe nicht enthalten

TABELLE 2.1: Themenbezogene Schlagworte auf den Plattformen Springer Link, GKV, EBS- CO host und ACM

u. a., 2013). Quellen zum Thema Smart Contracts sind deutlich weniger zahlreich und der Such- begriff „Smart Contracts“ liefert noch eine geringere Anzahl von Ergebnissen. Daher wurde die vorliegende Arbeit auch auf Grundlage von grauen Quellen erstellt. Dies liegt zum einen an der beschriebenen geringen Anzahl wissenschaftlicher Quellen, zum anderen aber auch daran, dass die Entwicklung der Blockchain-Technologie (Im Folgenden auch bezeichnet als DLT = Distri- buted Ledger Technology) derzeit maßgeblich durch die Wirtschaft vorangetrieben wird. Inso- weit verschwimmen die Grenzen zwischen Wissenschaft und Wirtschaft, beispielsweise durch Whitepaper für Kryptowährungen wie Bitcoin oder Ethereum, die zunächst als Konzept erdacht werden und später zu eigenen Wirtschaftsbereichen mit erheblicher finanzieller Schlagkraft heranwachsen. Eling und Lehmann (2017) kommen in ihrer Literaturstudie zu dem Ergebnis, dass zum Thema Digitalisierung der Versicherungsbranche und damit zur Nutzung der DLT für Versicherungsanwendungen bislang kaum wissenschaftliche Publikation veröffentlicht wurden, gleichzeitig wird dieser Bereich als praxisrelevant hervorgehoben.

2.2 Smart Contracts

Der Begriff Smart Contract wurde 1994 von Nick Szabo im gleichnamigen Artikel geprägt. Dar- in beschreibt er einen Smart Contract als computerbasiertes Transaktionsprotokoll, das den In- halt eines Vertrages ausführt. Der Smart Contract soll in dieser Hinsicht alle relevanten Vertrags- bestandteile enthalten und automatisch umsetzen. Unvorhergesehenes Verhalten durch techni- sche Fehler muss dazu ausgeschlossen werden. Durch die automatische Umsetzung haben die Vertragsparteien keine Möglichkeit, den Vertrag durch betrügerische Handlungen zu missach- ten. Außerdem verringert sich der Bedarf nach vertrauenswürdigen Dritten (Trusted Third Par- ties, TTP), die zwischen den Vertragsparteien vermitteln (vgl. Szabo, 1994). Diese Definition entspricht relativ genau Transaktionen von Kryptowährungen, die im folgenden Abschnitt be- schrieben werden und von Szabo als mögliches Einsatzgebiet von Smart Contracts identifiziert wurden.

Eine weitere relevante Definition lieferte Grigg 2004 mit dem Begriff „Ricardian Contracts“, die Smart Contracts ähneln, da sie ebenfalls von Computer ausgeführt werden können. Im Ge- gensatz zu Smart Contracts ist deren Ansatz allerdings nicht, mittels Programmen Vertragsbe- standteile abzubilden, sondern klassische Verträge fürMaschinen les- und umsetzbar zu machen (vgl. Szabo, 1994).

In der aktuellen Literatur wird jedoch oftmals nicht unterschieden, ob die beschriebenen Smart Contracts eher den Ansatz von Szabo oder jenen von Grigg verfolgen. Auch wenn sich beide Arten von Smart Contracts auf den ersten Blick ähneln, bieten sie unterschiedliche Herausfor- derungen bei der Durchsetzung. Szabos Smart Contracts müssen möglichst fehlerfrei funktio- nieren, da sie bewusst so gestaltet sind, dass eine nachträgliche Änderung des Vertragsinhaltes sehr aufwendig oder gar unmöglich ist. Sie basieren auf dem „Code is Law“-Prinzip und werden gemäß ihres Codes durchgesetzt, ungeachtet dessen, wie dieser im Verhältnis zu den geltenden Gesetzen steht oder wie er von den Vertragspartnern interpretiert wird. Die Verbindlichkeit des Vertrages basiert hierbei auf der korrekten Funktionsweise und Sicherheit des Codes. Dieser Ansatz wird als nicht-traditionelle Durchsetzung bezeichnet.

Demgegenüber stehen Ricardian Contracts, die zwar auch eine automatische Durchsetzung ent- halten können, diese aber nicht als alleiniges Durchsetzungsmittel besitzen. Da es sich bei ih- nen um klassische Verträge in digitaler Form handelt, besteht die Möglichkeit der traditionellen Durchsetzung von Ansprüchen beispielsweise vor Gericht. Die Verbindlichkeit des Vertrages basiert damit auf der Auslegung durch die Vertragsparteien und - im Falle von Konflikten - des zuständigen Gerichts (vgl. Clack u. a., 2016b, S. 4). Um diese unterschiedlichen Herangehens- weisen mit einer eindeutigen Beschreibung gerecht zu werden, definiert Clack Smart Contracts wie folgt:

„Ein Smart Contract ist ein automatisierbarer und durchsetzbarer Vertrag.“ (Clack u. a., 2016b, S. 2) Automatisierbarkeit setzt dabei keine vollständig autonome Bearbeitung durch Computer voraus sondern räumt ein, dass Teile des Vertrages durch Menschen geregelt werden. Die Durchsetz- barkeit kann entweder durch traditionelle oder durch nicht-traditionelle Maßnahmen erreicht werden. Beginnend mit der Entstehungsgeschichte der Blockchain-Technologie wird die vorlie- gende Arbeit im Folgenden Clacks Definition für Smart Contracts verwenden.

2.3 Blockchain

2.3.1 Entstehungsgeschichte

Da die Entwicklung der DLT eng an die Entwicklung des Bitcoin geknöpft ist, wird im Folgen- den ein kurzer Überblick über die Entwicklung von Bitcoin gegeben.

Finanztransaktionen im Internet waren vor der Einführung von Kryptowährungen auf TTPs in Form von Banken, Zahlungsdienstleistern und anderen angewiesen. Die Inanspruchnahme der Dienstleistungen der TTP erhöht die Transaktionskosten. Außerdem führt auch das Trust-Based Modell selbst zu Transaktionskosten, da sowohl Käufer als auch Verkäufer im Trust-Based Mo- dell keine hundertprozentige Sicherheit haben, die Bezahlung bzw. Waren auch wirklich zu erhalten, beispielsweise aufgrund von Betrug durch die andere Partei. Daraus resultieren wei- tere Transaktionskosten, sowohl in direkter Form durch notwendige Verifikation von Kunden, als auch indirekt, da die TTPs im Falle von Konflikten in der Regel eingreifen müssen, was wiederum die Kosten für deren Dienstleistungen erhöht.

Kryptowährungen schlagen eine Lösung für dieses Problem vor, indem Transaktionen nicht durch TTPs sondern durch Kryptographie abgesichert werden. So gesicherte, praktisch irre- versible Transaktionen führen dazu, dass sich der Verkäufer sicher sein kann, dass er die verein- barte Bezahlung erhält. Durch ergänzende treuhänderische Funktionen, realisiert durch Smart Contracts, kann auch der Käufer geschützt werden.

Im Ergebnis werden keine TTPs mehr benötigt und die Transaktionskosten reduziert. Durch den Wegfall der Notwendigkeit von Vertrauen zwischen den Vertragspartnern reduzieren sich die Transaktionskosten außerdem noch weiter. Kunden hätten dann weniger Anreiz, Händler mit guter Reputation günstigeren, unbekannten Händlern vorzuziehen, da keine Verifizierung der Vertragspartner mehr stattfinden muss. Letztlich wäre so völlige Anonymität zwischen den Vertragspartnern möglich (vgl. Nakamoto, 2008).

Ende der 1990er Jahre entstanden bereits Konzepte für digitaleWährungen auf Basis von asym- metrischen bzw. Public-Key-Verschlüsselungsverfahren, die jedoch nicht in die Praxis umge- setzt werden konnten. Ursache hierfür waren zum einen Schwierigkeiten bei der technischen Umsetzung dieser dezentralen Systeme im Allgemeinen, aber auch das sogenannte Double- Spending-Problem, bei dem sichergestellt werden muss, dass Transaktionen ein und derselben Werte nicht durch Fehler oder böswillige Teilnehmer mehrfach mit unterschiedlichen Empfän- gern durchgeführt werden.²

Im Zusammenhang mit DLTs bedeutet dies, dass die Blockchain über einen Konsensmechanis- mus verfügen muss, der Double-Spending verhindert und einen Konsens aller Teilnehmer über den korrekten Zustand des Netzwerks gewährleistet. Im Folgenden werden einige der wesentli- chen Merkmale der Blockchain-Technologie anhand der Bitcoin-Blockchain erläutert, da diese viele folgende Blockchains maßgeblich beeinflusst hat. Im Anschluss daran werden die Block- chains Ethereum und Hyperledger vorgestellt, da diese mit dem ausdrücklichen Ziel entwickelt wurden, eine Plattform für Smart Contracts zu bieten.

2.3.2 Bitcoin

2.3.2.1 Grundlagen

Nakamoto (2008) konnte das Double-Spending-Problem lösen, indem jeweils die erste Trans- aktion eines jeweiligen Coins als die korrekte Transaktion definiert und mit einem Timestamp versehen allen Teilnehmern des Netzwerkes mitgeteilt wird. Die jeweiligen Coins enthalten da- bei ihre eigene Transaktionshistorie (vgl. Abbildung 2.1). Besitzer des Coins ist dabei immer der Empfänger der letzten Transaktion des Coins, da dieser als einziger die Möglichkeit hat, eine weitere Transaktion des Coins zu veranlassen.

ABBILDUNG 2.1: Transaktionshistorie von Bitcoins (Nakamoto, 2008)

Als Konsensmechanismus wird ein Proof-of-Work (PoW) Verfahren eingesetzt, bei dem No- des (Die Teilnehmer des Netzwerkes) Rechenaufwand betreiben müssen, um ein Hashpuzzle zu lösen. Durch die Hashpuzzles sind Transaktionen bzw. deren Verifikation an physikalische Res- sourcen in Form von Hardware und Energie geknüpft. Außerdem verhindert dasPoW-Verfahren Denial-of-Service-Attacken auf das Netzwerk, die in der massenhaften Ausführung von leeren Transaktionen bestehen. Das Bitcoin-Netzwerk wiederholt dabei die folgenden Schritte (vgl. Nakamoto, 2008):

1. Neue Transaktionen werden den Netzwerkteilnehmern mitgeteilt
2. Nodes sammeln veröffentlichte Transaktionen in einem Block
3. Jede Node versucht, das Hashpuzzle für den PoW des eigenen Blocks zu lösen
4. Falls der PoW für den eigenen Block gefunden wurde, wird der Block mit PoW den Netzwerkteilnehmern mitgeteilt
5. Andere Nodes prüfen, ob der PoW korrekt ist und die Transaktionen nicht schon durch- geführt wurden
6. Falls die Prüfung erfolgreich ist, akzeptieren andere Nodes den Block, in dem sie diesen als Ausgangsblock für die Arbeit am nächsten Block verwenden, diese beginnt mit Schritt

So ergibt sich eine Kette aus Blöcken, die Blockchain. Der Inhalt der Blöcke wird in Abbildung

2.2 dargestellt:

ABBILDUNG 2.2: Inhalt der Blöcke in der Bitcoin-Blockchain (Nakamoto, 2008)

Für die Erstellung von Blöcken erhalten die Nodes eine Belohnung in Form neuer Bitcoins sowie die Gebühren für die Transaktionen, die im erstellten Block verarbeitetet werden. Dabei kann es aufgrund von Latenz bei der Verbreitung neuer Blöcke im Netzwerk dazu kommen, dass

mehrere unterschiedliche valide Blöcke am Ende der Blockchain stehen, sich die Kette also teilt und unterschiedliche Fraktionen innerhalb des Netzwerkes an unterschiedlichen Zweigen der Blockchain arbeiten. Dabei handelt es sich allerdings um einen instabilen Zustand, der nur für eine kurze Zeit besteht. Denn da die Miner nur³ für die Erstellung valider Blöcke belohnt werden, haben sie einen starken wirtschaftlichen Anreiz, für den längsten Zweig zu minen und dafür gegebenenfalls den eigenen Zweig aufzugeben. Der Aufbau der Bitcoin-Blockchain wird in Abbildung 2.3 veranschaulicht.

ABBILDUNG 2.3: Aufbau der Bitcoin-Blockchain (Okupski, 2014, S. 35)

Per Definition enthält die längste Blockchain(Main Blocks) den korrekten Zustand des Netzwer- kes sowie alle vorherigen Zustände und Transaktionen. Falls sich die Blockchain aufteilt, gelten nur diejenigen Transaktionen als korrekt, die in dem Zweig enthalten sind, der im Netzwerk die Mehrheit erlangt. Blöcke eines anderen Zweiges (Orphaned Blocks) werden von Nodes als inkorrekt betrachtet, das gilt ebenso für die darin enthaltenen Transaktionen. Somit können meh- rere gleiche Transaktionen während des instabilen Zustandes, in dem noch keine klare Mehrheit innerhalb des Netzwerkes besteht als korrekt gelten, was ein Double-Spending-Problem dar- stellt. Dieses ist zeitlich allerdings sehr begrenzt. Im Moment, in dem das Netzwerk einen der beiden Zweige mehrheitlich akzeptiert, werden alle Transaktionen des kürzeren Zweiges als inkorrekt betrachtet, auch wenn diese von Teilen des Netzwerkes zuvor als korrekt betrachtet wurden. Die Wahrscheinlichkeit einer derartigen Rückabwicklung bereits verifizierter Transak- tionen sinkt mit fortschreitender Tiefe des Blocks, in dem die betroffene Transaktion verarbeitet wurde.

Als Miner werden Netzwerkteilnehmer(Nodes) bezeichnet, die an der Verarbeitung von neuen Transaktionen nach dem PoW-Verfahren teilnehmen.

2.3.2.2 51%-Attacken

Neben der oben beschriebenen zufälligen Aufteilung der Blockchain in verschiedene Zweige ist ein Szenario denkbar, in dem ein unehrlicher Teilnehmer des Netzwerkes nachträglich einen Zweig an die Blockchain anfügt, um bereits verifizierte Transaktionen gezielt zu verändern und so beispielsweise eigene Bitcoins mehrfach ausgeben zu können. Dieses Szenario wird als 51%- Attacke bezeichnet, da der Angreifer über eineMehrheit der Hashing Power des Netzwerkes ver- fügen muss, damit er die korrekte Version der Blockchain mit seinem eigenen Zweig einholen und die Transaktionshistorie der Blockchain so gezielt manipulieren kann. Die Wahrscheinlich- keit, dass ein Angreifer ohneMehrheit der Hashing Power Transaktionen nachträglich verändern kann, sinkt dabei mit fortschreitender Blocktiefe und liegt nach fünf Blöcken bereits bei unter 0,1% (vgl. Nakamoto, 2008).

In den folgenden Abschnitten werden einige der wesentlichen Technologien kurz vorgestellt, die im Bitcoin-Protokoll, sowie in den meisten anderen Blockchains zum Einsatz kommen.

2.3.2.3 Asymmetrische Kryptographie

Bei der asymmetrischen Kryptographie (Auch: Public-Key-Kryptographie) werden Schlüssel- paare genutzt, um Nachrichten zu verschlüsseln und digital zu signieren. Dabei ist ein Teil des Schlüsselpaares, der Public Key, frei verfügbar. Der Private Key muss vom Besitzer geheim gehalten werden. Die Ver- und Entschlüsselung ist in Abbildung 2.4 dargestellt. Der Verschlüsselungsalgorithmus funktioniert dabei wie folgt (Tanenbaum undWetherall, 2011, S. 768):

1. Entschlüsseln(Verschlüsseln(Klartext)) = Klartext
2. Entschlüsseln() kann nicht aus Verschlüsseln() abgeleitet werden
3. Der private Schlüssel kann nicht durch eine Plaintext-Attacke, also Verwendung eines

bekannten Klartextes, erraten werden.

Im Zusammenhang mit der Blockchain-Technologie wird die Public-Key-Kryptographie einge- setzt,um Transaktionen zu verifizieren. Accounts innerhalb der Blockchain bestehen aus Schlüs- selpaaren, wobei der Public Key die Accountnummer bildet und der Private Key den Schlüs- sel zur Bestätigung von Transaktionen. Um eine Transaktion zu verifizieren, verschlüsselt der

ABBILDUNG 2.4: Asymmetrische Kryptographie, schematische Darstellung (Drescher, 2017, S. 97)

Besitzer die Accountnummer des Empfängers zusammen mit den weiteren Informationen zur Transaktion mit seinem privaten Schlüssel.

2.3.2.4 Hashfunktionen

Hashfunktionen weisen einem beliebig langen Wort ein neues Wort mit vorgegebener Länge zu, den sogenannten Hashwert. Im Zusammenhang mit Blockchains werden kryptographische Hashfunktionen eingesetzt, welche die folgenden Merkmale besitzen: - Sie sind deterministisch - Sie erzeugen pseudozufällige Hashwerte, das heißt der Hashwert eines Wortes kann nicht vorbestimmt werden, ohne die Hashfunktion für das Wort auszuführen. - Es sind Einweg- bzw. Trap-Door-Funktionen, das heißt aus dem Hashwert eines Wortes kann nicht das Wort berechnet werden.

- Kollisionsresistenz: Die Wahrscheinlichkeit, das zwei unterschiedliche Worte den glei- chen Hashwert besitzen, ist ausreichend gering.

Innerhalb von Blockchains werden Hashfunktionen in zwei Bereichen eingesetzt. Zum einen dienen Hashfunktionen innerhalb der Blöcke dazu, um Daten gegen Manipulationen zu sichern.

Zum anderen werden sie in Form von Hashpuzzles als PoW-Mechanismus eingesetzt. Dabei wird der Hashwert eines Blockes aus dem Block Header und einer zufällig gewählten Zahl, der Nonce, gebildet. Der gebildete Hashwert muss die vorgegebene Schwierigkeit des Puzzles erfül- len. Diese wird durch eine bestimmte Anzahl an Nullen festgelegt, mit der der Hashwert begin- nen muss. Erfüllt der Hashwert die vorgegebene Schwierigkeit nicht, wird die Berechnung mit einer anderen Nonce erneut durchgeführt, bis das Puzzle gelöst wurde. Hashpuzzle können auf- grund der oben beschriebenen Merkmale der Hashfunktionen nur im Trial-and-Error-Verfahren gelöst werden und eignen sich daher gut als PoW (vgl. Drescher, 2017, S. 141).

2.3.3 Ethereum

2.3.3.1 Grundlagen

Das Bitcoin-Protokoll bietet zwar einen Funktionsumfang, der über einfache Transaktionen zwi- schen zwei Parteien hinausgeht,⁴ allerdings muss jeder Transaktionstyp von den Entwicklern im Bitcoin-Protokoll implementiert werden. Daher bietet Bitcoin nur sehr begrenzte Möglichkei- ten, Smart Contracts zu realisieren. Diese Tatsache führte zur Entwicklung von Ethereum, einer Blockchain, die darauf ausgelegt ist, den Netzwerkteilnehmern vollkommene Freiheit über die Gestaltung der Transaktionen bzw. Verträge innerhalb der Blockchain zu gewähren. Dies ermög- licht die Gestaltung von Smart Contracts und autonomen Programmen (Decentralized Applica- tion, Dapp) in der Blockchain, bis hin zu vollständigen Organisationen (Decentralized Autono- mous Organization, DAO), die mit klassischen Firmen vergleichbar sind, jedoch ausschließlich in der Blockchain existieren und vollkommen autonom agieren. Ethereum wurde erstmals von Buterin (2013) in einem Whitepaper vorgestellt .

Ethereum enthält eine Turing-vollständige Programmiersprache, um den Nutzern die beschrie- bene Gestaltungsfreiheit zuermöglichen. Diese beinhaltetim Gegensatz zu Bitcoin Script Schlei- fen, die dort bewusst ausgeschlossen wurden, damit Endlosschleifen in Transaktionen als mög- licher Angriffspunkt ausgeschlossen sind (vgl. Antonopoulos, 2017, S. 230f.). Um die hier theo- retisch möglichen Endlosschleifen in der Praxis auszuschließen, nutzt Ethereum Gas, welches im Folgenden beschrieben wird. Ethereum bietet gegenüber Bitcoin und Bitcoin-verwandten Blockchains die folgenden grundlegenden Vorteile (vgl. Buterin, 2017):

- Turing-Vollständigkeit: Soll den größtmöglichen Funktionsumfang und Einsatzbereich der Blockchain gewährleisten.
- Value-Awareness: Transaktionen können den Wert der eigenen Auszahlung bestimmen und beispielsweise an einen externen Wechselkurs binden. Bitcoin ermöglicht lediglich die Auszahlung vorher bestimmter fester Beträge.
- Blockchain-Awareness: Transaktionen können auf den Zustand der Blockchain zugreifen wie beispielsweise die Nonce, Block Hash oder Timestamp vorheriger Blöcke. Dies stellt eine deterministische Quelle für quasizufällige Zahlen innerhalb der Blockchain dar.
- State: Transaktionen können interne Zustände besitzen zwischen Erfüllung und Nichter- füllung.Während Transaktionen in Bitcoin entweder ausgeführt werden oder nicht ausge- führt werden, können Transaktionen in Ethereum an Bedingungen geknüpft werden, die dauerhaft in der Blockchain gespeichert werden. Dies stellt eine wesentliche Vorausset- zung für Smart Contracts dar.

Ethereum bietet zwar einen größeren Funktionsumfang als Bitcoin, die genutzte Blockchain- Technologie basiert jedoch auf den gleichen Prinzipien wie Bitcoin, in dem Transaktionen in Blöcke zusammengefasst, gehasht und in Form einer Kette dezentral gespeichert werden. Im Detail bestehen dabei Unterschiede, zum Beispiel bei der gewählten Hashfunktion und dem PoW-Verfahren.⁵ Ethereum enthält eine Kryptowährung namens Ether,⁶ die unter anderem da- zu genutzt wird Transaktionsgebühren im Netzwerk zu bezahlen und Mining-Belohnungen zu generieren.

2.3.3.2 Transaktionen

Die Kommunikation unter den Netzwerkteilnehmern findet in Ethereum durch Transaktionen

statt, welche die folgenden Informationen enthalten: - Den Empfänger - Die Signatur des Senders - Die Summe an Ether, die vom Sender zum Empfänger transferiert werden soll Für technische Details

- Daten (Optional)
- Den Wert STARTGAS, der bestimmt, wie viele Rechenschritte die Ausführung der Trans- aktion höchstens in Anspruch nehmen darf.
- DenWert GASPRICE, derbestimmt, welchen Preis der Sender pro Rechenschritt bezahlt.⁷

Nachrichten können zwischen Teilnehmern des Netzwerkes versendet werden, indem Transak- tionen ohne Ether-Gegenwert gebildet werden (vgl. Buterin, 2017).

2.3.3.3 Smart Contracts

Die zuvor beschriebenen Transaktionen finden in Ethereum zwischen Accounts statt. Diese ent- halten die folgenden Informationen:

- Ein Zähler, der mit jeder Transaktion steigt⁸
- Das Guthaben des Accounts in Ether
- Den Contract Code des Accounts
- Den Datenspeicher des Accounts in Form einer Key/Value Datenbank.

Es bestehen zwei Arten von Accounts: Accounts, die durch mit Private Keys verifizierte Trans- aktionen extern gesteuert werden (Im Folgenden: Externally Owned Accounts, EOAs), sowie Contract Accounts, die durch ihren Contract Code gesteuert werden (Im Folgenden: Contracts).

EOAs sind mit Bitcoin Accounts vergleichbar und enthalten weder Contract Code noch gespei- cherte Daten. Contracts bilden die Grundlage für Smart Contracts, Dapps und DAOs. Nachrich- ten können innerhalb des Netzwerks durch Transaktionen zwischen Accounts versendet werden.

Dabei können auch Contracts untereinander kommunizieren und neue Contracts erstellen. Con- tracts führen ihren Code immer dann aus, wenn sie eine Transaktion als Empfänger erhalten und können dabei auf die Daten in ihrem Speicher zugreifen und diese verändern. Durch die zuvor beschriebene State-Eigenschaft existieren Contracts zeitlich unbegrenzt, solange das Ethereum- Netzwerk besteht oder bis der Contract durch den suicide Befehl aufgelöst wird (vgl. Buterin, 2017).

Contracts erfüllen grundsätzlich eine der folgenden vier Funktionen:

1. Bereitstellung von Daten, beispielsweise des Wechselkurses einer Währung.

2. Die Funktion eines Forwarding Contracts: Daten werden nur dann weitergegeben an einen bestimmtes Ziel, wenn die dafür festgelegten Voraussetzungen erfüllt werden, wie bei- spielsweise die erforderliche Anzahl an Signaturen für eine Multi-Signatur Transaktion.

3. Verwaltung einer bestehenden Beziehung zwischen mehreren EOAs oder Contracts. Dazu zählen Contracts, die Ether treuhänderisch verwalten, bis bestimmte Konditionen erfüllt wurden, aber auch Versicherungen, die Auszahlungen an die Versicherungsnehmer veran- lassen, wenn bestimmte Kriterien erfüllt werden.

4. Bereitstellung von Funktionen für andere Contracts, vergleichbar mit Software Libraries. Contracts die aufgerufen werden, haben die Möglichkeit, Daten zurückzugeben an den Sen- der der Transaktion, die der Sender weiterverwenden kann. Damit sind Contracts mit Funktio- nen vergleichbar und das Senden einer Transaktion mit dem Aufruf einer Funktion in klassi- schen Programmen (vgl. Buterin, 2015). Die Möglichkeit, innerhalb der Blockchain unabhän- gige bzw. autonom agierende Contracts zu erstellen und diese untereinander sowie mit EOAs mittels Transaktionen kommunizieren zu lassen, ermöglicht die Erstellung von Smart Contracts für eine Vielzahl von Anwendungsfällen.

2.3.3.4 Gas

Gas ist ein Gebührensystem in Ethereum und dient dazu, Denial of Service-Attacken zu verhin- dern. Diese können in Form von bösartigen oder versehentlichen Endlosschleifen im Contract- Code auszuführender Accounts auftreten. Außerdem bildet das Gas-System einen Anreiz, mög- lichst sparsam mit Ressourcen im Ethereum Netzwerk umzugehen. Die Kostenstruktur wurde im Ethereum Yellow Paper festgelegt und soll dem Ressourcenverbrauch in Form von Rechen- schritten und Speicher bei der Ausführung des Contracts entsprechen. Die einzelnen Rechen- und Speicheroperationen sind dabei mit festen Preisen in der Einheit Gas versehen und reichen von 0 für STOP und RETURN bis 32.000 Gas für die Erstellung eines neuen Contracts. Für ein- fache Transaktionen zwischen EOAs beträgt die Gebühr 21.000 Gas (vgl. WOOD, 2014). Die tatsächlich in Ether zu bezahlende Gebühr für Transaktionen wird aus der Multiplikation der Gas-Gebühr mit dem Gaspreis errechnet.⁹ Dieser ist vom Sender der Transaktion frei wählbar. Die Gebühren erhält der Miner, der die Transaktion verarbeitet. Da die Miner die Transaktio- nen, die sie verarbeiten, nach der Höhe der gebotenen Gebühr auswählen können, bildet sich ein Gleichgewicht aus Angebot und Nachfrage bei der Verarbeitung von Transaktionen. Je höher der Sender den Gaspreis setzt, desto größer ist die Wahrscheinlichkeit, dass seine Transaktion schnell ausgeführt wird.

Der Gasverbrauch komplexer Programme kann nicht mit absoluter Sicherheit vorhergesagt wer- den, da der Zeitpunkt der Ausführung des Programms und damit der Zustand der Blockchain zum Zeitpunkt der Ausführung von der quasizufälligen Hashfunktion abhängen. Außerdem ist der Quellcode von fremden Contracts in der Ethereum Blockchain oftmals nicht bekannt (vgl.

Luu u. a., 2016), das Verhalten eines fremden Contracts kann somit ebenfalls nicht mit vollstän- diger Sicherheit vorhergesagt werden. Der Wert STARTGAS stellt deshalb eine Obergrenze dar, die die Rechenschritte der aufgerufenen Contracts höchstens verbrauchen dürfen. Wird diese Grenze erreicht, bevor die aufgerufenen Programme beendet sind, werden die entsprechenden Änderungen nicht in die Blockchain übernommen, allerdings wird die Transaktionsgebühr nicht rückerstattet, sondern verbleibt beim Miner. Gas, das nach der korrekten Ausführung der aufge- rufenen Contracts noch nicht verbraucht wurde, wird an den Sender zurück erstattet.

2.3.3.5 Ethereum Virtual Machine (EVM)

Die Berechnungen in der Ethereum Blockchain werden in einer virtuellen Maschine durchge- führt, der Ethereum Virtual Machine (EVM). Die Berechnungen der EVM werden auf allen Nodes parallel ausgeführt. Sie wurde von Wood 2014 in einem Yellow Paper formal beschrie- ben (vgl. WOOD, 2014). Die EVM nutzt eine Assemblersprache, den EVM Code, der in Form von Bytecode im Datenteil der Transaktionen an die EVM übergeben werden kann. Da die EVM parallel ausgeführt wird in einem Netzwerk, dessen wichtigstes Merkmal es ist, dass es nur einen korrekten Zustand innehat, ist es essentiell, dass die EVM alle Berechnungen determi- nistisch durchführt. Um dies zu gewährleisten, werden neue Contracts aus der Accountnummer und der Nonce des Senders der entsprechenden Transaktion gebildet. Außerdem wird durch die zuvor beschriebene Gas-Funktion sichergestellt, dass Endlosschleifen die Blockchain nicht nur nicht überlasten können, sondern auch genau festgelegt ist, wann eine entsprechende Transakti- on abgebrochen wird.

Wenn Contracts die Ausführung anderer Contracts anstoßen, werden diese Sub-Contracts zu- nächst vollständig ausgeführt, bevor die Ausführung des auslösenden Contracts fortgesetzt wird. Die Transaktion an den Sub-Contract enthält dabei ein eigenes Gaslimit, was sich vom Gasli- mit der ursprünglichen Transaktion unterscheiden kann. Kommt es aufgrund der Erreichung des Gaslimits im Sub-Contract zu einem Fehler, wird die Gasprämie der entsprechenden Transak- tion einbehalten, der auslösende Contract kann aber fortgesetzt werden bis das Gaslimit der auslösenden Transaktion erreicht ist (vgl. Buterin, 2015). Derzeit existieren vier Programmier- sprachen für die EVM: Solidity, Serpent, LLL und Mutan, diese sind jeweils an JavaScript, Python, Lisp und Go angelehnt (vgl. Diedrich, 2016, S. 212).

2.3.4 Differenzierung von Blockchains nach Lese- und Schreibrechten

Blockchains können danach unterschieden werden, wie Lese- und Schreibrechte an Teilnehmer des Netzwerkes vergeben werden. Die Leserechte bestimmen, wer auf die Daten in der Block- chain zugreifen kann. Hier wird zwischen öffentlichen (public) und privaten (private) Block- chains unterschieden. Public Blockchains stellen alle Daten allen Nutzern zur Verfügung. Priva- te sind solche Blockchains, die den Zugriff auf die gespeicherten Daten regulieren, indem bei- spielsweise Teile oder die Gesamtheit der Daten nur autorisierten Nutzern zur Verfügung stehen oder innerhalb der Blockchain Nutzergruppen gebildet werden, die jeweils eigene Leserechte für Teile der Blockchain besitzen.

Die Schreibrechte innerhalb einer Blockchain regeln, wer Transaktionen verifizieren und neue Blöcke bilden darf. Permissionless Blockchains ermöglichen allen Netzwerkteilnehmern die Ve- rifikation von Transaktionen und Erstellung neuer Blöcke, während permissioned Blockchains diese regulieren. Diese können auch noch weiter differenzieren zwischen der Berechtigung, Transaktionen zu verifizieren und Blöcke zu bilden und diese ans Netzwerk zu übermitteln. Die Autorisierung der Teilnehmer erfolgt bei permissioned Blockchains durch eine oder mehrere vertrauenswürdige Parteien (vgl. BitFury Group, 2015, S. 11).

Dadurch, dass vertrauenswürdige Parteien notwendigerweise erforderlich sind, widersprechen permissioned Blockchains dem Grundgedanken, der bei Bitcoin verfolgt wurde und vorsah, eine Plattform zu schaffen, in der keinerlei Vertrauen zwischen den Teilnehmern notwendig ist (vgl.

Nakamoto, 2008). Bei Bitcoin und Ethereum handelt es sich um public permissionless Block- chains. Diesen gegenüber stehen private permissioned Blockchains, die im Folgenden anhand der Blockchain-Plattform Hyperledger beschrieben werden.

2.3.5 Hyperledger

Hyperledger ist eine Plattform für Blockchain-Technologie, die das Ziel hat, Industrie unabhän- gige Blockchain-Lösungen für B2B-Anwendungen bereitzustellen. Das Projekt wird von der Linux-Stiftung geleitet und die grundlegende Technologie ist Open-Source. Allerdings bietet neben anderen IBM kommerzielle Dienstleistungen rund um Hyperledger an. Im Vergleich zu Ethereum und Bitcoin bestehen einige grundlegende Unterschiede:

Hyperledger ist modular aufgebaut. Es bestehen verschiedene Layer und Frameworks, die auf die Anforderungen des jeweiligen Einsatzbereichs angepasst werden können. Für die vorliegen- de Fragestellung interessant sind dabei vor allem die Frameworks Hyperledger Fabric und Hy- perledger Burrow, die sich unter anderem im eingesetzten Konsensverfahren und der zugrunde- liegenden DLT unterscheiden. Während Burrow auf einer (u.a. durch Einführung von Zugriffs- rechten) abgewandelten Ethereum Virtual Machine basiert und das Proof-of-Stake-Verfahren Tendermint¹⁰ nutzt, basiert Fabric auf einer eigenen DLT und stellt als Konsensmechanismen Apache Kafka¹¹ und den BFT-Algorithmus¹² zur Verfügung.

Die vorliegende Arbeit wird sich im Folgenden auf Hyperledger Fabric konzentrieren, da sich dieses Framework stärker von Ethereum unterscheidet und derzeit das fortschrittlichste Hyper- ledger Framework mit Fokus auf Smart Contracts darstellt. Es gibt keine zentrale Blockchain, in der alle Transaktionen abgewickelt und Daten gespeichert werden, stattdessen verfügen einzelne oder mehrere Unternehmen jeweils über eigene Blockchains, die sich im Aufbau unterscheiden können.

Bei Hyperledger Fabric handelt es sich um eine private permissioned Blockchain. Diese bie- tet gegenüber public permissionless Blockchains wie Ethereum den Vorteil, dass Daten gegen den Zugriff von Dritten geschützt werden können und auch innerhalb der Blockchain, in un- ternehmensübergreifenden Blockchains nur diejenigen Daten geteilt werden müssen, die dafür vorgesehen sind.

Die Vergabe von Schreibrechten erfolgt durch vertrauenswürdige Parteien, was die Verwendung von effizienteren Konsensmechanismen als dem PoW-Verfahren ermöglicht. Hyperledger nutzt die Programmiersprache Go; Smart Contracts werden in Hyperledger als Chaincode bezeichnet.

2.4 Orakel

Blockchains bilden ein geschlossenes System, in dem nur auf Informationen zugegriffen werden kann, die entweder bereits in der Blockchain gespeichert sind oder die als Teil von Transaktio- nen bereitgestellt werden. Abrufe externer Daten durch Contracts innerhalb einer Blockchain könnten dazu führen, dass gleiche Anfragen als Antwort unterschiedliche Daten erhalten. Dieses würde zu nicht-deterministischem Verhalten der Blockchain führen. Eine Vielzahl von Anwen- dungsfällen für Smart Contracts, darunter auch Versicherungen, setzen allerdings Daten voraus, die zum Zeitpunkt der Erstellung eines Contracts noch nicht bekannt sind. Daher können diese Daten nicht vom Sender bei Erstellung des Contracts bereitgestellt werden, sondern müssen zu einem späteren Zeitpunkt in die Blockchain integriert werden. Die Bereitstellung dieser Daten kann durch externe Parteien erfolgen, die als Orakel bezeichnet werden (vgl. Diedrich, 2016, S. 187f.).

Orakel bestehen aus zwei Teilen. Der eine Teil innerhalb der Blockchain verarbeitet Anfra- gen und stellt Daten als Teil von Contracts bereit. Der andere Teil außerhalb der Blockchain nimmt Anfragen aus der Blockchain an, beschafft die geforderten Daten und integriert sie mit- tels Transaktionen in die Blockchain. Der Ablauf des Anfrage- und Bereitstellungsprozesses wird in Abbildung 2.5 dargestellt. Für die Bereitstellung von externen Daten erhalten Orakel eine Entschädigung.

Orakel bilden die Schnittstelle zwischen Daten innerhalb und außerhalb der Blockchain und stellen dabei für das vertrauensfreie Modell eine Herausforderung dar, da sowohl auf die Kor- rektheit der Daten als auch auf die korrekte Ausführung der Anfragen durch das Orakel ver- traut werden muss. Der erste Punkt wird dadurch gelöst, dass die Korrektheit von Daten durch ABBILDUNG 2.5: Anfrage und Bereitstellung externer Daten durch Orakel sichere Protokolle wie HTTPS im Internet grundsätzlich gewährleistet werden kann. Durch vorhandene Erfahrungswerte sind Nutzer außerdem in der Lage, vertrauenswürdige von nicht- vertrauenswürdigen Quellen von Daten zu unterscheiden (vgl. Zhang u. a., 2016, S. 1).

Der zweite Punkt gestaltet sich schwieriger, da es sich bei den derzeit bestehenden Orakeln um kleine und junge Unternehmen handelt, die noch über keine aussagekräftige Reputation verfügen.¹³ Oraclize.it stellt dabei das derzeit meistverwendete Orakel in Ethereum dar (vgl. Bartoletti und Pompianu, 2017, S. 10). Das Vertrauensproblem löst Oraclize durch einen als „provable honesty“ bezeichneten Ansatz, bei dem neben den angeforderten Daten ein Beweis mitgeliefert wird, dass die gelieferten Daten identisch sind mit denen, die zum beschriebenen Zeitpunkt vom angegebenen Server abgerufen wurden. Damit besteht zwar keine Garantie, dass Oraclize die angeforderten Daten liefert. Sofern es Daten liefert, kann jedoch geprüft werden, ob diese von Oraclize manipuliert wurden.

Einen anderen Ansatz verfolgt das Orakel Town Crier, das Intels SGX-Funktion nutzt um zu gewährleisten, dass die von einem externen Server abgerufenen Daten weder von Dritten noch von Town Crier selbst manipuliert werden können. Damit muss der Nutzer zwar nicht dem Town Crier Orakel vertrauen, stattdessen aber der Sicherheit von Intels SGX-Feature.

Auch wenn Oraclize und Town Crier mit den gewählten Ansätzen ausreichend vertrauenswür- dig sind, um in der Praxis verwendet zu werden, können sie nicht das grundsätzliche Problem lösen, Daten als zentrale Anbieter zu liefern. Dies widerspricht dem dezentralen, vertrauensfrei- en Grundsatz der Blockchain, dessen Vorteil unter anderem die Unabhängigkeit von einzelnen Netzwerkteilnehmern ist. So ist die derzeitige Lösung der Vertrauensfrage durch provable hones- ty einWerkzeug, dass das Vertrauen in den Anbieter bestärkt, jedoch nicht die Ausfallsicherheit einer dezentralen Lösung bieten kann.

Eine mögliche Alternative bieten dezentrale Orakel, die allerdings deutlich komplexer sind. So entwickelt das Startup Delphi Systems eine Plattform für dezentrale Orakel. Diese besteht zum einen aus dem Framework Pythia, welches kein konkretes Orakel sondern eine Plattform dar- stellt, auf dem der Anbieter, aber auch Dritte, Orakel-Dienstleistungen anbieten können. Von dem so geförderten Wettbewerb sollen die Nutzer durch geringere Gebühren profitieren. Pythia ermöglicht dabei eine freie, beliebig komplexe Gestaltung der Konsensmechanismen dezentra- ler Orakel. Diese bestehen in ihrer Grundform aus Multisignatur-Contracts, die von mehreren Parteien verifiziert werden müssen, um Output zu generieren. Damit dieses System funktionie- ren kann, muss gewährleistet werden, dass die Teilnehmer der Plattform korrekt agieren. Dies wird von Delphi über ein integriertes Token-System erreicht, das korrektes Verhalten belohnt und dieses durch eine positive Reputation bekannt macht, während negatives Verhalten bestraft wird. Delphi befindet sich derzeit noch in Entwicklung (vgl. Delphi Systems, 2017, S. 3).

EineWeiterentwicklung dezentraler Orakel stellen PredictionMarkets dar. Diese bilden eine de- zentrale Plattform, um auf beliebige Ereignisse in der Zukunft zu wetten. Die Netzwerkteilneh- mer haben dabei einen finanziellen Anreiz, auf das aus ihrer Sicht wahrscheinlichere Ereignis zu setzen: Tritt das gewählte Ereignis ein, erhalten sie eine Belohnung, tritt es nicht ein, verlieren sie ihren Einsatz. Das Verhalten der Marktteilnehmer kann als Prognose über die Eintrittswahr- scheinlichkeit der betrachteten Ereignisse genutzt werden; diese Prognosen können herkömmli- che Methoden übertreffen. Neben Delphi, dessen Produkt auch einen Prediction Market enthält, entwickeln die Unternehmen Augur und Gnosis ebenfalls entsprechende Plattformen.¹⁴

2.5 Bestehende Produkte Smart Contract-basierte Produkte

Nachdem in den vorherigen Abschnitten die Grundlagen von Smart Contracts und der dahinter stehenden Blockchain Technologie erläutert wurden, werden in diesem Teil der Arbeit Produkte vorgestellt, die Versicherungen auf Grundlage von Smart Contracts anbieten.

2.5.1 Etherisc

Das Startup Etherisc hat eine parametrische Versicherung gegen Flugverspätungen in Form einer dezentralen App auf Basis der Ethereum-Blockchain entwickelt. Dieses Produkt wurde erstmals 2016 auf der Devcon2 in Shanghai als Konzept vorgestellt und zwischenzeitlich auch öffentlich angeboten, ist aktuell jedoch nicht verfügbar.¹⁶ Bei der Flight Delay Dapp handelt es sich um ein dezentralisiertes Versicherungsprodukt mit Rückversicherungsplattform in Ethereum. Bei- des basiert auf einem Token Modell, welches Investoren ermöglicht, Long-Tail-Risiken eines dezentralen Versicherungsportfolios zu übernehmen und dafür einen Teil der Prämien zu erhal- ten. Zusammen mit einem Front-End für Versicherungsnehmer handelt es sich damit um eine komplette und funktionierende Versicherung auf Basis der Blockchain Ethereum, die kein Ver- trauen zwischen den handelnden Parteien erfordert. Das Ziel der Entwickler ist dabei, durch die Monetarisierung von Versicherungsrisiken durch Tokens die Versicherungspools skalierbar zu machen. Die Kunden sollen hiervon durch flexiblere und transparentere Produkte profitie- ren, die letztendlich zu verringerten Kostensätzen führen. Außerdem soll durch die Tokens die Beteiligung an Rückversicherungspools als Investitionsmöglichkeit der breiten Öffentlichkeit zugänglich gemacht werden.

Die Versicherung gegen Flugverspätungen wurde als erstes Produkt gewählt, da die Einzel- risiken hier größtenteils unabhängig voneinander sind und das individuelle Risiko gemessen am Gesamtpool relativ gering ausfällt. Zudem ermöglicht das Produkt eine voll automatisierte Schadenregulierung. Als wesentliche Bereiche, in denen die Blockchain gegenüber klassischen Produkten Vorteile hat, wurden die folgenden Felder identifiziert:

- Effizienz durch Automatisierung
- Erschließung neuer Märkte durch niedrigere Kosten, z.B. Ernteausfall für Farmer in der dritten Welt
- Freier Zugang zu den Versicherungspools als Investitionsobjekt
- Volle Transparenz gegenüber den Versicherten

In der ursprünglichen Form bestand Etherisc aus den Kernkomponenten Risikopool, Rückver- sicherungspool, Claim Verification Process, Risk Management System und Token Marketplace.

Es sollte zunächst die gesamte Prozesskette für die Flight Delay Dapp realisiert werden, um das Angebot im Anschluss auf weitere Produkte auszudehnen (vgl. Karpischek u. a., 2016, S. 6).

Seit Veröffentlichung des ursprünglichen Konzepts wurden Änderungen am Etherisc Projekt vorgenommen. Aufgrund regulatorischer Probleme wurde der Reinsurance Pool auf unbestimm- te Zeit verschoben und anstelle der Veröffentlichung eines einzelnen Produktes hat Etherisc nun das Ziel, eine vollkommen offene, umfassende Versicherungsplattform zu schaffen. Diese soll ebenfalls vollständig als Dapp realisiert werden. Neben der bereits beschriebenen Flight Delay Dapp sollen auf dieser Plattform auch weitere Produkte angeboten werden. Die Plattform wird dabei für Dritte offen gestaltet, sodass diese eigene Produkte und Services anbieten können, ent- weder in Form von kompletten Produkten oder als Teilprozess eines bestehenden Produktes. Das Ziel ist dabei die Disintermediation von Risikoträgern und Versicherten, was einer Disruption der Versicherungsbranche gleichkommt.¹⁷

Die wesentlichen Merkmale der Etherisc-Versicherungsplattform werden im Folgenden noch etwas eingehender beschrieben, da sie auch für die Fragestellung der vorliegenden Arbeit rele- vant sind. Dies sind zum einen der grundsätzliche Aufbau der Plattform und zum anderen das eingesetzte Token-System.

[...]

---

¹ Vgl. Ripple Blockchain: https://ripple.com/

² Mit Stand 24.03.2018 sind dies die folgenden Versionsnummern:
Hyperledger Fabric: Version 1.1.0
Ethereum: Byzantinum Update
Solidity: Version 0.4.21

¹ Vgl. auch (Szabo, 1997), (Dai, 1998)

² Das Byzantine Generals Problem (BGP) veranschaulicht das Problem, in einem unsicheren Netzwerk mit nicht vertrauenswürdigen Teilnehmen kommunizieren und einen Konsens über den korrekten Zustand desSystems erzielen zu müssen. Die Generäle des Beispiels müssen einen Angriff koordinieren, wissen aber weder, ob ihre Nachrichten ankommen, noch können sie ausschließen, dass sich unter den Generälen Verräter befinden, die falsche Informationen verbreiten. Das Problem wurde im Zusammenhang mit Computernetzwerken unter anderem von Lamport u. a. (1982) beschrieben. Algorithmen zur Lösung des BGP sind fortlaufend Gegenstand der Forschung.

³ Als Miner werden Netzwerkteilnehmer(Nodes) bezeichnet, die an der Verarbeitung von neuen Transaktionen nach dem PoW-Verfahren teilnehmen

⁴ Bitcoin unterstützt beispielsweise Multi-Signatur-Transaktionen, bei der mehrere Parteien einer Transaktion zu- stimmen müssen.

⁵ vgl. auch (Okupski, 2014) für Bitcoin, (WOOD, 2014) für Ethereum

⁶ Ein Ether wird unterteilt in 1.000 Finney, 1.000.000 Szabo oder 10 Wei

⁷ Gas-Werte werden im entsprechenden Abschnitt erläutert.

⁸ Dabei handelt es sich um eine Sicherheitsmaßnahme, die gewährleisten soll, dass jede Transaktion nur einmal gültig ist, um Replay Attacks zu verhindern, bei denen dieselbe Transaktion mehrfach ausgeführt wird (vgl. Buterin, 2013).

⁹ Zur Berechnung von Transaktionsgebühren siehe https://ethgasstation.info/. Bei einem aktuellen durchschnitt- lichen Gaspreis von 4 GWei beträgt die durchschnittliche Gebühr einer einfachen EOA-Transaktion beispielsweise 8*10 Ether oder circa $0,085.

¹⁰ Proof-of-Stake nutzt im Gegensatz zu PoW keine externen Ressourcen zur Validierung (Rechenleistung, Ener- gie), sondern setzt voraus, dass die validierenden Nodes virtuelle Währung in dafür vorgesehenen Transaktionen als Pfand deponieren. Dafür erhalten sie ein Stimmrecht zur Validierung proportional zum deponierten Geldbetrag. Verletzten sie die Regeln und ermöglichen so beispielsweise Double-Spending, werden die verursachenden Nodes bestraft, in dem der als Pfand deponierte Betrag eingezogen wird. Für das korrekte Ausüben des Stimmrechtes be- ziehungsweise die Verifizierung von Blöcken erhalten die Nodes eine Belohnung (vgl. Kwon, 2014).

¹¹ Weitere Informationen siehe https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ Apache Kafka ist ein Streaming Service, der parallel auf mehreren Servern ausgeführt wird. Er ist resistent gegen den Ausfall einzelner Server, nicht jedoch BGP-tolerant (vgl. Apache Software Foundation, 2017).

¹² Der BFT-Algorithmus (BFT = Byzantine Fault Tolerant) ist ein Replikationsalgorithmus, der BGP-tolerant ist, solang weniger als 1/3 der betroffenen Server fehlerhaft arbeiten (vgl. Castro und Liskov, 2002, S. 1).

¹³ Siehe beispielsweise http://www.oraclize.it/, https://www.realitykeys.com/

¹⁴Siehe https://delphi.systems/, http://www.augur.net/, https://gnosis.pm/

¹⁵ https://fdd.etherisc.com/

¹⁶ Mussenbrock (2017a) verwendet ein Versicherungsmodell, welches anfallende Entschädigungen in zwei Kate- gorien unterteilt:
1.) Erwarteten Schäden, die aus den laufenden Prämieneinnahmen bezahlt werden und mit hoherWahrscheinlichkeit nicht überschritten werden.
2.) Long-Tail-Risiken: Schadenzahlungen, die nur mit geringer Wahrscheinlichkeit anfallen, dafür aber die Rückla- gen für erwartete Schäden übersteigen.
Rücklagen fürMussenbrocks Long-Tail-Risiken sind vergleichbar mit Excess of Loss-Rückversicherungen(vgl. Mu- nich Re, 2010, S. 41).

¹⁷ Der Aufbau der Etherisc-Plattform ist in Abbildung 2.6 dargestellt. Die Plattform besteht aus den folgenden Komponenten:
Disintermediation: Beschreibt die Eliminierung von Mittelsmännern in einer Wertschöpfungskette, in diesem Fall der Vermittler und Versicherungsgesellschaften.
Disruption: Innovationen sind disruptiv, wenn sie die folgenden Kriterien erfüllen (vgl. Christensen u. a., 2015, S. 47): 1.) Sie bieten eine schlechtere Leistung als die etablierten Produkte der Wettbewerber gemessen an den geltenden Standards innerhalb der Branche 2.) Durch einen günstigeren Preis oder die bessere Erfüllung zuvor nicht beachteter Kundenwünsche bieten sie einen
Mehrwert für preisbewusste Kunden oder erschließen neue Käufergruppen.