Ausstellen und Verifizieren von Leistungsausweisen auf der Ethereum-Blockchain - Bachelor Thesis 2019 - FHNW
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Ausstellen und Verifizieren von
Leistungsausweisen auf der Ethereum-
Blockchain
Bachelor Thesis 2019
Autor: Sven Cueni
Ort, Datum: Olten, 05. August 2019
Betreuender Dozent: Prof. Dr. Walter Dettling
Auftraggeber: login Berufsbildung AG, Philipp Schenker
Folgeseite
Folgeseite
Titel Ausstellen und Verifizieren von
Leistungsausweisen auf der
Ethereum-Blockchain
Untertitel Bachelor Thesis 2019
Autor Sven Cueni
Gelterkinderstrasse 31
4450 Sissach
Betreuender Dozent Prof. Dr. Walter Dettling
FHNW
Hochschule für Wirtschaft,
Institut für Wirtschaftsinformatik
Peter Merian-Strasse 86
4052 Basel
Auftraggeber login Berufsbildung AG
Philipp Schenker
Riggenbachstrasse 8
4601 Olten
Ort und Datum Olten, 05. August 2019
05. August 2019 I
Ehrenwörtliche Erklärung Ehrenwörtliche Erklärung Ich versichere, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der im Literaturverzeichnis angegebenen Quellen und Hilfsmittel angefertigt habe. Die wörtlich oder inhaltlich den im Literaturverzeichnis aufgeführten Quellen und Hilfsmitteln entnommenen Stellen sind in der Arbeit als Zitat bzw. Paraphrase kenntlich gemacht. Diese Bachelor Thesis ist noch nicht veröffentlicht worden. Sie ist somit weder anderen Interessierten zugänglich gemacht noch einer anderen Prüfungsbehörde vorgelegt worden. Ort, Datum Unterschrift Autor Sissach, 05. August 2019 _________________ 05. August 2019 II
Danksagung Danksagung Ein grosses Dankeschön gebührt dem verantwortlichen Fachdozenten und Betreuer dieser Bachelor Thesis, Prof. Dr. Walter Dettling, Dozent für Wirtschaftsinformatik und Mathematik an der Fachhoch- schule Nordwestschweiz. Seine Leidenschaft für das Thema Blockchain ist inspirierend und motiviert andere in diese spannende Technologie einzutauchen. Die vermittelten Kontakte, die empfohlene Fachliteratur sowie die gemeinsamen Gespräche vor Beginn dieser Arbeit und auch im Rahmen der Treffen während dieser Arbeit waren elementar für deren Erfolg. Egal ob in der Rolle als Auftraggeber oder als Vorgesetzter, ein grosses Dankeschön gilt auch Philipp Schenker, Leiter ICT bei der login Berufsbildung AG. Sein grosses Vertrauen, die gebotenen Freiheiten aber auch seine Unterstützung in den richtigen Momenten machen ihn zu einem unglaublich guten Vorgesetzten und noch besseren Arbeitskollegen. Auch in hektischen Zeiten bietet er jederzeit ein offenes Ohr und findet für jede Problemstellung praktikable und unkomplizierte Lösungen. Die Begeisterung und der Eifer, mit welcher er seinen beruflichen Alltag meistert, sind schlichtweg ansteckend. Dank steht auch der BlockFactory zu – allen voran Fabian Mösli, Product Owner von certifaction. Die Flexibilität und die Geduld, mit der sie diese Arbeit unterstützt haben, ist nicht selbstverständlich. Die entgegengebrachte Geduld und das Verständnis bildeten eine solide Basis für eine Zusammen- arbeit auf Augenhöhe zwischen Blockchain-Experten und einem Neuling auf diesem Gebiet. Zum Schluss möchte ich allen bei login involvierten Mitarbeitenden danken. Sie haben es überhaupt möglich gemacht, dass diese Arbeit zu einem Ergebnis geführt hat. Alle die für eine Zusammenarbeit oder für eine Auskunft angefragt wurden, haben sofort Interesse an der Arbeit gezeigt und waren offen für konstruktive Gespräche. 05. August 2019 III
Management Summary Management Summary Die login Berufsbildung AG hat im Rahmen der Strategieumsetzung 2018 diverse Projekte zur Digitalisierung der Prozesse rund um die Ausbildung ihrer Lernenden und Praktikanten realisiert. Trotz ausgeprägtem Digitalisierungsgedanke werden Leistungsausweise von login nach wie vor in Papierform ausgestellt. Das Ziel der vorliegenden Arbeit war herauszufinden, ob sich Blockchain für das Ausstellen und Verifizieren digitaler und fälschungssicherer Leistungsausweise eignet und ob der Software-Markt angemessene Lösungen bietet. Für den Einsatz der gefundenen Lösung bei login soll deren Wirt- schaftlichkeit beurteilt werden. Die Machbarkeit des Ausstellens und Verifizierens von Leistungsausweisen auf der Blockchain wird im ersten Teil der Arbeit mit Hilfe einer Literaturrecherche geprüft. Dabei werden die Grundsätze der Blockchain-Technologie erklärt und auf einen konkreten Anwendungsfall von login projiziert. Im zweiten Teil der Arbeit wird die Webapplikation certifaction, entwickelt vom Schweizer Start-up-Un- ternehmen BlockFactory, auf dessen Eignung für den Anwendungsfall von login geprüft. Die Lösung wird zudem aus wirtschaftlicher Sicht analysiert und die Funktionen der Anwendung ausführlich dokumentiert. Die Literaturrecherche ergab, dass sich die Eigenschaften der Blockchain hervorragend für das Ausstellen und Verifizieren von digitalen Dokumenten anbieten. Die Sicherheit vor Fälschungen ist dabei wesentlich höher als bei Papierdokumenten. Das während dieser Arbeit evaluierte Produkt certifaction der BlockFactory AG eignet sich für den Anwendungsfall von login und wird nun mit einer Pilotgruppe genauer auf dessen praktische Brauchbarkeit getestet. Die erfolgte Dokumentation der Applikation bietet interessante Einblicke in die Funktionalität der Software und zeigt, dass es auch Möglichkeiten gibt, die Funktionalität in login-Systeme zu integrieren. Aus der Wirtschaftlichkeits- analyse ergab sich eine klare Empfehlung für das Ausstellen von digitalen Leistungsausweisen auf der Blockchain. 05. August 2019 IV
Inhaltsverzeichnis
Inhaltsverzeichnis
Folgeseite......................................................................................................................................... I
Ehrenwörtliche Erklärung ................................................................................................................ II
Danksagung ................................................................................................................................... III
Management Summary ................................................................................................................. IV
Inhaltsverzeichnis ........................................................................................................................... V
1 Einleitung ................................................................................................................................. 1
1.1 Auftraggeber .....................................................................................................................1
1.2 Ausgangslage und Problemstellung ..................................................................................1
1.3 Ziele ..................................................................................................................................2
1.4 Vorgehen ..........................................................................................................................3
1.4.1 Meilensteine ...............................................................................................................3
1.5 Erwartete Ergebnisse ........................................................................................................4
1.6 Abgrenzung .......................................................................................................................4
1.6.1 Evaluation einer Standardlösung ................................................................................4
1.6.2 Erhebung und Definition der Anforderungen mit der Auftraggeberschaft ....................4
1.6.3 Umgang mit allfälligen Zusatzkosten ..........................................................................4
1.6.4 Dokumentation der Lösung (technisches Konzept) ....................................................5
1.6.5 Proof of Concept mit Hilfe einer Pilotgruppe ...............................................................5
1.6.6 Projekt der SBB..........................................................................................................5
2 Blockchain – Einführung in die Theorie .................................................................................... 6
2.1 Entstehungsgeschichte der Blockchain .............................................................................6
2.2 Anforderungen an ein Transaktionssystem .......................................................................7
2.2.1 Verfügbarkeit ..............................................................................................................7
2.2.2 Eigentumssicherung ...................................................................................................7
2.2.3 Unveränderbarkeit ......................................................................................................8
2.2.4 Überprüfbarkeit ..........................................................................................................8
2.2.5 Skalierbarkeit .............................................................................................................8
2.3 Schwachstellen intermediärer Transaktionssysteme .........................................................8
2.4 Verteilte Transaktionssysteme (DLT) ................................................................................9
2.5 Elemente einer Blockchain ..............................................................................................10
05. August 2019 V
Inhaltsverzeichnis
2.5.1 Verteiltes Peer-to-peer-Netzwerk .............................................................................10
2.5.2 Asymmetrische Kryptographie ..................................................................................11
2.5.3 Hash-Funktion und Blockbildung ..............................................................................13
2.5.4 Konsensalgorithmen ................................................................................................16
2.6 Ablauf einer Transaktion .................................................................................................18
2.7 Ethereum und seine wichtigsten Eigenschaften ..............................................................21
2.7.1 Smart Contracts, DApps und DAOs .........................................................................21
2.7.2 Transaktionskosten und die Einheit Gas ..................................................................22
2.8 Herausforderung «Skalierbarkeit» ...................................................................................23
3 Leistungsausweise auf der Blockchain ................................................................................... 25
3.1 Fälschung von Leistungsausweisen ................................................................................25
3.2 Leistungsausweise auf Papier .........................................................................................27
3.3 Leistungsausweise auf der Blockchain ............................................................................27
4 Anwendungsfall Lehrzeugnisse .............................................................................................. 30
4.1 Ist-Situation .....................................................................................................................31
4.2 Soll-Situation ...................................................................................................................31
4.2.1 Anforderungen an das Ausstellen von Lehrzeugnissen ............................................32
4.2.2 Anforderungen an die Verifizierung von Lehrzeugnissen ..........................................32
4.2.3 Anforderung an das Teilen von Lehrzeugnissen.......................................................32
4.2.4 Anforderung an den Rückruf von Lehrzeugnissen ....................................................33
5 Technische Umsetzung auf der Ethereum Blockchain ............................................................ 34
5.1 Lösung von BlockFactory ................................................................................................34
5.2 Benutzerdokumentation Certifaction................................................................................34
5.2.1 Leistungsausweise ausstellen ..................................................................................35
5.2.2 Leistungsausweise teilen .........................................................................................38
5.2.3 Leistungsausweise verifizieren .................................................................................38
5.2.4 Leistungsausweise als ungültig erklären (revoken) ..................................................39
5.3 Technische Dokumentation Certifaction ..........................................................................40
5.3.1 Blockchain-Protokoll .................................................................................................40
5.3.2 Systemarchitektur und Smart Contracts ...................................................................41
5.3.3 Transaction Engine ..................................................................................................41
5.3.4 Wichtigste Funktionen ..............................................................................................42
05. August 2019 VI
Inhaltsverzeichnis
5.3.5 Hash der PDF-Datei .................................................................................................44
5.3.6 Bezahlvorgang mit Credits .......................................................................................45
5.3.7 Whitelist-Einträge .....................................................................................................46
5.3.8 Sicherheit (Kunden-Wallet und Anmeldung) .............................................................46
5.4 Integrationsmöglichkeiten ................................................................................................47
5.4.1 Verifizierungstool auf der login Homepage ...............................................................47
5.5 Pilot .................................................................................................................................47
6 Wirtschaftlichkeit .................................................................................................................... 49
6.1 Exploratives Projekt.........................................................................................................49
6.2 Wirtschaftlichkeitsanalyse ...............................................................................................49
6.2.1 Kosten ......................................................................................................................50
6.2.2 Nutzen .....................................................................................................................50
6.2.3 Vergleich Kosten und Nutzen ...................................................................................50
6.2.4 Empfehlung ..............................................................................................................52
7 Ausblick – weitere Anwendungsfälle der Blockchain für login ................................................. 53
7.1 Registrierung von intellektuellem Eigentum .....................................................................53
7.2 Reputations-Währung .....................................................................................................53
7.3 Digitale Identitäten ..........................................................................................................53
8 Fazit und Ausblick .................................................................................................................. 55
8.1 Fazit ................................................................................................................................55
8.2 Ausblick...........................................................................................................................55
9 Literaturverzeichnis ................................................................................................................ 57
10 Glossar................................................................................................................................... 59
11 Abbildungs- und Tabellenverzeichnis ..................................................................................... 61
05. August 2019 VII
Einleitung 1 Einleitung Die vorliegende Bachelor-Thesis wurde in Zusammenarbeit zwischen der login Berufsbildung AG und der Hochschule für Wirtschaft an der Fachhochschule Nordwestschweiz verfasst. 1.1 Auftraggeber Die login Berufsbildung AG (nachfolgend «login») ist der professionelle Partner für Berufsbildung in der Welt des Verkehrs. Als Bildungspartner der SBB, BLS, RhB, des VöV und rund 50 weiteren Unternehmen organisiert login marktorientierte Berufslehren, Praktika und weiterführende Ausbil- dungen. login ist ein führender Anbieter von attraktiver und bedarfsgerechter Berufsbildung und leistet einen wesentlichen Beitrag zur Sicherung des Nachwuchses in der Welt des Verkehrs. Per 01. Januar 2002 schlossen sich die Gründungsmitglieder SBB und BLS zu einem Ausbildungs- verbund zusammen. Der Zusammenschluss erfolgte aus Gründen der Öffnung und Attraktivitätsstei- gerung ihrer Ausbildung. Die Öffnung sollte es auch Drittfirmen ermöglichen von den Ausbildungsan- geboten der SBB und BLS – neu login – zu profitieren. Zudem konnte login dadurch früher nicht marktfähige Monopollehren eidgenössisch anerkennen lassen (z.B. Spezialist/in öffentlicher Ver- kehr). Die Mitgliederversammlung von login stimmte am 22. November 2013 der Umwandlung in eine Aktiengesellschaft zu. Aus dem Verein mit ursprünglich über 60 Partnerfirmen wurde eine Aktienge- sellschaft, an der sich die SBB als grösster Lehrbetrieb mit 70%, die BLS, die Rhätische Bahn (RhB) und der Verband öffentlicher Verkehr (VöV) mit je 10% beteiligen. Als Bildungspartner organisiert login die Ausbildung von über 2000 Lernenden in 25 verschiedenen Berufslehren. Zentraler Bestandteil ihrer Ausbildung sind Praxiseinsätze in den unternehmerisch ausgerichteten Junior Teams bei login und deren Partnerfirmen. Abgesehen von einem Vertiefungs- jahr rotieren die Lernenden während ihrer Ausbildung im Halbjahresrhythmus zwischen verschie- denen Ausbildungsplätzen. login beschäftigt heute rund 140 Mitarbeitende, davon ca. 50 am Hauptstandort in Olten. Die rest- lichen Mitarbeitenden sind über die Standorte in Trimbach, Bern, Spiez, Zürich, Lausanne, Yverdon, Bellinzona und Landquart verteilt. 1.2 Ausgangslage und Problemstellung Im Rahmen der Strategieumsetzung 2018 hat login diverse Projekte zur Digitalisierung der Prozesse rund um die Ausbildung der Lernenden und Praktikanten realisiert. login verfolgt damit das Ziel die 05. August 2019 1
Einleitung
Ausbildung für Lernende und die Zusammenarbeit mit den Berufsbildenden zeitgemäss und attraktiv
zu gestalten und gleichzeitig die Effizienz administrativer Prozesse zu erhöhen.
Mit der Strategieumsetzung hat login eine Systemumgebung geschaffen, die den aktuellen
Anforderungen von Lernenden, Ausbildenden und Partnerfirmen entspricht. Die Systeme werden
kontinuierlich weiterentwickelt um auch weiterhin den Anforderungen aller Stakeholder gerecht zu
werden. Um auch langfristig als kompetenter, attraktiver und innovativer Bildungspartner
wahrgenommen zu werden, setzt sich login aktiv mit aktuellen Technologie-Entwicklungen und
zukünftigen Trends auseinander. Eine dieser Technologien ist Blockchain.
Als Bildungsinstitution führt login verschiedenste Kurse wie die Schulung von Berufsbildenden, oder
überbetriebliche Kurse durch und stellt den Teilnehmenden Leistungsausweise aus, die das
Absolvieren eines solchen Kurses bescheinigen. Die Leistungsausweise werden auf Papier
gedruckt, vom Kursleitenden unterzeichnet und dem Teilnehmenden ausgehändigt. In dieser Form
entsprechen die Leistungsausweise nicht dem Digitalisierungsgedanken der login und können
zudem leicht gefälscht und nur umständlich verifiziert werden.
Der Begriff Leistungsausweis wird im Rahmen dieser Arbeit sehr oft verwendet und beschreibt die
schriftliche Dokumentation des Erbringens einer Leistung wie z.B. das Absolvieren eines Kurses (mit
oder ohne Bewertung) oder ein Nachweis der Arbeitsleistung eines Mitarbeitenden (Arbeitszeugnis).
Leistungsausweise sind auch bekannt als Urkunden, Diplome oder Zertifikate. Konkrete Beispiele
für Leistungsausweise im Kontext dieser Arbeit sind:
• Schulzeugnisse
• Arbeits-, Lehr- und Praktikumszeugnisse
• Diplom für den Besuch der Schulung Berufsbildende
• Diplom für den Modulabschluss oder Gesamtabschluss des Lehrgangs Spezialist öffentlicher
Verkehr
1.3 Ziele
Das Ziel dieser Arbeit ist primär die Beantwortung der folgenden Fragen:
• Eignet sich Blockchain für das Ausstellen und Verifizieren digitaler und fälschungssicheren
Leistungsausweisen?
• Gibt es Anbieter von Lösungen für das Ausstellen und Verifizieren digitaler Leistungsaus-
weise auf der Blockchain?
• Wie könnte eine solche Lösung bei login eingesetzt werden und wie wäre das Verhältnis von
Kosten und Nutzen?
05. August 2019 2Einleitung
Im weiteren Sinne verfolgt diese Arbeit das Ziel bei login ein Bewusstsein und Verständnis für das
Potenzial von Blockchain abseits von Kryptowährungen und ICOs zu schaffen und dies anhand
eines einfachen Beispiels zu demonstrieren.
Die Fragen werden in Form dieser Arbeit unter Anwendung verschiedener Methoden (siehe 1.4
Vorgehen) bearbeitet und beantwortet.
1.4 Vorgehen
Für die Beantwortung der Fragen orientieren wir uns am Anwendungsfall für das Ausstellen von
Leistungsausweisen in Form von Lehrzeugnissen (schriftlicher Nachweis des Arbeitsverhaltens).
Die Arbeit umfasst einen theoretischen und einen praktischen Teil. Im theoretischen Teil wird
analysiert, ob und wie Leistungsausweise auf einer Blockchain ausgestellt werden können. Dieser
wird primär auf Grund er Analyse von akademisch relevanter Literatur erarbeitet.
Im zweiten Teil der Arbeit werden in Form einer Anforderungsanalyse die Bedürfnisse der Auftrag-
geberschaft erhoben. Im Anschluss beginnt die Evaluation einer Lösung, die den Anforderungen
von login entspricht. Das Resultat aus der Evaluation ist ein Konzept für die technische Umsetzung
der vorgestellten Lösung. Zusätzlich wird im Rahmen der Evaluation mit Hilfe einer Kosten-
/Nutzenanalyse auch die Wirtschaftlichkeit der Lösung betrachtet und in dieser Arbeit ausgewiesen.
Sofern es der zeitliche Rahmen der Bachelor-Thesis und die finanzielle Machbarkeit beim Auftrag-
gebenden zulässt, wird als Proof of Concept ein Pilot durchgeführt. Über die Durchführung und die
Dokumentation des Pilots entscheiden der Auftraggeber, der betreuende Fachdozent und der Autor
dieser Arbeit gemeinsam im Rahmen der Zwischenpräsentation vom 05. Juni 2019. Im Zweifelsfall
wird im Rahmen der Bachelor-Thesis kein Pilot durchgeführt um den Erfolg dieser Arbeit nicht zu
gefährden.
Der Auftraggeber und der betreuende Fachdozent erhalten die fertige Bachelorthesis bis spätestens
am 05. August 2019 in digitaler Form zugestellt. Die Ergebnisse werden im Rahmen der Schlussprä-
sentation vom 13. August 2019 präsentiert und besprochen. Sofern vom Auftraggeber bis zu diesem
Zeitpunkt keine schriftlichen Ansprüche beim Verfasser dieser Arbeit geltend gemacht wurden,
gelten die Ergebnisse als abgenommen.
1.4.1 Meilensteine
Als Meilensteine gelten die folgenden Termine:
• 09. April 2019 Kick-Off (bei Auftraggeberschaft)
• 05. Juni 2019 Zwischenpräsentation (inkl. Entscheid Pilot)
05. August 2019 3Einleitung
• 05. August 2019 Abgabe der Bachelor-Thesis an Auftraggeberschaft und Fachdozent
• 13. August 2019 Schlusspräsentation und Bewertung der Arbeit
Abgesehen vom 05. August 2019 gilt bei allen Meilensteinterminen Anwesenheitspflicht für alle
Parteien (Auftraggeber, betreuender Fachdozent und Auftragnehmer).
1.5 Erwartete Ergebnisse
Als Ergebnis erhält die Auftraggeberschaft diese Arbeit. Die Arbeit enthält alle Antworten auf die
Fragestellungen. Die Ergebnisse der Literaturrecherche, die Anforderungsanalyse, die Wirtschaft-
lichkeitsbeurteilung sowie ein allfälliger Bericht aus der Pilotgruppe sind Teil dieser Arbeit. Detail-
lierte Arbeitsdokumentationen, Protokolle, etc. werden je nach Relevanz im Anhang der Arbeit
angefügt, gelten jedoch nicht als zu erwartende Lieferobjekte.
1.6 Abgrenzung
1.6.1 Evaluation einer Standardlösung
Die Lösungsevaluation umfasst im Minimum einen Anbieter. Es muss kein Vergleich zwischen
verschiedenen Anbietern erfolgen. Sofern keine Lösung die Anforderungen erfüllen kann bzw. der
Anbieter nicht für eine Zusammenarbeit bereit ist (z.B. aus Ressourcengründen), ist dies unver-
züglich nach Bekanntwerden durch den Auftragnehmenden an den Auftraggebenden zu melden und
hat keine Auswirkung auf den Erfolg dieser Arbeit.
1.6.2 Erhebung und Definition der Anforderungen mit der Auftraggeberschaft
Für die Analyse der Anforderungen sind dem Auftragnehmenden durch den Auftraggebenden die
nötigen Unterlagen und Ressourcen von Mitarbeitenden (z.B. für Interviews) zur Verfügung zu
stellen. Werden dem Auftragnehmenden nicht in nützlicher Frist die nötigen Ressourcen zur
Verfügung gestellt, kann dem Auftraggebenden die Qualität bzw. Vollständigkeit der Ergebnisse
nicht länger garantiert werden.
1.6.3 Umgang mit allfälligen Zusatzkosten
Zu Beginn der Arbeit wurden dem Auftragnehmenden weder personelle noch finanzielle Ressourcen
zugesprochen. Sollte im Rahmen der Arbeit Bedarf für Ressourcen entstehen, ist dies dem Auftrag-
gebenden unverzüglich mitzuteilen. Es werden weder durch den Auftragnehmenden noch durch die
Fachhochschule zusätzliche Kosten getragen. Kann ein Arbeitsschritt nicht ohne Zusatzkosten
durchgeführt werden (z.B. Evaluation einer Lösung) und der Auftraggebende ist nicht bereit diese
zu tragen, verfällt der Anspruch auf die direkten und davon abhängigen Ergebnisse.
05. August 2019 4Einleitung 1.6.4 Dokumentation der Lösung (technisches Konzept) Die Dokumentation der Lösung erfolgt nur soweit dies durch den Anbieter zugelassen und unter- stützt wird. 1.6.5 Proof of Concept mit Hilfe einer Pilotgruppe Das Proof of Concept in Form eines Pilots ist optional und kein verpflichtendes Ergebnis. 1.6.6 Projekt der SBB Im Anschluss an das Kick-Off-Meeting vom 09. April 2019 fand auf Wunsch der Auftraggeberschaft ein Treffen zwischen dem Auftragnehmenden und dem Mutterkonzern SBB AG statt. Dabei ging es darum sich über den aktuellen Stand von Blockchain-Entwicklungen bei der SBB AG zu erkundigen um allenfalls die SBB AG als potentiellen Anbieter aufzunehmen und so Synergien zu nutzen. Das vorgestellte Projekt der SBB AG beschäftigt sich mit der Zutrittsregelung zu Gebäuden bzw. Baustellen mit Hilfe von digital ausgestellten Zutrittsberechtigungen und entspricht nicht dem Anwendungsfall von login. Die Partizipation von login oder weitere Abklärungen zu diesem Projekt sind nicht Teil dieser Arbeit. 05. August 2019 5
Blockchain – Einführung in die Theorie 2 Blockchain – Einführung in die Theorie Bevor man verstehen kann, wie Leistungsausweise auf der Blockchain ausgestellt werden können und inwiefern sich die Technologie Blockchain in dieser Hinsicht von anderen Technologien unterscheidet, ist es elementar die Eigenschaften der Blockchain zu verstehen. Um das Potenzial und den Reifegrad der Technologie über den Anwendungsfall dieser Arbeit hinaus einschätzen zu können, braucht es zudem ein gewisses Verständnis dafür, wie und wann das Konzept Blockchain entstanden ist und wie es sich in ihren konkreten Ausprägungen (z.B. Ethereum) noch weiterent- wickeln wird. Das gesamte Kapitel 2 basiert auf der fundierten Fachliteratur «Blockchain für die Praxis» von Egloff und Turnes (2019), «Mastering Ethereum» von Antonopoulus und Wood (2018) und «Bitcoin und andere dezentrale Transaktionssysteme» von Elfriede Sixt (2017) und ist wo nötig durch weitere Quellen ergänzt. 2.1 Entstehungsgeschichte der Blockchain Ein erster Grundstein für Blockchains wurde 1991 durch Stuart Haber und W. Scott Stornetta gelegt als sie ihre wissenschaftliche Arbeit zum Thema «Cryptographically linking blocks in an append-only data structure» veröffentlicht hatten (Haber & Stornetta, 1991). Das kryptografische Verlinken von Blöcken in einer Datenstruktur, die ausschliesslich neue Einträge entgegennimmt ohne alte Einträge zu verändern oder zu löschen, bildet heute ein zentrales Element jeder Blockchain. Rund 17 Jahre nach der Veröffentlichung der Arbeit von Haber und Stornetta erlangt eine Person oder eine Gruppe, bekannt unter dem Pseudonym Satoshi Nakamoto, grosse Aufmerksamkeit durch ihren Beschrieb der ersten Kryptowährung basierend auf der Bitcoin-Blockchain. Die Idee von Nakamoto war die Erschaffung eines dezentralen Zahlungssystems, das es jeder an der Blockchain partizipierender Partei erlaubt Transaktionen durchzuführen ohne dabei eine absichernde Drittpartei wie z.B. eine Bank hinzuzuziehen (Nakamoto, 2008). Das benötigte Vertrauen zwischen den an der Transaktion beteiligten Parteien sollte durch die Blockchain sichergestellt sein wodurch die Funktion des Mittelsmannes (oft auch als Intermediieren- de bezeichnet) hinfällig wird. Blockchains sind also im Grunde genommen eine Alternative zu den klassischen intermediären Transaktionssystemen, welche eine vertrauensstiftende Drittpartei vor- aussetzen. Um die Funktionsweise und die Eigenschaften einer Blockchain zu verstehen, ist es daher wichtig die Anforderungen an ein Transaktionssystem zu kennen. 05. August 2019 6
Blockchain – Einführung in die Theorie 2.2 Anforderungen an ein Transaktionssystem Unter dem Begriff Transaktion versteht man den Austausch von Gütern oder Informationen zwischen zwei Parteien. Sehr oft wird unter Transaktion der Austausch von monetären Gütern wie z.B. Geld, Wohneigentum, etc. verstanden. Transaktionen können aber auch nicht-monetärer Art sein wie zum Beispiel das Ausstellen von Auszeichnungen oder das entgegenbringen von Anerkennung. Eine Transaktion von Anerkennung klingt zwar etwas abstrakt, wird aber zum Beispiel auf Social Media in digitaler Form massenhaft ausgeführt. Für die Abwicklung von Transaktionen wird jeweils ein Transaktionssystem vorausgesetzt. Auch wenn dies in der heutigen Zeit so üblich ist, beschreibt ein Transaktionssystem nicht zwingend ein IT-System. Es kann sich dabei auch um ein analoges und primitives System wie beispielsweise der Eintrag von Viehbestand eines Bauern im Registerbuch des Königs oder den Austausch von Wolle gegen Getreide eingemeisselt in eine Steintafel handeln. Egal in welcher Zeit der menschlichen Evolution man sich bewegt; Die Anforderungen an Transaktionssysteme bleiben mehr oder weniger dieselben: Ein Transaktionssystem definiert Eigentums- und Nutzungsrechte und kann diese bei Bedarf transferieren. Egloff und Turnes unterteilen die Anforderungen in die nachfolgenden fünf Punkte und definieren damit die Faktoren für das Vertrauen in Transaktionssysteme (Egloff & Turnes, 2019, S. 25-27). 2.2.1 Verfügbarkeit Das Transaktionssystem muss möglichst einfach zugänglich und stabil sein. Betrachtet man z.B. die Entwicklung vom herkömmlichen Schaltergeschäft von Banken hin zum heutigen e-Banking, war dies ein grosser Schritt zur Optimierung der Verfügbarkeit der Transaktionssysteme der Banken. Trotzdem ist die Verfügbarkeit in diesem Fall von einem zentralen Anbietenden abhängig, was dazu führt, dass die Bank nach ihrem eigenen Interesse Personen vom Transaktionssystem ausschliessen kann. Zudem garantiert die Bank alleine für die Ausfallsicherheit und auch für die Integrität des Transaktionssystems. Die Kunden der Bank müssen auf die Dienste der Bank vertrauen. 2.2.2 Eigentumssicherung Neben der Verfügbarkeit ist die Eigentumssicherung ein zentraler Faktor für das Vertrauen in ein Transaktionssystem. Alle an einer Transaktion beteiligten Parteien müssen sicher sein können, dass der Versand von Gütern nur von Personen erfolgen kann, die auch tatsächlich im Besitz des Gutes sind und dass nur die empfangende Partei die Transaktion entgegennehmen (lesen) kann, ohne dass sie von Dritten abgefangen oder manipuliert wird. 05. August 2019 7
Blockchain – Einführung in die Theorie
2.2.3 Unveränderbarkeit
Des Weiteren müssen Transaktionssysteme garantieren, dass Transaktionen nicht nur während des
Transaktionsvorgangs, sondern auch im Nachhinein nicht verändert werden. Beispielsweise dürfen
unter keinen Umständen ohne die Durchführung einer Transaktion Kontosaldos oder Besitzer im
Grundbuch geändert werden. Die Integrität und Nachvollziehbarkeit von Transaktionen bildet die
Grundlage des Vertrauens von Kunden eines Transaktionssystems.
2.2.4 Überprüfbarkeit
Die Überprüfbarkeit beschreibt grundsätzlich das Verlangen nach Transparenz. Bei einer
Transaktion möchten die Parteien prüfen, ob tatsächlich das gewünschte Gut bzw. der gewünschte
Betrag transferiert wurde und der neue Zustand (z.B. Kontosaldo) der Transaktion entspricht. Bei
modernen intermediären Transaktionssystemen sind die Bewegungen beinahe unmittelbar
ersichtlich (z.B. e-Banking). Durch diese zeitnahe Transparenz über den neuen Zustand im
Transaktionssystem schaffen die Intermediierenden Konsens zwischen den Parteien und somit
zusätzliches Vertrauen in ihr System.
2.2.5 Skalierbarkeit
Skalierbarkeit beschreibt die Expansionsfähigkeit eines Systems. Dabei gilt diese Anforderung nicht
nur für Transaktionssysteme, sondern für jegliche Systeme, über welche ein Austausch
irgendwelcher Art erfolgen soll. So ist z.B. eine Messaging Plattform, welche maximal 5'000
Nutzende zulässt, wenig attraktiv, da man darüber kaum Massen erreicht. So verhält es sich auch
mit Transaktionssystemen. Kann man über ein Transaktionssystem nur mit einem kleinen Kreis
Güter austauschen, entspricht dies kaum den Anforderungen der heutigen Marktwirtschaft. Ein
weiterer Faktor für die Expansionsfähigkeit eines Transaktionssystems ist die Anzahl zulässiger
Transaktionen. So wären zum Beispiel die Steintafel oder auch die handschriftliche Notation keine
geeigneten Hilfsmittel für die Erfassung von Transaktionen von Kleinstbeträgen.
2.3 Schwachstellen intermediärer Transaktionssysteme
Herkömmliche Transaktionssysteme haben meist einen intermediären Aufbau. Das bedeutet, das
Vertrauen zwischen zwei Transaktionsparteien wird durch eine zentrale Drittpartei garantiert. Diese
zentralen Parteien – auch Intermediierende genannt – gelten gemäss Egloff und Turnes (2019) aus
folgenden Gründen als Schwachstelle der intermediären Transaktionssysteme:
• Abhängigkeit – Die Macht über das Transaktionssystem konzentriert sich auf den
Intermediierenden.
05. August 2019 8Blockchain – Einführung in die Theorie
• Angreifbarkeit – Ein zentrales System ist zwar umgehend und einfacher implementierbar,
jedoch leichter angreifbar als ein dezentrales System mit mehreren Knoten. Bei einem
dezentralen System wird der Ausfall eines Knotens durch die restlichen Knoten abgefangen.
• Hohe Kosten – Die Leistungen des Intermediierenden hat in den meisten Fällen Kosten für
die Transaktionsparteien zur Folge.
• Ineffizienzen – Egloff und Turnes (2019) begründen diesen Punkt nur sehr spärlich mit den
Stichworten «Verzögerungen» und «Doppelspurigkeiten». Vermutlich sprechen sie damit die
Ineffizienzen an, welche beim Hinzuziehen einer weiteren Partei entstehen (zusätzliche
Bearbeitungs- und Antwortzeiten, redundante Arbeiten und Datenpflege, etc.).
Um diese Schwachstellen zu eliminieren, wurden verteilte Transaktionssysteme oder im englischen
die «Distributed Ledger Technology» (kurz DLT) erfunden.
2.4 Verteilte Transaktionssysteme (DLT)
Im bisherigen Verlauf dieser Arbeit wurde stets sehr allgemein von Transaktionssystemen
gesprochen. Meist wurde dabei davon ausgegangen, dass es eine zentrale Instanz gibt, welche
Vertrauen zwischen Transaktionsparteien herstellt. Durch verteilte Transaktionssysteme sollen
genau diese zentralen Instanzen abgelöst werden. Man spricht in diesem Kontext auch von
Disintermediation.
Egloff und Turnes (2019) ordnen DLT den Systemarchitekturen ein und definieren den Unterschied
so, dass verteilte Systeme im Vergleich zu intermediären Systemen nicht über einen zentralen
Knotenpunkt, sondern alle an diesem Netzwerk teilnehmenden Systeme miteinander kommunizie-
ren. Sie veranschaulichen dies in Abbildung 1 und grenzen dabei dezentrale von verteilten Systemen
ab, wobei es in dezentralen Systemen zwar mehrere Hauptknoten gibt, jedoch nicht alle Knoten
direkt miteinander kommunizieren.
Abbildung 1 – Systemarchitekturen (Egloff & Turnes, 2019)
05. August 2019 9Blockchain – Einführung in die Theorie Eine mögliche technologische Ausprägung eines verteilten Transaktionssystems ist die Blockchain. Neben der Blockchain gibt es aktuell mindestens eine weitere Technologie namens «Directed Acyclic Graph» (kurz DAG), welche ebenfalls zur Gruppe der verteilten Transaktionssysteme gehört. Die beiden Technologien unterscheiden sich primär in der Art wie die Anforderung an die Unveränderbarkeit von Transaktionen umgesetzt ist. Bei Blockchain-Protokollen werden die Transaktionen in Blöcke gepackt und gespeichert. DAG-Protokolle speichern die Transaktionen ohne Blockbildung einzeln ab und sind unter anderem dadurch im Stande Transaktionen schneller auszuführen. Bekannte Blockchain-Protokolle sind Bitcoin und Ethereum mit den jeweils gleich- namigen Tokens. Eine der bekannteren Ausprägungen der DAG-Technologie ist der Token MIOTA basierend auf dem Tangle-Protokoll (Egloff & Turnes, 2019, S. 27-29, 71-74). Wie die Blockbildung funktioniert und wie die weiteren Anforderungen an verteilte Transaktions- systeme in der Technologie Blockchain umgesetzt werden, ist im nachfolgenden Abschnitt 2.5 beschrieben. 2.5 Elemente einer Blockchain Blockchain wird häufig als komplexe Technologie verstanden beziehungsweise eben nicht vollstän- dig verstanden. Dabei handelt es sich bei Blockchain im Grunde genommen um eine Zusammen- setzung von etablierten technologischen Konzepten der Informatik und Mathematik. 2.5.1 Verteiltes Peer-to-peer-Netzwerk Eines dieser technologischen Konzepte wurde spätestens 1999 bekannt als Shawn «Napster» Fanning ein File-Sharing-System veröffentlicht. Napster entwickelte sich rasend schnell zu einer Plattform zur Verbreitung von Musikdateien. Napster war zwar nie ein wirkliches verteiltes Peer-to- peer-Netzwerk, weil es von einem zentralen Knoten abhängig war. Es hat aber die Ära von verteilten Netzwerken eingeläutet (Mahlmann & Schindelhauer, 2007). Schoder und Fischbach (2002) definieren Peer-to-peer-Netzwerke als Verbund gleichberechtigter «Peers», die sich wechselseitig Ressourcen zur Verfügung stellen und ohne zentrale Koordinations- instanzen kollaborative Prozesse ausführen. Die sogenannten «Peers» werden im Kontext von verteilten Transaktionssystemen meist als Knoten (engl. nodes) bezeichnet und sind Computer, welche der Blockchain Speicher- und Rechenre- ssourcen zur Verfügung stellen. Blockchain basiert also im Grunde genommen auf einem Netz an gleichberechtigten Knoten, die ohne eine koordinierende zentrale Instanz über das Internet miteinander kommunizieren. Dabei verfügt jeder Knoten des Netzwerks über eine aktuelle und 05. August 2019 10
Blockchain – Einführung in die Theorie vollständige Kopie der Transaktionshistorie (auch «Ledger» oder zu Deutsch «Hauptbuch» ge- nannt). Nun gibt es zwei Punkte, die aus dieser Definition mit Vorsicht zu geniessen sind: Erstens kommunizieren Blockchains nicht zwingend über das Internet. Es gibt öffentliche Blockchains wie Bitcoin und Ethereum, auf welche jeder mit einem Computer zugreifen kann und es gibt private Blockchains, welche nur mit Erlaubnis (Zugang zu privatem Netzwerk oder durch Benutzerauthentifizierung) benutzt werden können. Private Blockchains können also rein theoretisch an Stelle des Internets auch ausschliesslich über unternehmensinterne Netzwerke kommunizieren. Die wesentlichen Unterschiede zwischen privaten und öffentlichen Blockchains sind, dass private Blockchains nur mit Erlaubnis genutzt werden können, dadurch eine Identifikation der Nutzenden möglich ist, die Daten nur für Teilnehmende transparent sind und dass sie unter normalen Umständen schneller als öffentliche Blockchains sind (Egloff & Turnes, 2019, S. 38-39). Im weiteren Verlauf dieser Arbeit liegt der Fokus auf öffentlichen Blockchains. Zweitens vermerken Egloff und Turnes (2019), dass nicht jeder Knoten über eine volle Kopie der Transaktionen verfügt. Man unterscheidet hier zwischen vollen Knoten (engl. Full Nodes) und leichten Knoten (engl. Lightweight Nodes). Volle Knoten validieren alle Transaktionen und Blöcke und bilden somit das Rückgrat der Blockchain. Es ist beinahe unmöglich ein grosses Netz an «Full Nodes» gesamthaft zu verfälschen oder in die Knie zu zwingen. Fällt ein Knoten aus, wird seine Arbeit durch die weiteren Knoten des Netzwerks fortgesetzt. Leichte Knoten hingegen speichern nur die Header eines Blocks um Speicherplatz zu sparen und trotzdem prüfen zu können, ob konkrete Transaktionen in einem Block enthalten waren oder nicht. Wallets sind Beispiele von leichten Knoten. Um auf die Anforderungen an verteilte Transaktionssysteme zurückzukommen – es gibt zwei Aspekte, welche die Verfügbarkeit des Systems beeinflussen: Zum einen bedeutet eine hohe Anzahl voller Knoten geringes Ausfallrisiko und somit hohe Verfügbarkeit des Systems. Zum anderen kann die Verfügbarkeit durch Privatisierung einer Blockchain eingeschränkt werden. 2.5.2 Asymmetrische Kryptographie Im vorausgehenden Abschnitt wurde bereits der Begriff «Wallet» verwendet. Übersetzt bedeutet «Wallet» so viel wie Brieftasche. Dabei wäre der Begriff Schlüsselbund viel passender, da Trans- aktionen auf der Blockchain und nicht in der Wallet gespeichert sind und eine Wallet nur über sogenannte Schlüssel verfügt, welche auf die in der Blockchain gespeicherten Transaktionen verweisen (Antonopoulus & Wood, 2018, S. 79-80). Ein Wallet beinhaltet mindestens ein Schlüsselpaar. Ein Paar besteht jeweils aus einem privaten und einen öffentlichen Schlüssel (engl. «private key» und «public key»). Mit Hilfe dieser beiden 05. August 2019 11
Blockchain – Einführung in die Theorie
Schlüssel ist es möglich, dass zwei Parteien miteinander kommunizieren können, ohne dass es für
Dritte möglich ist den Inhalt der Nachricht zu entschlüsseln. Zudem kann die sendende Partei die
ausgehende Nachricht signieren damit die empfangende Person weiss, dass die Nachricht von der
korrekten Person stammt. Der öffentliche Schlüssel ist dabei für jeden sichtbar. Der private Schlüssel
hingegen muss gut verwahrt werden, weil damit verschlüsselte Nachrichten entschlüsselt werden
können. Dieses Vorgehen ist bekannt als asymmetrische Kryptographie (auch Verschlüsselung) und
wird von Egloff und Turnes (2019) wie folgt beschrieben:
Ein Schlüsselpaar wird durch einen Algorithmus generiert. Dieser erstellt zuerst einen privaten
Schlüssel und leitet den öffentlichen Schlüssel so davon ab, dass es nahezu unmöglich ist auf Grund
des öffentlichen Schlüssels den privaten Schlüssel zu rekonstruieren. Es entsteht also eine Art
Einbahnbeziehung zwischen den beiden Schlüsseln. Diese Einwegbeziehung bildet die Grundlage
für die beiden Vorgänge «verschlüsseln und entschlüsseln» und «signieren und verifizieren».
Verschlüsseln und entschlüsseln
Anna möchte Ben eine Nachricht senden, deren Inhalt nur Ben lesen kann. Dazu nimmt sie den
öffentlichen Schlüssel von Ben und verschlüsselt damit den Inhalt der Nachricht. Ab diesem
Zeitpunkt könnte selbst Anna den Inhalt der Nachricht nicht mehr entschlüsseln. Nur Ben kann den
Inhalt der Nachricht, welche er von Anna empfängt, mit seinem privaten Schlüssel auflösen.
Man kann sich den öffentlichen Schlüssel von Ben auch als offene Vorhängeschlösser vorstellen,
bei welchen sich Anna und alle anderen Personen bedienen können, welche Ben eine Nachricht
senden möchten. Man packt die Nachricht an Ben in eine Box, nimmt eines der offenen Vorhänge-
schlösser von Ben und verschliesst die Box mit dem Vorhängeschloss. Ab diesem Zeitpunkt kann
nur noch Ben als Besitzer des Schlüssels zum Vorhängeschloss an den Inhalt der Box gelangen.
Abbildung 2 - Verschlüsseln und entschlüsseln (Egloff & Turnes, 2019)
Signieren und verifizieren
Durch das Verschlüsseln und Entschlüsseln ist sichergestellt, dass nur die empfangsberechtigte
Person den Inhalt einer Transaktion lesen kann. Jedoch ist dadurch noch nicht garantiert, dass Anna
auch die Person ist, für welche sie sich ausgibt. Um das zu beweisen, signiert Anna die Nachricht
an Ben mit ihrem privaten Schlüssel. Ben kann beim Empfang der Nachricht mit Hilfe des
05. August 2019 12Blockchain – Einführung in die Theorie
öffentlichen Schlüssels von Anna verifizieren, ob es sich tatsächlich um eine Nachricht von Anna
handelt (Egloff & Turnes, 2019, S. 42-44).
Abbildung 3 - Signieren und verifizieren (Egloff & Turnes, 2019)
Blockchains bedienen sich also auch bei der Verschlüsselung von Nachrichten an einem altbe-
kannten Konzept der Informationssicherheit. Die asymmetrische Verschlüsselung wurde bereits
1970 veröffentlicht (Antonopoulus & Wood, 2018, S. 60). Sie sorgt dafür, dass die Anforderung an
die Eigentumssicherung in Blockchains erfüllt ist. Wie die Unveränderbarkeit von Transaktionen
sichergestellt ist, wird im folgenden Abschnitt erklärt.
2.5.3 Hash-Funktion und Blockbildung
Wie einleitend erwähnt, publizierten Haber und Stornetta (1991) ein Verfahren, nachdem es möglich
ist, Daten so in einer Struktur hinzuzufügen, dass sie anschliessend nicht mehr verändert werden
können. Sie beschreiben in ihrer Arbeit, vereinfacht ausgedrückt, ein Verfahren wie Transaktionen
so miteinander verlinkt werden, dass sie später nicht mehr änderbar sind ohne die gesamte Kette
von Transaktionen zu verändern. Unter anderem bedienen sie sich dabei sogenannter Hash-
Funktionen.
Hash-Funktionen
Haber und Stornetta (1991) definieren Hash-Funktionen als Familie von Funktionen, welche einen
Input (in Form eines Bit-Strings) mit zufälliger Länge entgegennehmen und in einen Output (auch in
Form eines Bit-Strings) mit fixer länge umwandeln. Dabei wird der exakt gleiche Input immer zu
einem identischen Output führen. Umgekehrt ist es nicht möglich auf Grund zwei verschiedener
Inputs den gleichen Output zu generieren (auf jeden Fall bei kollisionsfreien Hash-Funktionen).
Hash-Funktionen haben die Eigenschaft, dass der Output auf Grund des Inputs leicht berechnet, auf
Grund des Outputs aber unmöglich auf den Input geschlossen werden kann (Haber & Stornetta,
1991).
Abbildung 4 zeigt wie sich aus der Eingabe zwei leicht unterschiedlicher Inputs, zwei komplett unter-
schiedliche Outputs (auch Hash-Wert, Hash-Code, Fingerprint, etc. genannt) ergeben. Für die Grafik
wurde die Hashfunktion Keccak-256 verwendet, die in der Ethereum-Blockchain sehr oft Anwendung
findet (Antonopoulus & Wood, 2018, S. 72).
05. August 2019 13Blockchain – Einführung in die Theorie
Abbildung 4 - Hash-Funktion mit minim unterschiedlichem Input (eigene Darstellung)
Inputs als Hash-Werte zu speichern macht aus diversen Gründen Sinn. Zum einen sind Hash-Werte
meist kleiner als ihr Input-Wert und brauchen so weniger Speicherplatz. Trotzdem kann man mit
Hilfe des ursprünglichen (unveränderten) Inputs nachweisen, dass dieser zum entsprechenden
Hash-Wert führt. Zum anderen kann auf Grund des Hash-Werts nicht auf den Input geschlossen
werden (Egloff & Turnes, 2019). Das bedeutet, wenn es sich um sensitiven Input handelt, kann man
mit dem Hash-Wert öffentlich eine Referenz speichern, ohne dass jemand (ohne den originalen
Input) auf den Inhalt schliessen kann. Die Daten sind folglich vollständig geschützt.
Blockbildung
Welche Rolle Hash-Algorithmen im Kontext von Blockchains spielen, wird spätestens klar, wenn
man betrachtet, wie Transaktionen in Blöcke gepackt und Blöcke miteinander verlinkt werden.
Abbildung 5 veranschaulicht dieses Konzept der Blockbildung.
Abbildung 5 - Von der Transaktion zur Blockkette (eigene Darstellung angelehnt an Egloff & Turnes, 2019)
05. August 2019 14Blockchain – Einführung in die Theorie Damit Transaktionen unveränderbar werden, bilden Blockchains in einem bestimmten Zeitintervall aus den Transaktionen Blöcke, welche chronologisch angeordnet miteinander verbunden werden. Die Blöcke bestehen immer aus einem Block-Header mit Metadaten zum Block und einen Block- Body mit dem Inhalt (Transaktionen) des Blocks. Je nach Blockchain-Protokoll können die Header- daten unterschiedliche Angaben enthalten. Gemäss Egloff und Turnes (2019) müssen im Header zumindest die folgenden Daten enthalten sein: Zeitangabe: Enthält die Zeit, zu welcher der Block erstellt wurde. Dies dient dem Nachweis des Erstellungszeitpunkts und der chronologischen Anordnung der Blocks in der Kette. Hash vorheriger Block: Beim Hinzufügen eines neuen Blocks wird anhand der Header-Daten des vorherigen Blocks ein Hash-Wert berechnet und im neuen Block eingefügt. Durch diese Referenzier- ung bildet sich erst eine Kette und somit die Grundlage für die Unveränderbarkeit von Transaktionen. Nonce: Nonce (kurz für Number Used Once) steht für eine Zufallszahl, die während dem Prozess der Blockbildung bei der Ausführung des Konsensmechanismus definiert wird. Dieser Wert wird für den Konsensmechanismus Proof of Work (kurz PoW) verwendet. In diesem Zusammenhang wird im Block-Header meist auch ein Wert «Difficulty» gespeichert. Dieser Wert definiert das Schwierig- keitslevel, mit dem der Block erzeugt wurde. Mehr dazu gibt es im Abschnitt «Konsensalgorithmen». Transaktionsverweis: Das Feld Transaktionsverweis dient dazu den Block-Header nicht unnötig aufzublähen. An dieser Stelle wird der sogenannte Top-Hash aller im Block gespeicherten Transak- tionen festgehalten. Der Top-Hash ist der oberste Hash eines sogenannten Merkle-Trees. Beim erschaffen eines Merkle-Trees startet man auf der untersten Ebene (Transaktionen), berechnet einzeln deren Hash-Werte und hasht rekursiv immer wieder zwei Hash-Paare bis nur noch der Top- Hash übrigbleibt (Egloff & Turnes, 2019). Im Gegensatz zu Bitcoin basiert Ethereum auf einer etwas komplexeren Variante des Merkle-Trees: Dem sogenannten «Merkle-Patricia-Tree» (Antonopoulus & Wood, 2018). Wenn also jemand eine Transaktion ändern möchte, würden sich dadurch die Hash-Werte im Merkle-Tree und dadurch der Transaktionsverweis ändern. Da der Transaktionsverweis Teil des Block-Headers ist, würde dadurch auch der Header-Hash verändert und der Block und alle nachfol- genden Blocks ungültig. Auf einem zentral geführten System wäre das kein Problem, weil dieses System das «einzig Richtige» ist. Auf einem verteilten System, bei welchem alle Knoten gleich- berechtigt sind und ein Konsens zwischen den Knoten verlangt wird, ist eine solche Manipulation äusserst unwahrscheinlich. Ein solcher Angriff könnte erfolgen, wenn 51% der Knoten oder mehr manipuliert werden (Sixt, 2017). Die Unveränderbarkeit einer Transaktion und damit das Vertrauen 05. August 2019 15
Blockchain – Einführung in die Theorie in eine Blockchain steigen folglich mit der Anzahl unabhängiger voller Knoten eines Blockchain- Netzwerks und der Anzahl nach der Transaktion folgender Blöcke. 2.5.4 Konsensalgorithmen Blockchains bestehen also aus asymmetrisch verschlüsselt durchgeführten Transaktionen, deren Hash-Werte in Blöcke verpackt und auf einem weltweit verteilten Transaktionssystem gespeichert werden. Soweit so gut. Nun gibt es jedoch noch eine Problemstellung, die noch nicht thematisiert wurde. Diese Herausforderung entsteht durch die Verteilung des Systems: Die Synchronizität der partizipierenden Knoten. Bei einem intermediären System passiert die Synchronisation über eine zentrale Stelle. Alle teilnehmenden Knoten oder auch Clients in diesem System vertrauen auf die Korrektheit und Integrität der Daten auf dem zentralen Server. In einem verteilten System, in dem alle Knoten gleichberechtigt sind, kann es unterschiedliche Zustände geben, weil beispielsweise die betreibende Person des Knotens die lokal gespeicherten Daten manipuliert oder einfach weil auf Grund zeitlicher Verzögerungen noch nicht alle Knoten über den neusten Status informiert sind (Egloff & Turnes, 2019, S. 51-52). Dieses Problem ist auch unter dem Begriff «Byzantinischer Fehler» bekannt (Egloff & Turnes, 2019, S. 30). Durch die zeitliche Verzögerung kann es zu sogenanntem «Double Spending» kommen. Das heisst eine Transaktion könnte mehrfach ausgeführt werden, weil zwei verschiedenen Knoten mit unter- schiedlichem Status dieselbe Transaktion erhalten und ausführen. Um solche Fehler zu verhindern, sind verteilte Systeme auf sogenannte Konsensmechanismen (auch Konsensalgorithmen) angewiesen, welche helfen über alle Knoten oder zumindest über eine Mehrheit der Knoten einen Konsens zu schaffen. Dieser wird geschaffen, indem der Knoten, der das Konsensverfahren für sich entscheidet, den Block berechnet und zur Prüfung an alle anderen Knoten sendet. Erklären diese den Block als valide, wird er der Blockchain angehängt (Sixt, 2017, S. 43). Die beiden bekanntesten Mechanismen sind «Proof of Work» (kurz PoW) und «Proof of Stake» (kurz PoS). Die Protokolle Bitcoin und Ethereum verwenden nach aktuellem Stand der Fachliteratur beide einen PoW-Mechanismus. Bei Ethereum wird im Rahmen der Protokoll-anpassung «Casper» ein zumindest teilweiser Wechsel auf ein PoS-Mechanismus geplant (Antonopoulus & Wood, 2018, S. 322; Egloff & Turnes, 2019, S. 124-125). Die beiden Verfahren sind in der Fachliteratur von Egloff und Turnes (2019, S. 55-63) und Antonopoulus und Wood (2018, S. 320-322) beschrieben und werden in den folgenden beiden Abschnitten zusammengefasst. 05. August 2019 16
Sie können auch lesen
