Blockchain und maschinelles Lernen: Wie das maschinelle Lernen und die Distributed-Ledger-Technologie voneinander profitieren [1. Aufl. 2019] 978-3-662-60407-6, 978-3-662-60408-3

Table of contents :
Front Matter ....Pages I-VII
Einleitung (Sigurd Schacht, Carsten Lanquillon)....Pages 1-2
Die Blockchain-Technologie (Sigurd Schacht)....Pages 3-87
Grundzüge des maschinellen Lernens (Carsten Lanquillon)....Pages 89-142
Blockchain und maschinelles Lernen – Ein Literaturüberblick (Jerome Tagliaferri)....Pages 143-166
Der Analytics-Marktplatz (Carsten Lanquillon, Sigurd Schacht)....Pages 167-193
DLT im Energiesektor – Wie blockchainbasierte Werkzeuge und maschinelles Lernen ein dekarbonisiertes Energiesystem möglich machen (Thomas Brenner)....Pages 195-216
Back Matter ....Pages 217-220

Citation preview

Sigurd Schacht Carsten Lanquillon Hrsg.

Blockchain und maschinelles Lernen Wie das maschinelle Lernen und die Distributed-Ledger-Technologie voneinander profitieren

Blockchain und maschinelles Lernen

Sigurd Schacht · Carsten Lanquillon (Hrsg.)

Blockchain und maschinelles Lernen Wie das maschinelle Lernen und die Distributed-Ledger-Technologie voneinander profitieren

Hrsg. Sigurd Schacht Hochschule Heilbronn Heilbronn, Deutschland

Carsten Lanquillon Hochschule Heilbronn Heilbronn, Deutschland

ISBN 978-3-662-60407-6 ISBN 978-3-662-60408-3  (eBook) https://doi.org/10.1007/978-3-662-60408-3 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer-Verlag GmbH, DE und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Heidelberger Platz 3, 14197 Berlin, Germany

Inhaltsverzeichnis

1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Sigurd Schacht und Carsten Lanquillon Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Die Blockchain-Technologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Sigurd Schacht 2.1 Bedeutung und Verbreitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Blockchain und Distributed-Ledger-Technologie: Eine kurze Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Distributed-Ledger-Technologie im Detail . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Ebene 1 „Principles“: Komponenten der Distributed Ledger Technologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2 Ebene 2 „Concept – Base Framework“. . . . . . . . . . . . . . . . . . . . . . 37 2.3.3 Ebene 3 „Concept – Application Framework“. . . . . . . . . . . . . . . . . 69 2.3.4 Ebene 4 „Implementation Frameworks“. . . . . . . . . . . . . . . . . . . . . 75 2.4 Ausblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3 Grundzüge des maschinellen Lernens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Carsten Lanquillon 3.1 Definition und Entwicklung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.1.1 Informatik, KI und maschinelles Lernen. . . . . . . . . . . . . . . . . . . . . 90 3.1.2 Machine-Learning-Definitionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.1.3 Maschinelles Lernen und verwandte Disziplinen . . . . . . . . . . . . . . 93 3.2 Lernformen: Wie wird gelernt?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.2.1 Überwachtes Lernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 3.2.2 Unüberwachtes Lernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.2.3 Halbüberwachtes Lernen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.2.4 Bestärkendes Lernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 3.2.5 Weitere Kategorisierungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

V

VI

Inhaltsverzeichnis

3.3 Aufgabentypen: Was wird gelernt?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.3.1 Modellanwendung: Wie wird ein Modell verwendet?. . . . . . . . . . . 100 3.3.2 Eingabe: Die Daten als Matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.3.3 Gängige Aufgabentypen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.4 Grundlegende Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.4.1 CRISP-DM: Ein Prozessmodell für Analyseprojekte . . . . . . . . . . . 112 3.4.2 Automatisierung und Operationalisierung. . . . . . . . . . . . . . . . . . . . 117 3.5 Lernverfahren: Ein kurzer Überblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 3.5.1 Grundbausteine maschineller Lernverfahren. . . . . . . . . . . . . . . . . . 123 3.5.2 Verfahrensklassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 3.5.3 Ausgewählte Lernverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 3.6 Zentralisiertes und verteiltes Lernen: Wo wird gelernt? . . . . . . . . . . . . . . . 131 3.6.1 Parallelisierung von Berechnungen. . . . . . . . . . . . . . . . . . . . . . . . . 131 3.6.2 Klassisches verteiltes Lernen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 3.6.3 Föderiertes Lernen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 3.7 Zusammenfassung und Ausblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 3.7.1 Einfluss der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 3.7.2 Einfluss der Lernverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 4 Blockchain und maschinelles Lernen – Ein Literaturüberblick . . . . . . . . . . 143 Jerome Tagliaferri 4.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 4.2 Maschinelles Lernen zur Unterstützung der Blockchain. . . . . . . . . . . . . . . 144 4.3 Blockchain zur Unterstützung des maschinellen Lernens. . . . . . . . . . . . . . 146 4.3.1 Datensicherheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 4.3.2 Smart Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 4.3.3 Incentivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 4.3.4 Datenplattform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 4.3.5 Anwendungsformen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 4.4 Anwendungsfälle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 4.4.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 4.4.2 Anwendung 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 4.4.3 Anwendung 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 4.4.4 Anwendung 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 4.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5 Der Analytics-Marktplatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Carsten Lanquillon und Sigurd Schacht 5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.2 Zielsetzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Inhaltsverzeichnis

VII

5.3 Ordnungsrahmen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 5.3.1 Ressourcen und Rollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.4 Herausforderungen und Lösungsansätze. . . . . . . . . . . . . . . . . . . . . . . . . . . 177 5.4.1 Vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 5.4.2 Datenschutz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 5.4.3 Anreizsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 5.4.4 Automatisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 5.5 Aktuelle Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 5.5.1 Kurtulmus und Daniel: Trustless Machine Learning Contracts. . . . 184 5.5.2 Özyilmaz et al.: IDMoB: IoT Data Marketplace on Blockchain. . . 187 5.5.3 Fitchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 5.6 Zusammenfassung und Ausblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge und maschinelles Lernen ein dekarbonisiertes Energiesystem möglich machen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Thomas Brenner 6.1 Dezentrales Energiesystem – verteiltes IT-Netzwerk . . . . . . . . . . . . . . . . . 195 6.1.1 Herausforderungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 6.1.2 DLT und neutrale lokale Märkte als Lösungsansatz . . . . . . . . . . . . 198 6.2 Von der Anlage zum Kunden – Das Allgäu Microgrid . . . . . . . . . . . . . . . . 200 6.2.1 Status Quo und Ziele. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 6.2.2 Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 6.2.3 Ein Blick hinter die Kulissen – das Blockchain-Backend und exemplarische Smart Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 6.2.4 Die Kundenschnittstelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 6.2.5 Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 6.3 Machine Learning für ein agentenbasiertes Energiemanagement. . . . . . . . 210 6.3.1 Data Mining zur Disaggregaton von Energieverbrauchsdaten. . . . . 211 6.3.2 Deep Neural Networks und SMPC zur Prognoseoptimierung und Prozesssteuerung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 6.3.3 Predictive Maintenance und Pay Per Use . . . . . . . . . . . . . . . . . . . . 213 6.4 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Stichwortverzeichnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

1

Einleitung Sigurd Schacht und Carsten Lanquillon

Sowohl die Blockchain als auch die künstliche Intelligenz, die auch das maschinelle Lernen umfasst, zählen zu den disruptiven Technologien, die unsere Arbeitswelt und insbesondere die Zusammenarbeit und Interaktion von Unternehmen und Arbeitnehmern fundamental ändern werden [1]. Was aber haben Blockchain und maschinelles Lernen miteinander zu tun? Nach dem Abflachen des „Krypto-Hype“ von 2017, bei dem die unterschiedlichen Kryptowährungen, allen voran Bitcoin, großes Aufsehen erregt hatten, rückte die Technologie dahinter mehr und mehr in den Vordergrund. Dabei gehört die Blockchain zu den jüngeren Technologien. Aufgrund ihres Charakters als Infrastruktur-Technologie kann sie nicht schnell eingeführt werden bzw. führt sie auch nicht zu schnellen Erfolgen. Dementsprechend gibt auch Gartner in seinem Hype-Cycle an, dass die Technologie erst zwischen 2024 und 2029 den Bereich der Produktivität erreichen wird. Gartner behandelt in seinem Beitrag „The Reality of Blockchain“ auch die „programmable economy“, also eine „programmierbare Wirtschaft“, die ein intelligentes Wirtschaftssystem, das die Produktion und den Konsum von Waren und Dienstleistungen unterstützt, verwaltet und verschiedene Szenarien des Werteaustausches ermöglichen soll [3]. In diesem Kontext spielt die Blockchain-Technologie eine essenzielle Rolle. Es geht um die Optimierung, Standardisierung und Automatisierung von Prozessen und Abläufen nicht nur im Unternehmen selbst, sondern über die Unternehmensgrenzen hinweg. Bevorzugt soll ein hoher Grad an Automatisierung erreicht werden, der nicht nur die operationalen Abläufe betrifft, sondern auch die monetären Ströme zwischen den beteiligten Parteien abbildet. Die S. Schacht (B) · C. Lanquillon Hochschule Heilbronn, Heilbronn, Deutschland E-Mail: [email protected] C. Lanquillon E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 S. Schacht und C. Lanquillon (Hrsg.), Blockchain und maschinelles Lernen, https://doi.org/10.1007/978-3-662-60408-3_1

1

2

S. Schacht und C. Lanquillon

Entwicklung einer „programmable economy“ benötigt aus Sicht von Gartner eine passende Infrastruktur, die durch die Blockchain-Technologie bereitgestellt wird. Außerdem ist die Möglichkeit der Automatisierung durch Smart Contracts notwendig, der Einsatz dezentraler Applikationen und natürlich die Partizipation der Kunden. Eine blockchainbasierte Infrastruktur alleine wird jedoch nicht genügen, um den eingebetteten Programmen auch die Möglichkeit zu bieten, nicht nur nach vordefinierten Regeln zu entscheiden, sondern Entscheidungen auf intelligente Art und Weise zu treffen, also insbesondere kontextabhängig und adaptiv die Zusammenhänge zwischen relevanten Einflussfaktoren berücksichtigend. Dafür wiederum ist der Einsatz künstlicher Intelligenz erforderlich. Insbesondere das maschinelle Lernen, durch das Programme ohne explizites Programmieren datenbasiert erstellt werden können, ist der entscheidende Baustein für einen hohen Grad der Automatisierung in der programmierbaren Wirtschaft, denn es kann das Automatisieren automatisieren [2]. Bereits diese Überlegung lässt erahnen, dass die beiden Technologien jeweils Eigenschaften und Potenziale besitzen, die sich sehr gut ergänzen können. Wie aber kann dieses Zusammenspiel aussehen und gestaltet werden? So vielversprechend und naheliegend eine Kombination der beiden Technologien auch ist, gibt es auf dem Weg zur ihrer Gestaltung und Umsetzung noch viele Fragen und Herausforderungen zu klären. Dieses Buch soll einen Einblick in die gegenwärtige Entwicklung der Kombination aus maschinellem Lernen und der Blockchain-Technologie bieten. Dazu wird im folgenden Kapitel zunächst eine Einführung in die Blockchain und die dahinter stehende DistributedLedger-Technologie gegeben. In Kap. 3 werden sodann die wichtigsten Aspekte des maschinellen Lernens mit Blick auf die folgende Kombination mit der Blockchain kompakt zusammengefasst. Kap. 4 gibt einen Überblick über die aktuelle Forschung in diesem Bereich. Dabei entpuppt sich insbesondere der Aufbau von Marktplätzen zum nahtlosen und automatisierbaren Austausch von Ressourcen als vielversprechende Anwendungsform. Ein branchenneutraler Analytics-Marktplatz sowie ein Use-Case aus dem Energiesektor werden schließlich als aktuelle Beispiele der Kombination aus maschinellem Lernen und der Blockchain-Technologie in den Kap. 5 und 6 detailliert erläutert.

Literatur 1. Dinh, T.N., Thai, M.T.: AI and blockchain: a disruptive integration. Computer 51(9), 48–53 (2018). https://doi.org/10.1109/MC.2018.3620971 2. Domingos, P.: The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World. Basic Books Inc., New York (2015) 3. Heather Pemberton Levy: The Reality of Blockchain – Smarter With Gartner. https://www.gartner. com/smarterwithgartner/the-reality-of-blockchain/ (2018). Zugegriffen: 20. Juni 2019

2

Die Blockchain-Technologie Sigurd Schacht

Zusammenfassung

In diesem Kapitel wird ein Überblick über das Ecosystem Distributed-LedgerTechnologie dargestellt. Ziel ist es, ein Verständnis über die neue Technologie zu vermitteln und einen möglichst breiten Überblick über die unterschiedlichsten Technologien und Verfahren zu liefern. Dabei wird als Struktur ein Ordnungsrahmen, gegliedert nach vier Ebenen der Distributed-Ledger-Technologie, herangezogen. Auf der ersten Ebene werden die wichtigsten Prinzipen der Distributed-Ledger-Technologie dargestellt. Darauf aufbauend werden in Ebene zwei Blockchain, Tangle und Hashgraph als Ausprägungen der DLT erläutert. In Ebene drei werden die wichtigsten Applikationen, Smart Contracts und dezentrale autonome Organisationen dargestellt. Als Abschluss wird jeweils eine DLT-Implementierung für öffentliche und private DLTs erläutert.

2.1

Bedeutung und Verbreitung

Die Blockchain-Technologie steht noch am Anfang ihrer Entwicklung, weshalb momentan in Unternehmen überwiegend Pilotprojekte gestartet werden. So entwickelt Facebook die eigene Kryptowährung „Libra“, die den Zahlungsverkehr zwischen Individuen länderübergreifend schnell und einfach ermöglichen soll. Aber auch andere Unternehmen werden zukünftig in diese Technologie investieren. Nach einer Studie der International Data Corporation sollen die Ausgaben für Blockchain-Lösungen von 0,95 US$ im Jahr 2017 auf bis zu 11,7 Mrd. US$ im Jahr 2022 ansteigen. Diese Investitionssumme verteilt sich vor allem auf die USA, West-Europa und China [44]. S. Schacht (B) Hochschule Heilbronn, Heilbronn, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 S. Schacht und C. Lanquillon (Hrsg.), Blockchain und maschinelles Lernen, https://doi.org/10.1007/978-3-662-60408-3_2

3

4

S. Schacht

Auch Deloitte bietet mit einer Umfrage über den Status aktueller Blockchain-Projekte vom April 2018 einen interessanten Einblick. Es wird deutlich, dass sich über alle Branchen hinweg mehr als 31 % der Befragten in der Phase des Experimentierens (Proof-of-Concept) befinden und dass einige wenige Projekte schon produktiv genutzt werden, besonders im Bereich Konsumgüter & Maschinenbau. Weiterhin zeigt die Umfrage, dass ein Großteil der Befragten eine Produktivsetzung schon innerhalb des nächsten Jahres sieht (Abb. 2.1). Ganz vorne stehen hier die Länder China und Mexiko, während überraschenderweise die USA, die erwartungsgemäß auf Grund der technologischen Dominanz im Silicon Valley normalerweise eine führende Rolle einnimmt – zumindest laut dieser Studie – in Bezug auf produktive Blockchain-Projekte im Vergleich zu anderen Nationen weit abgeschlagen sind (Abb. 2.2).

Abb. 2.1 Weltweite Blockchain-Einführungsphasen in Unternehmen [77]

Abb. 2.2 Geplante Produktivsetzungen von Blockchain-Projekten [77]

2 Die Blockchain-Technologie

5

Es ist anzunehmen, dass die Blockchain-Technologie in den nächsten ein bis zwei Jahren in immer mehr produktiven Projekten, besonders in kleinen, speziellen Anwendungsbereichen, wie das Nachvollziehen von Lieferflüssen, eingesetzt werden wird, eine große Verbreitung aber erst in fünf bis zehn Jahren zu erwarten ist.

2.2

Blockchain und Distributed-Ledger-Technologie: Eine kurze Einführung

Distributed-Ledger-Technologie (DLT) bedeutet, dass Transaktionen nacheinander in einem auf viele unabhängige Rechner verteilten Hauptbuch (Ledger) gespeichert werden [58]. Die in Form eines dezentralen Netzwerks organisierten Rechner werden dabei als Knoten oder Nodes bezeichnet. Bei der Blockchain, dem bekanntesten DLT-Verfahren, werden Transaktionen in Form von (Informations-) Blöcken zusammengefasst und mittels kryptografischer Verfahren miteinander verkettet [72]. Das Besondere an der Blockchain ist die transparente, nachvollziehbare und verifizierte Übertragung von Transaktionen sowohl in öffentlichen wie auch geschlossenen Transaktionsketten zwischen unbekannten Marktteilnehmern ohne eine zentrale Instanz. Fünf wesentliche Eigenschaften zeichnen die Blockchain aus: Dezentral und belastbar Die Blockchain ist dezentral organisiert. Das heißt, es gibt keine zentrale Kontrollinstanz, sondern alle Knoten im Netzwerk sind in ihrer Funktion gleichberechtigt. Jederzeit kann ein Knoten das Netz verlassen oder ein anderer hinzukommen [94]. Die dezentrale Organisation bewirkt, dass eine zentrale Kontrolle durch ein Individuum oder eine Organisation erschwert wird. Außerdem wird dadurch das Netzwerk wesentlich belastbarer und ein Ausfall mit zunehmender Anzahl an Knoten immer unwahrscheinlicher. Die Teilnehmer des Netzwerks sind nicht auf ein Unternehmen, eine Organisation oder ein Land beschränkt, sondern können über Landes- und Unternehmensgrenzen hinweg organisiert sein. Auf diese Weise sind Blockchains auch gegenüber politischen oder organisatorischen Eingriffen weitgehend geschützt. Verifizierbar und transparent Auf jedem Knoten des Netzwerks sind die Daten der gesamten Blockchain gespeichert, was den Zugriff auf alle Transaktionen innerhalb der Blockchain für jeden Teilnehmer ermöglicht [94]. Jede Transaktion, die in der Blockchain gespeichert werden soll, wird freiwillig durch immer wieder wechselnde andere Netzwerkteilnehmer verifiziert. Hierbei werden unterschiedliche Algorithmen, auch Konsens-Algorithmen genannt, verwendet. Der bekannteste Konsens-Algorithmus heißt „Proof-of-Work“ und verifiziert Transaktionen auf Basis von Rechenleistung [22]. Sowohl der Konsens-Mechanismus, als auch die Möglichkeit für jeden Netzteilnehmer, alle Transaktionen zu betrachten, sorgen für die Belastbarkeit der Daten sowie eine hohe Nachvollziehbarkeit.

6

S. Schacht

Unveränderlich Alle Daten, die in der Blockchain gespeichert werden, sind „by design“ unveränderlich. Zum Einen ist jede Transaktion in einem eigenen Block gespeichert und dieser mittels kryptografischer Hash-Verfahren mit seinem nachfolgenden Block verkettet. Zum Anderen liegen diese verketteten Blöcke in identischer Form auf vielen unterschiedlichen Knoten [94]. Das heißt: Wird eine Transaktion innerhalb eines Knotens verändert, ist die BlockKette auf diesem speziellen Knoten nicht mehr konsistent, da die errechneten Werte der Blöcke nicht mehr den definierten Regeln entsprechen. Um diesen Mangel zu beheben, müsste ein potenzieller Angreifer nun alle nachfolgenden Blöcke mit viel Rechenaufwand neu verketten. Der Einsatz der dafür notwendigen Rechenleistung stellt die erste Hürde dar. Die zweite Hürde ist, dass die so veränderte Blockchain auf dem einen Knoten nicht mehr mit der Mehrheit der Kopien auf den übrigen Knoten übereinstimmt. Das hat zur Folge, dass der so manipulierte Knoten im Netzwerk als nicht mehr gültig erachtet und ihm eine weitere Teilnahme am Netzwerk verwehrt wird. Damit wäre die Manipulation eliminiert. „Unveränderbarkeit“ bedeutet in diesem Zusammenhang nicht, dass keinerlei Daten verändert werden können, sondern dass das System der Blockchain ungerechtfertigte Änderungen erkennt und aus dem Netzwerk eliminiert. Eine Erläuterung über den genauen Ablauf des Blockchain-Protokolls erfolgt im Abschnitt „Ebene 2 Concept Base – Framework‘“ gegeben. ’

2.3

Distributed-Ledger-Technologie im Detail

Unter Distributed-Ledger-Technologie versteht man ein sozio-technisches Informationssystem, das wie eine dezentrale Datenbank funktioniert, bei dem aber keine dominante zentrale Validierungsinstanz für die zu speichernden Informationen vorhanden ist. Stattdessen erfolgt die Konsensbildung über ein demokratisches Prinzip mit Hilfe von Konsens-Algorithmen. In Anlehnung an Burkhard et al. wird die Distributed-Ledger-Technologie im vorliegenden Buch in vier wesentliche Ebenen aufgeteilt [22]. Ebene 1 „Principles“ geht auf die Komponenten und technischen Aspekte der Distributed-Ledger-Technologie ein. In der Ebene 2 „Concept – Base Framework“ werden die wesentlichen Distributed-Ledger-Technologien wie Blockchain, Tangle und Hashgraph erläutert sowie die Unterschiede zwischen diesen Technologien dargestellt. Auf Ebene 3 „Concept – Application Framework“ werden aufbauend auf den Base Frameworks die Aspekte Smart Contracts und dezentrale autonome Organisationen erklärt. Auf Ebene 4 „Implementation Frameworks“ werden die am Markt gängigen DLT-Projekte nach öffentlichen und permissioned bzw. private DLTs erläutert und die Vor- und Nachteile dargelegt (Abb. 2.3).

2 Die Blockchain-Technologie

7

Abb. 2.3 Ebenen der Distributed-Ledger-Technologie. (In Anlehnung an [22])

2.3.1

Ebene 1„Principles“: Komponenten der Distributed Ledger Technologie

Um ein verteiltes Hauptbuch zu generieren, nutzt die Distributed-Ledger-Technologie unterschiedliche Technologien: Für die Verteilung der Informationen im Netzwerk ohne zentrale Instanz wird auf die Peer-to-Peer-Netzwerk-Technologie zurückgegriffen. Für die Verkettung der einzelnen Blöcke findet zur Bildung von eindeutigen Fingerabdrücken ein HashAlgorithmus Verwendung. Für die Sicherstellung der Identität von Transaktionen wird die asymmetrische Verschlüsselung herangezogen, und für die Schaffung einer Einigung darüber, welche Transaktion überhaupt in die Blockchain geschrieben werden darf, werden unterschiedliche Konsens-Algorithmen wie beispielsweise Proof-of-Work benutzt. Bei der Konsensbildung ist wichtig, dass neben dem Willen aller Teilnehmer zur Sicherung des Netzwerks auch ein Anreiz zur Beteiligung vorhanden ist. Die Implementierung solcher Anreizsysteme geschieht durch die Anwendung spieltheoretischer Ansätze, auf die später noch genauer eingegangen wird. Im Grunde kann man die Blockchain-Technologie als Datenstruktur und Algorithmus in Analogie zur Software beschreiben. Eine Software ist die Summe aus Daten (Datenstruktur) und Algorithmen, die die Daten beliebig bearbeiten [66]. Ähnlich ist es bei der Blockchain; Sie ist die Summe aus den Datenstrukturen, hier Distributed-Ledger-Technologie, und den Algorithmen, die diese Daten verarbeiten. Zu den Algorithmen gehören unter anderem auch die Konsens-Algorithmen [66].

8

S. Schacht

Blockchain = Distributed-Ledger -T echnologie + Consensus

(2.1)

2.3.1.1 Kryptografie Kryptografie spielt in der Blockchain-Technologie eine wichtige Rolle, da über die Verwendung eines Verschlüsselungsverfahrens sichergestellt wird, dass die Person, die eine Transaktion in das Blockchain-Netz eingibt, nachweislich auch diese Person ist und dass die Transaktion nicht während der Übertragung verändert wurde. Mittels der Kryptografie wird somit der Schutz der Daten gegenüber Zugriff unberechtigter Dritter gewährleistet. Des Weiteren werden kryptografische Hashes verwendet, um Veränderungen an Daten aufzuzeigen und nachvollziehbar zu machen. Hash-Verfahren Bei den Distributed-Ledger-Technologien spielen die Hash-Funktionen – auch Streuwertfunktion genannt – eine sehr wichtige Rolle. Mittels dieser Verfahren ist es möglich, für jede Nachricht einen eindeutigen Fingerabdruck zu erzeugen, indem eine Zeichenkette mit einer vorgegebenen Länge generiert wird. Dabei ist es egal, wie groß die Nachricht – also der Input – ist, die erzeugte Zeichenkette ist immer gleich lang. Der Vorteil von solchen Hash-Verfahren ist, dass mittels dieses Werts überprüft werden kann, ob eine Nachricht im Nachhinein verändert wurde oder nicht. Wichtige Anforderungen für eine Hash-Funktion sind, dass für identische Eingaben an Informationen auch immer ein identischer Hash-Wert erzeugt wird. Des Weiteren muss die Hash-Funktion so aufgebaut werden, dass es so wenig Kollisionen wie möglich gibt, dass also die Ausgabe identischer Hash-Werte bei unterschiedlichen Eingaben vermieden wird. Hash-Verfahren dürfen nicht mit Verschlüsselung gleichgesetzt werden. Zwar können Nachrichten in einen Hash-Wert umgewandelt werden, der umgekehrte Weg ist aber nicht mehr möglich. Der Hash-Wert ist nicht invertierbar [59]. Eine typische Verwendung des Hash-Werts ist die sichere Ablage von Passwörtern. Hierzu wird das Passwort mittels einer Hash-Funktion in einen Hash-Wert gewandelt und dieser in einer Datenbank abgelegt. Ein unberechtigter Lesezugriff auf die Datenbank offenbart dann nicht das Passwort, sondern nur den korrespondierenden Hash-Wert, mittels dem das Passwort nicht wiederhergestellt werden kann. Ein Zurückrechnen ist in dem genannten Beispiel bei der Prüfung des Kennwortes aber auch nicht notwendig, da dies durch den Vergleich des berechneten Hash-Werts aus dem eingegebenen Passwort und dem gespeicherten Hash-Wert geschieht. Gängige Hash-Funktionen im kryptografischen Umfeld sind MD5 in der Länge von 128 bits oder der Secure-Hash-Algorithmus (SHA) in unterschiedlichen Längen. Also z. B. SHA256. Als Beispiel wird aus dem unten stehenden Input-Text bei Verwendung des gängigen Verfahrens SHA256 ein Hash-Wert erzeugt:

2 Die Blockchain-Technologie

9

Input: „Dieses Buch handelt von Blockchain und Machine Learning!“ Hash-Wert: „93e4833c9e363723bfb406b1c92a8c6faf421a1a32ee69e2e1180ed3827db9ce“ Der SHA256 hat einen sehr guten Lawineneffekt, also die Eigenschaft, dass kleine Änderungen der Input-Nachricht zu einem komplett anderen Hash-Wert führen. Im Beispiel ändern wir das Ausrufezeichen am Ende des Beispieltextes in ein Fragezeichen: Input: „Dieses Buch handelt von Blockchain und Machine Learning?“ Hash-Wert: „a3c778f3b7a22c2e4b77fd32e0cfa13d0ab0df99e05e36eff923eb8f68f55717“ Kaum ein Zeichen ist in diesem neuen Hash-Wert gleich geblieben, obwohl nur ein einziges Input-Zeichen verändert wurde. Die Länge des Hash-Werts gibt an, wie viele unterschiedliche Werte erzeugt werden können. Eine Hash-Funktion mit der Länge 256 Bit ermöglicht die Erzeugung von 2256 Hash-Werten ohne Kollision. Eine Kollision ist bei dieser Anzahl an möglichen Ergebnissen – nämlich mehr als Sandkörner auf der Erde – überhaupt unwahrscheinlich, besonders wenn die Nebenbedingung erfüllt ist, dass die möglichen Ergebnisse gleich wahrscheinlich auftreten, also gleichverteilt sind [62]. Die Hash-Funktion ist eine wichtige technische Komponente der Blockchain bzw. der Distributed-Ledger-Technologie allgemein, da sie dazu dient, jeden Block, in dem Transaktionen gespeichert sind, mit einem eindeutigen Fingerabdruck zu versehen, der wiederum im nächsten Block gespeichert wird. Auf diese Weise werden die Blöcke miteinander verbunden und unbemerkte Manipulationen einzelner Blöcke unmöglich. Des Weiteren wird die Hash-Funktion bei der digitalen Signatur benötigt, die wiederum bei allen Transaktionen angewandt wird. Asymmetrische Verschlüsselung & digitale Signatur Zum Verschlüsseln von geheimen Informationen wird sowohl die symmetrische als auch die asymmetrische Verschlüsselung angewandt. Bei der symmetrischen Verschlüsselung einigen sich zwei Parteien auf einen gemeinsamen geheimen Schlüssel, der zur Verschlüsselung der Nachricht herangezogen wird. Dieser geheime Schlüssel muss beiden Parteien bekannt sein, denn nur so kann Individuum A die Nachricht ver- und Individuum B sie mit demselben Schlüssel wieder entschlüsseln. Es muss also gewährleistet sein, dass beide Parteien sich vor der eigentlichen Verschlüsselung der sensiblen Nachricht über einen geeigneten geheimen Schlüssel austauschen und diesen über einen – meist ungesicherten – Kanal übertragen. Dies birgt Risiken, da ein Dritter den geheimen Schlüssel abfangen und so die Nachricht übersetzen könnte. Das asymmetrische Verschlüsselungsverfahren versucht, das Übermitteln des geheimen Schlüssels durch die Verwendung von einem Schlüsselpaar aus einem privaten und einem öffentlichen Schlüssel überflüssig zu machen. Dieses Verfahren wird bei den meisten Blockchain-Technologien verwendet, schon, weil ein direkter Austausch des geheimen

10

S. Schacht

Schlüssels für die symmetrische Verschlüsselung bedingt, dass alle Teilnehmer eines Netzwerks sich persönlich kennen. Bei der asymmetrischen Verschlüsselung wird für jeden Teilnehmer des Netzwerks jeweils ein öffentlicher und ein privater Schlüssel generiert. Beide Schlüssel bestehen aus mathematisch generierten alphanumerischen Zeichen einer bestimmten Länge und sind nicht identisch, hängen aber voneinander ab. Die Berechnung des Schlüsselpaares muss so gestaltet sein, dass sie in die eine Richtung einfach zu bestimmen, aber schwierig wieder zurückzuberechnen ist [20]. Zum Beispiel werden beim RSA-Verfahren – das seinen Namen von den Erfindern Rivest, Shamir und Adleman bekommen hat – Einwegfunktionen auf Basis von Primzahlen-Multiplikationen vorgenommen. Diese Berechnung ist sozusagen eine mathematische Einbahnstraße, da die Multiplikation zwar simpel ist, das Ergebnisprodukt aber nur sehr schwer wieder zurück in die ursprünglichen Primzahlen zerlegt werden kann [54]. Das Produkt 42.444.277 aus den Primzahlen 8311 und 5107 kann beispielsweise bei Kenntnis dieser beiden Ausgangswerte sehr schnell berechnet werden. Anders herum dauert es schon etwas länger, ohne Kenntnis der einzelnen Primzahlen die Teiler von 42.444.277 zu finden. Die genannte Zahl hat aufgrund der Wahl der Primfaktoren als Ausgangsprodukt nämlich nur vier Teiler: 1, die Zahl selber und die beiden Primzahlen, aus der sie gebildet wurde. Für die Rückrechnung des Produktergebnisses auf die ursprünglichen Primzahlen gibt es momentan keine guten Algorithmen, es muss viel durch ausprobieren ermittelt werden. Dazu sind Computer natürlich in der Lage, aber wenn für das Produkt ausreichend große Primzahlen herangezogen werden, dauert dies sehr lange. Bei einem 300-stelligen Produkt ist aktuell kein Computer in der Lage, die Berechnung in akzeptabler Zeit vorzunehmen. Auch eine Steigerung der Rechenleistung bringt da nicht viel, weil parallel zur Steigerung der Rechenleistung auch die Größe der Ausgangs-Primzahlen verändert werden und damit das Lösen des Rätsels ebenfalls nicht schneller vorgenommen werden kann [54]. Da es nun aber wichtig ist, dass die Person, die den privaten Schlüssel besitzt, eine verschlüsselte Nachricht schnell und einfach entschlüsseln kann, wird auf sogenannte Falltürfunktionen zurückgegriffen. Das sind Funktionen, die mit einer Zusatzinformation leicht rückzurechnen sind. Im RSA-Verfahren setzt sich der private Schlüssel aus den beiden Primfaktoren und einer weiteren Zahl zusammen, deren größter gemeinsamer Teiler 1 sein muss. Aus diesen drei Komponenten können nun öffentlicher und privater Schlüssel erzeugt werden. Folgende Formel ergibt den öffentlichen Schlüssel: Beispielhaft würden die Primzahlen 13 und 19 sowie die Zahl e mit 7 einen privaten Schlüssel d von 31 ergeben: 1 =(e ∗ d)mod(( p − 1) ∗ (q − 1)) p, q Primzahlen e Weitere Zahl d Privater Schl¨ussel

(2.2)

2 Die Blockchain-Technologie

11

1 = (7 ∗ d)mod((13 − 1) ∗ (19 − 1)) = 1 = (7 ∗ d)mod216 = (7 ∗ d) = 216 + 1 = d = 31 Da die Restberechnung 1 sein muss, ergibt sich für den Term (7 * d) das notwendige Ergebnis von 217. d ist folglich 31. Der öffentliche Schlüssel setzt sich zusammen aus dem Produkt o, der Multiplikation beider Primzahlen sowie der weiteren Zahl e: o = ( p ∗ q) = 12 ∗ 19 = 247

(2.3)

Somit ergibt sich dieser als 247 und 7. Mittels dieser beider Zahlen kann nun eine beliebige Nachricht verschlüsselt werden. Hierbei wird die Nachricht N zunächst in eine Zahl umgewandelt, z. B. könnte man hierfür die ASCII-Code-Tabelle für den Buchstaben T, der durch den Wert 84 repräsentiert wird, heranziehen. Eine Verschlüsselung dieses Werts wird nun mittels nachstehender Formel vorgenommen: C = N e modo

(2.4)

In dem aufgeführten Beispiel würde folgende Berechnung vorgenommen: C = 847 mod247 C = 46 Eine Entschlüsselung der Zahl 46 zurück zur 84 ist nun nurmehr möglich, wenn der private Schlüssel d bekannt ist. Dann wird folgende Formel angewandt: N = C d modo

(2.5)

In dem Beispiel würde folgende Rückrechnung vorgenommen werden: C = 4631 mod247 C = 84 Die 84 entspricht unserem vorher ausgewählten ASCII-Zeichencode. Auf diese Weise kann nun eine Nachricht verschlüsselt werden. Da es sehr schwierig ist, aus dem öffentlichen Schlüssel den privaten Schlüssel zu bestimmen, können die öffentlichen Schlüssel jedem bekannt gemacht werden, was einen leichten Austausch der Schlüssel ermöglicht. Dadurch reduziert sich die Anzahl der benötigen Schlüssel enorm.

12

S. Schacht

Mittels der Graphentheorie, die Graphen und ihre Beziehungen zueinander untersucht, kann ermittelt werden wie viele Schlüssel bei einem symmetrischen Verschlüsselungsverfahren für eine gegebene Anzahl an Teilnehmer notwendig ist. Die Knoten stellen die Anzahl der Teilnehmer und die Kanten die notwendigen geheimen Schlüssel zwischen den Individuen da. Es wird nun ein geschlossener Graph gebildet, bei dem jeder Knoten per Kante auf jeden anderen Knoten verweist. In diesem Beispiel wird von 1000 Personen ausgegangen. Gemäß würden, wenn vereinfacht davon ausgegangen wird, dass kein der Formel N = n∗(n−1) 2 = Schlüssel mehrfach verwendet werden darf, für diese Konstellation N = 1000 ∗ (1000−1) 2 499.500 verschiedene Schlüssel benötigt. Bei Anwendung des asymmetrischen Verfahrens dagegen werden für jeden Teilnehmer des Netzwerks lediglich ein öffentlicher und ein privater Schlüssel, also insgesamt 2n Schlüssel gebraucht. In den konkreten Zahlen unseres Beispiels ausgedrückt ergibt sich somit eine benötigte Schlüsselanzahl von 2000 [48]. Seinen Namen trägt das Verfahren wegen der asymmetrischen Verteilung der Schlüssel unter den Teilnehmern. Wollen zum Beispiel die zwei Personen S und E eine verschlüsselte Nachricht austauschen, so gibt Person E Person S ein offenes Schloss – dies stellt vereinfacht den öffentlichen Schlüssel aus dem Primzahlenprodukt und einer weiteren Zahl dar. Person S nimmt nun das offene Schloss und verschließt damit die Nachricht in einer Kiste. Das übergebene Schloss kann S nur zum Verschließen verwenden, öffnen kann S es nicht mehr. Sobald die Kiste verschlossen ist, kann nur E diese wieder öffnen, da nur E den entsprechenden Schlüssel besitzt. Der Schlüssel, mit dem das Schloss wieder geöffnet werden kann, liegt ausschließlich in der Hand von Person E und stellt ihren privaten Schlüssel dar [54]. Eine Abwandlung der Verschlüsselung von ganzen Nachrichten ist das digitale Signieren. Unter einer Signatur versteht man die Versicherung, dass eine Nachricht nach der Übertragung nicht verändert wurde. Ein Dokument, das digital signiert ist, kann von jedem gelesen werden, aber durch die Signatur ist gewährleistet, dass das Dokument nach dem Signieren durch den Verfasser von niemandem verändert wurde. Dafür wird zunächst mittels eines Hash-Algorithmus eine eindeutige Prüfsumme aus dem gesamten Text ermittelt – sozusagen der Fingerabdruck der Nachricht. Verschlüsselt wird nun nicht mehr die gesamte Nachricht, sondern nur der Hash-Wert, der dann ans Ende der Nachricht angehängt wird. Besitzt nun Empfänger E der signierten Nachricht den öffentlichen Schlüssel des Senders S, kann er die Signatur am Ende der Nachricht entschlüsseln und erhält den durch S berechneten Hash-Wert. Empfänger E berechnet nun ebenfalls einen Hash-Wert für die empfangene Nachricht. Ist der entschlüsselte Hash-Wert identisch mit dem berechneten Hash-Wert der empfangenen Nachricht, ist klar, dass die Nachricht nach der Signatur durch den Sender S nicht mehr verändert wurde. Dieses Verfahren wird bei vielen Blockchains verwendet, um die Identitäten von Konten und deren Transaktionen sowie deren Integrität zu gewährleisten. Die Nummernfolge, die

2 Die Blockchain-Technologie

13

sich aus dem öffentlichen Schlüssel ergibt, wird auch häufig als Kontonummer, in Blockchains z. B. für Kryptowährungen wie Ethereum u. a., verwendet.

2.3.1.2 Spieltheorie – Konsens Wesentlicher Schlüssel für die Funktionsfähigkeit eines dezentralen Netzwerks ist ein Mechanismus, der sicherstellt, dass die Knoten des Netzwerks Transaktionen verifizieren und sich außerdem alle Knoten darüber einig sind, in welcher Reihenfolge Transaktionen im Hauptbuch erfasst werden. Dieser Mechanismus wird Konsens-Mechanismus genannt und ist zentraler Bestandteil der Distributed-Ledger-Technologie. Er gewährleistet, dass Transaktionen nicht doppelt und invalide Daten, die die Integrität des Hauptbuches verletzen könnten, gar nicht gespeichert werden [88]. In den meisten Informationssystemen wird eine solche Kontrolle durch eine zentralisierte Instanz vorgenommen, wie beispielsweise das System zur Verwaltung von Konten einer Bank. Eine Überweisung von Konto A auf Konto B wird durch die Bank und die zentral in das Informationssystem eingearbeiteten Kontrollen verifiziert und die ordnungsmäßige Erfassung der Überweisung im System sichergestellt. Es existiert somit ein durch eine zentrale Instanz geführtes Kontrollsystem, dem die Teilnehmer vertrauen. Im dezentralen System der Distributed-Ledger-Technologie wird diese zentrale Kontrollinstanz entfernt. Die Aufgabe der Verifizierung und Sicherstellung der ordnungsgemäßen Erfassung im Hauptbuch wird durch den Konsens-Mechanismus vorgenommen, der so als Mittel zur Entfernung von Intermediären, also von Zwischenakteuren, dient [58]. Um die Notwendigkeit des Konsens-Mechanismus zu erklären, greift Anthony Stevens beispielhaft auf die Geschichte der Datenbank-Applikationen zurück. Er zeigt auf, wie sich aufgrund der Verfügbarkeitsdebatte aus einem zentralen Datenbanksystem verteilte Datenbanksysteme entwickelt haben [88]: In den Anfangszeiten wurde für eine Applikation eine Master-Datenbank eingesetzt, die alle Daten der Applikation speicherte. Da sämtliche Daten jedoch nur an einer Stelle gespeichert wurden, agierte die Datenbank als gefährlicher Single Point of Failure. Durch BackupMechanismen konnte man dieses Problem zwar lösen, aber um eine schnellere Rücksicherung im Schadensfall zu gewährleisten, wurde später neben der Master-Datenbank auch eine Slave-Datenbank eingesetzt, in der alle Daten in Echtzeit mit abgelegt wurden. Fiel die Master-Datenbank aus oder war defekt, konnte zügig auf die Slave-Datenbank zurückgegriffen werden. Ein direktes Speichern in die Slave-Datenbank oder das Auslesen daraus war in diesem Szenario nicht vorgesehen, da die Slave-Datenbank erst zur Verwendung kam, wenn die Master-Datenbank ausfiel. Die Weiterentwicklung dieses Szenarios führt zu dezentralen Datenbanken, bei denen mehrere Master-Datenbanken miteinander vernetzt sind und die Daten so an unterschiedlichen Knoten gespeichert und ausgelesen werden. Dieser Aufbau führt allerdings wieder zu Problemen, denn wenn gleiche Daten innerhalb der Applikation verändert werden, kommt

14

S. Schacht

es zu einem Synchronisations-Konflikt, den jemand lösen muss. Mit zunehmender Zahl an Knoten und gegebenenfalls auch Benutzern nehmen solche Konflikte immer mehr zu [88]. Die Darstellung von Stevens zeigt auf, dass eine rein technische Lösung zu Konflikten führt und dass diesen Konflikte schon bei der Erstellung des Algorithmus vorgebeugt werden muss. Werden dezentrale Datenbanken über mehrere Unternehmen hinweg betrieben, wie es z. B. in Konsortien vorkommen kann, stellt sich die Frage, wer die Hoheit und damit die Verantwortung über das System übernimmt. In der Regel wird dies ein dominanter KonsortiumsTeilnehmer sein, der durch die Verwaltung eine gewisse Machtposition erlangt. In einer dezentralen Multi-Master-Welt sollte das Ziel sein, dass die Konsens-Bildung über die Richtigkeit der Daten sowie ihre Ablage ebenfalls dezentral und nicht durch einen einzelnen Teilnehmer gewährleistet ist. Ferner zeigt Stevens auf, dass für die Erstellung eines solchen Algorithmus drei Bedingungen zu erfüllen sind [88]: 1. Der Algorithmus muss sicherstellen, dass sich alle Teilnehmer, die eine Instanz, also einen Master, der Datenbank kontrollieren, auf eine Reihenfolge der zu speichernden Transaktionen einigen und diese auch in der festgelegten Reihenfolge ablegen. 2. Ferner darf kein Teilnehmer die Fähigkeit haben, die definierte und gemeinsam freigegebene Reihenfolge von Transaktionen zu ändern. 3. Schon freigegebene Transaktionen, die über die Knoten hinweg verteilt werden, dürfen nicht durch einen Teilnehmer gestoppt oder verhindert werden können. Mit diesen drei Bedingungen zeigt Stevens, dass es sich bei der Konsens-Bildung um einen Prozess handelt, der komplett durchlebt werden muss, damit es sicher zu einer Einigung kommen kann. Verallgemeinert wird der Prozess der Konsens-Bildung in folgenden Schritten beschrieben [88]: 1. Jeder Knoten erstellt eigene Transaktionen. 2. Die so erstellten Transaktionen müssen mit allen beteiligten Knoten ausgetauscht werden, sodass alle Knoten den gleichen Datenstand haben. 3. Es wird Konsens über die Reihenfolge und die Richtigkeit der Daten zwischen den Knoten hergestellt. 4. Im letzten Schritt aktualisieren die Knoten das Ergebnis der Konsensbildung in den jeweiligen Transaktionen. Um unterschiedlichen Anforderungen gerecht zu werden, existieren unterschiedlichste Konsens-Algorithmen. Dabei versteht man unter einem Algorithmus laut Nölle Acheson eine genaue operative Abfolge von Handlungsanweisungen bzw. Befehlen, die eine Maschine in

2 Die Blockchain-Technologie

15

immer derselben Reihenfolge abarbeiten muss. Dahingegen sei ein Protokoll eine Beschreibung, wie etwas ausgestaltet sei, also die Eigenschaften, die eine Applikation oder ein Objekt besitzt [1]. Im Kontext der Distributed-Ledger-Technologie liefert das Protokoll den grundsätzlichen Rahmen, wie die Kommunikation zwischen den Knoten abläuft, bzw. wie die Daten verteilt werden. Dem Algorithmus obliegen nach den vordefinierten Regeln des Protokolls Funktionen wie die Verifizierung von Signaturen oder die Entscheidung, ob ein Block valide ist. Die Unterscheidung zwischen Protokoll und Algorithmus ist laut Acheson dahingehend wichtig, da durch eine getrennte Betrachtung der Rahmenbedingungen (Protokoll) und der Umsetzung (Algorithmus) unterschiedlichste kreative Ansätze gefunden werden können [1]. Diese Kreativität spiegelt sich auch in der Masse der existierenden Konsens-Algorithmen wieder, die unterschiedliche Eigenschaften besitzen, aber trotzdem den von Stevens verallgemeinerten Prozessschritten folgen. Überblick Konsens-Algorithmen In einem dezentralen System können drei mögliche Fehler auftreten. Erstens: Eine Komponente des Systems stellt seine Funktion ein und ist damit nicht mehr für alle Teilnehmer erreichbar. Zweitens: Nachrichten, über die die Knoten miteinander kommunizieren, werden zwar versendet, kommen aber nicht bei den Zielknoten an. Drittens: Es werden Nachrichten mit gefälschtem Inhalt übermittelt. Dieser Fehlertyp wird byzantinischer Fehler genannt [50]. Der byzantinische Fehler beruht auf dem Gedankenspiel der byzantinischen Generäle, das von Lamport in seinem Paper „The Byzantine Generals Problem“ veröffentlicht wurde: Drei Generäle wollen eine Stadt erobern. Dabei sind sie soweit voneinander entfernt, dass eine direkte Kommunikation nicht möglich ist – sie können lediglich Nachrichten über Boten austauschen. Die Stadt kann aber nur dann besiegt werden, wenn alle Generäle gleichzeitig angreifen. Sie müssen sich also auf eine einheitliche Strategie einigen, nämlich angreifen oder nicht angreifen [56]. Bezogen auf die Problematik in verteilten Systemen sind die Generäle die Knoten, die am Netzwerk partizipieren und die Nachrichten sind ebenfalls Nachrichten, die in verteilten Systemen unter den Knoten ausgetauscht werden, um das Netzwerk aktiv zu halten. Lambert geht weiter davon aus, dass sich unter den Generälen Verräter befinden, die an der Kommunikation des Netzwerks teilnehmen, aber das Ziel verfolgen, den Verbund zu destabilisieren. Alle Generäle wie auch der Kommandant sind in diesem Beispiel gleichberechtigt, so dass keine Entscheidung per Hierarchie herbeigeführt werden kann. General 1, der Kommandant, gibt den Befehl zum Angriff und schickt diesen Befehl per Bote an General 2 und 3. General 3 stellt in unserem Gedankenspiel den Verräter dar. Er bekommt die Nachricht für den Angriff, gibt aber an General 2 weiter, man solle sich zurückziehen. General 2 hat nun kaum eine Möglichkeit, zu entscheiden, ob der Angriff durchzuführen ist oder nicht – er hat widersprüchliche Befehle erhalten und weiß nicht, wem zu trauen ist (Abb. 2.4).

16

S. Schacht

Abb. 2.4 Byzantine Generäle. (In Anlehnung an [56])

Das Gedankenspiel kann in unterschiedlichen Richtungen durchgespielt werden. Wenn beispielsweise der Kommandant der Verräter ist und beiden Generälen unterschiedliche Nachrichten schickt. Lambert führt weiter aus, dass es bei einem Netzwerk aus drei Knoten nie zu einer Lösung kommt, die den Verräter identifiziert oder die Entscheidung zugunsten des Netzwerks durchführt. Bei mehr als drei Generälen dagegen zeigt Lambert auf, dass eine Konsensbildung über die Mehrheit der Generäle möglich ist, wenn mindestens 3 m + 1 Generäle im Netzwerk existieren, wobei m die Menge der Verräter im Verbund darstellt. Die Anzahl der Verräter muss also kleiner als ein Drittel sein. Diese Art des Fehlers, also das manipulierende Handeln von Netzteilnehmern, tritt vor allem in dezentralen Systemen mit vielen unbekannten bzw. sich nicht per se vertrauende Knoten bzw. Teilnehmern auf. Vor allem dann, wenn das Individuum ein größeres Individualinteresse an einer Fehlentscheidung hat, als es Vorteile aus dem gemeinsamen Betrieb des Netzwerks zieht. Aus diesem Grund müssen, neben dem Versprechen eines funktionierenden Netzwerkes zusätzliche Anreize zur Einhaltung der Konsensregeln geboten werden. Um nun einen Überblick über die unterschiedlichen Konsens-Algorithmen zu bekommen, können die drei eingangs dargestellten Fehlertypen herangezogen werden. Bei den Fehlertypen eins und zwei handelt es sich um Fehler, die in einem dezentralen System leicht identifiziert werden können; Es sind binäre Fehler. Ein binärer Fehler kann zwei Zustände annehmen: Ein Knoten des verteilten Systems funktioniert ordnungsgemäß oder er funktioniert nicht bzw. Nachrichten werden empfangen oder werden nicht empfangen. Der byzantinische Fehler lässt sich nicht so einfach erkennen, da es sich hierbei nicht um einen binären Fehler handelt, sondern um einen ordnungsgemäß funktionierenden Knoten des Netzes, der Nachrichten gemäß Protokoll übermittelt, allerdings mit manipulierten, fehlerhaften Inhalten. Zur Erkennung des byzantinischen Fehlers wurden spezielle KonsensAlgorithmen entwickelt, sodass es sich anbietet, die Algorithmen in die Kategorien „Byzantinischer Fehler“ und „Nicht byzantinischer Fehler“ zu unterteilen (Siehe Abb. 2.5). Die Kategorie „Nicht byzantinischer Fehler“ kann gemäß Preethi Kasireddy auch als einfache Fehlertoleranz bezeichnet werden und wird oft bei kontrollierten Umgebungen, in denen alle Beteiligten sich kennen und vertrauen, angewandt [50].

2 Die Blockchain-Technologie

17

Abb. 2.5 Einteilung Konsens-Mechanismen

Neben den Fehlertypen als Hilfsmittel zur Klassifizierung vorhandener Algorithmen ist es sinnvoll, die Algorithmen ergänzend über den Bekanntheitsgrad der Netzwerkteilnehmer zu klassifizieren. Eine Kategorie sind dabei Algorithmen, die verwendet werden, wenn sich alle Teilnehmer des verteilten Systems kennen. Dem gegenüber stehen Algorithmen, die zur Anwendung kommen, wenn sich die Teilnehmer gar nicht kennen. Abb. 2.5 zeigt eine Aufteilung der Algorithmen gemäß den beiden Dimensionen Bekanntheitsgrad und byzantinischer Fehler. Sind die Teilnehmer des Netzwerks einander bekannt und sind byzantinische Fehler nicht zu erwarten, können Konsens Algorithmen wie PAXOS und RAFT eingesetzt werden. Der Sachverhalt „unbekannte Netzteilnehmer“ und „Nicht byzantinischer Fehler“ ist eine Kategorie, die aus Sicht des Autors nicht vorkommen kann, da einzelne Individuen, wenn sie sich nicht kennen und sich auch nicht vertrauen, immer zu ihrem eigenen Vorteil entscheiden und somit Entscheidungen, die im Verbund notwendig sind, individuell aber zunächst einen Nachteil darstellen, nicht mitgetragen werden. Die Teilnehmer verhalten sich dann entsprechend byzantinisch. In der Gruppe der einander bekannten Teilnehmer, die trotzdem byzantinische Fehler zulassen könnten, sind vor allem die Konsens-Algorithmen Practical Byzantine Fault Tolerance (PBFT) und UpRight zu nennen. Bei dieser Gruppe könnte man z. B. von Unternehmenszusammenschlüssen sprechen, bei denen sich die Teilnehmer gut kennen, aber trotzdem ein gewisses Misstrauen vorhanden ist und somit byzantinische Fehler auftreten können. In der letzten Gruppe sind vor allem öffentliche dezentrale Systeme zu subsumieren, bei denen sich die Teilnehmer nicht kennen und byzantinische Fehler wahrscheinlich sind. Hierzu gehören die Kryptowährungen, die einen freien Handel über Landes- und Systemgrenzen zulassen. Sie bieten einen Anreiz für Betrüger, den eigenen Kontostand zu manipulieren. Um in einem solchen Netz zu einer Einigung zu kommen, kann auf KonsensAlgorithmen wie Proof-of-Work, Proof-of-Stake, S-Chord oder auf Derivate dieser grundlegenden Algorithmen zurückgegriffen werden.

18

S. Schacht

Konsens-Algorithmen im Detail Im nachfolgenden Abschnitt werden die wesentlichen Konsens-Algorithmen vorgestellt. Interessant sind vor allem die Algorithmen, die den nyzantinischen Fehler berücksichtigen. Dementsprechend werden die Algorithmen Proof-of-Work und Proof-of-Stake für die Kategorie „Teilnehmer kennen sich nicht“ und die Algorithmen Practical Byzantine Fault Tolerance für die Kategorie „Teilnehmer kennen sich“ ausgewählt und dargestellt. Proof-of-Work Proof-of-Work (PoW) ist einer der bekanntesten und auch am weitesten verbreiteten Konsens-Algorithmen. Grund hierfür ist der Einsatz in einigen Kryptowährungen wie Bitcoin, Litecoin aber auch Cash, Monero und anderen [95]. Der Algorithmus basiert vor allem auf der Idee, durch einzusetzende Rechenleistung ein kryptographisches Rätsel zu lösen und damit nachzuweisen, dass man durch den Einsatz von eigenen Ressourcen vertrauenswürdig ist. Technologische Basis des Algorithmus sind Hash-Verfahren, Merkle-Trees und P2P-Netzwerke [95]. Historisch gesehen ist dieser Algorithmus keine neue Erfindung, die erst durch die Distributed-Ledger-Technologie aufgetaucht ist. Nach Abdul Wahab und Waqas Mehmood wurden Teile des Algorithmus schon in früheren Implementierungen in anderen Zusammenhängen verwendet. So zeigen die Autoren auf, dass 1992 die Grundprinzipien von Dwork und Naor in ähnlicher Form in Algorithmen zur Verhinderung von E-Mail-Spam verwendet wurden. Nachweis ist der Artikel „Pricing via Procession or Combatting Junk eMails“ der beiden. 1996 kam der Algorithmus für die Micropaymentsysteme PayWord und Micromint von Rivest und Shamir in ihrem Artikel „Payword and MicroMint – Two Simple Micropayment Schemes“ zur Anwendung [95]. Ferner führen Wahab und Memood auf, dass die Technologie 1997 zur Verifizierung von Besucherzahlen auf Webseiten vorgeschlagen wurde, um erwirtschaftete Werbeeinnahmen durch den Nachweis von Besucherzahlen betrugsfrei sicherzustellen. Ergänzend wurde die Idee des Proof-of-Work im Hashcash-Verfahren zur Anwendung gebracht, einem Verfahren, das auch zur Reduktion von E-Mail-Spam und Denial-of-Service-Attacken bzw. als Mechanismus zur Verhinderung des Missbrauchs von allen möglichen freien Internetressourcen entwickelt wurde. Beschrieben wurde es von Adam Back in seinem Whitepaper „Hashcash – A Denial of Service Counter-Measure“ [8]. Die erstmalige Anwendung des PoW-Verfahrens fand dann durch Satoshi Nakamoto1 in seinem Whitepaper „Bitcoin: A Peer-to-Peer Electronic Cash System“ statt, wobei es davor sicherlich noch weitere Anwendungen gab. Alle diese Implementierungen basieren auf der Idee, freie Ressourcen durch eine beliebig ausgestaltete Arbeitsleistung zu schützen, indem immer dann, wenn die Ressource genutzt wird, die ordnungsgemäße Verwendung durch die Investition dieser Arbeitsleistung nachgewiesen werden muss. Am Beispiel von SpamE-Mails dürfen Mails nur dann versendet werden, wenn eine gewisse Rechenleistung zum Nachweis erbracht wurde, dass der Versender bereit ist, Ressourcen bereitzustellen. Damit wird der Versand von Emails durch den Mechanismus sozusagen bepreist. Die Bepreisung 1 Hierbei handelt es sich um ein Pseudonym des Autors, der bis heute nicht bekannt ist.

2 Die Blockchain-Technologie

19

entsteht einerseits durch die einzusetzenden Ressourcen und andererseits durch eine leichte Verzögerung des Mailversandes, die durch die rechtmäßige Benutzung der E-Mail-Funktion nicht auffällt aber massenhafter Versand durchaus behindert werden kann. Bezogen auf öffentliche Blockchains wäre das Ausführen einer Transaktion bzw. die Erstellung eines Blocks, der mehrere Transaktionen zusammenfasst, kostenlos. Bei kostenlosen Ressourcen stellt sich immer die Frage, was einen Knotenbetreiber davon abhält, Blöcke mit Transaktionen zu erzeugen, die vor allem einen Vorteil für den Betreiber des Knotens bedeuten. Die Grundidee zur Verhinderung dieses Missbrauchs sieht vereinfacht wie folgt aus: Jeder Knotenbetreiber hat die Möglichkeit, einen Block aus gebündelten Transaktionen zu erzeugen. Damit nicht unendlich viele Transaktionen erzeugt werden und das Netz geflutet wird, schreibt der Algorithmus vor, dass zunächst ein kryptografisches Rätsel gelöst werden muss, ehe ein Block in die Blockchain geschrieben werden kann. Diese Bepreisung der Erstellung einer Transaktion sorgt dafür, dass Betreiber nicht beliebig viele – vielleicht auch manipulierte – Transaktionen erzeugen. Durch die Bepreisung ist aber nicht sichergestellt, dass nicht doch eine betrügerische Transaktion den Weg in die Blockchain findet. Um dies zu verhindern, sieht der PoWAlgorithmus vor, dass der Block mit den neuen Transaktionen, der in der Blockchain gespeichert werden soll, nicht nur von einem, sondern von mehreren Knotenbetreibern verifiziert werden muss. Diese Verifizierung wird ebenfalls durch das Lösen des kryptografischen Rätsels vorgenommen. Der Knoten, der das Rätsel am schnellsten löst, bekommt eine Belohnung z. B. in Form einzelner Kryptowährung-Coins, auch Mining genannt. Ein Block wird aber nur dann in die Blockchain geschrieben, wenn das Rätsel gelöst wurde und andere Knotenbetreiber das Ergebnis verifiziert haben. Hierdurch wird gewährleistet, dass ein Knotenbetreiber zwar unsinnige oder betrügerische Transaktionen erzeugen kann, sie aber spätestens bei der Verifizierung durch andere Netzteilnehmer entdeckt und eliminiert werden. Besonders bei einer großen Anzahl an Knoten kann es vorkommen, dass mehrere Teilnehmer das Rätsel für einen Block gleichzeitig lösen. Wenn nun die anderen Knoten die verschiedenen neuen Blöcke verifizieren, entstehen unterschiedliche Blockketten mit unterschiedlicher Länge. Damit die Blockchain konsistent bleibt und nicht unterschiedliche Blockketten nebeneinander existieren, wird von den Knoten nur die längste Blockkette akzeptiert, da diese von der Mehrzahl der Knotenbetreiber als valide angesehen wurde. Die wesentlichen Eigenschaften des PoW-Algorithmus sind [95]: • Anwendbar für öffentliche Distributed-Ledger • Jede Transaktion ist mittels des asymmetrischen Verschlüsselungsverfahrens digital signiert und wird auch von den Knoten nur dann akzeptiert, wenn die Signatur valide und verifizierbar ist. • Bei Konflikten – insbesondere in der zeitlichen Erstellung und Verifizierung von Blöcken – werden zunächst zwar verschiedene lineare Äste der Blockchain erstellt, am

20

S. Schacht

Ende überlebt aber nur der längste, da dieser als vertrauenswürdigster Ast angesehen wird. • Der Algorithmus besitzt eine faire und nachvollziehbare Auswahl der Miner, die berechtigt sind einen Block in die Blockchain zu schreiben und damit eine Belohnung zubekommen, die für die Erstellung eines Blocks vergeben wird. Die Wahrscheinlichkeit, eine gültigen Block zu erstellen, ist direkt proportional zu der eingesetzten Rechenleistung im Verhältnis zur verfügbaren Gesamtrechenleistung, die dem gesamten Blockchain-Netz für das Mining zur Verfügung steht. Je mehr Rechenleistung eingesetzt wird je wahrscheinlicher ist es, als erster einen gültigen neuen Block zu erstellen und hierfür die Belohnung zu erhalten. Neben den Vorteilen, nämlich, dass PoW ein einfaches und faires Verfahren ist, hat es auch einige Nachteile, die nicht unerwähnt bleiben dürfen. Ganz vorne ist der Energieverbrauch zu nennen. Durch die Tatsache, dass viele Teilnehmer dasselbe Rätsel lösen müssen und nur einer gewinnen kann, wird Rechenleistung vergeudet. Das Rätsel, das gelöst werden muss, ist weitestgehend sinnlos. Es dient nur als Nachweis, dass der Teilnehmer bereit ist, eine gewisse Rechenleistung zu investieren, damit der Block aufgenommen wird. Einen weiteren Nutzen hat es nicht. Andererseits sichert dieser hohe Energieeinsatz das Netz zusätzlich gegen Angriffe ab. So müsste z. B. ein Angreifer, der die Blockchain rückwirkend ändern möchte, mindestens 51 % der gesamten Rechenleistung auf sich vereinen. Eine weitere nachteilige Eigenschaft des Proof-of-Work-Algorithmus ist die Difficulty. Wenn mehr und mehr Miner dem Netz beitreten und hierdurch mehr Rechenleistung für das Gesamtnetz zur Verfügung steht, muss dennoch das Protokoll für alle Beteiligten fair und auch die Zeit für die Erstellung eines Blocks weitestgehend konstant bleiben. Dazu wurde beim Proof-of-Work-Protokoll ein Schwierigkeitsgrad für die Lösung des Rätsels eingeführt. Nimmt die Gesamtrechenleistung im Netz zu, dann steigt auch der Schwierigkeitsgrad (eben die Difficulty) des Rätsels. Das bedeutet, dass mit zunehmender Anzahl an Minern – also Knotenbetreibern – nicht die Transaktionsgeschwindigkeit zunimmt, sondern die Schwierigkeit des Rätsels erhöht und dadurch mehr Energie verbraucht wird. Die Geschwindigkeit, mit der Transaktionen verifiziert werden, bleibt hierdurch aber konstant. Beim PoW-Verfahren gewinnen tendenziell eher diejenigen Miner, die über die größte Rechenleistung verfügen. Das führte dazu, dass mittlerweile Mining-Rigs aus zusammengeschlossenen Grafikkarten verwendet werden, die viel mehr Rechenleistung liefern können als z. B. die CPUs eines Rechners. Ergänzend bildeten sich sogenannten Mining-Pools, in denen sich viele Miner zu einem virtuellen großen Miner zusammenschließen, um gebündelte Rechenleistung bereitzustellen. Diese Mining-Pools und auch die Mining-Rigs werden in der Regel in Gebieten betrieben, wo der Strom billig ist, was die Marge weiter erhöht. In der 2nd Global Cryptoasset Benchmarking Study wird aufgezeigt, dass der Strombedarf der sechs größten Kryptowährungen, die Proof-of-Work als Konsens-Algorithmus verwenden, im Mittel bei 82 TWh pro Jahr liegt [81]. Interessant ist, dass die Studie auch aufzeigt, dass

2 Die Blockchain-Technologie

21

ein Großteil dieser Strommenge von Anlagen für erneuerbare Energiequellen bereitgestellt wird, die in Regionen betrieben werden, deren Lage eine Überproduktion ermöglicht [81]. Die Diskussionen bezüglich des enormen Energieverbrauches können durch diese Kenntnis ein wenig abgeschwächt werden. Nichtsdestotrotz ist es sinnvoll, verstärkt Algorithmen zu betrachten, die in diesem Punkt effizienter sind. Durch die Limitierungen des Proof-of-Work-Algorithmus werden immer wieder Derivate des PoW erarbeitet. So zeigt Sunny King in seinem Whitepaper auf, dass man das sinnlose Lösen des Rätsels auch für die Suche nach Primzahlen verwenden könnte und somit der mathematischen Forschung eine Hilfestellung leisten könnte [51]. Andere Ansätze schlagen vor, dass man die Algorithmen grundsätzlich anders aufbauen sollte, wie beispielsweise den Proof-of-Stake-Algorithmus, der von einigen Blockchains verwendet wird. Proof-of-Stake Beim Proof-of-Stake-Algorithmus (PoS) handelt es sich um einen Konsens-Algorithmus, der vor allem in Netzwerken verwendet wird, in denen sich viele Teilnehmer untereinander nicht kennen und byzantinisches Verhalten – also Betrugsversuche einzelner Teilnehmer – nicht ausgeschlossen ist. Wird beim PoW das Vertrauen durch die Bereitstellung von Rechenleistung zum Lösen eines Rätsels hergestellt, geschieht das beim PoS über einen Anteilsnachweis. Auch der Proof-of-Stake-Algorithmus hat zum Ziel, Transaktionen zu verifizieren und einen Konsens, also eine digitale Einigung über die Richtigkeit und damit die Blockchain zwischen allen Teilnehmern, herzustellen. Als Basis wird ein Anteilssystem herangezogen. Beim PoW gibt es ein Wettrennen um die Erstellung des Blocks: Derjenige, der das kryptografische Rätsel als Erster löst, darf den Block erstellen und wird dafür mit Kryptowährungen entlohnt. Beim PoS findet die Entscheidung, wer einen Block erstellen darf, auf Basis von gehaltenen Anteilen an allen verfügbaren Coins statt und unterliegt nicht dem Wettlauf ein definiertes Rätsel am schnellsten zu lösen, wie es beim PoW der Fall ist. Ein weiterer Unterschied liegt darin, dass Miner in einem PoW zunächst keine Token besitzen müssen, sondern nur die Hardware zum Minen notwendig ist. In einem PoS-System müssen die Teilnehmer eine gewisse Anzahl an Token der insgesamt verfügbaren Tokens besitzen, um überhaupt am System teilnehmen zu können. Da kein Rätsel gelöst werden muss, gibt es im PoS auch keine direkte Belohnung für die Erstellung eines Blocks. Damit sich nun die Knotenbetreiber trotzdem an dem KonsensMechanismus beteiligen, muss ein gewisser monetärer Anreiz geschaffen werden. Daher wird in einem PoS-System für das Validieren und die Konsensbildung eine Transaktionsgebühr aufgerufen, die der jeweilige Validierer der Transaktion einbehalten darf. Damit hat er einen Anreiz, Transaktionen zu verifizieren. Implementiert wird das Verfahren meistens in Form eines Pools von Validierern, an dem jeder teilnehmen kann, der ein Token der Blockchain in seinem „Geldbeutel“ hat und diesen oder mehr als Einlage für das Validieren bereitstellt. Die Einlage entspricht sozusagen einer

22

S. Schacht

Kaution, die hinterlegt wird, um zu gewährleisten, dass man akkurat validiert. Wenn der Validierer sich betrügerisch verhält und entdeckt wird, wird seine Kaution eingezogen und er muss diesen Verlust hinnehmen. Zur eigentlichen Erstellung und Validierung eines Blocks wird aus dem Pool der Validierer zufällig einer ausgewählt, wobei die Höhe der eingelegten Token die Wahrscheinlichkeit, als Validierer ausgewählt zu werden, erhöht. Der PoS-Algorithmus ist also eigentlich ein Kautionssystem [18]. Die hinterlegten Tokens, die jeder als Sicherheit einlegen kann, werden Stake genannt. Eine reine Fokussierung auf die Anzahl der Token, die ein Validierer besitzt, führt zu dem Problem, dass die Entscheidungsmacht, ob eine Transaktion korrekt ist und in die Blockchain eingefügt werden darf, auf wenige Teilnehmer des Gesamtnetzes beschränkt wird. Damit das nicht passiert, werden unterschiedliche Ansätze zur Auswahl der Erzeuger eines neuen Blocks eingesetzt. Zum Beispiel „Randomized Block Selection“, bei dem der Validierer durch eine Kombination aus niedrigstem Hash-Wert und Anzahl der gehaltenen Token berechnet wird. Oder ein Verfahren, das auf dem Alter der gehaltenen Token basiert: „Coin age-based selection“. Ersteres wird von den Kryptowährungen Neo und BlackCoin angewandt, Zweiteres von der Kryptowährung PeerCoin [16]. Leo Bach, Branko Mihaljevic und Martin Zagar zeigen in ihrem Paper „Comparative Analysis of Blockchain Consensus Algorithms“ die praktische Implementierung des Proofof-Stakes-Algorithmus bei drei Kryptowährungen auf. Bei PeerCoin – eine der ersten Implementierungen des PoS – wurde ein hybrider Ansatz zwischen PoW und PoS gewählt. Für die erstmalige Erzeugung der Coins, wie hier die Token genannt werden, wird das PoWVerfahren angewandt, während nach Erreichen der maximalen Coins auf das PoS-Verfahren umgestellt wird. Ergänzend wird die Anzahl der Tage, die ein Coin bei einem Teilnehmer gehalten wurde, mit in die Betrachtung des Stakes einbezogen [7]. Hierfür wird die Anzahl der gehaltenen Tage mit der Anzahl der Coins multipliziert und das Ergebnis als Bewertungsmaßstab für einen Stake herangezogen. Werden die Coins in einer Transaktion weitertransferiert, wird das Alter des Coins auf null gesetzt. Im Gegensatz zum Proof-ofWork-Algorithmus, bei dem die längste Kette mit der meisten investierten Rechenleistung als die gültige Blockchain gilt, wird beim Proof-of-Stake-Algorithmus die Kette als gültig betrachtet, bei der am meisten Coin-Tage verkonsumiert werden. In dem Whitepaper „BlackCoin’s Proof-of-Stake Protocol v2“ von Pavel Vasin wird die Funktionsweise des Verfahrens von PeerCoin gemäß folgender Formel erklärt [92]: pr oo f hash < coins ∗ age ∗ target

(2.6)

Der Proof-Hash wird in einer nicht öffentlichen Berechnung aus einem Stake-Modifikator, den nicht ausgegebenen Coins und der Anzahl der Tage, die die Coins schon gehalten werden, erstellt. Möchte nun ein Teilnehmer einen Block generieren, kann er dies nur, wenn das Produkt aus Coins, Tage, wie lange die Coins gehalten wurden und einem vorgegeben Target-Wert größer ist als der Proof-Hash. Der vorgegebene Target-Wert entspricht der Difficulty aus dem Proof-of-Work-Algorithmus und dient dazu, dem potenziellen Validierer

2 Die Blockchain-Technologie

23

eine Mindestzahl an Coins vorzugeben, die notwendig sind, damit er als Validierer ausgewählt wird. Sind die Voraussetzungen erfüllt, muss der Validierer seine Coins als Stake an sich selbst überweisen und setzt damit das Alter der eingesetzten Coins zurück. So ist gewährleistet, dass nicht immer derselbe Validierer zum Zuge kommt [7, 92]. In der Weiterentwicklung des PoS-Stake-Protokolls von Blackcoin wurden einige Nachteile des Protokolls von PeerCoin durch das Entfernen des Alters der einzusetzenden Coins optimiert. Nachteilig am Alter ist nämlich, dass es einen Anreiz schafft, bestimmte Knoten nur ab und zu online in das Netz zu hängen und dies nur zu dem Zweck, dass man die Belohnung für die Erzeugung eines Blocks bekommt. Durch das Entfernen des Alters zwingt man alle beteiligten Knoten, immer online zu sein und am Netz teilzunehmen, aber auf Kosten der Gleichbehandlung der Teilnehmer, da nun Teilnehmer mit vielen Coins auch mehr Macht bekommen [92]. Die wesentlichen Eigenschaften des Proof-of-Stake Algorithmus sind [95]: • Kann sowohl für öffentliche freie als auch mittels Zugriffschutz gesicherte Blockchains verwendet werden. • Es werden – anders als beim PoW-Verfahren – durch das Mining keine neuen Token erstellt. Alle Token müssen schon von Anfang an vorhanden sein bzw. in Form eines hybriden Verfahrens zunächst mittels Proof-of-Work verdient werden. • Belohnung besteht in der Höhe aus den einbehaltenen Transaktionskosten, der für diesen Block selektierten Transaktionen. • Das Protokoll an sich ist fair, da die Wahrscheinlichkeit, ausgewählt zu werden, direkt proportional zu den Anteilen ist, die im Konto geführt werden. Vorteilhaft am PoS ist vor allem der geringe Energiebedarf durch den Wegfall des kryptografischen Rätsels. Nachteilig ist, dass vor allem diejenigen Stakeholder belohnt werden, die bereits einen großen Anteil an Token halten. Dieser Nachteil wird durch die Haltedauer bzw. das zufällige Auswählen von einzelnen Validierern zwar abgeschwächt, aber dennoch haben die Teilnehmer, die viele Token besitzen und diese länger halten auch eine höhere Wahrscheinlichkeit, ausgewählt zu werden. „51 %-Attacken“ 2 , wie sie beim Proof-of-WorkSystem durch die Ansammlung enormer Rechenleistung möglich wären, kann es auch beim PoS-Algorithmus geben, wobei hier 51 % aller im Umlauf befindlichen Token als Einsatz dienen, was wiederum sehr teuer und somit unwahrscheinlich ist, da der Angreifer nicht nur eine enorme Menge an Investitionen tätigen müsste, bevor er die Blockchain manipulieren kann. Außerdem würde durch ein Aufdecken der Manipulation der Wert der zugrunde liegenden Kryptowährung stark sinken. Der sehr hohe Investitionsaufwand und das Risiko des Wertverlustes machen die Wahrscheinlichkeit einer solchen Attacke sehr gering.

2 51 % Attacken können immer dann durchgeführt werden, wenn mehr als 50 % der Rechenleistung

oder der verfügbaren Token auf eine Person vereinigt ist. Hierdurch kann diese eine Person, die Blockchain komplett kontrollieren.

24

S. Schacht

Gerade bei öffentlichen Blockchains, bei denen viele Teilnehmer unbekannterweise miteinander interagieren, bietet sich das PoS-Verfahren an. Neben dem klassischen Verfahren des Proof-of-Stake gibt es mittlerweile auch einige Derivate, die die Auswahl der Validierer weiter optimieren. Hier ist vor allem das Delegated-Proof-of-Stake-Verfahren (dPoS) zu nennen, bei dem zunächst einmal alle Teilnehmer, die Tokens für das dPoS-Verfahren einsetzen wollen, eine Anzahl von Zeugen für die Blockerzeugung und Validierung in Form einer demokratischen Wahl wählen. Jeder dieser gewählten Zeugen hat nun das Recht, einen Block innerhalb dieser Runde zu erzeugen. Nach jeder Runde werden die ausgewählten Zeugen wieder neu gewählt. Jeder Zeuge bekommt eine Belohnung für die Erzeugung des Blocks [7]. Practical Byzantine-Fault-Tolerance Wenn die Teilnehmer im Netzwerk bekannt sind, aber trotzdem die Möglichkeit byzantinischen Verhaltens besteht, bietet sich der Practical Byzantine-Fault-Tolerance-Algorithmus (PBFT) an. Der PBFT gehört zu den Voting-Based-Algorithmen, bei denen die Validierung und Verifizierung der Transaktionen nicht durch einen Beweis der Vertrauenswürdigkeit, sondern mittels eines Abstimmungsverfahrens getroffen wird. Wie in der Einführung dargestellt, handelt es sich bei einem byzantinischen Fehler um einen Fehler, bei dem die teilnehmenden Knoten technisch einwandfrei arbeiten, der Inhalt der Nachrichten aber inkonsistent ist und manipuliert sein könnte. Dieses Problem kann nur gelöst werden, wenn eine höhere Anzahl an Knoten im Netz vorhanden ist als Fehler, da sonst die bösartigen Knoten, die gutartigen Unterlaufen und somit nicht mehr entdeckt werden könnten. Eine mathematische Herleitung dieses Problems führt zur nachstehenden Formel, mittels der die Anzahl der notwendigen Knoten im gesamten Netz unter der Annahme einer zu erwartenden Anzahl an bösartigen Knoten ermittelt werden kann [60]: n >3∗ f +1 n Anzahl der Knoten insgesamt f Anzahl von b¨osartigen Knoten

(2.7)

Das Problem ist auch als Replicated-State-Machine-Problem bekannt, in dem einzelne Maschinen sogenannte State-Variablen besitzen, die den Zustand des Knotens beschreiben und nur Operationen vom Typ Lesen und Schreiben ausführen können. Der Zustand der einzelnen Maschinen wird über alle beteiligten Maschinen synchronisiert, wobei einzelne Maschinen sich betrügerisch verhalten und einen anderen Status speichern und verteilen, als sie tatsächlich haben. Ziel ist es, alle Maschinen in den gleichen Status zu bringen, sodass sie konsistent sind, und zwar unter dem Gesichtspunkt der Effizienz in Bezug auf die notwendigen Kommunikationswege [60]. In einem System mit sehr vielen Knoten kommen ergänzend zu der benötigten Anzahl der Kommunikationskanäle noch weitere Schwierigkeiten. So kann es zum Beispiel vorkommen, dass in einem verteilten System die zugrunde liegenden Netzwerkstränge nicht zuverlässig arbeiten oder Nachrichten zwischen den Knoten zeitversetzt, gar nicht oder

2 Die Blockchain-Technologie

25

nicht in der gesendeten Reihenfolge übermittelt werden. Gegebenenfalls werden Nachrichten von einzelnen Teilnehmern auch mehrfach übermittelt. All diese Probleme gilt es zu berücksichtigen, um einen einheitlichen Status im Gesamtsystem zu erreichen [60]. Wie funktioniert nun der Algorithmus im Detail? Vereinfacht ausgedrückt müssen alle Teilnehmer im Netz einem gesendeten Status zustimmen. Wenn die Mehrheit der Knoten dem Status zustimmt, bzw. ihn bestätigt, gilt der Status als der aktuelle des gesamten Netzwerks. Bezogen auf Transaktionen in einer Blockchain bedeutet dies, dass alle beteiligten Knoten über die Richtigkeit der Transaktion – also dem Status aus dem Beispiel der Replicated-State-Machine – abstimmen müssen. Alle Knoten kommunizieren miteinander, wobei für eine Transaktionsverifizierung ein Knoten die Führung übernimmt. Dieser Knoten ist der Prime-Node, während die anderen die Replicas oder auch Backup-Knoten des Prime-Knoten darstellen [37]. Die Knoten müssen zwei Bedingungen erfüllen: Sie müssen deterministisch sein, das heißt, ihr Verhalten ist nicht zufällig und ein gegebener Input ergibt immer den gleichen Output. Und alle Knoten, die sich normal, also nicht betrügerisch, verhalten, müssen mit dem gleichen Status starten [60]. Der Ablauf des Prozesses lässt sich in fünf Schritte untergliedern, wobei die drei mittleren Schritte das eigentliche Protokoll darstellen, während die beiden Äußeren zur Initiierung und zum Abschluss des Prozesses herangezogen werden [95]. Request, Pre-prepare, Prepare, Commit und Reply (Abb. 2.6): Ein Client sendet eine Anfrage zur Durchführung und Verifizierung einer Transaktion an den Primary-Node. Dieser verteilt nun in der Phase „Pre-Prepare“ die Transaktion an alle Backup-Knoten innerhalb des Netzwerks. Die Backup-Knoten senden nun ihren Status über die Richtigkeit der Transaktion an alle Knoten innerhalb der „Prepare“-Phase, damit die einzelnen Knoten die Nachrichten untereinander abgleichen können. In der „Commit“-Phase senden alle Knoten dem Client ihre Meinung zur Transaktion. Der Client selber wartet auf

Abb. 2.6 PBFT Konsens – Ablauf. (In Anlehnung an [23, 73])

26

S. Schacht

f+1 Antworten, bis er die Ergebnisse als richtig definiert, wobei wie in der oben aufgeführten Formel f als Anzahl der Fehler im Netzwerk definiert ist [60]. In unserem Beispiel würde der Client auf mindestens zwei Antworten warten, da der dritte Knoten betrügerisch handelt, also genau ein Fehler f im Netzwerk existiert. Erhält der Client in einer vorgegebenen Zeit nicht genügend oder gar keine Antworten, verteilt er die Transaktion nicht nur an den Primary-Node, sondern gleich an alle BackupKnoten im Netzwerk. Hat der jeweilige Backup-Knoten die Nachricht schon verarbeitet, schickt er nur sein ursprüngliches Ergebnis an den Client zurück. So kann aufgedeckt werden, ob der Primary-Node betrügerisch handelt: Wenn die Nachricht nicht an die anderen Teilnehmer versendet wurde, befragt der Client auf Grund mangelnder Antworten die Backup-Knoten direkt und wenn bei der Verifizierung die Mehrheit der Knoten zu einem anderen Ergebnis kommt als der Primary Node, würde auch eine solche Manipulation aufgedeckt. In beiden Fällen verliert der Primary-Knoten seinen Status als Lead und ein anderer Knoten fungiert zukünftig als Primary-Node. Anhand des Schaubildes wird auch ersichtlich, dass der PBFT einen gewissen Nachteil aufweist, nämlich die große Menge an notwendigen Nachrichten, die über den gesamten Prozess gesendet werden müssen. Scheffield Nolan hat in seinem Beitrag „pBFT – Understanding the Consensus Algorithm“ die Berechnung der für jede Phase minimal notwendigen Nachrichten dargestellt [73]. Bezogen auf unser Beispiel sind folgende Werte zu berechnen, um den betrügerischen Knoten zu entdecken: • • • • •

Phase 1 – Request : 1 Nachricht Phase 2 – Pre-Prepare: 3 ∗ f = 3 ∗ 1 = 3 Nachrichten Phase 3 – Prepare: 3 ∗ f ∗ (3 ∗ f − f ) = 6 Nachrichten Phase 4 – Commit: (3 ∗ f − f + 1) ∗ (3 ∗ f + 1) = 12 Nachrichten Phase 5 – Reply: (3 ∗ f − 1) = 2 Nachrichten

In Summe ergeben sich 23 Nachrichten, die im Netz versendet werden müssen. Wenn wir von zwei möglichen Fehlern ausgehen, dann sind sogar schon sieben Knoten notwendig und die minimale Nachrichtenanzahl erhöht sich auf 71, um die betrügerischen Knoten zu eliminieren [73]. Es wird deutlich, dass diese Art des Konsens-Algorithmus nicht sehr gut skaliert und deswegen in öffentlichen Blockchains mit sehr vielen Knoten nicht effizient funktionieren kann. Auch müssen für die Wahl eines Knotens als Primary-Node die Teilnehmer im Netzwerk bekannt sein. In einzelnen Texten wird auch aufgeführt, dass durch die Wahl des Primary-Node eine gewisse Zentralisierung im Netzwerk besteht und damit nicht von einer vollständig dezentralisierten Blockchain gesprochen werden kann [95]. Der Algorithmus bietet aber auch Vorteile: Da kein Rätsel gelöst werden muss, kann die Anfrage schnell beantwortet werden. Dadurch bietet der PBFT im Gegensatz zu den auf

2 Die Blockchain-Technologie

27

einen Beweis basierenden Algorithmen eine hohe Transaktionsverarbeitungsgeschwindigkeit. Des Weiteren ermöglicht der PBFT die asynchrone Übermittlung und Verifizierung von Transaktionen auf Basis des Voting-Systems. Das spart Rechenleistung und macht den PBFT zu einem effizienten Algorithmus. Diese Effizienz wird allerdings durch die Aufgabe der Anonymität der Knoten erkauft, weshalb der PBFT wie schon erwähnt eher im geschlossenen Netzen anzutreffen ist als in öffentlichen. Der Practical-Byzantine-Fault-Tolerance-Algorithmus wird in der permissioned Blockchain Hyperledger Fabric aber auch in der Kryptowährung Ripple und in abgewandelter Form in der Kryptowährung Stellar verwendet [24, 65, 95]. Überblick über Proof-Based- und Voting-Based-Algorithmen Tab. 2.1 zeigt eine Gegenüberstellung zwischen beweisführenden und auf einem Votingsystem basierenden Algorithmen. Zero-Knowledge-Proof Bei den bisher aufgeführten Algorithmen ist es notwendig, dass die Transaktion bzw. der Block für alle Validierer einsehbar ist. Es ist also transparent, welches Konto welche Transaktion mit welchem Inhalt transferiert. Die in den meisten Blockchains propagierte Anonymität ist vielmehr eine Pseudonymisierung, da die Konten keine Klarnamen verwenden. Mit einer Analyse einzelner Accounts, z. B. mittels maschinellem Lernen, ist es aber möglich, diese Pseudonymisierung aufzulösen und somit die Identitäten dahinter offenzulegen.

Tab. 2.1 Proof-Based- und Voting-Based-Algorithmen Kriterium

Auf Proof basierende Algorithmen

Auf Voting basierende Algorithmen

Wie wird Konsens bestimmt

Eine ausreichende Anzahl an Knoten liefert genügend „Proof“

Mehrheit der teilnehmenden Knoten muss zustimmen

Knoten können dem Netzwerk frei beitreten

Ja

Nein

Anzahl der Knoten, die in den Entscheidungsprozess einbezogen werden können

Unbegrenzt

Begrenzt – Wegen Skalierung

Dezentralisierung

Meistens hoch

Niedrig wegen den Primary Nodes

Trust

Vertrauen zwischen den Parteien nicht erforderlich

Vertrauen zwischen den Parteien erforderlich

Identität der Knoten wird verwaltet

Nein

Ja

Belohnung für das Validieren & Ja Verifizieren

Nein

28

S. Schacht

In den 80er-Jahren wurde das Verfahren des Zero-Knowledge-Proof (ZKP) entwickelt, bei dem eine Verifizierung trotz vollständiger Anonymisierung möglich ist. Verfahren auf Basis des ZKP halten immer mehr Einzug in öffentliche wie auch private Blockchains, damit Transaktionen vollständig anonym vorgenommen werden können. Nicht nur Transaktionen, sondern auch andere Bereiche wie zum Beispiel die Verifizierung der Identität bieten sich als Anwendungsfall für das ZKP an. Das ZKP ist ein Verfahren, bei dem eine Partei einer anderen Partei glaubhaft macht, dass sie über ein gewisses Wissen verfügt, ohne das Wissen offenlegen zu müssen. Um diese Funktion näher zu erklären, werden häufig ähnliche Beispiele herangezogen.3 Kostas Chalkias postuliert, dass zwei Freunde – einer farbenblind (Spieler B), der andere nicht (Spieler A) – einen roten und einen grünen, sonst identischen Ball besitzen. Spieler A möchte Spieler B beweisen, dass die beiden Bälle unterschiedlich gefärbt sind, ohne Spieler B zu sagen, welcher Ball welche Farbe hat. Er möchte also sein Wissen nicht mit Spieler B teilen, aber trotzdem den Beweis liefern, dass die Bälle unterscheidbar sind. Spieler B ist skeptisch. Um nun den Beweis antreten zu können, bittet Spieler A den farbenblinden Spieler B, die Bälle hinter seinem Rücken zu vertauschen und Spieler A einen davon zu zeigen. Dann soll Spieler B die Bälle hinter seinem Rücken erneut vertauschen und Spieler A fragen, ob der präsentierte Ball derselbe wie vorher ist. Dieses Prozedere führt Spieler B nun mehrmals durch, z. B. 100 mal. Wenn Spieler A die Bälle tatsächlich unterscheiden kann, dann müsste er mit einer höheren Wahrscheinlichkeit als 50 % die richtige Antwort geben können. Da die Bälle der Farbe nach eindeutig identifiziert werden können, kann Spieler A die Frage, ob die Bälle hinter dem Rücken von Spieler B vertauscht wurden, häufiger als 50 mal richtig beantworten. So beweist Spieler A Spieler B, dass die Bälle unterschiedlich sind. Da Spieler B zwar den Beweis hat, aber niemals das Wissen über die Unterscheidbarkeit der Bälle erlangen wird, liegt hier eindeutig ein Zero-Knowledge-Proof-Prozess vor. Spieler A musste sein Wissen nicht preisgeben, um Spieler B zu überzeugen [52]. Die Parteien, die den Beweis eines Sachverhaltes antreten wollen, werden meist Prover genannt und die Parteien, die überzeugt werden, Verifyer. Um einen ZKP-Algorithmus implementieren zu können, müssen drei wesentliche Voraussetzungen erfüllt werden [6, 93]: • Vollständigkeit • Zuverlässigkeit • Zero-Knowledge

3 Jean-Jacques Quisquater (et al.) verwendet in seinem Artikel „How to Explain Zero-Knowledge

Protocols to Your Children“ auf die Geschichte von Ali Baba und einer geheimnisvollen Höhle zurück [47].

2 Die Blockchain-Technologie

29

„Vollständigkeit“ bedeutet, dass, wenn ein Prover eine Aussage macht und beide Parteien dem gleichen Protokoll korrekt folgen, auch der Verifyer von dem Ergebnis überzeugt sein wird. Unter „Zuverlässigkeit“ im Sinne des ZKP ist zu verstehen, dass, wenn der Prover eine falsche Aussage macht, der Verifyer auch mit ziemlicher Wahrscheinlichkeit von dem Beweis nicht überzeugt sein wird. Zu beachten ist hier, dass nicht nur die hundertprozentige Richtigkeit gilt, da probabilistisch überprüfbare Beweisführungen auf einer häufigen Anzahl an Wiederholungen beruhen und diese so lange durchgeführt werden müssen, bis die Wahrscheinlichkeit des Eintritts sich dem allgemeinen Zufall entweder annähert und damit wahrscheinlich nicht richtig ist, oder sich von der zufälligen Wahrscheinlichkeit deutlich absetzt und damit der Beweis geführt ist. „Zero-Knowledge“ bedeutet, dass der Verifyer nur weiß, dass die Aussage des Provers richtig ist [6, 93]. Das aufgeführte Beispiel zeigt aber auch, dass, um einen solchen Algorithmus zu implementieren, eine gewisse Interaktivität zwischen den Parteien existieren muss, da häufige Abfragen stattfinden, um Gewissheit über die Aussage des Provers zu bekommen. Daher konnte ZKP bisher nicht wirklich in praktischen Anwendungen verwendet werden, da dies einen enormen Kommunikationsaufwand erforderte. Die Weiterentwicklung des ZKP durch das Entfernen der Interaktivität zwischen den Parteien führte zu Non-Interactive Zero-Knowledge-Proof-Algorithmen. Einer davon ist zk-SNARK, der z. B. in der Kryptowährung Zcash zum Einsatz kommt. Vorteil dieser Algorithmen-Klasse ist, dass zwischen Prover und Verifyer keine Interaktivität mehr notwendig ist und damit die Verwendung des ZKP praktikabel wird. Wie erwähnt wird der Algorithmus zk-SNARK in der Kryptowährung Zcash eingesetzt. Das Akronym steht für „Zero-Knowledge Succinct Non-Interactive Argument of Knowledge“ [98]. Mit „Succinct“ ist gemeint, dass der Algorithmus es ermöglicht, den Beweis innerhalb des ZKP-Prozesses in sehr kurzer Zeit – Millisekunden – zu überprüfen, da der Beweis auf wenige Bytes reduziert wird, selbst wenn der ursprüngliche Beweis wesentlich größer ist. Der Unterschied zum klassischen ZKP ist, dass nur eine Prüfnachricht zwischen Prover und Verifyer ausgetauscht wird, was das Protokoll nicht-interaktiv macht [98]. Durch diese Art von Algorithmen wird die Möglichkeit geschaffen, z. B. einen Eigentumsbeweis zu erbringen, ohne sensitive Daten zur Verfügung stellen zu müssen. Die Technik lässt sich zur Steigerung der Privatsphäre in unterschiedlichen Bereichen einsetzen. So können damit Identitäten geprüft werden, ohne dass ein Passwort einer Internetseite bereitgestellt oder bei dem Betreiber der Internetseite gespeichert werden muss [6]. Gerade unter dem Gesichtspunkt der vielen gehackten Internetportale wäre dies ein Gewinn, da selbst wenn eine Seite gehackt werden würde, keine Passwörter dort mehr gespeichert wären. In Bars, die nur dann Alkohol ausschenken dürfen, wenn der Kunde nachweist, dass er volljährig ist, muss bisher der Ausweis vorgezeigt werden. Der Mitarbeiter der Bar hat in dem Moment nicht nur das Geburtsdatum, sondern auch alle anderen Informationen über den Kunden – wie Name, Wohnort usw. Mittels der genannten Algorithmen könnte der Gast

30

S. Schacht

in der Bar nachweisen, dass er alt genug ist, ohne private Informationen über seine Person preiszugeben. Im Bereich von Finanztransaktionen muss der Sender immer nachweisen, dass sein Konto die nötige Deckung für die anstehende Transaktion besitzt, bisher durch Offenlegung des Saldos gegenüber einer Bank oder bei Kryptowährungen durch Offenlegung des gesamten Kontos. Mittels ZKP würde auch das überflüssig [6]. Es ist ersichtlich, dass diese Art von Protokollen ein großes Potenzial hat. Gerade in Blockchains zwischen Firmen, in denen nicht jede Transaktion öffentlich zu sehen sein sollte, könnten diese Protokolle helfen, mehr Akzeptanz für die Blockchain-Technologie zu schaffen. Aufgreifen der Spieltheorie Um noch einmal die Spieltheorie aufzugreifen, muss das Gefangenen-Dilemma erläutert werden, wie es in einem Blogbeitrag von Daniel Krawisz von 2013 kurz dargestellt wird. Zwei Personen werden für ein Verbrechen festgenommen und unabhängig voneinander befragt. Beide haben nun die Möglichkeit, entweder zu dem Sachverhalt zu schweigen oder den jeweils anderen als Täter zu beschuldigen. Schweigen beide, werden beide nicht allzu hart bestraft. Beschuldigt der eine den anderen, bekommt der Beschuldigte eine hohe Strafe und der Andere kommt frei. Beschuldigen sich beide gegenseitig, bekommen beide die höchste Strafe. Dadurch, dass es beiden nicht möglich ist, sich abzustimmen – sodass beide schweigen – wird das sogenannte Nash-Gleichgewicht dahingehend eintreten, dass beide Verdächtigen den jeweils anderen beschuldigen, sodass das denkbar ungünstigste Ergebnis eintritt. Das Gefangenen-Dilemma lässt sich lösen, wenn die Verdächtigen vorher miteinander reden können. Da dies nicht möglich ist, aber das Vertrauen auf den jeweils anderen ebenfalls zu beidseitigem Schweigen führen würde, könnte – wie in den Konsens-Mechanismen – auferlegte Kosten als Beweis für die Kooperation eingeführt werden. Dieser Beweis wird gemäß Daniel Krawisz im Gefangenen-Dilemma so konstruiert, dass ein Beschuldigter dem Staatsanwalt sagt, dass wenn der Andere schuldig sei, er ebenfalls schuldig wäre [53]. So würde sich der Beschuldigte Kosten in Form des Verzichts auf die Möglichkeit, die Tat zu leugnen, aufbürden. Das Gefangenen-Dilemma und andere spieltheoretische Ansätze nehmen Einfluss auf die Art, wie Distributed-Ledger-Technologien aufgebaut sind.

2.3.1.3 Netzwerktypologie Bisher wurden auf Ebene der grundlegenden Prinzipien die Kryptografie, die Spieltheorie und zugrunde liegende Konsens-Algorithmen erklärt. Was nun fehlt, ist die notwendige Netzwerkschicht, die für den Zusammenschluss vieler unabhängiger Knoten über Grenzen hinweg notwendig ist. Auch der Zugriff auf die Netzwerke muss noch ausgeführt werden.

2 Die Blockchain-Technologie

31

P2P-Typologie Alle Blockchain-Technologien greifen bei der Vernetzung der teilnehmenden Rechner auf das Peer-To-Peer (P2P) Protokoll zurück. Bei dem P2P-Protokoll handelt es sich um ein Verfahren, bei dem Rechner untereinander Daten austauschen, ohne dass ein zentraler Server involviert ist. Laut Andrew Oram ist ein Peer-to-Peer-System ein selbstorganisierendes System aus gleichberechtigten, autonomen Peers, das auf die gemeinsame Nutzung verteilter Ressourcen in einer vernetzten Umgebung ausgelegt ist [76] (Abb. 2.7). Gemäß Werle und Steinmetz deckt P2P die drei wichtigsten Anforderungen an zukünftige internetbasierte Applikationen ab. Dies sind Skalierbarkeit, Sicherheit und Zuverlässigkeit und Flexibilität. Skalierbarkeit ist eine wichtige Eigenschaft, da mit zunehmender Nutzerzahl der Applikation zusätzlich Bandbreite, Rechenkapazität und Speicherplatz bereitgestellt werden muss. Die Applikation muss somit abhängig von der Nachfrage dynamisch skalierbar sein [96]. Dies ist mittels eins zentralisierten, monolithischen Systems kaum möglich. Sicherheit und Zuverlässigkeit ist aus zwei Gesichtspunkten wichtig für zukünftige Systeme. Einerseits aufgrund zunehmender Angriffe auf zentralisierte Systeme und andererseits für den Aufbau von Systemen, die den zensurresistenten Abruf und die Speicherung von Daten ermöglichen und dabei die Anonymität sichern. Flexibilität bedeutet für moderne, online-basierte Applikationen eine schnelle und einfache Bereitstellung von neuen Diensten, und zwar mit bestmöglicher Verfügbarkeit [96]. In ihrem Artikel „Peer-to-Peer-Systeme und Anwendungen“ zeigten die beiden Autoren schon 2004 auf, dass die Client-Server-Technologie die Anforderungen moderner internetbasierter Applikationen nicht bedienen kann, da diese mit ihrer Zentralität einerseits zum Ressourcenengpass werden und andererseits anfällig für Angriffe sind [96]. Wesentliche Charakteristika sind die dezentrale Ressourcennutzung und die dezentrale Selbstorganisation. Bei der dezentralen Ressourcennutzung werden Betriebsmittel wie CPU, Speicherplatz, etc. der einzelnen Peers gemeinsam homogen genutzt und somit über den gesamten Verbund verteilt. Bei der dezentralen Selbstorganisation interagieren die einzelnen Peers direkt untereinander und werden nicht von einem zentralen Dienst gesteuert. Sie

Abb. 2.7 Peer-to-Peer. (In Anlehnung an [87])

32

S. Schacht

sind gleichzeitig sowohl Server als auch Clients. Die Selbstorganisation sowie die Ressourcennutzung muss auch dann noch funktionieren, wenn einzelne Knoten im Netz ausfallen, da nicht von einer gleichbleibend guten Verbindung der einzelnen Peers zueinander ausgegangen werden kann [96]. Die einzelnen Peers bieten unter der Selbstorganisation ihre Dienste untereinander eigenständig an. Wehre et al. zeigt die wesentlichen Unterschiede zu einem klassischen ClientServer-System treffend auf, in dem sie darstellen, dass in einer Client-Server-Architektur der Server ein ordnendes Element in der gesamten Architektur darstellt, während bei Peer-toPeer-Netzen eine gleichberechtigte Kooperation zwischen allen Elementen die Basis bildet. Üblicherweise werden P2P-Netzwerke in Form von virtuellen Overlay-Netzwerken über das Internet aufgebaut. Durch die Verwendung von Kommunikationsstrukturen wie das TCP/IP-Protokoll des Internets lassen sich Rechnerverbunde wesentlich schneller und effizienter organisieren [80]. Ergänzend wird über die virtuelle Netzwerkschicht der Suchprozess zwischen den Knoten – also das einfache Auffinden von Peers für neue Teilnehmer im Netzwerk – erleichtert. Der Zusammenschluss der Rechner in einem Overall-Netzwerk wird in Form einer partiellen Mesh-Topologie vorgenommen, bei der jeder Knoten im Netzwerk mit mindestens zwei anderen Knoten verbunden ist. Dies bedeutet, dass jeder Peer mit zufälligen anderen Peers verbunden ist, aber nicht jeder mit jedem. Zwar kann jeder Peer zu jedem beliebigen Peer Kontakt aufnehmen, dies aber zum Teil nur durch die Kommunikation über andere Peers. P2P-Netzwerke werden in strukturierte Netze – bei denen jeder Knoten mit einem anderen Knoten verbunden ist – und unstrukturierte Netze – bei denen die Peers nicht nach einer vorgegebenen Ordnung und auch nicht jeder Peer mit jedem verbunden ist – unterteilt [80]. In unstrukturierten Netzwerken ist jeder Knoten zufällig mit anderen Knoten verbunden, sodass in Summe eine logische Mesh-Topologie erreicht wird. Diese unstrukturierte Verknüpfung ist robust gegen Ausfälle und Angriffe, da durch die zufällige Verbindung kein zentraler Angriffspunkt entsteht und im Netz etliche Redundanzen existieren. In strukturierten P2P-Netzwerken wird die Ordnung, wie die Knoten sich untereinander verbinden sollen und auch, welche Informationen welcher Knoten führt, vorgegeben. Dies hat den Vorteil, dass angefragte Informationen aus dem Netzwerk in einer vordefinierten Zeit geliefert werden können. Strukturierte P2P-Netzwerke werden sehr häufig mithilfe von Distributed Hash Tables (DHT) abgebildet, da diese einen dezentralen Nachschlagedienst ermöglichen, der mittels Key-Value-Einträgen die Information liefert, bei welchem Peer welche Ressource zu finden ist [80]. Ergänzend führt Wehrle noch auf, dass unstrukturierte Netzwerke in zentralisierte P2PNetzwerke, reine P2P-Netzwerke und in hybride P2P-Netzwerke unterteilt werden können. Zentralisierte P2P-Netzwerke verwenden für die Koordination und Verwaltung der Peers fest definierte Koordinationsserver. Bei hybriden P2P-Netzwerken werden mehrere zentrale Server, auch Superknoten genannt, zur Verwaltung dynamisch durch das Netz bestimmt [87].

2 Die Blockchain-Technologie

33

P2P-Netzwerke bilden das Rückgrat der dezentralen Blockchain-Systeme. In öffentlichen Blockchains werden unstrukturierte P2P-Netzwerke verwendet, während in geschlossenen Blockchain-Netzwerken häufig ein hybrider Ansatz gewählt wird. Netzwerkzugriff Wenn sich ein Netz von unabhängigen Knoten zu einem Peer-to-Peer-Netz zusammenschaltet, stellt sich die Frage, wer alles teilnehmen darf. Gerade im Kontext von Blockchains, mit denen Unternehmen ihre Abläufe optimieren wollen, tauchen Fragen über die Zugriffsrechte auf. Um allen Anforderungen gerecht zu werden, wurden unterschiedliche Typen von Blockchains entwickelt. Diese unterscheiden sich zum Einen in der Art des Zugriffes auf das Netzwerk und zum Anderen durch die verwendeten Konsens-Algorithmen. Öffentlicher Zugriff Blockchains, bei denen alle Teilnehmer unabhängig von ihren Rechten vollen Zugriff auf das Netzwerk haben, werden Public Blockchains oder Permissionless Blockchains genannt [80]. Gerade im Umfeld von Kryptowährungen, bei denen der Zugriff frei zugänglich sein muss, bieten sich Public Blockchains an. In der Regel wird die Software zum Betreiben eines Knotens als Open-Source-Software frei zur Verfügung gestellt. Public Blockchains bestehen aus vielen einzelnen Rechnern, die sich über die P2PTechnik unstrukturiert, dezentral und demokratisch formieren. Durch die hohe Anzahl an Knoten kennen sich die einzelnen Teilnehmer nicht mehr gegenseitig, was KonsensProtokolle notwendig macht, die mit dieser großen Zahl an Teilnehmern, bei denen byzantinisches Verhalten möglich ist, umgehen können. Sehr häufig werden hier beweisführende Algorithmen wie Proof-of-Work oder Proof-of-Stake angewandt. In öffentlichen Blockchains wird sehr häufig Skalierbarkeit als ein Thema aufgeführt. Hierbei ist aber nicht Skalierbarkeit in Bezug auf die Anzahl der teilnehmenden Rechner, sondern Skalierbarkeit in Bezug auf die Geschwindigkeit pro Transaktion gemeint. Denn durch den beweisführenden Konsens-Algorithmus müssen mit zunehmender Anzahl an Teilnehmern auch mehr Personen die von einem Miner erstellte und verifizierte Transaktion prüfen und bestätigen. Dies kostet Zeit und führt dementsprechend zu langsamen Transaktionsverarbeitungen [80]. Nichtsdestotrotz hat dieses Design von öffentlichen Blockchains auch enorme Vorteile. Zum einen sind sie aufgrund der großen Zahl von redundant geführten Informationen sehr ausfallsicher und zum anderen sind sie manipulationssicher. Öffentliche Blockchains sind vor allem für transparente Applikationen sinnvoll, bei denen die Datenstruktur vor Änderungen und Manipulationen in einem Netz mit vielen sich nicht vertrauenden Teilnehmern sichergestellt werden soll. Beispiele können die Kryptowährungen sein, aber z. B. auch Track and Trace, wenn eine Produktionskette wie bei Lebensmitteln von den Rohstoffen bis zum Fertigprodukt für Dritte nachvollziehbar und unveränderbar protokolliert werden muss.

34

S. Schacht

Eine treffende Definition für öffentliche Blockchains ist, dass sie von jedem, für jeden und durch jeden betrieben werden. Jeder kann jederzeit das Netzwerk betreten und es wieder verlassen. Alle Informationen des Netzwerks sind öffentlich und gemäß des KonsensAlgorithmus, also den Regeln des Netzwerks, kann jeder Teilnehmer neue Funktionen hinzufügen. Eine Rechtevergabe gibt es nicht. Über die Pseudonymisierung werden Teilnehmer des Netzes verschleiert, können aber aufgrund der Transparenz des Netzwerks mit Aufwand identifiziert werden. Vorteile der Public Blockchains sind die starke Dezentralisierung, der demokratische Aufbau, der mittels eines geeigneten Anreizsystems aufrechterhalten werden kann und natürlich das Fehlen einer zentralen Autorität. Privater Zugriff Im Gegensatz zu den Public Blockchains wird bei privaten Blockchains der Netzwerkzugriff und damit der Zugang ausschließlich von einer Organisation für eine Organisation vorgenommen, externe Teilnehmer gibt es in einer solchen Blockchain nicht. Der Zugang zu privaten Blockchains bzw. Netzwerken wird nur durch einen Netzwerkoperator als Administrator oder durch klar definierte Regeln des Protokolls gewährleistet. Diese Form der Blockchains benötigt ein klar definiertes und implementiertes Rechte- und Zugriffssystem, da nur ausgewählte Teilnehmer Daten in der Blockchain erfassen dürfen bzw. eine Restriktion der Leseberechtigungen für die Teilnehmer existiert. In privaten Blockchains wird kontrolliert, wer dem Netzwerk beitreten darf und wie der Konsens-Mechanismus aussieht bzw. wer diesen betreibt. Durch die Zentralisierung auf eine Organisation könnte der Administrator eines solchen Netzwerks Einfluss auf die Blöcke bzw. Transaktionen der Blockchain nehmen und an diesen Änderungen vornehmen. Private Blockchains agieren gegen die grundlegende Idee, da sie nicht dezentralisiert sind und somit die Hoheit bei einer Person oder Organisation liegt. Es existieren Autoritäten mit unterschiedlicher Stärke. Dadurch, dass bei privaten Blockchains eine Zugriffskontrolle stattfindet und nur vertrauenswürdige Teilnehmer im Netzwerk aktiv sind, findet byzantinisches Verhalten kaum statt. Es handelt sich also um vertrauenswürdige Netzwerke. Private Blockchains benutzen keinen beweisführenden Konsens-Algorithmus wie Proof-of-Work, da das Vertrauen im Netzwerk durch die Zugangskontrolle höher ist und somit dieser kostenintensive KonsensMechanismus nicht zwingend notwendig ist [80]. Trotz aller Nachteile ist es manchmal sinnvoll, statt einer einfachen Datenbank im Unternehmen eine private Blockchain zu verwenden. Gerade bei Anwendungen, bei denen die Nachvollziehbarkeit und die erschwerten Veränderungen von Inhalten ein Thema sind, können private Blockchains ein Anwendungsfeld finden, so z. B. bei revisionssicheren Archiven oder kritischen, dokumentationspflichtigen Sachverhalten, wie z. B. die Zutaten von Lebensmitteln oder Inhaltsstoffe von Arzneimitteln. Damit diese Netzwerke aber nicht genauso wie eine Datenbank geführt werden, sollten die Knoten über unterschiedliche Einheiten

2 Die Blockchain-Technologie

35

des Konzerns verteilt werden, sodass eine Veränderung der Daten innerhalb der Blockchain zusätzlich erschwert wird. Für andere Zwecke als Nachvollziehbarkeit und Unveränderbarkeit bieten sich private Blockchains nicht an. Permissioned bzw. Konsortiumszugriff Eine Kombination aus öffentlichen und privaten Blockchains bilden Konsortiums- und Permissioned Blockchains. Beide Typen sind in ihrer Ausgestaltung sehr ähnlich, wobei Konsortiums-Blockchains einen geringeren zentralen Anteil aufweisen. Bei den Blockchains vom Typ Permissioned müssen die Personen, die am Netzwerk teilnehmen wollen, zunächst verifiziert und auch berechtigt werden. Die Benutzeradministration wird von einer zentralen Instanz vorgenommen und durchbricht somit das Prinzip der öffentlichen Blockchains. Im Gegensatz zu den privaten Blockchains wird aber der Betrieb und damit auch der Inhalt, also das eigentliche Ledger, nicht von einer Autorität kontrolliert, sondern dezentral von allen Beteiligten betrieben. Somit steht jedem Mitglied frei, ob es einen Knoten betreiben will oder nicht. Außerdem besteht die Möglichkeit, einen beispielsweise lesenden Zugriff auf die Blockchain öffentlich zu machen. Dieser Typ der Blockchain ist dezentral und unveränderlich, wird also demokratisch betrieben, aber der Zugang zu dem Netzwerk wird von einem dominanten Partner des Netzwerks geregelt. Sollte der dominante Partner sich gegen das demokratische Netzwerk stellen wollen, muss er nur die Zugriffe derjenigen Teilnehmer sperren, die für ihn unangenehm sind. Um eine solche Bündelung von Macht in einem demokratischen System zu verhindern, wurden die permissioned Blockchains um die Konsortiums-Blockchains erweitert, bei denen nicht eine zentrale Autorität die Verwaltung der Rechte vornimmt, sondern ein Verbund von beteiligten Mitgliedern bzw. Unternehmen. Das Konsortium entscheidet gemeinsam demokratisch über den Zugang zur Blockchain, während der Betrieb in der gleichen Art und Weise geführt wird wie bei permissioned Blockchains. Ergänzend wird meist ein Konsens-Algorithmus gewählt, bei dem der Prozess der Konsensbildung von den Konsortiumsmitgliedern bzw. von Knoten, die die Konsortiumsmitglieder betreiben, vorgenommen wird. Dies hat den Vorteil, dass wesentlich weniger Knoten für die Konsensbildung notwendig sind und diese schneller vorgenommen werden kann. Auch hier kann natürlich das Konsortium andere Mitglieder ausschließen, aber im Gegensatz zu den permissioned Blockchains ist die Macht dazu nicht auf einen Teilnehmer konzentriert, sondern auf mehrere Mitglieder verteilt. Gegenüberstellung Netzwerkzugriffe Eine Statistik von Deloitte zeigt auf, dass ein Großteil der in Unternehmen vertretenen Blockchains vom Typ Konsortium oder Permissioned sind. Die Grafik zeigt aber auch, dass im Jahr 2018 viele Unternehmen private Blockchains betrieben. Aus Sicht des Autors ist das ein wenig verwunderlich, da private Blockchains – wie weiter oben aufgeführt – keinen Mehrwert gegenüber internen Datenbanken liefert. Wahrscheinlicher ist, dass viele Unternehmen

36

S. Schacht

Blockchains vom Typ Privat noch für prototypische Tests bzw. Machbarkeitsanalysen einsetzen und deswegen die Zahl der privaten Blockchains so hoch ist [77] (Abb. 2.8). In Tab. 2.2 ist nochmals zusammenfassend eine synoptische Darstellung zwischen den drei wesentlichen Typen von Netzwerkzugriffen innerhalb von Blockchains zu sehen.

Abb. 2.8 Verteilung der Blockchain-Typen. (In Anlehnung an [77])

Tab. 2.2 Public-, Privat-, Konsortium-Zugriffstypen Public

Privat

Konsortium/Permissioned

Art des Netzwerks

Dezentral

Teilweise dezentral/Nicht dezentral

Teilweise dezentral. Hybrid aus privater und Public Blockchain

Kurzbeschreibung

Jeder kann Teil der Blockchain werden und Daten schreiben oder lesen. Validierung der Daten wird durch die Netzwerkteilnehmer (Nodes) vorgenommen

Wer am Netzwerk teilnehmen oder Daten erfassen oder lesen darf, bestimmt eine zentrale Organisation, der ein hohes Maß an Vertrauen zugesprochen wird. Zentrale Organisation ist gleichzeitig Eigentümer der Blockchain

Wer am Netzwerk teilnehmen oder Daten erfassen oder lesen darf, wird von einem Konsortium der beteiligten Unternehmen bestimmt. Anzahl der Organisationen bestimmen den Grad der Dezentralisierung

(Fortsetzung)

2 Die Blockchain-Technologie

37

Tab. 2.2 (Fortsetzung) Public

Privat

Konsortium/Permissioned

Vorteile

Sicherheit: KonsensMechanismen sorgen für dezentrale Verifizierung der Transaktionen. Transparent: Alle Transaktionen können von allen eingesehen werden. Anonym: Einzelne Individuen nicht direkt erkennbar

Effizient, da die Verifizierung von einem Unternehmen vorgenommen wird

Effizient, da nur wenige Knoten die Verifizierung von Transaktionen vornehmen müssen.Dezentrale Struktur, da nur Konsortium in Summe Einfluss auf das Netzwerk nehmen kann. Keine Konsolidierung der Entscheidungsmacht

Nachteile

Ressourcenaufwändig, da viele Knoten die Transaktionen verifizieren

Kontrolle über die Blockchain und damit über alle Daten (Schreib-, Lese und Änderungszugriff) liegt in der Hand einer Organisation. Schwierig unternehmensübergreifende Use-Cases aufzubauen

Selektionsverfahren der Unternehmen im Konsortium kann Struktur der Blockchain beeinflussen

2.3.2

Ebene 2 „Concept – Base Framework“

In der ersten Ebene, „Principles“, wurde gewissermaßen zusammenhanglos auf die wesentlichen Komponenten der Distributed-Ledger-Technologie eingegangen. In der zweiten Ebene, „Concept Base – Frameworks“, werden mit diesen Komponenten die wesentlichen drei Ausprägungen der Distributed-Ledger-Technologie erläutert. Zu nennen sind hier die Blockchain als erste DLT-Implementierung, Tangle, die vor allem in der Datenstruktur einen anderen Weg einschlägt als die Blockchain und von IOTA genutzt wird, und Hashgraph, der vor allem wegen der Ausführungsgeschwindigkeit eine gewisse Beachtung zuteil wird. Ergänzt werden diese Typen um das Distributed File Storage System IPFS, das zwar nicht direkt eine Distributed-Ledger-Technologie ist, aber sehr häufig in Kombination mit einem der drei genannten Typen eingesetzt wird und deswegen hier nicht unerwähnt bleiben soll. IPFS stellt sozusagen eine Sonderform dar.

2.3.2.1 Blockchain Die Blockchain ist die erste implementierte Distributed-Ledger-Technologie. Sie wurde in dem Paper „Bitcoin: A Peer-to-Peer Electronic Cash System“ von Satoshi Nakamoto im Jahr 2008 entwickelt und bildet die Basis für die Kryptowährung Bitcoin (BTC) [70].

38

S. Schacht

Das Hauptproblem, das mit diesem Paper gelöst werden sollte, war das Double-SpendingProblem in einem nicht durch zentrale Instanzen kontrollierte Peer-to-Peer-Netzwerk. Damit ist gemeint, dass Besitzer eines Kontos in einem Zahlungssystem das vorhandene Geld nicht zweimal ausgeben können. Weiterhin skizziert Nakamoto in dem Paper die wichtigsten Komponenten der Blockchain und zeigt auf, dass dieses System für ein dezentrales Zahlungssystem verwendet werden kann [70]. Zu den wichtigsten Eigenschaften der Blockchain gehören gemäß Nakamoto und Ziyao Liu et al. [61, 70]: • Dezentrales Netzwerk: Jeder Rechner hat die Möglichkeit, an dem Netzwerk teilzunehmen, und Einigungen müssen über alle beteiligten Rechner erzielt werden. • Fälschungssicheres Hauptbuch: Jegliche Änderungen an den Inhalten der Blockchain können aufgrund der verwendeten kryptografischen Methoden von jedem Knoten erkannt werden. Hierdurch ist das Hauptbuch vor Änderungen geschützt. • Transparente Transaktionen: Alle Transaktionen können von allen Knoten zurückverfolgt und nachvollzogen werden. • Vertrauensloser Verbund, aber sicherer Handel zwischen den Parteien: Durch die Verwendung von privaten und öffentlichen Schlüsselpaaren wird sichergestellt, dass nur Sender und Empfänger, für die die Transaktion vorgesehen ist, mit dieser Transaktion etwas anfangen können. Zusammenfassend definiert Liu et al. die Blockchain als dezentrales, fälschungssicheres Hauptbuch. Funktionsweise und Datenmodell Wie funktioniert die Blockchain nun im Detail? Dies soll anhand der Blockchain Bitcoin erklärt werden. Über ein Peer-to-Peer-Netz verbinden sich alle beteiligten Knoten untereinander. Jeder dieser Knoten enthält alle Informationen der gesamten Blockchain. Zu Beginn, also bei erstmaliger Verwendung der Blockchain, wird ein sogenannter Genesis-Block definiert, der später im Text genauer erklärt wird. An diesen Genesis-Block werden alle weiteren Blöcke angehängt. Er stellt den Anfangspunkt einer Blockchain dar und jeder Knoten kennt diesen Block [4]. Angenommen, Person A möchte einen gewissen Betrag ihres Kontos über die Blockchain an Person B transferieren. In zentralen Systemen ist dies kein Problem, da eine Nachricht mit der Information „Person A will Person B den Betrag X schicken“ an die zentrale Instanz, z. B. eine Bank, ausreicht, damit diese erstens die Identitäten der Beteiligten und zweitens die Legitimation für die Überweisung überprüft. Sind beide Prüfungen positiv, führt die zentrale Instanz die Transaktion aus, zieht also dem Konto der Person A den entsprechenden Betrag ab und fügt diesen dem Konto der Person B hinzu. Kontrolle und Sicherheit obliegen somit der zentralen Instanz, der alle Beteiligten vertrauen.

2 Die Blockchain-Technologie

39

Abb. 2.9 Mempool. (In Anlehnung an [69])

Im Blockchain-Netz existiert diese zentrale Instanz nicht mehr und Vertrauen zwischen den Beteiligten ist per se auch nicht vorhanden. Wie funktioniert eine Transaktion in diesem Fall? Auch hier sendet Person A zunächst eine Nachricht mit dem Wunsch des Geldtransfers, z. B. „A möchte einen bitcoin (BTC)4 an B überweisen“. Diese Nachricht wird nun aber nicht mehr an eine zentrale Instanz, sondern an einen der Knoten des Peer-to-Peer-Netzes gesendet. Daraufhin fügt der Knoten die Nachricht in einen sogenannten Mempool ein, der über alle beteiligten Knoten verteilt wird. Wichtig für das Verständnis ist, dass dieser Mempool noch nicht das eigentliche Ledger, also das Hauptbuch, der Blockchain Bitcoin darstellt, sondern eher so etwas wie ein Arbeitspool von noch ausstehenden Transaktionen ist. In diesem Mempool werden die Transaktionen aller Teilnehmer gesammelt, also nicht nur von Person A an B, sondern vielleicht auch Person C an D usw. Ergänzend zu dem eigentlichen Transaktionswunsch wird im Mempool auch ein Zeitstempel mitgeführt, der aufzeigt, wann die Transaktion erfasst wurde. Transaktionen im Mempool haben kein zeitliches Verfallsdatum. Sie bleiben solange in diesem Pool, bis einer der Benutzer sie in einem Block zusammenfasst (Abb. 2.9). So werden alle Transaktionen, die verbucht werden sollen, an möglichst viele benachbarte Knoten des Netzes verteilt. Nun kann jeder Betreiber eines Knotens eine oder mehrere Transaktionen aus dem Mempool nehmen und diese auf ihre Validität überprüfen [69]. Dabei sieht das Protokoll vor, dass einzelne Transaktionen anhand der benötigten Datengröße, der Zeitdauer, die sie schon unbearbeitet im Mempool liegen, und der Anzahl der zu transferierenden bitcoins, also ihrem Wert, priorisiert werden müssen [91]. Die Personen, die die Transaktionen im Bitcoin-Netz auswählen und in Blöcke zusammenfassen, sind die „Miner“ und der Prozess des Validierens wird „Minen“ genannt. Das Bitcoin-Protokoll gibt ergänzend dem Benutzer die Regeln vor, wie er die ausgewählten Transaktionen verifizieren muss. So muss beispielsweise geprüft werden, ob der sendende Benutzer auch wirklich die Menge an bitcoins besitzt, die er an den Empfänger senden möchte. Diese Prüfung führt der Miner 4 Bitcoin mit einem kleinen „b“ geschrieben soll in diesem Text die Währungseinheit darstellen und nicht die Blockchain.

40

S. Schacht

für mehrere Transaktionen durch und bündelt diese Transaktionen in einem eigenen Block [69]. Das Bündeln in einen Block ist sozusagen ein Wettrennen zwischen allen beteiligen Minern des Blocks. Ein Block muss aus sechs Informationen bestehen [4, 90]: • die Versionsnummer des verwendeten Protokolls, • der vorherige Block-Hash, • der Hash-Wert des Merkle-Roots, der ein effizientes Hash-Verfahren aller im Block befindlichen Transaktionen darstellt, • der Zeitstempel, der die ungefähre Erstellungszeit des Blocks darstellt, • die Difficulty • das Nonce, ein für den Proof-of-Work verwendeter Zähler. Abb. 2.10 zeigt den Block 574.236 und dessen wichtigsten Kopfinformationen. Die Auflistung der Transaktionen wird von dem Miner um eine weitere Transaktion am Anfang der Liste ergänzt. Diese erste Transaktion im Block, die Coinbase-Transaktion, hat keinen Absender, aber als Empfänger den Ersteller des Blocks. Es handelt sich hierbei um die Transaktion, die die Belohnung für das Erstellen des Blocks an den Miner transferiert. Für jeden erstellten Block bekommt der Miner 12,5 bitcoins plus die Summe aller Transaktionskosten der in diesem Block zusammengefassten Transaktionen. In Abb. 2.11 die ersten beiden Transaktionen des Blocks 574.236. Die Belohnung für den Miner dieses Blockes besteht aus 12,5 BTC für die Erstellung des Blocks und aus 0,31 BTC bezogen aus der Summe der Transaktionskosten pro Transaktion, die jeder Teilnehmer für seinen Bitcoin-Transfer zahlen muss. Um den Block in der Blockchain speichern zu können und damit auch die Transaktionen durchzuführen, muss der Miner zwei wesentliche Schritte durchführen. Erstens muss aus

Abb. 2.10 Blockkopf [17]

2 Die Blockchain-Technologie

41

Abb. 2.11 Ersten beiden Transaktionen des Blockes 574236 [17]

dem Block, in dem die geprüften Transaktionen gesammelt sind, ein Hash-Wert gebildet werden. Dieser Hash-Wert ist die Basis für die Verkettung der einzelnen Blöcke untereinander und sorgt dafür, dass die Blockchain fälschungssicher bleibt. Zweitens muss der Nachweis geliefert werden, dass der Miner vertrauenswürdig ist und den Block in der Blockchain speichern darf. Wie oben aufgeführt, wird in jedem neuen Block der Blockchain der Hash-Wert des letzten gültigen Blocks als weiteres Datenfeld mit aufgenommen und in die Berechnung des Hash-Werts des neuen Blocks mit einbezogen. Dies führt dazu, dass alle Blöcke in zeitlicher Reihenfolge miteinander verkettet sind und eine Änderung eines einzelnen Blocks in der Kette nicht möglich ist – denn alle anderen Blöcke verändern sich hierdurch nicht und der manipulierte Block fällt sofort auf (Abb. 2.12). Es drängt sich die Frage auf, wie derjenige Miner ausgewählt wird, der letztendlich den Block in die Blockchain schreiben darf, wenn mehrere Miner völlig frei die Transaktionen aus dem Mempool nehmen können. In der Bitcoin-Blockchain regelt das der KonsensMechanismus Proof-of-Work. Es darf also derjenige einen Block speichern, der über einen Arbeitsnachweis zeigt, dass er bereit ist, eine gewisse Last in Form von Rechenleistung auf sich zu nehmen. Umgesetzt wird dieses Verfahren, indem der PoW vorsieht, dass nur Blöcke, bei denen der Hash-Wert mit einer gewissen Anzahl an Nullen beginnt, in die Blockchain gespeichert werden darf. Basierend auf dem Hash-Verfahren ändert sich der Hash-Wert einer Nachricht schon bei der Änderung des kleinsten Zeichens komplett. Es können also

42

S. Schacht

Abb. 2.12 Block-Kette

solange an der Nachricht Zeichen geändert werden, bis ein gewünschter Hash-Wert des Blocks entsteht. An dieser Stelle ist das Feld Nonce wichtig, dass nur eine Zahl enthält. Der Miner benutzt dieses Feld, um den nötigen Hash-Wert „auszuprobieren“. Bei der Erstellung des Blocks wird das Feld Nonce zunächst mit dem Wert 0 besetzt und der Hash-Wert für den ganzen Block ermittelt. Entspricht der Hash-Wert nicht dem durch das Protokoll vorgegebenen Format, erhöht der Miner den Wert im Feld Nonce um eins und vergleicht den Ergebnis-Hash erneut mit der Vorgabe. Dies wird solange durchgeführt, bis der Hash die vorgegebene Anzahl an führenden Nullen aufweist. Wichtig zu verstehen ist, dass es aufgrund der Natur des Hash-Verfahrens (Siehe Abb. 2.13) nicht möglich ist, den nötigen Hash-Wert im Vorfeld zu ermitteln, sondern er nur mittels Ausprobierens (Brute-Force-Task) ermittelt werden kann. Dies kostet Zeit und Rechenleistung. BillyBitco.in vergleicht in seinem Blockbeitrag dieses Suchen mit dem Werfen mehrere Münzen [69]. Ziel ist, dass zwei Münzen bei gleichzeitigem Werfen die Seite mit dem Kopf zeigen. Dies geschieht ergänzend im Wettkampf mit einem Freund. Gewinnen wird derjenige, der es schafft, die Münzen zuerst so zu werfen, dass zwei Köpfe liegen. Die Wahrscheinlichkeit, dass dies passiert, liegt bei einer Münze bei 50 % bei zwei Münzen bei 25 % und bei vier Münzen schon nur noch bei 6,25 %. Bezogen auf Bitcoin muss zum Stand Mai 2019 der Hash eines Blocks schon 18 führende Nullen aufweisen, um gültig zu sein [17]. Damit liegt die Wahrscheinlichkeit, dass ein Miner einen gültigen Hash-Wert findet, schon nur noch bei 0,0000038155 . Da im Bitcoin-Netz die Blöcke mit einer festen Zeitspanne von ca. zehn Minuten erstellt werden müssen, ist es kaum einem Miner möglich, alle möglichen Hash-Werte – immerhin

5 1/218

2 Die Blockchain-Technologie

43

Abb. 2.13 Nonce Berechnung. (In Anlehnung an [69])

6422 – zu durchlaufen6 . Dementsprechend probiert der Miner die Nonce-Zahl nicht systematisch von 0 bis zur gesuchten Zahl durch, sondern wählt zufällige Nonce-Zahlen, in der Hoffnung, dass die richtige Zahl für die Berechnung des passenden Hash dabei ist. Statistisch gesehen werden aufgrund der hohen Anzahl an Minern und des zufälligen Probierens im Mittel aller Miner alle möglichen Kombinationen getestet. Findet nun ein Minder den passenden Block, wird dieser sofort an alle teilnehmenden Knoten verteilt und diese können nun den Block anhand der gegebenen Werte überprüfen. Stimmt der Block bei einer der durch das Protokoll vordefinierten Prüfregeln nicht überein, wird dieser sofort von allen Knoten abgelehnt [91]. Eine weitere Schwierigkeit liegt darin, dass wenn immer mehr Knoten mit größerer Rechenleistung dem Netz beitreten, bei diesen die Suche nach dem passenden Nonce durch die größere Rechenleistung wesentlich schneller durchgeführt wird. Das heißt, dass auf Dauer die benötigte Zeit zur Erstellung eines Blocks sinkt. Da es aber gewünscht ist, dass Blöcke mit einer konstanten Zeitspanne von zehn Minuten erstellt werden7 , muss ein Mechanismus eingebaut werden, der dafür sorgt, dass mit zunehmender Rechenleistung auch die Schwierigkeit, eine passende Nonce zu finden, zunimmt. In dem Proof-of-WorkAlgorithmus des Bitcoin-Netzes wurde dies realisiert, indem alle zwei Wochen bzw. exakt nach der Erstellung von 2016 Blöcken die sogenannte Difficulty im Blockheader entweder nach oben oder nach unten so angepasst wird, dass die Zeit von zehn Minuten für die Erstellung eines Blocks wieder eingehalten werden kann. Steigt die Difficulty, dann sind für die 6 22 da SHA-256 Hashes aus den Zeichen A-F,a-f und 0–9 bestehen und damit jede Stelle 22 ver-

schiedene Zeichen annehmen kann. 7 Die Entscheidung für zehn Minuten ist ein Tradeoff zwischen einzusetzender Bandbreite, mehrer Forks (dazu später mehr) und schnellerer Konfirmation von Transaktionen.

44

S. Schacht

Validierung des Blocks über seinen Hash mehr führende Nullen notwendig, wenn sie sinkt, weniger. Mit zunehmender Rechenleistung im Netz wird es also schwieriger, das korrekte Nonce zu finden, und damit wird auch wesentlich mehr Strom benötigt, um den gleichen Output wie mit niedriger Rechenleistung zu erhalten. Um die Blockchain und deren Mechanismus zu verstehen, ist noch der letzte Aspekt des Erstellens von Blöcken nötig, und zwar die Einbettung des Blocks in die gültige BlockchainKette. Nachdem der Miner den Gewinner-Block an das Netz versendet hat, brechen diejenigen, die ebenfalls gerade an dem Block gearbeitet haben, ihre Suche nach dem passenden Hash ab, gleichen ab, welche Transaktionen in dem Block eingebettet sind und welche sie deswegen aus dem Mempool entfernen müssen und prüfen anhand einer Checkliste, ob der Block den Regeln des Netzwerks entspricht. Zu den Regeln gehört: • Die Datenstruktur des Blocks muss syntaktisch richtig sein. • Der Blockheader-Hash entspricht den Regeln und hat dementsprechend die notwendige Anzahl an führenden Nullen. • Der Zeitstempel des Blocks liegt weniger als zwei Stunden in der Zukunft, um eine zeitliche Fehlertoleranz zu erlauben. • Die Blockgröße entspricht den Vorgaben. • Die erste Transaktion ist die Coinbase-Transaktion. • Alle Transaktionen halten den Prüfregeln für Transaktionen stand. Das unabhängige Validieren von Blöcken durch viele Individuen sorgt dafür, dass Täuschungsversuche schnell entdeckt werden, und stellt somit die Integrität für das Netz dar. Es ist ersichtlich, dass der Aufbau des Blocks und die Berechnung der einzelnen Hashes ein Invest für den Miner in Form von Zeit und Strom darstellen. Der Prozess des unabhängigen Validierens als Schlüsselkomponente für den dezentralen Konsens sorgt dafür, dass der Miner sein Invest beim Schummeln verlieren würde und somit der Anreiz hierfür geringer ist [4]. Die bisherige Erläuterung zeigt auf, dass das Protokoll eine lineare Kette von Blöcken erzeugt. In einem dezentralen Netzwerk von vielen unabhängigen Knoten kann es aber vorkommen, dass gleiche Blöcke von unterschiedlichen Minern nahezu zur gleichen Zeit erzeugt werden und somit keine lineare Kette von Blöcke vorhanden ist, sondern eher eine Art von Baum mit Verästelungen. Innerhalb des Bitcoin-Netzes existieren drei verschiedene Arten von Blöcken. Blöcke, die direkt mit der Haupt-Chain verbunden sind, Blöcke, die als sekundäre Chain wie bei einer Verästelung aus der Haupt-Chain herauswachsen und verwaiste Blöcke, die nicht in die Blockchain eingehängt werden können.

2 Die Blockchain-Technologie

45

Abb. 2.14 Verästelung der Hauptchain

Empfängt nun ein Knoten einen validen Block, versucht er diesen mittels des eingetragenen Hash des Vorgängerblocks an den Block mit dem gleichen Hash-Wert anzuhängen. Normalerweise ist dies das Ende der Haupt-Chain. Es kann nun passieren, dass ein Block später bei einem Knoten ankommt, während ein Block mit gleicher Blocknummer viel früher in die Blockchain eingehängt wurde. In Abb. 2.14 kommt zunächst Block 2 bei einem Knoten an, dann Block 3. Der Betreiber des Knotens hängt nun Block 2 an Block 1 und Block 3 an Block 2. Wenn aber Block 2 von einem anderen Miner ebenfalls ankommt, dann würde der Knoten diesen Block in einer sekundären Chain dem Block 1 in Form einer Abzweigung mit anhängen. Der Knoten beobachtet nun das Wachstum der unterschiedlich langen Ketten. Am Ende wird die längste Kette überleben, da die meiste Proof-of-Work-Arbeitsleistung in die Kette eingebracht wurde [4]. Ein Block, der bei einem Knoten ankommt und einen Vorgänger-Hash besitzt, der keinem vorherigen Block zuzuordnen ist, wird zunächst als verwaister Block in einem separaten Verzeichnis geführt. Wahrscheinlich ist, dass dieser Block schneller bei diesem Knoten ankam als sein Vorgänger und deswegen noch nicht eingehängt werden konnte. Erscheint der passende Block, wird der verwaiste Block aus dem Verzeichnis einfach an die Kette angehängt. Anhand der Definition, dass alle Knoten diejenige Kette als Master-Chain anerkennen, die die kumulativ meist geleistete Arbeit besitzt, erreichen auf Dauer alle Knoten im Netz Konsens darüber, welche die Master-Chain ist. In der Regel ist es in der Blockchain so, dass viele Verästelungen vorkommen können. Zwei oder mehr lange sekundäre Chains sind eher unwahrscheinlich, da hier das ZehnMinuten-Zeitintervall für die Erstellung von Blöcken hilft, schnell eine längere Haupt-Chain aufzubauen. Diese fest definierte Zeitspanne ist ein Kompromiss zwischen Transaktionsgeschwindigkeit und der Wahrscheinlichkeit einer stärkeren Verästelung. Kurze Blockerstellungszeiten würden mehr sekundäre Chains erzeugen, während längere die Anzahl der Kollisionen verringern aber hierdurch auch die Transaktionsgeschwindigkeit verlangsamen [4]. Zusammenfassend lässt sich der Ablauf der Blockchain anhand des nachstehenden Abbildes darstellen (Abb. 2.15).

46

S. Schacht

Abb. 2.15 Workflow Blockerstellung Bitcoin. (In Anlehnung an [91])

Signieren von Transaktionen mittels der asymmetrischen Verschlüsselung Bisher wurden der Ablauf der Validierung und die Verteilung und Speicherung im Blockchain-Netz betrachtet. In dem aufgeführten Beispiel der Überweisung von Person A an Person B wurde zunächst davon ausgegangen, dass Person A und Person B auch wirklich die sind, für die sie sich ausgeben. In einem Netz, in dem sich die Teilnehmer untereinander nicht kennen, ist der Nachweis der Authentizität aber ein wichtiger Aspekt. Wie wird also sichergestellt, dass A wirklich an die gewünschte Person B überweist und nicht an jemanden, der sich als B ausgibt?[69] In öffentlichen Blockchains wird jeder Teilnehmer durch eine Blockchain-Adresse repräsentiert. Es steht aber auch jedem Teilnehmer frei, mehr als eine Adresse zu erstellen und zu verwenden. Eine Bitcoin-Adresse sieht z. B. so aus: 3LEvkBTqqgyn8w8TnyRqQpvprsAWZGYUht. Für die Erstellung der Adressen wird die asymmetrische Verschlüsselung verwendet. Die Bitcoin-Adresse wird aus dem öffentlichen Schlüssel des Schlüsselpaares abgeleitet. Wie in Unterkapitel 2.3.1.1 beschrieben, kann mittels des öffentlichen Schlüssels der private Schlüssel nicht zurückgerechnet werden. Der private Schlüssel ist also auch der Zugriffsschutz zu dem jeweiligen Bitcoin-Konto [69].

2 Die Blockchain-Technologie

47

Damit die Authentizität der Nachrichten gesichert und nachgewiesen werden kann, wird jede Transaktion digital signiert. In unserem Beispiel wird die Überweisung, die Person A an B senden möchte, von A zunächst mit einem digitalen Fingerabdruck (Hash-Wert) versehen. Der wiederum wird mittels des privaten Schlüssels gesichert, sodass der Fingerabdruck mit dem öffentlichen Schlüssel des Empfängers verifiziert werden kann. A sendet also bei jeder Transaktion zwei weitere Informationen mit [69]: • Transaktion • Digitale Signatur der Transaktion • Public Key des Senders Durch dieses Verfahren haben die Miner die Möglichkeit, jede Transaktion, die aus dem Mempool herausgenommen wird, auf ihre Authentizität zu prüfen, also sicherzustellen, dass der Kontoinhaber wirklich bitcoins transferieren will und sich nicht jemand anderes an dem Konto bedient. Wichtig ist, dass der Zugang zu den Konten nur über den jeweiligen Private Key möglich ist [69]. Execution Model Da in Unterkapitel 2.3.4 ein Vergleich zwischen den unterschiedlichen Blockchains insbesondere im Hinblick auf Konsortiums-Blockchains gezogen wird, ist es wichtig, zu verstehen, wie das Execution Model bei der klassischen Blockchain aussieht, da dies je nach Implementierung anders ausgestaltet sein kann. Die Architektur sieht vor, dass zunächst alle Transaktionen gesammelt, nach Priorisierungskriterien geordnet und in Blöcken zusammen gefasst werden. Erst dann wird über den Konsens-Mechanismus der Block ausgeführt, geprüft und die Blockchain aktualisiert. Diese Architektur wird auch Order-Execute-Model genannt. In diesem Modell wird die Transaktion immer erst dann ausgeführt, wenn der Konsens abgeschlossen ist. Bei einem Proof-of-Work-Mechanismus vergeht hier einige Zeit. Neben dem Order-Execute-Model gibt es noch das Execute-Order-Validate-Model, dass vor allem von der permissioned Blockchain Hyperledger verwendet wird [68]. Vor- und Nachteile Die Vorteile der Blockchain-Technologie liegen vor allem in der Manipulationssicherheit, da Betrugsaktivitäten und das nachträgliche Ändern von Transaktionen erschwert werden, in der Transparenz von Transaktionen, der Stabilität des gesamten Netzes (und damit einhergehenden Ausfallsicherheit, die sich durch die große Menge an redundant gehaltenen Daten ergibt). Auch der Konsens-Mechanismus kann als Vorteil mit aufgeführt werden, da mit ihm eine einfache, aber höchst effiziente Methode geschaffen wurde, sichere Transaktionen zwischen sich nicht bekannten und damit einander nicht vertrauenden Personen auszuführen. Wobei Transaktionen nicht nur für den Transfer von virtuellem Geld verwendet werden können, sondern auch für den Austausch von Werten und die Sicherung immaterieller Vermögensgegenstände [4]. Der Konsens-Mechanismus macht zentrale Verifizierungsinstanzen überflüssig.

48

S. Schacht

Nachteile sind vor allem Transaktionsgeschwindigkeit, hoher Stromverbrauch, Sicherheitslücken, mangelnder Zugriffsschutz (vor allem aus Unternehmenssicht) und das Risiko von Forks. Forks entstehen, wenn eine bestimmte Anzahl an Knotenbetreiber eine andere Software für den Betrieb, als der Rest der Knotenbetreiber verwendet. Auf diese Weise haben alle Betreiber die gleiche historische Blockchain, ab dem Zeitpunkt des Wechsels der Betreibersoftware entwickeln sich aber nun zwei getrennte Blockchains weiter. Es spaltet sich somit ein Teil der Knotenbetreiber von der ursprünglichen Blockchain ab. Diese Abspaltung kann z. B. auf Grund Uneinigkeit zwischen den Minern in Bezug auf die technische Basis des gesamten Netzes entstehen. Die meisten Nachteile sind technischer Natur und werden nach und nach durch neue Technologien bzw. Anpassung der aktuellen Technologie abgebaut. Zum Beispiel führte die Diskussion über den Stromverbrauch bei einigen Blockchains dazu, dass der KonsensMechanismus von Proof-of-Work zu Proof-of-Stake geändert wurde, um den Ressourcenverbrauch zu reduzieren. Forks stellen vor allem aus Sicht der Stabilität ein Risiko dar. So führte die Diskussion über die richtige Blockgröße bei der Bitcoin-Blockchain zu einer Spaltung der Miner, sodass sich zwei Blockchains nebeneinander bildeten: Mit Bitcoin Cash spalteten sich Miner ab, die der Meinung waren, dass ein auf 8 MB vergrößerter Block mehr Transaktionen aufnehmen kann und damit die Transaktionsgeschwindigkeit erhöht wird. Andere Miner bestanden darauf, dass die bis dahin aktuelle Größe von 1 MB mehr als ausreichend und hier keine Änderungen notwendig wären. Für die Blockchain Bitcoin bedeutet dies, dass ein Teil der Miner ab einem gewissen Zeitpunkt eine andere Knoten-Software verwendete als die anderen und sich so ab diesen Zeitpunkt zwei unterschiedliche Blockchains weiterentwickelten, die aber beide dieselbe historische Basis an Transaktionen beinhalteten. Die Transaktionsgeschwindigkeit wird oft als großer Nachteil aufgeführt, da in der Bitcoin Blockchain nur alle zehn Minuten ein Block erzeugt wird, in den nur eine gewisse Anzahl an Transaktionen aufgenommen werden kann. Mit Stand Mai 2019 wurden durchschnittlich 2750 Transaktionen in einem Block zusammengefasst. Ergänzend sind die Transaktionskosten für eine Bitcoin-Transaktion momentan noch relativ hoch, sie beliefen sich im Mai 2019 auf einen Betrag von rund 2,5 US$. Um diesen Problemen entgegenzutreten, wird an drei unterschiedlichen Lösungen gearbeitet. Die schon erwähnten größeren Blöcke, Batching und Zahlungskanäle (Lightning-Protokoll). Beim Batching werden mehrere Transaktionen zu einer zusammengefasst, um den Speicherbedarf zu reduzieren und mehr Transaktionen in einem Block aufzunehmen. Eine solche Zusammenfassung kann aber faktisch nur von Zahlungsprozessoren wie Tausch- und Handelsplattformen vorgenommen werden, die viele Transaktionen verarbeiten [63]. Sicherlich die aussichtsreichste Lösung zur Erhöhung der Transaktionsgeschwindigkeit und zur Reduktion der Transaktionskosten sind die Zahlungskanäle, die im Bitcoin-Netz über das Lightning-Protokoll funktionieren. Bei den Zahlungskanälen handelt es sich um Kontokorrentabwicklungen zwischen zwei Parteien, die Geschäfte miteinander tätigen. In einem Nebenbuch werden alle Zahlungen und Geschäfte untereinander aufgezeichnet, also

2 Die Blockchain-Technologie

49

wenn A bei B kauft und B bei C, usw., und miteinander verrechnet. In der Blockchain wird zu einem festgelegten Zeitpunkt der Saldo der Verrechnung verbucht und nicht mehr jede einzelne Transaktion [63]. Spannend an diesem Ansatz ist, dass ein Zahlungskanal nicht nur zwischen zwei Parteien aufgebaut wird, sondern über mehrere Parteien hinweg gebildet werden kann und somit auch bidirektionale Transaktionen in den Nebenbüchern zwischen zwei Parteien vorgenommen werden können, ohne den dazwischenliegenden Knoten zu vertrauen [4]. Andererseits kann die Implementierung des Lightning-Standards auch dazu führen, dass über das jeweils implementierte Lightning-Protokoll sogenannte Atomic Swaps – Überweisungen zwischen unterschiedlichen Blockchains, wie Bitcoin und Ethereum – vorgenommen werden können, da man in unterschiedlichen Blockchains dieses Protokoll identisch implementieren könnte [36]. Zum Verständnis des Lightning-Protokolls soll an dieser Stelle ein kurzes Beispiel von Andreas Antonopoulos aufgeführt werden (Abb. 2.16):

Abb. 2.16 Funktionsweise Lightning Zahlungsprotokoll. (In Anlehnung an [4])

50

S. Schacht

Alice möchte an Eric eine Zahlung in Höhe von 1 bitcoin überweisen, es besteht aber kein direkter Zahlungskanal zwischen den beiden. Eine Weiterleitung der Zahlung über Bob, Carol und Diana zu Eric macht sie aber dennoch möglich. Hierfür müssen alle Teilnehmer des Rings einen gewissen Betrag an bitcoins in ihrem Lightning-Network-Node halten. Um nun Eric 1 bitcoin zu überweisen, stimmt sich Alice außerhalb der vorhandenen Zahlungskanäle mit Eric über die Transaktion ab, der ihr den Hash-Wert (H) für ein geheimes Secret (R) – eine geheime Zeichenfolge – zukommen lässt. Alice kann nun über die Kette Alice, Bob, Carol und Diana bis zu Eric einen Transfer des BTC initiieren. Dafür baut sie einen Hash Time Lock Contract (HTLC) zwischen sich und Bob auf, in dem vereinbart wird, dass 1 BTC plus Transaktionskosten in Höhe von 0,003 BTC innerhalb einer Zeitspanne von zehn Blöcken an den Hash H transferiert werden soll. Der HTLC ermöglicht es den Teilnehmern, eine Zahlung an einen geheimen Hash zu initiieren und diese Zahlung mit einem Verfallsdatum zu versehen. Eingelöst werden kann dieser Kontrakt von jedem, der das Secret, in unserem Fall das Secret (R) von Eric, kennt. Bob hat nun zehn Blöcke Zeit, das Secret zu bekommen, andernfalls verfällt der HTLC und Alice und Bob stehen genauso da wie vorher. Um an das Secret zu kommen, baut Bob seinerseits ein HTLC über 1 BTC mit Carol auf, gibt ihr aber nur eine Zeitspanne von neun Blöcken und Transaktionskosten von 0,002 BTC vor. Dieser Prozess wiederholt sich, bis ein HTLC zwischen Eric und Diana geschlossen wird. Eric kann nun das Secret (R) an Diana übergeben, die ihren HTLC auslöst und das Secret an Carol übergibt, die ebenfalls ihren HTLC auslöst, usw. Ergebnis dieses Prozedere ist, dass Alice ohne direkten Zahlungsverkehr 1 BTC an Eric transferiert hat. Alle Teilnehmer des Netzwerks mit Ausnahme von Alice und Eric haben hinterher die gleiche Anzahl an BTC plus jeweils 0,001 BTC als Gebühr für das Durchleiten der Transaktion [4]. Der Vorteil eines solchen Lightning-Networks lässt sich in folgenden Punkte zusammenfassen[4]: • Privatsphäre: Zahlungen im Lightning-Nebenbuch sind für die Öffentlichkeit nicht zu sehen. Nur die Salden werden in der öffentlichen Blockchain geführt. Zwar sehen alle Teilnehmer einer Route die Transaktionen, da dies aber immer anhand von Ziel-Hash und Secret vorgenommen wird, sind dem Routingteilnehmer Sender und Empfänger nicht bekannt. • Übertragbarkeit: Gerade in Regionen, in denen Regulationen z. B. durch das Blockieren von Konten vorgenommen werden, bietet das Lightning-Network eine erhöhte Schwierigkeit für das Blockieren der Zahlung, da Sender und Empfänger Secret und Hash für jede Transaktion neu erstellen. • Geschwindigkeit und Kapazität: Die Transaktionsgeschwindigkeit kann mithilfe des Lightning-Protokolls auf Millisekunden statt Minuten reduziert werden. Die Anzahl der Transaktionen spielt keine Rolle, da nicht mehr jede einzelne Transaktion in der Blockchain gespeichert wird. • Granularität: Ein Lightning-Netzwerk erlaubt unabhängig von der Struktur der HauptBlockchain fein granulare Transaktionen und ermöglicht somit Micopayments.

2 Die Blockchain-Technologie

51

2.3.2.2 Tangle bzw. Directed Acyclic Graph Die bisher dargestellte Distributed-Ledger-Technologie Blockchain basiert auf einer linearen Verknüpfung von Blöcken, die über einen Proof-basierten Konsens-Mechanismus validiert und der Blockchain angehängt werden. Neben dieser existieren noch zwei weitere Technologien, die als Distributed-Ledger-Technologien bezeichnet werden können. Eine davon ist IOTA, die auf einer Datenstruktur mit der Bezeichnung Tangle aufbaut, die andere ist Hashgraph, die später erläutert wird. Auf Tangle basierende DLT wurden entwickelt, um die niedrigen Transaktionsgeschwindigkeiten und die durch den Proof-Ansatz notwendigen Gebühren der Transaktionen zu verringern bzw. zu eliminieren. Um dies zu erreichen, setzt Tangle mit dem Directed Acycling Graph (DAG) auf eine komplett andere Datenstruktur als die Blockchain [78]. Ein weiterer Unterschied zur klassischen Blockchain sind die Rollen: Grundsätzlich gibt es in der Blockchain Teilnehmer, die Transaktionen erstellen und Miner, die sie validieren. Das ist im Tangle nicht so, hier sind Transaktionsersteller und Transaktionsvalidierer die gleichen Personen. Die Entwickler von Tangle hatten vor allem das „Internet der Dinge“ (IoT) im Fokus, bei dem erstens sehr viele Transaktionen mit möglichst niedriger Rechenleistung und andererseits niedrige Transaktionskosten für z. B. Mircopayments notwendig sind [40]. Die Verwendung des DAG als Datenstruktur für die Distributed-Ledger-Technologie wird neben IOTA auch von anderen Projekten vorangetrieben. Zu nennen sind hier vor allem die Arbeiten von Sergio Lerner im Projekt DagCoin [57] und von Yonatan Sompolinsky und Aviv Zohar zur Beschleunigung von Bitcoin-Transaktionen [85]. Funktionsweise und Datenmodell Die Datenstruktur Tangle von IOTA basiert auf einem Directed Acycling Graph (DAG), der die einzelnen Elemente nicht in Form einer linearen Kette, sondern in Form von Knoten und Kanten abbildet. So entsteht ein Netz aus verbundenen Transaktionen. Beim DAG darf es keine Zirkelverbindungen, Verbindungen bei denen die Knotenverbindungen wieder auf sich selbst zeigen, geben. Abb. 2.17 zeigt die Unterschiede zwischen den Graph-Typen. Während bei einem Directed Graph die Kanten in beliebiger Reihenfolge aufeinander zeigen dürfen und damit auch

Abb. 2.17 Directed & Directed Acycling Graph

52

S. Schacht

Abb. 2.18 IOTA Datenstruktur. (In Anlehnung an [74])

bidirektionale Verknüpfungen möglich sind, laufen bei einem Directed Acycling Graph die Kanten immer in eine Richtung. Bei Tangle heißt das, dass neue Transaktionen immer in Richtung älterer Transaktionen verweisen und so ein Directed Acycling Graph von Transaktionen aufgebaut wird (Abb. 2.18). Die Transaktionen bilden die Knoten des Directed Acyclic Graph, während die Verbindungen zwischen den Transaktionen durch die Kanten dargestellt werden. Um Verwirrung vorzubeugen: „Knoten“ im Kontext des DAG sind die Transaktionen, die das Netz formen, während Rechner-Knoten bzw. Nodes die verteilten Computer des Gesamtnetzes darstellen, die das Tangle betreiben und Transaktionen in den DAG einspielen können. Bei der Initialisierung des Tangle wird eine Genesis-Transaktion angelegt, auf die später alle anderen Knoten direkt oder indirekt verweisen. Diese Genesis-Transaktion enthält alle Token, die fortan für diese DLT verwendet werden, damit keine neuen Token generiert werden müssen. Somit existiert auch kein Mining [40, 78]. Wenn nun dem Netz eine neue Transaktion hinzugefügt werden soll, dann muss diese am Ende des Graphen eingesetzt werden und auf mindestens zwei andere Transaktionen verweisen8 . Um die Kante, also den Verweis, herstellen zu dürfen, schreibt das Protokoll vor, dass die zwei vorgelagerten Transaktionen, auf die der Tip verweisen möchte, verifiziert werden müssen. Die Transaktionen, die am Ende des Netzes stehen, auf die also noch niemand verweist, werden Tip genannt. Sie sind zwar im Netz schon vorhanden, aber noch unbestätigt. Zu diesen Zeitpunkt kann die Richtigkeit der Transaktion noch nicht gewährleistet werden. Zu beachten ist, dass Transaktion A von Transaktion B entweder durch eine direkte Verbindung oder durch eine indirekte Verbindung, z. B., indem B auf den Knoten Y, dieser wiederum auf X und dieser auf A verweist, validiert werden kann [78]. Der Prozess des Validierens der Transaktionen im gesamten Verbund wird durch die Vorgabe sichergestellt, dass jeder, der eine Transaktion in das Netz einspielen will, bereit 8 Ausnahme von dieser Regel ist der Verweis auf die Genesis-Transaktion.

2 Die Blockchain-Technologie

53

sein muss, zwei ältere zu verifizieren. Hierdurch werden alle Nutzer des Netzes Teil des Validierungsmechanismus und garantieren gemeinsam die Richtigkeit aller Transaktionen. Wenn ein Node eine Transaktion hinzufügen will, die entweder betrügerisch ist oder mit einer anderen Transaktion im Konflikt steht, wird das durch nachfolgende Transaktionen identifiziert und weder direkt noch indirekt verifiziert. Das heißt, dass genauso wie bei der Blockchain Transaktionen, die schon von mehreren anderen Netzteilnehmern validiert wurden, ein größeres Vertrauen auf Richtigkeit genießen als Transaktionen mit wenigen Validierungszyklen. Die Validierungszyklen werden mit sogenannten Gewichten in der Transaktion vermerkt. Durch diese Vernetzung wird es schwierig, Transaktionen, die z. B. doppelt Token verwenden wollen, tatsächlich im System zu speichern [78]. Die Erstellung einer neuen Transaktion läuft wie folgt ab [78, 83]: 1. Ein Rechner-Knoten (Node) möchte eine Transaktion im System erfassen. Hierfür wählt der Node nach einem implementierten Selektionsverfahren zwei andere Transaktionen aus. Ergänzend werden die Transaktionen mittels asymmetrischer Verschlüsselung signiert. 2. Der Node prüft nun, ob die ausgewählten Transaktionen mit anderen Transaktionen im DAG im Konflikt stehen und stellt sicher, dass er keine konfliktbehafteten Transaktionen validiert. Die beiden ausgewählten Transaktion werden in der Transaktionsstruktur von IOTA unter branchTransaction und trunkTransaction abgelegt [46]. 3. Um seine eigene Transaktion nun an die positiv geprüften Transaktionen anzuhängen, muss der Node – ähnlich wie beim PoW – ein kryptografisches Rätsel lösen, in dem mittels einer Zahl (Nonce) ein Hash der Transaktion in vorgegebener Form gefunden werden muss. Im Gegensatz zur klassischen Blockchain, bei der das Signieren der Transaktion mittels eines einmal erzeugten Public- und Private Key vorgenommen wird, wird bei IOTA für jede Transaktion das Schlüsselpaar mittels einer definierten SEED-Nummer mit 81 Zeichen neu generiert. Nur mittels der SEED-Nummer können Konten verwendet und neue Transaktionen erzeugt werden [46, 83]. Tangle ist ein asynchrones Netzwerk von Rechner-Knoten. Nicht alle Nodes müssen zu jeder Zeit alle Transaktionen kennen oder in ihrem Teil des DAGs gespeichert haben. Damit muss nicht jeder Node den kompletten Graph speichern. Die einzelnen Transaktionen werden von den Knoten im Netzwerk immer mit den jeweiligen Nachbarknoten, mit den diese direkt verbunden sind, geteilt und über ein Gossip-Protokoll im P2P-Netzverbund nach und nach über alle Rechner weitergereicht. Unter dem Gossip-Protokoll wird ein Kommunikationsprotokoll verstanden, mittels dem ein Rechnerverbund Daten austauschen kann, ohne eine zentrale Vermittlungsstelle zu besitzen. Der Austausch wird vorgenommen, indem die Nodes die Informationen zu anderen Rechnern und diese wiederum die Informationen weiterleiten [29].

54

S. Schacht

Abb. 2.19 DAG Gewichtung aller Transaktionen. (In Anlehnung an [78])

Die Auswahl der beiden zu verifizierenden Transaktionen (TIP-Selektion) wird mittels eines gewichteten Zufalls-Algorithmus, dem Tip-Selektor, vorgenommen. Eine rein zufällige Auswahl der Transaktionen führt womöglich, wie Florea erklärt, zu einer Fokussierung auf immer die gleichen Transaktionen [31]. Aus diesem Grund wird auf einen MarkovChain-Monte-Carlo-Algorithmus (MCMC) zurückgegriffen. Für die Gewichtung des Zufallslaufs wird die „cumulative weight“ der Transaktion genutzt: Jede Transaktion bekommt einen Gewichtungsfaktor, der steigt, wenn mehr Transaktionen direkt oder indirekt auf diese Transaktion verweisen. Dieser Faktor spiegelt die eingesetzte Arbeit wieder, die ein Rechner-Knoten für die Transaktion eingesetzt hat und entspricht somit dem Proof-of-Work. Transaktionen mit hohem Cumulative-Weight-Faktor sind mit höherer Wahrscheinlichkeit korrekt und somit bedeutsamer für das Gesamtnetz als andere. Abb. 2.19 zeigt beispielhaft die Gewichtung einer Menge an Transaktionen. Die kleine Zahl in der rechten unteren Ecke stellt das eigene Gewicht dar, während die größere Zahl in der oberen linken Ecke die summierten Gewichtungen aller auf diese Transaktion verweisenden Transaktionen zeigt. Transaktion D z. B. besteht aus dem Eigengewicht 1 und den Gewichten der Transaktionen A=1, B=3, C=1, das in Summe ein Cumulative Weight von 6 ergibt. Das gewichtete Zufallsverfahren bei der Auswahl von Tips verhindert die Selektion von immer gleichen Transaktionen, so genannten Lazy Tips. Bei einem völlig zufälligen Verfahren wird kein Anreiz geschaffen, neue Tips zu verifizieren, sondern es könnte zur Strategie „fauler“ Nodes werden, immer die gleichen, alten Transaktionen zu verifizieren, da hierdurch der individuelle Arbeitsaufwand auf Dauer niedriger wird. In Abb. 2.20 ist der Tip 14, der Transaktion 1 und 3 verifiziert, ein Lazy Tip, da er sehr alte Transaktionen verifiziert. Bei einem zufälligen Tip-Selektionsverfahren ist diese Auswahl aber genauso wahrscheinlich wie alle anderen Pfade zur Genesis-Transaktion und

2 Die Blockchain-Technologie

55

Abb. 2.20 IOTA Lazy Tip. (In Anlehnung an [33])

somit wird ein solches Vorgehen nicht bestraft [33]. Um nun eine solche Vorgehensweise zu verhindern, ohne Einfluss auf die Dezentralität des Netzes zu nehmen, wird der zufällige Pfad vom Tip zur Genesis-Transaktion mit Hilfe des kumulierten Gewichtes verzerrt. Wie stark die Verzerrung Einfluss auf den zufälligen Pfad nimmt, definiert der Parameter Alpha. Ein Alphawert von 0 würde einem völlig zufälligen Weg entsprechen, wobei ein sehr hoher Alphawert einem Pfad entspricht, der nicht mehr zufällig ausgewählt wird, sondern der nur noch auf die Gewichte der einzelnen Transaktionen achtet. Eine solche Ausprägung würde dazu führen, dass ein Korridor von verifizierten Transaktionen entsteht, aber Tips, die am Rande des Graphen eingeführt wurden, nicht mehr verifiziert werden und somit nicht relevant sind (Abb. 2.21). Damit die Tangle eine adäquate Verteilung der Tips und Transaktionen erreicht, muss ein passender Wert für Alpha definiert werden [33]. Durch die Verzerrung des zufälligen

Abb. 2.21 Gewichteter Pfad ohne Zufall. (In Anlehnung an [33])

56

S. Schacht

Abb. 2.22 Selection Prozess unter Berücksichtigung des cumulative weights. (In Anlehnung an [33])

Pfads wird sichergestellt, dass Transaktionen, die ein höheres Cumulative Weight haben, mit höherer Wahrscheinlichkeit ausgewählt werden und hierdurch Lazy Tips, die sehr alte Transaktionen verifizieren wollen, unwahrscheinlicher ausgewählt werden (Abb. 2.22). Um Tip 16 verifizieren zu können, muss der Tip Selector an der Stelle 7 den Tip 16 der Transaktion 9 vorziehen. Da aber Transaktion 9 ein Cumulative Weight von 7 gegenüber einem Cumulative Weight von 1 bei Tip 16 besitzt, wird der Selektor auf Basis von Cumulative Weight die Transaktion 9 der Transaktion 16 vorziehen und somit diesen Tipp nicht verifizieren. Das Cumulative Weight von 7 bei der Transaktion 9 ergibt sich durch die Summe der Elemente, die direkt oder indirekt auf die Transaktion 9 verweisen. In diesem Fall sind dies die Transaktionen 10 bis 15. Durch die Gewichtung der Transaktionen wird nun das Lazy-Tips-Verhalten bestraft, da es weniger wahrscheinlich ist, dass dieser Tip 16 verifiziert wird. Bisher sind wir davon ausgegangen, dass die Transaktionen, die im Netz angelegt werden, nicht byzantinisch, also betrügerisch sind. Betrachtet man das Double-Spending-Problem, bei dem ein Account das eigene Geld mehrfach ausgibt, stellt sich die Frage, wie das im Tangle verhindert wird. Wenn Person A zehn Geldeinheiten an B sendet, obwohl A nur fünf Geldeinheiten besitzt, kann A zwar die Transaktion als Tip in die Tangle hängen und zwei andere Transaktionen überprüfen, aber spätestens, wenn eine neue Transaktion z. B. von C im Tangle ergänzt werden soll, müsste C die Transaktion von A als richtig verifizieren. Wenn C das tut, bedeutet das, dass die eigene Transaktion wegen der Ungültigkeit der Transaktion von A nie verifiziert werden wird. C wird also die Transaktion von A nicht verifizieren und damit verwaist die Transaktion von A. Da ein neuer Tip mindestens zwei nicht verifizierte Tips verifizieren muss, werden auf diesem Weg auch alle Transaktionen, die vorher im Netz vorhanden sind, ebenfalls nochmals überprüft [34]. Wenn Person A nun zwei Transaktionen zum Geldtransfer mit jeweils zehn Geldeinheiten an B und C anlegt, A insgesamt aber nur zehn Einheiten besitzt, sieht die Situation

2 Die Blockchain-Technologie

57

anders aus. Jede Transaktion ist für sich gültig, sodass A kein Problem hatte, die Transaktionen anzulegen. Welche Transaktion soll nun der neue Tip-Geber D verifizieren? Hier greift wieder der gewichtete Zufallsweg. Es wird die Transaktion priorisiert, die ein höheres Cumulative Weight hat und damit dem längeren Teilast unterliegt. Die andere Transaktion wird dann aufgegeben und vom Netz ignoriert. Folge dieses Vorgehens ist aber auch, dass keine Transaktion sofort im Netz gespeichert wird, sondern erst nach einer gewissen Anzahl an Verifizierungen als gesichert gilt. Hierfür wird in Tangle die sogenannte Confirmation Confidence eingeführt. Diese Confirmation Confidence wird ermittelt, indem der Tip-Selektions-Algorithmus 100 mal ausgeführt wird. Dabei wird gezählt, wie viele der 100 Tips die betrachtete Transaktion verifizieren. Die Häufigkeit ausgedrückt in Prozent entspricht dann der Confirmation Confidence. Diese entspricht also dem Prozentsatz der Tips, die die Transaktion verifizieren [35]. Eine Transaktion ist nur dann gültig, wenn die Confirmation Confidence einen hohen prozentualen Wert erreicht, z. B. 95 %. Das Verfahren ist stabil, wenn das Netz viele Teilnehmer hat. Bei wenigen Teilnehmern könnte Person A eine Transaktion pushen, wenn sie erstens eine hohe Rechenleistung besitzt und zweitens zusätzlich zu dem betrügerischen Tip noch sehr viele Tips anlegt, nämlich mehr als alle anderen Teilnehmer im Netz. Auf diese Weise kann der Selektor dazu bewegt werden, die betrügerische Transaktion mit einer höheren Confirmation Confidence zu versehen. Um das zu unterbinden, wurde im Tangle zusätzlich zu dem grundsätzlich verteilten Ansatz der Verifizierung über den gewichteten zufälligen Lauf eine Sicherung bei niedriger Netzaktivität eingeführt. Diese Sicherung ist ein Koordinator, der von der IOTA-Foundation betrieben wird und der alle zwei Minuten alle Transaktion bis zu diesem Zeitpunkt prüft und validiert, indem eine Zero-Value-Transaktion „Milestone“ eingefügt wird. Alle Transaktionen, die über den Tip-Selektor ausgewählt wurden und indirekt mit einer „Milestone“-Transaktion referenziert sind, bekommen sofort den Confirmation Confidence Wert 100 % [35]. Durch die Einführung des Koordinators wird die Dezentralität aufgegeben, sodass wir es bei Tangle im Moment mit einem zentral koordinierten Netz zu tun haben. Mit zunehmenden Teilnehmern im Netz soll allerdings auf Dauer der Koordinator abgeschafft und die Validierung über die Masse der Teilnehmer vorgenommen werden. Execution Model Die Architektur des Tangle sieht vor, dass Transaktionen direkt in den Graphen geschrieben und, solange sie nicht verifiziert wurden, als Tips behandelt werden. Die Reihenfolge der Transaktionen wird durch den DAG sichergestellt. Wir haben somit wie bei der Blockchain ein Order-Execute-Modell [68]. Erst wenn alle Transaktionen durch zwei andere oder mehr überprüft wurden, gelten sie als validiert und gültig. Vor- und Nachteile Der DAG und im Speziellen die Implementierung von IOTA unterscheidet sich von klassischen Blockchains vor allem durch das Fehlen von Blöcken und unterschiedlichen Netzwerkrollen. So wird bei IOTA nicht eine Ansammlung von Transaktionen in einem Block

58

S. Schacht

zusammengefasst, sondern jede Transaktion als individuelles Datenelement dem Tangle zunächst in Form eines Tips hinzugefügt. Dieses Vorgehen führt dazu, dass die Latenzzeit, Daten in den DAG von IOTA zu schreiben und auszulesen, im Vergleich zu den klassischen Blockchain-Implementierungen sehr niedrig ist. Ein Vergleich mit der Blockchain Bitcoin zeigt, dass IOTA etwa zehn Millisekunden benötigt, um Daten zu erfassen, während es bei Bitcoin zehn Minuten dauert, bis ein Block in der Blockchain erfasst wird [83]. Diese niedrige Latenz ist vor allem dann relevant, wenn viele gegebenenfalls kleine Transaktionen z. B. im „Internet der Dinge“ dezentral gespeichert und ausgelesen werden sollen. Aber nicht nur die Latenzzeit ist als Vorteil zu nennen, sondern auch die Transaktionsgeschwindigkeit. IOTA verzichtet auf die Unterscheidung zwischen Nutzer und Miner. Jeder, der eine Transaktion im Netz anlegen möchte, muss zwei andere verifizieren. Auf dieses Weise entfallen das Validieren und Verifizieren durch spezielle Netzteilnehmer, was zu einer schnelleren Transaktionszeit führt. Auch herrscht kein Wettbewerb um die Verifizierung einzelner Transaktionen und eine Belohnung als Anreiz für die Validierung einer Transaktion entfällt. Der Anreiz der Validierung einer Transaktion wird alleine darüber geschaffen, dass die eigene Transaktion nur dann im System erfasst werden kann, wenn sich der Ersteller an der Validierung beteiligt. Keine monetäre Belohnung bedeutet zwangsläufig niedrige bzw. nahezu keine Transaktionskosten [83]. Dies ist vorteilhaft, wenn der Anwendungsfall der Distributed-Ledger-Technologie Micro-Payments sind, bei denen Bruchteile von Cent-Beträgen übertragen werden sollen. Aber auch, wenn viele Transaktionen durchgeführt werden sollen, wie eben im „Internet der Dinge“, bietet sich dieses Vorgehen an. Der Verzicht auf unterschiedliche Rollen im Netz hat noch den Nebeneffekt, dass kein Interessenskonflikt zwischen dem Betrieb des Netzwerks und der Validierung von Transaktionen entsteht. Viele Systeme skalieren schlecht. Das heißt, mit zunehmender Anzahl an Teilnehmern und Transaktionen wird die Verarbeitungsgeschwindigkeit langsamer. Bei IOTA ist dies gerade umgekehrt der Fall: Das Netz wird immer performanter, je mehr Transaktionen und Teilnehmer im Netz vorhanden sind. Das liegt daran, dass jede neue Transaktion zwei ältere Transaktionen verifizieren muss. Die Skalierbarkeit in diesem Fall bezieht sich aber nicht nur auf die Geschwindigkeit des Netzes, sondern auch auf die Sicherheit. Je mehr Teilnehmer im Netz vorhanden sind, umso höher ist die Transaktionssicherheit im Tangle [83]. Ein weiterer Vorteil von Tangle ist der niedrige Energiebedarf. In der klassischen Blockchain ist der erhöhte Energiebedarf auf die Notwendigkeit des Proof-of-Work-Ansatzes, also des Arbeitsbeweises für die Validierung, sowie auf den Wettbewerb der Miner um die Erstellung des nächsten Blocks zurückzuführen. Im IOTA-Netz gibt es diesen Wettbewerb nicht, Transaktionen werden von demjenigen durchgeführt, der eine weitere Transaktion in Form eines Tips in Tangle speichern möchte. Der durchzuführende Arbeitsnachweis ist die Verifizierung der Transaktionen vom Genesis-Block bis zum jeweiligen Tip unter Verwendung des Tip-Selektionsverfahrens. Diese Berechnung ist wesentlich weniger energieintensiv als der Proof-of-Work-Ansatz in klassischen Blockchain-Implementierungen.

2 Die Blockchain-Technologie

59

Ergänzend wird neben dem niedrigeren Einsatz von Rechenleistung auch der Netzwerkverkehr reduziert. Da kein kryptografisches Rätsel in Form von „finde mit geeigneter Rechenleistung den passenden Hash“ existiert, ist Tangle quantencomputerresistent. Dies heißt, mit unendlicher Rechenleistung, die ein Quantencomputer gegebenenfalls bietet, besteht trotzdem nicht die Möglichkeit, den Proof auszuhebeln. Bei klassischen Blockchains würde ein Quantencomputer den Aufwand für den PoW so stark reduzieren, dass damit der Anreiz, nicht zu betrügen, nicht mehr gegeben wäre. Neben den Vorteilen existieren im Tangle allerdings auch Nachteile. Wesentlich ist hier die aktuelle Verwendung von Koordinator-Knoten zu nennen. Zwar stabilisieren die Koordinatoren das Netz, sodass nicht ein Teilnehmer den Tangle mit vielen Transaktionen fluten kann, aber gleichzeitig wird mit einem solchen Dienst die Dezentralität des Netzes aufgegeben. Die ordentliche Funktionsweise des Tangles hängt von einem zentralen Service der IOTA-Foundation ab. Positiv zu nennen ist hier die Tatsache, dass die Koordinatoren nur solange im Netz verbleiben sollen, bis genügend Teilnehmer zusammengekommen sind [49]. Eine weitere Restriktion ist die Notwendigkeit des Vorhandenseins des gesamten Tangles für die Validierung einzelner Transaktionen. Diese Restriktion ist deshalb nachteilig, da IOTA Tangle vor allem für den Einsatz im „Internet der Dinge“ entwickelt hat und die Größe des Tangles es kleinen IoT-Geräten nicht ermöglicht, ihn komplett im Device vorzuhalten. Weitere Entwicklungsschritte des Tangles zeigen aber jetzt schon Lösungsmöglichkeiten für das Problem. Zu nennen sind z. B. ein Swarm Client, automatisches Snapshoting oder Flash Channel als zweite Schicht, ähnlich dem Lightning-Protokoll bei der Blockchain, die in späteren Releases implementiert werden.9 In der Literatur finden sich auch immer wieder Kritikpunkte an der Sicherheit des Tangles, da die Sicherheitsmechanismen zwar grundsätzlich diskutiert, aber noch nie mittels einer mathematischen Prüfung nachgewiesen wurden. Aus Sicht der Anwendung ist noch nachteilig zu nennen, dass im IOTA-Netz noch keine Smart Contracts – also ausführbare Programme – möglich sind. Aber auch an dieser Schwäche wird gearbeitet. Mit der zukünftigen Einführung des Qubic-Protokolls soll Tangle auch Smart Contracts und Oracles unterstützen.10

2.3.2.3 Hashgraph Datenmodell und Struktur Auch Hashgraph basiert auf dem einem Directed Acycling Graph. Der Unterschied zu Tangle ist aber, dass nicht einzelne Transaktionen als Elemente miteinander verknüpft werden, sondern Events. Events sind ähnlich wie die Blocks der klassischen Blockchain aufgebaut. Sie beinhalten eine Sammlung von Transaktionen, die in einer gewissen Zeit durchgeführt 9 Auf Grund des Entwicklungsstandes der einzelnen Module werden diese hier nicht weiter ausgeführt. 10 Zum Zeitpunkt des Buches stand noch kein Veröffentlichungstermin für das Protokoll Qubic fest.

60

S. Schacht

Abb. 2.23 Grundstruktur Hashgraph. (In Anlehnung an [10])

wurden, einen Zeitstempel und zwei Hash-Werte, die dazu dienen, zwei Events miteinander zu verbinden [32]. Wie findet nun die Speicherung dieses Events innerhalb des Hashgraph statt? Jeder Teilnehmer entspricht einem Fullnode, also einem Rechner-Knoten, der den stetig wachsenden Hashgraph-DAG vollständig enthält. In Abb. 2.23 sind beispielhaft die vier Nodes A, B, C und D aufgeführt. Die Basis des Protokolls in Hashgraph ist, wie auch bei Tangle oder in der Blockchain, das Gossip-Protokoll, bei dem die Knoten sich über ihre Nachbarn abgleichen und so Events untereinander austauschen. A stimmt sich nun zufällig mit D ab und übermittelt ihm alle Events, die D noch nicht kennt. Dafür muss A mit D nur vergleichen, wie viele Events A von B, C und D kennt. Weicht die Anzahl der Events bei D von der Anzahl bei A ab, muss die Differenz transferiert werden. Wenn A z. B. sechs Events von B kennt und D nur drei, dann muss A die fehlenden drei Events an D übermitteln. Dieser Abgleich wird bei D wiederum in einem eigenen Event gespeichert und über die Speicherung der Hash-Werte beider Events verbunden. Damit ist der Hashgraph die Dokumentation aller Abstimmungsaktivitäten zwischen den Knoten [10]. Neben den Transaktionen beinhaltet ein Event auch einen Zeitstempel, der von D zum Zeitpunkt der Erstellung des Events gespeichert wird und die digitale Signatur von D. Das signierte Event wird von D wieder an A zurückgeschickt, der ebenfalls ein Event dafür

2 Die Blockchain-Technologie

61

anlegt. In Anschluss wählt dann A zufällig B aus und wiederholt dieses Verfahren mit B. Da dies nicht nur A, sondern auch die anderen Nodes im Netz so durchführen, entsteht ein Directed Acycling Graph, der über die Zeitachse wächst, bis jeder Knoten des gesamten Netzes auf dem gleichen Stand von Events ist. Ähnlich wie bei der Blockchain sind gespeicherte Events wegen der Verbindung zwischen dem Event und seiner Vorgänger durch die Verknüpfung über die Hash-Werte und die Signatur des Erstellers unveränderbar [10]. Jeder Teilnehmer hat also einen Graphen, der den kompletten Kommunikationsfluss zwischen den Knoten aus seiner Sicht enthält. Dieser Blickwinkel auf den Graphen wird wiederum an alle Teilnehmer verteilt. Hierdurch wird gewährleistet, dass jeder Teilnehmer im Netzwerk den gleichen Gesamt-Graphen sieht. Dieses Verfahren wird als Gossip-about-Gossip bezeichnet, da nicht nur die Nachrichten mittels Gossip-Protokoll verteilt werden, sondern auch das Ergebnis des zuvor stattgefundenen Gossip-Laufs [11]. Bisher wurde der Hashgraph aufgebaut, indem alle Knoten A, B, C, D über alle Transaktionen und Events informiert und auf den gleichen Stand gebracht wurden. Ein Konsens über den Inhalt der Events hat noch nicht stattgefunden. Der Konsensmechanismus für Hashgraph basiert auf einem Asynchronous-Byzantine-Fault-Toleranzmechanismus. Das heißt, eine gewisse Anzahl Knoten stimmt über den Inhalt der Transaktionen ab, und wenn mehr als 2/3 der Knoten die Events als richtig bewerten, gelten diese im Netz als validiert [32]. Da der Hashgraph über die Zeit immer weiter wächst, ist es wichtig, dass die Validierung zu festen Zeitpunkten stattfindet. Das wird bei Hashgraph über Runden für einzelne Events umgesetzt. Eine neue Runde wird immer dann begonnen, wenn ein Event sich einerseits mit mehr als 2/3 der ersten Events der vorhandenen Knoten der aktuellen Runde verbunden hat und andererseits diese Verbindung über mehr als 2/3 der existierenden Pfade vorgenommen wurde [10, 32]. Die ersten Events eines Teilnehmers einer Runde werden Witness (Zeuge) genannt. In Abb. 2.24 sind z. B. A2, B2, C2, D2 Witnesses für den Hashgraph. Ergänzend wird in der nächsten Runde bestimmt, ob eines der Witness-Events aus der Vorrunde als „Famous Witness“ behandelt wird. Famous-Witness-Events sind Events, die von mehr als 2/3 aller beteiligten Knoten als „Famous“ gewählt wurden. Die Wahl wird durchgeführt, indem in Runde t+1 alle vorhandenen Witnesses prüfen, ob sie mit dem zu betrachtenden Witness in Verbindung stehen, sodass das zu betrachtende Event ein Vorfahr im Graph zu dem Witness-Event in der nachfolgenden Runde ist. Ist eine solche Beziehung vorhanden, also reicht ein Event z. B. A3 in Abb. 2.24 in seiner Graph-Verknüpfung bis zu dem zu überprüfenden Event B2 zurück, gibt A3 seine Stimme für B2 als „Famous Event“ positiv ab. Diese Prüfung wird nun von allen Knoten durchgeführt. In einer weiteren Runde zählt ein weiteres Witness-Event (B4) die Anzahl an Ja-Stimmen von den Events, die er selber „strongly sees“, also wenn dieser Knoten durch mehrere direkte Pfade mit dem jeweiligen Witness-Event verbunden ist. Wichtig ist, dass es nicht ausreicht, dass B4 eine Verknüpfung zu den Vote-WitnessEvents besitzt, sondern die Verknüpfung muss über die Mehrzahl der im Netz vorhandenen

62

S. Schacht

Abb. 2.24 Funktionsweise Hashgraph. (In Anlehnung an [10])

Knoten hergestellt worden sein. In unserem Beispiel sind dies drei der vier vorhandenen Knoten A, B, C und D. B4 sieht A3 stark (strongly sees), da B4 über D und dann den Pfad über C zu A3 zurückverfolgen kann. Das Einsammeln der abgegebenen Stimmen über eine starke Verknüpfung wird nun von Knoten B solange durchgeführt, bis keine neue Stimme mehr eingesammelt werden kann. B4 hat nun vier Wahlstimmen mit dem Ergebnis, dass B2 ein „Famous Witness“ sein soll, eingesammelt, und zwar über mehr als 2/3 der im Netz vorhandenen Knoten, also entscheidet B4, dass B2 als ein „Famous Witness“ markiert wird. (In der Abbildung wird das Event grün gefärbt.) Das Ganze wiederholt sich nun für alle weiteren Witness-Events [10]. Vereinfacht stellt Dr. Leemon Baird den Konsens-Mechanismus in einem Erklärvideo wie folgt dar[12]: • Zunächst werden die Transaktionen mittels eines Zeitstempels in eine chronologische Reihenfolge gebracht. Hierbei werden zunächst die Transaktionen in den Events und dann die Events selbst sortiert. Da es durch das Gossip-Verfahren bei den unterschiedlichen Teilnehmern zu minimal abweichenden Zeitstempeln für die einzelnen Events kommen kann, wird als Konsens-Zeitstempel für ein Event der Mittelwert aller im Graph bekannten Eingangs-Zeitstempel eines aktiven Knotens herangezogen. • Ein aktiver Knoten ist ein Teilnehmer bzw. Computer, der im Graph Events empfängt und an viele andere verteilt. • Wie oben aufgeführt, wird die gesamte Historie des Graphen in einzelne Runden aufgeteilt. Es wird betrachtet, ob ein Knoten innerhalb dieser Runde Daten an andere Knoten

2 Die Blockchain-Technologie

63

versendet. Ist dies der Fall und erreicht der Knoten viele andere Beteiligte, dann hat der Knoten auch einen Famous Witness. • Um nun ein Gewicht der einzelnen Beteiligten noch mit in den Prozess dieses Virtual Votings zu bekommen, wird jeder Knoten, der seine Stimme für den Famous Witness abgibt, auf Basis seiner gehaltenen Token gewichtet. (Stakes) Zusammenfassend besteht der Konsens-Mechanismus von Hashgraph aus zwei wesentlichen Komponenten, Gossip-about-Gossip und virtual Voting. Gossip-about-Gossip, da das Protokoll Gossip zunächst für den Austausch der Transaktionen zwischen zufälligen Knoten vorgenommen wird und in Folge wieder dasselbe Protokoll verwendet wird, um den gesamten Graphen unter den Knoten auszutauschen. Virtual Voting, das verwendet wird, um die Validierung und Verifizierung vorzunehmen. Execution Model Bei Hashgraph werden Transaktionen im System mittels des beschriebenen VotingVerfahrens validiert. Durch die Verteilung der Events und die Verteilung des Kommunikations-Graphen über alle Beteiligten müssen bei der Betrachtung der FamousWitnesses mindestens zwei Runden vergehen, bevor eine Transaktion als bestätigt gilt. Damit wird das Execution Model nach dem Schema Order-Execute-Model vorgenommen. Vor- und Nachteil Einer der Vorteile von Hashgraph gegenüber klassischen Blockchain-Architekturen ist die hohe Verarbeitungsgeschwindigkeit der Transaktionen. Faktisch ist diese nur durch die Bandbreite des unterliegenden Netzes beschränkt. Hashgraph schafft bis zu 250.000 Transaktionen pro Sekunde, während Bitcoin etwa sieben Transaktionen pro Sekunde verarbeiten kann [32]. Ähnlich wie bei Tangle existiert bei Hashgraph keine Unterscheidung zwischen Minern und Teilnehmern, die die Transaktionen ausführen, da alle Beteiligten auch an der Verteilung der Informationen (Gossip-about-Gossip) und am Wahlverfahren (Virtual Voting) teilnehmen. Dies hat den Vorteil, dass es keine Interessenskonflikte zwischen Minern und den Anwendern des Netzes gibt. Durch das Fehlen der Miner im Hashgraph-Netz sind auch keine Belohnungssysteme nötig, was die Transaktionskosten niedrig hält bzw. sie komplett wegfallen lässt. Damit eignet sich Hashgraph zum Einsatz bei Micropayments oder im IoT-Umfeld [86]. Ein weiterer Vorteil ist der faire Algorithmus. Wie bei Tangle werden Transaktionen nicht gemäß ihrer Transaktionskosten priorisiert, sondern jede Transaktion hat die gleiche Gewichtung und damit dieselbe Chance, im Netz verarbeitet zu werden [82]. Weiterhin ist Hedera Hashgraph, die öffentliche Implementierung von Hashgraph, extrem stabil, da es aufgrund der Governance-Struktur durch ein Konsortium keine Forks, also Absplitterungen einer neuen DLT-Kette aus der alten heraus, gibt. Eine Änderung am öffentlichen Ledger kann nur durch einen Konsens des Konsortiums vorgenommen werden, was

64

S. Schacht

ein Auseinanderdriften der unterschiedlichen Interessengruppen und der Technologie verhindert [82]. Nachteilig ist vor allem, dass es sich bei der Technologie um eine Closed-Source-Software handelt. Der Algorithmus und die Implementierung wurden von Dr. Leemon Baird über seine Firma Swirlds patentiert. Dementsprechend kann Swirlds auch entscheiden, wer die Technologie nutzen darf und wer nicht [86]. Im Vergleich zur Blockchain-Technologie, bei der alle Ideen und Protokolle öffentlich und frei nutzbar sind, ist die Hashgraph-Technologie zentralisiert. Zwar wurde dies von Swirlds ein wenig abgeschwächt, indem man ein Konsortium für Entscheidungsfragen über die zukünftige Entwicklung von Hashgraph bildete, aber der Beitritt zu diesem Konsortium steht nicht jedem offen. Das Konsortium besteht aus bis zu 39 führenden globalen Unternehmen, die eine gewisse Expertise im Bereich der PublicLedger-Plattformen mitbringen müssen [13]. Kein Unternehmen kann alleine Einfluss auf den Ledger nehmen, sondern Änderungen am System sind nur über das demokratisch agierende Konsortium möglich. Der größte Kritikpunkt ist die Lizenzierung. Die Technologie muss bei Verwendung im eigenen Unternehmen in Form von privaten oder eigenen Konsortiums-DLTs von der Firma Swirlds lizenziert werden. Dies führt zu einer gewissen Abhängigkeit von dem Unternehmen.

2.3.2.4 Data Storage Bisher wurde nur auf die DLT-Technologien in Bezug auf ihre unterschiedlichen Datenstrukturen und Konsens-Mechanismen eingegangen. Ein Nachteil dieser Datenstrukturen ist aber, dass kaum eine die Möglichkeit bietet, Daten verteilt abzulegen. Zwar besteht die Möglichkeit, eine Datei z. B. in Form einer oder mehrerer Transaktionen zu codieren und diese dann in die DLT einzuspielen. Dies führt aber in der Regel dazu, dass die Kosten für das Speichern einer solchen Datei sehr hoch werden. Zum Beispiel die Ablage von einem Kilobyte in der Ethereum-Blockchain rund 0,0032 ETH, was beim aktuellen Umrechnungskurs 0,7648 Cent entspricht. In Gigabyte ausgedrückt kostet es 801.950,92 e, ein Gigabyte in der Ethereum-Blockchain abzulegen.11 Im Umfeld des maschinellen Lernens werden aber größere Datenmengen zum Anlernen neuer Modelle der Algorithmen benötigt. Hier gilt die Devise, je mehr Daten für die Entwicklung eines Algorithmus verwendet werden können, umso besser ist das Ergebnis. Um die Kosten der Speicherung zu reduzieren, werden unterschiedliche Lösungen verwendet. Eine Lösung wäre die lokale zentrale Speicherung der Daten. Hierbei wird die DLT-Technik nur als Verifizierungsstelle verwendet. Die zentral gespeicherten Daten werden durch Hash-Werte beschrieben und diese dann in der Blockchain gespeichert. So kann kostengünstiger lokaler oder Cloudspeicherplatz verwendet werden und die Unveränderbarkeit der Daten wird über die unveränderbare Speicherung des Fingerabdruckes dieser Daten 11 Es benötigt ca. 640.000 GAS Einheiten ein Kilobyte abzulegen. Eine GAS Einheit entspricht 5

GWEI, was wiederum 0,000000005 ETH entspricht. (Siehe ETH-Converter.com). In Summe kommen somit die 0,7648 Cent pro Kilobyte heraus. (Kursdatum 27.05.2019)

2 Die Blockchain-Technologie

65

Abb. 2.25 Anchoring lokaler Daten in der Blockchain. (In Anlehnung an [9])

in der Blockchain gesichert. Jeder Teilnehmer mit Zugriff kann den Datensatz auslesen (Abb. 2.25). Es wäre auch vorstellbar, ein Rechtesystem auf einem zentralen Datenspeicher zu etablieren und damit allen Beteiligten Zugriff auf die Daten zu ermöglichen. Das funktioniert aber nur in einem Verbund von wenigen Teilnehmern und nicht in DLT-Implementierungen, an denen viele Unbekannte beteiligt sind, da diese sonst alle berechtigt werden müssten. Außerdem durchbricht diese Lösung die Grundidee der Dezentralisierung der DLT-Technik und müsste als Achillesferse des gesamten Systems angesehen werden. Lösungsideen, die auf einem zentralen Service aufbauen, haben alle das Problem der Abhängigkeit. Jemand muss den zentralen Service betreiben und verwalten, besitzt also große Macht und kann Einfluss auf die Bereitstellung der Daten nehmen. Zwei wesentliche dezentrale File-Storage-Dienste im DLT-Umfeld sind das InterPlanetary File System und Ethereum Swarm. Beide Projekte haben zum Ziel, sowohl eine dezentrale Speicherlösung als auch das Kommunikationsprotokoll für die Verwendung dieser Speicherlösung zu liefern, und beide Systeme verwenden für diesen Zweck die P2PTechnologie. Um Dateien anzusprechen, werden sie mittels ihres eindeutigen Hash-Werts adressiert [9]. Da beide Technologien von der Funktionsweise ähnlich sind, das InterPlanetary File System aber von der Entwicklung und damit Reife weiter ist, werden wir in diesem Buch nur darauf eingehen [30]. InterPlanetary File System Das Ziel des InterPlanetary File System (IPFS) war ursprünglich nicht, eine Möglichkeit zur Datenspeicherung in DLT-Environments zu liefern, sondern es wurde entwickelt, um die Schwächen eines zentral basierten Internets zu beseitigen. Als Basis für die Übertragung von Internetseiten und Daten wird das Hypertext Transfer Protocol (HTTP) verwendet. Erfunden wurde es 1989 von Tim Berner Lee. Grundprinzip und Funktionsweise der Datenlieferung im Internet sind einfach erklärt. Zunächst basiert das Internet auf einer Ansammlung vernetzter Rechner und Server, die Daten wie Webseiten und Dateien speichern und diese über das HTTP-Protokoll zur

66

S. Schacht

Verfügung stellen. Ein User lädt z. B. eine Datei auf einen definierten Server mit einer eindeutigen IP-Adresse und andere können diese Datei dann mittels der IP-Adresse und der genauen Verzeichnisangabe herunterladen. Da die Server im Internet dezentral organisiert sind, muss die Anfrage, eine spezifische Datei herunterzuladen, von dem Rechner, der sie bekommt, bis zum Ziel-Rechner, auf dem die Datei gespeichert ist, durchgeleitet werden. Zwar wird für das Routing ein dezentrales Netz von Servern verwendet, aber prinzipiell handelt es sich um eine Client-Server-Architektur, bei der der Client Daten von einem zentralisierten Server holt. Fällt dieser Server aus, ist auch die Datei nicht mehr erreichbar. Liegt die Datei auf einem Server am anderen Ende der Welt, muss zunächst die Anfrage und dann die Datei über viele Verbindungen, also andere Server, zum Server und dann zum Anfragenden geroutet werden. Dies führt zu einer langsamen Latenz und ggf. langsamen Übertragungsgeschwindigkeiten [55]. Das Content Delivery Network (CDN) IPFS möchte diese Schwächen des Internets lösen, indem es eine völlig dezentrale Welt sowohl für die Vernetzung der Rechner untereinander als auch für die Anfrage und Speicherung von Daten aufbaut. Wesentliche Unterscheidungsmerkmale von IPFS zur klassischen Bereitstellung von Daten über das Internet sind: • Dateien und Informationen werden nicht mehr per Server-Adresse (IP-Adresse) angesprochen, sondern mittels einer Content-Adresse, die direkt den Inhalt anspricht. Auf diese Weise ist es egal, auf welchem Server die Datei liegt, es ergibt sich sogar die Möglichkeit, eine Datei in Teilen über viele Server zu replizieren und zu verteilen. Entscheidend für das Verständnis zwischen Location-Based-Address und Content-Based-Address ist, dass bei Ersterer die Adresse angefragt wird, die vermeintlich die gewünschte Datei enthält, und bei Zweiterer keine Adresse, sondern der Inhalt – es wird also beschrieben, was man sucht, nicht, wo man es sucht [28]. • Alle Informationen im IPFS sind Immutable also unveränderbar, sodass für jede Datei bzw. Dateiänderungen eine Versionsverwaltung vorliegt. • Alle Informationen sind dezentral abgelegt, es existiert kein zentraler Server zur Verwaltung oder Speicherung der Daten. Durch die Dezentralisierung ergeben sich viele Möglichkeiten. Zensur oder das Abschalten von Informationen ist nicht mehr möglich [28]. Wie funktioniert dies nun technisch? Das IPFS-Netz greift wie die DLT auf die Schlüsseltechnologie Peer-to-Peer zu und baut einen Verbund von Rechnerknoten auf. Auf diesen Rechnern werden die Dateien in Form eines Hash-Werts über den Inhalt der Datei dezentral gespeichert [21]. Der Abruf der gespeicherten Datei wird mittels des Hash-Werts, also der Beschreibung ihres eindeutigen Fingerabdrucks, vorgenommen, über den diese dann im Netzwerk aufgefunden werden kann [21]. Die Verwendung des Hash-Werts als Abfrageobjekt und eindeutige Identifikation hat mehrere Vorteile. Erstens kann der Anfragende anhand des Hash-Werts sicher sein, dass er

2 Die Blockchain-Technologie

67

Abb. 2.26 IPFS Blockstruktur. (In Anlehnung an [28])

Datei und Datei-Inhalt bekommt, die er auch angefordert hat. Dateien, die mit Viren angereicht wären, hätten einen anderen Hash-Wert. Zweitens besteht für das Protokoll die Möglichkeit, anhand der Hash-Werte zu erkennen, ob die gleiche Datei noch einmal gespeichert werden soll, was zur Optimierung des Speicherplatzes vermieden werden kann. Ergänzend überwacht das Protokoll die Versionshistorie einer jeden Datei [21] (Abb. 2.26). Im Detail werden die Daten in Form von IPFS-Objekten gespeichert. Ein IPFS-Objekt besteht aus den eigentlichen Daten, z. B. ein Textfile, sowie einem Link-Feld. In dem Datenfeld können in einem IPFS-Objekt 256 kb an Daten gespeichert werden. Sollte die Datei größer als 256 kb sein, wird sie in mehrere IPFS-Objekte gesplittet. Um die Objekte später wieder verbinden zu können, wird ein weiteres IPFS-Objekt mit einem leeren Datenfeld erzeugt, das in dem Link-Feld die Hash-Werte der einzelnen Blöcke enthält und somit ein Auffinden der Blöcke für die ursprüngliche Datei ermöglicht. Die Art und Weise, wie die Daten in IPFS-Objekten abgelegt werden, ist sehr flexibel, da hierdurch das IPFS-System auch wie ein Dateisystem verwendet werden kann. Betrachtet man eine Ordnerstruktur, dann kann diese Ordnerstruktur auch in verlinkten IPFS-Objekten dargestellt werden [28] (Abb. 2.27). Wie schon erwähnt sind Dateien, die in IPFS abgelegt werden, unveränderbar. Dies liegt daran, dass keine ortsbezogene, sondern eine inhaltsbezogene Adressierung vorgenommen wird. Eine Änderung des Inhalts würde zu einem neuen Hash-Wert und damit zu einer neuen Adresse führen. Dennoch ist es gerade bei Dateien wichtig, dass Änderungen möglich sind. IPFS löst dieses Problem mit der Implementierung einer Versionsverwaltung über die abgelegten Daten. Genau genommen wird bei einer Änderung der Daten eine neue Datei in Form von IPFS-Objekten angelegt und diese neue Datei mit der alten mittels eines CommitObjects, das die Datenfelder „Parent“ und „Object“ enthält, verlinkt. Bei jeder Anlage einer

68

S. Schacht

Abb. 2.27 Ordnerstruktur in IPFS. (In Anlehnung an [28])

Datei wird neben den IPFS-Objekten, die die Daten enthalten, auch immer ein CommitObjekt angelegt. Bei Erstanlage enthält das Datenfeld Parent keinen Wert und das Feld Object verweist auf den Hash-Wert des IPFS-Objektes. Eine Änderung an der Datei erzeugt wiederum ein neues IPFS-Objekt und ein neues Commit-Objekt, das in dem Feld Parent nun auf das ursprüngliche Commit-Objekt und im Feld Object auf die veränderte Datei verweist. Diese Verkettung von Änderungen kann beliebig wiederholt werden und es kann über die Historie der Datei jeder beliebige Stand wiederhergestellt werden [28]. IPFS bietet durch seine Dezentralisierung und die Art der Datenspeicherung viele Vorteile, aber auch diese Vorgehensweise hat Nachteile. Ein großes Thema ist die langfristige Bereitstellung der Daten. Zwar sind die Daten nicht löschbar, werden sie aber nur auf einem Knoten abgelegt und dieser Knoten verlässt das Netz, dann sind die Daten auch nicht mehr verfügbar, also faktisch gelöscht. IPFS versucht, dieses Problem so zu lösen, dass Dateien nicht nur von einem Knoten, sondern von mehreren zwischengespeichert werden. So speichert jeder Knoten, der eine Datei anfordert und lädt, diese auch wieder zwischen [21, 28]. Aber auch dann ist die Datei nicht mehr verfügbar, wenn diese Knoten das Netz verlassen. Für Stabilität müssen also entweder zusätzliche Anreize geschaffen werden, sodass Knoten Dateien speichern und vorhalten wollen, oder Dateien müssen proaktiv auf sehr viele Knoten verteilt werden. Hier kommt die Blockchain-Technologie ins Spiel: FileCoin ist ein Service, der auf Basis der Blockchain entwickelt wurde und Personen, die Speicherplatz für IPFS zur Verfügung stellen, über Kryptowährungen incentiviert, damit die Dateien dem Netzwerk lange zur Verfügung gestellt werden [14]. Der Zugriff auf das IPFS-Netzwerk erfolgt entweder mittels des Betriebs eines eigenen IPFS-Knotens oder über ein IPFS-Gateway wie „http://gateway.ipfs.io/ipfs/hash“. Das Gateway ist ein öffentlich zugänglicher Knoten, der die Anfrage dann weiterleitet.

2 Die Blockchain-Technologie

69

Gerade die Tatsache, dass die Knoten die Dateien, die angefordert wurden, auch zwischenspeichern, sorgt dafür, dass IPFS für einige Anwendungsfälle interessant ist. So zeigt Jonas Bostoen in seinem Beitrag „A Hands-on Introduction to IPFS“, dass unter Verwendung von IPFS z. B. bei einer gleichzeitigen Bearbeitung eines Dokuments von mehreren Personen im gleichen Raum, wie es mittels Google Docs möglich ist, die Änderungen nicht jedes Mal an einen zentralen Server von Google geschickt werden müssen, sondern direkt auf dem IPFS-Knoten im Raum gespeichert werden und alle Teilnehmer direkt mit diesem Knoten kommunizieren können. Die Latenz und auch die Bandbreite würde sich bei einer solchen Vorgehensweise massiv reduzieren lassen [19]. Die unterliegende Technologie Peer-to-Peer, das Hash-Verfahren zur Adressierung der Inhalte sowie die Möglichkeit, dezentral ohne Server große Datenmengen ablegen zu können, machen das IPFS Content Delivery Network zum idealen Partner für die Blockchain, in der das Speichern von großen Datenmengen nicht vorgesehen ist und könnte eine Schlüsseltechnologie für die Kombination von maschinellem Lernen und der Distributed-LedgerTechnologie darstellen.

2.3.3

Ebene 3„Concept – Application Framework“

Bisher wurden die technologischen Grundprinzipien (Ebene 1) sowie die Basis-Konzepte, auf denen die Distributed-Ledger-Technologie aufbaut (Ebene 2), erläutert. Ebene 3 zeigt nun die Konzepte mit Fokus auf verfügbare Applikationen auf. Hierbei handelt es sich um die Implementierung von Hilfsstrukturen, die die Abbildung einer Applikation auf der Distributed-Ledger-Technologie ermöglichen. Um eine Applikation abbilden zu können, ist es notwendig, dass die DLT nicht nur Transaktionen und damit Daten speichert, sondern dass eine Verarbeitung der Daten innerhalb der Distributed-Ledger-Technologie möglich ist. Die Verarbeitbarkeit von Transaktionen innerhalb der Blockchain wird mittels sogenannter Smart Contracts realisiert. Diese Smart Contracts sind eigenständige Programme, die innerhalb des DLT-Netzes ablaufen. Durch die Verwendung von mehreren miteinander verbundenen Smart Contracts können ganze Organisationen dezentral abgebildet werden. Sogenannte Oracles liefern den Smart Contracts die notwendigen Schnittstellen zu bestehenden Datenquellen bzw. Vorsystemen. Im nachstehenden Abschnitt werden Smart Contracts, dezentrale Applikationen und Oracles ausgeführt.

2.3.3.1 Smart Contracts Neben der Dezentralisierung von Transaktionen und dem Austausch von Informationen bietet die Distributed-Ledger-Technologie die Möglichkeit, mittels Smart Contracts einerseits automatisierte Prozesse über Unternehmensgrenzen hinweg zu etablieren und anderseits die

70

S. Schacht

Abbildung von Regularien und Organisationsprinzipien zu ermöglichen [84]. Smart Contracts wurden erstmals 1997 von Nick Szabo in seinem Artikel „Formalizing and Securing Relationships in Public Networks“ erwähnt. Dabei beschreibt Szabo, wie einzelne Vertragsklauseln normaler Verträge direkt in die Software und Hardware eingebettet werden können. Zu möglichen Vertragsklauseln zählt Szabo Sicherheiten, Kautionen und die Übertragung von Eigentum. Prinzipiell funktionieren laut Szabo Smart Contracts so ähnlich wie ein Automat, an dem man gegen Geldmünzen Eigentum an einem Gegenstand, z. B. ein Eis, erlangen kann. Der Eigentümer der Münze erwirbt durch Einwerfen derselben ein Eis aus dem Automaten, ohne mit dem eigentlichen Eigentümer des Eises in Verhandlung treten zu müssen. Der eingebaute Mechanismus nimmt das Geld entgegen, prüft auf Echtheit und den korrekten Betrag und gibt bei positiver Prüfung das Eis aus. In dem Automaten sind alle Bedingungen der Prozessschritte hinterlegt, ebenso wie ein Regelwerk, was bei positiver und was bei negativer Prüfung passieren soll. Es wurde somit eine Automatisierung des Prozesses „Verkauf eines Eises“ mittels der Einbettung von Wenn-Dann-Beziehungen in die Hardware und Software des Automaten implementiert [71]. Durch Kombination der Blockchain-Technologie mit den Ideen der Smart Contracts aus den 90er-Jahren ergeben sich spannende Anwendungsfälle. So führte Szabo schon 1997 auf, dass man einen Smart Contract als Hilfsmittel zur Sicherung von Eigentumsrechten, z. B. im Bereich Fahrzeugleasing, etablieren könnte. Vorstellbar ist hier die Zündung und Bedienung des Fahrzeugs über digitale Schlüssel (Private/ Public-Keys), die im Handy gespeichert sind. Das Fahrzeug selbst dient in Leasing-Verträgen in der Regel als Sicherheit für die Bank, falls der Leasingnehmer die Raten nicht bezahlt. Mittels Smart Contracts könnte nun bei jedem Zündvorgang oder in regelmäßigen Abständen überprüft werden, ob die Leasingraten bezahlt wurden oder nicht, um im negativen Fall gegebenenfalls die digitalen Schlüssel einzuziehen bzw. für ungültig zu erklären [71]. Aber auch viele weitere Szenarien sind unter der Anwendung von Smart Contracts denkbar. So könnten im Service-Level-Management die Service-Level-Agreements in Smart Contracts abgebildet werden. Damit könnte ein solcher Smart Contract die Einhaltung der definierten Service Levels überwachen, sowie bei Nichteinhaltung sofort Pönalen einziehen oder bei positiver Übererfüllung Boni auszahlen – und das ohne jegliche Interaktion durch einen Menschen. Entgegen der vielversprechenden Idee wurde das Konzept der Smart Contracts, wie Szabo es ausführte, nicht auf breiter Ebene angenommen. Als Grund nennen Christoff Graf et al. fehlende Akzeptanz der Vertragsparteien, offene rechtliche Fragen, fehlende Standardisierung und das Fehlen einer technischen Infrastruktur [38]. Aber auch die Tatsache, dass zur Einführung von Smart Contracts wiederum eine zentralisierte Plattform notwendig ist und damit wieder Vertrauen in den Betreiber der Plattform aufgebaut werden muss, behinderte die Entwicklung von Smart Contracts seit den 90er-Jahren. Erst mit dem Aufkommen der Distributed-Ledger-Technologie scheint nun die notwendige dezentrale Infrastruktur vorhanden zu sein, damit die von Szabo postulierten positiven

2 Die Blockchain-Technologie

71

Eigenschaften auch greifen können – nämlich Senkung von Transaktionskosten und Risiken der Transaktionen durch den Verzicht auf menschliche Akteure. Auch ermöglicht DLT ein größeres Vertrauen in die Funktionsweise von Smart Contracts. Nach Jonatan Bergquist müssen Smart Contracts eine Reihe von Merkmalen aufweisen: Sichtbarkeit, Online-Durchsetzbarkeit, Überprüfbarkeit und Privatsphäre. Sichtbarkeit bedeutet, dass jeder Teilnehmer den Inhalt des Smart Contracts betrachten kann und außerdem die Möglichkeit hat, die gegenseitige Leistungserfüllung transparent nachweisen und nachvollziehen zu können. Unter Online-Durchsetzbarkeit versteht man die Sicherstellung der Einhaltung der Bedingungen, die im Contract hinterlegt wurden. Dies kann proaktiv durch die Verwendung von technischen Maßnahmen, die ein Abweichen von einer Bedingung verhindern, sichergestellt werden, oder durch reaktive Maßnahmen, die einen Bruch einer Bedingung nachträglich aufdecken. Das Kriterium der Überprüfbarkeit ist insbesondere bei autonomen Smart Contracts wichtig, da hierdurch die transparente Nachvollziehbarkeit des autonomen Smart Contracts gewährleistet ist. Zu guter Letzt sollten innerhalb von Smart Contracts die Inhalte und die Interaktionen zu einem Smart Contract so privat wie möglich gehalten werden, damit die Privatsphäre der Teilnehmer so weit wie möglich gewahrt ist. Bergquist führt weiter aus, dass gerade die ersten drei Eigenschaften im Widerspruch zur letzten stehen, was ein Optimierungsproblem anzeigt [15]. Dieses Optimierungsproblem kann entweder durch die Einbindung eines Intermediärs gelöst werden, dem vertraut werden muss, wie es Szabo erläutert, oder mittels der Verwendung der Distributed-LedgerTechnologie unter Anwendung von Anonymisierung und Verschlüsselung [15]. Bisher wurden Smart Contracts gemäß ihrer Bezeichnung erläutert. Aber Smart Contracts sind entgegen ihrer Namensgebung weder „smarte“ Programme noch Verträge im Sinne einer legalen Bindung [5]. Vielmehr handelt es sich bei Smart Contracts lediglich um eine Abbildung legaler Verträge mittels Wenn-Dann-Regeln in der digitalen Welt, bzw. um eigenständige Programme, die keinen Vertragscharakter beinhalten müssen. Antonopoulos bringt es in seinem Buch „Mastering Ethereum“ auf den Punkt: Bei Smart Contracts im Rahmen der Blockchain handelt es sich um Programme, die unverändert in der Blockchain ablaufen und sich deterministisch verhalten. Die Blockchain wird somit zu einem dezentralen „Welt-Computer“, in dem eigenständige Programme ihren Dienst erbringen. Unveränderbarkeit in diesem Kontext bedeutet, dass eine Änderung oder Löschung des Programmcodes, nachdem dieser bereitgestellt wurde, nicht mehr möglich ist. Anpassungen können nur in Form einer neuen Instanz vorgenommen werden [5]. Da genau wie Transaktionen auch der Programmcode von Smart Contracts über die beteiligten Knoten des Blockchain-Netzes verteilt, redundant vorgehalten und ggf. auch ausgeführt wird, ist es wichtig, dass diese Art von Programmen sich deterministisch verhalten. Das heißt, dass jede Ausführung von z. B. unterschiedlichen Personen bzw. auf unterschiedlichen Knoten zum gleichen Ergebnis führt, wenn man den Kontext der Transaktion, die die

72

S. Schacht

Ausführung ausgelöst hat, und den Stand der Blockchain zum Zeitpunkt der Ausführung betrachtet. Das Ergebnis eines Programmaufrufs muss also unter gleichen Bedingungen immer zu den gleichen Ergebnissen führen [5]. Unter „Welt-Computer“ wird die Tatsache verstanden, dass die Blockchain und auch die Replikation der Programme über die Knoten der Blockchain von außen betrachtet nicht als Verbund vieler Knoten oder auch vieler replizierter Programme wahrgenommen wird, sondern dass die Blockchain sich wie ein weltumspannender Einzelrechner verhält [5]. Smart Contracts bieten neben der Möglichkeit der Prozessoptimierung und -automatisierung über Unternehmensgrenzen hinweg etliche weitere Vorteile. So bieten sie einen hohen Grad an vordefiniertem Ausgang, da Sachverhalte immer in Wenn-Dann-Bedingungen transformiert werden. Interpretationsspielraum in der Ausführung einzelner Regeln kann und darf bei der Umsetzung von Smart Contracts nicht existieren. So hohe Genauigkeit ist vorteilhaft für die Automatisierung von Prozessen. Neben der Genauigkeit sind Transparenz und damit auch das Beseitigen von asymmetrischen Informationsverteilungen weitere Vorteile der Smart Contracts. Jeder Vertragspartner bzw. jeder, der mit einem Smart Contract interagiert, kann die Funktionsweise und den Inhalt des Vertrages nachvollziehen. Aufgrund der Genauigkeit müssen alle Bedingungen im Vertrag hinterlegt sein, da sonst das Programm nicht automatisiert und autonom agieren kann. Durch die autonome, automatisierte Funktionsweise ist die Selbstausführung einer Bedingung nach einem Trigger schnell und effizient. Der Smart Contract erfüllt die hinterlegten Vertragsbedingungen in dem Moment, in dem das Ereignis eingetreten und die Bedingung hierdurch erfüllt ist. Im Falle des Service-Level-Management können Pönalen sofort eingezogen werden, wenn z. B. der Service nicht wie definiert bereitgestellt wird. Dies erhöht Effizienz und Geschwindigkeit. Die Selbstausführung führt weiterhin zu einer Kostenreduktion in der Verwaltung und Überwachung von Vertragsbedingungen zwischen Parteien [3]. Neben den Vorteilen müssen aber auch die Nachteile von Smart Contracts aufgezählt werden. Ein großer Nachteil ist die Unveränderlichkeit von Verträgen, die allerdings z. B. bei falsch hinterlegten Bedingungen oder der Beendigung eines Vertragsverhältnisses notwendig sind. Einmal in der Blockchain abgelegt, besteht keine Möglichkeit, den Vertrag zu ändern. In jeden Vertrag muss also eine Terminierungsfunktion implementiert werden, damit er unter bestimmten Bedingungen inaktiv gesetzt werden kann. Eine Änderung kann bisher nur durch das Bereitstellen eines neuen Smart Contracts vorgenommen werden, wobei der Vorgänger weiterlebt und wegen der Unveränderbarkeit der Blockchain auch nicht entfernt werden kann. Dementsprechend muss ein Mechanismus zur Inaktivierung des Contracts in das Programm eingebettet werden. Problematisch an einem solchen Mechanismus ist die Absicherung, dass er auch nur von den Parteien initiiert werden kann, die hierfür berechtigt sind [3]. Ein weiterer Nachteil ist die Transparenz der hinterlegten Bedingungen. Oft ist es gar nicht erwünscht, dass Bedingungen zwischen Vertragsparteien öffentlich für jeden einsehbar sind. Smart Contracts auf Ebene der öffentlichen Blockchains replizieren diesen aber auf

2 Die Blockchain-Technologie

73

alle Knoten des gesamten Netzes und sorgen somit für eine vollständige Transparenz. Ein Lösungsansatz wäre, mittels Verschlüsselungstechniken die Bedingungen des Vertrages nur für die beteiligten Parteien sichtbar zu machen, was aber zu einem ergänzenden Overhead führt. Alternativ könnte man Smart Contracts nur auf einzelnen Knoten des Netzes verwalten und damit die Sichtbarkeit nur für diese Knotenbetreiber ermöglichen. Dieser Weg wird vor allem bei nicht öffentlichen Blockchains, z. B. Hyperledger, eingeschlagen [3]. In den unterschiedlichen Blockchain-Implementierungen haben Smart Contracts unterschiedliche Bezeichnungen. So wird in Ethereum, eine generalistische Blockchain, durchaus von Smart Contracts gesprochen, währen IOTA das Äquivalent zu Smart Contracts als Qubic bezeichnet. Hyperledger nennt Smart Contracts ChainCode, was sicherlich sprechender ist, da es sich nicht um Verträge, sondern um Programme in der Blockchain handelt.

2.3.3.2 Dezentrale Applikationen und dezentrale autonome Organisationen Klassische zentrale Webapplikationen werden immer auf einem zentralen Server, der von einer Partei kontrolliert wird, betrieben. Diese Partei besitzt die vollständige Kontrolle über die Applikationen, die Funktionen und auch die Daten, die in die Applikationen eingegeben und verarbeitet werden. So kontrolliert beispielsweise Facebook sowohl die Applikation selber, also deren Funktionsweise, als auch alle Daten der Benutzer, die bereit sind, diese in die Applikation einzugeben. Dezentrale Applikationen (Dapp) dagegen werden nicht durch eine Partei oder eine Person kontrolliert, sondern funktionieren auf Basis vordefinierter Protokolle, die die Kommunikation zwischen Benutzern und die Funktionsweise der Applikationen bestimmen [45]. Die Protokolle werden als Smart Contracts unveränderlich in der Blockchain abgebildet und formen somit in Summe die Applikation. Dabei ist es möglich, die Dapp so zu gestalten, dass einzelne Nutzer mehr Einfluss auf die Applikation haben als andere, z. B. durch mehr Anteile. Das ist z. B. für Abstimm-Applikationen relevant, bei denen bestimmte Nutzer, die mehr Stimmrechte haben sollen, auch ein höheres Gewicht in der Abstimmung bekommen. Aufgrund der Unveränderbarkeit und Transparenz der zugrunde liegenden Smart Contracts kann nach Bereitstellung einer Dapp hinterher kein Einfluss auf die Applikation und die definierten Regeln genommen werden. Dapps ermöglichen den Betrieb von Applikationen wie Facebook, Uber oder Airbnb über die Blockchain. So kann über die mangelnde Zentralisierungsmacht sichergestellt werden, dass die Datenhoheit bei den Nutzern bleibt bzw. Daten nur für den originären Zweck der Applikationen verwendet werden. Ergänzt man Dapps um autonome Agenten, entstehen dezentrale autonome Organisationen (DAO), die ohne jegliche menschliche Interaktion existieren und interagieren können. Autonome Agenten sind Softwareprogramme, die selbsttätig mit anderen Individuen oder anderen Software-Services interagieren und sich in einem gegebenen Rahmen auch an neue Anforderungen anpassen, also rekonfigurieren können. Dezentrale autonome Organisationen weisen ein hohes Maß an Automatisierung auf und sind damit wesentlich

74

S. Schacht

vertrauenswürdiger als Dapp, da auch die Interaktion zwischen den Parteien weitestgehend auf autonomen Protokollen basiert und somit transparent und nachvollziehbar ist. Mittels DAO lassen sich komplett autarke Unternehmen abbilden, in denen keine Eigentümer oder auch nur Mitarbeiter existieren. Sogar die legale Einheit „Unternehmen“ wird überflüssig und trotzdem interagiert diese Organisation am Markt. In dem Artikel der „Zeit“ vom 26. Mai 2016, „Die erste Firma ohne Menschen“, wurde über eine Investment-DAO berichtet, die insgesamt 140 Mio. US$ eingesammelt und nach einem Abstimmungsprozess ähnlich wie ein Investor an Start-Ups verteilte. In diesem Fall bestand die DAO aus Smart Contracts, die sowohl die Gelder in Form von Kryptowährungen verwalteten als auch die Adressaten des eingetriebenen Gelds über eine Voting-App sicherstellten [39]. Diese Form der Nutzung der Blockchain-Technologie erlaubt zahlreiche Anwendungsfälle. So ist vorstellbar, dass Genossenschaften, die als Ziel die Förderung der Einzelwirtschaften ihrer Mitglieder haben, in Form von dezentralen autonomen Organisationen abgebildet werden und damit zu virtuellen Genossenschaften werden. Vorteil dieser Vorgehensweise wäre, dass die Organe der Genossenschaft durch die DAO automatisiert und in die Hände aller Mitglieder zurückgegeben werden – damit wird der Overhead für den Betrieb der Genossenschaft durch die Besetzung der Organe minimiert oder sogar eliminiert, was eine Genossenschaft in Reinform ergibt.

2.3.3.3 Oracles Beim Einsatz von Smart Contracts oder dezentralen autonomen Organisationen ist es immer wieder notwendig, dass die Smart Contracts auf Daten anderer Anbieter zurückgreifen. Dies können Wetterdaten, Aktienkurse oder andere Datenquellen sein. Grundsätzlich ist die Einbindung solcher Datenquellen über standardisierte Protokolle wie REST API oder Ähnliches möglich. Im Rahmen der Smart Contracts ist dies aber nicht so einfach, da die Einbindung eines zentralisierten Datenlieferanten zwei wesentliche Nachteile mit sich bringt: Einerseits kann das durch die Blockchain geschaffene Vertrauen unterlaufen werden, da der zentralisierte Datenlieferant durch geschickte Manipulation der zu liefernden Daten das Ergebnis der Smart-Contract-Routinen beeinflussen kann, und andererseits entsteht ein technisches Problem, da gegebenenfalls der Daten-Provider unter der Last der parallel eintreffenden Anfragen von vielen Knoten des Blockchain-Netzes überlastet wird und damit entweder keine Daten liefert oder das zu langsam tut [2, 45]. Um nun diese Nachteile auszugleichen, wurden Oracles eingeführt. Oracles sind Vermittler zwischen dem Blockchain-Netzwerk und der Welt außerhalb der Blockchain [2]. Sie lassen sich nach der Art der Integration und nach Typen unterschieden. Xiwei Xu et al. definieren zwei wesentliche Arten von Oracles [97]: • Oracles, die als eigenständige Dienste außerhalb der Blockchain agieren und die Zustände der realen Welt in Form von Transaktionen in die Blockchain schreiben.

2 Die Blockchain-Technologie

75

• Oracles, die in der Blockchain-Plattform integriert sind und damit auch die Möglichkeit haben, mit Smart Contracts zu interagieren, diese also auch aufzurufen. Brian Curran hingegen gliedert Oracles nach folgenden Typen [27]: • Hardware Oracles: Hardware Oracles sind Geräte wie z. B. Wechselrichter, Wärmepumpen oder Thermometer, die ihre Messdaten direkt einem Smart Contract zur Verfügung stellen können. • Software Oracles: Die Implementierung wird über einen Softwareservice vorgenommen. Dies ermöglicht die Einbindung von webAPIs, wie Flugdaten, Wetterdaten oder Aktienkurse. • Consensus Oracles: Oracles, die auf Basis einer dezentralen Oracle-Architektur die Schwächen der zentral geführten Oracles ausgleichen. Hier werden Daten von mehreren verschiedenen Oracles zusammengeführt und über einen Konsens-Mechanismus die Richtigkeit dieser Daten verifiziert. • Inbound Oracles: Oracles, die dem Smart Contract Daten zur Verfügung stellen, also als Datenlieferanten fungieren. • Outbound Oracles: Bieten den Smart Contracts die Möglichkeit, Daten aus dem Smart Contract in die Welt außerhalb der Blockchain zu senden. Dies ist vor allem für die Steuerung von Maschinen aus einem Smart Contract heraus notwendig. Die Problematik an Oracles ist, dass es sich grundsätzlich um Drittanbieter-Services handelt, die außerhalb des Konsens-Mechanismus der Blockchain agieren. Das heißt, dass die Nutzung solcher Services ein gewisses Vertrauen gegenüber den Betreibern der Services notwendig macht und damit der Grundgedanke der Blockchain unterlaufen werden kann. Um diesen Nachteil auszugleichen, arbeiten einzelne Projekte und Firmen wie Provable12 [79] oder Town Crier [89] an dezentralen Oracle-Lösungen, indem Sie z. B. Trusted-HardwareChips wie den Intel SGX als Mittel zur Absicherung der Oracles heranziehen. Aber auch Lösungen, die ein Netz aus dezentralen Oracles aufbauen, wie das ChainLinkNetzwerk, das viele dezentrale Knoten für das Verifizieren von Oracle-Daten mittels Konsens nutzt, können die aufgeführten Nachteile beseitigen [75].

2.3.4

Ebene 4„Implementation Frameworks“

Dieser Abschnitt behandelt mögliche Implementierungsframeworks für die Bereiche Public Blockchain und permissioned Blockchain. Im öffentlichen Bereich wird Ethereum vorgestellt, da es sich bei Ethereum um eine generalistische Blockchain-Plattform handelt, die sowohl die klassischen Transaktionen als auch dezentrale Applikationen abbilden kann. Im Bereich der nicht öffentlichen Blockchains wird auf Hyperledger Fabric eingegangen. 12 Früher Oraclize.

76

S. Schacht

2.3.4.1 Public Blockchain Wie in Abschn. 2.3.1 beschrieben, handelt es sich bei Public Blockchains um Distributed Ledger, auf die jeder unbeschränkt zugreifen darf und an denen jeder jederzeit teilnehmen bzw. das Netzwerk wieder verlassen kann. Öffentliche Blockchains werden für die Nutzung von Kryptowährungen wie Bitcoin und Ethereum herangezogen, finden aber auch Anwendung in „Track and Trace“-Applikationen, bei denen der Status von Gütern über viele Unternehmens- und Landesgrenzen hinweg verfolgt werden soll. Zu den bekanntesten öffentlichen Blockchains, die nicht nur das Ledger zur Verfügung stellen, sondern auch eine Plattform für die Bereitstellung von dezentralen Applikationen mittels Smart Contracts, zählt Ethereum. Ethereum Ethereum ist eine auf der Blockchain basierende Open-Source-Plattform, mittels der generische dezentrale Applikationen abgebildet werden können. Die Plattform wurde 2013 von Vitalik Buterin in seinem Whitpaper „A next Generation Smart Contract and Decentralized Application Platform“ erstmalig beschrieben und um 2015 in Betrieb genommen. Buterin entwickelte Ethereum, um die Blockchain-Technologie nicht nur im finanziellen Umfeld in Form eines Distributed Ledger zu betreiben, sondern auch die Möglichkeit zu bieten, sie mithilfe von dezentral ausführbaren Programmen auf andere Anwendungsfelder zu erweitern. Dazu initiierte Buterin 2015 eine Crowdfunding-Kampagne zur Ausgabe der Kryptowährung Ether und konnte zu Beginn rund 18 Mio. US$ eintreiben. Ziel von Buterin ist es, mit Ethereum eine Lösung zu schaffen, die alle möglichen Use Cases auf Basis der Blockchain abbilden kann [64]. Im Vergleich zu Bitcoin waren einige Änderungen nötig. Zunächst wurde mit Ethereum Virtual Machine eine Umgebung geschaffen, die es erlaubt, Smart Contracts mittels der eigenentwickelten Programmiersprache Solidity ablaufen zu lassen. Außerdem wurde die Transaktionsgeschwindigkeit durch die Reduktion der Erstellungszeit der Blöcke erhöht. Letzteres führt zu dem Nachteil, dass damit die Wahrscheinlichkeit steigt, dass Blöcke von mehreren Minern gleichzeitig validiert werden und somit neue Blockäste in der Blockchain entstehen. Im Bitcoin-Netz werden diese Nebenäste eliminiert, indem immer nur die längste Kette als gültig betrachtet wird. Wird die Blockzeit reduziert, führt dies aber zu sehr vielen Nebenästen, was die eindeutige Identifikation der längsten Kette erschwert. Ethereum löst dies durch die Einführung von sogenannten Uncles: Werden Blöcke mehrfach als valide angesehen, gilt der erste Block als Teil der Kette und alle anderen Blöcke bestätigen bzw. gewichten in Form eines Uncle-Blocks diesen validen Block. Hierdurch kann nun die gültige Blockchain mittels der Menge der gewichteten Blöcke identifiziert werden [97]. Neben der Konzentration auf öffentliche Blockchain-Technologie bietet Ethereum auch die Möglichkeit, eigene Knoten und damit private Blockchains aufzubauen. In Ethereum gibt es zwei verschiedene Arten von Adressen bzw. Konten. Zunächst die normalen Konten zur Verwaltung der Kryptowährungen, bei denen die Möglichkeit besteht, eigene Token von einem Konto zu einem anderen Konto zu transferieren. Die andere Art

2 Die Blockchain-Technologie

77

von Konten sind die Smart Contracts. Auch hier besteht die Möglichkeit, Token an einen Smart Contract zu transferieren, der gemäß Programm diese Token dann verarbeiten oder weiterleiten kann. Da man in der Blockchain sowohl Transaktionen als auch Programme abbilden kann, ergeben sich komplett neue Automatisierungsmöglichkeiten von Geschäftsabläufen, wie z. B. die bereits genannte automatisierte Überwachung von Service-Leveln. Aber auch andere Applikationen wie Lotterien oder Ähnliches können mittels Smart Contracts abgewickelt werden. So könnte ein Smart Contract zufällig aus allen Konten, die Token in den Contract einbezahlt haben, eines auswählen und alle im Contract vorhandene Token auf dieses Konto transferieren. Die Ausführung eines Programmes kostet Rechenzeit. Da die Smart Contracts aber gleichzeitig auf vielen Knoten verteilt sind und damit auch eine Vielzahl an Ressourcen zur Ausführung ihrer Funktionen verwenden, musste ein Mechanismus eingebaut werden, der sicherstellt, dass Programme nicht komplett alle Ressourcen verwenden bzw. sogar verschwenden. Hierfür wurde GAS eingeführt. GAS ist der Preis, den ein Smart Contract dafür bezahlt, dass einzelne Operationen ausgeführt werden. Somit bepreist die Ethereum Blockchain jede Low-Level-Operation des Smart Contracts mithilfe des GAS. Der Preis des GAS wird genau wie der Preis der Kryptowährung Ether über den Markt festgelegt [26]. Die Ethereum-Plattform kann durch ihre Flexibilität auch als Basis für andere Kryptowährungen dienen. Hierzu wurden Smart Contracts entwickelt, die das Handling der eigenen Kryptowährung regeln und vornehmen. Damit nicht jeder auch seine eigene Geldbörse für die Speicherung der eigenen Token entwickeln muss, wurden die Standards ERC20, ERC223, ERC777 und ERC827 entwickelt, die definieren, welche Funktionen ein Smart Contract besitzen muss, damit er mit dem jeweiligen Standard kompatibel ist und somit bestehende Applikationen auf diese neuen Token zugreifen können [26]. Die Schaffung eines eigenen Tokens schafft neue Anwendungsfälle, da mittels eines Tokens eine Incentivierung von z. B. Kunden vorgenommen werden kann.

2.3.4.2 Private/permissioned Blockchain Im Unternehmenskontext bekommen die permissioned Blockchains immer größere Bedeutung, da viele Unternehmen die Kommunikation mit anderen Marktteilnehmern, z. B. in Lieferketten, nicht öffentlich einsehbar machen wollen. Dementsprechend wird hier auf Framework-Implementierungen wie Hyperledger Fabric, Multichain oder Corda zurückgegriffen. Hyperledger Hyperledger ist selber keine Blockchain, sondern ein Konsortium aus mehreren Mitgliedern, das von der Linux Foundation seit Dezember 2015 gehostet und unterstützt wird. Zu den Mitgliedern dieses Konsortiums, die aus unterschiedlichsten Branchen stammen, gehören ca. 185 Firmen wie Airbus, Accenture, Deutsche Bank, Daimler, IBM, SAP und viele andere

78

S. Schacht

Abb. 2.28 Hyperledger Projekte. (In Anlehnung an [43])

[41]. Das Hyperledger Konsortium ist ein Dachprojekt, dass insgesamt sechs Frameworks und sieben Tools als Unterprojekte beinhaltet (Abb. 2.28). Ein wesentliches Projekt ist Hyperledger Fabric, dass eine modulare permissioned Blockchain abbilden kann. Durch die modulare Architektur ist es möglich, dass Daten in der Blockchain in unterschiedlichen Formaten abgelegt werden und auch unterschiedlichste Konsens-Algorithmen zur Verwendung stehen. Gerade die Modularität ermöglicht einen flexiblen Einsatz dieses Blockchain-Framworks für unterschiedliche Anwendungsfälle und -gruppen. Wie viele andere Blockchains legt Hyperledger die Transaktionen in Form eines chronologisch geordneten Ledgers unveränderlich ab. Hyperledger sieht sich aber als generisches Blockchain-Framework, bei dem nicht nur Zahlungen transferiert werden, sondern alle Vermögensgegenstände oder Informationen Teil der Transaktion sein können. Hyperledger nennt diese Vermögensgegenstände Assets. In Fabric werden Assets als Sammlung von Key-Value-Paaren abgelegt, deren Zustandsänderungen als Transaktionen im Ledger aufgezeichnet werden. Die Zustände der Assets können durch Transaktionen von Individuen verändert werden. Mittels ChainCode – der Entsprechung von Smart Contracts – werden das Asset und seine Eigenschaften, sowie die Anweisungen, wie Transaktionen diese Eigenschaften ändern können, definiert. Jedes Mitglied des permissioned Networks hat die Möglichkeit, mit diesen ChainCodes zu interagieren oder eigene Programme in dem gemeinsamen Ledger zu hinterlegen. Die Zugriffsrechte der permissioned Blockchain werden von den Mitgliedern des Konsortiums über Memebership Identity Services unter Zuhilfenahme von AccessControl-Listen gepflegt [67]. Der grundlegende Aufbau des Fabric-Netzwerks sieht zwei verschiedene Typen von Nodes vor: Peer-Nodes und Ordering-Nodes. Peer-Nodes sind verantwortlich für die

2 Die Blockchain-Technologie

79

Ausführung und die Verifizierung von Transaktionen, wohingegen Ordering-Nodes für die chronologische Reihenfolge der Transaktionen im Ledger sorgen, diese an alle anderen Knoten verteilen und für den Konsens-Mechanismus zuständig sind. Peer-Nodes nehmen die Rolle des Endorsers (Unterstützers) bei der Verifizierung von Transaktionen ein. Der eigentliche Ledger ist ebenfalls in zwei Komponenten aufgeteilt: Das TransactionLog, das alle Transaktionen unveränderbar in Blöcken speichert, und die State-Database, die den Zustand des Ledgers und damit der in ihm befindlichen Assets und Transaktionen beschreibt (World-State) [67]. Grundsätzlich kann man über das Transaction-Log die gleichen Informationen extrahieren, die in der State-Database gespeichert werden, aber durch die Bereitstellung dieser Information in einer eigenen Datenbank ist ein Zugriff wesentlich einfacher. Es müssen nicht die gesamten historischen Daten durchgerechnet werden, um den aktuellen Zustand zu ermitteln. Ein weiterer Vorteil der Zustands-Datenbank ist, dass sie mit gängigen Datenbanksystemen wie Couch-DB abgebildet werden kann und somit auch mittels SQL-ähnlichen Befehlen schnell abgefragt werden kann. Ein weiterer Unterschied zu öffentlichen Blockchains ist die Verwendung von Private Channels. Private Channels beschränken die Sichtbarkeit und den Zugriff auf Transaktionen auf einzelne Beteiligte, die auf den diesen Channel zugreifen können. So können auch im Wettbewerb stehende Unternehmen am gleichen Business-Netzwerk teilnehmen, ohne dass die Transaktionen von den konkurrierenden Unternehmen wechselseitig eingesehen werden können. Dies ermöglicht z. B. Einkaufsnetzwerke, bei denen die Lieferanten die Preise bzw. die Einkaufstransaktionen nur den Parteien sichtbar machen, die an dem Einkauf beteiligt sind. In nachstehender Abbildung ist der grundlegende Aufbau eines Hyperledger-FabricNetzwerks dargestellt (Abb. 2.29). In Fabric besteht eine Transaktion aus mehreren Komponenten. Der Header enthält die Metadaten der Transaktion und das Proposal die Eingabeparameter für die gewünschte

Abb. 2.29 Architektur Hyperledger Fabric. (In Anlehnung an [97])

80

S. Schacht

Abb. 2.30 Transaktionsablauf Hyperledger Fabric. (In Anlehnung an [25])

Ledger-Änderung. Im Response-Feld stehen die nach ausgeführter Transaktion erstellten Vorher-Nachher-Werte und das Endorsement-Feld beinhaltet eine Liste von unterschiedlichen Transaktionsantworten der beteiligten Organisationen, die erforderlich sind, damit diese Transaktion als valide definiert werden kann. Die Definition, wie viele Antworten hierfür notwendig sind, wird mittels der Endorsement-Policy definiert [42]. Nachstehende Abbildung zeigt den Ablauf der Transaktionsdurchführung im Hyperledger-Fabric-Netzwerk auf (Abb. 2.30): Zunächst sendet ein Client über die API-Schnittstelle einen Transaktionsvorschlag an einen oder mehrere Endorser-Nodes. (Achtung: Nicht alle Nodes im Netzwerk müssen Endorser-Nodes sein!) Die Endorser-Nodes verifizieren die Transaktion, indem sie sie ggf. in einem Smart Contract simulieren und erzeugen im Ergebnis eine Endorsement-Signatur, die an den Client zurückgeschickt wird. Der Client bündelt alle erhaltenen EndorsementSignaturen in der Transaktion und sendet diese validierte Transaktion an einen der OrdererNodes, der die Transaktion chronologisch einordnet und einem Block hinzufügt, sowie die Richtigkeit aller Endorsement-Responses noch einmal überprüft. Anschließend verteilt der Orderer-Node diesen Block an andere Peers im gesamten Netzwerk und sorgt damit dafür, dass alle Nodes den gleichen neuen Stand des Ledgers besitzen [25]. Hyperledger Fabric ist als permissioned Blockchain für Unternehmen aus mehreren Gründen interessant. Einerseits besteht die Möglichkeit, über das Berechtigungssystem der Membership-Services festzulegen, wer welchen Zugriff auf das Fabric-Netzwerk bekommen soll. Außerdem können Channels, also Kommunikations- bzw. Interaktionskanäle zwischen beteiligten Unternehmen innerhalb der Blockchain, aufgebaut werden, auf denen Unternehmensinformationen nur den Unternehmen zur Verfügung gestellt werden können, die an einem Prozess beteiligt sind. Und das alles, ohne auf die Vorteile der Distributed-LedgerTechnologie zu verzichten.

2 Die Blockchain-Technologie

81

Tab. 2.3 Übersicht Permissioned-Blockchain-Plattformen Metriken

Hyperledger Ethereum Fabric

Quorum

R3 Corda

Multichain

Datendurchsatz (Transaktionen pro Sekunde)

>2000 tps

∼150 tps

∼170 tps

∼750 tps

Konsens

– Proof-ofVerschiedene Work Mechanismen möglich – Pluggable Konsens

– Verschiedene Mechanismen möglich – Pluggable Konsens

– Verschieden Mechanismen möglich – Pluggable Konsens

similar to Practical Byzantine Fault Tolerance (PBFT)

Komplexe Queries möglich

Ja

Nein

Ja

Nein

Private Kanäle/DB

Multiple private Kanäle zwischen den Teilnehmern

Eigene private Datenbanken pro Node möglich

Daten sind Multichain by design Streams privat für an Transaktionen beteiligte Parteien

Cryptocurrencies

∼200 tps

Nein

Ether

Ether

Zero Knowledge Proof

Ja

Nein

Ja

Nein

Nein

Transaction Endorsement

Ja

Nein

Nein

Nein

Nein

Mandantenfähigkeit

Ja, mittels Channels möglich

Nein

Nein

Ja, by design privat und Multimandantenfähig

Ja, mittels Multichain Streams möglich

Privatsphäre bei Transaktionen

Bedingt: Nein Mittels Channels möglich, aber Mitglieder des Channels haben Zugriff

Ja

Alle Transaktionen sind privat und werden nur von den Beteiligten gesehen

Bedingt: Mittels Stream möglich, aber Mitglieder des Streams haben Zugriff

Smart Contract Programmiersprache

Golang, Solidity Java, NodeJS

Solidity

Kotlin, Java

Smart Filter: Javascript

82

S. Schacht

Ergänzend liefert Hyperledger durch den modularen Aufbau und die Tatsache, dass der Zustand in einer Datenbank gespeichert wird, vereinfachte Auswertungsmöglichkeiten, die gegebenenfalls die Anwendung von maschinellem Lernen in diesem Kontext vereinfachen können. Weitere Permissioned-Blockchain-Plattformen Neben Hyperledger und Ethereum existieren noch weitere Frameworks zur Implementierung von permissioned Blockchains. Die bekanntesten sind Corda R3, Multichain und Quorum. Tab. 2.3 vergleicht diese Technologien der Vollständigkeit halber:

2.4

Ausblick

Der hier dargestellte Überblick der Distributed-Ledger-Technologie zeigt auf, dass es sich bei der DLT um eine Infrastrukturtechnologie handelt, mit der automatisierte vertrauenswürdige Transaktionen zwischen sich nicht kennenden Marktteilnehmern ohne die Verwendung von Intermediären möglich ist. Diese Infrastrukturtechnologie ermöglicht einerseits die Reduzierung der Transaktionskosten und schafft andererseits standardisierte Datenverarbeitungskanäle. Diese werden durch dezentrale Applikationen oder sogar dezentrale autonome Organisationen (DAO) auf Basis der Smart Contracts genutzt, um zwischen den Teilnehmern einen großen Automatisierungsgrad zu erreichen. Da aber derartig automatisierte Prozesse momentan nur für Abläufe mit einfachen Wenn-Dann-Entscheidungen möglich sind, wäre es sinnvoll, machinelles Lernen als Entscheidungsgrundlage für solche Smart Contracts bzw. dezentrale autonome Organisationen zu verwenden. In den nachstehenden Kapiteln sollen dem Leser zunächst die Grundlagen des maschinellen Lernens erläutert werden, um dann zu eruieren, ob es möglich, ist maschinelles Lernen als Unterstützung für die Distributed-Ledger-Technologie zu verwenden oder ob sogar die DL-Technologie als Infrastrukturtechnik maschinelles Lernen z. B. zur Verbesserung der Prozesstransparenz herangezogen werden kann.

Literatur 1. Acheson, N.: What is the difference between an algorithm and a protocol, and why does it matter? https://www.linkedin.com/pulse/what-difference-between-algorithm-protocol-whydoes-matter-acheson/ (2016). Zugegriffen: 25. März 2019 2. Adler, J., Berryhill, R., Veneris, A., Poulos, Z., Veira, N., Kastania, A.: Astraea: a decentralized blockchain oracle. In: 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), S. 1145–1152 (2018). https://doi.org/ 10.1109/Cybermatics_2018.2018.00207

2 Die Blockchain-Technologie

83

3. Allam, Z.: On smart contracts and organisational performance: a review of smart contracts through the blockchain technology. Rev. Econ. Bus. Stud. 11(2), 137–156 (2019). https://doi. org/10.1515/rebs-2018-0079 4. Antonopoulos, A.M.: Bitcoin & Blockchain. dpunkt, Heidelberg (2019) 5. Antonopoulos, A.M., Wood, G.: Mastering Ethereum: Building Smart Contracts and DApps. O’Reilly Media, Incorporated, Sebastopol (2018) 6. Ashish: Introduction to Zero Knowledge Proof: the protocol of next generation blockchain. https://medium.com/coinmonks/introduction-to-zero-knowledge-proof-the-protocol-of-nextgeneration-blockchain-305b2fc7f8e5. Zugegriffen: 24. Apr. 2019 7. Bach, L.M., Mihaljevic, B., Zagar, M.: Comparative analysis of blockchain consensus algorithms. In: 41st International Convention on Information and Communication Technology, Electronics and Microelectronics, MIPRO 2018 – Proceedings, S. 1545–1550 (2018). https://doi.org/10. 23919/MIPRO.2018.8400278 8. Back, A.: Hashcash – a denial of service counter-measure. http://www.hashcash.org/papers/ hashcash.pdf (2002). Zugegriffen: 14. Apr. 2019 9. Badr, B.: Blockchain by Example. Packt Publishing, Birmingham (2018) 10. Baird, L.: Hashgraph consensus: detailed examples (2016a) 11. Baird, L.: The Swirlds Hashgraph consensus algorithm. https://www.swirlds.com/downloads/ SWIRLDS-TR-2016-01.pdf (2016b). Zugegriffen: 22. Mai 2019 12. Baird, L.: Hashgraph consensus algorithm. https://www.youtube.com/watch?v=cje1vuVKhwY (2018). Zugegriffen: 5. März 2019 13. Baird, L., Harmon, M., Madsen, P.: Hedera: a public hashgraph network & governing council. https://www.hedera.com/hh-whitepaper-v1.5-190219.pdf (2019). Zugegriffen: 22. Mai 2019 14. Benet, J., Greco, N.: Filecoin: a decentralized storage network. https://filecoin.io/filecoin.pdf (2017). Zugegriffen: 22. Mai 2019 15. Bergquist, J.: Blockchain Technology and Smart Contracts: Privacy-preserving Tools (2017) 16. BitcoinWiki: Proof-of-stake. https://en.bitcoinwiki.org/wiki/Proof-of-stake. Zugegriffen: 10. Dez. 2018 17. Blockexplorer: Blockexplorer – Bitcoin. https://blockexplorer.com/block/ 0000000000000000001fe83840cb301b35cf30e5b9f6ee812b78246dcc31b187 (2019). Zugegriffen: 5. Juni 2019 18. Blockgeeks: Proof of Work (Arbeitsnachweis) vs. Proof of Stake (Anteilsnachweis): Grundlegende Anleitung für das Mining – Blockgeeks. https://blockgeeks.com/guides/de/proof-ofwork-arbeitsnachweis-vs-proof-of-stake-anteilsnachweis/ (2019). Zugegriffen: 21. Apr. 2019 19. Bostoen, J.: A Hands-on Introduction to IPFS. https://medium.com/coinmonks/a-hands-onintroduction-to-ipfs-ee65b594937 (2018). Zugegriffen: 29. Mai 2019 20. BSI: Asymmetrische Verschlüsselung. https://www.bsi-fuer-buerger.de/BSIFB/DE/ Empfehlungen/Verschluesselung/Verschluesseltkommunizieren/Grundlagenwissen/ AsymmetrischeVerschluesselung/asymmetrische_verschluesselung.html (2018). Zugegriffen: 10. Nov. 2018 21. BTC Echo: Beginner: IPFS für Blockchains – Wie funktioniert IPFS? https://www.btc-echo.de/ tutorial/ipfs-fuer-blockchains/ (2018). Zugegriffen: 29. Mai 2019 22. Burkhardt, D., Werling, M.: Distributed ledger. In: IEEE International Conference on Engineering, Technology and Innovation (ICE/ITMC), S. 1–9 (2018). https://doi.org/10.1109/ICE.2018. 8436299 23. Castro, M., Liskov, B.: Practical Byzantine Fault Tolerance. In: OSDI 1999: Proceedings of the Third Symposium on Operating Systems Design and Implementation SE – OSDI 1999, S. 173–186 (1999). https://doi.org/10.1145/4221.214134

84

S. Schacht

24. Chase, B., MacBrough, E.: Analysis of the XRP ledger consensus protocol. CoRR abs/1802.07242 (2018) 25. Choudhury, O., Sarker, H., Rudolph, N., Foreman, M., Fay, N., Dhuliawala, M., Sylla, I., Fairoza, N., Das, A.K.: Enforcing human subject regulations using blockchain and smart contracts. Blockchain in healthcare today, S. 1–14 (2018). https://doi.org/10.30953/bhty.v1.10 26. Condon, M.: Getting up to speed on ethereum. https://medium.com/@mattcondon/getting-upto-speed-on-ethereum-63ed28821bbe (2017). Zugegriffen: 11. Juni 2019 27. Curran, B.: What are Oracles? Smart Contracts, Chainlink & „The Oracle Problem“. https:// blockonomi.com/oracles-guide/ (2019). Zugegriffen: 5. Juni 2019 28. DAO.casinos: What is IPFS: overview and use cases. https://dao.casino/blog/what-is-ipfs/ (2018). Zugegriffen: 29. Mai 2019 29. Di Marzo Serugendo, G., Gleizes, M.P., Karageorgos, A.: Self-organising software: from natural to artificial adaptation. Nat. Comput. Ser. 37, 1–26 (2011). https://doi.org/10.1007/978-3-64217348-6 30. Ethersphere: IPFS & SWARM SWARM – IPFS. https://github.com/ethersphere/go-ethereum/ wiki/IPFS-&-SWARM (2017). Zugegriffen: 3. Juni 2019 31. Florea, B.C.: Blockchain and internet of things data provider for smart applications. In: 2018 7th Mediterranean Conference on Embedded Computing (MECO), S. 1–4 (2018). https://doi.org/ 10.1109/MECO.2018.8406041 32. Follow, T.R.: Hashgraph for dummies. https://medium.com/ibbc-io/hashgraph-for-dummies90ddde3be9e2 (2017). Zugegriffen: 22. Apr. 2019 33. Gal, A.: The Tangle: an illustrated introduction IOTA Part 3. https://blog.iota.org/the-tangle-anillustrated-introduction-f359b8b2ec80 (2018a). Zugegriffen: 13. Mai 2019 34. Gal, A.: The Tangle: an illustrated introduction IOTA Part 4. https://blog.iota.org/the-tangle-anillustrated-introduction-1618d3e140ad (2018b). Zugegriffen: 13. Mai 2019 35. Gal, A.: The Tangle: an illustrated introduction IOTA Part 5: consensus, confirmation confidence, and the coordinator. https://blog.iota.org/the-tangle-an-illustrated-introduction-79f537b0a455 (2018c). Zugegriffen: 13. Mai 2019 36. GEOFF MCCABE: Introducing our lightning network. https://blog.diviproject.org/chainlightning-network/ (2019). Zugegriffen: 6. Mai 2019 37. Giang Truong, N., Kyungbaek, K.: A survey about consensus algorithms used in blockchain. J. Inf. Process. Syst. 14(1), 101–128 (2018). https://doi.org/10.3745/JIPS.01.0024 38. Graff, C., Stoiber, H., Zscherp, M.: Plattformsicherheit: Smart Contracts und TPM. shortcuts. entwickler.Press (2015) 39. Grassegger, H.: Die erste Firma ohne Menschen. https://www.zeit.de/digital/internet/2016-05/ blockchain-dao-crowdfunding-rekord-ethereum. Zugegriffen: 5. Mai 2019 40. Hu, J.: IOTA Tangle: introductory overview of white paper for Beginners. https://hackernoon. com/iota-tangle-introductory-overview-of-white-paper-for-beginners-df9b14882b64. Zugegriffen: 12. Mai 2019 41. Hyperledger: https://www.hyperledger.org/members. Zugegriffen: 20. Juni 2019 42. Hyperledger: Hyperledger documentation. https://hyperledger-fabric.readthedocs.io/en/release1.4/. Zugegriffen: 5. Mai 2019 43. Hyperledger: The hyperledger greenhouse. https://www.hyperledger.org/. Zugegriffen: 5. Mai 2019 44. IDC: New IDC Spending Guide Sees Strong Growth in Blockchain Solutions Leading to USD 15.9 Billion Market in 2023. IDC. https://www.idc.com/getdoc.jsp?containerId=prUS45429719 (2019). Zugegriffen: 10. Aug. 2019 45. Infante, R.: Building Ethereum Dapps. Manning Publications Co., Shelter Island (2019)

2 Die Blockchain-Technologie

85

46. IOTA Foundation: Overview | Introduction | The Tangle | IOTA Documentation. https://docs. iota.org/docs/the-tangle/0.1/introduction/overview (2018). Zugegriffen: 13. Mai 2019 47. Jean-Jacques, Q.: How to explain zero knowledge protocol. http://pages.cs.wisc.edu/~mkowalcz/ 628.pdf. Zugegriffen: 8. Mai 2019 48. Jlledom: Number of keys when using symmetric and asymmetric encryption? https:// crypto.stackexchange.com/questions/16075/number-of-keys-when-using-symmetric-andasymmetric-encryption (2015). Zugegriffen: 21. März 2019 49. Kammerer, M.: IOTA die nächste Generation der Blockchain? | heise Developer. https://www. heise.de/developer/artikel/IOTA-die-naechste-Generation-der-Blockchain-4208154.html? seite=all (2018). Zugegriffen: 17. Mai 2019 50. Kasireddy, P.: Let’s take a crack at understanding distributed consensus. https://medium.com/ s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95 (2018). Zugegriffen: 4. Apr. 2019 51. King, S.: Primecoin: Cryptocurrency with Prime Number Proof-of-Work. http://primecoin.io/ bin/primecoin-paper.pdf (2013). Zugegriffen: 13. Mai 2019 52. Kostas (Konstantinos) Chalkias: Demonstrate how Zero-Knowledge Proofs work without using maths. https://www.linkedin.com/pulse/demonstrate-how-zero-knowledge-proofs-workwithout-using-chalkias/ (2017). Zugegriffen: 25. Apr. 2019 53. Krawisz, D.: The proof-of-work concept. https://nakamotoinstitute.org/mempool/the-proof-ofwork-concept/ (2013). Zugegriffen: 21. Dez. 2018 54. Kruse, D.: Asymmetrische Verschlüsselung einfach erklärt. http://www.dkruse.de/dokumente/ netzwerke/Sicher3_Asymm_Verschluesselung.pdf. Zugegriffen: 11. Febr. 2019 55. Kumar, R: IPFS: a complete analysis of the distributed web. https://blog.goodaudience.com/ipfsa-complete-analysis-of-the-distributed-web-18ad66bf47e7 (2018). Zugegriffen: 29. Mai 2019 56. Lamport, L., Shostak, R., Pease, M.: The Byzantine Generals Problem. ACM Trans. Program. Lang. Syst. 4(3), 382–401 (2002). https://doi.org/10.1145/357172.357176 57. Lerner, S.D.: DagCoin draft. https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf (2015). Zugegriffen: 13. Mai 2019 58. Lewrick, M., Giorgio, C.D.: Live aus dem Krypto-Valley. Vahlen, München (2018). https://doi. org/10.1002/ange.201505829.Das 59. Linefeed, Schmitz, P.: Was ist ein Hash? https://www.security-insider.de/was-ist-ein-hash-a635712/ (2017). Zugegriffen: 10. Nov. 2018 60. Liskov, B., Castro, M., Karumuri, S.: Practical Byzantine Fault Tolerance. https://de.slideshare. net/mansu/practical-byzantine-fault-tolerance (2019). Zugegriffen: 12. Dez. 2018 61. Liu, Z., Luong, N.C., Wang, W., Niyato, D., Wang, P., Liang, Y., Kim, D.I.: A survey on applications of game theory in blockchain. CoRR abs/1902.10865 (2019) 62. Lynch, V.: Re-Hashed: The Difference Between SHA1-, SHA-2 and SHA-256 Hash Algorithms. https://www.thesslstore.com/blog/difference-sha-1-sha-2-sha-256-hash-algorithms/ (2018). Zugegriffen: 15. Nov. 2018 63. Marcus Misiak: Bitcoin Transaktionskosten sinken weiter: Wie sich die Höhe bestimmt. https:// coin-hero.de/wie-sich-die-hoehe-von-bitcoin-transaktionskosten-bestimmt/ (2018). Zugegriffen: 6. Mai 2019 64. Marr, B.: Blockchain: a very short history of ethereum everyone should read. https://www.forbes. com/sites/bernardmarr/2018/02/02/blockchain-a-very-short-history-of-ethereum-everyoneshould-read/ (2018). Zugegriffen: 11. Juni 2019 65. Mazieres, D.: The stellar consensus protocol: a federated model for internet-level consensus. Stellar Development Foundation, S. 1–45 (2015). https://doi.org/10.1021/ja982417z 66. Meier, A., Stormer, H.: Blockchain=Distributed Ledger+Consensus. HMD Praxis der Wirtschaftsinformatik (2018). https://doi.org/10.1365/s40702-018-00457-7

86

S. Schacht

67. Moschner, F.: Entwicklung eines Konzepts für den unternehmensübergreifenden Austausch von VDA-Behälterdaten. Bachelor-thesis, Hochschule Heilbronn (2019) 68. Mourouzis, T., Tandon, J.: Introduction to decentralization and smart contracts. CoRR abs/1903.04806 (2019) 69. N. a.: A technical explanation of bitcoin for everyone. http://billybitco.in/. Zugegriffen: 2. Mai 2019 70. Nakamoto, S.: Bitcoin: a peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf (2008). Zugegriffen: 18. Apr. 2019 71. NICK SZABO: Smart Contracts: Formalizing and Securing Relationships on Public Networks. First Monday 2(9). https://ojphi.org/ojs/index.php/fm/article/view/548/469 (1997). Zugegriffen: 14. Apr. 2019 72. Nofer, M., Gomber, P., Hinz, O., Schiereck, D.: Blockchain. Business & Information. Sys. Eng. 59(3), 183–187 (2017). https://doi.org/10.1007/s12599-017-0467-3 73. Nolan, S.: pBFT understanding the algorithm. https://medium.com/coinmonks/pbftunderstanding-the-algorithm-b7a7869650ae. Zugegriffen: 24. Apr. 2019 74. noneymous: IOTA – adding a transaction. https://github.com/noneymous/iota-consensuspresentation/blob/master/README.md. Zugegriffen: 2. März 2019 75. Oliver Dale: What is chainlink coin (LINK) complete guide information & review. https:// blockonomi.com/chainlink-guide/ (2019). Zugegriffen: 5. Juni 2019 76. Oram, A.: Peer-to-Peer: Harnessing the Power of Disruptive Technologies. O’Reilly Media, Sebastopol (2001) 77. Pawczuk, L., Massev, R., Schatsky, D.: Breaking blockchain open Deloitte’s 2018 global blockchain survey. https://www2.deloitte.com/content/dam/Deloitte/cz/Documents/financialservices/cz-2018-deloitte-global-blockchain-survey.pdf (2018). Zugegriffen: 18. Juli 2019 78. Popov, S.: The tangle. http://www.vanderbilt.edu/viibre/members/documents/12960-WeinerNY-2005.pdf (2018). Zugegriffen: 28. Apr. 2019 79. Provable: The provable blockchain oracle for modern DApps. http://provable.xyz. Zugegriffen: 5. Mai 2019 80. Raj, K.: Foundations of Blockchain. Packt Publishing, Birmingham (2019) 81. Rauchs, M., Blandin, A., Klein, K., Pieters, G.C., Recanatini, M., Zhang, B.Z.: 2nd Global Cryptoasset Benchmarking Study. SSRN Electron. J. (2018). https://doi.org/10.2139/ssrn.3306125 82. Sara Technologies Inc.: Hedera Hashgraph, Consensus, and Scalability. https://medium.com/ @saratechnologiesinc/hedera-hashgraph-consensus-and-scalability-2315133a3e33 (2018). Zugegriffen: 20. Mai 2019 83. Schuster, S.: Die Umsetzung des Internet of Things basierend auf IOTA. Bachelorthesis, Hochschule Heilbronn (2019) 84. Schütte, J., Fridgen, G., Prinz, W., Rose, T., Urbach, N., Hoeren, T., Guggenberger, N., Welzel, C., Holly, S., Schulte, A., Sprenger, P., Schwede, C., Weimert, B., Otto, B., Dalheimer, M., Wenzel, M., Kreutzer, M., Fritz, M., Leiner, U., Nouak, A.: Blockchain und Smart Contracts – Technologien, Forschungsfragen und Anwendungen, S. 50. Fraunhofer-Gesellschaft, Stuttgart (2017) 85. Sompolinsky, Y., Zohar, A.: Secure high-rate transaction processing in bitcoin (full version). https://eprint.iacr.org/2013/881.pdf. Zugegriffen: 13. Mai 2019 86. Spilka, D.: Blockchain Versus Hashgraph | CoinCodex. https://coincodex.com/article/2715/ blockchain-versus-hashgraph/. Zugegriffen: 27. Mai 2019 87. Steinmetz, R., Wehrle, K.: Peer-to-Peer Systems and Applications. Springer, Berlin (2005) 88. Stevens, A.: Distributed ledger consensus explained – Hacker Noon. https://hackernoon.com/ distributed-ledger-consensus-explained-b0968d1ba087 (2018). Zugegriffen: 21. März 2019

2 Die Blockchain-Technologie

87

89. Town-Crier: Town crier – an authenticated data feed for smart contracts. https://www.town-crier. org. Zugegriffen: 5. Mai 2019 90. Vaidya, K.: Bitcoin’s implementation of blockchain. https://medium.com/all-things-ledger/ bitcoins-implementation-of-blockchain-2be713f662c2. Zugegriffen: 2. Mai 2019 91. Vaidya, K.: Decoding the enigma of bitcoin mining part I: mechanism. https://medium.com/ all-things-ledger/decoding-the-enigma-of-bitcoin-mining-f8b2697bc4e2. Zugegriffen: 2. Mai 2019 92. Vasin, P.: BlackCoin’s Proof-of-Stake Protocol v2 Pavel. Self-published. https://blackcoin.co/ blackcoin-pos-protocol-v2-whitepaper.pdf (2014). Zugegriffen: 14. Apr. 2019 93. Vollmer, J.: Was sind Zero-Knowledge-Proofs? https://t3n.de/news/eigenlich-zero-knowledgeproofs-1099164/ (2018). Zugegriffen: 25. Apr. 2019 94. Voshmgir, S.: Blockchains, Smart Contracts und das Dezentrale Web (2016) 95. Wahab, A., Mehmood, W.: Survey of consensus protocols. CoRR abs/1810.03357 (2018) 96. Wehrle, K., Steinmetz, R.: Peer-to-Peer-Systeme und -Anwendungen. Fachzeitschrift des Kompetenzzentrums eGovernment 2, 38–39 (2004) 97. Xu, X., Weber, I., Staples, M.: Architecture for Blockchain Applications. Springer International Publishing, Cham (2019) 98. Zcash: What are zk-SNARKs? https://z.cash/technology/zksnarks/ (2018). Zugegriffen: 20. Dez. 2018

3

Grundzüge des maschinellen Lernens Carsten Lanquillon

Zusammenfassung

In diesem Kapitel werden Grundzüge des maschinellen Lernens dargestellt. Ziel ist es, ein allgemeines Verständnis dafür zu schaffen, was maschinelle Lernverfahren leisten können. Neben bekannten Definitionen und einem kurzen Abriss über die Entstehung maschineller Lernverfahren werden insbesondere Unterscheidungsmerkmale und Varianten sowie gängige Aufgabentypen erläutert. Erst danach werden beispielhaft verschiedene Lernverfahren vorgestellt, die besonders eingängig oder typisch sind und oft in der Praxis zum Einsatz kommen. In praktischen Anwendungen spielt aufgrund der großen Datenmengen und zusätzlicher Anforderungen zum Datenschutz das verteilte Lernen eine immer wichtigere Rolle. Als Abschluss und gleichermaßen Überleitung zur Verbindung mit Blockchain-Technologie gilt der Ausblick am Ende des Kapitels.

3.1

Definition und Entwicklung

Das maschinelles Lernen (engl. machine learning) ist inzwischen allgegenwärtig: Die Filterung von Spam-Nachrichten, Produktempfehlungen, Handschrifterkennung, Erkennung von Objekten auf Bildern, Spracherkennung, selbstfahrende Autos, Erfolge in Strategiespielen wie Schach und Go. Jegliche Tätigkeiten, die eine regelmäßige Verarbeitung von Daten erfordern, lassen sich durch maschinelle Lernverfahren unterstützen. Aber was genau ist maschinelles Lernen und wie ist es entstanden?

C. Lanquillon (B) Hochschule Heilbronn, Heilbronn, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 S. Schacht und C. Lanquillon (Hrsg.), Blockchain und maschinelles Lernen, https://doi.org/10.1007/978-3-662-60408-3_3

89

90

3.1.1

C. Lanquillon

Informatik, KI und maschinelles Lernen

Die systematische und insbesondere automatische Verarbeitung von Informationen bzw. Daten mit Hilfe von Computern ist die Kernaufgabe der Informatik. Der Begriff Informatik leitet sich aus der Verschmelzung von Information und Automatik ab. Im Kern stehen somit Programme, die Informationen bzw. eher Daten ausgehend von einer Eingabe in eine Ausgabe transformieren, mit dem Ziel, damit ein Problem zu lösen (siehe Abb. 3.1). Traditionell obliegt die Erstellung dieser Programme den Menschen. Dabei gibt es eine große Vielfalt an Problemen, von einfachen bis äußerst komplexen und zeitaufwendigen oder gar (fast) unmöglich zu lösenden. Dies kann die Verarbeitung der Eingabeinformationen also auch die Erstellung des Programms betreffen. Ein Tier auf einem Foto als Katze zu identifizieren, ist selbst für die meisten Kinder eine einfache Aufgabe. Jemandem zu erklären, woran man eine Katze genau erkennt, ist schon etwas schwieriger. Die explizite Erstellung eines Programms, das diese Aufgabe löst, ist dagegen alles andere als trivial. Es gibt eine Vielzahl derartiger Probleme, insbesondere im Umfeld der künstlichen Intelligenz (KI). Im Kern ist das Ziel dort, Probleme zu lösen, die dem Menschen leicht fallen, für die eine gewisse Form an Intelligenz notwendig zu sein scheint. So kann der menschliche Prozess der Entscheidungsfindung etwa durch Expertensysteme unterstützt werden. Regelbasierte Systeme sind in diesem Umfeld sehr verbreitet. Die manuelle Modellierung der für diese Systeme erforderlichen Fakten und Regeln als Wissensbasis ist sehr aufwendig, kostenintensiv und oft auch fehleranfällig. Diese Schwierigkeit ist weithin als knowledge acquisition bottleneck bekannt. Lässt sich das Wissen nicht automatisch aus Erfahrungen ableiten, die in Form von Daten vorliegen? Die anfängliche Entwicklung des maschinellen Lernens als Teilbereich der KI kann als Antwort zur Lösung dieses Problems gedeutet werden. Inzwischen kann das maschinelle Lernen sogar als Schlüsseltechnologie zur Lösung von KI-Aufgaben betrachtet werden und kommt auch in zahlreichen Anwendungsbereichen zum Einsatz, die nicht direkt der KI zugeordnet werden.

3.1.2

Machine-Learning-Definitionen

Das maschinelle Lernen ist der Teilbereich der KI bzw. allgemeiner der Informatik, der sich damit befasst, Computer Probleme lösen zu lassen, ohne sie dafür explizit zu programmieren: Abb.3.1 Informationsverarbeitung: Eine Eingabe wird auf eine Ausgabe abgebildet

3 Grundzüge des maschinellen Lernens

91

Abb. 3.2 Programmierung auf klassische Weise (links) und durch maschinelles Lernen (rechts)

Machine learning is the field of study that gives computers the ability to learn without being explicit programmed.1 – Arthur L. Samuel, 1959

Auch wenn sehr häufig die Lernverfahren, mit denen aus Daten gelernt wird, im Vordergrund stehen, so geht es um weit mehr als nur diese. Vielmehr ist es eine umfassende Art und Weise, wie Probleme gelöst werden. Nach und nach wird der menschliche Aufwand für das Programmieren abnehmen und eine neue Ära der Softwareentwicklung ist bereits eingeleitet. So ist es auch möglich, Systeme zu entwickeln, die sich den Anforderungen und Bedürfnissen der Anwender und Anwenderinnen anpassen können. Abstrakt gesehen geht es daher darum, das Automatisieren zu automatisieren. Wie ist das möglich? Welche Problemlösungen lassen sich überhaupt automatisieren? Normalerweise berechnet ein Programm aus einer Eingabe eine Ausgabe. Das maschinelle Lernen dreht dieses grundlegende Prinzip der Informatinonsverarbeitung um: Aus einer Eingabe und der gewünschten Ausgabe als gemeinsame Eingabe eines Lernverfahrens erstellt dieses ein Programm, das die Eingabe in die gewünschte Ausgabe überführen kann. Das vom Lernverfahren erzeugte Programm wird beim maschinellen Lernen auch Modell genannt. Dieser Unterschied ist in Abb. 3.2 dargestellt. Somit können Computer durch maschinelles Lernen ihre eigenen Programme schreiben und sind nicht auf die Programmierung durch den Menschen angewiesen [15]. Die Erstellung eines Modells aus Erfahrungen, die in Form von Daten vorliegen, wird als Lernphase oder auch Trainingsphase bezeichnet. Die dabei verwendeten Daten sind entsprechend die Trainingsdaten. Sehr oft werden diese Modelle in der folgenden Anwendungsphase (engl. model deployment) als Vorhersagemodelle verwendet, um für neue Eingabedaten die zuvor unbekannten Ausgaben zu bestimmen. In einigen Fällen ist jedoch auch das aus der Lernphase resultierende Modell als Beschreibung oder Zusammenfassung der Eingabedaten von Interesse. Durch geeignete Interpretation kann ein Modell dann zu neuen Erkenntnissen im Kontext der Anwendungsdomäne führen. Diese verschiedenen Anwendungsszenarien werden in Abschn. 3.3 näher betrachtet. Auch wenn der Begriff maschinelles Lernen dies suggeriert, ein echtes Lernen, wie wir es als Menschen kennen, findet in der Lernphase nicht statt. In anderen Fachbereichen spricht man daher auch weniger aufregend von der Anpassung (engl. fitting) eines Modells an Daten oder dem Schätzen der Parameter eines Modells. Letztlich handelt es sich um ein Optimie1 Diese frühe und oft zitierte Definition des maschinellen Lernens ist auch heute noch äußerst treffend.

Als Quelle wird meist ein Artikel des KI-Pioniers Arthur L. Samuel angegeben [34]. Allerdings findet sich in der verfügbaren Version des Artikels dieses Zitat nicht direkt.

92

C. Lanquillon

rungsproblem, bei dem basierend auf gegebenen Trainingsdaten und unter Berücksichtigung einer konkreten Aufgabe (Ziel), das beste oder ein möglichst gutes Modell in der Menge aller möglichen Modelle gesucht wird. Die Herausforderung dabei ist, dass der Suchraum sehr groß ist. Um die Suche erfolgreich gestalten zu können, müssen gewisse Einschränkungen, Annahmen und Vorgaben (engl. bias) gemacht werden. Bei der Entwicklung und auch Anwendung maschineller Lernverfahren ist es wichtig, diese zu kennen. Um Lernverfahren und ihre Voraussetzungen und Annahmen besser zu erfassen, muss das maschinelle Lernen operationalisiert werden. Tom Mitchell definiert das maschinelle Lernen daher konkreter: A computer program is said to learn from experience E with respect to some class of tasks T and performance measure P, if its performance at tasks in T , as measured by P, improves with experience E. – Tom Mitchell [29]

Beispielsweise kann die Aufgabe T (engl. task) darin bestehen, E-Mails als Spam zu erkennen. Ein sinnvolles Maß zur Bewertung einer Lösung für diese Aufgabe könnte die Genauigkeit sein, mit der diese Entscheidungen getroffen werden, und die Erfahrung E ist die Menge aller verfügbaren E-Mails, für die bereits bekannt ist, ob sie Spam sind oder nicht. Bei einer prozessorientierten Betrachtung hat das maschinelle Lernen das Ziel, ein Modell zur Beschreibung von Daten oder zur Vorhersage zu erstellen, und behandelt Vorgehensweisen, Technologien und Werkzeuge, um dieses Ziel zu erreichen. Als wissenschaftliche Disziplin kommt als elementarer Untersuchungsgegenstand auch der Lernprozess selbst dazu. So formuliert Tom Mitchell in einer Ergänzung seines bekannten Maschine-LearningLehrbuchs die zentralen Fragen des maschinellen Lernens wie folgt: How can we build computer systems that automatically improve with experience, and what are the fundamental laws that govern all learning processes? – Tom Mitchell

Wie kann ein Computer aus Erfahrungen in Form von Daten lernen? Welche Daten werden dafür benötigt? Welche Aufgaben werden gelöst und welche gängigen Lernverfahren gibt es dafür? Da das maschinelle Lernen nicht die einzige Disziplin ist, die aus Daten lernt, werden im nächsten Abschnitt das maschinelle Lernen anderen Disziplinen gegenübergestellt und Gemeinsamkeiten und Unterschiede identifiziert. Erst danach werden Antworten auf die oben gestellten Fragen durch ein kompaktes Zusammenfassen der elementaren Ideen und Ansätze aus dem maschinellen Lernen gefunden. Ziel dabei ist ein allgemeines Verständnis der Funktionsweise und ein Verständnis über Annahmen und Voraussetzungen für die Nutzung und nicht eine vollständige und mathematisch tiefe Darstellung möglichst vieler Verfahren.

3 Grundzüge des maschinellen Lernens

3.1.3

93

Maschinelles Lernen und verwandte Disziplinen

Das maschinelle Lernen kommt inzwischen in zahlreichen Anwendungsbereichen zum Einsatz. Aus dem Bereich der künstlichen Intelligenz hervorgegangen hat sich das maschinelle Lernen schon zu einem eigenständigen Bereich entwickelt, in dem Probleme gelöst werden, die über die klassischen Probleme aus der künstlichen Intelligenz hinausgehen. Je nach Präferenz und gewählter Perspektive lassen sich unterschiedliche Schwerpunkte im maschinellen Lernen definieren. Während bei einer kognitionsorientierten Sichtweise Lernprozesse als solche zu verstehen angestrebt wird und bei einer theoretischen Betrachtung die Untersuchung dessen, was mit welchem Ressourcenbedarf erlernbar ist, im Vordergrund steht, sollen bei einer anwendungsorientierten Sichtweise durch maschinelle Lernverfahren erzeugte Ergebnisse in konkreten Anwendungen zur Lösung praktischer Probleme zum Einsatz kommen [41]. Das maschinelle Lernen kommt in unterschiedlichsten Facetten in Anwendungen vor, in denen aus Daten Erkenntnisse zur Lösung praktischer Probleme abgeleitet werden sollen, und ist unter vielen verschiedenen Namen geläufig: Mustererkennung, statistische Modellierung, Data Mining, Wissensentdeckung in Datenbanken, Predictive Analytics und Data Science sind einige der bekannteren Begriffe [15]. Für einige sind diese Begriffe Synonyme für das maschinelle Lernen, andere sehen gewisse Unterschiede. Im folgenden sollen Gemeinsamkeiten und Unterschiede in der Sichtweise und Wahrnehmung einiger dieser Disziplinen im Vergleich zum maschinellen Lernen betrachtet werden.

3.1.3.1 Statistik Statistik ist sicherlich die älteste namentlich erfasste Disziplin, die sich mit der Sammlung, Aufbereitung, Analyse und Interpretation von Daten befasst. Ziele der angewandten Statistik sind die Beschreibung der gesammelten Daten (deskriptive Statistik) und deren Erkundung (explorative Statistik) sowie die Überprüfung von Aussagen (Hypothesen) über oder das Schließen auf Strukturen in einer Grundgesamtheit (induktive Statistik) basierend auf den vorliegenden Daten. Schon innerhalb der Statistik gibt es unterschiedliche Strömungen und sich widersprechende Auffassungen, wie mit bestimmten Problemtypen umzugehen ist. Beispielhaft sei die explorative Statistik oder auch explorative Datenanalyse (EDA) erwähnt, die auf [38] zurückgeht. Er verlangte, dass neben der klassischen Überprüfung von Hypothesen auch deren Erzeugung aus vorliegenden Daten ein wichtiger Aspekt sei. Die explorative Datenanalyse weist hinsichtlich der Vorgehensweise bei der Verwendung von Daten die größte Gemeinsamkeit mit dem maschinellen Lernen auf und kann gar als Vorreiter für das Data Mining gesehen werden. Das maschinelle Lernen bedient sich einerseits der Methoden der Statistik und hat andererseits Methoden eigenständig entwickelt. Es gibt eine große Überlappung und auf den

94

C. Lanquillon

ersten Blick erscheint zumindest ein Teil der Statistik, das statistische Lernen, synonym zum maschinellen Lernen zu sein. Während in der Statistik oftmals mehr Wert auf die theoretischen Aspekte von Lernverfahren und der Überprüfung der Anwendbarkeit von Lernverfahren und schließlich auf deren Signifikanz und Robustheit sowie Erklärbarkeit gelegt wird, steht beim maschinellen Lernen häufiger Vorhersagegüte von Modellen im Vordergrund. Um die Fähigkeit zum Generalisieren zu bewerten, wurden daher eigene Konzepte wie das Verwenden separater Trainingsund Testdaten sowie die Kreuzvalidierung entwickelt. Mit Wurzeln in der Informatik geht es beim maschinellen Lernen stärker als in der Statistik auch um die Fähigkeit, mit größeren Datenmengen effizient umzugehen und die Lernfähigkeit in Systeme und Anwendungen zu integrieren, anstatt ausschließlich die Menschen bei ihren Anwendungen unmittelbar zu unterstützen.

3.1.3.2 Wissensentdeckung in Datenbanken und Data Mining Gerade im anwendungsorientierten Kontext bildet das maschinelle Lernen eine sehr große Schnittmenge mit den Disziplinen Data Mining bzw. der Wissensentdeckung in Daten bzw. Datenbanken (engl. knowledge discovery in databases, kurz KDD) und Data Science. Data Mining wurde anfangs oft noch als Teilschritt in einem Prozess der Wissensentdeckung betrachtet. Inzwischen werden allerdings Data Mining und die Wissensentdeckung in Daten oft synonym verwendet. So ist auch Data Mining der Prozess zum Entdecken interessanter Muster und Zusammenhänge in meist großen Datenbeständen. Die beim Data Mining behandelten Aufgaben decken sich weitgehend mit den Aufgaben des maschinellen Lernens, die im Folgenden vorgestellt werden. Wenn die Aufgaben praktisch weitgehend identisch sind, müssten dann Data Mining und maschinelles Lernen nicht tatsächlich dasselbe sein? Oberflächlich betrachtet erscheint es so. Oft werden die Begriffe Data Mining und maschinelles Lernen sogar synonym verwendet. Zumindest aber überschneiden sich die Disziplinen extrem stark. Und in vielen Bereichen könnten die Begriffe problemlos gegeneinander ausgetauscht werden. Unterschiede bestehen jedoch insbesondere in der Zielsetzung und in der Durchführung hinsichtlich der Einbindung des Menschen in den Prozess der Modellerzeugung. Beim maschinellen Lernen ist die Leistungsfähigkeit der Modelle, d. h. insbesondere die Güte der vorhergesagten Werte von zentraler Bedeutung. Beim Data Mining geht es neben der Vorhersageleistung oft auch stark um die Interpretierbarkeit der Ergebnisse und somit letztlich um den Erkenntnisgewinn beim Menschen im Kontext der Anwendung. Während beim maschinellen Lernen die Lernprozesse eher automatisiert ablaufen, ist der Analyseprozess beim Data Mining sehr oft auch interaktiv (semi-automatisch). Auf diese Art und Weise kann viel leichter Expertenwissen in die Analyse einfließen.

3 Grundzüge des maschinellen Lernens

95

3.1.3.3 Mustererkennung Die Mustererkennung (engl. pattern recognition) als eigene Disziplin hat sich im Fachbereich der Elektrotechnik entwickelt und befasst sich weitgehend mit denselben Aufgabentypen wie das maschinelle Lernen, so dass beide als zwei Seiten desselben Aufgabenbereichs betrachtet werden können [4, S. vii].

3.1.3.4 Data Science als Oberbegriff Angewandte Statistik, Data Mining, Pattern Recognition gehören zu den Disziplinen, die sich am stärksten mit dem maschinellen Lernen überlappen. In der Praxis sind sie oft gar nicht auseinanderzuhalten. Die behandelten Aufgaben sind oftmals identisch, jedoch gibt es aufgrund der historischen Entwicklungen Unterschiede in den verwendeten Begriffen und Notationen sowie unterschiedliche Betrachtungsweisen über die Art und Weise, wie Methoden zur Lösung der Aufgaben eingesetzt werden sollten. Es haben sich viele Methoden und Vorgehensweisen unabhängig in den verschieden Disziplinen entwickelt, aber sie haben sich auch gegenseitig befruchtet. Es bestehen fachspezifische wissenschaftliche Gemeinschaften mit entsprechenden Organisationen, Konferenzen und Fachzeitschriften. Dennoch findet inzwischen ein verstärkter Austausch statt und die Disziplinen wachsen zumindest inhaltlich immer stärker zusammen. Seit einigen Jahren wird der Begriff Data Science immer häufiger verwendet. Er lässt sich in gewisser Weise als Oberbegriff für die oben genannten Disziplinen und letztlich aller Disziplinen auffassen, die sich mit der systematischen Sammlung, Speicherung, Aufbereitung, Beschreibung, Analyse, Visualisierung, Präsentation und Interpretation von Daten mit dem Ziel des Erkenntnisgewinns und der Erzeugung von Mehrwert in Anwendungen befassen.

3.2

Lernformen: Wie wird gelernt?

Maschinelles Lernen ist inzwischen allgegenwärtig und unterstützt insbesondere die Tätigkeiten, die eine regelmäßige Verarbeitung von Daten erfordern. Paradoxerweise sind für das maschinelle Lernen die Probleme, die für Menschen schwierig sind, vergleichsweise einfach, während für den Menschen einfache Tätigkeiten erstaunlich schwierig zu lösen sind.2 Abstrahiert man von den unzähligen Anwendungen, so kristallisieren sich einige wenige typische Aufgaben heraus. Sie geben schließlich eine Antwort auf die Frage, welche Probleme gelöst werden können. So läge es nahe, den Einstieg in die Möglichkeiten, die das maschinelle Lernen bietet, mit einer Beschreibung der Aufgaben zu beginnen. Jedoch stehen diese Möglichkeiten in engem Zusammenhang mit den verfügbaren Eingaben und der Art und Weise, wie daraus gelernt wird. Daher beginnen auch wir mit einer Beschreibung der 2 Hard thinks are easy, but easy things are hard. (Moravec’sches Paradox) [30].

96

C. Lanquillon

gängigen Lernformen des maschinellen Lernens: überwachtes Lernen, unüberwachtes Lernen, die Mischform halbüberwachtes Lernen und bestärkendes Lernen. Es ist zu beachten, dass sich die Lernformen nicht gegenseitig ausschließen müssen und oft auch Kombinationen zur Anwendung kommen. In Abhängigkeit der Lernformen werden dann im folgenden Abschnitt die gängigsten Aufgabentypen vorgestellt.

3.2.1

Überwachtes Lernen

Beim überwachten Lernen (engl. supervised learning) soll anhand von Beispielen, das sind Eingabe-Ausgabe-Paare, eine Funktion bestimmt werden, die gegebene Eingabewerte auf bekannte Zielwerte abbildet. Daher wird das überwachte Lernen auch als Lernen aus Beispielen bezeichnet. Es gibt somit eine explizite Zielgröße, für die in den Trainingsdaten die wahren Werte bekannt sind. Die Zielwerte werden beim maschinellen Lernen typischerweise als Label bezeichnet. Ist das Label nominal, dann handelt es sich um eine Klassifikation. Bei metrischer Zielgröße liegt eine Regression oder auch numerische Vorhersage vor. Klassifikation und Regression sind die am häufigsten betrachteten Aufgabentypen. Sie werden zusammen mit weiteren Aufgabentypen im nächsten Abschnitt ausführlicher betrachtet. Nun ist es für einen Computer keine große Herausforderung, eine Abbildung aller durch die Trainingsdaten vorgegebenen Eingabe-Ausgabe-Paare zu speichern und im Bedarfsfall abzurufen. Aus menschlicher Perspektive kommt dies dem Auswendiglernen gleich. Ziel ist es vielmehr, über die gegebenen Trainingsdaten hinaus zu generalisieren. Die gelernte Funktion, die beim maschinellen Lernen auch Modell bezeichnet wird, soll als Vorhersagemodell für neue, bislang ungesehene Eingaben sinnvolle Ausgabewerte bestimmen. In den meisten Fällen wird die Art des Modells durch die Auswahl eines Lernverfahrens vorgegeben und während der Lernphase werden die Parameter des gewählten Modells optimiert.3 So gesehen entspricht das Lernen einer Suche nach optimalen Modellparametern. Der Begriff Überwachung bedeutet, dass durch Kenntnis der korrekten Ausgabewerte (Zielwerte) beim Lernvorgang ermittelt werden kann, ob das aktuelle Modell korrekt ist bzw. wie gut es ist. Dies ist vergleichbar mit einem Lehrer (engl. supervisor), der den aktuellen Wissensstand bewertet und Rückmeldung über die Güte des Modells erteilt. Um die Fähigkeit eines Modells zum Generalisieren zu beurteilen, ist es wichtig, das Modell mit Daten zu bewerten, die in der Lernphase nicht verwendet wurden. Ist die Leistungsfähigkeit auf unbekannten Daten schlechter als auf den Trainingsdaten, dann liegt eine Überanpassung (engl. overfitting) an die Trainingsdaten vor. Ein Erkennen und idealerweise Vermeiden von Overfitting ist eine zentrale Herausforderung beim Lernen aus Beispielen. Es ist zusammen mit einer guten Merkmalserzeugung und sinnvollen Merkmalsauswahl oftmals wichtiger als die Auswahl eines bestimmten Lernverfahrens selbst. Sind die Modelle, die ein gewähltes Lernverfahren erzeugen kann, nicht komplex genug, dann besteht die 3 Ein kurzer Überblick über in der Praxis oft verwendete Modelle und eine Auswahl bekannter Lern-

verfahren folgt in Abschn. 3.5 dieses Kapitels.

3 Grundzüge des maschinellen Lernens

97

Gefahr, dass keine ausreichende Leistung erreicht werden kann. In diesem Fall spricht man von Underfitting, das für einen Einsatz in einer Anwendung genau so problematisch ist wie das Overfitting. Überwachtes Lernen setzt die Verfügbarkeit gelabelter Trainingsdaten voraus und ist daher die Lernform mit den meisten Vorgaben. Die Trainingsdaten müssen meist durch einen Menschen ausgewählt und zusammen mit den wahren Werten für die Zielgröße bereitgestellt werden. In vielen Anwendungen ist gerade das Bereitstellen der Label ein sehr zeitaufwendiger und kostenintensiver Prozess, der oft Expertenwissen in der vorliegenden Anwendungsdomäne voraussetzt.

3.2.2

Unüberwachtes Lernen

Unüberwachtes Lernen (engl. unsupervised learning) heißt auch Lernen aus Beobachtungen. Als Beobachtungen werden beim maschinellen Lernen im Gegensatz zu Beispielen Daten ohne vorgegebene Zielgröße und Label bezeichnet. Es liegen also ungelabelte Trainingsdaten vor oder aber verfügbare Label werden beim Lernprozess explizit nicht verwendet. Es sind somit Eingabewerte, aber keine Ausgabewerte bekannt. Wie beim überwachten Lernen werden die Trainingsdaten üblicherweise von Menschen ausgewählt und bereitgestellt. Da keine Label bereitgestellt werden müssen, ist der Aufwand dafür jedoch verschwindend gering, so dass oft eine große Menge an Daten zum Lernen zur Verfügung steht. Da es keine feste Zielgröße gibt, werden beim unüberwachten Lernen deutlich weniger Vorgaben gemacht als beim überwachten Lernen. Ziel ist es, in den Trainingsdaten Strukturen oder Muster zu entdecken. Die Suche nach Mustern umfasst dabei die gesamten Trainingsdaten und ist nicht wie beim überwachten Lernen beschränkt auf Zusammenhänge mit einer konkreten Zielgröße. Ohne eine konkrete Zielgröße mit bekannten Werten kann es allerdings auch kein explizites Richtig oder Falsch einer Lösung geben und daher keine Rückmeldung über die Güte der entdeckten Muster während des Lernvorgangs von außen. Der Lernvorgang ist zwar in diesem Sinne unüberwacht, aber dennoch agiert das Lernverfahren nicht völlig frei ohne jegliche Kontrolle. Dies vermuten einige Anwender und Anwenderinnen zwar beunruhigt, vielmehr wird jedoch in der Regel lediglich eine vorgegebene Zielfunktion optimiert oder anderweitig nach bestimmten Mustern oder Strukturen in den Daten gesucht. Die bekannteste Art von Struktur sind Gruppierungen ähnlicher Objekte in einer Datenmenge zu sogenannten Clustern. Diese und weitere Aufgaben werden im folgenden Abschnitt genauer dargestellt.

3.2.3

Halbüberwachtes Lernen

Das halbüberwachte Lernen (engl. semi-supervised learning) kombiniert Aspekte des überwachten und des unüberwachten Lernens. Als Mischform wird es oft gar nicht als

98

C. Lanquillon

eigenständige Lernform aufgefasst. Da aber einerseits das Bereitstellen von Zielwerten für die Trainingsdaten oft zeitaufwendig und kostenintensiv ist und andererseits Vorhersagemodelle in Anwendungen sehr oft genutzt werden, ist es naheliegend, nach Lösungen zu suchen, die mit möglichst wenig gelabelten Trainingsdaten auskommen können. Das halbüberwachte Lernen verwendet Trainingsdaten, die nur zum Teil gelabelt sind. Ist das Ziel des Lernprozesses die Erstellung eines Vorhersagemodells, dann soll beim halbüberwachten Lernen Nutzen aus den latenten Strukturen in den Daten gezogen werden, um die Vorhersageleistung eines Vorhersagemodells zu verbessern. Typischerweise wird dabei die Menge der Trainingsdaten iterativ um Beispiele angereichert, für die das zu lernende Vorhersagemodell selbst Label generiert.

3.2.4

Bestärkendes Lernen

Das bestärkende Lernen (engl. reinforcement learning) unterscheidet sich grundlegend von den anderen vorgestellten Lernformen, bei denen bereits zu Beginn des Lernvorgangs die Trainingsdaten zur Verfügung stehen, sei es mit oder ohne Label als Beispiele oder Beobachtungen. Beim bestärkenden Lernen steht ein Agent oder ein System im Mittelpunkt, das durch Interaktion mit seiner Umwelt (engl. environment) erst Daten generiert. Deshalb wird das bestärkende Lernen auch als Lernen durch Interaktion bezeichnet. Beim bestärkenden Lernen werden somit am wenigsten Vorgaben gemacht, so dass diese Lernform ideal für Szenarien ist, in denen das Bereitstellen von Trainingsdaten schwierig ist und ein Agent eine Strategie für eine Folge von Entscheidungen treffen muss, wie etwa beim Durchführen eines Spiels oder bei der Navigation durch unbekanntes Gebiet. Die Aktionen des Agenten führen direkt durch entsprechende Reaktion oder indirekt durch Veränderung des Zustands der Umwelt zu meist zeitlich versetztem Feedback für die vom Agenten getroffene Folge von Entscheidungen hinsichtlich der durchzuführenden Aktionen. Das Feedback-Signal drückt bezüglich der Erreichung eines Ziels entweder eine Belohnung oder eine Bestrafung (negative Belohnung) aus, die der Agent zu maximieren versucht. Übergeordnetes Ziel ist das Erlernen einer Strategie, die die Belohnung für eine abgeschlossene Folge von Aktionen insgesamt maximiert. Beispielsweise führt beim Spielen eines Spiels wie Schach oder Go Sieg oder Niederlage zum Feedback-Signal für eine Folge von Zügen während des Spiels. Während beim überwachten Lernen durch Kenntnis der korrekten Zielwerte für die Trainingsdaten genau bestimmt werden kann, ob eine Entscheidung richtig oder falsch ist (Klassifikation) oder wie weit eine Vorhersage vom richtigen Wert entfernt ist (Regression), weiß der Agent beim bestärkenden Lernen in der Regel nicht, ob eine Entscheidung wirklich die beste ist. Da der Erfahrungsschatz erst mit seiner Interaktion wächst, weiß der Agent oft nur für einen Teil der möglichen Aktionen, welche in der Vergangenheit zu einer größeren oder kleineren Belohnung geführt haben. Um dieses Problem zu lösen, müssen typischerweise im Sinne von Versuch und Irrtum auch bislang unbekannte (nicht evaluierte) Aktionen vom

3 Grundzüge des maschinellen Lernens

99

Agenten ausprobiert werden, um den Handlungsspielraum im Rahmen seiner Strategie zu vergrößern. Zusätzlich zum beschriebenen Unterschied zwischen dem Feedback-Signal und der Kenntnis der Zielgröße kommt oft erschwerend hinzu, dass das Feedback-Signal in der Regel erst zeitlich versetzt, also nach mehreren Aktionen zur Verfügung steht. Daraus resultiert die Schwierigkeit der Zuordnung des Signals zu einzelnen Aktionen. Dies ist das sogenannte Credit Assignment Problem, für das ein Lernverfahren dieser Lernform eine Lösung finden muss.

3.2.5

Weitere Kategorisierungen

Im Folgenden werden weitere Unterscheidungsmerkmale für Lernformen vorgestellt.

3.2.5.1 Transfer Learning Wenn das Lernergebnis einer Lernaufgabe für die Lösung einer anderen Aufgabe verwendet wird, spricht man von Transfer Learning. Offensichtlich ist dabei die Forderung verletzt, dass die Trainingsdaten repräsentativ für die neuen Daten sein sollten, für die ein Vorhersagemodell zur Anwendung kommt. Dennoch kann auf diese Weise eine Lösung insbesondere für Anwendungsszenarien mit sehr wenig verfügbaren Trainingsdaten erzielt werden. Durch ein nachträgliches Anpassen eines bestehenden Modells mit Trainingsdaten aus der neuen Aufgabe, kann sogar die Problematik abgefedert werden, die sich durch die Nicht-Repräsentativität der ursprünglichen Trainingsdaten ergibt.

3.2.5.2 Batch vs. Online Learning und Stream Learning Beim klassischen überwachten und unüberwachten Lernen wird davon ausgegangen, dass die Trainingsdaten vollständig zu Beginn des Lernprozesses vorliegen. Typisch für einen Lernvorgang ist das vielfache Iterieren über die Trainingsdaten. Man spricht in diesem Zusammenhang von Batch Learning. Im Gegensatz dazu könnten die Daten auch erst nach und nach zur Verfügung stehen, so dass Lernverfahren von Interesse sind, die inkrementell arbeiten. Man spricht dann auch von Online Learning. Wenn überhaupt nur ein Datenstrom zur Verfügung steht, der möglicherweise so groß ist, dass gar nicht alle Daten dauerhaft gespeichert werden können, und ein Lernverfahren nur einmal ein Datenobjekt betrachten kann, anstatt beliebig oft über alle Trainingsdaten iterieren zu können, dann liegt eine Form von Stream Learning vor.

3.2.5.3 Active Learning Beim überwachten Lernen stehen die Label der Trainingsdaten zu Beginn zur Verfügung und beim halbüberwachten Lernen kann ein Lernverfahren selbst generierte Label während

100

C. Lanquillon

des Lernvorgangs nutzen. Wenn ein Lernverfahren im Kontext der Anwendung nach den korrekten Zielwerten für Datenpunkte, von deren Kenntnis es sich signifikante Verbesserung der Leistungsfähigkeit verspricht, einhalten darf, dann handelt es sich um Active Learning. Da beim bestärkenden Lernen der Agent eigenständig auch neuartige Aktionen ausführt, um für diese die Stärke des Feedback-Signals zu erkunden, ähnelt dieser Ansatz einem aktiven Erfragen von Zielwerten.

3.3

Aufgabentypen: Was wird gelernt?

Entsprechend der Informationsverarbeitung wird eine Lernaufgabe als Abbildung f einer Eingabe X auf eine Ausgabe Y betrachtet. Aus Sicht der Informatik und der für die Transformation der Eingabewerte in die Ausgabewerte notwendigen Rechenschritte handelt es sich dabei um einen Algorithmus, der in einem Programm implementiert ist. Dennoch wird die Abbildung oder Funktion f beim maschinellen Lernen üblicherweise als Modell bezeichnet. Ziel des maschinellen Lernens ist es nun, die Erstellung des Modells zu automatisieren. Mit Hilfe eines Lernalgorithmus soll basierend auf Trainingsdaten ein Modell gelernt werden. Bei der Betrachtung der Aufgabentypen sei daran erinnert, dass es elementar ist zu unterscheiden zwischen dem Problem oder der Aufgabe, die mit Hilfe eines Programms (Modell) gelöst werden soll, und der Aufgabe, ein derartiges Modell zu erstellen. Letztere – also die Modellerstellung – wird zur Abgrenzung auch als Lernaufgabe bezeichnet. Gerade bei wissenschaftlichen Betrachtungen des maschinellen Lernens stehen die Algorithmen zum Lernen aus den verfügbaren Daten im Vordergrund. Aus Sicht der Anwendung sollten jedoch die Ziele im Vordergrund stehen, die mit dem maschinellen Lernen verfolgt werden. Während die Aufgabe in einer konkreten Anwendung entsprechend der vorgegebenen Ziele festgelegt ist, können stets unterschiedlichste Lernverfahren für deren Lösung herangezogen werden. In den meisten Anwendungsprojekten werden unterschiedliche Verfahren herangezogen und miteinander verglichen, bevor eine Konstellation als Lösung des Problems ausgewählt wird. Eine gut formulierte und abgegrenzte Aufgabenstellung ist ein entscheidender Schritt zur Lösung eines Problems [31]. Daher werden zunächst grundlegende Aufgabentypen und deren Art der Verwendung (Modellanwendung) und im Anschluss gängige Vorgehensweisen und Methoden zu deren Lösung vorgestellt und beschrieben.

3.3.1

Modellanwendung: Wie wird ein Modell verwendet?

Oft wird zwischen Vorhersagemodellen und Modellen für die Beschreibung unterschieden. Diese Unterscheidung bezieht sich im Kern auf die Verwendung eines Modells. Vorhersagemodelle sollen meist die Werte für ein spezielles Merkmal, der sogenannten Zielgröße (engl.

3 Grundzüge des maschinellen Lernens

101

Abb. 3.3 Beim maschinellen Lernen wird zwischen der Modellerstellung (Lernphase) und der Modellanwendung unterschieden

target attribute), basierend auf anderen beobachtbaren oder messbaren Merkmalen vorhersagen. Die Verwendung eines Vorhersagemodells zur Durchführung eben dieser Vorhersagen für neue Daten ist das Nutzungsszenario eines Modells, das beim maschinellen Lernen am meisten verbreitet ist. Dies ist nicht verwunderlich, da es primär um die Automatisierung von Prozessen geht. Diese Lernaufgabe wird meistens durch überwachte Lernverfahren gelöst. Man unterscheidet daher zwischen der Modellerstellung bzw. Lernphase und einer Phase der Modellanwendung wie in Abb. 3.3 dargestellt. Wenn das primäre Ziel der Modellerstellung die Beschreibung ist, dann gibt es keine Modellanwendung in dem Sinne, dass neue Daten durch das Modell verarbeitet werden. Vielmehr dient das beschreibende Modell dem Erkenntnisgewinn durch Betrachtung und Interpretation von Menschen im Kontext der Anwendung. Diese Form der Nutzung ist eher typisch für das Data Mining, wenn man denn einen Unterschied zwischen Data Mining und maschinellem Lernen betonen möchte. Die gängigen Aufgaben werden nun oft entsprechend der Nutzung für Vorhersagen und zur Beschreibung eingeteilt. Es zeigt sich aber, dass die meisten Modelle der beschreibenden Art letztlich auch für Vorhersagen eingesetzt werden können. Und gerade im Kontext des maschinellen Lernens geschieht dies sehr oft. Wie dies konkret aussieht, wird weiter unten betrachtet.

3.3.2

Eingabe: Die Daten als Matrix

Wenn nun aber beschreibende Modelle auch für Vorhersagen verwendet werden und einige Vorhersagemodelle auch als Beschreibung dienen können, dann ist diese Einteilung weniger sinnvoll, als sie auf den ersten Blick erscheint. Wesentlich für die Unterscheidung ist vielmehr, ob es ein Merkmal gibt, das von vornherein speziell als Zielgröße gekennzeichnet ist. So wird unterschieden zwischen Aufgaben, bei denen durch Vorgabe der Zielgröße bereits eine gewisse Struktur für den Lernprozess vorgegeben ist, und solchen, bei denen eine den Daten inhärente Struktur erst entdeckt werden soll. Im vorherigen Abschnitt wurde herausgestellt, dass Aufgaben mit vorgegebener Zielgröße und entsprechenden Werten dafür in den Trainingsdaten üblicherweise durch überwachte Lernverfahren, wohingegen Aufgaben ohne vorgegebene Zielgröße durch unüberwachte Lernverfahren gelöst werden.

102

C. Lanquillon

Abb. 3.4 Datenmatrix mit Zielgröße (links) und ohne Zielgröße (rechts)

Zur Charakterisierung und Einordnung der Aufgaben ist es hilfreich, sich die Eingabe in Form einer Datenmatrix vorzustellen. Diese besteht aus n Zeilen, die die Objekte der Anwendung repräsentieren. Je nach Fachrichtung sind neben Zeile und Objekt unterschiedliche neutrale Begriffe für die Zeilen der Matrix gängig wie etwa Instanz, Datensatz (engl. record), Datenpunkt oder nur Punkt. In konkreten Anwendungen werden die Zeilen natürlich auch als das bezeichnet, was sie darstellen, also beispielsweise Kunde, Patientin oder Fahrzeug. Die Spalten der Matrix repräsentieren Eigenschaften der Objekte und werden typischerweise als Merkmale (engl. features) bezeichnet. Aber auch die Begriffe Variable, Attribut oder Dimension sind für eine Spalte gängig. Zu beachten ist, dass die Datenmatrix beim überwachten Lernen die Zielgröße, also die Ausgabe der zu lösenden Aufgabe enthält, wie auch in Abb. 3.4 (links) dargestellt. Somit ist die Ausgabe der Aufgabe ein Teil der Eingabe für das Lernverfahren. Ein unüberwachtes Lernverfahren erhält als Eingabe nur die Eingabedaten der Aufgabe und keine Zielgröße wie in Abb. 3.4 (rechts) zu sehen.

3.3.3

Gängige Aufgabentypen

Abstrahiert man von den unzähligen Anwendungen, so kristallisieren sich einige wenige typische Aufgaben heraus, die in Abb. 3.5 zusammengefasst sind. Sie sind derjenigen Lernform zugeordnet, durch die sie am häufigsten adressiert werden. Das Erlernen einer Strategie für eine Abfolge von Handlungen ist die allgemein formulierte Lernaufgabe im Rahmen des bestärkenden Lernens, die an dieser Stelle nicht weiter betrachtet wird, da der Fokus auf Aufgabentypen liegen soll, bei denen Daten, aus denen gelernt werden sollen, bereits vorliegen. Klassifikation und Regression sind die gängigsten Vertreter für Aufgaben mit vorgegebener Zielgröße, die üblicherweise mit Hilfe von überwachten Lernverfahren gelöst werden. Die restlichen Aufgaben haben keine vorgegebene Zielgröße und gelten als strukturentdeckend. Sie werden üblicherweise durch unüberwachte Lernverfahren bearbeitet.

3 Grundzüge des maschinellen Lernens

103

Abb. 3.5 Übersicht über die gängigsten Aufgabentypen gruppiert nach Lernform

3.3.3.1 Aufgaben mit vorgegebener Zielgröße Bei Aufgaben mit gegebener Zielgröße handelt es sich um die klassische Form der Vorhersage. Nach einer Lernphase, in der ein Vorhersagemodell erstellt wird, wird das Modell zur Vorhersage der Zielgröße für neue Daten eingesetzt. Nichtsdestotrotz gibt es Anwendungen, bei denen ein Modell auch zur Beschreibung von Klassen oder Zusammenhängen herangezogen wird. Eine weitere Unterscheidung erfolgt nun nach dem Skalenniveau der Zielgröße. Ist das Zielattribut nominal (qualitativ), dann handelt es sich um eine Klassifikation. Bei metrischer (quantitativer) Zielgröße spricht man von Regression oder auch numerischer Vorhersage. Klassifikation Bei der Klassifikation sollen Objekte anhand der sie repräsentierenden Merkmale (Eingabe) auf entweder keine Klasse, genau eine Klasse oder mehrere Klassen aus einer vorgegebenen Klassenstruktur abgebildet werden (Ausgabe). Die Klassenzugehörigkeit stellt dabei die nominale Zielgröße dar. Das durch Lernverfahren erstellte Modell wird auch als Klassifikator bezeichnet. Die Klassifikation ist sicherlich die am häufigsten betrachtete Aufgabe beim maschinellen Lernen. Bei der binären Klassifikation sollen Objekte auf eine von zwei Klassen abgebildet werden. Ob eine E-Mail Spam ist oder nicht oder ob ein Kunde seine Geschäftsbeziehung kündigen wird oder nicht, sind typische Beispiele dafür. Beim maschinellen Lernen werden die beiden Klassen der binären Klassifikation allgemein oft mit positiv und negativ bezeichnet. Dabei steht positiv nicht unbedingt für eine Eigenschaft, die als positiv für den Anwender wahrgenommen wird, sondern für die Klasse, die für die Anwendung von größerer Relevanz ist wie etwa eine betrügerische Transaktion, eine Spam-Nachricht, ein defektes Produkt oder eine abwanderungswillige Kundin, die als solche erkannt werden soll. Handelt

104

C. Lanquillon

es sich bei den Klassen explizit um die Wahrheitswerte wahr und falsch, dann spricht man auch von einem Konzept (engl. concept) und die Aufgabe ist im Englischen als Concept Learning bekannt. In der allgemeinen Form sind auch mehr als zwei Klassen möglich. Man spricht dann auch von einem Mehrklassenproblem. Weiterhin ist es möglich, dass ein Objekt auch keiner der bekannten Klassen oder gar mehreren Klassen zugeordnet wird. Letzteres ist beispielsweise bei der Zuordnung von Schlagwörtern oder Themen zu Texten interessant. Es gibt Lernverfahren, die Mehrklassenprobleme direkt lösen können. Viele können allerdings nur mit einer binären Klassifikation umgehen. Aufgaben mit mehr als zwei Klassen lassen sich jedoch immer auch durch binäre Klassifikatoren realisieren, indem beispielsweise für jede Klasse ein binärer Klassifikator erstellt wird, der entscheidet, ob ein Objekt zu dieser Klasse gehört oder nicht. Auf diese Art und Weise ist es auch möglich, die Zuordnung zu einer Klasse komplett zu verweigern (Zuordnung zu keiner Klasse) oder eine Zuordnung zu mehreren Klassen zu erlauben. Wenn die Klassifikatoren nicht nur die Klassenentscheidung, sondern auch einen Konfidenzwert für die Entscheidung ausgeben, dann kann nach dem Winner-takes-all-Prinzip die Klasse mit der größten Konfidenz den Zuschlag erhalten. Eine Zuordnung zu keiner oder mehreren Klassen kann durch Entscheidungen basierend auf Vergleichen mit vorgegebenen Schwellwerten erreicht werden. Um die Leistungsfähigkeit eines Klassifikators zu bestimmen, werden die bekannten wahren Werte der Zielgröße mit den Vorhersagen des Klassifikators verglichen. Da die Zielgröße nominal ist, bleiben bei der binären Klassifikation nur die beiden Möglichkeiten, dass der vorhergesagte Wert korrekt ist oder nicht. Alle Kombinationen sind in einer sogenannten Konfusionsmatrix zusammengefasst. Abb. 3.6 illustriert dies an einem binären Klassifikationsproblem. In der Hauptdiagonalen stehen als Häufigkeiten die korrekten Entscheidungen: die richtig positiven (engl. true positives) TP und die richtig negativen (engl. true negatives) TN. In der Nebendiagonalen stehen die Fehler: die falsch positiven (engl. false positives) FP und die falsch negativen (engl. false negatives) FN. Die Betrachtung lässt sich auch auf Mehrklassenprobleme erweitern. Die Hauptdiagonale enthält dann weiterhin die richtigen Entscheidungen und unterhalb sowie oberhalb der Hauptdiagonalen stehen die Fehler.

Abb. 3.6 Konfusionsmatrix zur Gegenüberstellung der tatsächlichen Klassen mit der prognostizierten. Bei einer binären Klassifikation ergeben sich die dargestellten vier Felder

3 Grundzüge des maschinellen Lernens

105

Ein Standardmaß zur Messung der Leistungsfähigkeit (Gütemaß) ist die empirische Fehlerrate, die sich als Summe der Fehler geteilt durch die Summe aller Entscheidungen ergibt: error =

FP + FN TP + FP + TN + FN

Alternativ ergibt sich die Genauigkeit: accuracy = 1 − error =

TP + TN TP + FP + TN + FN

Es gibt Anwendungen, bei denen ist die Fehlerrate bzw. die Genauigkeit nicht sinnvoll. Dies ist insbesondere bei sehr schiefen Klassenverteilungen der Fall. Bei der Erkennung von seltenen betrügerischen Transaktionen beispielsweise würde ein Klassifikator, der nie auf Betrugsfälle hinweist, eine sehr hohe Genauigkeit erreichen. Der Klassifikator wäre für den Einsatz zur Betrugserkennung in einer Anwendung jedoch völlig ungeeignet. Stattdessen könnte zum Beispiel die Richtig-Positiv-Rate, die je nach Anwendungskontext auch als Recall oder Sensitivität bekannt ist, als Gütemaß verwendet werden: recall =

TP TP + FN

Alternative Gütemaße konzentrieren sich meist nur auf eine Zeile oder Spalte der Matrix anstatt auf alle Werte wie die Genauigkeit bzw. die Fehlerrate. Entscheidend ist, dass ein für die Anwendung sinnvolles Gütemaß gewählt wird. Wie bereits oben erläutert, muss ein Klassifikator auf Daten evaluiert werden, die nicht zum Lernen verwendet wurden, um die Generalisierungsfähigkeit einzuschätzen. Speziell für diesen Zweck werden Validierungs- bzw. Testdaten vor dem Lernen bei Seite gelegt und verwendet. Regression Wenn das Zielattribut metrisch (quantitativ) ist, dann spricht man von einer Regression. Die Bezeichnung stammt aus der Statistik. Während dort zunächst die Bestimmung einer Regressionsfunktion im Vordergrund steht, mit der der Zusammenhang in den vorliegenden Daten beschrieben wird, steht beim maschinellen Lernen primär die Nutzung der Regressionsfunktion zur Vorhersage des Zielattributes für neue Objekte im Fokus. Die Regressionsaufgabe ist mit der Erstellung einer Funktion, die die Zielgröße basierend auf den Eingabewerten berechnet, klar vorgegeben. Das intuitive Bild der Anpassung von Funktionen an gegebene Daten als Lernprozess stammt von dieser Aufgabe. Lernverfahren unterscheiden sich insbesondere in der Art bzw. Komplexität der verwendbaren Funktionen und in der Art und Weise, wie eine Überanpassung an die Trainingsdaten vermieden werden kann. Denn gerade bei einer numerischen Zielgröße ist offensichtlich, dass eine hinreichend komplexe Funktion jeden Datenpunkt in der Trainingsmenge abbilden könnte, solange es keine Widersprüche in den Daten gibt.

106

C. Lanquillon

Abb. 3.7 Underfitting (grün gepunktet), Overfitting (orange gestrichelt) und angemessene Komplexität mit guter Anpassung (blau durchgezogen) bei der Funktionsapproximation

Im einfachsten Fall sollen die Zielwerte (y-Achse) anhand eines Merkmals (x-Achse) prognostiziert werden. Beispielhaft zeigt Abb. 3.7 die verfügbaren Trainingsdaten als blaue Punkte. Der Zusammenhang (Regressionsfunktion) wird durch eine Gerade (Polynom ersten Grades, grün gepunktet), eine Parabel (Polynom zweiten Grades, blau durchgezogen) und ein Polynom mit Grad 50 (orange gestrichelt) beschrieben. Die Gerade ist offensichtlich nicht komplex genug, um den Verlauf hinreichend genau zu beschreiben (Underfitting). Beim Polynom vom Grad 50 liegt dagegen Overfitting vor, da durch den Verlauf der Kurve bereits zufällige Schwankungen gelernt wurden. Die Parabel scheint die Struktur in den Daten gut zu beschreiben. Wie lässt sich die Güte einer Regressionsfunktion erfassen? Während bei Klassifikationsproblemen die Güte basierend auf den richtigen und falschen Entscheidungen getroffen werden kann, ist dies bei einer metrischen Zielgröße mit potenziell unendlich vielen möglichen Zielwerten nicht sinnvoll. Man geht üblicherweise davon aus, dass die Zielgröße zu einem gewissen Grad verrauscht ist, und erwartet keine perfekt zu allen Trainingsdaten passende Funktion. Ein gängiges Gütemaß für Regressionsaufgaben ist die Wurzel des mittleren quadrierten Fehlers (engl. root mean squared error, kurz RMSE):  (yi − f (xi ))2 RMSE = n . Weitere Varianten Die Klassifikation mit nominaler und die Regression mit metrischer Zielgröße sind die bekanntesten Aufgaben im maschinellen Lernen. Liegt eine ordinalskalierte Zielgröße vor,

3 Grundzüge des maschinellen Lernens

107

dann wird die Aufgabe als Ranking bezeichnet. Dies ist in der Praxis eine sehr weit verbreitete Aufgabe – man denke nur an die Sortierung von Suchergebnissen. Oftmals wird ein Ranking jedoch als Regressionsaufgabe interpretiert und durch die Vorhersage eines numerischen Relevanz-Wertes und anschließende Sortierung gelöst. In vielen Darstellungen zum maschinellen Lernen wird das Ranking daher nicht als separate Aufgabe genannt. Ebenso kann die Zielgröße auch ein komplexerer Datentyp sein, der die Lösung für ein größeres Problem repräsentiert. Auch derartige Fälle werden in diesem allgemeinen Überblick nicht weiter betrachtet.

3.3.3.2 Aufgaben ohne vorgegebene Zielgröße Aufgaben ohne vorgegebene Zielgröße werden auch als beschreibend oder strukturentdeckend charakterisiert. Während die Lernaufgabe bei vorhersagenden Aufgaben durch die Vorgabe der Zielgröße ganz klar umrissen ist, bestehen bei strukturentdeckenden Aufgaben, die üblicherweise durch unüberwachte Lernverfahren gelöst werden, deutlich mehr Freiheiten. Durch Vorgabe eines Analyseziels und eines Lernverfahrens wird die Art der Struktur, die entdeckt werden kann, stark eingeschränkt und dadurch die Bearbeitung der Aufgabe in angemessener Zeit beherrschbar und bewertbar. Im Folgenden erfolgt ein Einblick in die wesentlichen Arten von Strukturen bzw. Mustern, die entdeckt werden sollen. Die Datenmatrix dient dabei wieder als Orientierungshilfe, denn eine wesentliche Unterscheidung hinsichtlich der Strukturen liegt in der Fokussierung auf entweder Spalten oder Zeilen wie in Abb. 3.8 dargestellt. Clustering (Segmentierung) Die Clusteranalyse oder das Clustering fasst ähnliche Objekte in einem Datenbestand zu Gruppen zusammen. Es handelt sich folglich um eine zeilenorientierte Betrachtung der Datenmatrix. Die entstehenden Gruppen werden auch als Cluster, Klassen oder Segmente bezeichnet. Im Gegensatz zu einer manuellen Segmentierung durch Menschen wird bei der Clusteranalyse die Einteilung datengetrieben durch einen Algorithmus durchgeführt. Die datengetriebene Zusammenfassung ähnlicher Objekte setzt voraus, dass die Ähnlichkeit oder der Abstand zwischen Objekten sinnvoll im Kontext einer Anwendung definiert werden kann. Verschiedene Clusterverfahren mögen jeweils Stärken oder Schwächen bei der Entdeckung unterschiedlichster Strukturen haben. Die Abb. 3.9 lässt bereits im zweidimensionalen Raum erahnen, wie unterschiedlich Strukturen sein können, die entdeckt werden sollen. Clustering und Klassifikation hängen eng zusammen. Bei der Klassifikation wird die Zuordnung von Objekten in eine bestehende Klassenstruktur gelernt, während beim Clustering eine Klassenstruktur überhaupt erst gefunden werden soll. In diesem Sinne ist die Clusteranalyse beschreibend (Descriptive Clustering). Wenn das Modell, das die Klassenstruktur beschreibt, in der Lage ist, neue Datenpunkte den Klassen der neu entdeckten Klassenstruktur zuzuordnen, dann handelt es sich um Predictive Clustering.

108

C. Lanquillon

Abb. 3.8 Eine Analyseaufgabe hat jeweils eine spezielle Betrachtungsweise der Datenmatrix. Die Assoziationsanalye sucht spaltenorientiert nach Strukturen, während die Clusteranalyse und die Anomalieerkennung zeilenweise orientiert sind

Abb. 3.9 Unterschiedliche Strukturen (farblich gekennzeichnet) erfordern geeignete Clusterverfahren, um sie zu entdecken. Einem Clusterverfahren steht die farbliche Information bei der Strukturentdeckung nicht zur Verfügung

Wegen der fehlenden Zielgröße ist eine Evaluierung und Interpretation der resultierenden Cluster die größte Herausforderung bei der Clusteranalyse. So gibt es zum Beispiel Kennzahlen, die die Kompaktheit oder Trennung zwischen Clustern messen. Diese werden jedoch mit wachsender Anzahl immer besser, so dass bei der Suche nach einer idealen Anzahl an Clustern eine Form von Überanpassung stattfindet. Der Silhouettenkoeffizient basiert auf

3 Grundzüge des maschinellen Lernens

109

der Betrachtung der beiden nächst gelegenen Cluster und ist robuster. Diese Kennzahlen sind allerdings nur dann sinnvoll, wenn die Cluster tatsächlich kompakt und eher sphärisch sein sollen wie in Abb. 3.9 im Beispiel ganz links. Bei allen Kennzahlen bleibt jedoch die Herausforderung, dass ein Mensch die Ergebnisse im Kontext der Anwendung verstehen und bewerten muss, um für die zugrunde liegende Zielstellung etwas Nützliches zu finden. Anomalieerkennung Bei der Anomalieerkennung oder auch Ausreißererkennung werden Objekte in einer Datenmenge gesucht, die von den meisten anderen Objekten abweichen. Die Begriffe Ausreißer (engl. outlier) und Anomalie werden meist synonym verwendet. In einigen Fällen werden Ausreißer als Oberbegriff betrachtet, der neben Fehlern in den Daten und Rauschen die im Kontext einer Anwendung besonders relevanten Anomalien im engeren Sinne enthält [1, S. 3]. An outlier is an observation that deviates so much from the other observations as to arouse suspicions that it was generated by a different mechanism. – Hawkins, 1980 [22]

Abweichungen zwischen Ausreißern und den normalen Datenpunkten können sich durch extreme Werte bei einem Merkmal zeigen (univariat), was vergleichsweise leicht zu entdecken ist. Eine deutlich größere Herausforderung stellt dagegen das Entdecken von Ausreißern dar, bei denen die Werte jedes einzelnen Attributes unauffällig sind, jedoch eine ungewöhnliche Kombination mehrere Attribute (Muster) vorliegt (multivariate Betrachtung). Wie die Clusteranalyse ist auch die Anomalieerkennung zeilenorientiert in Bezug auf eine gegebene Datenmatrix. Es zeigt sich weiterhin, dass die Anomalieerkennung und die Clusteranalyse komplementäre Aufgaben sind. Die Clusteranalyse gruppiert ähnliche Objekte und die Anomalieerkennung identifiziert Objekte, die sich durch eine gewisse Unähnlichkeit zu den meisten anderen Objekten auszeichnen, wie in Abb. 3.10 erkennbar.

Abb. 3.10 Eine Clusteranalyse gruppiert ähnliche Punkte zu einem Cluster. Ausreißer zeichnen sich oft durch Unähnlichkeit zu entdeckten Clustern aus, wie durch die rote Umrandung verdeutlicht

110

C. Lanquillon

Wenn in einer Datenmenge Anomalien als solche gekennzeichnet sind, ließe sich die Anomalieerkennung jedoch auch als binäre Klassifikationsaufgabe auffassen und durch überwachte Lernverfahren lösen. Die Herausforderung läge dann allerdings in der sehr schiefen Klassenverteilung, da Anomalien typischerweise selten sind. Assoziationsanalyse Bei der Assoziationsanalyse werden Beziehungen zwischen den Merkmalen bzw. zwischen konkreten Merkmalswerten identifiziert. Die Aufgabe ist ursprünglich aus dem Data Mining bekannt, insbesondere in Form der Warenkorbanalyse, bei der häufig zusammen in einer Transaktion gekaufte Artikel in einer Menge von Transaktionen gesucht werden. Die Assoziationsanalyse hat aber inzwischen auch Einzug in das Aufgabenspektrum des maschinellen Lernens gefunden. Dort lässt es sich beispielsweise zur Automatisierung von Produktempfehlungen nutzen. In dem Fall wird das Ergebnis der Assoziationsanalyse dann zur Vorhersage von Produkten verwendet, für die sich ein Kunde oder eine Kundin unter Berücksichtigung bereits ausgewählter oder betrachteter Produkte noch interessieren könnte. Wenn eine Zielgröße existiert und nur die Zusammenhänge betrachtet werden, die die Zielgröße enthalten, dann lassen sich die Zusammenhänge auch für Klassifikationsaufgaben einsetzen. Die Beobachtung, dass bestimmte Merkmale bzw. deren Werte häufig in den gegebenen Daten gemeinsam vorkommen, beruht auf einem einfachen Auszählen der Häufigkeiten und scheint zunächst keine große Herausforderung zu sein. Diese entsteht bei einer größeren Anzahl an Merkmalen erst aufgrund der kombinatorischen Explosion der möglichen Zusammenhänge. Die Kunst ist es daher, alle interessanten Zusammenhänge möglichst effizient zu ermitteln. Dimensionsreduktion Ziel der Dimensionsreduktion ist die Abbildung der Datenmatrix auf eine Matrix mit weniger Spalten, während die Anzahl der Zeilen (Objekte) unverändert bleibt. Somit ist diese Aufgabe spaltenorientiert. Die Dimensionsreduktion ist keine Aufgabe des maschinellen Lernens im klassischen Sinne, sondern vielmehr ein Schritt der Datenvorverarbeitung. Die Dimensionsreduktion kommt insbesondere als Vorstufe bei der explorativen Datenanalyse zum Einsatz, wobei oft eine Reduktion auf höchstens drei Dimensionen (Merkmale) angestrebt wird. Im Kontext des maschinellen Lernens mit einem Fokus auf eine automatisierte Datenverarbeitung für eine Anwendung kann die Dimensionsreduktion als Schritt der Datenvorverarbeitung für Lernverfahren zum Einsatz kommen, die Probleme mit zu vielen Merkmalen haben oder um den Ressourcenbedarf während der Lernphase zu reduzieren. Wenn die Dimensionsreduktion für die Datenvorverarbeitung bei anderen Aufgaben eingesetzt wird, dann muss darauf geachtet werden, dass das Modell für die Dimensionsreduktion ausschließlich auf den Trainingsdaten erstellt wird. Da es in der Folge auch für die Testdaten und andere neue Daten verwendet werden muss, damit auch diese Daten entsprechend für die folgende Aufgabe aufbereitet sind, wird die Dimensionsreduktion oft wie ein Vorhersagemodell verwendet.

3 Grundzüge des maschinellen Lernens

3.4

111

Grundlegende Vorgehensweisen

In der frühen Phase des maschinellen Lernens und insbesondere im wissenschaftlichen Umfeld lag der Fokus sehr stark auf der Entwicklung von Lernverfahren für unterschiedliche Probleme mit variierenden Anforderungen und Herausforderungen. Im nächsten Kapitel werden wir einen kurzen systematischen Überblick über diese Verfahren geben. Bei praktischen Problemen hat sich jedoch sehr schnell gezeigt, dass neben den eigentlichen Lernverfahren die Aufbereitung der für ein Problem relevanten Daten sehr wichtig und zugleich sehr aufwendig ist: Coming up with features is difficult, time-consuming, requires expert knowledge. Applied machine learning is basically feature engineering. – Andrew Ng

Letztlich sind die verfügbaren Daten und eine angemessene Datenaufbereitung, oft auch als Feature Engineering bezeichnet, für den Erfolg von Machine-Learning-Projekten wichtiger als die Lernalgorithmen [14]. Während das eigentliche Lernen aus den Daten nach der Auswahl geeigneter Lernverfahren weitgehend automatisiert ablaufen kann, wenn nicht eine interaktive Form der Modellerstellung zum Erkenntnisgewinn beim Menschen führen soll, so erfordert bislang insbesondere noch die Datenaufbereitung sehr viel fachliches und analytisches Expertenwissen. Der Erfolg von Deep Learning als Teilbereich des maschinellen Lernens im Wesentlichen mit vielschichtigen neuronalen Netzen, ist jedoch zum Teil dadurch begründet, dass das Feature Engineering sehr stark automatisiert abläuft. Daher spricht man beim Deep Learning oft auch vom Repräsentation Learning. Dennoch wird die Datenaufbereitung auch zukünftig noch eine zentrale Rolle spielen. Die elementare Bedeutung der Daten kommt gerade in Prozessmodellen für die Durchführung von Analysenprojekten stark zum Ausdruck. Unberührt davon bleibt die Definition und Zielsetzung einer Analyseaufgabe im Anwendungskontext als wichtige Aufgabe. In diesem Abschnitt soll daher zunächst anhand eines standardisierten Vorgehensmodells für Analyseaufgaben der typische Ablauf und Aufbau für Analyseprozesse unter Berücksichtigung menschlicher Beteiligung aufgezeigt werden. Als Umsetzung eines automatisierbaren Prozessablaufs werden wir anschließend einen Teil davon als Machine-Learning-Prozessmodel einführen. Dieser dient insbesondere als Basis für die Zusammenführung von Blockchain-Technologien mit dem maschinellen Lernen in den Folgekapiteln. Ergänzend werden einige typische analytische Entwurfsmuster bei der Durchführung von Analysenprojekten identifiziert und erläutert, die insbesondere die Aufteilung und Verwendung der Daten während der Modellierung und Evaluierung herausstellen.

112

3.4.1

C. Lanquillon

CRISP-DM: Ein Prozessmodell für Analyseprojekte

Ein standardisiertes und strukturiertes Vorgehen erleichtert den Einstieg in die Durchführung von Analyseprojekten und kann diese beschleunigen, hilft bei der Planung und Verwaltung der erforderlichen Aktivitäten und erhöht die Validität und Verlässlichkeit. Darüber hinaus fördert ein derartiges Prozessmodell die Wiederholbarkeit und Nachvollziehbarkeit aller tatsächlich durchgeführten Verarbeitungsschritte und Entscheidungen, erleichtert so die Dokumentation und auch die Wiederverwendung von Erfahrungen. Letztlich hilft ein gemeinsames Verständnis über den allgemeinen Ablauf einer Datenanalyse bei der Kommunikation zwischen allen beteiligten Parteien. Viele Prozessmodelle stammen ursprünglich eher aus dem Data Mining, haben aber längst auch Einzug in die Machine-Learning-Community erhalten und werden daher bei der Durchführung von Analyseprojekten jeglicher Art sehr oft eingesetzt. Ein sehr weit verbreitetes und ausgereiftes Prozessmodell ist der Cross Industry Standard Process for Data Mining, kurz CRISP-DM [37]. Es bricht ein Analyseprojekt hierarchisch auf vier Abstraktionsebenen herunter. Auf der obersten Ebene wird der Analyseprozess, wie

Abb.3.11 CRISP-DM: Ein Standard-Prozessmodell zur Durchführung von Datenanalysen in Anlehnung an Chapman et al. [10]

3 Grundzüge des maschinellen Lernens

113

in Abb. 3.11 dargestellt, durch sechs Phasen vollständig abgedeckt. Dabei wird insbesondere die Einbettung in den Unternehmenskontext ausgehend von einer fachlichen Zielsetzung bis hin zur Anwendung der Ergebnisse berücksichtigt. Die nächste Ebene beschreibt generisch, d. h. unabhängig von konkreten Problemstellungen und Methoden, die Aufgaben der einzelnen Phasen. Erst in der dritten Ebene wird auf die mögliche Umsetzung für verschiedene Situationen bei konkreten Analyseaufgaben eingegangen. Schließlich findet auf der letzten Ebene eine Instanziierung des Prozessmodells für eine konkrete Problemstellung statt. Diese dient letztlich der Aufzeichnung der geplanten Aufgaben, der Entscheidungen, der tatsächlich ausgeführten Schritte oder Maßnahmen und der Ergebnisse. Insbesondere eine ausführliche Dokumentation ist essentiell, da eine Datenanalyse stets verlässlich und vor allem reproduzierbar sein sollte. Es sollte nicht nur dokumentiert werden, was am Ende erfolgreich war und umgesetzt wurde, sondern auch Wege, die nicht erfolgreich waren. Dies kann in späteren Iterationen sehr viel Arbeit und somit Zeit und Kosten sparen. Die folgende Beschreibung konzentriert sich auf die fachlichen und analytischen Aspekte der Phasen. Für eine detaillierte Beschreibung sei auf die ausführliche CRISP-DMDokumentation verwiesen [10]. Der Analyseprozess beginnt beim Business Understanding, folgt insgesamt aber keinem streng linearen Ablauf. Neue Erkenntnisse während der Analyse machen es oft erforderlich, dass Phasen mehrfach besucht werden. Ein Sprung von einer Phase zu einer beliebigen anderen ist stets möglich, wenn dies inhaltlich erforderlich ist. Die Pfeile im Schaubild sind lediglich als die in einem Analyseprojekt am häufigsten zu beobachtenden Sprünge zu interpretieren. Der äußere Kreislauf deutet an, dass der gesamte Analyseprozess oft mehrfach durchlaufen wird (z. B. auch bei Folgeprojekten) und dass zuvor gemachte Erfahrungen bei späteren Iterationen berücksichtigt werden sollten.

3.4.1.1 Business Understanding Mit dieser Phase beginnt der Analyseprozess. Als erstes müssen der fachliche Kontext und die Rahmenbedingungen des Anwendungsszenarios verstanden und die fachlichen Anforderungen und Ziele mit angemessenen Erfolgskriterien bestimmt werden. Warum ist das Projekt für das Unternehmen wichtig und wie sollen die Ergebnisse verwendet werden? Ohne messbare Ziele ist eine spätere Evaluierung der Analyseergebnisse problematisch. Ein ganz zentraler Schritt ist die Abbildung der fachlichen Ziele auf die oben eingeführten Analyseaufgaben. Für die Lösung einer fachlichen Problemstellung kann auch eine Kombination mehrerer der kanonischen Analyseaufgaben erforderlich sein. Außerdem müssen entsprechend der fachlichen Erfolgskriterien Kennzahlen für die Evaluierung der Analyseergebnisse festgelegt und die Vorgehensweise geplant werden. Erfahrungen aus möglicherweise bereits bestehenden Problemlösungen im Unternehmen sind unbedingt zu berücksichtigen. Die Erwartungshaltung der Auftraggeber sollte in Abhängigkeit von Randbedingungen und verfügbaren Ressourcen wie Daten, Rechenleistung und Fachexperten entsprechend angepasst werden. Hervorzuheben ist an dieser Stelle, dass insbesondere weiche Aspekte

114

C. Lanquillon

wie eine ungenügende Verfügbarkeit und Mitarbeit der beteiligten Fachbereiche sowie die gelebte Politik einzelner beteiligter Menschen oder ganzer Bereiche kritische Projektrisiken darstellen.

3.4.1.2 Data Understanding In der Data-Understanding-Phase erfolgt eine erste Sichtung der zur Verfügung stehenden Daten. Es werden hinsichtlich der Analyseziele relevante und geeignete Datenquellen identifiziert und erste Erkenntnisse über die Daten basierend auf einfachen Zusammenfassungen, Visualisierungen und auch explorativer Datenanalyse gewonnen. Es ist hervorzuheben, dass die explorative Analyse lediglich der ersten Erkundung der Daten und dem Vertrautwerden dient und nicht das Ziel selbst ist. In dieser Phase sollen insbesondere Probleme mit den Daten ans Licht kommen. Mangelnde Datenqualität und oftmals unzureichende Möglichkeiten, diese entscheidend zu verbessern, stellen in vielen Projekten ein hohes Risiko für eine erfolgreiche Analyse dar. Ist die Datenbasis hinsichtlich Relevanz, Menge oder Qualität unzureichend, sind Maßnahmen zur Erhöhung der Datenqualität einzuleiten oder alternative Datenquellen zu erschließen. Durch einen Sprung in die erste Phase können auch Ziele und Erwartungshaltungen korrigiert werden.

3.4.1.3 Data Preparation Ziel der Data-Preparation-Phase ist die Aufbereitung der Daten in einem Format, das für die nachfolgend eingesetzten Methoden in der Modellierungsphase geeignet ist. Meistens ist dies, wie oben dargestellt, eine Datenmatrix mit gewissen Anforderungen an das Skalenniveau bzw. die Datentypen der Merkmale. Elementare Schritte der Datenaufbereitung sind das Zusammenfügen von Daten aus verschiedenen Tabellen oder Datenquellen (Integration), die Auswahl der zu verwendenden Datensätze (Zeilen) und Merkmale (Spalten), Bereinigung, Transformationen wie etwa Aggregationen, Normalisierungen oder das Ableiten neuer Merkmale und die Formatierung. Während durch Bereinigung und Transformation semantische Änderungen an den Daten vorgenommen werden, geht es bei der Formatierung ausschließlich um Änderungen syntaktischer Natur, um die Daten entsprechend der vorgesehenen Lernverfahren und Werkzeuge aufzubereiten. Wie oben bereits erläutert gilt die Datenaufbereitung als zentraler Erfolgsfaktor für Analyseprojekte. Da die verschiedenen Lernverfahren sehr unterschiedliche Anforderungen an die Daten haben können, gibt es nicht die eine geeignete Aufbereitung der Daten. Die meisten Standardverfahren der Datenanalyse arbeiten mit Daten in Form einer Matrix. Aber z. B. die Reihenfolge der Attribute und akzeptierte Datentypen und deren Kodierungen mögen variieren. Da in einem Analyseprojekt oft verschiedene Lernverfahren angewendet werden, erfordert dies ein ständiges Wechselspiel zwischen der Datenvorbereitung und der folgenden Modellierungsphase. Dennoch lässt sich versuchen eine Repräsentation der Daten zu

3 Grundzüge des maschinellen Lernens

115

finden, die für möglichst viele Lernverfahren geeignet und nutzbar ist, wie beispielsweise die Überführung aller beschreibenden Merkmale in eine normalisierte numerische Form.

3.4.1.4 Modeling Ziel der Modellierungsphase ist die Auswahl und Anwendung geeigneter Lernverfahren für die zugrundeliegende Aufgabe. Schließlich sollte bereits in dieser Phase eine Bewertung der Analyseergebnisse, insbesondere zur Vermeidung von Overfitting, d. h. der Überanpassung eines Modells, erfolgen. Eine Evaluierung unter Berücksichtigung des Anwendungskontexts und der fachlichen Fragestellung wird dagegen erst in der folgenden Phase stattfinden. Da es je nach Analyseaufgabe nicht das eine Lernverfahren gibt, das konsistent bei allen Anwendungen das beste ist4 , müssen geeignete Modellklassen und Lernverfahren ausgewählt werden. Diese Aufgabe ist auch als Model Selection bekannt. Bei der Auswahl gibt es neben der eigentlichen Analyseaufgabe verschiedene wichtige Einflussfaktoren, wie etwa die Beschaffenheit der Daten, die Verfügbarkeit von Lernverfahren in entsprechenden Analyse-Werkzeugen und letztlich die Erfahrung der Machine-Learning-Experten und Expertinnen. Empfehlenswert ist es, anfangs einfache Lernverfahren zu verwenden, deren Funktionsweise gut verstanden wird. Komplexere Lernverfahren können später zum Einsatz kommen, wenn mehr Verständnis für das vorliegende Problem mit seinen Daten aufgebaut wurde und die erreichte Qualität der Ergebnisse nicht genügt. Komplexere Lernverfahren haben meist mehr Stellschrauben (Hyperparameter), die bei falscher Wahl zu deutlich schlechteren Ergebnissen führen können als einfache Lernverfahren [14]. Häufig werden nicht mehr nur einzelne Modelle als Ergebnis verwendet, sondern sogenannte Model Ensembles. Wie bei einem Expertengremium soll die Kombination mehrerer Meinungen (Ergebnisse) im Mittel deutlich treffendere Resultate ergeben. Unterschiedliche Ansätze, wie z. B. Bagging oder Boosting, erreichen durch gezielte Variation der Trainingsdaten mit demselben Lernverfahren unterschiedliche Ergebnisse, die kombiniert werden können [14]. Aber auch die Kombination von Ergebnissen verschiedener Lernverfahren kann vorteilhaft sein, da jedes Verfahren Stärken in unterschiedlichen Lernsituationen haben kann. Genügt wenigstens ein Modell (oder Modell-Ensemble) den gesteckten Erwartungen, wird das gemäß vorgegebener Kriterien beste Modell an die nächste Phase zur Evaluierung weitergegeben.

4 David Wolpert hat gezeigt, dass es ohne jegliche Annahmen bezüglich der Daten, keinen Grund

gibt, warum ein Modell einem anderen vorgezogen werden sollte. Dies ist eine Variante des No-FreeLunch-Theorems bekannt [40].

116

C. Lanquillon

3.4.1.5 Evaluation Wenn nur intensiv genug gesucht wird, lassen sich in nahezu allen Datenbeständen auffällige Muster finden, selbst wenn die zugrunde liegenden Daten zufällig erzeugt wurden. Diese können sogar statistisch signifikant sein. Statistische Signifikanz ist wichtig, geht aber nicht zwingend mit Relevanz und Anwendbarkeit für ein Unternehmen einher. Eine geeignete Evaluierung ist daher essentiell, bevor ein Analyseergebnis zur Lösung einer fachlichen Fragestellung kommuniziert und zur Anwendung gebracht werden sollte. Ziel der Evaluierung ist die Überprüfung des Nutzens der Analyseergebnisse im Kontext der Anwendung und letztlich die Auswahl des Modells (oder des Modell-Ensembles), das die Aufgabenstellung unter Berücksichtigung der Erfolgskriterien am besten löst. Dies setzt natürlich voraus, dass die Ziele und Erfolgskriterien in der Phase Business Understanding entsprechend definiert wurden. Außerdem sollte in dieser Phase der gesamte bisherige Analyseprozess einem Review unterzogen werden. Die Evaluierungsmethoden und die Evaluierungskriterien hängen stark von der Analyseaufgabe ab. Damit beispielsweise ein Prognosemodell für die Auswahl in Frage kommt, sollte es besser sein als ein Vergleichsmodell, das sogenannte Null-Modell. Letzteres kann z. B. durch Verwendung einfacher Regeln gebildet werden, wie etwa die Klassifikation anhand der häufigsten Klasse oder eines bedeutsamen (relevanten) Merkmals. Liegen Ergebnisse aus einer bestehenden Lösung vor, sollten diese für den Vergleich herangezogen werden.

3.4.1.6 Deployment In der letzten Phase des Prozessmodells werden Berichte und Abschlusspräsentationen zur Dokumentation des Analyseprozesses und Kommunikation der Ergebnisse bereitgestellt. Die Evaluierungsphase stellt sicher, dass die Analyseergebnisse den Anforderungen der geplanten Anwendung genügen. Für einen erfolgreichen Abschluss eines Analyseprojekts genügt das jedoch noch nicht. Ebenso wichtig sind eine verständliche und nachvollziehbare Dokumentation und eine überzeugende Präsentation gegenüber den Auftraggebern und beteiligten Fachbereichen. Namensgeber für die Phase ist die Planung und Umsetzung der Anwendung der Ergebnisse, das sogenannte Deployment. Die Spannbreite der möglichen Nutzung kann dabei von einem einmaligen Erkenntnisgewinn durch Interpretation und Verstehen der Ergebnisse über eine einmalige eher manuelle Anwendung eines Modells auf einen ausgewählten Datenbestand bis hin zur regelmäßigen automatischen Anwendung durch Integration in die betroffenen Geschäftsprozesse erfolgen. Bei einer regelmäßigen Anwendung sollte auch eine Kontrolle und Wartung eines Modells erfolgen, um auf Veränderungen im Anwendungskontext oder der Umwelt gezielt reagieren zu können. Gerade der letzte Aspekt gewinnt zunehmend an Bedeutung, da immer mehr Modelle in Geschäftsmodelle integriert werden. Dies drückt sich explizit durch die Forderung nach einem Management des Lebenszyklus von Modellen aus (Model Life-Cycle Management).

3 Grundzüge des maschinellen Lernens

3.4.2

117

Automatisierung und Operationalisierung

CRISP-DM betont den interaktiven Charakter bei der Durchführung von Analyseprojekten und hebt die Rolle der Menschen im Prozess ganz deutlich hervor. Die Bedeutung des Verständnisses von Anwendung, Problemstellung und Daten steht so stark im Vordergrund, dass der technische Aspekt des Zugriffs auf die Daten und deren Integration als Aufgabe selbstverständlich eine Rolle spielt, aber in der Benennung und Darstellung der Phasen untergeht.

3.4.2.1 Machine-Learning-Prozessmodell Ziel des maschinellen Lernens ist die Automatisierung der Programmerstellung für eine konkrete Aufgabenstellung. Damit geht ein verstärkter Fokus auf die Operationalisierung der technischen Prozessschritte bis hin zu deren Automatisierung einher. Nicht als Alternative zu CRISP-DM, sondern vielmehr als eine Form der Instanziierung der eher technischen und daher leichter automatisierbaren Schritte, die nach dem Business und Data Understanding folgen und somit insbesondere von einer festgelegten Aufgabenstellung ausgehen, wird hier ein Machine-Learning-Prozessmodell vorgestellt, das wegen seines Fokus auf den Datenfluss und die Analyseergebnisse (Modelle) auch als Machine Learning Pipeline bezeichnet werden kann (siehe Abb. 3.12). Es dient im folgenden Kapitel als Basis für die Diskussion und Einordnung bei der Verbindung der Blockchain-Technologie mit dem maschinellen Lernen. Unter der Annahme, dass die Aufgabenstellung bekannt und klar definiert ist, beginnt das Machine-Learning-Prozessmodell direkt mit dem Zugriff auf die Datenquellen und der Extraktion relevanter Inhalte. In Anlehnung an aktuelle Big-Data-Technologien wird diese Phase als Data Ingestion bezeichnet. Da im Kontext von Big Data die Anzahl und Vielfältigkeit relevanter Datenquellen für eine Aufgabenstellung zugenommen hat, muss der Integration ausgewählter Daten zu den Rohdaten für eine Analyseaufgabe eine größere Bedeutung zugeschrieben werden. Dem wird mit der expliziten Aufnahme der Integration als zweite Phase Rechnung getragen. Die ersten beiden Schritte sind bei CRISP-DM teilweise implizit

Abb. 3.12 Machine-Learning-Prozessmodell mit Fokus auf Datenfluss sowie Modellerstellung und Modellanwendung auf Basis der leichter automatisierbaren technischen CRISP-DM-Phasen

118

C. Lanquillon

in der Data-Understandings-Phase enthalten. Danach schließen mit der Aufbereitung der Rohdaten zu den relevanten Merkmalen im Kontext der Aufgabenstellung (Data Preparation), der Modellerstellung (Modeling) sowie der Evaluierung der Modelle (Evaluation) und Nutzung als geeignet eingestufter Modelle (Deployment) die bekannten CRISP-DM-Phasen an, wobei jedoch auch hier der Fokus auf den technischen Aufgaben dieser Phasen liegt.

3.4.2.2 Herausforderungen und analytische Entwurfsmuster In Ergänzung zur oben vorgestellten Machine-Learning-Pipeline sollen nun zwei ganz zentrale Herausforderungen beim Lernen aus Daten zusammen mit typischen Lösungen beschrieben werden. Die Lösungen für derartige Herausforderungen sind in der Praxis so weit verbreitet, dass sie als analytische Entwurfsmuster bezeichnet werden können. Overfitting und Underfitting Eine der größten allgemeinen Herausforderungen beim maschinellen Lernen ist das Problem der Überanpassung (engl. overfitting). Im Gegenzug dazu gibt es auch das Problem der Unteranpassung (engl. underfitting). Da Modelle, deren Leistungsfähigkeit nicht ausreichend ist, selten zum Einsatz kommen, ist dieses Problem in der Praxis nur relevant, um zu erkennen, dass komplexere Modelle erzeugt werden sollten, und wird deutlich seltener explizit angesprochen. Beim Lernen aus Daten stellt das Overfitting sicherlich das größte Risiko für einen erfolgreichen operativen Einsatz dar. Overfitting tritt auf, wenn ein Modell zufällige Eigenarten der Daten (Rauschen, engl. noise) anstatt der zu Grunde liegenden Zusammenhänge (das Signal) beschreibt. Eine zu hohe Modellkomplexität ist dabei die Hauptursache. Overfitting sollte bereits in der Modellierungsphase erkannt und möglichst gebannt werden, sodass keine überangepassten Modelle als Analyseergebnisse an die Evaluierungsphase weitergegeben werden. Zur Erkennung von Overfitting muss die Modellgüte auf nicht zum Lernen verwendeten Daten bewertet werden. Dies erfordert das Aufteilen der verfügbaren Daten in eine Trainingsmenge und eine Test- bzw. Validierungsmenge. Üblicherweise bezeichnet man Daten, die vor der Modellierungsphase und unter Umständen auch schon vor den Transformationsschritten der Datenaufbereitung zum Zwecke der späteren Evaluierung zur Seite gelegt werden als Testdaten. Daten, die während der Modellierungsphase zur Bewertung und Auswahl von Modellen und Parametern der Lernverfahren (sogenannte Hyperparameter) verwendet werden, werden dagegen als Validierungsdaten bezeichnet. Da es konzeptionell um dasselbe Prinzip geht, werden die Begriffe Test und Validierung nicht immer einheitlich und konsistent verwendet: In beiden Fällen handelt es sich um Daten, die bei der Modellerstellung nicht verwendet werden dürfen und die einem Modell zum Zwecke der Evaluierung als neue (ungesehene) Daten präsentiert werden. So ist es möglich, die Leistungsfähigkeit bei überwachten Lernszenarien einfach zu bewerten, denn für die Testdaten bzw. Validierungsdaten sind ebenso wie für die Trainings-

3 Grundzüge des maschinellen Lernens

119

Abb. 3.13 Damit die zu erwartende Leistungsfähigkeit eingeschätzt und Overfitting erkannt werden kann, erfolgt eine Aufteilung der verfügbaren Daten in Trainings- und Testdaten. Die Testdaten dürfen bei der Modellerstellung und Modellauswahl nicht verwendet werden

daten die Werte der Zielgröße (Label) bekannt. Abb. 3.13 zeigt den Datenfluss während der Datenaufbereitung, Modellierung und Evaluierung unter Berücksichtigung der Aufteilung in Trainings- und Testdaten. Ein zwar einfaches, aber fundamentales Konzept für die Bewertung der Generalisierungsfähigkeit von Modellen besteht darin, dass die Testdaten während der Modellerstellung in keiner Form verwendet werden dürfen. Beim überwachten Lernen zeigt sich Overfitting durch eine deutlich schlechtere Leistungsfähigkeit eines Modells bei neuen Daten im Vergleich zur Leistung bei den Trainingsdaten wie in Abb. 3.14 (links) dargestellt. Es werden zu viele Besonderheiten der Trainingsdaten im Modell berücksichtigt. Das Modell beginnt, die Trainingsdaten auswendig zu lernen und ist nicht in der Lage, auf ungesehene Daten zu generalisieren. Die Fähigkeit zu generalisieren ist aber genau das, worauf es ankommt, denn zum Auswendiglernen braucht man keine maschinellen Lernverfahren, das können Computer auf herkömmliche Art und Weise ausgezeichnet. Wenn die Trainingsmenge zu klein im Verhältnis zur Modellkomplexität ist, kommt es ebenfalls schnell zum Overfitting. Abb. 3.14 (rechts) zeigt die Güte eines Modells, dass

120

C. Lanquillon

Abb. 3.14 Underfitting und Overfitting in Abhängigkeit der Modellkomplexität (links) und Overfitting bei einer zu kleinen Trainingsmenge (rechts)

bei sehr kleiner Trainingsmenge diese praktisch auswendig lernt. Mit zunehmender Größe der Trainingsmenge hat ein Modell bei gleichbleibender Komplexität immer weniger die Kapazität, um die Trainingsdaten auswendig zu lernen. Dies erkennt man an der Verringerung der Güte auf den Trainingsdaten. Gleichzeitig wird das Modell gezwungen, die echten Zusammenhänge in den Daten zu lernen, so dass es zunehmend besser generalisieren kann. Dies zeigt sich in steigender Güte auf den Testdaten. Entsprechende, zumindest gleichbleibende Datenqualität vorausgesetzt, sind mehr Daten immer besser und können Overfitting verhindern. Die Aufteilung der insgesamt verfügbaren Daten in Trainingsdaten für die Modellerstellung, Validierungsdaten für die Modellauswahl und die Optimierung von Hyperparametern und Testdaten für die abschließende Evaluierung geht sehr verschwenderisch mit den Daten um. Wenn die Menge verfügbarer Daten sehr groß ist, mag dies unerheblich sein. Da andererseits aber bekannt ist, dass sich, je größer die Datenmenge ist, immer besser daraus lernen lässt, sollte die Trainingsmenge möglichst groß sein. Durch Kreuzvalidierung kann dem Problem einer zu kleinen Datenmenge bzw. dem Problem der Datenverschwendung für die Validierung begegnet werden. Bei der k-fachen Kreuzvalidierung werden die Trainingsdaten in k möglichst gleich große Datenmengen partitioniert. Es wird dann k mal aus k–1 Datenmengen ein Modell erstellt und jeweils mit der übrig gebliebenen Menge evaluiert. Abb. 3.15 zeigt dies für k=5 Partitionen. Die Validierungsmengen sind zwar vergleichsweise klein und die Varianz der darauf gemessenen Modellgüte ist nicht unerheblich, aber der Mittelwert der k Wert für die Modellgüte stellt in der Praxis meist einen sehr verlässlichen Schätzer für die zu erwartende Modellgüte auf neuen Daten dar. Neben der Erkennung stellt die Vermeidung von Overfitting ein wichtiges Konzept dar. Ein frühzeitiges Beenden des Lernvorgangs oder das Bestrafen unnötiger Komplexität, beispielsweise durch Regularisierung, sind übliche Wege dafür. Die Möglichkeiten zur Vermeidung hängen sehr stark von der Modellklasse ab. Eine genaue Kenntnis und ein Einsatz

3 Grundzüge des maschinellen Lernens

121

Abb. 3.15 Aufteilung und Verwendung der Daten bei einer 5-fache Kreuzvalidierung. Der Durschnitt der einzelnen Gütewerte ist der Schätzer für die zu erwartende Güte des Modells bei bislang ungesehenden Daten

der Möglichkeiten zur Vermeidung von Overfitting bei den eingesetzten Lernverfahren sind daher essentiell für den Erfolg beim maschinellen Lernen. Nach der Kreuzvalidierung hat man in den meisten Fällen eine recht gute Abschätzung der auf neuen Daten zu erwartenden Leistungsfähigkeit eines Vorhersagemodells. Was man allerdings nicht hat, ist ein Vorhersagemodell, das in der Folge tatsächlich direkt verwendet werden kann, Stattdessen hat man k Modelle, von denen eines ausgewählt werden müsste, wenn man nicht die k Modelle als Ensemble nutzen möchte. Wenn ein Modell zur tiefergreifenden Evaluierung in die nächste Phase kommen soll, besteht eine andere oft gewählte Möglichkeit darin, abschließend mit den besten Einstellungen (Hyperparametern) auf Basis der kompletten Trainingsdaten ein Modell zu erlernen, das dann in der Evaluierungsphase auf Basis der bislang zurückgehaltenen Testdaten bewertet wird. Sollte die Evaluierung über mehrere Iterationen mehrfach negativ für ein Modell ausfallen und einen Rücksprung in frühere Phasen mit wiederholter Modellerstellung erforderlich sein, so besteht die Gefahr, dass trotz erprobtem Validierungskonzept mit Trainings- und Testdaten eine gewisse Form der Überanpassung stattfindet. Bei zu vielen Iterationen besteht die Gefahr, dass ein Modell gefunden wurde, dass nur zufällig auf den Trainingsdaten und den Testdaten erfolgreich ist, auf wiederum wirklich neuen Daten dagegen nicht. Formen des Overfittings sind auch bei unüberwachten Lernverfahren beobachtbar, wenn auch weniger dominant in der Darstellung und Diskussion von Machine-LearningErgebnissen. Beim partionierenden Clustering mit dem k-Means-Verfahren beispielsweise schneiden Clusterergebnisse mit steigender Clusteranzahl im Mittel immer besser ab. Begrenzte man die Komplexität, in diesem Fall die Anzahl der Cluster, die gefunden werden sollen, nicht manuell, so käme auf der Suche nach der besten Clusteranzahl stets die Anzahl der Datenpunkte heraus, da die Summe aller Abstände von den Datenpunkten zum jeweils nächst gelegenen Clusterzentrum dann stets 0 ist. Diese vermeintlich perfekte Lösung ist jedoch unnütz, da keine echte Gruppierung vorliegt.

122

C. Lanquillon

Data Leakage Bei signifikantem Unterschied zwischen Leistungsfähigkeit auf Trainingsdaten und Validierungsdaten liegt Overfitting vor. Aber insbesondere bei extrem leistungsfähigen Modellen ist auch Vorsicht geboten. Eine möglicherweise unerwartet hohe Leistungsgüte kann darauf hindeuten, dass die Machine-Learning-Pipeline Fehler enthält, dass beispielsweise Informationen bei der Datenaufbereitung oder Modellerstellung verwendet werden, die in einer realen Anwendung gar nicht verfügbar sind. Dieses Problem wird als Data Leakage bezeichnet und Machine-Learning-Pipelines sollten systematisch auf derartige Fälle hin untersucht werden. Skalierbarkeit und verteiltes Lernen Klassische Lernverfahren gehen noch davon, dass die Daten zentral auf einem Rechner verfügbar sind und sogar in den Hauptspeicher passen und die in der Lernphase erforderlichen Rechenoperationen auf einem Rechner ausgeführt werden können. Bei aktuellen Anwendungen im Zeitalter von Big Data ist dies meist nicht mehr möglich. Skalierbare Datenhaltung und Verarbeitung sind notwendig, um mit aktuellen Anforderungen zurecht zu kommen. Skalierbare Anwendungen werden inzwischen durch Verteilung der Daten und Rechenleistung auf viele Rechner in einem Rechnerverbund (Cluster) realisiert. Ein Kernprinzip dabei ist, dass Berechnungen dort stattfinden sollen, wo die Daten liegen, anstatt die Daten kostspielig in Netzwerken dorthin zu transportieren, wo Rechenleistung zur Verfügung steht oder gar der Analyseexperte oder die Analyseexpertin sitzt. Aufgrund der großen praktischen Relevanz für viele Anwendungen und weil die Umsetzungsmöglichkeiten stark von den gewählten Lernverfahren abhängen, wird der Aspekt des verteilten Lernens erst nach einer kurzen Einführung in gängige Lernverfahren in einem separaten Abschnitt aufgegriffen.

3.5

Lernverfahren: Ein kurzer Überblick

Unzählige Lernalgorithmen werden in der Literatur beschrieben und laufend kommen neue Varianten hinzu. Häufig unterscheiden sich neue Ansätze nur in Details. Ein vollständiger Überblick ist selbst in einem dedizierten Fachbuch nicht mehr möglich. Anhand der drei elementaren Komponenten Repräsentation, Evaluierung und Optimierung wird die Modellerstellung im Rahmen des maschinellen Lernens zunächst als Suche nach einem optimalen, oder zumindest sehr guten und nützlichen Modell im Raum aller darstellbaren Modelle, dem sogenannten Hypothesenraum, beschrieben [14]. Zusätzlich werden fünf elementare Verfahrensklassen identifiziert, denen sich die einzelnen Lernverfahren zuordnen lassen [15]. Unter Berücksichtigung der Grundbausteine und der Verfahrensklassen werden einige populäre Lernverfahren ausgewählt und ihre grundlegende Funktionsweise kurz darstellt.

3 Grundzüge des maschinellen Lernens

3.5.1

123

Grundbausteine maschineller Lernverfahren

Pedro Domingos setzt in seinem Artikel über nützliche Erfahrungen aus der Anwendung maschineller Lernverfahren das Lernen als Kombination aus Repräsentation, Evaluierung und Optimierung von Modellen gleich [14]. Wenn man die Bedeutung dieser drei grundlegenden Komponenten im Rahmen des maschinellen Lernens verstanden hat und gängige Umsetzungsvarianten für die einzelnen Komponenten von Lernverfahren kennt, dann hat man einen systematischen Überblick über die sehr große und noch ständig wachsenden Menge an Lernverfahren. Das maschinelle Lernen soll basierend auf Daten Lösungen für vorgegebene Aufgaben finden. Entscheidend ist, dass die Lösung, also das Modell, nicht nur für die bekannten Daten, sondern auch für neue Daten gültig ist. Gesucht sind also Modelle, die generalisieren können. Gemäß der Hypothese des induktiven Lernens wird angenommen, dass ein Modell, dass eine hinreichend große Menge bekannter Daten gut beschreibt, auch auf neue Daten anwendbar ist [29]. Da es in der Regel sehr viele Lösungen für eine meist unterspezifizierte Lernaufgabe gibt, lässt sich die Generalisierungsfähigkeit nicht formal auf der Basis gegebener Daten herleiten und rechtfertigen. Deshalb werden auf der Suche nach geeigneten Modellen, die generalisieren können, gewisse Vorgaben bzw. Annahmen benötigt, damit die Suche erfolgreich gesteuert werden kann und nicht hoffnungslos der kombinatorischen Explosion aller theoretisch denkbaren Modelle erliegt. Diese Vorgaben werden als induktiver Bias (engl. inductive bias) bezeichnet und allgemein werden Vorgaben bezüglich der Repräsentation bzw. Sprache der Modelle, der Präferenz für bestimmte Modelle bei der Suche und die Art und Weise der Vermeidung des Overfittings gemacht. Diese Bias-Varianten sind eng verknüpft mit den drei grundlegenden Komponenten, aus denen sich Lernverfahren zusammensetzen. Repräsentation: Sprache zur Darstellung von Modellen Wie soll das Modell und somit das explizit oder implizit gelernte Wissen repräsentiert werden? Eine formale Darstellung eines Modells, auch als Modellsprache bezeichnet, ist essentiell für die automatisierte rechnergestützte Verarbeitung. Die Wahl der Modellsprache ist für den weiteren Lernprozess von fundamentaler Bedeutung, da sie vorgibt, was im Folgenden gelernt werden kann. Die Menge der in einer Repräsentationsart darstellbaren Modelle wird beim maschinellen Lernen auch als Hypothesenraum (engl. hypothesis space) bezeichnet. Die Darstellung von Lernverfahren in der Literatur orientiert sich üblicherweise sehr stark an der Modellsprache. Typische Beispiele für Modellrepräsentationen sind Polynome, Entscheidungsbäume, Regelmengen, Instanzen, lineare Modelle, graphische Modelle und neuronale Netze. Sollen beispielsweise Datenpunkte durch eine Funktion approximiert werden, so wäre die Beschränkung auf Polynome bis zu einem vorgegebenen Grad einerseits eine konkrete Modellsprache und gleichzeitig ein Repräsentationsbias, also eine Vorgabe, die die Menge

124

C. Lanquillon

der in Frage kommenden Funktionen sehr stark einschränkt. Bei starker Beschränkung des maximalen Polynomgrades ist es gleichzeitig ein sinnvolles Vorgehen, um Overfitting zu vermeiden. Evaluierung: Bewertung von Modellen (Gütekriterien) Da die Modellerstellung als Suche nach einer angemessenen und nützlichen Lösung für ein Problem betrachtet wird, muss spezifiziert werden, welches Modell gut ist oder besser als ein anderes. Es wird eine Evaluierungsfunktion bzw. eine Zielfunktion benötigt, mit der jedes erzeugte Modell bewertet werden kann, um das beste unter ihnen zu finden. In vielen Fällen wird man höchstens ein lokales Optimum finden und es gibt auch Fälle mit mehreren optimalen Lösungen. Bei mehreren gleich oder ähnlich guten Modellen entscheidet oft ein Such- oder Präferenzbias anhand weiterer Kriterien über die Auswahl, wie etwa die Modellkomplexität unter Anwendung von Occams Razor oder dem Prinzip der minimalen Beschreibungslänge (engl. minimal description length (MDL)). Zu beachten ist, dass die Evaluierung, die ein Lernverfahren selbst bei der Suche nach dem besten Modell anwendet, oft von den Evaluierungskriterien abweicht, die im Rahmen der Anwendung vorgegeben werden. Schließlich optimieren die meisten Verfahren die Modelle basierend auf den Trainingsdaten und gewünscht ist eine gute Generalisierungsfähigkeit. Schon in diesem Punkt ist eine große Diskrepanz festzustellen, die die Bedeutung der Aufteilung in Trainings- und Testdaten und Kreuzvalidierung für die Bewertung von Modellen erklärt, insbesondere zur Erkennung und letztlich Vermeidung von Overfitting. Optimierung: Die Suche nach dem besten Modell Im Rahmen der Modellsprache steuert die Optimierung die Modellerzeugung während der Lernphase. Nur durch die Optimierungstechnik generierte Modelle werden mit Hilfe der Evaluierungsfunktion bewertet und kommen als Kandidat für das beste Modell in Frage. Es ist zu beachten, dass das beste erzeugte Modell nicht auch generell das beste sein muss. Die Effizienz eines Lernverfahrens hängt ganz entscheidend von der Optimierungstechnik ab [14].

3.5.2

Verfahrensklassen

Mit Hilfe der oben beschriebenen Grundbausteine lassen sich fünf Verfahrensklassen identifizieren, die wesentliche Merkmale gemein haben. Einige Grundzüge sind so elementar, dass sich sogar von verschiedenen Denkschulen und Lagern innerhalb des maschinellen Lernens sprechen lässt – Pedro Domingos spricht in seiner Abhandlung über den MasterAlgorithmus des maschinellen Lernens gar von verschiedenen Stämmen des maschinellen Lernens (tribes of machine learning), die im Folgenden kurz vorgestellt werden [15].

3 Grundzüge des maschinellen Lernens

125

Symbolische Verfahren Die Grundannahme bei dieser Verfahrensklasse ist, dass Intelligenz auf die Verarbeitung von Symbolen reduziert werden kann [15]. Symbolische Verfahren verknüpfen durch Symbole repräsentierte Informationen durch logische Ausdrücke. Auf diese Weise können beliebige Zusammenhänge und Bedingungen formuliert und auf vielfältige Weise neu verknüpft werden und somit letztlich Modelle für eine konkrete Aufgabe erstellt werden. Es kann sogar auf einfache Art und Weise Vorwissen oder Expertenwissen in die Modellbildung einfließen. Da allerdings wie bereits anfangs beschrieben die manuelle Modellerstellung wie bei Expertensystemen einen großen Engpass darstellt, soll durch maschinelle Lernverfahren die Modellerstellung auf Basis von Hintergrundwissen und Daten erfolgen. Das Lernen beruht auf Induktion (inverser Deduktion), die für deduktive Schlüsse fehlendes Wissen in möglichst allgemeiner Form identifiziert [15]. Die bekanntesten Vertreter dieser Verfahrensklasse sind Lernverfahren für Entscheidungsbäume, die weiter unten vorgestellt werden. Bayes’sche Verfahren In realen Anwendungen sind Wissen und Lernen meist mit Unsicherheit behaftet und dies greifen Bayes’sche Verfahren als elementaren Bestandteil auf. Bayes’sche Verfahren beruhen auf der Verarbeitung von Indizien in Form von Wahrscheinlichkeiten mittels des Satzes von Bayes. Mit probabilistischer Inferenz ist es möglich, effizient mit Rauschen, fehlenden oder widersprüchlichen Informationen umzugehen [15]. Ein sehr einfaches, aber dennoch in vielen Anwendungen erfolgreicher Ansatz ist das Naive-Bayes-Verfahren. Analogieverfahren Kernidee bei Analogieverfahren ist die Abbildung von bekanntem Wissen auf neue Situationen auf Basis von Ähnlichkeiten. Die entscheidenden Fragen sind, wie Ähnlichkeiten berechnet werden, welche bekannten Datenpunkte aus den Trainingsdaten als Referenz in das bekannte Wissen aufgenommen werden und wie auf Basis der Ähnlichkeiten zum bekannten Wissen die Ausgabe für neue Datenpunkte bestimmt wird. Ein einfacher Ansatz dieser Art ist das k-Nächste-Nachbar-Verfahren, während die Support Vector Machine ein Vertreter der deutlich komplexeren Art darstellt. Beide Verfahren werden weiter unten genauer vorgestellt. Konnektionisitische Verfahren Die konnektionistischen Verfahren umfassen alle Varianten (künstlicher) neuronaler Netze und somit auch Deep-Learning-Verfahren, die letztlich neuronale Netze mit vielen Schichten sind. Neuronale Netze waren ursprünglich von der Funktionsweise des Gehirns inspiriert und beruhen auf der Annahme, dass Wissen in den Verbindungen zwischen Neuronen gespeichert wird. Während bei symbolischen und Bayes’schen Verfahren Wissensfragmente explizit einzelnen Komponenten im Modell zugeordnet werden können, was die Verständlichkeit und Nachvollziehbarkeit bei der Anwendung erhöht, ist die Speicherung von Wissen bei konnektionistischen Ansätzen implizit und im Allgemeinen deutlich schwerer zu lokalisieren.

126

C. Lanquillon

Evolutionäre Verfahren Evolutionäre oder auch genetische Verfahren beruhen auf der Annahme, dass ein Lernprozess durch natürliche Selektion zustande kommt. Dieser Lernprozess wird mit einer großen Menge an Modellen (Population) durch Veränderung der Modellstrukturen und Auswahl der besten Strukturen im Computer simuliert. Während konnektionistische Verfahren von einer festen Struktur ausgehend nur die Parameter innerhalb der Struktur optimieren, wird bei evolutionären Verfahren die Struktur selbst optimiert.

3.5.3

Ausgewählte Lernverfahren

Im Folgenden werden einige bekannte und häufig eingesetzte Verfahren aus dem überwachten und dem unüberwachten Lernen vorgestellt.

3.5.3.1 Überwachte Lernverfahren Zu den überwachten Lernverfahren für die Erstellung von Vorhersagemodellen zählen wie anfangs dargestellt insbesondere die Klassifikation mit nominaler Zielgröße sowie die Regression mit metrischer Zielgröße. Es zeigt sich, dass ohne große Anpassung viele Verfahren sowohl für die Klassifikation als auch für die Regression genutzt werden können. Daher wird bei der Auflistung nicht explizit danach unterschieden. K-Nearest-Neighbor Eines der bekanntesten und dem menschlichen Vorgehen oft sehr ähnlichen und daher auch sehr intuitiven Lernverfahren ist der k-Nächste-Nachbar-Algorithmus (kNN) (engl. k-nearest neighbors) [12]. Da dieses Verfahren im Prinzip lediglich alle Datenpunkte als Referenz speichert, also kein echter Lernprozess stattfindet, wird diese Lernform auch als Lazy Learning bezeichnet. Wenn ein neuer Datenpunkt klassifiziert werden soll, werden aus der Menge der bekannten Datenpunkte die k mit dem kleinsten Abstand zum neuen Datenpunkt herausgesucht. Die Klassifikationsentscheidung wird in der Regel per Mehrheitsentscheid getroffen. Erweiterungen, die bei der Entscheidung die Abstände als Gewicht einfließen lassen, bieten sich als Varianten an. Durch Mittelwertsbildung der bekannten Zielwerte lässt sich das Verfahren auch direkt für Regressionsaufgaben nutzen. Lineare Regression Ebenso bekannt und weit verbreitet ist die klassische lineare Regression. Eine metrische Zielgröße wird dabei auf Basis anderer metrischer erklärender Merkmale berechnet. Die Regressionsfunktion ist ein lineares Modell, das im einfachen Fall mit einem erklärenden Merkmal eine Gerade darstellt und im mehrdimensionalen Fall eine Hyperebene. Eine Besonderheit ist, dass sich die Parameter der linearen Funktion direkt basierend auf der Methode der kleinsten Quadrate berechnen lassen.

3 Grundzüge des maschinellen Lernens

127

Logistische Regression Namentlich ähnlich, aber für Klassifikationsaufgaben gedacht ist die logistische Regression. In seiner Grundform soll die logistische Regression die Wahrscheinlichkeit für ein binäres Ereignis in Abhängigkeit verschiedener erklärender Merkmale bestimmen. Dabei werden nominale Merkmale durch Dummy-Codierung in metrische Merkmale überführt. Eine Klassifikation wird basierend auf den ermittelten Eintrittswahrscheinlichkeiten durchgeführt. Im Gegensatz zur linearen Regression können die Parameter der logistischen Regressionskurve allerdings nicht direkt berechnet werden, sondern werden meist iterativ mittels MaximumLikelihood-Schätzer bestimmt. Naive Bayes Der Naive-Bayes-Algorithmus trifft die extrem stark vereinfachende Annahme, dass die erklärenden Merkmale untereinander unabhängig seien. Auch wenn dies bei einem Anwendungsproblem selten zutrifft, erzielt das Verfahren in bestimmten Anwendungsbereichen oft erstaunlich gute Ergebnisse bezogen auf die Klassifikationsleistung. Die Interpretation der Ausgaben als echte Wahrscheinlichkeiten ist in den meisten Fällen jedoch wegen der Verletzung der Unabhängigkeitsannahme wenig sinnvoll. Wegen dieser Annahmen ist das Verfahren jedoch sehr effizient, da die Anzahl der aus den Trainingsdaten zu schätzenden Wahrscheinlichkeiten überschaubar bleibt und die Berechnung mit einer Iteration über die Trainingsdaten abgeschlossen ist. Entscheidungsbäume Wenn es nicht nur um die Leistungsfähigkeit eines Modells geht, sondern auch Verständlichkeit und Erklärbarkeit eines Modells wichtig sind, dann stellen Lernverfahren für Entscheidungsbäume aus der Klasse der symbolischen Verfahren eine sinnvolle Alternative dar [8, 33]. Entscheidungsbäume eigenen sich sehr gut sowohl für Klassifikations- als auch für Regressionsaufgaben. Die Grundidee von Entscheidungsbäumen ist es, die Trainingsdaten solange in Teilmengen aufzuteilen, bis in jeder Teilmenge möglichst nur noch Datenpunkte einer Klasse liegen. Gängige Verfahren unterscheiden sich insbesondere darin, ob sie nur binäre oder beliebige Aufteilungen zulassen und anhand welchem Kriterium die beste Aufteilung an einer vorgegebenen Stelle bestimmt wird. Lässt man Entscheidungsbäume unkontrolliert wachsen, bis am Ende nur einer oder wenige Datenpunkte in einem Knoten des Baumes anzutreffen sind, dann neigt er zum Overfitting, das entweder durch frühzeitigen Abbruch des Baumaufbaus (Pre-Pruning) oder nachträgliches Entfernen wenig sinnvoller Zweige (Post-Pruning) vermieden wird. Support-Vector-Methode Bei der einfachen (linearen) Stützvektor-Methode oder Support Vector Machine (SVM) wird davon ausgegangen, dass eine Hyperebene mit maximalen Abstand (maximal margin) zu den Datenpunkten zweier linear trennbarer Klassen die bestmögliche Generalisierungsfähigkeit besitzt [5]. Deshalb wird versucht eine trennende Hyperebene zu finden, die den Abstand zu

128

C. Lanquillon

den gegebenen Datenpunkten der beiden Klassen maximiert. Die Punkte mit dem kleinsten Abstand zu dieser Hyperebene werden als Stützvektoren bezeichnet. Dies entspricht einem Präferenz-Bias bei der Auswahl der Modelle, die die Daten gleich gut beschreiben. Da praktische Probleme oft nicht linear trennbar sind, werden zum einen gewisse Fehler derart geduldet, dass eine kleine Anzahl der Datenpunkte auf der falschen Seite der TrennHyperebene liegen dürfen. In dem Fall spricht man dann von einer Soft-Margin-Hyperebene. Zum anderen können nichtlinearen SVMs zum Einsatz kommen, bei denen die Eingabedaten in einen höherdimensionalen Raum transformiert werden, in dem die Klassen dann besser linear trennbar sind. Für die Berechnungen von Abständen im transformierten Eingaberaum kommen sogenannte Kernels zum Einsatz. Die Anwendung der Transformation wird effizient mit dem sogenannten Kernel-Trick umgesetzt [36]. Neuronale Netze Die Grundideen der (künstlichen) neuronalen Netze sind älter als das maschinelle Lernen selbst. Die aktuell extrem große Aufmerksamkeit haben neuronale Netze als Deep-LearningVerfahren erhalten. Damit werden neuronale Netze bezeichnet, die viele Schichten haben. Insbesondere durch große verfügbare Datenmengen und große Fortschritte in der Rechenleistung in Verbindungen mit Weiterentwicklungen der zugrunde liegenden Algorithmen ist es möglich geworden, gerade in Anwendungsdomänen im Kontext der Sprach- und Bildverarbeitung Leistungen zu erreichen, die selbst den Menschen übertreffen können. Grundlegend bleibt jedoch, dass es unter Berücksichtigung vorgegebener Netzwerkarchitekturen miteinander verknüpfte Neuronen sind. Diese verarbeiten mit vorgegebenen Funktionen Eingaben zu Ausgaben. Als Eingabe eines Neurons werden die Ausgaben der vorgelagerten Neuronen gewichtet aggregiert. Im Lernprozess eines neuronalen Netzes werden letztlich diese Gewichte so optimiert, dass möglichst die gewünschten Ausgaben erzielt werden. Die Kernidee für die Anpassung der Gewichte beruht auf dem Prinzip der sogenannten Backpropagation. Basierend auf dem Unterschied zwischen aktueller und angestrebter Ausgabe als Fehler eines Modells werden Schicht für Schicht beginnend mit der Ausgabeschicht rückwärts die Gewichte angepasst, so dass der Fehler iterativ minimiert wird. Model Ensembles In der Praxis hat sich die Kombination mehrerer Modelle zu einem sogenannten Model Ensemble bewährt, um die Leistungsfähigkeit zu steigern oder die Gefahr von Overfitting zu reduzieren [13]. Die bekanntesten Ensemble-Ansätze sind Bootstrap Aggregating, kurz Bagging, Boosting und Stacking. Beim Bagging werden basierend auf zufälligen Stichproben der Trainingsdaten mit einem Basislernverfahren unabhängig voneinander verschiedene Modelle erstellt, deren Ergebnis durch Mehrheitsentscheid (Klassifikation) oder Mittelwertbildung (Regression) kombiniert werden [6]. Sehr bekannt ist der Random-Forest-Algorithmus, bei dem mit dem Basislernverfahren Entscheidungsbäume erzeugt werden [7].

3 Grundzüge des maschinellen Lernens

129

Während Bagging die einzelnen Modelle parallel erstellen kann, erfolgt beim Boosting die Modellerstellung sequentiell, da bei jeder Modellerstellung die Fehler aus vorhergehenden Modellen berücksichtigt werden. Dadurch ist es möglich, dass sich das Basislernverfahren auf die schwierigen Fälle konzentriert. Dies kann zwar die Leistungsfähigkeit steigern, erhöht aber wiederum auch die Gefahr des Overfittings. Der bekannteste Ansatz dieser Art ist das Adaptive Boosting (AdaBoost) [35]. Sowohl beim Bagging als auch beim Boosting wird jeweils ein und dasselbe Basislernverfahren für die Modellerstellung verwendet, wobei unterschiedliche Modelle durch Variation oder Gewichtung der Trainingsdaten erreicht werden. Eine andere Möglichkeit, um verschiedene Modelle zu erhalten, die ein Model Ensemble bilden, ist die Verwendung unterschiedlicher Lernverfahren. Die Ergebnisse dieser Modelle kann wie beim Bagging durch Mehrheitsentscheid oder Mittelwertsbildung erzeugt werden oder aber durch einen weiteres zu erlernendes Modell erfolgen. Diese Ensemble-Variante wird auch als Stacking bezeichnet.

3.5.3.2 Unüberwachte Lernverfahren Die Betrachtung bekannter Verfahren ist hier auf die Clusteranalyse und die Assoziationsanalyse beschränkt. Clusteranalyse Es gibt zahlreiche Clusteranalyseverfahren, die Cluster verschiedenster Art erzeugen können [23]. Eines der bekanntesten Verfahren ist der k-Means-Algorithmus [28]. Das Verfahren soll eine Partitionierung der Datenpunkte in eine vorgegebene Anzahl k an Clustern erstellen. Dabei ist die Summe der Abstände von allen Datenpunkten zum Clusterzentrum mit dem jeweils kleinsten Abstand zu minimieren. Nach einer zufälligen Initialisierung wird eine alternierende Optimierung mit folgenden beiden Schritten durchgeführt. Zum einen werden alle Datenpunkte dem Clusterzentrum zugeordnet, zu dem sie den jeweils kleinsten Abstand haben. Zum anderen wird ein Clusterzentrum als Mittelwert aller ihm zugeordneten Datenpunkte berechnet. Das Verfahren konvergiert nach einer endlichen Anzahl an Iterationen in einem lokalen Optimum. Typischerweise wird das Verfahren deshalb mit mehreren zufälligen Initialisierungen und auch mit unterschiedlichen Werten für die Clusteranzahl k durchgeführt. Da die Summe der Abstände der Datenpunkte zu ihren jeweiligen Clusterzentren mit wachsender Clusteranzahl k stets abnimmt, ist die Clusteranzahl k sinnvoll zu begrenzen, um eine Form des Overfittings für unüberwachtes Lernen zu verhindern. Sehr bekannt ist auch das hierarchische agglomerative Clustering (HAC), das baumartige Clusterstrukturen erzeugt, die sich mit Hilfe von Dendrogrammen sehr gut visualisieren lassen [39]. Die Berechnung beruht auf den paarweisen Abständen zwischen allen Datenpunkten und wächst daher kubisch mit der Anzahl der Datenpunkte. Daher ist die Nutzbarkeit bereits bei Anwendungen mit nur mäßig großen Datenmengen stark eingeschränkt.

130

C. Lanquillon

Dichtebasierte Clusterverfahren wie DBSCAN identifizieren zusammenhängende, mit Datenpunkten dicht bevölkerte Regionen im Eingaberaum als Cluster und werden insbesondere dann bevorzugt eingesetzt, wenn die zu entdeckenden Cluster unregelmäßige Formen aufweisen können [17]. Assoziationsanalyse Bei der Assoziationsanalyse erhält insbesondere die Erzeugung von Assoziationsregeln eine sehr große Aufmerksamkeit und einige der Methoden sind sehr weit verbreitet. Assoziationsregeln dienen zunächst der Beschreibung einer Datenmenge. Ausgangspunkt ist dabei eine meist große Menge an Transaktionen, die jeweils das gemeinsame Auftreten von Ereignissen zusammenfassen, wie etwa gleichzeitig in einem Warenkorb erworbene Artikel oder aber auch Fehlerzustände in einem Fahrzeug in einem vorgegebenen Zeitraum. Aus dieser Menge sollen Wenn-Dann-Regeln der Form „wenn Ereignis A eintritt, dann tritt auch Ereignis B ein“ zusammen mit Kennzahlen erzeugt werden, die die Regeln charakterisieren, wie etwa die Konfidenz der Regel, d. h. die Wahrscheinlichkeit, dass die Regel zutrifft, wenn die Bedingung erfüllt ist. Die Wahrscheinlichkeiten einer Regel aus den Daten zu bezeichnen ist keine Schwierigkeit. Bei einer großen Menge an Transaktionen mit vielen verschiedenen Ereignissen jedoch die für eine Anwendung interessanten zu finden, ist zum einen aufgrund der kombinatorischen Explosion der Anzahl möglicher Regeln bei einer steigenden Anzahl an Ereignissen, deren gemeinsames Auftreten betrachtet wird, und der Schwierigkeit der Bewertung der Interessantheit für eine Anwendung eine große Herausforderung. Assoziationsregeln dienen zunächst der Beschreibung einer Datenmenge, werden dann aber oft auch für Prognoseaufgaben wie Klassifikation oder Empfehlungen verwendet. Ein sehr bekanntes Verfahren zur Erzeugung von Assoziationsregeln ist der Apriori Algorithmus [2]. In der Menge der Transaktionen sucht der Algorithmus nach häufig gemeinsam verzeichneten Ereignissen unter Vorgabe eines Schwellwerts als mindestens erwartete Häufigkeit. Aus den häufig gemeinsam beobachteten Ereignissen lassen sich Assoziationsregeln ableiten und nach weiteren Kriterien filtern. Die kombinatorische Vielfalt, die sich bei der Betrachtung einer steigenden Anzahl an Ereignissen ergibt, wird mit der sogenannten Apriori-Eigenschaft bekämpft. Diese besagt, dass eine Menge von Ereignissen nicht mehr häufig genug in der Menge der Transaktionen enthalten sein kann, wenn bereits eine Teilmenge dieser Ereignisse nicht häufig genug vorkam. Das Ausnutzen dieser Eigenschaft führt oft zu einer starken Reduktion des Suchraums, so dass das Verfahren die erlebbare Möglichkeit hat, interessante Regeln zu generieren. Der FP-Growth-Algorithmus gilt als Verbesserung der Regelerzeugung hinsichtlich der Effizienz [20, 21]. Was als Ergebnis bei hinreichend viel Zeit und Rechenleistung zu erwarten ist, ist bei allen deterministisch arbeitenden Algorithmen für die Erzeugung von Assoziationsregeln identisch.

3 Grundzüge des maschinellen Lernens

3.6

131

Zentralisiertes und verteiltes Lernen: Wo wird gelernt?

Klassische Ansätze zum maschinellen Lernen gehen davon aus, dass die Daten in einem Speicherort (Rechner) zusammengeführt sind und dann der Lernprozess auf einem einzigen Rechner stattfindet. Es handelt sich demnach um ein zentralisiertes Lernen auf einem Rechner (engl. single node centralized learning). Dieses Lernszenario ist in Abb. 3.16 (links) dargestellt. Mit wachsendem Datenvolumen und wachsenden Anforderungen an die Rechenleistung für die Verarbeitung der Daten und die Modellerstellung reichen die Ressourcen für viele Anwendungen längst nicht mehr aus. In vielen Anwendungen liegen die Daten bereits verteilt vor und ein Zusammenführen an einem Speicherort ist etwa aus Gründen der Größe der Datenmenge nicht möglich oder aus Gründen des Datenschutzes nicht erwünscht. Während eine begrenzte Skalierung durch Nebenläufigkeit auf einem Rechner oder Parallelisierung von unabhängig berechenbaren Teilaufgaben erreicht werden kann, werden die oben genannten Probleme in größerem Stil üblicherweise durch verteiltes Lernen auf einem Verbund an Recheneinheiten (Knoten, engl. nodes), einem sogenannten Cluster, gelöst.

3.6.1

Parallelisierung von Berechnungen

Die Durchführung eines Analyseprojekts ist in der Regel sehr zeitaufwendig. An dieser Stelle liegt der Fokus allerdings nicht auf der oft mühevollen Datenaufbereitung, sondern auf der erforderlichen Rechenleistung für die Modellerstellung. Die Anwendung unterschiedlicher Lernverfahren und die Suche nach möglichst guten Einstellungen (Hyperparameter) eines jeden Lernverfahrens unter Zuhilfenahme der k-fachen Kreuzvalidierung führt dazu, dass

Abb. 3.16 Klassisches zentralisiertes maschinelles Lernen (links) im Gegensatz zum horizontal verteilten Lernen (rechts)

132

C. Lanquillon

oft eine große Menge an Modellen erstellt wird, bis wenigstens eines davon als technisch brauchbar tiefer fachlich evaluiert wird. Das Ausprobieren der verschiedenen Lernverfahren und der Varianten der Einstellungen für die Hyperparameter lässt sich zwar sehr gut automatisieren, so dass der Aufwand für den Menschen überschaubar bleibt, aber der Bedarf an Rechenleistung ist oft sehr hoch. Da zwischen den Berechnungen der einzelnen Trainingsläufe in der Regel keine Abhängigkeiten bestehen, lassen sich die Berechnungen sehr gut parallelisieren, solange auf alle Trainingsdaten von jedem an den Berechnungen beteiligtem Knoten aus zugegriffen werden kann. Die Durchführung der Modellierungsphase wird nahezu linear mit der Anzahl der Recheneinheiten skalieren. Wenn ein Lernverfahren tatsächlich aus mehreren Modellen besteht, dann lassen sich auch die Berechnungen für deren Erstellung sehr leicht parallelisieren, solange es keine Abhängigkeiten zwischen den Modellen gibt, wie beispielsweise beim Random-ForestAnsatz oder anderen Model Ensembles, die auf dem Prinzip des Baggins aufbauen. Die Parallelisierung der Berechnung einzelner Teilaufgaben innerhalb des Lernprozesses eines Lernverfahrens erfordert dagegen eine genauere Betrachtung des Vorgehens des jeweiligen Algorithmus. Lernverfahren, die nur eine Iteration benötigen, sind für eine parallele Umsetzung und einen Einsatz bei großen Datenmengen sehr gut geeignet, insbesondere dann, wenn sich die Objekte über ihre Schlüssel gleichmäßig auf die Knoten zur Berechnung verteilen lassen. Naive-Bayes oder k-Nächste-Nachbar-Verfahren sind Beispiele für diesen Fall. Auch mehrere Iterationen stellen kein Problem dar, wenn die erforderliche Kommunikation zwischen den Knoten, also etwa der Austausch von Zwischenergebnissen, von Iteration zu Iteration begrenzt ist. Der klassische k-Means-Algorithmus für die Clusteranalyse zählt z. B. zu dieser Gruppe. Viele Iterationen mit einem hohen Kommunikations- und Synchronisationsaufwand lassen sich dagegen weniger gut parallelisieren. Als Beispiel für diesen Fall sei die Support Vector Machine (SVM) genannt. Auch eine sehr schiefe Schlüsselverteilung ist schädlich, da sich dann die Rechenlast nicht gut auf die verschiedenen Knoten verteilen lässt.5 Bei Lernverfahren, die sich nicht leicht parallelisieren lassen, kann durch Anpassung der Berechnungen bei genauer Kenntnis der Algorithmen eine gewisse Parallelisierung erreicht werden. Letztlich ist die Entwicklung skalierbarer Lernverfahren aktuell immer noch eine große Herausforderung beim maschinellen Lernen.

3.6.2

Klassisches verteiltes Lernen

Solange auf alle Trainingsdaten von allen Knoten aus zugegriffen werden kann, lässt sich durch Parallelisierung der Berechnungen sehr viel erreichen. Bei modernen MaschineLearning-Anwendungen ist die Menge der als Trainingsdaten zu verwendenden Daten oft 5 Für eine ausführlichere Betrachtung dieser Thematik sei der Leser beispielsweise an Beschreibungen

der Umsetzung von Lernverfahren im Kontext von Hadoop Map-Reduce verwiesen [11].

3 Grundzüge des maschinellen Lernens

133

so groß, dass die Daten verteilt vorliegen. Ebenso gibt es Modelle, die so groß sind, dass sie nicht auf einer Recheneinheit Platz finden. So wird generell beim verteilten Lernen zwischen Datenparallelität und Modellparallelität unterschieden. Auch hybride Ansätze sind möglich. Eine weitere wichtige Unterscheidung ist die Frage, ob eine vertikale oder horizontale Aufteilung der Daten oder Modelle vorliegt. Während man durch die Verteilung einige Probleme lösen kann, gibt es zugleich neue Herausforderungen. Nicht alle Lernverfahren sind gleichermaßen für ein verteiltes Lernen geeignet. Insbesondere die Kommunikation zwischen den beteiligten Knoten und die Synchronisierung von Modellen bzw. das Zusammenführen von Ergebnissen muss unter Berücksichtigung der Lernverfahren gelöst werden.

3.6.2.1 Datenparallele Ansätze Beim Lernen aus verteilt vorliegenden Daten wird meist die verteilte Erstellung eines Modells angestrebt, dessen Leistungsfähigkeit zumindest näherungsweise der Leistungsfähigkeit eines Modells entspricht, das auf einem einzelnen Rechner bei Zugriff auf alle verfügbaren Daten hätte gelernt werden können. Je nach verfügbaren Ressourcen an Speicherplatz, Rechenleistung und Bandbreite des Netzwerks für die Kommunikation oder vorgegebenen Obergrenzen für die Nutzung dieser Ressourcen werden jedoch auch Abstriche hinsichtlich der Leistungsfähigkeit geduldet. Ausgehend von einer logischen Sicht auf alle Daten als integrierte Datenmatrix liegt bei einer horizontalen Verteilung bei den beteiligten Recheneinheiten (Knoten) eine Teilmenge der vollständigen Zeilen mit allen Spalten (Merkmalen) vor, wie in Abb. 3.16 (rechts) dargestellt. Bei einer vertikalen Verteilung liegen bei jedem Knoten alle Zeilen aber nur eine Teilmenge der Spalten vor (Abb. 3.17, links). Bei einem hybriden Verteilungsansatz kommen beide Varianten zusammen (Abb. 3.17, rechts).

Abb. 3.17 Vertikal verteiltes Lernen (links) und Lernen mit hybrider Datenparallelität (rechts)

134

C. Lanquillon

Wenn eine Verteilung der Daten nicht durch die Anwendung vorgegeben ist, sorgt eine zentrale Instanz für eine Verteilung der Daten auf die beteiligen Knoten zum Zweck der Modellerstellung. Die Knoten senden je nach Lernverfahren und Umsetzung Zwischenergebnisse, Teilmodelle oder Modellaktualisierungen an eine zentrale Instanz zurück. Diese wird oft als Parameter Server bezeichnet, da seine Hauptaufgabe in der Aktualisierung und Verwaltung der Parameter des (globalen) Modells liegt [26]. Diese Vorgehensweise stellt sehr große Anforderungen hinsichtlich der Synchronisierung aktueller Modellparameter zwischen den beteiligen Knoten. Die Möglichkeiten der Vereinigung verteilt erstellter Modelle hängt stark von der Art der Modelle ab. Welche Eigenschaften müssen Lernverfahren haben, damit sie für den Einsatz in verteilten Lernszenarien geeignet sind? Üblicherweise durchläuft ein Lernverfahren die Trainingsdaten, um Aggregationen (meist Summen) und andere Kennzahlen zu berechnen. Diese werden dann verwendet, um die Parameter eines zugrunde liegenden Modells zu bestimmen oder zu optimieren [42]. Während Naive-Bayes-Verfahren z. B. ihre Parameter jedoch in einer Iteration über die Trainingsdaten berechnen oder aktualisieren können, kommt bei den meisten Lernverfahren, wie etwa bei neuronalen Netzen und somit auch bei Deep-Learning-Verfahren, erschwerend hinzu, dass sie in einem Lernprozess mehrfach über die Trainingsdaten iterieren müssen, bis ein Konvergenzkriterium erreicht ist. Je nach dem, wie komplex die Abhängigkeiten und somit der Kommunikationsaufwand für die Synchronisation von Zwischenständen eines Modells ist, erschwert dies die Parallelisierung eines Lernverfahrens. Inkrementelle Lernverfahren können auf einen aktuellen Stand aufsetzen und neue Daten in das bestehende Modell einfließen lassen. Dies erleichtert die Parallelisierung des Lernprozesses bei horizontaler Verteilung der Daten, da Modellaktualisierungen aus beliebigen Teilmengen an Lernbeispielen berechnet und an den Parameter-Server übermittelt werden können. Als Beispiel dafür sei die Gruppe der Naive-Bayes-Verfahren genannt, bei denen sich die auf den Trainingsdaten berechneten Parameter (Wahrscheinlichkeiten) basierend auf neuen Daten einfach aktualisieren lassen. Somit können verteilt ermittelte Zwischenergebnisse problemlos zusammengeführt werden. Aber auch neuronale Netze und somit auch Deep-Learning-Verfahren lassen sich ohne Zugriff auf alle Trainingsdaten etwa mit Mini-Batches oder stochastischem Gradientenabstieg (engl. stochastic gradient decent (SGD)) gut inkrementell anpassen [9, 27]. Letztlich lassen sich alle Verfahren, deren Optimierungsprozess auf Parameteraktualiserungen basierend auf inkrementelle Ansätze wie SGD anstatt durch klassische batchorientierte Gradientenverfahren beruhen, gut parallelisieren. Zu dieser Gruppe gehören beispielsweise kMeans-Verfahren und sogar Support Vector Machines. Neben den oben genannten Verfahren, die gut mit einer horizontalen Verteilung der Daten umgehen können, gibt es auch Verfahren, die zwar Zugriff auf alle Zeilen der Datenmatrix benötigen, aber nicht auf alle Spalten (Merkmale) gleichzeitig zugreifen müssen, so dass eine vertikale Verteilung der Daten möglich ist. Beim Lernen von Entscheidungsbäumen kann die Berechnung eines Kriteriums zur Bewertung der Eignung von Merkmalen für

3 Grundzüge des maschinellen Lernens

135

eine Aufteilung der Daten an einem inneren Baumknoten wegen der Unabhängigkeit der einzelnen Berechnungen problemlos bei vertikaler Datenverteilung durchgeführt werden, solange die Zielgröße in den einzelnen Partitionen verfügbar ist.

3.6.2.2 Modellparallele Ansätze Wenn Modelle sehr groß werden, dann kann auch eine Partitionierung und Verteilung eines Modells auf mehrere Knoten sinnvoll sein. Die beteiligten Knoten berechnen oder aktualisieren dann basierend auf den ihnen verfügbaren Daten einzelne Teile eines Modells. Da ein Knoten nur für einen Teil eines Modells verantwortlich ist, ist der notwenige Kommunikationsbedarf zur Synchronisierung der Modellparameter deutlich kleiner. Solange es bei der Modellparallelität auf Grund der Größe nur um die verteilte Speicherung ginge und eine zentrale Instanz, der Parameter-Server, die Verwaltung und Aktualisierung des Modell übernähme, gäbe es nichts weiter zu beachten. Bei einem großen Modell ist es jedoch naheliegend, dass auch die Berechnungen für die Modellaktualisierungen zerlegt und verteilt werden müssen, um den Berechnungsaufwand in den Griff zu bekommen. Insofern greifen an dieser Stelle dieselben Überlegungen hinsichtlich der Modelleigenschaften, die bereits bei der Parallelisierung der Berechnungen angestellt wurden. Da die Erstellung großer Modelle typischerweise auch sehr große Datenmengen voraussetzt, werden modellparallele Ansätze zusammen mit Datenparallelität in hybriden Ansätzen kombiniert [18]. Die Verteilung von Berechnungsschritten unter Berücksichtigung von verteilt vorliegenden Trainingsdaten ist eine sehr große Herausforderung und bedarf einer sehr genauen Kenntnis der zugrunde liegenden Modelle.

3.6.3

Föderiertes Lernen

Erste Ansätze des föderierten Lernens (engl. federated learning) zielten auf die verteilte Modellerstellung auf vielen kleineren Recheneinheiten mit begrenzter Rechenleistung und teilweise eingeschränkter und begrenzter Netzwerkkonnektivität ab, die jeweils nur Zugriff auf ihre eigenen Daten haben [24, 25]. Verallgemeinert ist föderiertes Lernen eine besondere Variante des verteilten Lernens, die es mehreren Parteien erlaubt, auf dedizierten Recheneinheiten unter Wahrung des Datenschutzes ein Modell kollaborativ zu erstellen [43]. Daher ist der Einsatz des föderierten Lernens besonders dann sinnvoll, wenn Daten inhärent verteilt sind und eine Integration zu aufwendig oder aus Gründen des Datenschutzes nicht erwünscht ist oder wenn die Kommunikation bei einer verteilten Modellerstellung sonst zu komplex wäre. Für große Modelle, die eine Verteilung erfordern, ist der Ansatz wegen der vielen lokalen Kopien der Modelle dagegen nicht geeignet.

136

C. Lanquillon

Jeder der beteiligten Knoten erstellt ein Modell auf Basis der ihm zur Verfügung stehenden Daten und speichert sein Modell lokal. Typisch für föderiertes Lernen ist, dass die mit den jeweiligen Knoten assoziierten Parteien auch die Dateneigner sind, so dass eine anwendungsinhärente Verteilung der Daten im Lernprozess ausgenutzt wird. Beim allgemeinen verteilten Lernen kann dagegen auch wie oben beschrieben eine zentrale Instanz die Verteilung der Daten für die Modellerstellung auf die einzelnen Knoten steuern. Die Kommunikation über teilweise begrenzte oder unzuverlässige Netzwerke wird meist als ein stark limitierender Faktor betrachtet. Insbesondere bei einer großen Anzahl von Knoten ist bei klassisch verteilten Ansätzen der notwendige Kommunikationsaufwand für die Synchronisation oft nicht mehr realisierbar [32]. Deshalb soll die Übertragung von Zwischenergebnissen wie Modellaktualisierungen während der Lernphase minimiert werden. So werden die lokal aktualisierten Modelle in tendenziell eher größeren Abständen an eine zentrale Instanz gesendet, wo sie zu einem gemeinsamen (globalen) Modell zusammengeführt werden. Diese Instanz wird bisweilen auch beim föderierten Lernen als ParameterServer bezeichnet, wenn auch die Aufgaben stärker eingeschränkt sind. Der Aufwand für die Kommunikation und Synchronisation ist beim Zusammenführen vollständiger lokaler Modelle zu einem globalen Modell üblicherweise deutlich geringer als die stetige Verarbeitung von Modellaktualisierungen bei anderen Varianten des verteilten Lernens. Für weitere Modellanpassungen wird das gemeinsame Modell wieder an die lokalen Recheneinheiten zurückgespiegelt. Auch beim föderierten Lernen wird zwischen Ansätzen mit horizontaler und vertikaler Verteilung der notwenigen Daten unterschieden wie in Abb. 3.18 dargestellt. Beim horizontalen föderierten Lernen hat jeder beteiligte Knoten eine Teilmenge der vollständigen

Abb. 3.18 Klassisches zentralisiertes maschinelles Lernen (links) im Gegensatz zum horizontal verteilten Lernen (rechts)

3 Grundzüge des maschinellen Lernens

137

Zeilen der Datenmatrix. Dieser Ansatz wird oft verwendet, wenn es eine große Anzahl von Datenquellen mit vergleichbaren Datenstrukturen gibt, die aber nicht zu einer Datenbasis integriert werden können oder dürfen. Beispielsweise zählen dazu die Daten, die bei der Nutzung von Produkten, etwa Automobile oder mobile Endgeräte, oder Diensten individuell bei jedem Nutzer und jeder Nutzerin anfallen, aber zur Wahrung der Privatsphäre nicht an einem zentralen Ort zusammengeführt werden dürfen. Oftmals gibt es in derartigen Situationen auch eine starke Unausgeglichenheit hinsichtlich der Verteilung der Daten, was für manche Ansätze zum verteilten Lernen problematisch sein kann. Beim vertikalen föderierten Lernen hat jeder Knoten zwar alle Zeilen der Datenmatrix (oder wenigstens einen Großteil davon), aber nur eine Teilmenge der Spalten. Ebenfalls aus Gründen des Datenschutzes mag ein Verbinden der einzelnen Teilbereiche der Daten nicht erwünscht oder erlaubt sein. Dies lässt sich beispielsweise beobachten, wenn mehrere Unternehmen in einem gemeinsamen Vorhaben ein Modell aus verschiedenen Datenquellen erstellen wollen, ohne dabei die Kontrolle über den Zugriff auf die eigenen Daten aufzugeben.

3.7

Zusammenfassung und Ausblick

Beim maschinellen Lernen werden auf Basis von Daten Lösungen ohne explizite Programmierung gefunden. Sobald die Aufgabenstellung klar definiert ist, gibt es für die Qualität der Lösung zwei entscheidende Einflussfaktoren: die Daten als Eingabe für die Lernverfahren und die Lernverfahren selbst. Im Folgenden werden einige aktuelle Herausforderungen dargestellt, die sich aus der Bereitstellung und Verwendung von Daten und Lernverfahren für das maschinelle Lernen ergeben. Sie begründen allgemeine Forschungsaktivitäten im Bereich des maschinellen Lernens.

3.7.1

Einfluss der Daten

More data beats clever algorithms, but better data beats more data.6 – Peter Norvig

Möglichst viele qualitativ hochwertige Daten sind ideal, um daraus zu lernen. Welche Probleme und Herausforderungen sich dahinter verbergen, soll an dieser Stelle betrachtet werden.

6 Dieses Zitat wird Peter Norvig zugeschrieben und oft verwendet. Eine wissenschaftliche Quelle lässt sich dafür jedoch nicht finden.

138

C. Lanquillon

3.7.1.1 Die Qualität der Daten Dass die Qualität der Daten wichtig ist, leitet sich direkt aus dem bekannten Garbage-InGarbage-Out-Prinzip ab. Qualität bezieht sich stets auf den Einsatzzweck. In vielen Anwendungen stehen allerdings Daten zum Lernen bereit, die für einen anderen Zweck erzeugt und gespeichert wurden. Aus Sicht der Statistik findet daher vielfach eine Sekundäranalyse statt und es muss insbesondere überprüft werden, ob die verfügbaren Daten repräsentativ für die Aufgabenstellung sind. Aber auch andere Qualitätsmerkmale, die für eine geplante Anwendung relevant sind, sollten überprüft werden. Während sich wichtige Qualitätsmerkmale, wie etwa Korrektheit oder Genauigkeit, oft schwer validieren lassen, gehört das Erkennen und Behandeln von Ausreißern und fehlenden Werten zum Pflichtprogramm bei der Datenaufbereitung. Selbst wenn die Daten nur aus einer oder wenigen bekannten und verlässlichen Quellen stammen, ist die Datenqualität oft ein Problem. In einigen Anwendungsbereichen kommen jedoch auch noch Daten aus verteilten Quellen hinzu, deren Glaubwürdigkeit teilweise anzuzweifeln ist. Im Big-Data-Kontext wird diese Eigenschaft der Daten mit Veracity bezeichnet. Eine zentrale Herausforderung ist es daher, wie in diesen Situationen Vertrauen in die Qualität der Daten aufgebaut und zugesichert werden kann.

3.7.1.2 Die Menge verfügbarer Daten Anwendungen maschineller Lernverfahren in der Praxis haben gezeigt, dass viele Verfahren eine vergleichbare Leistung erreichen können, wenn die Trainingsmenge, gleichbleibende Qualität vorausgesetzt, nur groß genug ist [3]. Daher muss gut überlegt werden, ob sich Kosten und Aufwand eher für bessere Algorithmen oder mehr Trainingsdaten lohnen. Sehr viele Trainingsdaten scheinen bei komplexen Lernaufgaben bedeutsamer zu sein als die Lernverfahren [19]. Nun gibt es einige Anwendungen, bei denen unerschöpflich große Datenmengen beispielsweise durch tägliche Nutzung von Diensten oder Produkten bereitstehen. Allerdings könnte aus Gründen des Datenschutzes die beliebige Nutzung von Daten untersagt sein, so dass sie zur Lösung einer Lernaufgabe nicht zur Verfügung stehen. In anderen Anwendungen wiederum kann die Menge der verfügbaren Daten etwa wegen aufwendiger oder kostenintensiver Bereitstellung stark begrenzt bleiben. So mögen in vielen Anwendungen zwar große Mengen an Beobachtungen vorliegen, aber es fehlen oft Werte der Zielgröße, um die Daten für überwachte Lernverfahren vollumfänglich nutzen zu können. Die kontrollierte und sichere Datenbereitstellung für das maschinelle Lernen unter Berücksichtigung von Vorgaben des Datenschutzes stellt eine Herausforderung dar, deren Bedeutung bei stärkerer Automatisierung und Verbreitung in verschiedenen Anwendungsdomänen deutlich zunehmen wird.

3 Grundzüge des maschinellen Lernens

3.7.2

139

Einfluss der Lernverfahren

Gemäß Wolperts No-Free-Lunch-Theorem gibt es kein Lernverfahren, das bei allen Lernaufgaben eines Typs durchgängig immer das beste ist [40]. Daher werden üblicherweise immer mehrere Lernverfahren evaluiert, um eine angemessene Lösung zu finden. Wie oben beschrieben stellt das Verhindern von Overfitting die zentrale Herausforderung beim Anwenden maschineller Lernverfahren dar. Das Erkennen von Overfitting mithilfe separater Test- bzw. Validierungsdaten, die nicht für die Modellerstellung genutzt wurden, ist ein typisches Vorgehen beim maschinellen Lernen und wurde bereits als allgemeines analytisches Entwurfsmuster vorgestellt. Overfitting nicht nur zu erkennen, sondern gleich zu vermeiden, ist dagegen in der Regel speziell auf die zugrundeliegenden Lernverfahren zugeschnitten. Eine erfolgreiche Anwendung maschineller Lernverfahren setzt Kenntnisse zur Vermeidung von Overfitting voraus. Im Folgenden werden einige weitere aktuelle Herausforderungen und Entwicklungen beim Einsatz maschineller Lernverfahren betrachtet.

3.7.2.1 Automatisierung Das maschinelle Lernen hat das übergeordnete Ziel, das Automatisieren zu automatisieren. Es werden nicht nur immer mehr Entscheidungsprozesse automatisiert, sondern die Erzeugung der dafür verwendeten Machine-Learning-Ergebnisse selbst wird zusehends automatisiert. Damit eine Automatisierung in der gesamten Breite der Machine-Learning-Pipeline ermöglicht werden kann, gibt es einige Aspekte zu berücksichtigen. Dies betrifft insbesondere die verlässliche Bereitstellung von Daten aus potenziell vielen verteilten Datenquellen für die Modellerstellung unter Wahrung von Datenschutz und Datensicherheit. So fallen beispielsweise viele relevante Daten verteilt bei Nutzung von Produkten oder Diensten an. Die Nutzer und Nutzerinnen legen aber immer mehr Wert auf eine Privatsphäre und sind nicht unbedingt bereit, ohne entsprechende Maßnahmen für Datenschutz und Datensicherheit ihre Daten zur Verfügung zu stellen. Derartige Aspekte werden beispielsweise beim föderierten Lernen direkt adressiert. Während die Modellerstellung als Suche nach geeigneten Lern- und Modellparameter sehr gut automatisierbar ist, benötigt eine angemessene Merkmalsaufbereitung oftmals noch Unterstützung durch menschliche Expertise. Allerdings gibt es mit der Bild- und Sprachverarbeitung bereits jetzt Anwendungen, bei denen basierend auf Deep-Learning-Ansätzen die Merkmalserzeugung stark automatisiert abläuft. Deshalb werden diese Ansätze auch als Representation Learning bezeichnet. Letztlich erfordert nicht nur, aber insbesondere der automatisierte Einsatz von MachineLearning-Modellen definierte Prozesse für die Erstellung, Nutzung, Überwachung und Anpassung von Modellen. Es muss ein ganzheitliches Model Life-Cycle Management definiert und umgesetzt werden.

140

C. Lanquillon

Beim automatisierten Einsatz von Machine-Learning-Modellen rücken neben der Modellgüte einige weitere Modelleigenschaften noch stärker in den Vordergrund. So müssen einerseits Aspekte wie Sicherheit, Robustheit und ein angemessener Grad an Transparenz und dadurch auch Nachvollziehbarkeit und Vertrauen bei den technischen Schritten entlang der Machine-Learning-Pipeline gewährleistet und andererseits juristische Fragen geklärt werden, wie etwa Haftung bei Schäden und Mängeln und Verantwortlichkeiten bei automatisch getroffenen Entscheidungen [16].

3.7.2.2 Einsatz von Ressourcen Bei vielen Machine-Learning-Anwendungen ist die Modellerstellung sehr aufwendig. Insbesondere Deep-Learning-Verfahren benötigen aufgrund der Komplexität der Modelle und der stärkeren Automatisierung bei der Merkmalserzeugung (Representation Learning) als Ersatz für die menschliche Expertise nicht nur große Datenmengen, sondern auch sehr viel Rechenleistung. Die erzielten Ergebnisse beispielsweise bei der Sprach- und Bilderkennung sind zwar sehr gut und können mit der menschlichen Erkennungsleistung mithalten oder diese sogar überbieten, aber dies gilt in der Regel nur, solange es sich um genau die Aufgabenstellung handelt, für die die Modelle erstellt wurden. Die Anpassung an veränderte Einsatzund Umweltbedingungen oder die Übertragung auf ähnliche Aufgaben (Transfer Learning) erfordert den Einsatz weiterer Ressourcen in Form neuer Trainingsdaten und noch mehr Rechenleistung. Der für größere Anwendung benötige Speicherplatz auf Festplatten und insbesondere im Hauptspeicher für Daten und teilweise auch für Modelle und die benötigte Rechenleistung übersteigt inzwischen regelmäßig die Ressourcen eines Rechners. Eine angemessene Skalierung wird, wie oben bereits dargestellt, durch Verteilung bzw. Parallelisierung und die Verwendung der Ressourcen eines Rechnerverbunds (Cluster) erreicht. Im nächsten Kapitel wird untersucht, ob und inwieweit Lösungen für einige dieser Herausforderungen gerade in Bezug auf Datenqualität und kontrollierte, sicherere Datenbereitstellung sowie das Lernen von Modellen mit verteilten Ressourcen und das kontrollierte und verlässliche Anbieten und Nutzen von Produkten und Diensten auf Basis von MachineLearning-Ergebnissen mit Hilfe von Blockchain-Technologien entwickelt werden können.

Literatur 1. Aggarwal, C.C.: Outlier Analysis, 2. Aufl. Springer & Incorporated, New York (2016) 2. Agrawal, R., Srikant, R.: Fast algorithms for mining association rules in large databases. In: Proceedings of the 20th International Conference on Very Large Data Bases, VLDB ’94, S. 487–499. Morgan Kaufmann Publishers Inc., San Francisco (1994)

3 Grundzüge des maschinellen Lernens

141

3. Banko, M., Brill, E.: Scaling to very very large corpora for natural language disambiguation. In: Proceedings of the 39th Annual Meeting on Association for Computational Linguistics, ACL ’01, S. 26–33. Association for Computational Linguistics, Stroudsburg (2001). https://doi.org/ 10.3115/1073012.1073017 4. Bishop, C.M.: Pattern Recognition and Machine Learning. Springer, Berlin (2006) 5. Boser, B.E., Guyon, I.M., Vapnik, V.N.: A training algorithm for optimal margin classifiers. In: Proceedings of the Fifth Annual Workshop on Computational Learning Theory, COLT ’92, S. 144–152. ACM, New York (1992). https://doi.org/10.1145/130385.130401. Zugegriffen: 10. Mai. 2019 6. Breiman, L.: Bagging predictors. Mach. Learn. 24(2), 123–140 (1996). https://doi.org/10.1023/ A:1018054314350 7. Breiman, L.: Random forests. Mach. Learn. 45(1), 5–32 (2001). https://doi.org/10.1023/A: 1010933404324 8. Breiman, L., Friedman, J.H., Olshen, R.A., Stone, C.J.: Classification and Regression Trees. Wadsworth & Brooks, Monterey (1984) 9. Chahal, K.S., Grover, M.S., Dey, K.: A Hitchhiker’s guide on distributed training of deep neural networks. CoRR abs/1810.11787 (2018) 10. Chapman, P., Clinton, J., Kerber, R., Khabaza, T., Reinartz, T., Shearer, C., Wirth, R.: Crisp-dm 1.0 step-by-step data mining guide. Tech. rep., The CRISP-DM consortium (2000). http://www. the-modeling-agency.com/crisp-dm.pdf. Zugegriffen: 5. März 2019 11. Chu, C.T., Kim, S.K., Lin, Y.A., Yu, Y., Bradski, G., Ng, A.Y., Olukotun, K.: Map-reduce for machine learning on multicore. In: Proceedings of the 19th International Conference on Neural Information Processing Systems, NIPS’06, S. 281–288. MIT Press, Cambridge (2006) 12. Cover, T., Hart, P.: Nearest neighbor pattern classification. IEEE Trans Inf Theory 13(1), 21–27 (1967). https://doi.org/10.1109/TIT.1967.1053964 13. Dietterich, T.G.: Ensemble methods in machine learning. In: Proceedings of the First International Workshop on Multiple Classifier Systems, MCS ’00, S. 1–15. Springer, London (2000) 14. Domingos, P.: A few useful things to know about machine learning. Commun. ACM 55(10), 78–87 (2012). https://doi.org/10.1145/2347736.2347755 15. Domingos, P.: The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World. Basic Books Inc., New York (2015) 16. Döbel, I., Leis, M., Vogelsang, M.M., Neustroev, D., Petzka, H., Riemer, A., Rüping, S., Voss, A., Wegele, M., Welz, J.: Maschinelles Lernen: Eine Analyse zu Kompetenzen, Forschung und Anwendung (2018). https://www.bigdata.fraunhofer.de/content/dam/bigdata/de/ documents/Publikationen/Fraunhofer_Studie_ML_201809.pdf. Zugegriffen: 15. Mai. 2019 17. Ester, M., Kriegel, H.P., Sander, J., Xu, X.: A density-based algorithm for discovering clusters a density-based algorithm for discovering clusters in large spatial databases with noise. In: Proceedings of the Second International Conference on Knowledge Discovery and Data Mining, KDD ’96, S. 226–231. AAAI Press (1996) 18. Geng, J., Li, D., Wang, S.: Horizontal or vertical?: A hybrid approach to large-scale distributed machine learning. In: Proceedings of the 10th Workshop on Scientific Cloud Computing, ScienceCloud ’19, S. 1–4. ACM, New York (2019). https://doi.org/10.1145/3322795.3331461 19. Halevy, A., Norvig, P., Pereira, F.: The unreasonable effectiveness of data. IEEE Intell Syst 24, 8–12 (2009). http://goo.gl/q6LaZ8. Zugegriffen: 7. Apr. 2019 20. Han, J., Pei, J.: Mining frequent patterns by pattern-growth: methodology and implications. SIGKDD Explor. Newsl. 2(2), 14–20 (2000) 21. Han, J., Pei, J., Yin, Y.: Mining frequent patterns without candidate generation. SIGMOD Rec. 29(2), 1–12 (2000) 22. Hawkins, D.: Identification of Outliers. Chapman & Hall, London (1980)

142

C. Lanquillon

23. Jain, A.K., Dubes, R.C.: Algorithms for Clustering Data. Prentice-Hall Inc., Upper Saddle River (1988) 24. Konecný, J., McMahan, H.B., Ramage, D., Richtárik, P.: Federated optimization: distributed machine learning for on-device intelligence. CoRR abs/1610.02527 (2016) 25. Konecný, J., McMahan, H.B., Yu, F.X., Richtárik, P., Suresh, A.T., Bacon, D.: Federated learning: strategies for improving communication efficiency. CoRR abs/1610.05492 (2016) 26. Li, M., Andersen, D.G., Park, J.W., Smola, A.J., Ahmed, A., Josifovski, V., Long, J., Shekita, E.J., Su, B.Y.: Scaling distributed machine learning with the parameter server. In: Proceedings of the 11th USENIX Conference on Operating Systems Design and Implementation, OSDI’14, S. 583–598. USENIX Association, Berkeley (2014) 27. Lin, H., Zhang, H., Ma, Y., He, T., Zhang, Z., Zha, S., Li, M.: Dynamic mini-batch SGD for elastic distributed training: learning in the limbo of resources. CoRR abs/1904.12043 (2019) 28. MacQueen, J.: Some methods for classification and analysis of multivariate observations. In: Proceedings of the Fifth Berkeley Symposium on Mathematical Statistics and Probability, Volume 1: Statistics, S. 281–297. University of California Press, Berkeley (1967) 29. Mitchell, T.M.: Machine Learning, 1. Aufl. McGraw-Hill Inc., New York (1997) 30. Moravec, H.: Mind Children: The Future of Robot and Human Intelligence. Harvard University Press, Cambridge (1988) 31. Nelson, G.: The Analytics Lifecycle Toolkit: A Practical Guide for an Effective Analytics Capability. Wiley & SAS Business Series. Wiley, Incorporated (2018) 32. Nilsson, A., Smith, S., Ulm, G., Gustavsson, E., Jirstrand, M.: A performance evaluation of federated learning algorithms. In: Proceedings of the Second Workshop on Distributed Infrastructures for Deep Learning, DIDL ’18, S. 1–8. ACM, New York (2018). https://doi.org/10. 1145/3286490.3286559 33. Quinlan, J.R.: C4.5: Programs for Machine Learning. Morgan Kaufmann Publishers Inc., San Francisco (1993) 34. Samuel, A.L.: Some studies in machine learning using the game of checkers. IBM J. Res. Dev. 3(3), 210–229 (1959). https://doi.org/10.1147/rd.33.0210 35. Schapire, R.E., Freund, Y.: Boosting: Foundations and Algorithms. The MIT Press, Cambridge (2012) 36. Schölkopf, B., Smola, A.J.: Learning with Kernels: Support Vector Machines, Regularization, Optimization, and Beyond. MIT Press, Cambridge (2001) 37. Shearer, C.: The crisp-dm model: the new blueprint for data mining. J. Data Warehous. 5(4), (2000) 38. Tukey, J.W.: Exploratory Data Analysis. Addison-Wesley series in behavioral science : quantitative methods. Addison-Wesley, Reading, Mass. [u.a.] (1977) 39. Ward, J.H.: Hierarchical grouping to optimize an objective function. J. Am. Stat. Assoc. 58(301), 236–244 (1963). https://doi.org/10.1080/01621459.1963.10500845 40. Wolpert, D.H.: The lack of a priori distinctions between learning algorithms. Neural Comput. 8(7), 1341–1390 (1996). https://doi.org/10.1162/neco.1996.8.7.1341 41. Wrobel, S., Joachims, T., Morik, K.: Handbuch der Künstlichen Intelligenz, 5. Aufl., chap. Maschinelles Lernen und Data Mining. Oldenbourg, München (2014). https://doi.org/10.1524/ 9783486719796 42. Wu, X., Zhu, X., Wu, G., Ding, W.: Data Mining with Big Data. IEEE Transactions on Knowledge and Data Engineering 26(1), 97–107 (2014) 43. Yang, Q., Liu, Y., Chen, T., Tong, Y.: Federated machine learning: concept and applications. ACM Trans. Intell. Syst. Technol. 10(2), 12:1–12:19 (2019). https://doi.org/10.1145/3298981

4

Blockchain und maschinelles Lernen – Ein Literaturüberblick Jerome Tagliaferri

Zusammenfassung

Blockchain und maschinelles Lernen sind zwei der vielversprechendsten Technologien unserer Zeit. Obgleich vielen nur durch Kryptowährungen und selbstfahrende Autos bekannt und greifbar, sind die Potenzial viel weitreichender. Jede neue Technologie bringt neben teils umwälzenden Veränderungen auch viele neue Herausforderungen mit sich, die verhindern, dass diese ihr volles Potenzial entfalten können. Eine dieser Herausforderungen für das maschinelle Lernen stellt der enorme Bedarf an Daten, Hardware-Ressourcen und menschlicher Expertise dar. Ein zentrales Versprechen der Blockchain-Technologie hingegen ist die Demokratisierung gerade dieser Ressourcen. Hier kommt die Verschmelzung von Technologien ins Spiel, die nicht nur Herausforderungen bezwingen, sondern auch völlig neue Anwendungsformen erzeugen kann.

4.1

Einleitung

Im ersten Kapitel wurde die Blockchain als sichere, verteilte und unveränderliche Datenbank eingeführt, die sich alle teilnehmenden Parteien eines Netzwerks teilen. Auf diese Weise können Parteien, die sich nicht kennen und daher nicht vertrauen, dennoch verlässlich Daten austauschen. Im Folgenden wird der Begriff Blockchain oft als Synonym für Distributed-Ledger-Technologie (DLT) verwendet. Wenn tatsächlich Bezug auf die Blockchain als konkrete Implementierung des generischen DLT-Begriffs genommen werden soll, wird entsprechend darauf hingewiesen. Im dritten Kapitel wurde deutlich, dass das maschinelle Lernen, Computer zur Lösung von Aufgaben befähigt, ohne sie explizit dafür zu programmieren. So hat das maschinelle J. Tagliaferri (B) Besigheim, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 S. Schacht und C. Lanquillon (Hrsg.), Blockchain und maschinelles Lernen, https://doi.org/10.1007/978-3-662-60408-3_4

143

144

J.Tagliaferri

Lernen das Ziel, zur Lösung von Aufgaben, Modelle entweder zur Beschreibung von Daten oder zur Vorhersage von Zielgrößen automatisch aus gegebenen Daten zu erstellen. Während beschreibende Modelle primär dem Erkenntnisgewinn des Menschen dienen, helfen Prognosemodelle regelmäßig etwa bei der Automatisierung von Entscheidungen oder der Optimierung von Prozessen oder Einstellungen. Im Folgenden soll untersucht werden, inwieweit sich die beiden Technologien unterstützen können. Im nächsten Abschnitt wird zunächst betrachtet, wie das maschinelle Lernen die Blockchain stärken kann. Anschließend wird untersucht, inwiefern das maschinelle Lernen von der Blockchain als Infrastruktur-Technologie profitieren kann. Die Unterstützungsmöglichkeiten werden jeweils mit aktuellen Publikationen zur Kombination der beiden Technologien untermauert. Seit dem Jahr 2018 lassen sich lediglich 27 Quellen finden, die sich verstärkt mit der Kombination der beiden Technologien auseinandersetzen. Die geringe Anzahl lässt sich insbesondere dadurch erklären, dass die Blockchain bzw. DLT als übergeordnete Technologie mit ihrem grundlegenden Einsatzgebiet als Infrastruktur-Technologie noch sehr jung ist. Die relevanten Publikationen werden anschließend anhand ihrer zentralen Aussagen strukturiert vorgestellt. Die dabei identifizierten Eigenschaften und Anwendungsformen werden in einer Konzeptmatrix zusammengefasst.

4.2

Maschinelles Lernen zur Unterstützung der Blockchain

Wie kann das maschinelle Lernen die Blockchain unterstützen? Basierend auf Überlegungen von Corea [4] diskutieren Marwala und Xing [16] allgemein basierend auf Schwachstellen und Kritikpunkten der Blockchain Möglichkeiten, wie diese durch maschinelles Lernen umgangen oder verbessert werden können. Dazu gehören insbesondere Aspekte wie Steigerung der Nachhaltigkeit durch Senken des Energieverbrauchs und Verbesserung der Latenzen im Netz (Effizienz), Skalierbarkeit sowie Sicherheit und Datenschutz etwa durch das frühzeitige Erkennen von Angriffen auf eine Blockchain. Zusammengefasst wird versucht Erkenntnisse aus den Daten der Blockchain zu ziehen, um damit die oben genannten Aspekte zu adressieren. Dinh und Thai [5] verdeutlichen dies am Beispiel von Angriffen auf Kryptowährungen. Bei einem Angriff wurden rund 50 Mio. US$ der Kryptowährung Ether entwendet, indem Fehler innerhalb eines Smart Contracts ausgenutzt wurden. Mithilfe des maschinellen Lernens und dem transparenten Charakter solcher Kryptowährungen ist es möglich, unnatürliches Verhalten aufzuspüren und Gegenmaßnahmen einzuleiten. Ebenso ist es denkbar, dass es auch zu einer automatisierten Anpassung von Komponenten innerhalb der Blockchain kommt. Eine derartige Administration ist in der Lage, Probleme bei der Skalierung, z. B. bei einer plötzlich erhöhten Transaktionsanzahl, entgegenzuwirken, indem die Blockgröße vergrößert und damit der Durchsatz an Transaktionen erhöht wird. Momentan können solche Entscheidungen Monate dauern, da Anpassungen dieser Art bei der Blockchain vom Großteil der Nutzer unterstützt werden müssen.

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

145

Würde das maschinelle Lernen in die bestehende Software zum Betrieb der Knoten in einem Blockchain-Netz eingebettet werden, könnte tatsächlich eine dynamische, aber auch transparente Anpassung des Netzwerkes autark vorgenommen werden. Wichtig dabei ist jedoch eine hohe Transparenz. Algorithmen, bei denen die Prognose und Entscheidungsfindung kaum nachvollziehbar ist, würden dem Vertrauen in die Blockchain entgegenstehen und somit keinen Mehrwert liefern. Auch müssten die automatisierten Anpassungen an der grundlegenden Infrastruktur unveränderbar nachvollzogen werden können. Dies könnte beispielsweise durch das Speichern der Informationen in einer Transaktion der Blockchain selbst vorgenommen werden. Wie dies zumindest aus analytischer Sicht innerhalb einer praktischen Umsetzung aussehen kann, zeigt Bogner [2]. Er verfolgt das Ziel, Anomalien innerhalb der EthereumBlockchain zu erkennen. Während Dinh und Thai [5] die Relevanz einer automatischen Anomalieerkennung am Beispiel des DAO Hack aufzeigen, erläutert Bogner unter Berücksichtung der CRISP-DM-Phasen, wie ein Lernverfahren Anomalien eigenständig erkennen kann. Zusätzlich können Such- und Visualisierungsmöglichkeiten das unüberwachte Lernverfahren zur Anomalieerkennung ergänzen. Eine automatische Kombination dieser Anomalieerkennung in ein bestehendes Blockchain-Netzwerk mit der damit verbundenen Automatisierung der daraus resultierenden Aktivitäten wurde von Bogner allerdings noch nicht angedacht. Das Verständnis des entdeckten Problems sowie die Einleitung von passenden Gegenmaßnahmen wird in der Ausarbeitung von Bogner menschlichen Experten überlassen. Diese Vorgehensweise verteidigt Bogner [2] mit dem Verweis auf mögliche Fehlalarme. Ein effektives System kann aus seiner Sicht zum heutigen Stand der Technik nur durch eine Kombination aus maschinellem Lernen für die Entdeckung weniger Anomalien in riesigen Transaktionsdaten und der Interpretation und Bewertung der entdeckten Sachverhalte durch einen Menschen aufgebaut werden. Eine andere Form der Analyse ist die Vorhersage bestimmter Verhaltensmuster bei der Nutzung der Blockchain. Derartige Muster und damit zusammenhängende Gruppierungen wurden von Harlev et al. [7] analysiert. In dieser Arbeit findet sich die Verknüpfung der Blockchain und des maschinellen Lernens erneut im Bereich der Kryptowährungen sowie der Analyse von Transaktionen. Dabei ist es das Ziel zu untersuchen, wie anonym die Transaktionsnetzwerke tatsächlich sind. Es werden verschiedene überwachte Lernverfahren eingesetzt, um Transaktionen und deren Teilnehmer in Gruppen zu bündeln. Diese Gruppen konnten dann wiederum bestimmten Aktivitäten wie Glücksspiel, Tauschbörsen oder Betrug zugeordnet werden. In der momentanen Ausführung war das Modell dazu in der Lage, zuvor nicht zuordenbare Gruppen mit einer Genauigkeit von rund 77 % zu bestimmen. Mithilfe dieser Informationen ist es möglich, Individuen innerhalb des Netzwerkes zu identifizieren. Auch wenn die hier aufgeführten Beispiele sich ausschließlich auf die Analyse von Kryptowährungen beziehen, ist dies nicht der einzige Anwendungsfall. Die starke Fokussierung ist eher durch die Möglichkeit der einfachen Datenbeschaffung der Kryptowährungen geschuldet. Gerade in Konsortium-Blockchains könnte es von großer Bedeutung sein, dass

146

J.Tagliaferri

maschinelle Lernverfahren mit in die Blockchain integriert werden oder mittels Oracles auf die Daten der Konsortiumsblockchain zugreifen können. Dies hätte den Vorteil, dass Smart Contracts etwa bei der Analyse der einzuhaltenden Services innerhalb eines definierten Service Level Agreements unterstützt werden könnten. Auch ist vorstellbar, dass auf diese Weise voll automatisierte Einkaufs-Ketten zwischen den Konsortiumsteilnehmern umgesetzt werden können. Die implementierten Algorithmen agierten dann wie Software-Agenten über die Blockchain.1

4.3

Blockchain zur Unterstützung des maschinellen Lernens

Die Analyse von Daten der Blockchain und Verwendung der Ergebnisse im Rahmen von Blockchain-Anwendungen wie oben beschrieben ist oft naheliegend. Dennoch gibt es deutlich mehr Literatur, die sich mit der Unterstützung des maschinellen Lernens durch die Blockchain befasst. Dabei wird insbesondere auf die wesentlichen Merkmale der Blockchain wie Datensicherheit, Smart Contracts, Incentivierung und Konsens eingegangen, die gleichzeitig zur Klassifizierung der relevanten Quellen herangezogen wurden. Mit den Themen Datenplattform und Machine-Learning-Marktplatz stehen ergänzend dazu Anwendungsformen im Fokus. Auf letzten wird detailliert im nächsten Kapitel eingegangen.

4.3.1

Datensicherheit

Unter Datensicherheit wird die Vertraulichkeit, Integrität und Verfügbarkeit von Daten verstanden. Eigenschaften, für die die Blockchain bekannt ist und ihre Stärke ausspielen könnte. Da das maschinelle Lernen Zugriff auf möglichst viele Daten benötigt, wäre ein Speichern in einer öffentlichen Blockchain sehr kostspielig. Deshalb müssen strukturelle Anpassungen vorgenommen werden, damit die Blockchain als Datenbasis für das maschinelle Lernen dienen kann. Eine wesentliche Anpassung wäre das Speichern in Off-Chain-Lösungen, die dann in regelmäßigen Abständen mit der öffentlichen Blockchain synchronisiert wird. Die Synchronisation bezieht sich dann nur auf den Hash der lokal gespeicherten Daten, um deren Unveränderbarkeit nachzuweisen. Entscheidend ist aber, dass diese Off-Chain-Lösungen trotz lokaler Bearbeitung weiterhin den gleichen Sicherheitsmechanismen wie die öffentliche Chain unterliegt. Die Schwierigkeit, die sich bei Off-Chain Lösungen ergibt, ist, dass die Konsens-Mechanismen, die in der Haupt-Chain-Anwendung finden, in der Regel auf vielen Teilnehmern basieren und somit die Integrität der Daten gewährleistet ist. In Off-Chain Lösungen haben die Validierer und Verifizierer aber keinen direkten Zugriff und somit wird die Konsens-Findung erschwert. 1 Siehe hierzu auch den Beitrag DLT im Energiesektor in diesem Buch.

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

147

Die Variante einer Off-Chain betrieben Datenbasis, die über eine öffentliche Blockchain verwaltet wird, wird von Vishwa und Hussain [23] am Beispiel von urheberrechtlich geschützten Daten aufgegriffen. Das Ziel liegt dabei in der Konzeption einer Plattform, auf welcher Nutzer ihre Werke anbieten und verkaufen können, ohne die Kontrolle über ihre Daten zu verlieren. Die Blockchain dient in diesem Fall als eine Identifizierungs- und Authentifizierungsplattform. Die Daten und Werke der Nutzer werden dazu auf einer zentralen und gesicherten Cloud-Plattform abgelegt und sind nur über spezielle Schlüssel zugänglich. Gewährt der Inhaber der Daten einem Nutzer den Zugriff, wird dieser automatisch von Smart Contracts überprüft und gewährleistet. Durch das implementierte Sicherheitsprotokoll soll sichergestellt werden, dass die Daten zwar genutzt, aber nicht entwendet werden können. In diesem Anwendungsfall wird die Sicherheit über einen unveränderbaren Smart Contract Mechanismus herbeigeführt. Verfolgt man diesen Gedanken weiter, so könnten die Daten anstatt in einer zentralen Cloud-Plattform in einem dezentralen Data-Storage Dienst wie IPFS abgelegt werden. Um die Datensicherheit trotz dezentraler Datenhaltung sicherzustellen, müssten die Daten verschlüsselt gespeichert und die Überprüfung und der Zugang dann über Smart-Contracts geregelt werden, wie von Vishwa und Hussain aufgeführt [23]. In diesem Kontext sind auch die Arbeiten von Yaji et al. [29] zu nennen, dessen Untersuchungsgegenstand unterschiedliche Verschlüsselungsmethoden unter der Berücksichtigung von automatisierter Datenverarbeitung und der Blockchain ist. Dabei wird aufgezeigt, dass es trotz momentan verwendeter Verschlüsselung, wie SHA-256 oder MD5, Angriffsszenarien gibt, die die Datensicherheit innerhalb der Blockchain gefährden. Dabei sind gerade homomorphe Verschlüsselungsmethoden interessant, da es hierdurch möglich ist, maschinelles Lernen auf verschlüsselten Daten zu betreiben. Diese Fähigkeit erhält ihre Relevanz, sobald Modelle auf privaten, verteilten Daten trainiert werden sollen. Weiterhin hat sich gezeigt, dass homomorphe Methoden nicht nur die Datensicherheit innerhalb der Blockchain erhöht, sondern auch eine effiziente Lösung für verteilte Lernmethoden darstellt. Die Verwendung homomorpher Verschlüsselungsmethoden kann auch die Verwendung eines dezentralen Data-Storage wie das IPFS enorm erleichtern, da Daten somit verteilt auf beliebigen Knoten liegen könnten, ohne dass die Sicherheit gefährdet ist. Da es auch Ansätze gibt, die Bereitstellung von Speicherplatz für IPFS über Kryptowährungen zu incentivieren, würde die Kombination aus homomorphen Verschlüsselungen, IPFS und Belohnungssystem über die Blockchain sicherlich eine kostengünstige Speicherung und Auswertung von Massendaten für große und kleine Unternehmen ermöglichen. Auch wenn an diese Stelle der Aspekt der Datensicherheit explizit im Vordergrund stand, ist zu berücksichtigen, dass die Datensicherheit als Kernthema auch bei den folgenden Aspekten ein Rolle spielt. Ohne die Betrachtung der Datensicherheit ist es schwierig, die Blockchain als Unterstützung für maschinelles Lernen zu verwenden.

148

4.3.2

J.Tagliaferri

Smart Contracts

Smart Contracts spielen im Bereich der Automatisierung eine wichtige Rolle, da es sich hierbei um transparente Skripte handelt, die ohne den Eingriff menschlicher Akteure agieren können. Durch die Eliminierung des menschlichen Risikofaktors entsteht eine weitere Sicherheitsebene, denn die meisten Fehler werden immer noch vom Menschen gemacht. Eine Automatisierung der Prozesskette nicht nur innerhalb einer Organisation, sondern gegebenenfalls über mehrere Organisationen hinweg, wäre mittels Smart Contracts möglich. Im Lernprozess des maschinellen Lernens sind ebenfalls zentralisierte Anwender vorhanden. Alle Daten müssen zu einem Data Scientist, der dann den Lernprozess vom Datenzugriff bis hin zur Modellbereitstellung bearbeitet. Mittels Smart Contracts könnten Teile dieses Prozesses automatisiert werden und es wäre möglich, die Zentralisierung dieses Lernprozesses über Unternehmensgrenzen hinweg zu dezentralisieren. Lu et al. [14] spricht in seiner Arbeit genau solche zentralen Prozesse an und nutzt die Blockchain Technologie, um eine crowd-source-basierte Lösung zur Ausführung von maschinellen Lernprozessen zwischen sich nicht vertrauenden Individuen zu etablieren. Damit dies jedoch möglich wird, müssen noch aktuelle Limitierungen der Smart Contracts überwunden werden. Eine dieser Limitierungen ist die Komplexität und der damit einhergehende hohe Bedarf an Rechenleistung der auszuführenden Algorithmen. Die nutzbare Rechenleistung ist jedoch bei öffentlichen Blockchain-Lösungen streng limitiert, etwa über die Bepreisung einzelner Berechnungsschritte wie bei Ethereum mit der Währung GAS. So wird die Ausführung rechenintensiver Programme erschwert, wie sie z. B. beim maschinellen Lernen vorkommen. Um diese Limitierung zu umgehen, stellt Lu et al. [14] ein Konzept vor, in dem rechenintensive Prozesse auf viele Teilnehmer ausgelagert werden und jeder Teilnehmer für die erbrachte Leistung automatisiert vergütet werden kann. Ein Konzept, das in seiner Form dezentralen autonomen Organisationen ähnelt. Durch dieses Prinzip können auf Basis spieltheoretischer Ansätze Ressourcen und Dienste zur Verfügung gestellt und völlig autonom genutzt werden. Eine Untersuchung in diesem Kontext ist wichtig, da entgegen der Vorstellung ein Smart Contract identisch auf vielen Knoten ausgeführt wird. Dies ist zunächst aber kein verteiltes Rechnen, in dem jeder Knoten seine Ressourcen zu einem leistungsstarken Superrechner zusammenführen kann, sondern die vielen Knoten werden redundant verwendet. Ein Anpassen der unterliegenden Logik wäre somit ebenfalls notwendig. Vereinzelt ist dies bei permissioned Blockchains wie Hyperledger Fabric heute schon möglich, bei dem nicht auf jeden Knoten der gleiche Smart Contract laufen muss. Die zweite relevante Ressource neben der verfügbaren Rechenleistung stellt die Verfügbarkeit von großen Datenmengen dar. Als Öl des 21 Jahrhunderts‘ bezeichnet, steigt das ’ Vorkommen von Daten exponentiell an. Die Problematik, die sich hierbei stellt, kommt der Öl-Metapher insoweit nahe, dass es nur wenige Unternehmen gibt, welche ausreichend Zugang zu deren Quellen besitzen.

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

149

Der medizinische Sektor stellt dabei eine der Datenquellen dar, die aus Gründen des Datenschutzes extrem schwer zu erschließen ist. Dennoch lieferte diese Datenquelle einen großen Nutzen für alle Beteiligten, sofern eine zielgerichtete Auswertung ermöglicht würde. Wie Shae und Tsai [21] schreiben, sind diese Daten zudem stark fragmentiert und damit auf den unterschiedlichsten Systemen in einem Unternehmen und über Unternehmensgrenzen hinweg gespeichert. Um diese Herausforderungen zu lösen, wird die BlockchainTechnologie eingesetzt, um die unterschiedlichen Datenquellen zusammenzuführen, ohne die Datensicherheit zu vernachlässigen und die Datenhoheit zu verlieren. Über die Blockchain wird es möglich, dass jeder Patient und jede Patientin jederzeit bestimmen kann, ob der Zugang zu den eigenen Daten durch Dritte ermöglicht werden sollte oder nicht. Damit die strengen Anforderungen auch während der Verarbeitung durch maschinelle Lernverfahren gewährleistet werden können, könnte auf das föderierte Lernen als Form des verteilten Lernens zurückgegriffen werden. Die Architektur hält dabei die einzelnen Daten lokal (Offchain) und stellt diese über eine Blockchain zur Verfügung. Smart Contracts regeln den Zugriff sowie die Ausführung des verteilten Lernverfahrens. Die Rechenleistung muss in diesem Anwendungsfall von den Datenhaltern erbracht werden. Durch die Möglichkeit, die Daten bei vertrauenswürdigen Partnern lokal zu speichern, stellt diese Idee eine durchaus sichere Lösung für die Verarbeitung von sensiblen Daten dar. Wird das Szenario um weitere Akteure, die ebenfalls teile der Daten gespeichert haben, aber nicht Teil der vertrauenswürdigen Partner sind, erweitert und diese Daten auch verwertbar gemacht, treten erhöhte Risiken wie Manipulation des Systems oder der Datenabzug durch unberechtigte Dritte stärker in den Vordergrund. Zhu et al. [30] zeigt in seinem Beitrag, wie eine derartige heterogene Landschaft umgesetzt werden kann, da er vor allem durch die weitreichende Verfügbarkeit von Smartphones und Wearables freie Rechenleistung und wesentlich mehr Daten durch die in den Smart Homes verbauten Sensoren sieht. Für den Aufbau der hybriden Welt sieht Zhu et al. drei wesentliche Ebenen in der Architektur vor. Sie bestehen aus Partizipanten, die z. B. die mobilen Endgeräte oder ähnliches sein können, lokalen Hubs, in denen die Daten lokal gespeichert und ausgewertet werden, und der Blockchain als Backbone für die Verteilung der Modelle und deren Validierung. Da es sich bei diesen Daten fast ausschließlich um private Daten handelt, wird auch hier die Nutzung eines verteilten Lernverfahrens bevorzugt. Ergänzend betrachtet Zhu et al. unterschiedliche Szenarien, in denen fehlerhafte oder bösartige Geräte Teil des Netzwerkes sind. Derartige Geräte können sich byzantinisch verhalten und stellen daher ein großes Sicherheitsrisiko für die Qualität der Modelle wie auch für die restlichen Beteiligten dar, da die manipulierten Ergebnisse durch den verteilten Lernansatz mit zu einem Gesamtergebnis konsolidiert werden könnten. Um dies zu verhindern, wird die Blockchain-Technologie, die sich ausgiebig mit diesem Problem beschäftigt hat, als Lösung integriert. Dies wird möglich, da Smart Contracts – in der vorgeschlagenen Architektur – jegliche Zugriffs-, Speicher- und Rechenoperationen durchführen und es schließlich unter den Nutzern zu einem Konsens kommen muss. Die Blockchain-Technologie kommt in diesem Beispiel wieder als Basistechnologie zum Einsatz und schafft die nötige Umgebung, in der mittels maschineller Lernverfahren auch kritischere Daten verteilt ausgewertet werden können.

150

4.3.3

J.Tagliaferri

Incentivierung

Ein weiterer Aspekt der Blockchain-Technologie, der bei Kryptowährungen eine zentrale Rolle spielt, ist die Incentivierung der Teilnehmer als wichtigster Teil des dezentralen Netzwerkes. Diese Funktion spielt in vielen Anwendungsbereichen eine wichtige Rolle. Denn es kann nicht erwartet werden, dass Nutzer eines Netzwerks die richtigen dem Netzwerk nicht schadenden Schritte und Aktivitäten durchführen, ohne eine Gegenleistung hierfür zu erlangen. Durch Incentivierung wird gewährleistet, dass die Teilnehmer sich erstens nicht bösartig verhalten und zweitens einen Anreiz haben, die Stabilität und Integrität des Netzes selbst herbeizuführen. Denn erst durch den Konsens-Mechanismus, der stark auf einer Incentivierung z. B. der Miner in Form von Bezahlung setzt, wird die Integrität des dezentralen Netzwerks gewährleistet. Eine Incentivierung muss nicht nur in der Bezahlung für eine Aktivität ausgestaltet sein, sondern könnte auch z. B. durch die Verwendung von Stake-basierten Konsens-Mechanismen herbeigeführt werden. Wang et al. [26] nutzt für die Belohnung der Partizipanten Kryptowährungen basierend auf öffentlichen Blockchains, um automatisierte Vergütungen an die Nutzer zu vergeben. Diese Vergütungen haben das Ziel, dass Nutzer über das sogenannte Crowd Sensing spezielle Daten mithilfe von Smartphones erheben und zur Verfügung stellen. Abgesehen von der Sicherheit und Motivation, die unterschiedlichen Komponenten der Blockchain-Technologie bereitzustellen, sind die Datenqualität und Datenquantiät ein wichtiger Faktor, da das Ergebnis maschineller Lernverfahren stark davon abhängt und die Datenaufbereitung eine sehr zeitaufwendige Aufgabe ist. Beides wird in der Arbeit von Wang et al. [26] verknüpft. Dazu sollen mithilfe eines Konsens-Algorithmus die Datenqualität und -quantität überprüft und dementsprechend vergütet werden. Die Vergütung stellt dabei auch eine Möglichkeit dar, Nutzer zu animieren, private Daten bereit zu stellen, die diese normalerweise nicht zur Verfügung stellen würden. Diese werden zwar anonymisiert, sind jedoch in diesem Beispiel von anderen Nutzern einsehbar. Firmen können die daraus akquirierten Daten dann für maschinelle Lernprozesse nutzen. Vergütungen beziehen sich jedoch nicht nur auf die Erhebung und Bereitstellung von Daten, sondern können umgekehrt dazu verwendet werden, Modelle und deren Dienste zu unterstützen. Da die Gewichtung solcher Dienste im medizinischen Bereich sehr stark auf die Qualität ausgerichtet ist, werden im Rahmen von Marathe et al. [15] Modelle anhand der Qualität ihrer Leistung über einen Anreizmechanismus implementiert und mittels der DLT vergütet. Auch hier spielt wieder das verteilte Lernen unter der Verwendung von privaten Daten eine zentrale Rolle. Der treibende Faktor stellt die sonst zentralisierte Form des maschinellen Lernens dar, welche aus Datenschutzgründen in der Regel nur beschränkte Zugriffsmöglichkeiten bei der Verwendung von privaten Daten besitzt. Mittels eines offenen Marktplatzes könnten Zugriffsregeln von den Eigentümern der Daten bestimmt und verfügbare Ressourcen optimal allokiert werden. Auf diesem Marktplatz können Datenhalter und Experten aus

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

151

dem Feld des maschinellen Lernens zusammenkommen und ihre Ressourcen bündeln. Auch hier stellt die Blockchain die nötige Basis, damit ein gegenseitiges Vertrauen entsteht. Dies geschieht über eine höchstmögliche Transparenz, Datensicherheit sowie Automatisierung mithilfe von klar definierten und offenen Smart Contracts. Zudem soll ein Wettbewerbselement, welches nur die qualitativ hochwertigsten Modelle vergütet, zu einem gesunden Wettstreit beitragen. Auch hier findet die Vergütung auf Basis der zuvor definierten Verträge vollautomatisiert über die Blockchain statt. In allen hier betrachteten Arbeiten spielt die Ausgestaltung einer Incentivierung der Teilnehmer eine wesentliche Rolle. Denn abgesehen von den Vorteilen, welche die Gruppe in ihrer Gesamtheit durch die Bündelung ihrer Ressourcen erhält, stellt sich dem Individuum die Frage, inwiefern seine Leistung honoriert wird, damit er bereit ist, an dem Netzwerk im Form des Betriebes eines Knotens oder in der Bereitstellung der Daten teilzuhaben.

4.3.4

Datenplattform

Ein sehr viel allgemeinerer Anwendungsfall findet sich im Einsatz der Blockchain als generelle Datenplattform. Aufgrund der dezentralen verteilten Speicherung des gesamten Transaktionslogs, bietet es sich an, darüber nachzudenken, dieses unveränderbare Log als Basis für den Austausch von Metadaten über die eigentlichen Daten, die wiederum lokal oder im IPFS liegen, zu nutzen. Solche Datenplattformen spielen dann wiederum für das maschinelle Lernen eine wichtige Rolle. Gerade in Branchen, in welchen der Zugriff auf die lokal gespeicherten Daten bzw. die Bereitstellung dieser Daten für Dritte schwierig ist, könnten solche Plattformen eine Lösung darstellen. Eine erste prototypische Umsetzung und Evaluierung dieses Prinzips im medizinischen Umfeld wurde von Wang et al. [27] umgesetzt. Auch hier war der Wunsch, die dezentral verfügbaren Daten durch Lernalgorithmen auszuwerten, um somit genauere Diagnosen erzeugen zu können. Dabei hat er fünf Argumente vorgebracht, welche die Verarbeitung bis dato erschwert haben: • • • • •

Fehlende Austauschmechanismen Mangelnde Sicherheit und Schutz der Privatsphäre Mangelnde Datenintegrität Dateneigentum Hohe Kosten für die zentrale Datenspeicherung

Diese Auflistung spiegelt wieder, weshalb die Blockchain-Technologie in Kombination mit einer dezentralen Datenspeicherung in all diesen Punkten eine mögliche Grundlage für die weitere Verarbeitung von Daten bietet mit Ausnahme des letzten Punktes. Wang et al. [27] nutzt in diesem Beispiel die Blockchain-Technologie als ein Medium zur Authentifizierung sowie zur Datenzugriffssteuerung. Er schafft damit eine zentrale, überwachte

152

J.Tagliaferri

Dattenplattform die zudem Verarbeitungs- und Analysedienste anbietet. Jeder Zugriff sowie die Nutzung der unterschiedlichen Ebenen wird dabei parallel auf der Blockchain protokolliert und gesteuert, damit die zuvor genannten Sicherheitsaspekte eingehalten werden. Einen ähnlichen Weg wählen Juneja und Marefat [9], um mithilfe der Blockchain einen gesicherten Zugang zu Patientenakten zu schaffen. Die Datenhoheit des Patienten steht in dieser Ausarbeitung im Vordergrund. Dafür werden Patientendaten lokal abgelegt und sind nur über Verweise auf die eigentlichen Daten erreichbar, die transparent und unveränderbar innerhalb der Blockchain gespeichert sind. Der Patient hat mittels Smart Contracts die Möglichkeit, bestimmten Institutionen den Zugriff auf bestimmte Daten zu gewährleisten. Die Blockchain dient dabei als Authentifizierungssystem, welches die Identifizierung und Zugangsberechtigung überprüft. Wie auch bei Wang et al. [27] kommt das maschinelle Lernen erst nach dem Zugriff auf die Daten zur Anwendung. Die Blockchain schafft somit zunächst die Infrastruktur des gesicherten Datenaustauschs mit gleichzeitiger dezentraler Kontrolle über die Datenhoheit ohne zentrale Instanz. In bestimmten Szenarien ist es jedoch nicht praktikabel oder möglich, direkt an die vorhandenen Daten zu gelangen. In solchen Fällen wird dann versucht, die Lernalgorithmen zu den Daten zu befördern. Gerade beim Internet der Dinge (IoT) ist es oft schwierig, flächendeckend Daten zentral zu speichern und zu aggregieren, um diese auszuwerten. Eine Hürde hier ist vor allem die Zeit, die hierfür nötig ist, da oft die Informationen aus den Devices schon nicht mehr relevant sind, wenn diese zunächst zusammengetragen und dann erst ausgewertet werden. Deshalb besteht der Wunsch, diese Daten direkt auf den erzeugenden Geräten zu analysieren. Trotzdem muss die Datensicherheit der einzelnen Geräte gewährleistet sein. In solch einem Fall bieten sich zwei Lösungsstrategien an. Besitzen die Endgeräte, welche Daten erzeugen, genügend Rechenleistung, ist ein Einsatz von verteilten Lernmethoden, wie z. B. föderiertes Lernen, sinnvoll. Ist dies nicht möglich, zeigt Shent et al. [22] wie mithilfe homomorpher Verschlüsselung in einer IoT Umgebung auf Basis verteilter verschlüsselter Daten Algorithmus angelernt werden kann. Abgesehen von der Nutzung und dem Zugriff auf bestimmte Daten, besteht im betrieblichen Kontext ein erhebliches Interesse an der Vermarktung und dem Verkauf von Daten. Damit dies möglich wird, nutzt Ozyilmaz et al. [17] ein Netz an ineinander greifender Technologien, wie Ethereum als Kryptowährung und Swarm2 als Datenspeicher, um solch einen Marktplatz zu erzeugen. Auch Privatpersonen können durch den Einsatz eines Smartphones ähnliche Vorteile durch den Zusammenschluss von Daten erhalten. Dazu stellt Wang et al. [26] eine Plattform vor, welche automatisiert gewünschte Daten abruft. Dies kann z. B. über eine App geschehen, welche Daten aggregiert und durch eine gebündelte Analyse aller Nutzer wichtige Informationen bereitstellt. Ein Beispiel dafür wäre die Bereitstellung von Echtzeit-Verkehrsinformationen, wie sie z. B. innerhalb von Google Maps zur Verfügung stehen. Die gesammelten Daten werden daraufhin an das Blockchain-Netzwerk übermittelt, wo Miner anhand eines angepassten Konsens-Algorithmus die Datenqualität überprüfen. Ist diese zufriedenstellend, werden die Daten als Block hinterlegt und die jeweiligen Nutzer 2 Swarm gehört zu der Gruppe der dezentral verteilten Storagelösungen, wie IPFS.

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

153

mithilfe einer Kryptowährung vergütet. Die allgemeine Verfügbarkeit dieser Daten würde es unterschiedlichsten Anbietern erlauben, ihre Dienstleistungen zu erweitern oder völlig neue Anwendungsbereiche zu schaffen.

4.3.5

Anwendungsformen

Durch die Verknüpfung von Eigenschaften der Blockchain Technologie als Grundbaustein sowie Anwendungen aus dem maschinellen Lernen finden sich im Folgenden völlig neue Anwendungsformen. Hierbei liegt der Fokus nicht mehr darauf, inwieweit die Technologien einander unterstützen, sondern eher, wie sie gleichberechtigt integriert werden können Dementsprechend finden sich in den betrachteten Arbeiten wiederholt Ideen, die schon zuvor betrachtet wurden. Diese stechen jedoch durch ihre kreative Kombination oder Weiterentwicklung hervor. Dinh und Thai [5] zeigen auf theoretischer Basis einige Beispiele für erste Einsatzmöglichkeiten der Kombination der zwei Technologien: • • • •

Sichere Marktplätze für den Austausch von Daten und ML-Modellen Verteiltes Lernen von ML-Modellen Nachvollziehbarkeit künstlicher Intelligenz Koordinierter Einsatz von unsicheren Geräten

Dabei steht innerhalb dieser Ausarbeitung die Frage im Raum, wie spezielle Eigenschaften dieser zwei Technologien genutzt werden können, um Herausforderungen und offene Probleme der jeweils anderen Technologie zu lösen. Der Bereich des verteilten Lernens von Modellen wird dabei von Weng et al. [28] betrachtet und gelöst, indem Teilmodelle dezentral erzeugt und diese über Smart Contracts wieder zu einem ganzheitlichen Modell zusammengeführt werden. Dies stellt eine stärker automatisierte und transparente Form des Lernprozesses dar. Dieser Prozess durchläuft mehrere Iterationen, in welchen jedes Mal das aktualisierte Modell an die einzelnen Teilnehmer verteilt und diese das neue Modell auf ihren eigenen Datensätze anwenden. In Kombination mit der Verschlüsselung der Teilmodelle gelingt es, ein funktionierendes und sicheres Framework zu entwickeln. Ein Bereich, in welchem ein solcher Grad an Sicherheit benötigt wird und Daten stark verteilt vorliegen, findet sich im medizinischen Sektor, da gerade hier die Datensicherheit und das Wahren von Identitäten eine große Rolle spielen. Durch die Kombination von Blockchain und maschinellem Lernen erhofft man sich, diesen überregulierten Bereich zugänglich zu machen. Eine Auswertung von Patientendaten und die damit einhergehende Möglichkeit, neue Diagnosefelder durch den Einsatz von maschinellem Lernen zu entwickeln, zeigen Prototypen, wie in der Arbeit von Avdoshin und Pesotskaya [1] dargestellt. Zudem zeigen Kuo und Ohno-Machado [10] ein verteiltes Lernsystem, welches Konsortien ermöglicht, unterschiedliche Modelle gleichzeitig zu entwickeln. Dazu werden über

154

J.Tagliaferri

Smart Contracts auf Basis von Evaluierungswerten passende neue Datensätze zugewiesen, von welchen sich die stärkste Verbesserung des Models erhofft wird. Dies geschieht dadurch, dass nach einer bestimmten Iterationsanzahl die Modelle auf den Testdaten aller anderen Modelle überprüft werden. Es wird davon ausgegangen, dass der Datensatz, bei welchem das Modell die höchste Fehlerrate erzielt, somit auch das größte Potenzial zur Verbesserung des Modells besitzt. Nachdem somit jedem Modell ein neuer Datensatz zugewiesen wurde, beginnt der Lernprozess erneut. Diese Verteilung findet so lange statt, bis eine zuvor definierte Fehlerrate unterschritten wird. Durch diese intelligente und anonyme Verteilung der Daten soll die Fehlerquote verringert und schlussendlich das beste Modell ermittelt werden. Damit die Skepsis gegenüber neuen Technologien in diesem Feld genommen wird, stehen auch neue Konzepte zur Regulierung und der sicheren Zusammenarbeit mit künstlicher Intelligenz im Vordergrund. Dabei dient die Blockchain als dezentraler Daten- und Schlüsselhalter, um Missbrauch oder unerwünschte Verhaltensweisen künstlicher Intelligenz zu stoppen [6]. Dies zeigt sich z. B. bei Avdoshin und Pesotskaya [1], welcher ein intelligentes Netzwerk für medizinische Daten erzeugen möchte. Im Unterschied zu den bisher dargestellten Beispielen stellen die Autoren eine sehr starke Verzahnung zwischen der Bereitstellung von Daten innerhalb eines verteilten Hauptbuches und den Analysen auf Basis von maschinelle Lernen dar. Es bringt dadurch zum ersten Mal Ressourcen, Menschen und Algorithmen zusammen, welche zuvor keine Möglichkeit hatten, ein gemeinsames Ziel zu verfolgen. Gerade diese Verknüpfung stellt einen wesentlichen Bestandteil der Kombination der Blockchain-Technologie und des maschinellen Lernens dar. Ein weiteres Beispiel für solch eine Zusammenarbeit zeigt Qiu et al. [18] anhand einer Flotte von Automobilen. Die Vernetzung der einzelnen Fahrzeuge eröffnet zwar eine Reihe von neuen Möglichkeiten, die jedoch auf eine Konsensfindung zwischen den Fahrzeugen angewiesen ist. Momentane Blockchain Lösungen besitzen in solch einem Einsatzfeld jedoch einen zu geringen Durchsatz. Dieser Durchsatz entsteht durch die permanente Kommunikation aller Fahrzeuge untereinander, was zwar zu einem robusten und sicheren Netz führt, die Konsensfindung jedoch behindert. Hier kommt das maschinelle Lernen ins Spiel, welches dazu eingesetzt wird, die Auslastung des Netzes zu steuern und Ressourcen optimal zu verteilen, damit der Durchsatz erhöht werden kann. Solche automatisierten Dienste sind auch für kleine und mittelständische Unternehmen von enormen Wert, welche nicht in der Lage sind, die nötigen Ressourcen zu beschaffen. In diesem Kontext hat Li et al. [12] ein Konzept für eine automatisierte KundenservicePlattform entwickelt. Dies ist insoweit relevant, da sich der traditionelle Kundenservice immer weiter von der manuellen Bearbeitung in Richtung automatisierte Dienste entwickelt. Damit solche Dienste möglich werden, sind jedoch enorme Datenmengen und Expertise von Nöten. Um diese Problematik zu lösen nutzt, Li et al. die Blockchain als sichere Datenplattform, in welcher kleine und mittelständische Unternehmen ihre Daten bündeln können. Diese Plattform ist zusätzlich mit einem sogenannten AutoML Framework verbunden, welche eine vereinfachte Erstellung von Modellen erlaubt. Unter AutoML ist eine

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

155

beschreibende Sprache für die Implementierung von automatisierten Prozesse des maschinelle Lernens zu verstehen. Im nächsten Kapitel wird diese Plattform unter Berücksichtigung eines generischen Frameworks nächer beschrieben. Um die Komplexität und den Aufwand für Beteiligte zu verringern, streben viele Arbeiten solch eine Demokratisierung von Daten und Algorithmen an. Dabei sind dezentrale Marktplätze von Nöten, welche zum einen Daten und Modelle bereitstellen und zum anderen diese entwickeln [11]. Wang [25] betrachtet hierbei auf theoretischer Basis Möglichkeiten einer höchstmöglichen Automatisierung. Herausforderungen in diesem Zusammenhang stellen die Privatsphäre von Nutzern, das inkrementelle Erlernen von Modellen und die Limitierung der Blockchain im Bereich von schnellen und umfangreichen Datenströmen dar. Im Internet of Things werden diese Herausforderungen gelöst, indem Transaktionen über die Blockchain ausgeführt, große mediale Daten jedoch sicher und unveränderbar außerhalb der Blockchain aufbewahrt werden. Das Ziel des daraus entstandenen Frameworks ist die direkte Analyse der Daten am Entstehungsort. Diese Kombination aus Blockchain und maschinellem Lernen soll zukünftig als Teilgrundlage von sogenannten intelligenten Städten genutzt werden [19]. Unterstützend zeigt Vo et al. [24] einen Federated-LearningAnsatz, welcher es zudem erlaubt, aus vielen Teilmodellen ein passendes Gesamtmodell zu erstellen. Dabei können Edge-Geräte, kleine leistungsfähige Einplatinenrechner, wie sie im IoT Umfeld oft verwendet werden, oder Smartphones eingesetzt werden, um solche Teilmodelle zu entwickeln. Die Blockchain sorgt hierbei für die Integrität und Datenqualität und mündet somit erneut in einem Design eines Marktplatzes für große Datenmengen und Modelle aus dem Bereich des maschinellen Lernens. Das Design des vorgestellten Marktplatzes wird fortan von Hynes et al. [8] aufgegriffen und anhand eines Prototyps umgesetzt. Dabei wird sich der Herausforderung gewidmet, wie es in solch einem dezentralen Umfeld möglich ist, Modelle zu erzeugen. Dabei werden über sogenannte Machine-Learning-Pipelines, die eine Abfolge von auszuführenden Regeln und Befehle darstellen, die Datensicherheit und die Integrität der Modelle garantiert. Eine weitere prototypische Umsetzung, welche sich auf die eines solchen Marktplatzes unterliegende Idee fokussiert, findet sich im System Learning-Chain. Hierbei wurden die Sicherheits- und Identitätsherausforderungen näher betrachtet, um effizient Modelle zu entwickeln. Dieses Framework kann sich zudem effektiv gegen byzantinische Angriffe wehren [3]. Zusammenfassend zeigen Lopes und Alexandre [13] in ihrer Literaturanalyse, wie die Kombination von Blockchain und maschinellem Lernen und der Robotik im wissenschaftlichen Umfeld aufgenommen und umgesetzt wird. In dieser Arbeit wird die Thematik der Robotik vorangestellt, mit dem Ziel, die Blockchain als Lösungsmechanismus für Datensicherheits- und Kollaborationsprobleme zu etablieren. Die Autoren zeigen auf, wie sich Robotersysteme unter der Verwendung von Smart Contracts durch eine eingebettete Blockchain steuern lassen. Entscheidend für Lopes et al. ist vor allem die Fähigkeit eines solchen Steuerungssystem flexibel auf neue Gegebenheiten reagieren zu können.

156

J.Tagliaferri

Umgesetzt wurde dies durch eine Verknüpfung unterschiedlichster Smart Contracts. Neben dem maschinellen Lernen, das für die Robotik verwendet wurde, erfüllt die Blockchain in diesem Szenario mehrere wesentlichen Aufgaben und stellt neben der Verteilung der Informationen auch sicher, dass keine Manipulationen oder unbeabsichtigte Änderungen vorgenommen werden können.

4.4

Anwendungsfälle

4.4.1

Einleitung

Damit es zu einem besseren und greifbareren Verständnis der Anwendungsfälle kommt, soll im Folgenden auf drei Konzepte eingegangen werden, welche zukünftig relevant werden können. Die aufgeführten Beispiele sind aus den Bereichen des Gesundheits-, Energie- und Agrarsektors von Salah et al. [20].

4.4.2

Anwendung 1

In den vorherigen Arbeiten wurde öfters auf die schwierige Datenlage innerhalb des Gesundheitswesens hingewiesen. Die Erhebung und Verarbeitung von Daten unterliegt dabei strengen Richtlinien und Datenschutzbestimmungen. In diesem Fall stellt Salah et al. [20] eine umfassende Architektur vor, welche diese Problematik addressiert. Diese setzt sich aus Technologien wie Blockchain, IPFS, Kryptowährungen, und maschinellem Lernen zusammen um verschiedenste Akteure zu verknüpfen. Wie in Abb. 4.1 zu sehen, bildet die Blockchain sowie Dienste des maschinellen Lernens den Grundbaustein des Netzes. Alle Rollen innerhalb des Netzes tragen dafür einen gewissen Teil bei und erhoffen sich im Umkehrschluss passende Informationen. So beginnt alles damit, dass Patienten und Ärzte sowie Therapeuten Daten über den gesundheitlichen Zustand sammeln und an die Blockchain weiterleiten. Diese können dabei in völlig unterschiedlichen Formen vorliegen. Beispiele für solche Daten wären: Krankenakten, Diagnosen, Sensordaten von Wearables sowie Röntgenbilder. In diesem Fall, werden Mediendaten lokal via IPFS abgelegt und sind über einen IPFS-Hash zugänglich. Die Verarbeitung der Daten findet entweder über integrierte Smart Contracts oder Algorithmen des maschinellen Lernens statt. Ein Beispiel für solch eine Verarbeitung ist die Analyse von Röntgenaufnahmen, welche ein Radiologe über die Blockchain bereitstellt und dafür eine Auswertung der Bilder auf Anomalien erhält. Die spezifische Anforderungen an eine Auswertung sind dabei an die unterschiedlichen Nutzer gebunden. Ein Patient kann wahrscheinlich keine nützlichen Informationen aus einer Anomalieerkennung seiner Röntgenbilder ziehen, dafür aber Ratschläge umsetzen, welche auf Basis seines Fitness-Trackers entstehen. Weitere Nutzer sind z. B. Pharmakonzerne und Wissenschaftler, welche die Informationen auswerten um

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

157

Abb. 4.1 Kollektive Intelligenz für das dezentrale Gesunsheitswesen in Anlehnung an [20]

neue Behandlungsmethoden zu entwickeln. Da der Patient Inhaber all dieser Daten ist, kann es neben den offensichtlichen Vorteilen im Zuge einer Krankheit, noch weitere Motivationsmechanismen geben. So können z. B. Vergütungen in Form von Kryptowährungen an Patienten ausgegeben werden, damit eine Verarbeitung stattfinden kann.

4.4.3

Anwendung 2

Übertragen auf den Energiesektor beschreibt Salah et al. [20] ein Konzept zur Modernisierung und Automatisierung der Infrastrukturkomponenten. Diese haben sich mit dem Wandel hin zu erneuerbaren Energien sowie dem massiven Einsatz von Sensoren und IoT Geräten stark verändert. So setzt sich der Energiemarkt aus sehr vielen unterschiedlichen

158

J.Tagliaferri

Energiequellen, Sensoren und Verbrauchern zusammen. Durch die starken Schwankungen bei der Energiegewinnung aus erneuerbaren Energien steht die Verwaltung vor neuen Herausforderungen in Bezug auf Verteilung und Planung der Ressourcen. So besteht der Wunsch Zugriff auf die unterschiedlichen Informationsquellen zu erhalten um somit eine effizientere Steuerung und Analyse zu ermöglichen. Damit dies möglich wird, sitzt die Blockchain erneut im Zentrum, um Daten verteilt, transparent und sicher zu verwalten. Die darin enthaltenen Daten werden von unterschiedlichen Systemen genutzt, um wiederum die Energie-Infrastruktur zu unterstützen. Dies geschieht zum einen von analytischen Systemen, die Sensordaten auswerten und somit wichtige Informationen für die Verwaltungsorgane bereitstellen, sogenannte Expertensysteme. Solche Expertensysteme haben die Aufgabe Personen bei ihrer Arbeit mit wichtigen Informationen zu versorgen und auf mögliche Abweichungen innerhalb der Daten hinzuweisen. Dazu werden heutzutage vermehrt maschinelle Lernalgorithmen verwendet, welche auf einen zunehmenden Datenstrom angewiesen sind. Ein weiteres Feld welches sich in der Abb. 4.2 wiederfindet und eine starke Verzahnung mit dem maschinellen Lernen aufweist, ist die Robotik. Wo die Expertensysteme die vorliegenden Daten nutzen um Informationen zu extrahieren, werden diese innerhalb der Robotik verwendet um tatsächliche Aktionen durchzuführen und somit Systeme zu kontrollieren. Neben der sicheren und transparenten Ablage von Daten kann die Blockchain innerhalb des Energiesektors zudem als automatisierte Auktionsplattform dienen. Da die Energiepreise ständig neu verhandelt werden, kann ein Wahlsystem, verbunden mit Smart Contracts die Preise definieren und eine Verteilung automatisiert vornehmen.

Abb. 4.2 Zukünftige Energiewirtschaft unter Nutzung der Fähigkeiten von Blockchain und KI in Anlehnung an [20]

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

4.4.4

159

Anwendung 3

Der Agrarsektor ist ein weiterer Sektor, der von der Digitalisierung sowie der engeren Zusammenarbeit unterschiedlicher Akteure profitieren kann. Somit sieht Salah et al. [20] in seiner Ausarbeitung die Vorteile und Einsparungen einer derartigen Verknüpfung. Wie schon in den zuvor genannten Anwendungen entsteht auch innerhalb des Agrarsektors ein erhöhter Kommunikations- und Verwaltungsaufwand durch den Einsatz von Datenlieferanten in Form von Sensoren und IoT-Geräten. Vorteile können aus diesen Daten jedoch nur entstehen, wenn diese auch sinnvoll von den Beteiligten genutzt werden können. Erneut steht wie in Abb. 4.3 zu sehen die Blockchain als verteilte Datenbank im Zentrum aller Aktionen. Der Prozesszyklus beginnt bei diesem Beispiel in der Überwachung der Pflanzen durch Sensoren. Diese überwachen, Temperatur, Luftfeuchte, Druck, Mineralgehalt und weitere Indikatoren die zum Pflanzenwachstum beitragen. Sind diese in der Blockchain abgelegt kann der Agrarwirt durch den Einsatz von maschinellen Lernen auf Informationen zurückgreifen, die z. B. den Ertrag oder das allgemeine Wachstum vorhersagen. Zudem können hierdurch Gegenmaßnahmen getroffen werden um möglichen Missständen entgegen zu wirken. Auf der Kundenseite sind diese Informationen wiederum in Bezug auf Verfügbarkeit, Qualität und Preis der Produkte relevant. Somit können sich die Märkte schon frühzeitig auf die allgemeine Entwicklungslage einstellen. Damit einhergehend ist auch die Qualitätskontrolle mit inbegriffen. Durch eine automatisierte Erhebung, klare Identifikation der Güter und die Möglichkeit für den Kunden die für ihn relevanten Informationen einzusehen, kann von einem sicheren Produkt ausgegangen werden. Gerade solch automatisierten Identifikationsmöglichkeiten sind nach Salah et al. [20] wiederum innerhalb der Logistik verwendbar, da eine vollständige Nachverfolgung der Güter möglich wird. So können sich die einzelnen Logistikanbieter schon zuvor auf eintreffende Güter vorbereiten und aufwendige nicht standardisierte Prozesse entfallen. Damit wird im Allgemeinen der komplette Prozess vom Feld bis zum Endkunden, transparent, standardisiert, sicher und vor allem einfacher.

Abb. 4.3 Intelligente Landwirtschaft auf Basis der Blockchain in Anlehnung an [20]

160

4.5

J.Tagliaferri

Zusammenfassung

Alle die in der Literatur gefundenen Themen finden sich nun innerhalb der in Abb. 4.4 zu sehenden Konzeptmatrix wieder. Je stärker die Themen vertreten sind, je länger ist der zugrunde liegende Farbbalken. Es ist ersichtlich, dass das Thema Datensicherheit fest mit der Blockchain verbunden ist. Aber auch in einigen Artikeln werden die unterschiedlichen Anwendungsformen aufgegriffen. Dabei werden vereinzelt ML-Plattformen, automatisierte Dienste und der ML-Marktplatz genannt. Viel mehr sind aber Themen der Analyse und des Lernprozesses in den analysierten Artikeln in Kombination mit der Blockchain verarbeitet worden. Neben der Darstellung der Charakteristika sind in Tab. 4.1 die verwendete Literatur und deren Behandlung der einzelnen Charakteristika in Kombination dargestellt. Eine verstärkte Publikation und damit Interesse in der Verknüpfung beider Domänen findet erst seit Beginn 2018 statt. Dies ist nicht verwunderlich, da es sich aufseiten der Blockchain um eine neue Technologie handelt, die an vielen Stellen noch in der Entwicklungsphase ist. Es zeigt sich aber auch, dass die betrachteten Arbeiten einen unterschiedlich starken Fokus auf das jeweilige Charakteristikum haben. So finden sich unter den Arbeiten, die sich vorrangig mit der Blockchain und deren Weiterentwicklung beschäftigen, etliche wissenschaftliche Beiträge, die auch einen Bezug zum maschinellen Lernen herstellen. Diese Arbeiten bewegen sich dabei in Bezug auf das maschinelle Lernen in zwei unterschiedliche Richtungen. Zum einen zeigt sich die Unterstützung im Bereich des maschinellen Lernprozesses und zum anderen in der Regulierung und Verteilung maschineller Dienste. Bei den Anwendungsformen kommt es schließlich zu einer stärkeren Verschmelzung der beiden Technologien, die durch die einzigartige Kombination mehrerer Eigenschaften und Funktionen zu neuen Anwendungsformen gelangen. Eine dominierende Seite kann dabei

Abb. 4.4 Vertretung der Charateristika in der Literatur

Referenz

(Avdoshin und Pesotskaya 2019)

(Bogner 2017)

(Chen et al. 2018)

(Dinh und Thai 2018)

(Dronic 2019)

(Harlev et al. 2018)

(Hynes et al. 2018)

(Juneja und Marefat 2018)

(Kuo und OhnoMachado 2018)

(Kurtulmus und Daniel 2018)

(Li et al. 2019)

(Lopes und Alexandre 2018)

Nr.

[1]

[2]

[3]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

DatenSmart sicherheit Contract

Blockchain

X

X

X

X

X

Incentive

Eigenschaften und Funktionen

Tab. 4.1 Konzeptmatrix

X

X

X

X

X

X

X

Konsens

X

X

X

X

X

X

Datenplattform

X

X

X

X

X

X

X

X

Analyse

X

X

X

X

X

X

X

Lernprozess

Machine Learning

X

X

X

X

X

X

Dienste MLPlattform

X

X

Automatisierte Dienste

Anwendungs-formen

X

X

X

X

X

MLVerteiltes Marktplatz lernen

(Forsetzung)

X

X

X

Theoretische Ausarbeitung

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick 161

Referenz

(Lu et al. 2018)

(Marathe et al. 2018)

(Marwala und Xing 2018)

(Ozyilmaz et al. 2018)

(Qiu et al. 2018)

(Rahman et al. 2019)

(Salah et al. 2019)

(Shae und Tsai 2018)

(Shen et al. 2019)

Nr.

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

Tab. 4.1 Forsetzung

X

X

X

X

X

X

X

X

X

X

X

X

X

X

DatenSmart sicherheit Contract

Blockchain

X

X

X

X

X

Incentive

Eigenschaften und Funktionen

X

X

X

X

X

Konsens

X

X

X

X

X

Datenplattform

X

X

X

X

X

Analyse

X

X

X

X

X

Lernprozess

Machine Learning

X

X

X

X

Dienste MLPlattform

X

X

Automatisierte Dienste

Anwendungs-formen

X

X

X

MLVerteiltes Marktplatz lernen

(Forsetzung)

X

X

Theoretische Ausarbeitung

162 J.Tagliaferri

Referenz

(Vo et al. 2018)

(Wang et al. 2018)

(Wang 2018)

(Weng et al. 2015)

(Yaji et al. 2018)

(Zhu et al. 2019)

Nr.

[24]

[26]

[27]

[28]

[29]

[30]

Tab. 4.1 Forsetzung

X

X

X

X

X

X

X

X

X

X

X

DatenSmart sicherheit Contract

Blockchain

X

Incentive

Eigenschaften und Funktionen

X

X

X

X

X

Konsens

X

X

Datenplattform

X

X

X

Analyse

X

X

X

X

Lernprozess

Machine Learning

X

Dienste MLPlattform

X

Automatisierte Dienste

Anwendungs-formen

X

X

X

X

MLVerteiltes Marktplatz lernen

X

Theoretische Ausarbeitung

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick 163

164

J.Tagliaferri

nicht mehr benannt werden. Vollumfänglich versuchen die Beiträge von Avdoshin et al. [1], Dinh et al. [5], Li et al. [12], Lopes et al. [13] und Salah et al. [20] die Integration von Blockchain und maschinellem Lernen darzustellen. In dem nachstehenden Kapitel werden die Anwendungsformen aufgegriffen und in Form einer generischen Darstellung eines Analytics-Marktplatzes kombiniert. Dieser Ordnungsrahmen stellt eine erste Möglichkeit dar, die unterschiedlichen Ansätze zu klassifizieren und Gemeinsamkeiten aufzuzeigen.

Literatur 1. Avdoshin, S., Pesotskaya, E.: Blockchain revolution in the healthcare industry. In: Advances in Intelligent Systems and Computing, Bd. 880, S. 626–639. Springer International Publishing, Cham (2019). https://doi.org/10.1007/978-3-030-02686-8_47 2. Bogner, A.: Seeing is understanding – Anomaly detection in blockchains with visualized features. In: Proceedings of the 2017 ACM International Joint Conference on Pervasive and Ubiquitous Computing and Proceedings of the 2017 ACM International Symposium on Wearable Computers on – UbiComp 2017, S. 5–8. ACM Press, New York (2017). https://doi.org/10.1145/3123024. 3123157 3. Chen, X., Ji, J., Luo, C., Liao, W., Li, P.: When machine learning meets blockchain: a decentralized, privacy-preserving and secure design. In: 2018 IEEE International Conference on Big Data (Big Data), S. 1178–1187. IEEE (2018). https://doi.org/10.1109/BigData.2018.8622598 4. Corea, F.: The convergence of AI and Blockchain: What’s the deal? (2017). https://medium.com/ @Francesco_AI/the-convergence-of-ai-and-blockchain-whats-the-deal-60c618e3accc. Zugegriffen: 23. Juli 2019 5. Dinh, T.N., Thai, M.T.: AI and Blockchain: a disruptive integration. Computer 51(9), 48–53 (2018). https://doi.org/10.1109/MC.2018.3620971 6. Dronic, I.: A path to artificial intelligence. Adv. Intell. Syst. Comput. 869, 658–668 (2019). https://doi.org/10.1007/978-3-030-01057-7_50 7. Harlev, M.A., Sun Yin, H., Langenheldt, K.C., Mukkamala, R.R., Vatrapu, R.: Breaking bad: de-anonymising entity types on the bitcoin blockchain using supervised machine learning. In: Proceedings of the 51st Hawaii International Conference on System Sciences, Bd. 9, S. 3497– 3506 (2018). https://doi.org/10.24251/hicss.2018.443 8. Hynes, N., Dao, D., Yan, D., Cheng, R., Song, D.: A demonstration of sterling: a privacypreserving data marketplace. Proc. VLDB Endowment 11(12), 2086–2089 (2018). https://doi. org/10.14778/3229863.3236266 9. Juneja, A., Marefat, M.: Leveraging blockchain for retraining deep learning architecture in patient-specific arrhythmia classification. In: 2018 IEEE EMBS International Conference on Biomedical & Health Informatics (BHI), March, S. 393–397. IEEE (2018). https://doi.org/10. 1109/BHI.2018.8333451 10. Kuo, T.T., Ohno-Machado, L.: ModelChain: decentralized privacy-preserving healthcare predictive modeling framework on private blockchain networks, S. 517–522 (2018) 11. Kurtulmus, A.B., Daniel, K.: Trustless machine learning contracts; evaluating and exchanging machine learning models on the ethereum blockchain (2018) 12. Li, Z., Guo, H., Wang, W., Guan, Y., Barenji, A.V., Huang, G.Q., McFall, K.S., Chen, X.: A Blockchain and AutoML approach for open and automated customer service. IEEE Trans. Ind. Inform. PP(c), 1–1 (2019). https://doi.org/10.1109/TII.2019.2900987

4 Blockchain und maschinelles Lernen – Ein Literaturüberblick

165

13. Lopes, V., Alexandre, L.A.: An Overview of Blockchain Integration with Robotics and Artificial Intelligence (2018) 14. Lu, Y., Tang, Q., Wang, G.: On enabling machine learning tasks atop public blockchains: a crowdsourcing approach. In: 2018 IEEE International Conference on Data Mining Workshops (ICDMW), S. 81–88. IEEE (2018). https://doi.org/10.1109/ICDMW.2018.00019 15. Marathe, A., Narayanan, K., Gupta, A., Manoj, P.: DInEMMo: Decentralized Incentivization for Enterprise Marketplace Models. In: 2018 IEEE 25th International Conference on High Performance Computing Workshops (HiPCW), S. 95–100 (2018). https://doi.org/10.1109/HiPCW. 2018.00023 16. Marwala, T., Xing, B.: Blockchain and Artificial Intelligence, S. 302 (2018) 17. Ozyilmaz, K.R., Dogan, M., Yurdakul, A.: IDMoB: IoT data marketplace on blockchain. In: 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), S. 11–19. IEEE (2018). https://doi.org/10.1109/CVCBT.2018.00007 18. Qiu, C., Yu, F.R., Xu, F., Yao, H., Zhao, C.: Blockchain-based distributed software-defined vehicular networks via deep q-learning. In: Proceedings of the 8th ACM Symposium on Design and Analysis of Intelligent Vehicular Networks and Applications – DIVANet 2018, S. 8–14. ACM Press, New York (2018). https://doi.org/10.1145/3272036.3272040 19. Rahman, M.A., Rashid, M.M., Hossain, M.S., Hassanain, E., Alhamid, M.F., Guizani, M.: Blockchain and IoT-based cognitive edge framework for sharing economy services in a smart city. IEEE Access 7, 18611–18621 (2019). https://doi.org/10.1109/ACCESS.2019.2896065 20. Salah, K., Rehman, M.H.U., Nizamuddin, N., Al-Fuqaha, A.: Blockchain for AI: review and open research challenges. IEEE Access 7, 10127–10149 (2019). https://doi.org/10.1109/ACCESS. 2018.2890507 21. Shae, Z., Tsai, J.J.: Transform blockchain into distributed parallel computing architecture for precision medicine. In: 2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS), S. 1290–1299. IEEE (2018). https://doi.org/10.1109/ICDCS.2018.00129 22. Shen, M., Tang, X., Zhu, L., Du, X., Guizani, M.: Privacy-preserving support vector machine training over blockchain-based encrypted iot data in smart cities. IEEE Internet Things J. PP(c), 1 (2019). https://doi.org/10.1109/JIOT.2019.2901840 23. Vishwa, A., Hussain, F.K.: A Blockchain based approach for multimedia privacy protection and provenance. In: 2018 IEEE Symposium Series on Computational Intelligence (SSCI), S. 1941–1945 (2018) 24. Vo, H.T., Mohania, M., Verma, D., Mehedy, L.: Blockchain-powered big data analytics platform. In: Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), Bd. 11297. LNCS, S. 15–32. Springer International Publishing (2018). https://doi.org/10.1007/978-3-030-04780-1_2 25. Wang, T.: A unified analytical framework for trustable machine learning and automation running with blockchain. In: 2018 IEEE International Conference on Big Data (Big Data), S. 4974–4983. IEEE (2018). https://doi.org/10.1109/BigData.2018.8622262 26. Wang, J., Li, M., He, Y., Li, H., Xiao, K., Wang, C.: A blockchain based privacy-preserving incentive mechanism in crowdsensing applications. IEEE Access 6, 17545–17556 (2018). https:// doi.org/10.1109/ACCESS.2018.2805837 27. Wang, R., Tsai, W.T., He, J., Liu, C., Li, Q., Deng, E.: A medical data sharing platform based on permissioned blockchains. In: Proceedings of the 2018 International Conference on Blockchain Technology and Application – ICBTA 2018, S. 12–16. ACM Press, New York (2018). https:// doi.org/10.1145/3301403.3301406 28. Weng, J.S., Weng, J., Zhang, J., Li, M., Zhang, Y., Luo, W.: DeepChain: auditable and privacypreserving deep learning with blockchain-based incentive (2015)

166

J.Tagliaferri

29. Yaji, S., Bangera, K., Neelima, B.: Privacy preserving in blockchain based on partial homomorphic encryption system for AI applications. In: 2018 IEEE 25th International Conference on High Performance Computing Workshops (HiPCW), S. 81–85 (2018). https://doi.org/10.1109/ HiPCW.2018.00021 30. Zhu, X., Li, H., Yu, Y.: Blockchain-based privacy preserving deep learning, S. 370–383. Springer International Publishing (2019). https://doi.org/10.1007/978-3-030-14234-6_20

5

Der Analytics-Marktplatz Carsten Lanquillon und Sigurd Schacht

Zusammenfassung

Der Analytics-Marktplatz ist die natürliche Verbindung der beiden disruptiven Technologien Blockchain und maschinelles Lernen. Die Blockchain kann, insbesondere mit Blick auf Vertrauen in Daten und Modellen sowie Incentivierungen für den Einsatz von Ressourcen, die Infrastruktur für die Lösung einiger Herausforderungen bei der Automatisierung von Machine-Learning-Prozessen und bei der Gestaltung neuer Geschäftsmodelle zur Bereitstellung von Lösungen auf Basis des maschinellen Lernens bieten. Da die Anforderungen an die Kombination einerseits und an die Gestaltung von MachineLearning-Prozessen gerade unter Berücksichtigung der Datensicherheit und des Datenschutzes andererseits sehr vielfältig sind, wird es sehr unterschiedliche Ausprägungen bei der Umsetzung geeigneter Lösungen geben. Anhand eines Ordnungsrahmens werden die Herausforderungen für einen integrierten Analytics-Marktplatz dargestellt, bestehende Ansätze eingeordnet und zu erwartende Entwicklungen aufgezeigt.

5.1

Motivation

Entscheidungsunterstützende Systeme mit dem Bestreben, dass Organisationen ihre Entscheidungen stärker daten- und somit letztlich faktenbasiert treffen können, haben eine lange Historie wie in Abb. 5.1 dargestellt. Während noch die Business Intelligence das übergeordnete Ziel hatte, bestehende Insellösungen zu integrieren und mit einem zentralen Data C. Lanquillon (B) · S. Schacht Hochschule Heilbronn, Heilbronn, Deutschland E-Mail: [email protected] S. Schacht E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 S. Schacht und C. Lanquillon (Hrsg.), Blockchain und maschinelles Lernen, https://doi.org/10.1007/978-3-662-60408-3_5

167

168

C. Lanquillon und S. Schacht

Abb. 5.1 Die Evolution entscheidungsunterstützender Systeme in Anlehnung an Humm und Wietek [5] und ergänzt um Aspekte von Davenport [1]: Analytische Funktionalität wird immer stärker in Produkte und Dienstleistungen integriert werden

Warehouse eine konsolidierte Sicht auf alle relevanten Unternehmensdaten zu schaffen, ist mit dem Big-Data-Zeitalter die Verwendung eines größeren und breiteren Spektrums an Daten und komplexeren Analysen in den Vordergrund gerückt. Insbesondere durch das Web 2.0 mit seinen vielfältigen Nutzerbeiträgen (engl. usergenerated content) und das Internet der Dinge (engl. internet of things (IoT)) mit Kommunikationsdaten zwischen Geräten stehen Organisationen zusätzliche externe Datenquellen bereit. Und durch die digitale Transformation von Organisationen werden immer mehr Prozesse digitalisiert und es fallen stetig mehr Daten an aus internen Abläufen, über Kunden und deren Nutzung von Produkten und Dienstleistungen. Doch durch die bloße Existenz und möglicherweise Speicherung der Daten entsteht für eine Organisation noch kein Mehrwert. Erst durch die Analyse und die Umsetzung der Erkenntnisse aus den Daten bekommen die Daten einen Wert. Analysen und die Nutzung der Ergebnisse werden allgegenwärtig und betten sich zunehmend nahtlos in Prozesse, Produkte und Dienstleistungen. Aber auch neue Geschäftsmodelle entstehen im Kontext der Erkenntnisgewinnung aus Daten. Durch immer neue Innovationen haben sich im Laufe der Zeit die Marktführer und ihre Geschäftsmodelle kontinuierlich gewandelt, wie in Abb. 5.2 zu erkennen ist. Während standardisierte Hardware, Software und die Kommunikation über das Internet schon längst zum Allgemeingut zählen, gibt es jedoch nur wenige große IT-Unternehmen, wie zum Beispiel Google, Facebook und Twitter, die für viele Anwendungen relevante Nutzerdaten besitzen. Die Blockchain-Technologie hat das Potenzial dies zu ändern, sodass eine Bewegung hin zu öffentlich zugänglichen Daten erreicht werden kann, für deren Nutzung durch

5 Der Analytics-Marktplatz

169

Abb. 5.2 IT-Entwicklung in Anlehnung an Ehrsam [2]. Marktführer forcieren Standardisierungen. Durch Innovationen werden bestehende Technologien zum Allgemeingut und Geschäftsmodelle verändern sich. Eine Verschiebung Richtung Analytics basierend auf maschinellen Lernverfahren zeichnet sich ab

Organisationen die Dateneigner entsprechend entlohnt werden können. Letztlich werden sich die Geschäftsmodelle erneut verschieben, sodass anstelle der Daten die Algorithmen für deren Auswertung, also die maschinellen Lernverfahren, im Mittelpunkt stehen [2]. Für die Einbettung von Analysefunktionalität in bestehende oder neue Prozesse, Produkte und Dienstleistungen und auch für die Entwicklung und Umsetzung neuer Geschäftsmodelle werden Lösungen für Analyseaufgaben benötigt, die aufgrund ihrer großen Anzahl und zeitlichen Anforderungen hinsichtlich der Verfügbarkeit zunehmend automatisiert erstellt werden müssen. Die großen Internetkonzerne agieren gerne als „Daten-Krake“, besitzen inzwischen eine extrem breite Datenbasis und nutzen die daraus gezogenen Erkenntnisse äußerst gewinnbringend. Durch einen Analytics-Marktplatz auf Basis von Blockchain-Technologien kann eine Entmonopolisierung der Daten erreicht werden. Dies förderte die Entwicklung transparenter und effizienter maschineller Lernverfahren und Anwendungen.

5.2

Zielsetzung

Wenn eine Organisation eine Analyseaufgabe zur Lösung einer fachlichen Fragestellung definiert hat und diese mithilfe maschineller Lernverfahren lösen möchte, benötigt sie neben dem Zugriff auf relevante Daten insbesondere auch menschliche Ressourcen in Form von Machine-Learning-Experten (ML-Experten), auch als Data Scientists bekannt, für die Modellerstellung sowie technische Ressourcen in Form von Rechenleistung. Bei der traditionellen, wissenschaftlich geprägten Sicht auf das maschinelle Lernen wird davon ausgegangen, dass alle benötigen Ressourcen zentral verfügbar sind. Bei der praktischen Umsetzung in einer Organisation mangelt es jedoch häufig an mindestens einer dieser drei elementaren Ressourcen.

170

C. Lanquillon und S. Schacht

Dabei stellt sicherlich die fehlende ML-Expertise für viele Organisationen das größte Problem dar. Ohne diese Expertise lassen sich aus Daten keine Werte generieren. Häufig sind in einer Organisation zwar Daten verfügbar, werden aber nicht wirtschaftlich verwertet. Es gibt aktuell deutlich weniger ML-Experten, als in Organisationen für die Lösung von Analyseaufgaben benötigt werden. Zudem sind erfahrene Experten aufgrund der hohen Nachfrage meist sehr teuer. Gerade die großen Internetkonzerne wie Google, Amazon und Facebook haben die nötigen finanziellen Mittel, ihre Data-Science-Teams weiter zu vergrößern. Und wie oben bereits beschrieben haben sie außerdem Zugriff auf die notwendigen Daten, um in diesem Marktumfeld ihre dominierende Stellung zu festigen oder weiter auszubauen. Für kleine und mittlere Unternehmen (KMU) ist der Zugang zu diesem Markt dagegen ungleich problematischer. Daher können dort viele wichtige Machine-Learning-Vorhaben nicht durchgeführt werden und das große Potenzial verfügbarer Daten wird nicht vollumfänglich genutzt. Organisationen sind daher bestrebt, die fehlenden Ressourcen einzukaufen. Neben der Beauftragung von Beratungsleistungen über geeignete Beratungshäuser haben sich insbesondere isolierte ressourcenspezifische Marktplätze entwickelt wie in Abb. 5.3 dargestellt. Isolierte Marktplätze existieren vor allem bei den großen IT-Unternehmen oder fragmentiert bei vielen Spezialanbietern. So bieten beispielsweise Amazon, Microsoft und Google Rechenleistung über ihre Cloud-Dienste an. ML-Expertise kann über die unterschiedlichsten Freelancer-Portale, wie www.upWork.com oder www.toptal.com eingekauft werden. Auch die Daten werden letztlich isoliert über einzelne Marktplätze angeboten, wie etwa der Mobilitätsdaten-Marktplatz (MDM) der Bundesanstalt für Straßenwirtschaft, der Data Intelligence Hub der Deutschen Telekom oder www.dawex.com. Gelänge es, alle für Machine-Learning-Vorhaben notwendigen Ressourcen über eine integrierte Plattform oder einen integrierten Marktplatz bereitzustellen, könnten für

Abb. 5.3 Über verschiedene Ressourcen-Marktplätze können Organisationen fehlende Ressourcen für die Lösung von Analyseaufgaben beziehen

5 Der Analytics-Marktplatz

171

unterschiedlichste Aufgabenstellungen basierend auf dezentral, aber demokratisch verwalteten Daten mit geeigneten Lernverfahren Modelle erstellt werden, die allen Interessenten zur Verfügung stünden. Eine entsprechende Entschädigung oder Bezahlung der genutzten Ressourcen sowie die Berücksichtigung von Datensicherheit und Datenschutz sollten dabei selbstverständlich sein. Diese Entwicklung förderte schließlich die transparente Entwicklung und Anwendung effizienter maschineller Lernverfahren und Anwendungen und schafft mehr Vertrauen in diese Technologie. Ein derartiger Marktplatz ließe sich als zentrale Plattform umsetzen. Zentrale Plattformen dieser Art sind beispielsweise durch AirBnB und andere Sharing Economies bekannt. Dabei besitzt der Marktplatzbetreiber meist keine eigenen Assets. Beispielsweise besitzt AirBnB selbst keine einzige Wohnung und tritt nur als Vermittler zwischen Wohnungseigentümern und Feriengästen auf. Mit hinreichend vielen Teilnehmern auf einer derartigen Plattform entwickelt der Betreiber eine gewisse Machtposition gegenüber den Anbietern und Nachfragern. Gerade auf einem Analytics-Marktplatz wäre ein Betreiber mit einer derartigen Machtposition jedoch hinderlich, denn gerade Organisationen würden sensible interne Daten und daraus abgeleitete Erkenntnisse als wettbewerbssteigernde Faktoren nicht in die Hände einer dritten Person geben wollen. Das Problem ließe sich durch Entfernen des Marktbetreibers, also des sogenannten Intermediärs, vermeiden. Als Lösung bietet sich daher ein dezentraler Marktplatz ohne zentralen Intermediär an. Dieser Ansatz ist durch Kryptowährungen auf Basis von BlockchainTechnologien sehr bekannt geworden. Das Ziel sollte es daher sein, einen AnalyticsMarktplatz als dezentrale integrierte Plattform zu betreiben. Der hier dargestellte Analytics-Marktplatz integriert ressourcenspezifische Marktplätze und beschreibt als übergeordneter konzeptioneller Ordnungsrahmen die Möglichkeiten, wie unterschiedliche Parteien ohne Intermediär in einer verteilten Umgebung ohne inhärentes Vertrauen durch das Zusammenbringen ihrer Ressourcen Lösungen für analytische Aufgabenstellung entwickeln können. Neben dem wichtigen Aspekt der Schaffung von Vertrauen in die verwendeten Ressourcen spielt dabei insbesondere die Vergütung (Incentivierung) der Ressourcenanbieter eine zentrale Rolle, um Anreize für die Ressourcenbereitstellung zu schaffen. Aus technischer Perspektive muss der Analytics-Marktplatz eine Automatisierbarkeit von Machine-Learning-Prozessen unterstützen, da die große Anzahl an aktuellen und künftig zu erwartenden Machine-Learning-Anwendungen sonst nicht realisierbar ist.

5.3

Ordnungsrahmen

Der hier vorgestellte Ordnungsrahmen mit seinen charakteristischen Ressourcen und Rollen soll es ermöglichen, die wesentlichen Konzepte und Ideen eines integrierten AnalyticsMarktplatzes zu erläutern. Durch das Zusammenbringen von Ressourcen verschiedener Parteien ergeben sich Herausforderungen, die dann zusammen mit möglichen Lösungsvarianten auf Basis von Blockchain-Technologien im folgenden Kapitel dargestellt werden. Aufgrund der Vielfältigkeit der notwendigen Lösungen, insbesondere unter

172

C. Lanquillon und S. Schacht

Berücksichtigung der Art der Anwendungen und des Grades des notwendigen Datenschutzes, wird es sehr unterschiedliche Ausprägungen geben und es müssen dabei nicht immer alle Rollen berücksichtigt werden. Schließlich werden in Abschn. 5.5 anhand des Ordnungsrahmens auch bestehende Marktplatz-Lösungen systematisch eingeordnet und beschrieben.

5.3.1

Ressourcen und Rollen

Ressourcen seien fest definierte Dinge, Aufgaben, Kompetenzen oder Fähigkeiten, die für die Modellerstellung und Modellanwendung von Bedeutung sind und über einen integrierten Analytics-Marktplatz angeboten und bezogen werden können. Bei Machine-LearningAnwendungen zählen Daten, IT-Infrastruktur wie Speicherplatz und Rechenleistung und ML-Expertise zu den klassischen Ressourcen. Ohne Daten kann nichts gelernt werden, die ML-Expertise ist für die korrekte und erfolgreiche Anwendung der Lernverfahren und Interpretation der Analyseergebnisse sehr wichtig und ohne angemessene Rechenleistung ist die Erstellung komplexer Modelle für große Anwendungen kaum noch realisierbar. Der Ressourcen-Begriff soll hier aber noch weiter gefasst werden und in ganz allgemeiner Form auch die Analyseaufgabe, die Validierung und die Anwendung bzw. das Modell als Produkt selbst umfassen, denn die Vorgehensmodelle wie CRISP-DM lehren, dass auch diese Aspekte für den Erfolg eines Machine-Learning-Projekts unverzichtbar sind. Abb. 5.4 gibt einen Überblick über die relevanten Ressourcen und Rollen im Ordnungsrahmen für den integrierten Analytics-Marktplatz. Bei den mit den Ressourcen assoziierten und eng verzahnten Rollen ist die Zuordnung zu Personen oder Organisationen, allgemein im Folgenden auch als Partei bezeichnet, von Bedeutung. Damit einher geht die Berücksichtigung der Interessen, die eine Partei verfolgt, und welchen Anreiz sie hat, um am Analytics-Marktplatz teilzunehmen. Zu beachten ist, dass häufig eine Organisation mehrere Rollen übernimmt. Bei der klassischen Betrachtung von Machine-Learning-Anwendungen werden die Rollen typischerweise gar nicht explizit betrachtet. Vielmehr wird implizit davon ausgegangen, dass alle Rollen durch eine Organisation abgedeckt werden. Die Zuordnung aber ist sehr wichtig, da sich durch die Verteilung der Rollen auf mehr als eine Partei, Konsequenzen für deren Zusammenwirken ergeben, die betrachtet werden müssen. Da die Ressourcen und Rollen so eng verknüpft sind, erfolgt die gemeinsame Beschreibung der beiden Konzepte.

5.3.1.1 Analyseaufgabe und Aufgabensteller Die Definition und Vorgabe einer Analyseaufgabe ist essenziell für die weitere Anwendung maschineller Lernverfahren. Die analytische Fragestellung leitet sich üblicherweise aus einer fachlichen Fragestellung ab und sollte auch Anforderungen an die Lösungserstellung und die Lösung selbst umfassen, wie etwa Kriterien zu deren Bewertung.

5 Der Analytics-Marktplatz

173

Abb. 5.4 Ordnungsrahmen für einen Analytics-Marktplatz mit relevanten Rollen und Ressourcen

Auch wenn sich viele Schritte des Machine-Learning-Prozesses automatisieren lassen, die Festlegung einer analytischen Aufgabenstellung als eine zentrale Aufgabe der BusinessUnderstanding-Phase und auch der Aufbau von Datenverständnis etwa in Bezug auf Qualität und Relevanz für eine Lösung lassen sich deutlich schwieriger automatisieren. Beide erfordern bislang meist menschliche Expertise und Interaktion zwischen Fachexperten und ML-Experten. Meist kommt die fachliche Fragestellung und somit der Aufgabensteller aus einer Organisation, die zwar auch noch andere Ressourcen wie etwa die Daten mit einbringt, aber auch nicht alle notwendigen Ressourcen für die Lösungserstellung selbst besitzt. Über den Analytics-Marktplatz ist jedoch auch ein weiteres Szenario denkbar. Jede Person oder jede Organisation kann letztlich auch ohne weitere Ressourcen die Rolle des Aufgabenstellers bekleiden und Analyseaufgaben definieren, wenn entsprechende Ideen vorhanden sind. Hervorzuheben ist deshalb auch die Möglichkeit, dass durch eine geschickte Kombination der

174

C. Lanquillon und S. Schacht

Ressourcen ein Geschäftsmodell basierend auf einer Idee, die entsprechend als Analyseaufgabe in den Marktplatz eingestellt wird, und mit einem geeigneten Konzept der Modellnutzung, auch ohne eigene Daten, kostspielige ML-Expertise und IT-Infrastruktur umsetzbar ist, solange fremde Parteien Interesse an einer Zusammenarbeit haben.

5.3.1.2 ML-Expertise und Modellersteller (ML-Experte) Für die Durchführung von Machine-Learning-Projekten mit einer erfolgreichen Modellerstellung sind Erfahrung und ML-Expertise notwendig, und zwar insbesondere in der Anfangsphase. Wenn eine geeignete Machine-Learning-Pipeline für die Modellerstellung aufgebaut und erprobt ist, kann die Durchführung stark automatisiert ablaufen, vor allem dann, wenn die Modellerstellung zwecks Anpassung an neue Daten wiederholt wird. Die Expertise für die Anwendung maschineller Lernverfahren zur Lösung von Analyseaufgaben ist sicherlich die Ressource, an der es Organisationen, die eine analytische Aufgabenstellung mit Hilfe von Daten beantwortet wissen möchten, am häufigsten mangelt. Wenn auch ML-Experten an den benötigen Stellen fehlen mögen, so gibt es sie dennoch, beispielsweise als Freiberufler, die sich nicht an ein Unternehmen binden möchten und sich ihre Projekte nach ihren Interessen und Fähigkeiten aussuchen. Auch im akademischen Umfeld gibt es zahlreiche Experten für die Entwicklung und Anwendung maschineller Lernverfahren. Dort mangelt es jedoch gelegentlich an der Verfügbarkeit interessanter Datenquellen für die Evaluierung der entwickelten Verfahren. Das Potenzial eines Analytics-Marktplatzes besteht insbesondere darin, die Parteien mit analytischen Fragestellungen und relevanten Daten mit geeigneten ML-Experten auf einfache und flexible und dennoch sichere und verlässliche Weise zusammenzubringen.

5.3.1.3 Daten und Datenanbieter Die Datenbereitstellung ist wegen ihrer Bedeutung als Grundlage für das maschinelle Lernen, der Heterogenität der Datenquellen und wegen möglicher Anforderungen hinsichtlich Datensicherheit und Datenschutz sicherlich der komplexeste Aspekt des AnalyticsMarktplatzes. Wegen der Vielschichtigkeit der Anforderungen wird es sehr wahrscheinlich unterschiedliche Lösungsvarianten geben, die auch in Kombination zum Einsatz kommen werden. Die unter Berücksichtigung gesetzlicher Vorgaben, wie etwa der europäische General Data Protection Regulation (GDPR), wichtigste Unterscheidung ist die Frage des relevanten Datenschutzes für eine Datenquelle. Da Daten oft als sensibel und als hochgradig schützenswert erachtet werden, stellt sich die Frage, ob ein Dateneigner überhaupt in die Rolle des Datenanbieters schlüpfen sollte, um seine Daten auf dem Analytics-Marktplatz anzubieten? Aber ganz offensichtlich kann es Gründe dafür geben. Eine Organisation kann diese Rolle übernehmen, um relevante Daten für eine gestellte Analyseaufgabe bereitzustellen. Der Anreiz für eine Organisation ist offenkundig der

5 Der Analytics-Marktplatz

175

Wunsch, eine Lösung für die Analyseaufgabe zu erhalten. In diesen Fällen muss auf eine zweckgebundene Verwendung der Daten im Kontext der vorgegebenen Aufgabe und auf entsprechenden Datenschutz geachtet werden. Wie kann erreicht werden, dass die Daten vertraulich bleiben, auch wenn beispielsweise ein fremder ML-Experte sie für eine Modellerstellung verwendet? Wie können Datendiebstahl oder eine spätere unrechtmäßige Verwendung von Kopien der Daten verhindert werden? Dieselben Fragen stellen sich, wenn Privatpersonen sensible Daten anbieten möchten. Aber was für einen Anreiz hat eine Privatperson, eigene Daten bereitzustellen? Neben einer klassischen Vergütung kann hier auch die Aussicht auf personalisierte Dienste eine Rolle spielen. Bei nicht oder deutlich weniger sensiblen Daten, wie beispielsweise SensorZeitreihen vieler IoT-Geräte, bietet die Vergütung für die Bereitstellung der Daten eine Möglichkeit der Refinanzierung der Anschaffungskosten der Geräte.

5.3.1.4 IT-Infrastruktur und deren Anbieter Bezüglich der IT-Infrastruktur werden Speicherplatz und Rechenleistung betrachtet. Speicherplatz kann erforderlich sein, um Daten zu speichern. Dies ist insbesondere dann relevant, wenn verschiedene Datenquellen an einem Ort zusammengeführt werden sollen oder unveränderliche Datenspeicherung gefordert wird. Aber auch für die Speicherung von Modellen kann Speicherplatz benötigt werden. Rechenleistung wird insbesondere für die Modellerstellung benötigt. Aber auch andere Schritte des Machine-Learning-Prozesses erfordern eine gewisse Rechenleistung. Beispielsweise haben gerade Deep-Learning-Ansätze einen sehr großen Bedarf. Zu beachten ist, dass gerade der Bedarf an Rechenleistung nicht dauerhaft hoch ist, sondern in Abhängigkeit der Phasen des Maschine-Learning-Prozesses typischerweise großen Schwankungen unterliegt. Ein Erwerb und dauerhaftes Bereitstellen von Rechenleistung ist mit sehr hohen Kosten verbunden. Organisationen versuchen deshalb, die Kosten zu senken, indem bedarfsgesteuert Rechenleistung eingekauft wird. Beispielhaft seien an dieser Stelle die zahlreichen Cloud-Anbieter genannt, deren Dienste neben Datenspeicherung auch ausgereifte Analysefunktionalitäten umfassen. Aber nicht nur die großen Cloud-Anbieter, sondern auch kleinere Anbieter und sogar Privatpersonen haben die Möglichkeit, nicht genutzten Speicherplatz und nicht genutzte Rechenkapazitäten über einen Analytics-Marktplatz anzubieten und somit zu monetarisieren. Bei der Nutzung entfernter Rechenleistung ist zu beachten, dass auch Daten dorthin transportiert werden müssen, wo gerechnet werden soll, wenn dies nicht schon der Fall ist. Ein wichtiges Big-Data-Paradigma verlangt, dass Daten nicht dorthin gebracht werden, wo die Rechenleistung ist, sondern dass Berechnungen dort stattfinden sollen, wo die Daten liegen. Bei großen Datenmengen ist dies zwingend erforderlich, um den oft kostspieligen Netzwerkverkehr gering zu halten. Das Anbieten und Nutzen von Rechenleistung ist daher stets in Verbindung mit dem Speicherort der zu verwendenden Daten zu betrachten.

176

C. Lanquillon und S. Schacht

5.3.1.5 Validierung und Modellvalidierer Aus CRISP-DM ist die Evaluierungsphase bekannt. Die dort genannten Aufgaben mit dem Ziel der Überprüfung, ob ein Machine-Learning-Modell die fachlichen Anforderungen der Anwendung erfüllt, bleiben erhalten. Wenn aber fremde Parteien bei der Modellerstellung beteiligt sind, denen noch nicht vertraut wird, ergeben sich zusätzliche Anforderungen. Es muss sichergestellt werden, dass ein Modell keine schädlichen Programmfragmente enthält, die bei der Modellanwendung zur Ausführung kommen könnten. Insbesondere bei einer automatisierten Nutzung von Modellen müssen auch Qualitätsstandards wie etwa eine nicht zu unterschreitende Modellgüte eingehalten werden. Eine zentrale Frage bei dieser Rolle ist, wer diese im Analytics-Marktplatz übernehmen kann? Der Aufgabensteller, der oft auch Modellnutzer ist, kommt dafür nicht infrage, denn es besteht die Gefahr des Rollenmissbrauchs. Eine Organisation könnte behaupten, das Modell erfülle die Anforderungen nicht und trotzdem das zu validierende Modell nutzen, ohne dafür den Modellersteller zu vergüten. Lässt sich ein Modell validieren, ohne das Modell selbst zu sehen? Damit eine dritte Partei als Validierer einspringt, muss die Vergütung dafür angemessen sein.

5.3.1.6 Anwendung, Modell und Modellnutzer Es sind einige grundlegend verschiedene Varianten der Modellnutzung denkbar. Wichtig ist die Unterscheidung zwischen öffentlichen und privaten Modellen. Modelle für die private Nutzung, die nicht jeder beteiligte und eingebundene MarktplatzTeilnehmer einsehen kann, entsprechen eher der klassischen Nutzung von MaschineLearning-Ergebnissen, nach denen eine Organisation als Antwort für eine analytische Fragestellung im Rahmen eines angestrebten Anwendungsszenarios suchte. Somit werden mindestens die Rollen des Aufgabenstellers und Modellnutzers durch eine Partei abgedeckt. Die Wahrung von Datenschutz und Vertraulichkeit der Ergebnisse müssen dabei bei der Modellerstellung durch fremde Parteien berücksichtigt werden. Für eine öffentliche Modellnutzung kommen wiederum verschiedene Formen infrage. Zu unterscheiden ist zwischen einer unmittelbaren und einer mittelbaren Modellnutzung. Die unmittelbare Nutzung entspricht der Vermarktung fertig trainierter und getesteter Modelle über eine Modell-Bibliothek für etwaige Interessenten. Potenzielle Nutzer sind dann zum Beispiel Entwickler, die auf Basis der Modelle höherwertigere Produkte entwickeln möchten. Beispielsweise könnten die Entwickler von Software zur Unterstützung des Abwiegeprozesses von Obst und Gemüse in Supermärkten auf fertige Modelle für die Erkennung bestimmter Gegenstände auf Bildern zurückgreifen, sodass der Entwicklungsprozess für derartige Anwendungen beschleunigt wird. Weiterhin können die fertigen Modelle zum Beispiel auch als Basis eines Transfer-Learning-Prozesses für die Weiterentwicklung der Modelle anhand anwendungsspezifischerer Daten dienen. Bei der mittelbaren Modellnutzung kommen Modelle nicht direkt, sondern indirekt durch Integration in Produkte oder Dienstleistungen zur Anwendung. In diesem Fall gilt derjenige,

5 Der Analytics-Marktplatz

177

der die Modelle integriert als der Modellnutzer, auch wenn die analytische Funktionalität letztlich dem Anwender der smarten Produkte oder Dienstleistungen zugutekommt. So können beispielsweise die Fähigkeiten eines trainierten Modells als Model-as-a-Service über eine geeignete Schnittstelle angeboten werden.

5.4

Herausforderungen und Lösungsansätze

Oben wurde erläutert, dass ein integrierter Analytics-Marktplatz dezentral ohne Intermediär umgesetzt werden sollte, um eine mögliche Machtposition zentraler Instanzen auszuschließen. Wenn über eine verteilte Plattform ohne inhärentes Vertrauen verschiedene Parteien ihre Ressourcen anbieten sollen, damit in ihrer Kombination Machine-Learning-Lösungen entstehen, gibt es vier zentrale Herausforderungen zu betrachten. Wie können sich die beteiligten Parteien vertrauen? Wie kann Vertrauen in die angebotenen Ressourcen hergestellt werden, ohne dass die beteiligten Parteien sich kennen müssen? Anreizsystem Wie kann ein Anreizsystem etabliert werden, das die für ein MachineLearning-Projekt relevanten Parteien dazu bewegt, als Teilnehmer am Analytics-Markt aktiv zu agieren? Wie kann das Anbieten schadhafter, böswilliger oder gefälschter Ressourcen unterbunden werden? Datenschutz Wie können Daten geschützt werden, mit denen fremde Parteien Machine-Learning-Modelle erstellen sollen? Automatisierung Wie lässt sich der Austausch von Ressourcen und die Zusammenarbeit der beteiligen Parteien so gestalten, dass die Schritte auch stark automatisiert ablaufen können? Vertrauen

Im Folgenden wird dargelegt, wie diese vier zentralen Herausforderungen mit Hilfe von Blockchain-Technologien adressiert werden können.

5.4.1

Vertrauen

Vertrauen hinsichtlich eines Sachverhalts kann zwischen Parteien entstehen, wenn sich über längere Zeit kennen oder aber, wenn der Sachverhalt transparent und nachverfolgbar dauerhaft dokumentiert. Da es mühsam ist, ständig lange Historien von Sachverhalten zu prüfen, ob man ihnen zustimmt und daher vertraut, kann ihnen auch vertraut werden, wenn viele andere dies tun, also wenn allgemein ein Konsens darüber besteht. Das ist das Grundprinzip, wie bei der Blockchain Vertrauen etabliert wird. Sachverhalte sind beliebige Dinge, die in Form von Daten als Transaktionen in Blöcken dauerhaft und unveränderlich in einer Blockchain gespeichert werden. Die Funktionsweise der Blockchain mit ihrer verteilten Speicherung der Blöcke auf allen oder einer sehr großen

178

C. Lanquillon und S. Schacht

Anzahl an Recheneinheiten (Knoten) der beteiligten Parteien und Überprüfung der Korrektheit durch Konsensbildung zwischen den Parteien, kann zwar Vertrauen zwischen den Parteien etablieren, hat aber auch zwei gravierende Nachteile mit entscheidender Konsequenz für einen Einsatz als Infrastrukturbasis des Analytics-Marktplatz. Das Speichern von Daten in einer Blockchain ist vergleichsweise langsam und teuer und deshalb in seiner aktuellen Form für größere Datenmengen ungeeignet. Das Vertrauen in die Korrektheit und Verlässlichkeit der einzelnen Ressourcen und Rollen ist auch beim Analytics-Marktplatz ganz entscheidend. Drei der oben beschriebenen Ressourcen verdienen dabei einer besonderen Betrachtung im Rahmen des maschinellen Lernens, da sie für einen Zugriff und die Sichtbarkeit anderer gespeichert werden müssen. Dies sind insbesondere Daten und Modelle, aber auch die Festlegung der Analyseaufgaben. Neben Vertrauensbildung durch Unveränderlichkeit und Konsens werden auch die sogenannten Smart Contracts als Erweiterung der klassischen Strukturen für komplexere Interaktionen in einer Blockchain relevant. Aus technischer Sicht sind Smart Contracts kleine Programme, die in der Blockchain ausgeführt werden und Bedingungen einer Vereinbarung zwischen Parteien überprüfen können. Mit Hilfe von Smart Contracts lassen sich Beziehungen zwischen Parteien in Form von Vereinbarungen oder Verträgen formalisieren und absichern [8]. Die Sichtbarkeit des Programmcodes von Smart Contracts schafft Transparenz und Vertrauen, hat aber auch wiederum Konsequenzen hinsichtlich des Datenschutzes. Daten Ein ML-Experte in der Rolle des Modellerstellers verwendet Daten eines oder mehrerer Datenanbieter und muss sich auf die Korrektheit und Unveränderlichkeit der Daten verlassen können, denn der Lernprozess und folglich die Modellgüte hängen maßgeblich davon ab. Der Modellersteller muss das Zustandekommen seines Modells aus den Daten belegen können, damit diesem vertraut werden kann. Dennoch dürfte eine Speicherung aller relevanten Daten in einer Blockchain eher eine theoretische Lösung bleiben, denn aufgrund der Größe der meisten relevanten Datenbestände dürften technische und wirtschaftliche Gründe dagegen sprechen. Wie oben bereits erwähnt, skalieren existierende Blockchain-Varianten nicht gut und sind für die Datenspeicherung als Lösung zu langsam und zu teuer. Stattdessen bieten sich Lösungen wie das InterPlanetary File System (IPFS) oder Swarm an. Während dort die kompletten Daten liegen, wird lediglich ein Hash-Wert, der auf dem Inhalt eines Datenpakets bestimmt wird, unveränderlich in einer Blockchain gespeichert. Auf diese Weise kann deutlich effizienter die Unveränderlichkeit und Korrektheit der Daten gewährleistet werden. Modell Die meisten Modelle sind zwar deutlich kleiner als die Datenmenge, die bei der Modellerstellung verwendet wird, aber immer noch deutlich größer als die Transaktionen, die in klassischen Blockchain-Anwendungen gespeichert werden. Daher empfiehlt es sich, auch

5 Der Analytics-Marktplatz

179

Modelle genau wie die Daten nicht direkt in einer Blockchain, sondern über einen entsprechendes Speichernetzwerk abzulegen. Modelle und deren Nutzung könnten auch durch Smart Contracts abgesichert werden, zum Beispiel indem Modelle selbst als Smart Contracts programmiert werden. Wiederum die Modellgröße und die Menge der notwendigen Rechenoperationen verbieten aber auch diese Lösung in der Praxis. Da die Sicherstellung der Korrektheit und Validierung der beabsichtigen Funktionsfähigkeit jedoch essenziell für die Modellnutzung sind, gibt es explizit die Rolle des Modellvalidierers. Diese Aufgabe ist in Analogie zur Konsensbildung über die gefahrlose Verwendbarkeit von Modellen zu interpretieren. Um den Missbrauch dieser Rolle etwa durch unberechtigte Modellnutzung ohne entsprechende Vergütung zur gewährleisten, könnten dabei Konzepte wie der kenntnisfreien Beweis (engl. zero knowledge proof) zum Einsatz kommen. Analyseaufgabe Eine Analyseaufgabe muss unveränderlich gespeichert werden, damit sich ein Modellersteller darauf verlassen kann, dass er die richtige Aufgabe löst und diese nach Erstellung einer Lösung nicht einfach geändert wird und dadurch seine Lösung unbrauchbar und sein Aufwand vergeblich war. Für die Beschreibung und Festlegung einer Analyseaufgabe zusammen mit geeigneten Bewertungskriterien für die Evaluierung lassen sich Smart Contracts als Vereinbarung zwischen Aufgabensteller und Modellersteller (ML-Experte) über die Erstellung eines Modells umsetzen. Bei der Umsetzung des Smart Contracts für die Analyseaufgabe gibt es jedoch Folgendes zu beachten. Für die Bewertung von Modellen werden üblicherweise Testdaten benötigt, die aufgrund ihrer Größe wiederum nicht im Smart Contract und somit in einer Blockchain gespeichert werden sollten. Wie bereits allgemein beim Punkt Daten erläutert, sollte dafür auf entsprechende Speichernetzwerke zurückgegriffen werden. Allerdings dürfte der Hash-Wert als Adresse der Testdaten nicht über den Smart Contract einsehbar sein. Denn dies böte dem Modellersteller die Gelegenheit, auf die Testdaten selbst zuzugreifen und diese im Lernprozess zu verwenden, um bessere Modelle zu erstellen. Dabei handelt es sich um eine aus Sicht des maschinellen Lernens unerwünschte Form des Data Leakage, die zu Overfitting führt. Das vom Modellersteller erstellte Modell wäre zwar sehr wahrscheinlich auf den Testdaten und deshalb vermeintlich gut, aber auf wirklich ungesehen Daten eher nicht. Aber auch ohne direkte Sichtbarkeit der Adresse der Testdaten kann sich eine Form des Data Leakage einstellen. Nämlich genau dann, wenn der Modellersteller durch wiederholtes Ausführen der Modellbewertungsmethoden des Smart Contracts Kenntnisse über die erwarteten Ergebnisse für die Testdaten erlangt und in die künftige Modellerstellung einfließen lässt. Durch Berechnung der Bewertungskriterien auf einer dem Modellersteller unbekannten zufälligen Stichprobe der Testdaten kann dieses Risiko stark begrenzt werden.

180

C. Lanquillon und S. Schacht

Das Verstecken der Adresse der Testdaten oder der Bewertungsmethodik selbst innerhalb des Smart Contracts steht jedoch im Gegensatz zur Transparenzforderung, die durch vollständige Einsehbarkeit des Programmcodes eines Smart Contracts erfüllt wird. Durch Verschlüsselung der gesamten Bewertungsmethodik und modifizierbare Festlegung ausgewählter Validierern etwa nach einem noch zu etablierenden delegierten Beweis des Lernerfolgs (engl. delegated proof of learning) kann dieses Problem gelöst werden. Die Erstellung der Analyseaufgabe durch den Aufgabensteller mit fachlicher Expertise und die dann folgende Bearbeitung durch den Modellersteller mit seiner ML-Expertise definiert eine klare Trennung der beiden Rollen. Die Beschreibung der BusinessUnderstanding-Phase des Prozessmodells CRISP-DM verdeutlicht jedoch, dass bereits für die Ableitung einer Analyseaufgabe aus einer fachlichen Fragestellung ML-Expertise notwendig ist. Durch geeignete Interaktion zwischen den beiden Rollen oder durch den Einsatz zusätzlicher ML-Expertise muss eine verständliche und korrekte Aufgabenstellung gewährleistet werden.

5.4.2

Datenschutz

Die lokal für einen Datenbestand geltenden erfüllten Bestimmungen hinsichtlich Datensicherheit und Datenschutz bleiben unbedingt bestehen. Zusätzlich ist zu überlegen, welche zusätzlichen Herausforderungen durch den Austausch von Daten und auch Modellen und die Verwendung dieser durch fremde Parteien entstehen. Für eine sichere Modellerstellung, Modellvalidierung und Modellanwendung aus anderen Systemen heraus ist ein verschlüsselter Sandbox-Modell-Container, der Berechnungen für und durch ein Modell kapselt, wie man es beispielsweise von einer Java Virtual Machine (JVM) kennt, mit folgenden Eigenschaften sinnvoll: • • • • • • • • • • • •

Referenziert den Smart Contract für die Analyseaufgabe Konfigurierbar durch eine definierte Machine-Learning-Pipeline Inhalte unverschlüsselt nur für befugte Parteien wie dem Modellersteller Verschlüsselter Zugriff auf alle relevanten externen Datenquellen Verschlüsselte externe Speicherung von Modellen Ausführbar durch Rechenleistungsanbieter für die Modellerstellung Ausführbar durch Modellvalidierer für die Überprüfung Ausführbar durch Modellnutzer als eingebettete Komponente Unveränderbarkeit der Modelle nach ihrer Erstellung Export des gelernten und getesteten Modells für externe Nutzung Protokollierung verwendeter Ressourcen Kopplung mit Anreizsystem des Analytics-Marktplatzes

5 Der Analytics-Marktplatz

181

Um den Bezug zu einer Analyseaufgabe zu bewahren und die Bewertungskriterien abrufen zu können, ist eine unveränderbare Referenz auf den entsprechenden Smart Contract notwendig. Ein Modellersteller kann zur Lösung der Analyseaufgabe eine Machine-LearningPipeline als Modell-Template anhand aller verfügbaren Trainingsdaten oder auch nur basierend auf einer Stichprobe aufbauen und testen. Mit diesem Modell-Template instanziiert er einen Modell-Container, der dann auf beliebiger Infrastruktur mit entsprechender Vorrichtung ausführbar ist. So kann der oft langwierige und rechenintensive Lernprozess je nach Erfordernis entweder auf den Recheneinheiten des Modellerstellers selbst, bei den Datenanbietern oder bei einem Rechenleistungsanbieter durchgeführt werden. Der Zugriff auf die relevanten Datenquellen und der Transport zum Modell-Container muss verschlüsselt erfolgen, um die Daten vor unbefugter Einsicht auf fremden Rechnern zu schützen. Nach der Modellerstellung ist ein Modell unveränderbar und die Speicherung erfolgt bei Bedarf auch extern durch geeignete Speichernetzwerke wie oben beschrieben. Alle verwendeten Ressourcen werden protokolliert. Dies ist für die Incentivierung der Ressourcenanbieter notwendig und gewährleistet gleichzeitig Transparenz und Nachvollziehbarkeit der Modellerstellung. Letzteres ist nicht nur für das Etablieren von Vertrauen in das Modell notwendig, sondern wird teilweise auch aufgrund gesetzlicher Vorgaben bezüglich des transparenten und erklärbaren Einsatzes von Machine-Learning-Lösungen etwa durch die europäische General Data Protection Regulation (GDPR) gefordert. Modellvalidierer müssen innerhalb des Modell-Containers die Korrektheit überprüfen und die Modellgüte entsprechend der Vorgaben im Smart Contract für die Analyseaufgabe bewerten können. Das gelernte und getestete Modell muss einerseits innerhalb des Modell-Containers anwendbar sein, um bei Bedarf ein fremdes System nicht möglichen schädlichen Komponenten im Modell auszusetzen. Andererseits muss es auch die Möglichkeit geben, das gelernte und getestete Modell zu exportieren, um es außerhalb des Marktplatzes und dessen Infrastrukturvorgaben nutzen zu können. Bezüglich sinnvoller Austauschformate für Modelle sind Erfahrungen aus dem Bereich des Lebenszyklus-Managements von Modellen und deren Operationalisierung zu beachten. Schließlich ist eine Kopplung mit dem Anreizsystem des Analytics-Marktplatzes erforderlich, damit entsprechend der für die Modellerstellung verwendeten Ressourcen und der Modellnutzung die Incentivierung entsprechend erfolgen kann. Auch wenn sich konzeptionell für die Umsetzung des Modell-Containers ein Smart Contract anbieten, ist davon aufgrund er zu erwartenden Datenmengen und Rechenoperationen aus Performance- und Kostengründen abzuraten. Durch Lernen auf verschlüsselten Daten, etwa unter Verwendung homomorpher Verschlüsselung [4], oder durch verteiltes und insbesondere föderiertes Lernen (siehe Grundlagenkapitel zum maschinellen Lernen) kann der Schutz privater Daten weiter erhöht werden [9]. Dabei ist jedoch zu beachten, dass durch die Verschlüsselung und die Verteilung die Möglichkeiten hinsichtlich der lösbaren Aufgaben eingeschränkt werden kann und dass auch das Datenverständnis des Modellerstellers und folglich die Modellgüte darunter leiden können.

182

5.4.3

C. Lanquillon und S. Schacht

Anreizsystem

Ein faires, transparentes und reibungslos funktionierendes Anreizsystem ist essenziell für den Erfolg des Analytics-Marktplatzes. Ein Vorteil, der sich durch die Verwendung von Blockchain-Technologien ergibt, ist die meist direkte Verfügbarkeit oder enge Kopplung mit geeigneten Vergütungskonzepten wie zum Beispiel Micro-Payment-Kanäle. Aber welche Anreizmittel gibt es und wie lassen sich diese verteilen? Eine Vergütung muss nicht zwingend finanziell erfolgen. Es sind auch ein Austausch von Ressourcen, Rabatte auf Produkte oder gar die freie Nutzung von Dienstleistungen denkbar im Gegenzug für die Erlaubnis, Daten zu nutzen. Entscheidend ist, dass dieser Austausch wissentlich erfolgt und dass nachvollziehbar ist, welche Daten verwendet wurden. Gerade dies ist konträr zur aktuellen Praxis vieler Internetkonzerne, bei denen die Nutzung der Kundendaten deutlich intransparenter ist und oftmals unwissentlich geschieht. Eine finanzielle Vergütung kann transparent und vollautomatisch über Smart Contracts erfolgen. Die Höhe der Vergütung ist davon abhängig, wie positiv die erbrachte Leistung den Dienst schlussendlich beeinflusst hat. Dies geschieht, nachdem der Nutzer einer Dienstleistung den zuvor festgelegten Betrag beigesteuert hat. Es bietet sich im Falle eines Blockchain gestützten Systems an, diese Abwicklungen über eine angebundene Kryptowährung abzuwickeln. So können die Nachvollziehbarkeit sowie ein hoher Grad an Automatisierung sichergestellt werden. Während die ML-Experten als Modellersteller, die Datenanbieter, die Anbieter von ITInfrastruktur und die Modellvalidierer für ihre angebotenen und genutzten Ressourcen eine Vergütung empfangen, werden der Aufgabensteller und ganz besonders der Modellnutzer für die genutzten Ressourcen und Leistungen bezahlen. Die absolute Höhe der Vergütung für die Nutzung eines Modells oder die Beauftragung der Modellerstellung wird sicherlich der Markt selbst regeln. Wie aber können die Leistungen innerhalb des Machine-Learning-Prozesses verrechnet werden? Auf die regulierenden Kräfte von Angebot und Nachfrage muss auch bei der relativen Verteilung nicht verzichtet werden. Zusätzlich sollte aber auch die Güte eines Modells in Relation zur Güte bekannter und konkurrierender Modelle und insbesondere auch die Stärke des Einflusses einzelner Datenpakete auf die Modellgüte berücksichtigt werden. Beispielsweise lässt sich der Einfluss einzelner Merkmale auf ein Modell bei vielen Lernverfahren bestimmen. Die Vergütung für die Nutzung angebotener Ressourcen kann schwarze Schafe dazu verführen, falsche oder korrupte Daten oder Modelle anzubieten. Dies wird oft erst durch den Schaden bemerkt, den diese Daten oder Modelle anrichten. Durch Entzug oder Verweigerung der Entlohnung und schlechte Bewertungen würden sich diese Anbieter nicht langfristig auf dem Analytics-Marktplatz halten können. Jedoch kann ein Anbieter unter stets neuen Namen oder Adressen erneut schädliche Ressourcen bereitstellen. Durch die Schaffung leichter Eintrittsbarrieren zum Analytics-Markt kann dieses Problem deutlich reduziert werden. Auch dieses Konzept ist im Umfeld der BlockchainTechnologie bekannt. Um eine Rolle zu übernehmen und bestimmte Aufgaben zu bearbeiten,

5 Der Analytics-Marktplatz

183

die später incentiviert werden, muss anfangs Einsatzgeld (engl. stake) gezahlt werden. Bei akzeptiert gutwilliger Teilnahme und Erfüllung der Aufgaben kann mehr als das Einsatzgeld durch die Vergütung der genutzten Ressourcen zurückfließen. Werden die Leistungen jedoch als bösartig identifiziert, dann ist das Einsatzgeld verloren.

5.4.4

Automatisierung

Die Verwendung von Smart Contracts für die Definition der Analyseaufgabe und die Verwendung der Modell-Container wie oben dargestellt ermöglichen einen hohen Grad der Automatisierung. Sobald ein ML-Experte eine Machine-Learning-Pipeline aufgebaut und getestet hat, ist der Prozess der Modellerstellung bis hin zur Operationalisierung von Modellen im Rahmen einer Anwendung vollständig automatisiert ausführbar. Selbst die Validierung der Modelle lässt sich durch die Modell-Container und die Vorgaben im Smart Contract der Analyseaufgabe automatisieren, sodass die Gefahr des Einsatzes unzureichend arbeitender Modelle gering ist. Wie bereits im Grundlagenkapitel zum maschinellen Lernen bei den Vorgehensmodellen beschrieben, erfordern sowohl das Business und Data Understanding also auch einige Schritte der Datenaufbereitung einen manuellen Einsatz des Modellerstellers mit seiner ML-Expertise. Bei der Verwendung des Modell-Containers äußert sich dieser Fakt in der Bereitstellung des aufgebauten und getesteten Modell-Templates. Zukünftige Forschung und Entwicklung werden bestrebt sein, die Erstellung des Modell-Templates weiter zu automatisieren. Die Formalisierung und dafür notwendige Standardisierung der Prozessschritte im Rahmen des Modell-Containers unterstützt dieses Bestreben.

5.5

Aktuelle Ansätze

Die Idee Ressourcen für das maschinelle Lernen über einen blockchainbasierten Marktplatz ist vergleichsweise jung und es existieren erst wenige wissenschaftliche Beiträge sowie Beschreibungen von Unternehmen, insbesondere Start-ups, die derartige Bestrebungen umsetzen. In fast allen Beiträgen werden aber immer die Problematik der mangelnden Ressourcen auf der Seite des maschinellen Lernens und die Möglichkeit der automatisierten Abwicklung durch eine dezentrale Blockchain genannt. Es wird meist angenommen, dass das maschinelle Lernen ausschließlich auf Software basiert und die Modellerstellung daher keinerlei Interaktion mit dem Menschen benötigt, zumindest nachdem die Daten angemessen aufbereitet wurden. Daher ist es auch nach Kurtulmus und Daniel nur folgerichtig, diese beiden Welten zu verbinden. Im Folgenden werden einzelne interessante aktuelle Ansätze anhand des oben dargestellten Ordnungsrahmens systematisch eingeordnet und beschrieben.

184

5.5.1

C. Lanquillon und S. Schacht

Kurtulmus und Daniel: Trustless Machine Learning Contracts

Kurtulmus und Daniel zeigen in ihrem Beitrag auf wie ein solcher Marktplatz aussehen könnte. Sie sehen vor allem Smart Contracts als wesentliche Funktion zur Validierung und Incentivierung von gelernten Modellen, die über diese Plattform ausgetauscht werden [6]. Smart Contracts stellen die Kommunikationsschnittstelle zwischen den Parteien dar, wie im oben eingeführten Ordnungsrahmen beschrieben und in Abb. 5.4 zu erkennen ist. Dabei kann jeder Beteiligte, der Daten besitzt, auch einen derartigen Smart Contract laut den Autoren anlegen. Selbst Software-Agenten können dies ohne jegliche menschliche Interaktion tun. Die Rolle des Aufgabenstellers, des Modellnutzers und die des Datenanbieters fallen somit im Modell von Kurtulmus und Daniel zusammen. Der Smart Contract verifiziert und validiert, am besten vollautomatisch, die Ergebnisse eines für bestimmte Daten trainierten Modells und entlohnt den Modellanbieter mit einer Belohnung. Die Rolle des Modellvalidierers fällt somit im Modell der Autoren – zumindest bei der vollautomatischen Validierung – den Smart Contracts zu, die entweder aufgrund der programmierten Logik des Smart Contracts die Validierung direkt vornehmen oder über einen Konsens-Mechanismus an viele Personen verteilen [6]. Spannend ist die Idee der Autoren, die Ressourcen der Blockchain – nämlich die Knoten, die den Betrieb und Sicherheit des Netzwerkes sicherstellen – aufgrund des Anreizsystems entweder für das Minen und damit für die Validierung der Transaktionen oder für die Berechnung der Modelle im Rahmen des maschinellen Lernens zu verwenden. Die zugrunde liegende Idee basiert auf der Tatsache, dass für die Validierung von Transaktionen z. B. auf Basis des Proof-of-Work-Konsensus-Algorithmus in der Regel sehr viel GPU-Rechenleistung benötigt wird, die aber auch häufig für die Erstellung von MachineLearning-Modellen eingesetzt wird. Somit steht den Knotenbetreibern frei, ob sie entweder die Rolle des IT-Infrastruktur-Anbieters mit Rechenleistung für die Modellerstellung übernehmen oder ob sie die verfügbare Rechenleistung eher für das Minen verwenden, also für die Verifikation und Validierung der Transaktionen des zugrunde liegende Blockchain-Netzes. Laut den Autoren ist diese Entscheidung abhängig von der Incentivierung: Die Tätigkeit, die einen höheren Ertrag verspricht, wird sicherlich von den Knotenbetreibern bevorzugt gewählt [6]. Im Konkreten stellen Kurtulumus und Daniel ein Protokoll auf Basis der EthereumBlockchain vor, das sie DanKu-Protokoll nennen. Dieses Protokoll ist die Basis des ML-Exchange-Marktplatzes und entspricht in Teilen dem oben vorgestellten AnalyticsMarktplatz. Der Marktplatz selbst sieht eine Wettbewerbskomponente zwischen den MLExperten vor. Der Experte, der den besten Algorithmus in einer definierten Zeitspanne erstellt, bekommt die im Smart Contract hinterlegte Belohnung. Technisch sind das Protokoll und damit zwangsläufig auch die Prozessschritte in vier wesentliche Phasen aufgeteilt:

5 Der Analytics-Marktplatz

185

Initialisierungsphase Initialisierung des Smart Contracts, um einen Wettbewerb als Organisator anzulegen. Der Organisator stellt in dem Ordnungsrahmen die auf ihn gebündelten Rollen Aufgabensteller, Datenanbieter und Modellnutzer dar. Zur Initialisierung wird zunächst der Smart Contract in der Blockchain angelegt. Aber auch die Definition der Dauer des Wettbewerbs, also wie viele Blöcke dieser Smart Contract neue angelernte Modelle empfängt, werden nun dem Smart Contract als Parameter mitgegeben. Sobald der Smart Contract aktiviert ist, können in der Initialisierungsphase auch die Daten für den Wettbewerb zur Verfügung gestellt werden. Die Daten müssen zunächst in Trainingsund Testdaten aufgeteilt werden. Diese müssen den ML-Experten später über den Contract zur Verfügung gestellt werden, damit diese auf diesen Daten ihre Modelle erstellen können. Entscheidend ist hier, dass die vom Anbieter bereitgestellten Daten den ML-Experten nicht vollständig für die Modellerstellung zur Verfügung gestellt werden, sondern dass diese über den Smart Contract in kleine Portionen zerschnitten und abgelegt werden. So hat der Organisator keinen Einfluss darauf, welche Datenpakte die ML-Experten bekommen. Diese Vorgehensweise ist wichtig, da sonst der Organisator mit Fake-Daten Modelle einsammeln könnte, ohne dass eine Belohnung ausbezahlt werden würde. Da die Speicherung der Daten in der Ethereum-Blockchain sehr teuer ist, werden die Daten nicht im Smart Contract direkt, sondern in dem InterPlanetary File System (IPFS) abgelegt und mittels des Hash-Wertes, der die Adresse der abgelegten Daten darstellt, mit dem Smart Contract verknüpft. Die Ablage im IPFS hat den Vorteil, dass sie dezentral vorgenommen wird. Auch wenn die Autoren dies nicht so vorsehen, wäre es möglich das DanKu-Protokoll um die Rolle der IT-Infrastruktur-Anbieter zu erweitern und die Knotenbetreibern, die Daten im IPFS-Netz speichern, dafür über den Smart Contract zu vergüten. Damit hätten auch die Knotenbetreiber des IPFS-Netzes ein Interesse, die Daten für die Zeitspanne des Wettbewerbes zu speichern. Zu guter Letzt muss der Organisator im Smart Contract auch eine Evaluationsfunktion bereitstellen, die es ermöglicht, eine Bewertung der übermittelten ML-Modelle vorzunehmen. Außerdem hinterlegt der Organisator in einem Wallet in der Blockchain einen für ihn akzeptablen Betrag, mit dem der beste und ggf. weitere Modellersteller und die IPFSKnotenbetreiber vergütet werden. Submission-Phase Nachdem in der ersten Stufe der Wettbewerb vom Organisator angelegt wurde, können nun ML-Experten in den Prozess einsteigen. Zunächst können diese anhand der im Smart Contract hinterlegten Hash-Werte die Daten für das Training und Testen aus dem IPFS laden. Anhand dieser wird nun ein ML-Modell bestmöglich erstellt. Während der vom Smart Contract definierte Zeitspanne, können die ML-Experten so viele trainierte Modelle hochladen, wie sie möchten. Entscheidend ist, dass die Bereitstellung des Modells einerseits aus der Modell-Definition und den Parametern und den angelernten Gewichtungen besteht.

186

C. Lanquillon und S. Schacht

Ergänzend muss der ML-Experte auch noch eine Account-Adresse übermitteln, an die die Belohnung überwiesen wird, falls das eingereichte Modell sich für eine Vergütung qualifiziert. Evaluationsphase Die dritte Stufe des Protokolls sieht die Evaluierung der Ergebnisse der übermittelten Modelle vor. Diese Phase kann gemäß Protokoll auf zwei verschiedene Weisen initiiert werden. Entweder wird sie eingeleitet, sobald die in der Initialisierung hinterlegten Zeitspanne abgelaufen und damit der Wettbewerb beendet ist, oder aber sie wird beliebig vor Ablauf der Wettbewerbsfrist manuell durch den Organisator getriggert. Wenn die Evaluierungsphase beginnt, kann kein ML-Experte mehr neue Modelle übermitteln und der Smart Contract beginnt mit der Evaluierung aller bislang übermittelten Modelle. Aus den Bewertungen wird ein Ranking bezüglich der Modellgüte erstellt. Post-Evaluationsphase Nach Abschluss der Evaluierungsphase kann jeder der Beteiligten die Auszahlung der Belohnung über den Smart Contract anfordern. Die hinterlegte Belohnung wird dann vom Smart Contract direkt ausbezahlt. Sollte zu diesem Zeitpunkt kein Modell bereitgestellt worden sein oder die übermittelten Modelle nicht die erwartete Qualität aufweisen, wird die hinterlegte Belohnung an den Organisator zurücküberwiesen. In beiden Fällen wird am Ende der Phasen der Smart Contract geschlossen, sodass keine weiteren Aktivitäten mehr möglich sind. Das hier von Kurtulumus und Daniel vorgestellte Modell ähnelt dem Geschäftsmodell der von Google betriebenen Tochter Kaggle, die über eine zentralisierte, von Kaggle kontrollierte Plattform ML-Experten mit Personen in der gleichzeitigen Rolle des Modellnutzers, Aufgabenstellers und Datenanbieters zusammenbringt. Durch die Verwendung der Blockchain wird aber die dominierende zentrale Rolle des Betriebers aufgelöst. Die relevanten Daten werden nicht mehr in einer zentralen Plattform zur Verfügung gestellt. Schließlich wird die gesamte Incentivierung inklusive die der IT-Infrastruktur-Anbieter über die Blockchain automatisiert und ggf. auch autark vorgenommen. Der so dargestellte ML-Marktplatz hat aber noch einige praktische Hürden zu überwinden. Hierunter fallen einzelne byzantinische Angriffsszenarien, bei denen der Organisator z. B. Testdaten zurückhält, um bewusst keine Entlohnung zahlen zu müssen oder ML-Experten die Modelle so bauen, dass diese perfekt passen, in dem sie etwa auch die Testdaten zur Modellerstellung verwenden und nur aufgrund von Overfitting den ersten Platz im Ranking belegen. Aber auch technische Hürden, wie die Ausführungsdauer von Smart Contracts stellen für diese Art der Verwendung noch eine Hürde da. Jeder Smart Contract läuft auf den Knoten des Ethereum-Netzes. Damit diese aber nicht durch einen einzelnen Vertrag überlastet werden, sind Ausführungen in der Zeit beschränkt. Viele Übermittlungen von ML-Modell an den Smart Contract wären dann ebenfalls problematisch, da dieser abbricht, bevor alle Modelle bewertet sind. Alle aufgeführten Probleme lassen sich durch ein geeignetes Design des Smart Contracts oder durch zusätzliche Funktionen beheben.

5 Der Analytics-Marktplatz

187

Eine Sache mit großem Forschungsbedarf ist die Tatsache, dass alle Modelle und die Daten in Klartext, also von jedem lesbar in der Blockchain bzw. im IPFS verfügbar sind. Dieses Problem könnte zukünftig durch die Verwendung homomorphischer Verschlüsselungen gelöst werden, bei der eine Analyse auf verschlüsselten Daten möglich ist.

5.5.2

Özyilmaz et al.: IDMoB: IoT Data Marketplace on Blockchain

Einen ähnlichen Weg wie Kurtulumus und Daniel gehen Özyilmaz et al., indem sie einen Daten-Marktplatz ebenfalls mit Hilfe von Smart Contracts umsetzen [7]. Die wesentliche Unterscheidung ist, dass die Autoren eine Fokussierung auf IoT-Daten und deren Austausch zwischen den Modellerstellern und den Datenanbietern schaffen wollen. Ziel soll es sein, einen dezentralen vertrauenswürdigen Daten-Marktplatz aufzubauen und damit sowohl technische als ökonomische Vorteile für die Beteiligten zu schaffen. Technische Vorteile werden vor allem in folgenden Punkten gesehen: • Anbieter und Entwickler der IoT-Geräte benötigen kein Backend-System mehr, also keine eigens entwickelte Plattform zur Verwaltung der IoT-Devices und der rückgemeldeten Daten. • Durch die Verwendung eines einheitlichen Marktplatzes müssen für die Einbindung der Geräte standardisierte Programmierbibliotheken durch den Marktplatz angeboten werden, damit ein einfacher und schneller Zugang gewährleistet ist. Dies erleichtert und beschleunigt die Entwicklung eines IoT-Device-Herstellers, die Sensoren in die Plattform einzubinden und die Daten zügig zu monetarisieren. Die Time-to-Market-Spanne ist somit wesentlich kürzer, als wenn die Datenanbieter die gesamte Infrastruktur inklusive Anbindung selbst entwickeln müssten. • Ein standardisierter Marktplatz, der alle möglichen Daten unterschiedlicher IoT-Devices konsolidiert erhöht die Sichtbarkeit der Daten. Folgende ökonomische Vorteile werden von den Autoren genannt: • Eine erhöhte Sichtbarkeit der Daten führt auch zu einer erhöhten Marktreichweite und damit zu mehr Umsatz für die einzelnen Datenanbieter. Ähnlich wie dies schon bei Handy-App-Stores durch die standardisierten, aber zentral verwalteten App-Stores von Google und Apple vorgelebt wurde. • End-User könnten die IoT-Devices kostenlos nutzen, wenn sie im Gegenzug hierzu wiederum ihre durch diese Nutzung generierten Daten dem Marktplatz zur Verfügung stellten. Der hier vorgestellte IoT-Marktplatz stellt aber bisher nur eine Austauschplattform zwischen den Modellerstellern und den Datenanbietern dar. Zwar ist vorstellbar, dass über einen

188

C. Lanquillon und S. Schacht

derartigen Marktplatz nicht nur die Daten selbst, sondern auch die daraus abgeleiteten Modelle gehandelt werden, da dies am Ende auch nur Daten sind. Dieser Aspekt wurde jedoch in der Ausarbeitung der drei Autoren nicht berücksichtigt. Die Blockchain stellt auch hier den Backbone zwischen den Anbietern und Nachfragern dar. Im konkreten Beispiel wurden unterschiedliche Blockchain-Typen begutachtet. Einerseits wurde gerade aufgrund des IoT-Kontexts IOTA, aber auch Hyperledger und andere permissioned Blockchains wie Corda in die Evaluierung aufgenommen. Andererseits wurde aufgrund der Tatsache, dass es sich bei diesem Marktplatz um einen öffentlichen Marktplatz handeln soll, der gewissermaßen einen Standard für den Austausch von IoT-Daten darstellen soll, Ethereum als Basis für diesen Marktplatz gewählt. Bezogen auf den in diesem Kapitel vorgestellten Ordnungsrahmen, gibt es in dem IoTMarktplatz die Rolle der Datenanbieter und der Modellersteller sowie die IT-InfrastrukturAnbieter. Modellvalidierer, Modellnutzer und Aufgabensteller sind in dieser Ausbaustufe nicht explizit vorhanden, da noch keine ML-Modelle über diese Backend-Infrastruktur ausgetauscht werden. Da es sich hier um einen Daten-Marktplatz handelt, der direkt die Daten aus den Geräten zum Handel freigeben soll, müssen diese Daten auch direkt in der Plattform gespeichert werden. Auch hier treffen die Restriktionen über die Datenmenge, die in der öffentlichen Blockchain gespeichert werden können. Dementsprechend wurde auch hier ein dezentrales Speichernetzwerk gewählt. Zur Anwendung kam hier nicht IPFS, sondern das in Ethereum sehr stark integrierte System Swarm. Die Plattform muss drei wesentliche Aspekte bereitstellen. Sie muss die Datenspeicherung direkt von den IoT-Devices in das dezentrale Netzwerk zulassen, sie muss Werkzeuge zum Verwalten alter und Anbinden neuer IoT-Devices bereitstellen und zu guter Letzt muss eine Incentivierung für den stabilen Betrieb des Netzes etabliert werden. Özyilmaz et al. gehen davon aus, dass eine Incentivierung nicht für die Nutzung des Marktplatzes an sich notwendig ist, sondern dass diese ausschließlich für die Betreiber relevant ist, also für die IT-Infrastruktur-Anbieter. Eine Incentivierung kann als Kryptowährung entweder durch die Verwendung der Währung Ether der Ethereum-Blockchain, oder mittels eigens für die Plattform definierten Token auf Basis des Standards ERC201 vorgenommen werden. Bezogen auf die Verwaltungsfunktionen ist der Smart Contract mit den Funktionen zum Registrieren eines neuen Gerätes, des Hochladens neuer Daten, des Suchens nach passenden Daten aus Sicht des Modellerstellers und mit der Abwicklung der Zahlung ausgestattet. Die Speicherung im dezentralen Speichernetzwerk Swarm ist in diesem Marktplatz ein zentraler Punkt, denn die Daten können hier nicht transparent für alle öffentlich zur Verfügung stehen, da sonst kein Modellersteller mehr Interesse hätte, für diese Daten eine Zahlung zu leisten. Dementsprechend schlagen die Autoren vor, die Daten mittels symmetrischer Verschlüsselung zu verschlüsseln und im Swarm abzulegen. Die Adresse auf das 1 Der ERC20 Standard ermöglicht die Implementierung eigener Kryptowährungen auf der Blockchain

Ethereum.

5 Der Analytics-Marktplatz

189

verschlüsselte Datenpaket, die ähnlich wie bei IPFS aus einem Hash-Wert besteht, wird wiederum im Smart Contract hinterlegt, sodass eine Verknüpfung zwischen Datenanbieter und den Daten in Swarm vorhanden ist. Der Schlüssel zum Entpacken der Daten darf in dem Beispiel nicht im Smart Contract abgelegt werden, da ihn sonst jeder einsehen könnte und damit der Marktplatz ad absurdum geführt würde. Deswegen ist der Vorschlag, den Schlüssel zum Entschlüsseln im IoT-Device direkt zu hinterlegen und im Gerät noch weitere Funktionen für die Übermittlung des Schlüssels zu implementieren. Wenn nun ein Modellersteller diese Daten kaufen möchte, muss er über den Smart Contract eine Anfrage stellen. Diese Anfrage geht mit dem öffentlichen Schlüssel, der in der Ethereum-Blockchain die Adresse des anfragenden Modellerstellers darstellt, an das IoTDevice. Aufgrund der eingebetteten Funktionen kann nun das Gerät anhand des öffentlichen Schlüssels des Empfängers und seinem privaten Schlüssel den für die symmetrische Entschlüsselung notwendigen dritten Schlüssel erstellen und erzeugt mit diesen Informationen eine Transaktion die als Adressaten den Modellersteller hat. Auf diese Weise kann der notwendige Schlüssel zum Entpacken der Daten mittels des Smart Contracts erst dann ausgeliefert werden, wenn der Modellanbieter auch tatsächlich eine Zahlung dafür geleistet hat. Der hier dargestellte Ansatz zeigt auf, wie prototypisch ein Marktplatz mittels der Distributed-Ledger-Technologie und einem dezentralen Speichernetzwerk implementiert werden kann. Aber auch hier gilt, dass noch einige Forschungsaktivitäten zu leisten sind, damit ein derartiger Marktplatz produktiv genutzt werden kann. Vor allem sind hier die Themen der Verschlüsselung zu nennen. Da nicht nur der Austausch des symmetrischen Schlüssels das Problem darstellt, sondern auch Lösungen für die Anreizsysteme entwickelt werden müssen, die gewährleisten, dass die Schlüssel nicht kostenfrei von den Modellersteller weitergegeben werden. Die Idee, die Verwaltung des symmetrischen Schlüssels in den IoT-Devices durchzuführen, setzt aber auch voraus, dass diese solange wie die Daten verkauft werden sollen, auch tatsächlich online sind, da sonst der symmetrische Schlüssel nicht mehr verfügbar ist. Ein Verkauf von großen Zeitreihen in Form von historischen Daten wird somit zusätzlich erschwert. Des Weiteren sieht das hier vorgestellte System keine Echtzeitanalysen vor. Die verfügbaren Daten stehen nur als Datenpakete und nicht als Datenstrom für die Nutzung bereit.

5.5.3

Fitchain

Ein weiterer Ansatz, einen Analytics-Marktplatz mittels der Distributed-Ledger-Technologie umzusetzen, wird von dem privatwirtschaftlichen Startup Fitchain verfolgt [3]. Im Gegensatz zu den hier bisher vorgestellten Ansätzen ist vor allem die Fokussierung auf die Datensicherheit hervorzuheben, da das Konzept von Fitchain vorsieht, dass die Daten nie die Rechner des Dateneigners verlassen, also häufig die Unternehmen selbst. Vielmehr werden die Modelle

190

C. Lanquillon und S. Schacht

von den Modellanbieter auf sogenannten Steckbriefen, welche Datenrepräsentationen der im Original zu schützenden Daten sind, zunächst in Form von Machine-Learning-Pipelines entwickelt und über den Fitchain-Marktplatz an die Datenanbieter geliefert, wo diese dann die Pipelines in sogenannten Fitchain-Pods ausführen, um trainierte Modelle zu erzeugen. Dreh- und Angelpunkt in diesem Ansatz ist nicht mehr der Smart Contract, sondern eine Software, der Fitchain-Pod, der von allen Beteiligten ausgeführt werden kann. Dieser führt den Lernprozess lokal beim Dateneigner aus und kommuniziert mit der Blockchain. Bei dem Ansatz stellen insbesondere die Modellerstellung auf Daten, die die MLExperten zur Wahrung des Datenschutzes nicht direkt einsehen können, und das Bestreben, Unternehmen einen Zugang zu ML-Experten zu ermöglichen, ohne vertrauliche Informationen des Unternehmens preiszugeben, ein große Herausforderung dar. Umsetzbar ist dies nur, wenn drei wesentliche Aspekte berücksichtigt werden. Sicherheit, definierte Anerkennungsregeln und höchstmögliche Transparenz. Datensicherheit kann nur dann gewährleistet werden, wenn die Daten die Unternehmensgrenzen nicht verlassen. Dies hat zur Konsequenz, dass die ersten Machine-LerningPipelines auf Rechnern des Unternehmens für die Modellerstellung ausgeführt werden müssen. Genau genommen bedeutet dies, dass von Fremden (ML-Experten) definierter Programmcode im Unternehmen auf vorhandenen Daten ausgeführt wird. Dieser eingeschleuste Code kann aber auch Schadprogramme, wie Viren oder Trojaner enthalten. Dies muss unbedingt durch geeignete Mechanismen unterbunden werden. Im Rahmen des FitchainMarkptplatzes werden alle Machine-Learning-Pipelines, die in Unternehmen ausgeführt werden sollen, in einer gekapselten Umgebung des Fitchain-Pods ausgeführt. Schädlicher Programmcode hat somit keine Möglichkeit, tatsächlich Schaden anzurichten. Unter definierten Anerkennungsregeln werden einerseits die Anwendung des Algorithmus, wie er dem Unternehmen zur Verfügung gestellt wird, ohne jegliche Veränderung durch das Unternehmen selbst, und andererseits auch die Transparenz, dass das Unternehmen erkennen kann, welche Aktivitäten durch den Algorithmus ausgeführt wurden, verstanden. Es ist wichtig, dass der Modellersteller, der immer noch Eigner des Modells ist, auch nach der Modellerstellung sicherstellen kann, dass sein Algorithmus genau so funktioniert, wie er es beabsichtigt hat. Höchstmögliche Transparenz bedeutet in dem Kontext, dass einerseits das Unternehmen Klarheit über Inhalt und Ablauf des Algorithmus haben muss, und andererseits auch nachvollzogen werden muss, welcher Algorithmus mit welchen Daten in welchem Kontext verwendet wurde, damit eine Bewertung für die Anwendbarkeit in einem produktiven Umfeld überhaupt erst möglich ist. Darüber hinaus können Modelle, wie jedes andere wertvolle Gut, von anderen Organisationen und ML-Experten gehandelt und genutzt werden. Rückverfolgbarkeit und Reputation sind zwei wesentliche Anforderungen an jeden Software-Service, der mithilfe mehrerer Parteien erstellt wird, die an verschiedenen geografischen Standorten verteilt sind. Der Datenanbieter erstellt einen Steckbrief, in dem das zu lösende Problem definiert ist und auch die benötigten Daten, die zur für die Modellerstellung herangezogen werden

5 Der Analytics-Marktplatz

191

sollen. Für die Bereitstellung der Daten müssen diese nicht durch einen Export an alle Beteiligte übermittelt werden, vielmehr greift ein Programm (Fitchain-Pod) mittels einer benutzerfreundlichen Browser-Extension auf die definierte Datenquelle zu. Dies bedeutet, dass die Daten das Unternehmen bzw. den Datenanbieter nicht verlassen und damit sicherheitsrelevante Aspekte berücksichtigt werden. Damit die Entwickler der MachineLearning-Pipelines aber trotzdem die Möglichkeit haben, diese auch außerhalb des Unternehmens anzuwenden, stellt das Unternehmen über den Pod eine Datenvorlage bereit. Diese enthält weder die Originaldaten noch sensiblen Informationen, die es jedem ermöglichen würden, die ursprüngliche Datenquelle zu rekonstruieren. Dies ist eine wesentliche Voraussetzung dafür, dass jede Organisation ihre Projekte öffentlich einreichen kann und trotzdem nur ein abstrahiertes Abbild ihrer Daten veröffentlicht. Zusätzlich besteht die Möglichkeit, ein Anreizsystem in Form einer Belohnung bei der Bereitstellung eines Steckbriefes aufzusetzen, damit Modellersteller ein Interesse haben, für dieses Problem zu arbeiten. Die Belohnung dient aber nicht nur dem Modellersteller, sondern auch dem Modellvalidierer, der die Qualität und Korrektheit des Modells überprüft. Über den Fitchain-Pod werden die originalen Daten für das Training angesteuert. Basierend auf den angebundenen Daten kann das Unternehmen mit den bereitgestellten Algorithmen ein Modell erstellen. An dieser Stelle kommt dann auch die Blockchain ins Spiel, die den gesamten MachineLearning-Prozess zunächst im Sinne der Nachvollziehbarkeit unterstützt. Denn für jede Aktivität wird ein Trace in der angeschlossenen Blockchain abgelegt, damit nachvollzogen werden kann, welcher Algorithmus, wann in welcher Version, mit welchen Daten angewendet wurde. Wichtig für das Verständnis ist, dass die firmeninternen Originaldaten nicht verändert werden und auch nicht aus dem Unternehmen exportiert werden. Dies bedeutet, dass das Unternehmen zu jeder Zeit die absolute Hoheit über die Daten hat und somit auch Compliance-Regeln, wie die europäische General Data Protection Regulation (GDPR), einfach im Unternehmen umgesetzt werden können. An diesem Ansatz ist vor allem interessant, dass nicht alleine auf die Blockchain mittels Smart Contracts zurückgegriffen wird, sondern dass zusätzlich ein Programm die Arbeit mit den Algorithmen und den Daten in abgesicherten Unternehmensnetzen durchführt. Die im Fitchain-Pod implementierten Sicherheitsmechanismen bieten Garantien sowohl für die Organisation als auch für den ML-Experten. Eine Blockchain-Komponente verbindet alle Prozessschritte und protokolliert alle Aktivitäten der am Prozess beteiligten Akteure und bietet einen manipulationsfreien, reputationsbasierten Mechanismus für Datenanbieter, Modellersteller, Modellvalidierer und trainierte Modelle. Daten, die Fähigkeit Modelle zu erstellen und die erlernten Modelle sind handelbare Güter auf dem Fitchain-Marktplatz. Dieser ist somit die dezentrale, sichere und nachvollziehbare Fabrik für maschinelles Lernen.

192

5.6

C. Lanquillon und S. Schacht

Zusammenfassung und Ausblick

Ein integrierter Analytics-Marktplatz hat ein enormes Potenzial: Er kann die Ressourcen verschiedener Anbieter bündeln und die Lösung analytischer Fragestellungen mithilfe maschineller Lernverfahren auf transparente und effiziente Art und Weise ermöglichen, wodurch sich letztlich auch dank des großen Automatisierungspotenzial bestehende Prozesse, Produkte und Dienstleistung verbessern und neue Geschäftsmodelle umzusetzen lassen. Durch die offenen Datenmarktplätze als Teil der Plattform werden Daten demokratisiert, sodass die Dominanz der großen Internetkonzerne gebrochen werden. Dies fördert die Entwicklung transparenter und effizienter maschineller Lernverfahren und Anwendungen. Damit allerdings nicht gleich neue Machtpositionen geschaffen werden, sollte ein integrierter Analytics-Marktplatz dezentral ohne Intermediäre aufgebaut werden. Die Blockchain-Technologien bieten dafür als Infrastruktur zahlreiche Konzepte und Anknüpfungspunkte. Vertrauen in die angebotenen, verwendeten und erstellten Ressourcen kann etabliert werden durch Transparenz und Unveränderlichkeit sowie durch sogenannte Smart Contracts, die als offener Programmcode Beziehungen zwischen Parteien formalisieren und überwachen. Letztere ermöglichen als Software auch einen starken Automatisierungsgrad. Durch bestehende Vergütungssysteme können Anreize für die aktive Teilnahme am Analytics-Marktplatz gesetzt werden. Die bekannte Blockchain-Technologien lassen sich jedoch nicht ausnahmslos direkt übertragen. Machine-Learning-Anwendungen haben insbesondere aufgrund der großen Datenmengen, rechenintensiver Prozesse und hoher Anforderungen an den Datenschutz besondere Herausforderungen. Die tatsächliche Speicherung der Daten und Modelle wird beispielsweise außerhalb der Blockchain erfolgen müssen und auch die Ausführung von Lernprozessen ist aktuell nicht innerhalb der Blockchain sinnvoll. Deshalb muss einerseits auf zusätzliche Konzepte zurückgegriffen werden, wie etwas das InterPlanetary File System (IPFS), und andererseits müssen auch neue Konzepte entwickelt werden. Zu den neuen Konzepten gehören die verschlüsselten Modell-Container, die leicht verschiebbar über das Netzwerk auf unterschiedlichen Infrastrukturen in einer stark gekapselten, sicheren Umgebung (Sandbox-Prinzip) ausgeführt werden können, und neben der Modellerstellung auch die Modellvalidierung und Modellanwendung unterstützen müssen. Gerade der letzte Punkte und auch der Überblick der aktuellen Ansätze zeigen, dass es zwar einige vielversprechende grundlegende Konzepte gibt, dass aber auch noch einige offene Fragen zu klären sind. Zudem sind einige wichtige Komponenten noch in der Entwicklung und das notwendige Zusammenspiel wird noch erprobt. Der Organisationsrahmen für den integrierten Analytics-Marktplatz kann dabei helfen, die zukünftige Umsetzung zu strukturieren und gleichzeitig die konzeptionelle Basis dafür zu liefern.

5 Der Analytics-Marktplatz

193

Literatur 1. Davenport, T.H.: Analytics 3.0. Harv. Bus. Rev. 91(12), 64–72 (2013) 2. Ehrsam, F.: Blockchain-based machine learning marketplaces (2018). https://medium.com/ @FEhrsam/blockchain-based-machine-learning-marketplaces-cb2d4dae2c17. Zugegriffen: 10. Juni 2019 3. Gadaleta, F., Gerits, D.: Amethix – fitchain – the decentralized machine learning factory (2018). https://github.com/fitchain/technical-primer. Zugegriffen: 23. Febr. 2019 4. Graepel, T., Lauter, K., Naehrig, M.: Ml confidential: machine learning on encrypted data. In: Proceedings of the 15th International Conference on Information Security and Cryptology, ICISC’12, S. 1–21. Springer, Berlin (2013). https://doi.org/10.1007/978-3-642-37682-5_1 5. Humm, B., Wietek, F.: Architektur von data warehouses und business intelligence systemen. Informatik-Spektrum 28(1), 3–14 (2005). https://doi.org/10.1007/s00287-004-0450-5 6. Kurtulmus, A.B., Daniel, K.: Trustless machine learning contracts; evaluating and exchanging machine learning models on the Ethereum blockchain (2018) 7. Özyilmaz, K.R., Dogan, M., Yurdakul, A.: IDMoB: IoT Data Marketplace on Blockchain. In: 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), S. 11–19. IEEE (2018). https://doi.org/10.1109/CVCBT.2018.00007 8. Tonelli, R., Lunesu, M.I., Pinna, A., Taibi, D., Marchesi, M.: Implementing a microservices system with blockchain smart contracts. In: 2019 IEEE International Workshop on Blockchain Oriented Software Engineering (IWBOSE), S. 22–31 (2019) 9. Zhao, J., Mortier, R., Crowcroft, J., Wang, L.: Privacy-preserving machine learning based data analytics on edge devices. In: Proceedings of the 2018 AAAI/ACM Conference on AI, Ethics, and Society, AIES ’18, S. 341–346. ACM, New York (2018). https://doi.org/10.1145/3278721. 3278778

DLT im Energiesektor – Wie blockchainbasierte Werkzeuge und maschinelles Lernen ein dekarbonisiertes Energiesystem möglich machen Thomas Brenner

Zusammenfassung

Im vorliegenden Kapitel werden die Einsatzmöglichkeiten von DLT im Energiesektor skizziert und anhand des Allgäu Microgrid Projektes werden zahlreiche relevante Prozesse vorgestellt. Der Weg von hochaufgelösten Erzeugungs- und Verbrauchsdaten vom Zähler über ein Blockchaingateway bis zur Ausführung der Smart Contracts wird detailliert erläutert. Die Rolle der Kundenschnittstelle für einen derartigen lokalen Energiemarkt wird ebenfalls diskutiert. Die Bedeutung der Technologie für die Transformation zu einem vollständig dekarbonisierten Energiesystem wird anhand mehrerer Einsatzgebiete verdeutlicht, wie beispielsweise der Quartiersversorgung, regionaler Stromprodukte oder der Vermarktung von Erzeugungsanlagen. Anschließend wird das Zusammenwirken von DLT mit Ansätzen aus dem maschinellen Lernen anhand dreier Beispiele vorgestellt. Dabei zeigt sich die zentrale Rolle der Blockchaintechnologie als Datendrehscheibe und dezentrale Applikationsplattform, auf deren Basis Algorithmen für maschinelles Lernen die vorliegenden Daten verarbeiten und auswerten können.

6.1

Dezentrales Energiesystem – verteiltes IT-Netzwerk

Das Energiesystem ist weltweit seit über zwanzig Jahren in einem dauerhaften und systemverändernden Transformationsprozess begriffen. Durch den Aufstieg der Erneuerbaren Energien, der anfangs politisch getrieben wurde und der sich mittlerweile aus wirtschaftlichen Gründen fortsetzt, verändert sich die Art und Weise, wie wir Energie heute und in Zukunft nutzen, signifikant. Auf der Erzeugungsseite verdrängen dezentrale PhotovoltaikWind- und Biomasseanlagen zunehmend fossile Großkraftwerke. Im Jahr 2018 wurden T. Brenner (B) CTO, OLI Systems GmbH, Stuttgart, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 S. Schacht und C. Lanquillon (Hrsg.), Blockchain und maschinelles Lernen, https://doi.org/10.1007/978-3-662-60408-3_6

195

6

196

T. Brenner

knapp 38 % des deutschen Stromes aus solchen Anlagen erzeugt, während es vor zehn Jahren noch rund 15 % waren [30]. Was in Deutschland mit dem Ausstieg aus der Kernenergie begonnen hat, findet in den Planungen zum Kohleausstieg seine Fortsetzung für die kommenden Jahrzehnte. Dieses Phänomen ist jedoch nicht nur auf Deutschland beschränkt, weltweit lassen sich ähnliche Entwicklungen in vielen Ländern der Welt diagnostizieren [17]. Schaut man auf gesamten Primärenergieverbrauch der Bundesrepublik Deutschland, tragen Erneuerbare Energien allerdings erst 14 % zur Bedarfsdeckung bei [30], 86 % des heutigen Verbrauches kommen nach wie vor aus klassischen fossilen Energiequellen. Sowohl der technische Fortschritt auf der Anlagenseite als auch die Notwendigkeit, den Ausstieg aus fossiler Energieerzeugung bis zur Mitte des Jahrhunderts zu organisieren, tragen zu einem massiven Strukturwandel hin zu dezentralen, fluktuierenden und erneuerbaren Energiequellen bei. In den folgenden Kapiteln soll gezeigt werden, auf welche Weise blockchainbasierte Werkzeuge einen wesentlichen Beitrag dazu leisten können, diese Transformation technisch und wirtschaftlich erfolgreich zu gestalten.

6.1.1

Herausforderungen

Die Herausforderungen, weltweit das existierende Energiesystem im Sinne der drei „D“ – „Digitalisierung, Dezentralisierung und Dekarbonisierung“ – umzugestalten sind vielfältig: • Volatiliät Insbesondere Sonne und Wind sind sowohl im Verlauf eines Tages als auch im Verlauf eines Jahres nicht gleichmäßig vorhanden, sondern in ihrem Energieangebot stark schwankend und kaum steuerbar. Dies führt dazu, dass die Aufgabe Angebot und Nachfrage im Stromnetz auszubalancieren, zwangsläufig aufwendiger und komplexer wird. Erträge müssen mit hoher zeitlicher und räumlicher Auflösung genau prognostizierbar sein und Abweichungen müssen innerhalb von Minuten ausgeglichen werden, um die Versorgung stabil zu halten. Außerdem müssen Verbraucher zunehmend flexibel agieren können, um auf Erzeugungsspitzen in beide Richtungen – positiv und negativ – reagieren zu können. Erzeugungsanlagen und flexible Verbraucher müssen dafür datentechnisch transparent sein. Nur wenn der Zustand der Anlagen genau bekannt ist, können Anlagenund Netzbetreiber adäquat reagieren. • Kleinteiligkeit Im Vergleich zu konventionellen Großkraftwerken, die typischerweise Spitzenleistungen von einigen hundert Megawatt (1 MW = 1.000.000 W) bis zu einigen Gigawatt (1 GW = 1.000.000.000 W) erbringen können, sind Erneuerbare Energieanlagen typischerweise um einige Größenordnungen kleiner. Konventionelle Steuerung durch Menschen oder etablierte Leittechnik sind oftmals technisch und wirtschaftlich nicht umsetzbar.

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

197

• Sektorenkopplung Nicht nur aufgrund der ambitionierten Klimaziele, sondern auch aus Effizienzgründen ist die sogenannte Sektorenkopplung für viele Anwendungen, welche bisher kaum oder gar nicht mit dem Stromsektor in Berührung gekommen sind, die erste Wahl. Insbesondere im Wärmesektor kann der Einsatz von „Power-to-X“-Technologien, wie etwa von Wärmepumpen emissionsfrei Wärme für Gebäude und Warmwasser bereitstellen. Überschüssiger Strom kann durch Power-to-Gas oder Power-to-Liquid in andere Energieformen wie beispielsweise in Wasserstoff, Methan, oder Methanol überführt und auf diese Weise langfristig gespeichert werden. Derartige Anwendungen ermöglichen damit auch die Dekarbonisierung von Industrieprozessen oder dem Flugverkehr, bei dem Batterietechnologie nicht das erste Mittel der Wahl ist [25]. Elektromobilität verlagert den Teil des Energieverbrauches, der bisher primär durch Benzin und Diesel gedeckt wurde, ebenfalls in den Stromsektor und schafft damit neue Herausforderungen für das Stromnetz beim Laden der Fahrzeuge. In Abb. 6.1 ist ein primär auf Erneuerbarem Strom basierendes Energiesystem prototypisch dargestellt.

Abb. 6.1 Schema eines dezentralen Energiesystems inklusive Sektorenkopplung

198

T. Brenner

• Marktdesign Das aktuell gültige Marktdesign im Stromsektor ist noch unzureichend auf die Systemrelevanz dezentraler Anlagen vorbereitet [1]. Die Erbringung von Systemdienstleistungen, welche Frequenz- oder Spannungsschwankungen in den Stromnetzen ausgleichen sollen, aus solchen Anlagen ist schwierig, auch wenn die Marktrolle des Aggregators in den vergangenen Jahren an Relevanz gewonnen hat. Oftmals sind auch aktives Lastmanagement oder die Nutzung von Speichern zur Erbringung mehrerer Dienstleistungen (z. B. Eigenverbrauchsmaximierung, Lastspitzenkappung und Regelleistungserbringung für Netzbetreiber) aus einer einzelnen Anlage oder einem virtuellen Anlagenpool entweder technisch oder wirtschaftlich nicht möglich. Peer-to-Peer-Handel zwischen Nachbarn oder innerhalb eines Stadtquartieres auf Basis lokaler Strommärkte ist entweder im Pilotstatus [8, 11, 23] oder wird aufgrund mangelnder Wirtschaftlichkeit (noch) nicht im Realbetrieb umgesetzt. • Regulatorik Der aktuelle regulatorische Rahmen im Energiemarkt ist nur teilweise auf den flexiblen Einsatz kleiner Anlagen vorbereitet. Viele der heute in Europa geltenden Gesetze und Richtlinien – allein in Deutschland sind das über 12.000 Gesetze und Normen [31] mit Bezug zum Energiesektor – sind nicht für eine dezentrale und volatile Energiewelt konzipiert worden, was deren Anwendung heutzutage stark erschwert und Innovationen an der Umsetzung hindert. Stellvertretend seien hier die Behandlung von Speichern bei Netzentgelten und Umlagen [6] oder die Versorgung von Stadtquartieren mit dezentralen Erzeugungsanlagen genannt [18]. Hier bedarf es einerseits vereinfachter Möglichkeiten zur Erprobung von innovativen Werkzeugen im Realbetrieb, sowie andererseits einer grundlegenden Anpassung des bestehenden Regulierungsrahmens an die durch volatile Erzeuger und Sektorenkopplung sich rapide wandelnde Struktur des Energiesektors.

6.1.2

DLT und neutrale lokale Märkte als Lösungsansatz

An welchen Stellen können nun Blockchaintechnologien, beziehungsweise weiter gefasst Distributed-Ledger-Technologien (DLT) dazu beitragen, die Transformation des Energiesystems zu beschleunigen und wirtschaftlich effizienter zu gestalten? Betrachtet man die informationstechnische Architektur eines DLT-Systems fällt auf, dass dessen Struktur zu der des dezentralen Energiesystems starke Parallelen aufweist. Prozesse finden verteilt und direkt bei den Teilnehmern statt, eine koordinierende Zentralinstanz existiert in beiden Fällen nicht, wie in Abb. 6.2 skizziert. Die Anforderungen an die Hardware sind niedrig, anstelle von Industriecomputern kann auch mit Kleinstcomputern oder Embedded Hardware gearbeitet werden.

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

199

Abb. 6.2 Architektur eines zentralen (A), dezentralen (B) und verteilten (C) Systems. (Nach [5])

Prozesse zwischen mehreren Marktteilnehmern können mittels DLT gleichberechtigt ohne Mittelsmann abgewickelt werden. Dies ist insbesondere bei der Koordination komplexer Prozesse zwischen Endkunden, Anlagenbetreibern, Netzbetreibern und Regulierungsbehörden für den Energiesektor relevant. Der Einsatz von Smart Contracts – verteilt laufendem Programmcode auf der Blockchain – ermöglicht außerdem die verhältnismäßig einfache Automatisierung von Vorgängen mit klar definiertem Regelwerk. Als Beispiele seien hier der Energiegroßhandel [22], der Betrieb lokaler Energiehandelsmärkte oder der Abruf von Regelenergie aus einem virtuellen Speicher [27] genannt. Für den P2P-Handel spielt zusätzlich die Möglichkeit, auch kleinteilige Transaktionen zu geringen Kosten darstellen zu können, eine Rolle. Sind die Kosten für einen Kleinsthandel im einstelligen Eurobereich zu hoch, werden diese Szenarien ansonsten unwirtschaftlich. Bei Prozessen wie zum Beispiel der anlagenscharfen Dokumentation der Herkunft von Strom spielt der Transparenzaspekt von DLT-Systemen die entscheidende Rolle. Produktion, Handel und Verbrauch können für alle Marktteilnehmer nachvollziehbar und im Vergleich zum Stand der Technik sehr fälschungssicher dokumentiert werden [13]. Dies kann dazu genutzt werden, Endkunden eine größere Transparenz über das Produkt anzubieten, wie es etwa durch den Einzelverbindungsnachweis im Telekommunikationssektor bereits seit Jahren Standard ist. Andererseits lassen sich perspektivisch auch Handelsinstrumente wie z. B. Grün- oder Regionalstromzertifikate [29] damit wesentlich einfacher erstellen und handeln. „Double spending“ – der Verkauf eines Zertifikates an zwei Abnehmer – ein in Europa aktuell sehr betrugsanfälliger Prozess [7] ist durch die Architektur einer Blockchain praktisch ausgeschlossen. Als „Oracle“ werden im Bereich der DLT-Anwendungen externe Datenquellen bezeichnet, welche Daten in eine Blockchain schreiben oder einem Smart Contract zur Weiterverarbeitung zur Verfügung stellen können [10]. Dies können im Energiesektor die Anlagen

200

T. Brenner

selbst (z. B. Wechselrichter, Wärmepumpen oder Ladesäulen), Stromzähler oder IoT-Messund Sensortechnik im Verteilnetz sein. Es ist an dieser Stelle wichtig zu betonen, dass keine DLT-Technologie per se für die Korrektheit dieser externen Datenquellen sorgen kann. Gelangen falsche oder unvollständige Daten in die Blockchain, werden dort nur formale Kriterien geprüft. Eine inhaltliche Überprüfung der Daten kann Gegenstand einer weiteren Anwendung sein (siehe Abschn. 6.3.3), ist aber nicht Teil der Blockchainarchitektur selbst. Vereinfacht gesagt: Falsche Daten bleiben auch in einer Blockchain falsch. Die Frage des Energieverbrauches von Blockchainanwendungen ist insbesondere im Energiekontext besonders bedeutend und technisch sehr eng an die Verwendung des Konsensmechanismus gekoppelt. Während etwa die öffentliche Ethereum-Blockchain aktuell im Durchschnitt 26 kWh pro Transaktion verbraucht [12] (dies enspricht in Deutschland Kosten von ca. 7,80 e), kommen Anwendungen auf „permissioned blockchains“, bei denen anstelle von Proof-of-Work, oftmals Proof-of-Authority als Konsensmechanismus zum Einsatz kommt, mit einem Bruchteil der Energie zur Validierung aus und die Kosten liegen unter 0,1 Cent pro Transaktion [14]. Die in verschiedenen aktuellen Studien, zum Beispiel denen des Bundesverbandes der Energie- und Wasserwirtschaft (bdew) [2], der Deutschen Energieagentur [9] und der Forschungsstelle für Energiewirtschaft [15] untersuchten Anwendungsfälle sind zahlreich. Im Bereich Handel sind dies etwa die Themen Großhandel, P2P-Handel zwischen Kunden eines Lieferanten, die Allokation von Netzkapazitäten und Mieterstromlösungen. Auch im Bereich Marktkommunikation lassen sich geeignete Anwendungsfälle identifizieren, etwa bei der Abrechnung von Netzentgelten und Umlagen oder beim automatisierten Lieferantenwechsel. Auch Anwendungen im Bereich Elektromobilität, im Energiemanagement von Gebäuden und Anlagen, sowie im Bereich Zertifizierung von Herkunftsnachweisen stellen potenzielle Anwendungsfelder der Blockchaintechnologie dar. Eine detaillierte Analyse dieser Fälle findet sich für den interessierten Leser in den oben genannten Studien, welche frei zugänglich sind. Im folgenden Kapitel wird anhand des „Allgäu Microgrid“ Projektes detailliert der Bereich Peer-to-Peer-Handel erläutert, sowie mittelbar die Themen „Zertifizierung von Herkunftsnachweisen“ und „Mieterstrom“ näher beschrieben.

6.2

Von der Anlage zum Kunden – Das Allgäu Microgrid

6.2.1

Status Quo und Ziele

Das Ziel des „Allgäu Microgrid“ Projektes ist die Implementierung eines lokalen Strommarktes unter dem Dach des Allgäuer Überlandwerkes als Stromlieferant, Verteilnetzbetreiber und Bilanzkreisverantwortlichem. Das Pilotprojekt dient einerseits dazu, Erfahrungen mit DLT-Anwendungen im Realbetrieb zu sammeln, andererseits aber auch dazu, eine Gesamtarchitektur zu entwerfen, die aus regulatorischer und technischer Sicht in den

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

201

Realbetrieb übertragbar ist. Fünf Teilnehmer wurden für den Testbetrieb ausgewählt. Dabei war für den Betrieb des lokalen Marktes wichtig, dass deren Erzeugungs- und Verbrauchsprofile möglichst vielfältig sind. Für das Allgäu Microgrid wurden deshalb Haushalte mit Photovoltaikanlage, mit flexiblen Verbrauchern (Wärmepumpe), reine Verbraucherhaushalte und auch ein Gewerbebetrieb in die „Solar Community“ integriert. Das Erzeugungs- und Verbrauchsverhalten der Teilnehmer sollte unterschiedlich sein, um einen aktiven Handel im lokalen Markt zu ermöglichen und Clustereffekte zu vermeiden. Ein weiteres Ziel des Projektes ist es, den lokalen Markt inklusive der dazu notwendigen Hardware dezentral mittels eines Smart Contracts zu gestalten und ohne zentrale Plattform zu realisieren. Im Hinblick auf die Umsetzung im Realbetrieb bietet eine dezentrale Architektur mehrere Vorteile: • Durch den Verzicht auf einen zentralen Server wird das Gesamtsystem wesentlich ausfallsicherer. Selbst wenn mehrere Knoten des Blockchainnetzwerkes ausfallen, sind einerseits die Marktdaten mehrfach redundant vorhanden, andererseits gewährleisten die verbleibenden Knoten den reibungslosen Weiterbetrieb der Anwendung. • Der Betreiber des lokalen Marktes kann gleichzeitig als Anbieter und Nachfrager auftreten, ohne in einen Interessenskonflikt zu geraten. Der implementierte Smart Contract ist für alle Marktteilnehmer derselbe, eine Manipulation zugunsten des Betreibers ist ausgeschlossen. • Durch die Schaffung eines neutralen, standardisierten Marktplatzes wird die Einbindung von weiteren Teilnehmern – insbesondere von Erzeugungsanlagen unterschiedlicher Betreiber – wesentlich erleichtert. Die Marktlogik wird im Projekt komplett auf Basis des Smart Contracts abgebildet. Konkret bedeutet dies, dass sowohl die Regeln bezüglich Bietverfahren, Preisbildung und Markträumung dort festgelegt sind, als auch die automatisierte Ausführung des Verfahrens komplett über den Contract erfolgt. Wesentlich für das Projekt ist es ebenfalls, den Endkunden eine einfach zugängliche und intuitiv verständliche Schnittstelle zum lokalen Markt anzubieten. Über eine Smartphone-App hat der Endkunde Zugang zu seinen Erzeugungs- und Verbrauchsdaten. Die aktive Interaktion mit dem lokalen Markt findet ebenfalls über die Smartphone-App statt. Die Benutzeroberfläche unterscheidet dabei nicht zwischen Daten, die aus konventionellen Datenbanken bereitgestellt werden und solchen, die aus der Blockchain kommen.

6.2.2

Architektur

Die Erfassung von Leistungs- und Stammdaten erfolgt über ein sogenanntes BlockchainGateway. Dieses hat die Aufgabe, auf der einen Seite Daten aus Stromzählern und Erzeugungsanlagen in hoher Qualität zu erfassen und auf der anderen Seite die Verbindung zwischen den Teilnehmern über ein Kommunikationsnetzwerk sicherzustellen. Dies kann über

202

T. Brenner

das nutzereigene WLAN, einen kabelgebundenen LAN-Anschluss oder das Mobilfunknetz erfolgen, je nach Verfügbarkeit vor Ort. Das Blockchain-Gateway dient gleichzeitig als Light Node innerhalb des Blockchainnetzwerkes. Dies bedeutet, dass eine lokale Kopie der Blockchainheader zur Prüfung vorgehalten wird, aber der Teilnehmer keine aktive Validierungsfunktion übernehmen kann. Dabei wird berücksichtigt, dass das Blockchain-Gateway nur über eine begrenzte Rechenleistung verfügt und selbst nicht aktiv zur Aufrechterhaltung des Netzwerkes beitragen muss. Als Konsensmechanismus kommt eine Proof-of-Authority (PoA) Variante („Aura“) zum Einsatz. Dies sorgt für einen dramatisch geringeren Energieverbrauch pro Transaktion im Vergleich zu öffentlichen Blockchains, die auf Proof-of-Work basieren. Im Projekt validieren sechs Authority Nodes die Transaktionen. Diese sind wiederum verteilt auf drei Unternehmen. Es ist möglich, Authority Nodes auf eigener Hardware zu betreiben oder in einen Clouddienst (z. B. Open Telekom Cloud, Amazon AWS, Strato, etc.) auszulagern. Der dafür notwendige administrative Aufwand ist überschaubar, Authority Nodes sind typischerweise innerhalb weniger Stunden einsatzbereit. Die im Projekt erhobenen Daten werden nicht vollständig auf der Blockchain gespeichert. Wie in den meisten Fällen, in denen Blockchainkomponenten zum Einsatz kommen, werden diese nur dort verwendet, wo sie einen konkreten Mehrwert bieten. Dies bedeutet im Fall des Allgäu Microgrid, dass wie in Abb. 6.3 skizziert, die Blockchain zur Nutzerregistrierung, dem Sammeln und Aggregieren von Geboten für Stromein- und -verkäufe, der individuellen Berechnung der Markträumungsergebnisse für jeden Nutzer sowie zur Kommunikation der Marktergebnisse verwendet wird. Zur Speicherung hochaufgelöster Verbrauchsdaten hingegen kommt zum Beispiel eine konventionelle Datenbanklösung zum Einsatz. Die eingesetzte permissioned Blockchain mit PoA-Konsensmechanismus genügt bezüglich der Transaktionsgeschwindigkeit und Skalierbarkeit voll den Anforderungen und lässt auch eine größere Zahl an Teilnehmern zu. Soll die Anwendung auf das ganze Netzgebiet ausgeweitet, beziehungsweise deutschlandweit angeboten werden bietet es sich an, auf eine weltweit verfügbare Alternative wie die Blockchain der Energy Web Foundation zurückzugreifen. Diese ist technisch der im Allgäu realisierten Lösung sehr ähnlich, d.h. ein Umzug auf die Infrastruktur der Energy Web Foundation wäre mit vergleichsweise geringem Aufwand möglich. Ähnlich verhält es sich mit der Möglichkeit, an die bestehende Systemarchitektur weitere blockchainbasierte Anwendungen anzukoppeln. Das lokale Handelssystem lässt sich beispielsweise ebenfalls dafür nutzen, beschränkte Ladeleistung für Elektrofahrzeuge dezentral zu vermarkten oder aktiv steuernd in den Betrieb anderer Anlagen (z. B. Wärmepumpen oder gewerbliche Großverbraucher einzugreifen). Hierfür ist es allerdings notwendig, das Blockchain-Gateway (Abb. 6.4) neben einer Zählerschnittstelle auch direkt mit der zu steuernden Anlage oder zukünftig mit dem Smart Meter Gateway zu verbinden.

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

203

Abb. 6.3 Architektur des Allgäu Microgrid: Anlagen werden über das Blockchaingateway ins Netzwerk eingebunden (links); der Smart Contract (Mitte) übernimmt die zentralen Funktionen; über einen MQTT-Broker (oben rechts) werden Daten auf die Smartphone-App des Nutzers direkt aus der Blockchain übertragen und umgekehrt Kundeneingaben zurück an den Smart Contract übermittelt (unten rechts) Abb. 6.4 Exemplarische Vor-Ort-Installation eines Blockchain-Gateways (oben) an der optischen Schnittstelle des Stromzählers (Mitte)

204

6.2.3

T. Brenner

Ein Blick hinter die Kulissen – das Blockchain-Backend und exemplarische Smart Contracts

Im laufenden Betrieb kommt für die Blockchain des Allgäu Microgrid eine modifizierte Variante der „Tobalaba“-Blockchain der Energy Web Foundation zum Einsatz. Dies hat, wie im vorangegangenen Kapitel beschrieben, bezüglich der Skalierbarkeit und Sicherheit des Gesamtsystems wesentliche Vorteile gegenüber einer Nutzung der öffentlichen EthereumBlockchain, welche prinzipiell ebenfalls denkbar wäre. Der Betrieb der Authority Nodes bei verschiedenen Parteien erlaubt es, auf sehr ökonomische Weise ein ausfallsicheres Netzwerk für den lokalen Marktplatz zu schaffen und aufrecht zu erhalten. Selbst wenn eine Anzahl von f Knoten ausfällt, lässt sich der Marktplatz ohne nennenswerte Beeinträchtigung weiterbetreiben, solange 2 f + 1 ≤ n ist, wobei n die Zahl aller Knoten im Netzwerk bezeichnet. Dies ist bei einem zentralisierten Plattformservice nicht ohne weiteres technisch – bei vertretbarem wirtschaftlichem Aufwand – möglich. Ebenso verhält es sich mit der Absicherung des Marktplatzes gegenüber Hackerangriffen. Muss ein zentraler Service dahin gehend gesichert werden, dass Daten von Teilnehmern oder Dritten nicht nachträglich verändert werden können, ist der Aufwand hierfür ebenfalls beträchtlich. Hackerangriffe auf große Unternehmen zeigen immer wieder, dass dies selbst unter sehr großem Aufwand nicht immer gelingt. Hier schafft die Blockchainumgebung durch das Verlegen des Risikos an die Kanten des Gesamtsystems ein bei vergleichbarem Aufwand mit einer zentralen Plattform nicht zu realisierendes Sicherheitslevel. Dadurch, dass an den Endpunkten der Blockchain – den einzelnen Gateways beziehungsweise Energieanlagen – jeweils Light Nodes vorhanden sind, lässt sich prinzipiell durch jeden einzelnen Nutzer des Marktplatzes eine nachträgliche Manipulation der dort abgelegten Daten sehr leicht erkennen. Attacken sind selbstverständlich auch auf eine PoA-Blockchain möglich, erfordern aber ebenfalls einen sehr hohen Aufwand seitens des Angreifers. Ebenfalls zur hohen Vertrauenswürdigkeit trägt die Transparenz des Marktmechanismus gegenüber allen Marktteilnehmern bei. Die in den Smart Contracts hinterlegten Regeln zur Abwicklung des lokalen Marktes sind für alle gleich und nachvollziehbar. Im Folgenden sollen Teile daraus kurz vorgestellt werden, um einen Eindruck von den Funktionen und der Komplexität der notwendigen Smart Contracts zu vermitteln. Beispiel 1: Der Marktmechanismus // C a l c u l a t i o n of the M a r k e t f u n c t i o n c a l c u l a t e M a r k e t () e x t e r n a l { uint tempAP ; if ( countC >0) { sortConsumerPrice ( countC ); for ( u i n t i =0; i < c o u n t C ; i ++) // A v e r a g e P r i c e C a l c u l a t i o n

1 2 3 4 5 6 7 8

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

205

{ t e m p A P =( u s e r s [ cId [ i ]]. p r i c e * u s e r s [ cId [ i ]]. c o m m u n i t y E n e r g y ) / totalCommunityEnergy + tempAP ; } t o t a l C o m m u n i t y E n e r g y =0; } averagePrice = tempAP ; transferEnergy ( countC ); // T r a n s f e r f u n c t i o n to t r a n s f e r the e n e r g y to c o n s u m e r s t e m p A P =0; c o u n t C =0; }

9 10 11 12 13 14 15 16 17 18 19 20

Im ersten Teil des Smart Contracts werden die von den Stromverbrauchern abgegebenen Preisgebote aus der App entsprechend der Höhe sortiert, anschließend wird im zweiten Teil der Durchschnittspreis aller Gebote ermittelt. Anschließend wird dann die Verteilung der Community-Energie an die Teilnehmer gestartet. Beispiel 2: Energietransfer f u n c t i o n t r a n s f e r E n e r g y ( uint _c ) i n t e r n a l {

1

uint t e m p P r o d u c t i o n = t o t a l P r o d u c e d E n e r g y ;

2

for ( uint i = 0; i < _c ; i ++) {

3

if (( t e m p P r o d u c t i o n >= users [ cId [ i ]]. c o m m u n i t y E n e r g y ) && ( users [ cId [ i ]]. o t h e r E n e r g y == 0) ) { // c h e c k i n g the c o m m u n i t y e n e r g y if a v a i l a b l e and if b i d d i n g was

4 5 6

successful t e m p P r o d u c t i o n = t e m p P r o d u c t i o n - users [ cId [ i ]].

7

communityEnergy ; users [ cId [ i ]]. i n M o n e y = true ;

8

i n M o n e y I d [ c o u n t I n M o n e y I d ]= cId [ i ];

9

c o u n t I n M o n e y I d ++;

10 11

}

12

else { users [ cId [ i ]]. o t h e r E n e r g y = users [ cId [ i ]]. c o m m u n i t y E n e r g y ; // else t r a n s f e r r i n g o t h e r E n e r g y

13 14

users [ cId [ i ]]. c o m m u n i t y E n e r g y = 0;

15

u s e r s [ cId [ i ]]. i n M o n e y = f a l s e ;

16

s e t T o t a l O t h e r E n e r g y ( u s e r s [ cId [ i ]]. o t h e r E n e r g y , cId [ i ]) ;

17

// p r o v i d i n g id and E n e r g y for o t h e r E n e r g y }

18 19 20

} priceVolumeCalculation ( countInMoneyId );

21

206

T. Brenner // C a l c u l a t i o n of the c u r r e n t b u d g e t t e m p P r o d u c t i o n =0;

23 24

}

Dieser Teil der Smart Contract Architektur ist für die Zuteilung der Energie aus der Community an die einzelnen Marktteilnehmer zuständig. Zuerst wird überprüft, ob überhaupt Produktionsüberschüsse vorliegen, die an andere Marktteilnehmer abgegeben werden können. Ist dies der Fall, wird überprüft, ob das Gebot des jeweiligen Marktteilnehmers hoch genug war, um einen Zuschlag für die Belieferung in der zugehörigen Viertelstunde zu erhalten. Ist auch dies der Fall, wird die Lieferung dokumentiert. Hat der Teilnehmer keinen Zuschlag bekommen, stellt der Smart Contract sicher, dass die Lieferung aus dem in der App durch den Kunden gewählten Reststromtarif erfolgt. Abschließend wird das aktuelle Budget des Teilnehmers ermittelt, welches ihm im Tagesverlauf für weitere Transaktionen auf dem lokalen Marktplatz zur Verfügung steht. Anhand dieses Beispiels lässt sich zeigen, dass die Zuteilung transparent und vollautomatisch erfolgt. Durch die dezentrale Natur eines Smart Contracts ist es außerdem immer der Fall, dass dieser Code für alle Teilnehmer am lokalen Markt derselbe ist.

6.2.4

22

Die Kundenschnittstelle

Die Kundenschnittstelle ist in zahlreichen DLT-Anwendungen im Energiesektor ein Schlüsselelement. Aus der Tradition der technologieaffinen Nutzer von Kryptowährungen heraus leiden viele Anwendungen heutzutage noch unter einer „User experience“, die in anderen Bereichen bestenfalls vor 20 Jahren salonfähig war. Dies gilt es unbedingt zu verändern, da massenfähige Anwendungen nur dann von den Endkunden angenommen werden, wenn Sie sich ohne Hintergrundwissen und lange Erklärungen intuitiv nutzen lassen. Die meisten Kunden, die in Zukunft Blockchainanwendungen nutzen werden, verfügen über kein entsprechendes Vorwissen und möchten sich vermutlich größtenteils auch nicht mit WalletManagement, Konsensalgorithmen, Secret Stores oder Ähnlichem im Detail auseinandersetzen. Für das Allgäu Microgrid wurde deshalb eine Smartphone-App für Android und iOS entwickelt, die sowohl einen Überblick über die aktuellen Verbrauchs- und Erzeugungswerte zu Hause für jeden Nutzer bereitstellt (Abb. 6.5, links), als auch eine direkte Interaktionsmöglichkeit mit der blockchainbasierten Solar Community bietet (Abb. 6.5, Mitte). Dabei sieht man der App „von außen“ nicht an, dass es sich eigentlich um eine hybride dApp handelt. Der Begriff „hybrid“ bedeutet hierbei, dass die App sowohl auf konventionelle Datenbanken als auch auf die Blockchain zugreifen kann. Unter einer „dApp“ oder „distributed App“ versteht man eine Anwendung, welche im Vergleich zu einer konventionellen „App“ direkt mit einer Blockchain im Hintergrund kommunizieren kann.

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

207

Abb. 6.5 Smartphone-App des Allgäu Microgrid Projektes: Live-Verbrauchs- und Erzeugungswerte sowie Kosten und Einnahmen des Tages (links); Bietfunktion für die Solar Community und Auswahl des Reststromtarifes (Mitte); Stromherkunft und bezogene Strommengen des Tages (rechts)

Nach Eingabe von Benutzername und Passwort (automatisierbar), gelangt der Nutzer auf die Startseite, auf der alle relevanten Parameter zu Erzeugung, Verbrauch und Kosten des jeweiligen Tages einsehbar sind. Dabei werden bereits Daten aus der Blockchain bezüglich des Handels in der Solar Community berücksichtigt, da der Preis pro Kilowattstunde hier je nach Ergebnis der Auktion alle 15 min ein anderer ist. Über die App kann der Nutzer aktiv seine Gebote für Strom aus der Solar Community abgeben, den Stromtarif zur Reststrombelieferung wählen und eine genaue Übersicht über die Bezugsquellen seines Stromes erhalten (Abb. 6.5, Mitte). Eine Anpassung des Gebotspreises oder des Tagesbudgets kann theoretisch alle 15 min erfolgen. Ebenso kann der Tarifwechsel – in diesem Fall zwischen „Grünstrom“ und „Graustrom“ innerhalb des Lieferanten theoretisch alle 15 min erfolgen. Die Liefermengen und die dazugehörigen Preise pro Kilowattstunde werden transparent in der Blockchain dokumentiert und können im Falle einer Überführung in den Realbetrieb dazu genutzt werden, jedem Kunden eine detaillierte Verbrauchsrechnung zu erstellen, analog zum heute im Telekommunikationsbereich üblichen Einzelverbindungsnachweis. Für den aktuellen Tag erhält der jeweilige Kunde über die App eine Auswertung zu Herkunft und Kosten des bezogenen Stromes (Abb. 6.5, rechts). Dort lässt sich viertelstundengenau die Zusammensetzung grafisch und numerisch ablesen. Die dort angezeigten Daten kommen direkt aus der Blockchain. Außerdem dient die App als neuer Kundenkanal für das Allgäuer Überlandwerk, da über die Nachrichtenfunktion der App Neuigkeiten aus dem Unternehmen direkt auf das Smartphone des Kunden kommen.

208

T. Brenner

Perspektivisch ist ebenfalls denkbar, die App mit den in Abschn. 6.3 beschriebenen neuen Funktionen aufzurüsten. Besonders im Bereich Elektromobilität sowie beim Einsatz digitaler Bonussysteme ist die App der naheliegendste und in diesem Fall bereits vorhandene Kommunikationskanal. Auf diese Weise können Dienstleistungen von Versorgern und Stadtwerken digital gebündelt werden – die Blockchain bildet das Rückgrat, über das die einzelnen Dienste vernetzt werden.

6.2.5

Einsatzgebiete

Die in Deutschland gültige Regulierung im Energiesektor macht „echten“ Peer-to-Peer Handel von Energie zwischen Prosumenten sehr schwierig. Vereinfacht gesagt, wird jeder Teilnehmer an einem P2P-Handelsnetzwerk selbst zum Energieversorger mit allen Liefer- und Dokumentationspflichten. Dieser Aufwand ist unverhältnismäßig hoch im Vergleich zu den dabei entstehenden Erträgen und Einsparungen, insbesondere bei Privat- und Gewerbekunden. Dennoch gibt es verschiedene Möglichkeiten einen Ansatz, wie er im Allgäu Microgrid erprobt wurde, in einer Produktivumgebung umzusetzen.

6.2.5.1 Quartiere In Quartieren oder Arealen mit sogenannten geschlossenen Verteilnetzen bieten sich gute Umsetzungsmöglichkeiten, da in diesem Fall bei der Belieferung keine Netzentgelte, sondern unter gewissen regulatorischen Umständen nur Umlagen und Steuern fällig werden [18]. Dies betrifft insbesondere Fälle, in denen ein Unternehmen das Kundennetz innerhalb des Quartiers betreibt. Dort kann sich der Betreiber dazu entschließen, allen Teilnehmern – freiwillig – ein P2P-Handelssystem anzubieten. Die Abrechnung erfolgt dann nicht direkt, sondern über den Betreiber des Kundennetzes analog zu konventionellen Mieterstrommodellen. Dieser Ansatz wird aktuell beispielsweise im Landau Microgrid Projekt (LAMP) [21] verfolgt. Auch die Stadtwerke Walenstadt in der Schweiz erproben ein vergleichbares System in einer Pilotanwendung [11], der konzeptionelle Ansatz ist dem des Allgäu Microgrids sehr ähnlich. Generell lässt sich sagen, dass in der Schweiz die Regulatorik in Quartieren durch die „Zusammenschlüsse zum Eigenverbrauch (ZVE)“ wesentlich flexibler als in Deutschland ist. Das Konzept dezentral organisierter lokaler Märkte eignet sich in Quartieren jedoch prinzipiell nicht nur dazu, Strommengen zwischen einzelnen Teilnehmern zu handeln, sondern beispielsweise auch um begrenzte Ladeleistung für das Laden von Elektrofahrzeugen nutzergerecht zu verteilen. Dieses Problem stellt sich insbesondere in Bestandsquartieren oder Mehrfamilienhäusern, wo eine begrenzte Anschlusskapazität auf sehr hohe Spitzenleistungen beim gleichzeitigen Laden mehrerer Fahrzeuge trifft. Hier bedarf es ebenfalls eines dezentralen Konsensmechanismus, der es ermöglicht, Ladeleistung kosten- und

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

209

bedarfsgerecht anzupassen. Erschwerend kommt in diesem Fall hinzu, dass der Bedarf der einzelnen Nutzer individuell stark schwanken kann und entweder durch das Fahrzeug oder den Nutzer an das System übermittelt werden muss. Hier ist es möglich, die im Allgäu Microgrid entwickelte App zu erweitern und auch Ladepräferenzen von einzelnen Nutzern an einen Smart Contract zu übermitteln, um die optimale Ausnutzung der verfügbaren Ladeleistung zu ermöglichen.

6.2.5.2 Communities Die Bildung von „Communities“ zum Handel von Strom (-dienstleistungen) ist aus Sicht des gesellschaftlichen Trends zur Regionalität eine vielversprechende Vermarktungsmöglichkeit, um Kunden und regional verfügbare Erzeugungsanlagen miteinander zu vernetzen. Mit dieser Idee ist auch das erste Blockchainprojekt im Energiesektor, das „Brooklyn Microgrid“ 2016 gestartet [19]. Der „Talmarkt“ der Wuppertaler Stadtwerke [32] nutzt ebenfalls in Ansätzen Blockchaintechnologie zur Umsetzung eines solchen regionalen Marktes und ist bereits im Produktivbetrieb angekommen. Kunden können dort anlagenscharf ihre Präferenzen zur lokalen Belieferung von Strom über ein Webportal angeben und werden dann prioritär aus diesen Anlagen bedient. Auch der Batterieanbieter Sonnen bietet ein ähnliches Konzept für seine Batteriespeicherkunden an [28]. Dort können zum Beispiel Überschüsse aus einer gerade sonnenreichen Anlage an einen anderen Nutzer verkauft werden, welcher zum gleichen Zeitpunkt seinen Bedarf nicht aus Photovoltaikanlage oder Speicher decken kann. Dies funktioniert aufgrund der Homogenität der dort integrierten Anlagen (in der Regel Privathaushalte mit Photovoltaikanlage und Batteriespeicher) allerdings nur, wenn das Wetter an den Anlagenstandorten stark unterschiedlich ist. Den Modellen gemeinsam ist eine zentrale Rolle des Marktbetreibers, der alle „klassischen“ Rollen des Lieferanten (z. B. bezüglich Bilanzkreisverantwortung oder Rechnungsstellung) für die „Peers“ in der Community übernimmt. Eine vollständige Dezentralisierung ist hier aus rechtlichen und regulatorischen Gründen nicht gegeben, die Kunden erwartet im Gegenzug allerdings auch kein großer administrativer Zusatzaufwand, wenn sie einer Community beitreten möchten. Ein weiteres in der aktuell in Deutschland gültigen Netzentgeltsystematik begründetes Hindernis liegt darin, dass Umlagen und insbesondere die Netzentgelte nicht von der tatsächlich genutzten Netzinfrastruktur abhängig sind. Im Privatkundenbereich fällt für jede Kilowattstunde ein „Flat-Tarif“ an, unabhängig davon, ob diese in einer Community vom Nachbarn erzeugt oder vom anderen Ende Deutschlands geliefert wurde. Mit einer Blockchainlösung wie sie im Allgäu Microgrid umgesetzt wurde, ist es technisch nun möglich, die Nutzung (oder Nichtnutzung) bestimmter Netzebenen eindeutig zu dokumentieren. Im Sinne aller Bürger, die von vor Ort erzeugter Energie profitieren möchten ist damit eine Reform der Netzentgelte denkbar. Der Systemwechsel wäre analog zum Vorgehen, welches von Mautbetreibern auf Autobahnen bereits umgesetzt wird. Bezahlt wird nicht nutzungsunabhängig („Vignettenmodell“) sondern nach Nutzungshäufigkeit und Fahrzeugtyp (im Autobahnfall über ein GPS-basiertes Erfassungssystem).

210

T. Brenner

Abb. 6.6 Anzahl aus dem EEG fallender Anlagen pro Jahr (links) und die korrespondierende Peakleistung (rechts). (Quelle: Conenergy, basierend auf Daten von E3DC, BSW-Solar, BNetzA. Mit freundlicher Genehmigung von [24])

6.2.5.3 Post-EEG-Anlagen Wenn Ende 2020 die ersten Anlagen aus der EEG-Förderung herausfallen, stellt sich für viele Kleinerzeuger die Frage nach einem wirtschaftlich sinnvollen Weiterbetrieb der Anlagen. Oftmals sind diese technisch noch in einem sehr guten Zustand, eine konventionelle Anbindung an die Großhandelsmärkte aufgrund laufender Kosten im Falle von Windkraftanlagen oder aufgrund geringer Leistung im Fall der vor über 20 Jahren erbauten Photovoltaikanlagen ist aber unwirtschaftlich. Aufgrund der niedrigen Anbindungskosten über Open Source Blockchain-Gateways analog zum Allgäu Microgrid und dem hohen Automatisierungsgrad lokaler, blockchainbasierter Märkte kann ein wirtschaftlicher Weiterbetrieb dieser Anlagen ermöglicht werden. Die Betriebskosten der Blockchaininfrastruktur sind ebenfalls gering und prinzipiell auf eine Blockchain wie die der Energy Web Foundation übertragbar, sodass beim Betreiber eines solchen lokalen Marktplatzes nur sehr geringe, größtenteils transaktionsabhängige Kosten anfallen. Auf diese Weise kann Blockchaintechnologie einen Beitrag zu einer CO2 -freien, regionalen Stromversorgung liefern und den Weiterbetrieb vieler kleiner Anlagen (siehe Abb. 6.6) ermöglichen.

6.3

Machine Learning für ein agentenbasiertes Energiemanagement

Maschinelles Lernen, „Deep Learning“, oder „Künstliche Intelligenz“ werden heutzutage gerne als Verkaufsargumente benutzt, um Verfahren, die Daten mittels Algorithmen prozessieren für den Kunden interessanter zu machen. Im folgenden Kapitel soll es spezifisch um die Frage gehen, welche Möglichkeiten sich durch diese Verfahren im Energiesektor

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

211

tatsächlich ergeben und welche Rolle die Blockchaintechnologie dabei spielen kann. Es werden mögliche Verknüpfungspunkte zwischen Blockchain und Machine Learning aufgezeigt sowie einige gängige grundlegende Verfahren zur Datenverarbeitung vorgestellt [4]. Anhand von drei Beispielen wird dargestellt, wie Machine Learning und Blockchain im Energiesektor voneinander profitieren können und welche Anwendungsmöglichkeiten sich daraus perspektivisch ergeben.

6.3.1

Data Mining zur Disaggregaton von Energieverbrauchsdaten

Die gleichzeitige Verfügbarkeit von günstiger Sensorik für das Internet-of-Things (IoT), niedrige Speicherkosten sowie der Vernetzung dieser Sensoren in einem Kommunikationsnetzwerk ermöglichen es, große Datenmengen aus Energieerzeugern und -verbrauchern zu erheben und zu speichern. Diese Daten stehen nun wiederum Anbietern zur Verfügung, um daraus Muster bezüglich der Nutzung dieser Anlagen zu ziehen. Ein Beispiel aus dem Energiesektor ist der Ansatz, aus hochaufgelösten Stromzählerdaten die Nutzung einzelner Geräte „herauszulesen“. Dies geschieht durch die Disaggregation der vorhandenen Daten. Unternehmen wie bidgely [3] nutzen diese Technologie bereits, um aus hochfrequenten Stromzählerdaten (Abtastrate im kHz-Bereich – im Vergleich: Stromdaten sollen in Deutschland aktuell im 15-Minuten-Takt, also mit 0,0011 Hz erhoben werden) die gewünschten Informationen zu extrahieren. Auf diese Weise werden Verbrauchsmuster einzelnen Geräten zugeordnet. Dies geschieht durch den Vergleich der Messdaten mit hinterlegten Profilen typischer Geräte, wie z. B. Kühlschränken, Wärmepumpen oder Backöfen. In Abb. 6.7 ist ein Beispielprofil und die dazugehörige Disaggregation skizziert. Diese Verfahren dienen primär dazu, dem Endkunden Transparenz hinsichtlich des Verbrauchs zur Identifikation von „Stromfressern“ zu ermöglichen. Sie können allerdings auch dazu eingesetzt werden, einzelne Anlagen gezielt ein- und auszuschalten ohne Daten direkt aus den Anlagen auslesen zu müssen. Dies führt auf der einen Seite zu Einspareffekten beim Endkunden, verringert allerdings beim Energieversorger auch den Serviceaufwand, da beispielsweise Abrechnungen für den Kunden leichter nachvollziehbar werden.

6.3.2

Deep Neural Networks und SMPC zur Prognoseoptimierung und Prozesssteuerung

Wie im ersten Teil skizziert, ist die genaue Prognose von Erzeugung und Last bei hohem Anteil von Wind- und Sonnenstrom auf der einen Seite, sowie einer Vielzahl flexibler Verbraucher aus dem Wärme- und Mobilitätssektor auf der anderen Seite eine große Herausforderung für fast alle Teilnehmer am Energiemarkt. An dieser Stelle liefern Prognoseverfahren, die sich auf Deep Neural Networks stützen, vielversprechende Ansätze zur Verbesserung der Prognosequalität. Ein Beispiel ist der Einsatz eines Long Short Term Memory (LSTM)

212

T. Brenner

Abb. 6.7 Schematische Funktionsweise eines Disaggregationsalgorithmus; die Zuordnung zu Gerätetypen erfolgt statistisch über hinterlegte Verbrauchsprofile.

Algorithmus zur Vorhersage des Lastganges eines Einfamilienhauses [20]. Eine Sequenceto-Sequence-Architektur ermöglicht es, Inputdaten beliebiger Länge zur Vorhersage heranzuziehen. Zur Modellierung wurde in diesem Fall ein neurales Netz mit zwei Schichten und 50 Einheiten verwendet. Es konnte eine sehr gute Übereinstimmung zwischen den tatsächlich vorhandenen Lastgangdaten und der LSTM-basierten Vorhersage erzielt werden. Dieses Beispiel zeigt, dass zur genauen Vorhersage hochdynamischer Prozesse, wie dem Laden von Elektrofahrzeugen oder der Ertragsprognose einer Photovoltaikanlage Verfahren wie LSTM in Zukunft sehr wichtig sein werden, um Erzeugung und Verbrauch auf den verschiedenen Netzebenen zu jeder Zeit miteinander in Einklang bringen zu können. Bei der Wärmeerzeugung und Warmwasserbereitung mit Strom steckt ebenfalls großes Effizienzpotenzial in einer den Nutzerbedürfnissen und den Wetterbedingungen angepassten Steuerung. Vereinfacht gesagt muss nur dann geheizt werden, wenn Bewohner zuhause sind oder bald nach Hause kommen, und nicht in Zeiten, in denen Haus oder Wohnung leer stehen. Ebenfalls effizienz- und komfortmindernd wirkt sich das Heizen von Räumen aus, die mit hoher Wahrscheinlichkeit im Tagesverlauf intensivem Sonnenschein ausgesetzt sind. Beide Szenarien setzen voraus, dass die Präsenz von Personen zuverlässig erkannt sowie die Wetterprognose bei der Steuerung berücksichtigt wird.

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

213

Hier setzen maschinelle Lernverfahren an, welche die benötigte Raumwärme an Raumeigenschaften (Wie schnell erwärmt sich ein bestimmter Raum des Gebäudes?), Präsenz (Lässt sich aus dem Stromverbrauchsverhalten im Raum/Gebäude auf die Präsenz von Personen schließen? Lassen sich Muster im Tages- oder Wochenrhythmus erkennen?) und Wetterprognose (Wird der Raum auch ohne Heizung im Wohlfühlkorridor bleiben oder genügt der solare Wärmeeintrag nicht?) anpassen und sich am Verhalten des realen Gebäudes orientieren. Die Forschungsgruppe um Professor Fengqi You der Cornell University hat hierfür eine Kombination aus einem stochastischen Verfahren (stochastic model predictive control) und maschinellen Lernverfahren eingesetzt [26]. Das Konzept zielt darauf ab, mit einem begrenzten Satz an Referenzdaten die Unsicherheit bei der Wärmebereitstellung in einem Gebäude ausreichend gut abzubilden, sodass der Energieeinsatz minimiert wird und Temperaturgrenzwerte gleichzeitig eingehalten werden. Prinzipiell sind solche Verfahren auf alle Prozesse in der Energiewirtschaft anwendbar, welche durch Unsicherheiten bezüglich des Wetters oder des Nutzerverhaltens geprägt sind. Bei diesen beiden Einsatzbeispielen kann Blockchaintechnologie auf mehreren Ebenen zu einem flächendeckenden Einsatz beitragen. Wie in Abschn. 6.2 beschrieben, dient die Technologie als Mittel zum standardisierten, vertrauenswürdigen Datenaustausch zwischen Datenquelle und Analysetool. Zusätzlich ist bei Prognosen entscheidend, dass der Nutzer nachvollziehen kann, ob eine Prognose nachträglich (unerlaubt) manipuliert wurde. Werden Prognoseverfahren weltweit eingesetzt, würde eine kleine systematische Veränderung eines großen Datensatzes (z. B. eine etwas geringere prognostizierte Einspeiseleistung für alle Photovoltaikanlagen in Deutschland) bereits genügen, um einen Blackout im Stromnetz hervorzurufen. Kann der Nutzer sofort erkennen, dass die Prognose manipuliert ist können rechtzeitig Gegenmaßnahmen ergriffen werden. Genau diese Funktionalität kann mit der Nutzung einer geeigneten Blockchainarchitektur sichergestellt werden.

6.3.3

Predictive Maintenance und Pay Per Use

Die Nutzung von Anlagen- und Stromverbrauchsdaten lässt sich im nächsten Schritt auch auf Anwendungen jenseits des Energiesektors ausweiten. IoT-Daten eignen sich sehr gut dazu, mittels maschineller Lernverfahren auf Anomalien überprüft zu werden. Dabei können verschiedene Ansätze verfolgt werden: 1. Regressionsmodelle zur Bestimmung von Tauschintervallen: Auf Basis historischer Daten und eines daraus abgeleiteten Abnutzungsverhalten werden Tausch- oder Serviceintervalle bedarfsgerecht definiert. 2. Vorhersage der Fehlerwahrscheinlichkeit innerhalb eines Zeitraumes: Dem Nutzer wird eine Ausfallwahrscheinlichkeit für das System genannt – hier können mehrere Parameter in das Modell einfließen.

214

T. Brenner

3. Warnung bei anormalem Verhalten: Der Algorithmus erkennt Ausreißer an einem oder mehreren Messpunkten des Systems und weist den Benutzer/Servicepartner auf diesen hin. Die Rolle der Blockchaintechnologie in diesem Anwendungsfall bezieht sich auf die Schaffung einer neutralen „Dateninstanz“ zum Austausch der zur Wartung notwendigen Daten. Der Nutzer möchte produktionsrelevante Daten nicht dem Hersteller oder Servicepartner überlassen, umgekehrt hat der Kunde oftmals keine Daten über die Anlage selbst, diese laufen beim Hersteller zusammen und werden von dort bei Bedarf an den Servicepartner weitergegeben. Durch die Schaffung eines „Digitalen Zwillings“ auf einer Blockchain kann der Datenaustausch vereinheitlicht, ein klares Zugriffskonzept implementiert und eine Automatisierung des Servicevorganges auf Basis von Smart Contracts realisiert werden [16]. Wie in Abschn. 6.3.1 beschrieben, sind Energiedaten ein integraler Bestandteil des digitalen Zwillings. Auf diese Weise lassen sich perspektivisch nicht nur Wartung, sondern auch Bezahlmodelle und Versicherungsdienstleistungen durch diese Kombination aus Blockchaintechnologie, Lastgang- und Sensordaten für ein breites Kundensegment umsetzen.

6.4

Zusammenfassung

Die Herausforderungen, die mit der Dezentralisierung, Digitalisierung und Dekarbonisierung des Energiesystems einhergehen, sind äußerst vielfältig. Eine Echtzeitenergiewirtschaft funktioniert nur, wenn eine große Datenmenge schnell erhoben, analysiert und zur Koordination von Erzeugungs- und Verbrauchsanlagen herangezogen werden kann. Bei der Schaffung einer unabhängigen, neutralen Instanz zum Austausch von Daten und zur Koordination komplexer Prozesse kann Blockchaintechnologie auch im engen heute geltenden Regulierungsrahmen einen wertvollen Beitrag leisten. Das Allgäu Microgrid ist ein Beispiel dafür, wie die lokale Nutzung von Energie von der Erhebung der Daten am Stromzähler über die Automatisierung des Handelsprozesses bis hin zur Interaktion mit den Endkunden über die Smartphone-App mit Hilfe von Blockchaintechnologie abgewickelt werden kann. Hierbei ist die Wahl der DLT-Werkzeuge sowie die genaue „Übersetzung“ des Anwendungsfalles aus dem Energiesektor in Smart Contracts für eine erfolgreiche Implementierung entscheidend. Die Verarbeitung von Daten mit Energiebezug mithilfe maschineller Lernverfahren ist dabei auf eine Infrastruktur angewiesen, welche Zugriffs- und Steuerrechte neutral und automatisiert vergeben, dokumentieren und administrieren kann. Erste Beispiele zeigen das Potenzial stochastischer Verfahren sowie von Deep Neural Networks für den Energiesektor in den Bereichen Lastganganalyse, Wärmebereitstellung und Smart Maintenance. Die skizzierten Beispiele stellen nur einen Ausschnitt der technischen Möglichkeiten dar, auf deren Basis in den kommenden Monaten und Jahren maschinelle Lernverfahren und DistributedLedger-Technologien miteinander kombiniert werden, um systemübergreifende Mehrwerte im Energiesektor zu schaffen.

6 DLT im Energiesektor – Wie blockchainbasierte Werkzeuge …

215

Danksagung Das Allgäu Microgrid Projekt ist zwischen Juni 2018 und Juni 2019 in enger Zusammenarbeit zwischen den Allgäuer Überlandwerken (Joachim Klaus und Christian Ziegler), der mway solutions GmbH (Volker Hahn, Sascha Droste, Gregor Papez, Reinhard Blessing) und der OLI Systems GmbH umgesetzt worden. Aufseiten der OLI Systems wurde die Entwicklung von meinen Kollegen Dr. Ole Langniß, Peter Vogel, Felix Förster, Hassan Haroon, Muhammad Yahya und Philipp Kraus auf konzeptioneller und technischer Seite vorangebracht.

Literatur 1. Agora Energiewende: Büchner, Nikogosian, Schober, Woll, Weyer: Neue Preismodelle für die Energiewirtschaft – Reform der Struktur von etzentgelten und staatlich veranlasster Preisbestandteile (2017). https://www.agora-energiewende.de/fileadmin2/Projekte/2017/Abgaben_ Umlagen/146_Neue-Preismodelle_WEB.pdf. Zugegriffen: 23. Juli 2019 2. BDEW Bundesverband der Energie- und Wasserwirtschaft e. V.: Blockchain in der Energiewirtschaft – Potenziale für Energieversorger. Eine Studie in deutscher und englischer Fassung (2017). https://www.bdew.de/service/publikationen/blockchain-energiewirtschaft/. Zugegriffen: 23. Juli 2019 3. Bidgely: Home Energy Reports (2019). https://www.bidgely.com/bidgely_home-energyreports/. Zugegriffen: 23. Juli 2019 4. Boden Margaret, A.: Artificial Intelligence. A Very Short Introduction. Oxford University Press, Oxford (2018) 5. Buterin, V.: The meaning of decentralization (2017). https://medium.com/@VitalikButerin/themeaning-of-decentralization-a0c92b76a274. Zugegriffen: 23. Juli 2019 6. BVES – Bundesverband Energiespeicher e. V. Berlin und DIHK – Deutscher Industrie- und Handelskammertag Berlin/Brüssel: Faktenpapier Energiespeicher – Rechtsrahmen, Geschäftsmodelle, Forderungen (2017). https://www.bves.de/wp-content/uploads/2017/05/Faktenpapier_ 2017.pdf. Zugegriffen: 23. Juli 2019 7. CORRECTIV Recherchen für die Gesellschaft: Grand Theft Europe – A Cross-Border Investigation (2019). https://correctiv.org/top-stories/2019/05/06/grand-theft-europe/. Zugegriffen: 23. Juli 2019 8. Das Pebbles-Konsortium: Peer to Peer Energiehandel auf Basis von Blockchains (2019). https:// pebbles-projekt.de/. Zugegriffen: 23. Juli 2019 9. Deutsche Energie-Agentur: Blockchain in der integrierten Energiewende (2019). https:// www.dena.de/newsroom/publikationsdetailansicht/pub/blockchain-in-der-integriertenenergiewende/. Zugegriffen: 23. Juli 2019 10. Diedrich, H.: Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations. CreateSpace Independent Publishing Platform (2016) 11. Diermann, R.: Blockchain-Marktplatz für lokalen Handel mit Solarstrom in der Schweiz gestartet (2019). https://www.pv-magazine.de/2019/02/19/blockchain-marktplatz-fuer-lokalen-handelmit-solarstrom-in-der-schweiz-gestartet/. Zugegriffen: 23. Juli 2019 12. Digiconomist: Ethereum Energy Consumption (2019). https://digiconomist.net/ethereumenergy-consumption. Zugegriffen: 23. Juli 2019 13. Energy Web Foundation: EWF Origin (2019). https://energyweb.org/origin/. Zugegriffen: 23. Juli 2019 14. Energy Web Foundation: Internal Document on the Energy Web Chain. Internes Arbeitsdokument für alle Mitglieder der Energy Web Foundation (2019)

216

T. Brenner

15. Forschungsstelle für Energiewirtschaft e. V.: Anwendungsfälle der Blockchain-Technologie in der Energiewirtschaft (2018). https://www.ffe.de/themen-und-methoden/digitalisierung/846chancen-der-blockchain-technologie-in-der-energiewirtschaft-anwendungsfaelle. Zugegriffen: 23. Juli 2019 16. Heinert, S., Sandner, P.: FSBC Working Paper „Mit Blockchain auf dem Weg zur Smart Maintenance“ (2018). http://explore-ip.com/2018_Blockchain-and-Smart-Maintenance.pdf. Zugegriffen: 23. Juli 2019 17. International Energy Agency: IEA World Energy Outlook (2018). https://www.iea.org/ weo2018/. Zugegriffen: 23. Juli 2019 18. Kanzlei Becker Büttner Held: Rechtsleitfaden Quartiersversorgung. Publikation im Auftrag der Smart Grids Plattform Baden-Württemberg e. V. für Vereinsmitglieder (2018) 19. LO3 Energy: Brooklyn Microgrid (2019). https://www.brooklyn.energy/. Zugegriffen: 23. Juli 2019 20. Marino, D.L., Amarasinghe, K., Manic, M.: Building energy load forecasting using deep neural networks. ArXiV. http://arxiv.org/abs/1610.09460 (2016) 21. Mengelkamp, E.M.: Landau Microgrid Project (LAMP) (2019). http://im.iism.kit.edu/1093_ 2058.php. Zugegriffen: 23. Juli 2019 22. Merz, M.: Blockchain im B2B-Einsatz. MM Publishing, Hamburg (2019) 23. OLI Systems GmbH: Allgäu Microgrid (2019). https://www.my-oli.com/de/oli-projekte/19projekte/143-allgaeu-microgrid.html. Zugegriffen: 23. Juli 2019 24. Pisula, S.: Photovoltaikanlagen im Post-EEG-Zeitalter: Perspektiven für Anlagenbetreiber und Chancen für Energieversorger (2019). https://www.conenergy-unternehmensberatung.com/ photovoltaikanlagen-im-post-eeg-zeitalter/. Zugegriffen: 23. Juli 2019 25. Quaschning, V.: Sektorkopplung durch die Energiewende – Anforderungen an den Ausbau erneuerbarer Energien zum Erreichen der Pariser Klimaschutzziele unter Berücksichtigung der Sektorkopplung (2016). https://www.volker-quaschning.de/publis/studien/sektorkopplung/ Sektorkopplungsstudie.pdf. Zugegriffen: 23. Juli 2019 26. Shang, C., You, F.: A data-driven robust optimization approach to scenario-based stochastic model predictive control. ArXiV. https://arxiv.org/pdf/1807.05146.pdf (2019) 27. Sonnen: Das Nemogrid-Projekt (2018). https://sonnen.de/presse/schlaue-ortsnetze-mit-derblockchain-sonnen-nimmt-projekt-nemogrid-teil/. Zugegriffen: 23. Juli 2019 28. Sonnen: Die Sonnen Community (2019). https://sonnen.de/sonnencommunity/. Zugegriffen: 23. Juli 2019 29. Umweltbundesamt: Herkunftsnachweisregister (2019). https://www.hknr.de/Uba. Zugegriffen: 23. Juli 2019 30. Umweltbundesamt: Zeitreihen zur Entwicklung der erneuerbaren Energien in Deutschland (2018). https://www.erneuerbare-energien.de/EE/Redaktion/DE/Downloads/ zeitreihen-zur-entwicklung-der-erneuerbaren-energien-in-deutschland-1990-2018.pdf; jsessionid=78A826CECB6E412A332DC807E1FFDD46?__blob=publicationFile&v=20. Zugegriffen: 23. Juli 2019 31. Weise, M.: Strommarktgesetz, Messstellenbetriebsgesetz, EEG 2017 & Co. – Rechtsrahmen für die Energiewende? Smart Grids Kongress, Fellbach (2016) 32. Wuppertaler Stadtwerke: tal.markt (2019). https://www.wsw-online.de/wsw-energie-wasser/ privatkunden/produkte/strom/talmarkt/. Zugegriffen: 23. Juli 2019

Stichwortverzeichnis

A Active Learning, 100 AdaBoost, 129 Adaptive Boosting, 129 Analogieverfahren, 125 Analytics-Marktplatz, 169, 171 Anomalieerkennung, 109, 145 Anreizsystem, 177, 182 Ansätze modellparalleler, 135 spieltheoretische, 30 Anwendungsphase, 91 Applikation, dezentrale, 73 Apriori-Algorithmus, 130 Assoziationsanalyse, 110, 130 Atomic Swap, 49 Ausreißererkennung, 109 Automatisierung, 91, 117, 139, 155 AutoML, 154

B Backpropagation, 128 Bagging, 115, 128 Batch Learning, 99 Bayes’sche Verfahren, 125 Beweis des Lernerfolgs, 180 Bias, 92 induktiver, 123 Bitcoin, 38 Blockchain, 37, 143 belastbare, 5

dezentrale, 5 Eigenschaften, 5 öffentliche, 19, 33 transparente, 5 unveränderliche, 6 verifizierbare, 5 Blockchain-Gateway, 201 Boosting, 115, 128 Bootstrap Aggregating, 128 Business Intelligence, 167 Understanding, 113, 183

C ChainCode, 73, 78 Client-Server-System, 32 Clusteranalyse, 107 Clustering, 107 hierarchisches agglomeratives, 129 Concept Learning, 104 Content Delivery Network, 66 CRISP-DM, 112, 176 cumulative weight, 54, 56

D DAG (Directed Acycling Graph), 51 Dapp, 73 dApp, hybride, 206 Data Leakage, 122

© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 S. Schacht und C. Lanquillon (Hrsg.), Blockchain und maschinelles Lernen, https://doi.org/10.1007/978-3-662-60408-3

217

218 Mining, 93 Preparation, 114 Science, 93, 95 Scientist, 169 Understanding, 114, 183 Warehouse, 168 Daten-Marktplatz, 187 Datenanalyse, explorative, 93, 110 Datenmatrix, 102 Datenparallelität, 133 Datenplattform, 146, 151 DBSCAN, 130 Dekarbonisierung, 197 Delegated-Proof-of-Stake-Verfahren, 24 Deployment, 116 Descriptive Clustering, 107 Difficulty, 20, 43 Dimensionsreduktion, 110 Directed Acycling Graph, 51, 52, 59 Graph, 51 Disaggregation, 211 Distributed-Ledger-Technologie, 5, 37 Ebenen, 6

E Endorsement-Policy, 80 Entscheidungsbaum, 127 ERC20, 188 Ethereum, 76 Swarm, 65 Virtual Machine, 76 Evaluation, 116 Evaluierung, 116 Execute-Order-Validate-Model, 47 Expertensystem, 158

F Famous Witness, 62 feature, 102 Feature Engineering, 111 federated learning, 135, 155 Fehler, byzantinischer, 15, 16, 24 Fehlerrate, empirische, 105 Fitchain, 189 Fitchain-Pod, 191 FP-Growth-Algorithmus, 130

Stichwortverzeichnis G GAS, 77 Gefangenen-Dilemma, 30 General Data Protection Regulation, 174 Generalisierungsfähigkeit, 119, 123 Genesis-Block, 38 Genesis-Transaktion, 52, 54 Gossip-about-Gossip, 61, 63 Gossip-Protokoll, 61 Graphentheorie, 12 Gütemaß, 105 H Hash, 8 Hash-Algorithmus, 7, 12 Hash-Funktion, 8 Hash-Wert, 41, 61, 67 Hashgraph, 51, 59 Nachteile, 64 Vorteile, 63 Hyperledger Fabric, 27, 75, 78, 148 Hyperparameter, 118 I Incentivierung, 150, 171, 181 inductive bias, 123 Intermediärität, 171, 177 Internet of Things (IoT), 155, 168 InterPlanetary File System, 65, 178, 185, 192 IOTA, 51, 57 Nachteil, 59 Vorteil, 58 IPFS (InterPlanetary File System), 65 IPFS-Gateway, 68 IPFS-Objekte, 67 K k-Nächste-Nachbar-Algorithmus, 126 k-nearest neighbors, 126 KDD (knowledge discovery in databases), 94 Klassifikation, 103 Klassifikator, 103 Konfusionsmatrix, 104 Konsens-Algorithmus, 7, 16, 35 Bedingungen, 14 PAXOS, 17 RAFT, 17

Stichwortverzeichnis Konsensmechanismus, 13, 200 Konsortium, 77 Konsortiums–Blockchain, 35 Kontrollinstanz, zentrale, 13 Koordinator, 57 Kreuzvalidierung, 120 Kryptowährung, 144 Künstliche Intelligenz (KI), 90

L Lernen bestärkendes, 98 föderiertes, 135, 181 halbüberwachtes, 97 maschinelles, 91, 93, 169 überwachtes, 96 Unüberwachtes, 97 verteiltes, 122, 131 vertikales föderiertes, 137 Lernverfahren, inkrementelles, 134 Light Node, 202 Lightning-Protokoll, 48

M Machine-Learning-Marktplatz, 146 Machine-Learning-Pipeline, 117, 122, 155, 180 Machine-Learning-Prozess, 173 MD5, 8 Mempool, 39 Merkmal, 102 Microgrid, 201 Mining, 19 Mining-Pool, 20 Model Ensemble, 115, 128 Life-Cycle Management, 116 Selection, 115 Model-as-a-Service, 177 Modeling, 115 Modell, 91 Modellanwendung, 101 Modellerstellung, 101 Modellierungsphase, 115 Modellparallelität, 133 Mustererkennung, 93, 95

219 N Naive-Bayes-Algorithmus, 127 Netze, neuronales, 128 No-Free-Lunch-Theorem, 115, 139 Nonce, 43

O Off-Chain, 147 Optimierung, 124 Oracle, 74, 199 Order-Execute-Modell, 47, 57, 63 Ordering-Node, 79, 80 Organisation, dezentrale autonome, 73 outlier, 109 Overfitting, 96, 106, 118, 119, 121, 179

P P2P-Netzwerk, 32 Peer-to-Peer, 31, 69 Peer-to-Peer-Netzwerk, 7 Permissioned Blockchain, 27, 35, 78 Permissionless Blockchain, 33 Practical Byzantine-Fault Nachteil, 26 Schritte, 25 Practical Byzantine-Fault-Tolerance, 24 Predictive Analytics, 93 Clustering, 107 Private Blockchain, 34 Channel, 79 programmable economy, 1 proof of learning, 180 Proof-of-Authority, 200, 202 Proof-of-Stake, 21 Anteilssystem, 21 Difficulty, 22 Eigenschaften, 23 Proof-Hash, 22 Vorteil, 23 Proof-of-Work, 18, 41, 200 Nachteile, 20 Vorteile, 20 Public Blockchain, 33, 34

220

Stichwortverzeichnis

Q Qubic, 73

Transfer Learning, 99 Transfer-Learning-Prozess, 176

R Ranking, 107 Regression, 105 lineare, 126 logistische, 127 Regressionsfunktion, 105 reinforcement learning, 98 Replicated-State-Machine, 24

U Underfitting, 106, 118 unsupervised learning, 97

S Sandbox-Modell-Container, 180 Satoshi Nakamoto, 18, 37 Secure-Hash-Algorithmus, 8 semi-supervised learning, 97 Sharing Economy, 171 Signatur, digitale, 9 Skalierbarkeit, 33, 122 Smart Contract, 59, 69, 148, 179, 180 Merkmale, 71 Solidity, 76 Spieltheorie, 30 Stacking, 128 Stream Learning, 99 Streuwertfunktion, 8 Strommenge, 21 supervised learning, 96 Support Vector Machine, 127 T Tangle, 53 Testdaten, 118 Tip-Selektor, 54 Trainingsdaten, 91 Trainingsphase, 91

V Validierungsdaten, 118 Verfahren evolutionäres, 126 genetisches, 126 konnektionistische, 125 symbolisches, 125 Verfahrensklassen, 124 Verschlüsselung asymmetrische, 7, 46 symmetrische, 9 Verschlüsselungsverfahren asymmetrisches, 9 homomorphe, 147 verteiltes Lernen, 150 virtual Voting, 63 Vorhersagemodell, 91, 100

W Wissensentdeckung in Datenbanken, 94 Witness, 61

Z Zahlungskanal, 48 zero knowledge proof, 179 Zero-Knowledge, 29 Zero-Knowledge-Proof, 28 zk-SNARK, 29