BLOCKCHAIN FÜR UNTERNEHMEN - Masterarbeit zur Erlangung des akademischen Grades - JKU ePUB
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Eingereicht von
Ing. Andreas Rabitsch, BSc
Angefertigt am
Institut für
Wirtschaftsinformatik -
Information Engineering
Beurteiler / Beurteilerin
Univ.-Prof.in Dr.in Barbara
Krumay, Bakk. MSc (WU)
Monat Jahr
März 2021
BLOCKCHAIN
FÜR UNTERNEHMEN
Eine Analyse aus Kundensicht
Masterarbeit
zur Erlangung des akademischen Grades
Master of Science
im Masterstudium
Wirtschaftsinformatik
JOHANNES KEPLER
UNIVERSITÄT LINZ
Altenberger Straße 69
4040 Linz, Österreich
www.jku.at
DVR 0093696
EIDESSTATTLICHE ERKLÄRUNG Ich erkläre an Eides statt, dass ich die vorliegende Masterarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Masterarbeit ist mit dem elektronisch übermittelten Textdokument identisch. Steyr, 30.03.2021 Ort, Datum Unterschrift 30. März 2021 Andreas Rabitsch 2/77
Inhaltsverzeichnis
1. Einleitung ........................................................................................................................................... 9
2. Aktueller Stand des Wissens........................................................................................................... 10
2.1. Netzwerk-Architekturen............................................................................................................ 10
2.2. Kryptographie ........................................................................................................................... 11
2.3. Blockchain-Technologie ........................................................................................................... 13
2.3.1. Blockchain-Transaktionsablauf .................................................................................... 16
2.3.2. Blockchain-Kategorisierung .......................................................................................... 17
2.3.3. Blockchain-Konsensus ................................................................................................. 18
2.3.4. Smart Contracts ............................................................................................................ 24
2.3.5. Blockchain-Architektur .................................................................................................. 24
2.3.6. Blockchain-Abgrenzung................................................................................................ 26
2.4. Cloud Computing ..................................................................................................................... 29
2.4.1. Infrastructure-as-a-Service (IaaS) ................................................................................ 29
2.4.2. Platform-as-a-Service (PaaS)....................................................................................... 30
2.4.3. Software-as-a-Service (SaaS)...................................................................................... 30
2.4.4. Blockchain-as-a-Service (BaaS) .................................................................................. 30
3. Forschungsmethode ........................................................................................................................ 31
3.1. Design Science Research........................................................................................................ 31
4. Ergebnisse ....................................................................................................................................... 33
4.1. Vorläufiges Artefakt.................................................................................................................. 33
4.2. Experteninterview..................................................................................................................... 34
4.2.1. Interviewleitfaden .......................................................................................................... 34
4.3. Ergebnisse des Interviews ....................................................................................................... 35
4.4. Finales Artefakt - Kriterienkatalog............................................................................................ 39
4.4.1. Skalierbarkeit ................................................................................................................ 40
4.4.2. Interoperabilität ............................................................................................................. 40
4.4.3. Nachhaltigkeit ............................................................................................................... 41
4.4.4. Governance .................................................................................................................. 42
4.4.5. Programmiersprachen für ausführbaren Code ............................................................ 42
4.4.6. Tokenisierung ............................................................................................................... 42
4.4.7. DSGVO-Lösungsansätze ............................................................................................. 43
4.5. Ergebnisse aus der Anwendung des Artefakts ....................................................................... 43
4.5.1. Ethereum....................................................................................................................... 43
4.5.2. Hyperledger Fabric ....................................................................................................... 49
30. März 2021 Andreas Rabitsch 3/77
4.5.3. Quorum ......................................................................................................................... 55
4.5.4. Multichain ...................................................................................................................... 57
4.5.5. Übersicht der Ergebnisse ............................................................................................. 60
5. Diskussion........................................................................................................................................ 61
5.1. BaaS-Plattformen ..................................................................................................................... 62
5.1.1. Amazon AWS Managed Blockchain............................................................................. 62
5.1.2. Microsoft Azure Blockchain Service ............................................................................. 63
5.1.3. Oracle BaaS.................................................................................................................. 64
5.1.4. SAP HANA BaaS .......................................................................................................... 64
5.2. Gegenüberstellung der Plattformen......................................................................................... 65
6. Zusammenfassung und Ausblick .................................................................................................... 67
Literatur ................................................................................................................................................... 69
30. März 2021 Andreas Rabitsch 4/77
Abbildungsverzeichnis Abbildung 1 - Zentralisierte, dezentralisierte, verteilte Netzwerke (Baran, 1964) ................................. 10 Abbildung 2 - Merkle-Baum Datenstruktur (Gamage et al., 2020)......................................................... 12 Abbildung 3 - Digitale Signaturen in der Public-Key-Kryptographie (Badev & Chen, 2014) ................. 13 Abbildung 4 - Struktur eines Blocks (Zheng et al., 2017)....................................................................... 14 Abbildung 5 - Struktur einer Transaktion (Ghosh et al., 2020) .............................................................. 15 Abbildung 6 - Blockchain Transaktion; in Anlehnung an (Patel, Bothra, und Patel 2017) .................... 16 Abbildung 7 - Blockchain Kategorisierung; in Anlehnung an Baumann et al. (2017) ............................ 18 Abbildung 8 - Proof of Work Ablauf; in Anlehnung an Zhang & Lee (2019) .......................................... 19 Abbildung 9 - Proof of Stake Ablauf; in Anlehnung an Zhang & Lee (2019) ......................................... 20 Abbildung 10 - Practical Byzantine Fault Tolerance Ablauf (Liu et al., 2019) ....................................... 21 Abbildung 11 - Aura Ablauf (Angelis et al., 2017) .................................................................................. 22 Abbildung 12 - Clique Ablauf (Angelis et al., 2017)................................................................................ 22 Abbildung 13 - Auswahl der Authorities, die in Clique Blöcke vorschlagen dürfen (Angelis et al., 2017) ................................................................................................................................................................. 23 Abbildung 14 - Blockchain Architektur; in Anlehnung an Acharya et al. (o. J. ) .................................... 25 Abbildung 15 - Blockchain als DLT-Typ (Dhal, 2020) ............................................................................ 26 Abbildung 16 - Flussdiagramm - Notwendigkeit einer Blockchain (Wust & Gervais, 2018).................. 28 Abbildung 17 - Cloud-Computing Architekturschichten (Kushida et al., 2015)...................................... 29 Abbildung 18 - Lokalisierung von BaaS (Onik & Miraz, 2019) ............................................................... 30 Abbildung 19 - Design Science Research Zyklen (A. Hevner & Chatterjee, 2010)............................... 31 Abbildung 20 - Vorläufiges Artefakt - Kriterien ....................................................................................... 33 Abbildung 21 - Finales Artefakt - Kriterien.............................................................................................. 40 Abbildung 22 - Energieverbrauch pro Transaktion für verschiedene Architekturen (Sedlmeir et al., 2020) ....................................................................................................................................................... 41 Abbildung 23 - Beispiel für ein genesis.json File, Clique Konsens (Lange & Schmideg, 2020) ........... 44 Abbildung 24 - Ethereum Transaktionsraten (tps) (Toyoda et al., 2020) ............................................. 45 Abbildung 25 - Ethereum Latenzzeit der Transaktionen (Toyoda et al., 2020) ..................................... 45 Abbildung 26 - Polkadot's Stack (Belchior et al., 2020) ......................................................................... 47 Abbildung 27 - Struktur des Hyperledger Fabric Blockchain Netzwerks (Manevich et al., 2018) ......... 50 Abbildung 28 - Hyperledger Fabric Deployment Modell mit Entwicklungstools (Kuzlu et al., 2019)..... 51 Abbildung 29 - Hyperledger Fabric Transaktionsraten (tps) (Kuzlu et al., 2019) .................................. 51 Abbildung 30 - Interledger Protokoll Schichten (Interledger Project, o. J.)............................................ 52 Abbildung 31 - Einordnung der Hypleredger-Projekte und -Technologien unter das größere Dach der Linux Foundation (Dhillon et al., 2017)................................................................................................... 53 Abbildung 32 - Hyperledger Fabric: Peers betrachten unterschiedliche Daten im selben Channel (Hyperledger, 2020) ................................................................................................................................ 54 Abbildung 33 - Quorum Architektur (A. Baliga et al., 2018) ................................................................... 55 Abbildung 34 - Quorum Transaktionsraten (tps) (A. Baliga et al., 2018)............................................... 56 Abbildung 35 - Quorum Latenzzeit der Transaktionen (A. Baliga et al., 2018) .................................... 56 Abbildung 36 - Multichain Architektur (Ismailisufi et al., 2020) .............................................................. 58 Abbildung 37 - Amazon Managed Blockchain BaaS (Amazon, 2020) .................................................. 63 Abbildung 38 - Azure Blockchain Service Komponenten (Microsoft, 2020) .......................................... 63 Abbildung 39 - Oracle Blockchain Cloud Service Komponenten (Oracle, o. J.-b) ................................ 64 Abbildung 40 - SAP HANA BaaS-Komponenten (Schuster, 2018) ....................................................... 65 Abbildung 41 - Gesamtanalyse Blockchain-Plattformen ........................................................................ 67 30. März 2021 Andreas Rabitsch 5/77
Tabellenverzeichnis Tabelle 1 - Design Science Research Schritte ....................................................................................... 32 Tabelle 2 - Übersicht der Interview-Frageblöcke ................................................................................... 34 Tabelle 3 - Auswertung der Blockchain-Plattformen .............................................................................. 60 Tabelle 4 - Blockchain-Angebote der BaaS-Anbieter ............................................................................ 65 30. März 2021 Andreas Rabitsch 6/77
Abkürzungen API Application Programming Interface AWS Amazon Web Services BaaS Blockchain-as-a-Service BFT Byzantine Fault Tolerance BG Byzantinische Generäle DDoS Distributed Denial of Service DLT Distributed Ledger Technologie DoS Denial of Service DSGVO Datenschutzgrundverordnung EIP Ethereum Improvement Proposal EVM Ethereum Virtual Machine IaaS Infrastructure-as-a-Service IBFT Istanbul Byzantine Fault Tolerance ID Identifikation ILP Interledger Protokoll JSON JavaScript Object Notation KMU Kleine und mittlere Unternehmen NIST Nationales Institut für Standards und Technologie Nonce Number used once P2P Peer-to-Peer PaaS Platform-as-a-Service PBFT Practical Byzantine Fault Tolerance PoA Proof-of-Authority PoS Proof-of-Stake PoW Proof-of-Work SaaS Software-as-a-Service SHA Secure Hash Algorithm STXO Spent Transaction Output TXN Transaktion TXNID Transaktionsidentifikation UTXO Unspent Transaction Output WASM WebAssembly Zk-snark Zero knowledge Succinct Non-Interactive Arguments of Knowledge 30. März 2021 Andreas Rabitsch 7/77
Kurzfassung Im Rahmen der vorliegenden Masterarbeit werden aktuelle Blockchain-Netzwerke, die speziell für die Verwendung in einer privaten Umgebung geeignet sind, analysiert. Zunächst werden auf Basis herangezogener Literatur die Grundlagen der Blockchain Architektur erläutert. Dies umfasst Themen wie die in einem Blockchain Netzwerk eingesetzten kryptographischen Schemata, die Datenstruktur einer Blockchain, die unterschiedlichen Ausprägungen in denen Blockchains betrieben werden können, sowie eine Abgrenzung zu herkömmlichen Datenbank-Lösungen. Mit Hilfe eines qualitativen Interviews wird anschließend ein Kriterienkatalog erarbeitet, der im weiteren Verlauf für die Analyse der bekanntesten privaten Blockchain-Plattformen Verwendung findet. Diese Analyse umfasst Eigenschaften wie Skalierbarkeit, Interoperabilität, Nachhaltigkeit, Governance, sowie die in den jeweiligen Blockchain Netzwerken zum Einsatz kommenden Programmiersprachen, es werden vorhandene Möglichkeiten bzw. Standards zur Tokenisierung aufgezeigt und potentielle DSGVO- Lösungsansätze aufgegriffen. Schlüsselwörter: Blockchain, BaaS, Permissioned, Interoperabilität, Nachhaltigkeit, Governance, Programmiersprachen, Tokenisierung, DSGVO, Skalierbarkeit Abstract Within the scope of this master thesis, current blockchain networks are analyzed that are particularly suitable for the use in a private environment. First, the fundamentals of Blockchain architecture are explained based on the literature consulted. This covers topics ranging from the cryptographic schemes used in a blockchain network, the blockchain data structure, the possible types of blockchains, to the differentiation between blockchains and conventional database solutions. A qualitative interview is then used to develop a catalog of criteria, which is further used to analyze the most well-known private blockchain platforms. This analysis includes characteristics such as scalability, interoperability, sustainability, governance, as well as the programming languages used in the respective blockchain networks, and it also identifies existing possibilities and standards for tokenization and addresses potential GDPR solutions. Keywords: Blockchain, BaaS, Permissioned, Interoperability, Sustainability, Governance, Programming Languages, Tokenization, GDPR, Scalability 30. März 2021 Andreas Rabitsch 8/77
1. Einleitung Mit dem Hype um Kryptowährungen, der in den letzten Jahren dramatisch zugenommen hat, ist auch das Interesse an der Blockchain-Technologie als verteilte, sichere Datenbank stetig gewachsen. Einige Beispiele für nicht-monetäre Anwendungen sind nach Onik & Miraz (2019) die Wertpapierabwicklung, Personalmanagement, Supply Chain, Gesundheitswesen, die Verwaltung persönlicher Daten und vieles mehr. Gerade in Anbetracht von Problemen in Bezug auf Skalierbarkeit und Zuverlässigkeit zentralisierter Systeme, bewegt sich die digitale Welt hin zu verteilten Systemen. Aufgrund von Bitcoin und anderen Kryptowährungen haben vor allem öffentliche Blockchain- Netzwerke an Bekanntheit erlangt. Jedoch gibt es noch eine andere Ausprägung von Blockchains, die als private oder permissioned Blockchains bezeichnet werden und die in den letzten Jahren zunehmend an Popularität gewonnen haben (Nadir, 2019). Dies ist darauf zurückzuführen, dass einige Eigenschaften öffentlicher Blockchain Plattformen für bestimmte Geschäftsanwendungen ungeeignet sind. Das Konzept der privaten Blockchain erlaubt nur jenen Computern, denen die Erlaubnis erteilt wurde, am Netzwerk teilzunehmen. Zudem werden Transaktionen in einem weit schnelleren Tempo verarbeitet (Pongnumkul et al., 2017). Da jedoch viele (vor allem kleine und mittlere) Unternehmen gar nicht die notwendigen Ressourcen haben um ihre eigenen Blockchain- Projekte umzusetzen, hat sich unter den aktuellen Cloud Service Anbietern der Trend entwickelt, vorhandene Blockchain-Lösungen als „as a Service“-Modell anzubieten (Kobylinska & Martins, 2020). Nach derzeitigem Kenntnisstand gibt es keine Literatur, die sich sowohl mit aktuellen privaten Blockchain-Plattformen als auch mit verfügbaren Blockchain-as-a-Service-Lösungen befasst und diese aus der Sicht des Kunden analysiert. Ausgehend von der Problemstellung ist es das Ziel dieser Arbeit, aktuelle private Blockchain- Plattformen anhand geeigneter Kriterien zu analysieren, um potenziellen Nutzern eine fundierte Orientierungshilfe zu bieten. Im Zuge dieser Analyse werden die zurzeit prominentesten Enterprise- Blockchain-Lösungen auf Basis eines zuvor erstellten Artefakts betrachtet und entsprechend evaluiert. Auf Basis der Zielsetzung der Arbeit leitet sich die folgende Forschungsfrage ab: Welche Anforderungen werden im Kontext von Blockchain Architekturen und Blockchain-as-a-Service Lösungen von Seiten des Kunden gestellt? Der Inhalt der vorliegenden Arbeit gliedert sich dabei in 5 Kapitel, deren Zusammenhänge nachfolgend beschrieben werden. Kapitel 2 ist dem aktuellen Stand des Wissens gewidmet und betrachtet die theoretischen Grundlagen. Ausgehend von den verschiedenen Netzwerktypen und den Grundlagen der Kryptographie, werden weiters die Datenstruktur einer Blockchain, die wesentlichen Elemente einer Blockchain sowie deren Funktionsweise betrachtet. Darüber hinaus werden die unterschiedlichen Ausprägungen, in denen Blockchains betrieben werden können, sowie die unterschiedlichen Arten der Block-Validierung bzw. Konsens-Erstellung diskutiert und eine Abgrenzung zu herkömmlichen Datenbank-Lösungen vorgenommen. Kapitel 3 ist daraufhin der verwendeten Methodik sowie der geplanten Vorgehensweise gewidmet. In Kapitel 4 erfolgt die Auswertung der Ergebnisse, bestehend aus einer Reihe von Teilergebnissen. Zuerst wird auf Basis einer umfangreichen Literaturrecherche ein vorläufiges Artefakt erstellt. Weiters beinhaltet dieses Kapitel die Planung sowie die Durchführung des Experteninterviews. Aufbauend auf diesem Interview, sowie unter Einbeziehung aktueller Literatur, wird das finale Artefakt – in Form eines Kriterienkataloges - erstellt. Dieser Kriterienkatalog bildet die Grundlage für die Bewertung der bekanntesten privaten Blockchain-Plattformen, was 30. März 2021 Andreas Rabitsch 9/77
ebenfalls in diesem Kapitel erfolgt. Kapitel 5 diskutiert die Vor- und Nachteile der Nutzung eines
Blockchain-as-a-Service Anbieters im Vergleich zu einer selbstgehosteten Blockchain. Darüber hinaus
gibt dieses Kapitel einen Einblick in die aktuellen Angebote der bekanntesten Cloud-Service-Anbieter
und zeigt, welche Blockchain-Plattformen von welchen Anbietern bereitgestellt werden. Das Kapitel
endet mit einer Bewertung der Ergebnisse, die durch die Anwendung des Artefakts erzielt wurden,
zeigt aber auch die Limitationen dieser Ergebnisse auf. Den Abschluss dieser Arbeit bildet Kapitel 6
mit konkreten Vorschlägen, wie auf den Ergebnissen dieser Arbeit in Zukunft aufgebaut werden kann
bzw. Empfehlungen für zukünftige Forschungsrichtungen.
2. Aktueller Stand des Wissens
In diesem Kapitel wird zuerst gezeigt, wie sich Blockchain-Netzwerke von existierenden Netzwerk-
Architekturen unterscheiden. Anschließend werden die kryptographischen Methoden, die in der
Blockchain-Technologie von zentraler Bedeutung sind, detailliert beleuchtet. Der dritte Abschnitt
widmet sich dem strukturellen Aufbau einer Blockchain, erklärt, wie zwischen den Teilnehmern eines
Blockchain-Netzwerks ein Konsens erreicht werden kann und zeigt, wie Aktionen mithilfe von auf der
Blockchain abgelegten Skripten automatisiert werden können. Der letzte Abschnitt beschäftigt sich mit
Cloud Computing und seinen verschiedenen Servicemodellen und gibt Auskunft darüber, in welcher
Schicht sich eine Blockchain als "as-a-Service"-Modell einordnen lässt.
2.1. Netzwerk-Architekturen
Netzwerke lassen sich nach Baran (1964) allgemein in zwei Komponenten einteilen: zentralisiert
(Stern) und verteilt (Grid oder Mesh) – siehe Typ (a) und (c) in Abbildung 1. Üblicherweise wird für
Kommunikationsnetze häufig auch eine Mischung aus Stern- und Mesh-Komponenten verwendet, wie
in Abbildung 1(b) dargestellt. So zeigt dieser Typ b eine hierarchische Struktur einer Menge von
Sternen, die zu einem größeren Stern verbunden sind, wobei eine zusätzliche Verbindung eine
Schleife bildet. Ein solches Netz wird manchmal als "dezentralisiertes" Netz bezeichnet, weil nicht
immer die vollständige Abhängigkeit von einem einzigen Punkt erforderlich ist (Baran, 1964).
Abbildung 1 - Zentralisierte, dezentralisierte, verteilte Netzwerke (Baran, 1964)
30. März 2021 Andreas Rabitsch 10/77Die Debatte über zentralisierte vs. dezentralisierte vs. verteilte Systeme ist sowohl für Einzelpersonen
als auch für Organisationen relevant, da sie fast jeden betrifft, der das Web nutzt. Sie steht im
Mittelpunkt der Entwicklung und Evolution von Netzwerken, Finanzsystemen, Unternehmen,
Anwendungen, Webdiensten und anderen Bereichen (Berty Technologies, 2019).
Innerhalb eines zentralisierten Systems sind alle Benutzer mit einem zentralen Server verbunden,
welcher sämtliche Daten und Benutzerinformationen speichert. Ein solches zentralisiertes System ist
einfach einzurichten und kann schnell entwickelt werden. Nun hat dieses System aber auch
wesentliche Einschränkungen. Kommt es zum Beispiel zu einem Serverabsturz, funktioniert das
System nicht mehr richtig und die Benutzer können nicht auf die Daten zugreifen. Weiters benötigt ein
zentralisiertes System einen zentralen Eigentümer, wodurch die Verfügbarkeit für Benutzer/Geräte
von diesem Eigentümer abhängt. Hinzu kommen Sicherheitsbedenken, da der Eigentümer
Benutzerdaten speichert und auf diese auch zugreifen kann (Berty Technologies, 2019).
Dezentrale Systeme haben dagegen nicht einen zentralen Eigentümer, sondern mehrere zentrale
Eigentümer, von denen jeder eine Kopie der Ressourcen speichert, auf die der Benutzer zugreifen
kann. Wenn ein oder mehrere zentrale Eigentümer oder Server ausfallen, können die anderen den
Benutzern weiterhin den Datenzugriff ermöglichen. Da Knoten in verschiedenen Regionen erstellt
werden können, ist auch die Zugriffszeit auf die Daten oft schneller als bei zentralisierten Systemen.
Dennoch sind auch bei dezentralen Systemen dieselben Sicherheits- und Datenschutzrisiken für die
Benutzer vorhanden (Berty Technologies, 2019).
Ein verteiltes System ist einem dezentralen System insofern ähnlich, als es keinen zentralen
Eigentümer hat, geht aber noch einen Schritt weiter und eliminiert die Zentralisierung vollständig. In
einem solchen System haben die Benutzer gleichberechtigten Zugriff auf die Daten und
Benutzerrechte können bei Bedarf aktiviert werden. Nicht nur das Eigentum an den Daten selbst kann
geteilt werden, sondern auch die Hardware- und Software-Ressourcen können unter den Benutzern
aufgeteilt werden (Berty Technologies, 2019).
Als Unterkategorie dieser verteilten Systeme werden so genannte Peer-to-Peer Systeme (auch als
Peer-to-Peer-Computing oder Peer-to-Peer-Networking bezeichnet) verstanden. In einem solchen
System werden alle Knoten, die Teil des Systems sind, als gleichwertig betrachtet, was zwar für mehr
Robustheit im Falle von Ausfällen sorgt, aber gleichzeitig aufgrund der fehlenden (zentralen)
Organisation und (zentralen) Kontrolle neue Herausforderungen an das Netzwerk stellt. Auch die
Organisation eines Peer-to-Peer-Netzwerks in Anwesenheit von böswilligen Peers ist keine einfache
Aufgabe. Die Blockchain Technologie, wie sie mit Bitcoin populär geworden ist, macht sich das
gegenseitige Misstrauen der Peers in einem Netzwerk zunutze, um durch gemeinsame
Anstrengungen einen kollektiv vereinbarten Konsens zu erreichen (Meessen, 2017).
2.2. Kryptographie
Eine Blockchain stützt sich nach Badev & Chen (2014) auf zwei kryptografische Schemata, die im
folgenden Abschnitt analysiert werden: Hash-Funktionen und digitale Signaturen.
Eine kryptographische Hash-Funktion erhält als Eingabe eine Zeichenfolge von beliebiger Länge und
gibt eine Zeichenfolge mit vorgegebener Länge zurück. Es handelt sich dabei um eine
deterministische Funktion, was bedeutet, dass die gleiche Eingabe x immer die gleiche Ausgabe y
ergibt (Badev & Chen, 2014).
30. März 2021 Andreas Rabitsch 11/77Nach Rogaway & Shrimpton (2004) müssen Hash-Funktionen die folgenden Eigenschaften erfüllen:
• preimage resistance (zu Deutsch: Einwegfunktion):
Es darf rechnerisch nicht möglich sein, zu einem gegebenen Ausgabewert y einen
Eingabewert x zu finden, welchen die Hashfunktion auf y abbildet: h(x) = y.
• 2nd-preimage resistance (zu Deutsch: Schwache Kollisionsresistenz):
Es darf rechnerisch nicht möglich sein, einen zweiten Eingabewert zu finden, der auf
denselben Ausgabewert abgebildet wird, d.h. bei gegebenem x darf es nicht möglich sein, ein
zweites x zu finden, sodass h(x) = h(x).
• Starke Kollisionsresistenz:
Es darf rechnerisch nicht möglich sein, zwei unterschiedliche Eingabewerte zu finden, die auf
denselben Ausgabewert haben, d.h. sodass h(x) = h(x).
Durch diese Eigenschaften wird die Hash-Funktion zu einem leistungsfähigen Werkzeug zur
Verifizierung der Integrität von Daten. Innerhalb eines Blockchain-Systems wird jedes Mal, wenn ein
Block hinzugefügt wird, ein Hash des vorherigen Blocks in den neuen Block aufgenommen. Dadurch,
dass der aufgezeichnete Hash gegen den Hash der vorherigen Blöcke geprüft wird, kann leicht
festgestellt werden, ob Daten geändert wurden, ohne jede Transaktion einzeln zu verifizieren (de
Filippi & Mcmullen, 2018). Bei der Blockchain-Technologie werden nicht nur die Blöcke in einen Hash-
Wert umgewandelt, sondern auch die einzelnen Transaktionen, die in einem Block gebündelt werden.
Die Transaktionen in einem Block werden dabei solange paarweise gebündelt und erneut gehashed,
bis ein einziger Hash-Wert entsteht, der sogenannte Merkle Root Hash, siehe Abbildung 2
(Rosenberger, 2018).
Abbildung 2 - Merkle-Baum Datenstruktur (Gamage et al., 2020)
Ein Merkle Baum, benannt nach dessen Entdecker Ralph Merkle, ist eine sehr effiziente
Datenstruktur, um die Existenz bestimmter Daten innerhalb eines Baumes zu überprüfen. Ist ein Block
mit Transaktionsdaten einmal in der Blockchain bestätigt, wird das Ändern, Löschen oder Verändern
von Daten rechnerisch unmöglich. Durch das Ändern von Transaktionsdaten in einem Block wird der
Root-Hash des Merkle-Baums, der im Block-Header gespeichert ist, geändert, somit wird der Block
von den anderen Knoten im Netzwerk abgelehnt (Gamage et al., 2020).
30. März 2021 Andreas Rabitsch 12/77Neben den Hash-Funktionen stellen digitale Signaturen ein weiteres unverzichtbares kryptografisches
Primitiv in Blockchain-Systemen dar. Dieses Konzept der digitalen Signatur wurde 1976 von Diffie und
Hellman vorgestellt, nachdem sie das Tor zur Public-Key-Kryptografie geöffnet hatten (L. Wang et al.,
2019). Durch diese digitalen Signaturen kann eine Nachricht zwischen einem Absender und einem
Empfänger authentifiziert werden (Badev & Chen, 2014). Dabei erfüllt eine digitale Signatur nach
Antonopoulos (2017) in einem Blockchain-Netzwerk die folgenden drei Zwecke:
Erstens beweist die Signatur, dass der Besitzer des privaten Schlüssels die Ausgabe der Gelder
autorisiert hat. Zweitens ist der Nachweis der Autorisierung unbestreitbar (Nicht-Abstreitbarkeit). Und
drittens beweist die Signatur, dass die Transaktion von niemandem verändert wurde und auch nicht
verändert werden kann. Abbildung 3 veranschaulicht nun den Prozess des digitalen Signierens einer
Nachricht. Um die Signatur c zu erzeugen, wird über die „sign“-Funktion die Nachricht (m) mit dem
privaten Schlüssel (pa) des Senders kombiniert bzw. die Nachricht mit dem privaten Schlüssel signiert.
Bevor der Empfänger diese Nachricht nun akzeptiert, wird über die „verify“-Funktion der öffentliche
Schlüssel des Senders (pk) verwendet, um die Signatur (c) und die Original-Nachricht (m) miteinander
zu vergleichen (Badev & Chen, 2014).
Abbildung 3 - Digitale Signaturen in der Public-Key-Kryptographie (Badev & Chen, 2014)
Diese Public-Key-Kryptographie ist ein weiterer wichtiger Baustein in jedem Blockchain-System. Ein
Schlüsselpaar aus öffentlichem und privatem Schlüssel definiert den Besitz von Vermögenswerten.
Lediglich die Person, die den entsprechenden privaten Schlüssel kontrolliert, kann ein Asset
verwenden, das mit einem bestimmten öffentlichen Schlüssel verknüpft ist (de Filippi & Mcmullen,
2018).
2.3. Blockchain-Technologie
Nachdem die kryptographischen Grundlagen erläutert wurden, gibt dieser Abschnitt einen Einblick in
die Struktur einer Blockchain. Die Blockchain-Technologie erschien erstmals mit der Veröffentlichung
des Bitcoin-Whitepapers im Jahr 2008. Bitcoin war der erste erfolgreiche Versuch, eine dezentrale
digitale Währung zu implementieren, die die Möglichkeit bot, vollständig irreversible Transaktionen,
ohne eine vertrauenswürdige und zentralisierte dritte Partei durchzuführen. Zusammen mit einem
hashbasierten Arbeitsnachweis, Kryptographie mit öffentlichen Schlüsseln und einem Peer-to-Peer-
30. März 2021 Andreas Rabitsch 13/77Netzwerk, war das Blockchain-Konzept ein inhärenter Bestandteil dieser Dezentralisierung (Gamage
et al., 2020). Im Wesentlichen handelt es sich bei einer Blockchain um eine verteilte Datenbank mit
getätigten Transaktionen, die zwischen den beteiligten Parteien ausgetauscht wurden. Dabei wird jede
Transaktion durch den Konsens einer Mehrheit der Systemteilnehmer verifiziert. Einmal im Block
verifiziert, ist es nahezu unmöglich, die Einträge zu verändern oder zu löschen (Patel et al., 2017).
Ein Block enthält einen Block-Header und Blockdaten. Der Block-Header enthält Metadaten für diesen
Block, die Blockdaten enthalten eine Liste der validierten Transaktionen (Yaga et al., 2018).
Folgende Daten befinden sich nach Z. Zheng et al. (2017) in einem Block:
Abbildung 4 - Struktur eines Blocks (Zheng et al., 2017)
• Block Version: Gibt an, welcher Satz von Blockvalidierungsregeln zu befolgen ist.
• Merkle Tree Root Hash: Der Hash-Wert aller Transaktionen in einem Block.
• Timestamp: Zeitpunkt, wann der Block generiert wurde. (als Sekunden in Universalzeit seit
dem 1.Januar 1970)
• nBits: Ziel-Grenzwert eines gültigen Blockhashs.
• Nonce: ein 4-Byte-Feld, das in der Regel mit 0 beginnt und für jede Hash-Berechnung erhöht
wird. Der Wert muss so eingestellt werden, dass der Hash des Blocks eine Serie von Nullen
enthält. Jede Änderung der Daten, sowie des Nonce Feldes, verändert den Hash (wird in
Abschnitt 2.3.3. Blockchain-Konsensus genauer erläutert).
• Parent Block Hash: Ein 256-Bit-Hash-Wert, der auf den vorherigen Block zeigt. Die Bitcoin-
Blockchain verwendet den SHA-256 Hash-Algorithmus, welcher Daten, wie z.B.
Transaktionen, in eine zufällige Zeichenfolge verwandelt.
• TX: Inhalt hängt davon ab, für welchen Dienst die Blockchain in Verwendung ist, zum Beispiel
Transaktionen, Datensätze, Bankverrechnungssätze, Vertragsunterlagen etc.
(Z. Zheng et al., 2017)
Bei einer Transaktion handelt es sich nach Vallois & Guenane (2017) um eine Datenstruktur, die die
Übergabe von digitalen Vermögenswerten (Token) zwischen zwei Parteien speichert. Die Daten, aus
denen sich eine Transaktion zusammensetzt, können sich bei jeder Blockchain-Implementierung
unterscheiden, der zugrunde liegende Mechanismus ist jedoch weitgehend derselbe. Die Nutzer eines
Blockchain-Netzwerks senden Informationen an das Blockchain-Netzwerk. Die versendeten
30. März 2021 Andreas Rabitsch 14/77Informationen können die Adresse des Absenders (oder eine andere relevante Kennung), den
öffentlichen Schlüssel des Absenders, eine digitale Signatur, Transaktionsinputs und
Transaktionsoutputs enthalten (Yaga et al., 2018).
Folgende Daten befinden sich nach Ghosh et al. (2020) in einer Transaktion:
Abbildung 5 - Struktur einer Transaktion
(Ghosh et al., 2020)
• Amount: Summe der digitalen Werte, die übertragen werden sollen.
• Txn ID: Die Txn ID kann eine Transaktions-ID bzw. ein -Hash-Wert sein und dient der
Authentifizierung der Transaktion (Ghosh et al., 2020).
• Input: Inputs einer Transaktion identifizieren nach Antonopoulos (2017) welcher ‚unspent
transaction output‘ (UTXO) genutzt werden soll und stellen über eine digitale Signatur sowie
dem Public Key des Senders den Eigentumsnachweis sicher. Die digitalen Besitztümer können
entweder in neue, mit geringerem Wert, aufgeteilt werden oder zusammengelegt werden, um
einen Vermögenswert mit höherem Wert zu schaffen (Ghosh et al., 2020).
• Output: Jede Bitcoin Transaktion erzeugt einen Output, der in der Blockchain aufgezeichnet
wird. Diese werden im Netzwerk erkannt und stehen dem Besitzer zur Ausgabe in einer
zukünftigen Transaktion zur Verfügung (Antonopoulos, 2017). Der Output besteht aus dem
digitalen Vermögenswert, einer eindeutigen Identität des Empfängers und bestimmten Regeln,
die der Empfänger nicht verletzen sollte, um den festgelegten Wert zu erhalten (Ghosh et al.,
2020). Ein Output einer Transaktion kann dabei entweder als unspent transaction output
(UTXO) kategorisiert werden, wenn er noch nicht von einer nachfolgenden Transaktion
referenziert wurde, oder als spent transaction output (STXO), wenn dieser bereits referenziert
wurde (Tschorsch & Scheuermann, 2016).
Auch wenn Transaktionen in erster Linie zur Übertragung von digitalen Vermögenswerten verwendet
werden, können sie auch ganz allgemein zur Übertragung von Daten genutzt werden. Ein einfacher
Fall könnte sein, dass jemand einfach nur Daten dauerhaft und öffentlich in der Blockchain
veröffentlichen möchte. Anders bei Smart-Contract-Systemen (siehe Abschnitt 2.3.4. Smart
Contracts), hier können Transaktionen verwendet werden, um Daten zu senden, diese Daten zu
verarbeiten und das Ergebnis auf der Blockchain zu speichern (Yaga et al., 2018).
30. März 2021 Andreas Rabitsch 15/772.3.1. Blockchain-Transaktionsablauf
Benutzer des Blockchain-Netzwerks senden über eine Software (z. B. eine Desktop-Anwendung) eine
Transaktion an alle Knoten innerhalb des Blockchain-Netzwerks. Sobald ein Knoten einen Block
veröffentlicht, werden die Transaktionen der Blockchain hinzugefügt (Yaga et al., 2018).
Abbildung 6 - Blockchain Transaktion; in Anlehnung an (Patel, Bothra, und Patel 2017)
Abbildung 6 zeigt, wie die Abwicklung einer Transaktion in einem Blockchain-Netzwerk abläuft:
1. Transaktion definieren: Zunächst erstellt ein "Sender" eine Transaktion und überträgt diese
in das Netzwerk. Die Transaktion umfasst die öffentliche Adresse des Empfängers, den Betrag
und eine digitale Signatur zur Überprüfung der Authentizität (Patel et al., 2017).
2. Transaktion verifizieren: Die Knoten im Netzwerk empfangen die Nachricht und
authentifizieren ihre Gültigkeit durch Entschlüsselung der digitalen Signatur. Wenn die
Authentifizierung erfolgreich ist, wird die Transaktion in einem "Pool ausstehender
Transaktionen" platziert (Patel et al., 2017).
3. Block-Erstellung: Diese „ausstehenden Transaktionen“ werden von einem der Knoten im
Netzwerk in einem sogenannten Block zusammengefasst und in einem bestimmten
Zeitintervall zur Validierung ins Netzwerk gesendet (Patel et al., 2017).
4. Block-Validierung: Nun muss der Block vom Netzwerk validiert werden, was einen Konsens
der Mehrheit des Netzwerks erfordert. Verschiedene Blockchain-Netzwerke verwenden
unterschiedliche Blockvalidierungstechniken (Patel et al., 2017). Einige davon werden in
Abschnitt 2.3.3. Blockchain-Konsens vorgestellt.
30. März 2021 Andreas Rabitsch 16/775. Block-Chaining: Sobald der Block und die beinhalteten Transaktionen vom Netzwerk validiert
sind, wird der neue Block in die Blockchain „eingekettet“ und der aktuelle Stand des Ledgers
an das Netzwerk übertragen (Patel et al., 2017).
2.3.2. Blockchain-Kategorisierung
In diesem Abschnitt werden die unterschiedlichen Ausprägungen vorgestellt, in denen Blockchains
betrieben werden können. Die Unterschiede liegen in den Zugriffsrechten für Clients [Zugriff] und der
Möglichkeit neue Transaktionen zu bestätigen [Validierung] (Baumann et al., 2017). Die Entitäten
können mit einem Blockchain-Netzwerk wahlweise lesend oder schreibend interagieren. Ein Leser
beteiligt sich passiv am Transaktions-Prozess, indem er den Inhalt der Datensätze liest bzw.
analysiert. Im Unterschied dazu haben Schreiber die Fähigkeit, die Kette zu erweitern, was
üblicherweise die Teilnahme am Konsens-Protokoll bedeutet (Meng et al., 2018).
Bei einer Public Permissionless Blockchain gibt es weder eine zentrale Behörde, noch hat eine Partei
mehr Befugnisse als der Rest. Jeder kann hier nach Belieben beitreten oder gehen (Sankar et al.,
2017). Mit anderen Worten: „Jeder darf zugreifen und validieren“ (Klebsch, 2019). Die Bitcoin-
Blockchain ist das vermutlich bekannteste Beispiel einer Public-Permissionless Blockchain (Sankar et
al., 2017).
In einem Public Permissioned Blockchain-Netzwerk übernimmt die Validierung der Transaktionen eine
zuvor gewählte „vertrauenswürdige Gruppe“, deren Selektion durch einen festgelegten Wahlprozess
bestimmt wird (Baumann et al., 2017). Mit anderen Worten: „Jeder darf zugreifen, nur Berechtigte
dürfen validieren“ (Klebsch, 2019). Eine möglichst breite Nutzbarkeit für die Blockchain wird dadurch
geschaffen, dass die Lesezugriffsmöglichkeiten öffentlich sind (Baumann et al., 2017).
Die Variante der Private Permissioned Blockchain wird meist auch als "Consortium Blockchain"
bezeichnet. Hier wird genau festgelegt, welche Teilnehmer die Transaktionen einsehen oder Blöcke
bzw. Transaktionen validieren dürfen (Baumann et al., 2017). Mit anderen Worten: „Nur Berechtigte
dürfen zugreifen und validieren“ (Klebsch, 2019). Aufgrund der dadurch geschaffenen Transparenz
bevorzugen vor allem große Organisationen diesen Blockchain-Typ (Baumann et al., 2017).
Private Permissionless Blockchains gelten nach Baumann et al. (2017) hingegen als sehr kritisch zu
betrachten, da man hier weder von der offenen Zugänglichkeit einer Public Blockchain noch von z.B.
der Rollback Möglichkeit einer Permissioned Blockchain profitieren kann. Mit anderen Worten: „Jeder
darf validieren aber nur Berechtigte dürfen zugreifen“ (Klebsch, 2019).
Aus dieser erfolgten Kategorisierung von Blockchain-Netzwerken lässt sich nun die in Abbildung 7
dargestellte Dimensionsmatrix ableiten.
30. März 2021 Andreas Rabitsch 17/77Abbildung 7 - Blockchain Kategorisierung; in Anlehnung an
Baumann et al. (2017)
2.3.3. Blockchain-Konsensus
Das Erreichen eines Konsens in einem Blockchain-Netzwerk stellt sicher, dass sich alle Knoten in
diesem verteilten System auf einen konsistenten, globalen Zustand der Blockchain einigen (Baliga,
2017). Jedoch kann es vorkommen, dass einzelne Knoten abstürzen, sich böswillig verhalten oder die
Netzwerkkommunikation unterbrochen wird. Um sicherzustellen, dass sich alle Knoten darüber einig
sind, in welcher Reihenfolge die Einträge an die Blockchain angehängt werden, führen die Knoten
daher ein fehlertolerantes Konsensprotokoll aus (Cachin & Vukolić, 2017).
Xiao et al. (2020) definieren folgende Anforderungen für einen Blockchain-Konsens:
Terminierung: Jeder ehrliche Knoten hat die Aufgabe, eine Transaktion oder den Block, in dem sich
diese Transaktion befindet, entweder zu verwerfen oder zu akzeptieren.
Zustimmung: Wird ein Block akzeptiert, soll er von jedem Knoten die gleiche Sequenznummer
erhalten.
Gültigkeit: Wenn jeder Knoten die gleiche gültige Transaktion bzw. den gleichen gültigen Block
erhält, sollte dieser in die Blockchain aufgenommen werden.
Integrität: Alle akzeptierten Transaktionen sollten bei jedem ehrlichen Knoten konsistent sein und alle
akzeptierten Blöcke sollten korrekt und in chronologischer Reihenfolge generiert werden.
Wie in Abschnitt 2.3.2. Blockchain-Kategorisierung beschrieben, lassen sich Blockchain-Plattformen in
zwei Haupttypen einteilen – permissionless und permissioned. Während permissioned Blockchains
auf Konsortien ausgerichtet sind und die Teilnahme am Konsensprozess auf ausgewählte
Mitgliedsknoten beschränken, können bei permissionless Blockchain-Netzwerken wie Bitcoin und
Ethereum auch alle anderen Teilnehmer am Konsensprozess teilnehmen (Baliga, 2017).
In der Forschungsliteratur werden mehrere Algorithmen vorgeschlagen, um diese Konsens-Probleme
zu lösen, wobei jeder Algorithmus eine Reihe von Annahmen in Bezug auf Synchronität,
Nachrichtenübertragungen, Ausfälle, bösartige Knoten, Leistung und Sicherheit der ausgetauschten
Nachrichten trifft. Im nachfolgenden Abschnitt werden mit Proof-of-Work (PoW) und Proof-of-Stake
(PoS) die zwei bekanntesten Algorithmen zur Erreichung eines Konsenses in einem permissionless
Blockchain-Netzwerk vorgestellt und anschließend mit Byzantine Fault Tolerance (BFT) und Proof of
Authority (PoA), zwei Konsens-Mechanismen die in permissioned Blockchains zum Einsatz kommen,
verglichen.
Betrachten wir die Bitcoin-Blockchain als Beispiel für eine Blockchain, die mit einem Proof-of-Work-
Algorithmus gesichert ist. Ehe eine Transaktion verifiziert und im Netzwerk verteilt wird, muss
gemäß Tschorsch & Scheuermann (2016) von den Akteuren "Arbeit" geleistet werden. Diese
30. März 2021 Andreas Rabitsch 18/77"Arbeit" besteht aus einem kryptographischen Puzzle, das die Rechenkosten für die Verifizierung von
Transaktionen künstlich erhöht.
Abbildung 8 - Proof of Work Ablauf; in Anlehnung an Zhang & Lee (2019)
Zunächst werden von den Teilnehmern gültige Transaktionen zu einem Block zusammengefasst. Die
Aufgabe besteht nun darin, einen Hash-Wert des gebildeten Blocks zu berechnen und den Nonce-
Wert so anzupassen, dass der Hash-Wert kleiner oder gleich einem bestimmten Zielwert ist. Sobald
ein Teilnehmer einen solchen Nonce-Wert findet, wird der Block im Netzwerk verteilt und alle anderen
Teilnehmer aktualisieren ihre lokale Kopie der Blockchain (Tschorsch & Scheuermann, 2016). Dabei
besteht die einzige erfolgreiche Strategie darin, immer wieder verschiedene Nonce-Werte zu testen,
bis man eine Lösung gefunden hat. Gemäß Tschorsch & Scheuermann (2016) hängt die
Schwierigkeit, eine Lösung zu finden, daher vom Zielwert ab. Je niedriger das Ziel ist, desto geringer
ist die Anzahl der Lösungen und desto schwieriger wird das Rätsel. Diese sogenannte Difficulty wird
beispielsweise im Bitcoin-Protokoll dynamisch alle 2016 Blöcke eingestellt, wodurch im Schnitt alle 10
Minuten ein Block erzeugt wird. Dieser Vorgang des "Suchens nach einem geeigneten Nonce-Wert"
wird auch "Mining" genannt, folglich sind die Teilnehmer, die diese Arbeit verrichten, die sogenannten
"Miner". Die Chance, das Rätsel als Erster zu lösen, ist proportional zum Anteil an der
Gesamtrechenleistung. Die Gewinnchancen sind umso höher, je mehr Rechenleistung zur Verfügung
steht (Tschorsch & Scheuermann, 2016). Die anfängliche Block-Belohnung für die Miner wurde bei
Bitcoin auf 50 Coins (50 BTC) festgelegt. Alle 210.000 Blöcke, d.h. etwa alle vier Jahre (= 210.000 *
10 min), wird die Belohnung halbiert. Diese iterative Halbierung wird fortgesetzt, bis die Mining-
Belohnung unter 10-8 BTC fällt. Dieser Betrag ist die minimale Einheit von Bitcoin, auch bekannt als
satoshi. Ab diesem Zeitpunkt (etwa im Jahr 2140) werden alle jemals existierenden Coins im Umlauf
sein. Von da an erhalten die Miner nur noch die Transaktionsgebühren derjenigen Blöcke, die sie
validiert haben (Tschorsch & Scheuermann, 2016).
Um den Nachteil des hohen Stromverbrauchs von PoW-Algorithmen zu beseitigen, wurde mit Proof-
of-Stake eine Alternative geschaffen, die anstelle der Mining-Operation auf den Besitz der
Kryptowährung im Blockchain-System setzt (Baliga, 2017).
30. März 2021 Andreas Rabitsch 19/77Abbildung 9 - Proof of Stake Ablauf; in Anlehnung an Zhang & Lee (2019) Bei Proof-of-Stake hängt die Wahl des jeweiligen Knotens, der einen neuen Block erzeugt, von der Menge der jeweils gehaltenen Kryptowährung (Stake) und nicht von der Rechenleistung ab (S. Zhang & Lee, 2019). Alternativ kann auch das Münzalter (Münzbetrag x Haltedauer) anstelle der Menge herangezogen werden (Tschorsch & Scheuermann, 2016). Um sicherzustellen, dass kein Teilnehmer vorhersagen kann, wann er an der Reihe ist, wird der sogenannte Validator (Äquivalent zum ‚Miner‘ unter PoW) für die Blockerstellung durch den PoS-Algorithmus pseudozufällig ausgewählt (Baliga, 2017). Analog zu Proof of Work ist für die erfolgreiche Erzeugung eines Blocks auch hier ein Hash- Wert kleiner oder gleich einem bestimmten Zielwert erforderlich. Dieser Hash-Wert wird, mit Ausnahme des Zeitstempels, aus statischen Daten berechnet, somit besteht für die Teilnehmer keine Möglichkeit, das Rätsel mit Hilfe ihrer Rechenleistung schneller als andere zu lösen (Tschorsch & Scheuermann, 2016). Der Unterschied zu Proof-of-Work besteht im Wesentlichen also darin, dass die Knoten nicht wiederholt den Nonce-Wert anpassen müssen um das Rätsel zu lösen, sondern die Höhe des Stakes (bzw. das Münzalter) ausschlaggebend für die Lösung ist (S. Zhang & Lee, 2019). In privaten Blockchain-Netzwerken wie Hyperledger, mit vergleichsweise geringer Toleranz für bösartiges Verhalten, werden nach Salimitari et al. (2020) die auf sogenannten byzantinischen Vereinbarungen basierenden Konsensverfahren verstärkt eingesetzt. Eines der bekanntesten Beispiele hierfür ist der Practical Byzantine Fault Tolerance (PBFT) Konsensmechanismus. Diese Konsensmethoden basieren auf dem Problem der byzantinischen Generäle (BG), welches darin besteht einen Konsens zwischen byzantinischen Generälen in Bezug auf die Angriffsstrategie zu finden, wobei anzunehmen ist, dass einige der Generäle versuchen verräterische Aktionen umzusetzen, um loyale Generäle daran zu hindern einen Konsens zu erreichen (Salimitari et al., 2020). In PBFT ist ein Konsens erreicht, wenn mehr als zwei Drittel aller Knoten dem entsprechenden Block zustimmen. So sollten in einem System mit einem böswilligen Knoten mindestens 4 Knoten vorhanden sein, um einen Konsens erzielen zu können (Salimitari et al., 2020). Die Rollen der einzelnen Knoten können bei PBFT in Client, Primär- und Backup-Knoten unterteilt werden. Wie in Abbildung 10 dargestellt, besteht PBFT aus den fünf Phasen: Request, Pre-prepare, Prepare, Commit und Reply (Liu et al., 2019). 30. März 2021 Andreas Rabitsch 20/77
Abbildung 10 - Practical Byzantine Fault Tolerance Ablauf (Liu et al., 2019) Der Practical Byzantine Fault Tolerance Algorithmus (PBFT) enthält mindestens 3f +1 Gesamtreplikate und 5 Phasen (zwei vollständige Sendephasen) im Normalfallbetrieb (Q. Zhang et al., 2018). S1 wäre in diesem Beispiel der Primär-Knoten und S3 ein fehlerhafter Knoten (faulty node, f). Nachdem der Primär-Knoten eine Anfrage vom Client erhalten hat, kommt die pre-prepare Phase, in welcher der Primär-Knoten die sogenannte pre-prepare Nachricht per Multicast an die anderen Replikate überträgt. Nach Erhalt dieser Nachricht, überprüft diese jeder Knoten auf ihre Gültigkeit, fügt sie in ein lokales Protokoll ein und sendet eine prepare-Nachricht per Multicast an die anderen Replikate. Dies zeigt, dass der Inhalt erhalten und erkannt wurde. In der Prepare-Phase warten die Knoten bis sie 2f prepare-Nachrichten gesammelt haben, die mit der pre-prepare-Nachricht übereinstimmen, senden anschließend eine Commit-Nachricht und gehen in die commit-Phase über. Schließlich wird eine Anzahl von 2f + 1 Commit-Nachrichten gesammelt, um sicherzustellen, dass der Vorschlag des Primär-Knoten auch von genügend Knoten aufgezeichnet, sowie vertrauensvoll ausgeführt werden kann (X. Hao et al., 2018). Sobald ein Knoten 2f + 1 Commit-Nachrichten empfangen hat, antwortet er dem Client und hängt einen neuen Block in der lokalen Blockchain an. Der Prozess ist nun abgeschlossen (K. Zheng et al., 2018). Proof of Authority (PoA) zählt ebenfalls zur Familie der Byzantine Fault Tolerance Konsens- Mechanismen und findet Einsatz in privaten und permissioned Blockchains In diesen Blockchains sind die Validatoren, welche die Transaktionen der Clients sammeln und neue Blöcke erstellen, bekannt (P. K. Singh et al., 2019).Proof of Authority ist vergleichbar mit Proof of Stake, aber anstelle von Coins müssen die Knoten ihre Identität einsetzen. Die Grundidee ist, dass man, wenn man seine Identität aufs Spiel setzt, auch das Recht erhält, Blöcke zu bilden (Comans et al., 2019). Der PoA-Algorithmus vertraut auf einen Satz von N vertrauenswürdigen Knoten, die als ‚Authorities‘ bezeichnet werden. Diese Authorities sind für den Konsens im Netzwerk verantwortlich. Jeder Authority wird eine ID im Netzwerk gegeben und mindestens N/2 + 1 dieser Knoten müssen ‚ehrliche‘ Knoten sein. Ursprünglich wurde PoA als Teil des Ethereum-Ökosystems entwickelt und in den beiden Clients Aura und Clique implementiert, welche im folgenden Abschnitt beschrieben werden (Angelis et al., 2017). Aura ist der PoA-Algorithmus der in Parity, dem Rust-basierten Ethereum-Client, implementiert ist. In der Block proposal Runde, nimmt der Leader l die Transaktionen in einen Block auf und sendet diesen 30. März 2021 Andreas Rabitsch 21/77
an die anderen Authorities. Die anderen Authorities senden den empfangenen Block in der Block
acceptance Runde anschließend an alle anderen Authorities weiter. Stellt sich heraus, dass alle
denselben Block erhalten haben, wird dieser akzeptiert. Nur der aktuelle Leader l darf einen Block
senden, Blöcke von Authorities die nicht der Leader sind werden abgelehnt. Können sich die
Authorities bei der Annahme des Blocks nicht einigen, wird eine Abstimmung ausgelöst und in
weiterer Folge entschieden ob der aktuelle Leader l bösartig ist und dieser ggf. rausgeworfen. Diese
Abstimmung wir über einen Smart Contract (siehe Abschnitt 2.3.4. Smart Contracts) umgesetzt und
eine Mehrheit der Stimmen ist erforderlich, um den aktuellen Leader aus den vertrauenswürdigen
Authorities zu entfernen (Angelis et al., 2017).
Abbildung 11 - Aura Ablauf (Angelis et al., 2017)
Clique ist der PoA-Algorithmus der in Geth, dem Golang-basierten Ethereum-Client, implementiert ist.
Das Vorgehen des Algorithmus erfolgt in Epochen, die durch eine festgelegte Sequenz von
bestätigten Blöcken identifiziert werden. Sobald eine neue Epoche beginnt, wird ein spezieller
Übergangsblock ausgesendet. Dieser bestimmt die Menge der Authorities (d. h. ihre IDs) und kann als
Momentaufnahme der aktuellen Blockchain für die neuen Authorities verwendet werden, die sich erst
synchronisieren müssen. Beim Nachrichtenaustausch sendet der Leader in jedem Durchgang einen
Block aus, der von allen Authorities direkt in die Kette eingefügt wird (Angelis et al., 2017).
Abbildung 12 - Clique Ablauf (Angelis et al., 2017)
30. März 2021 Andreas Rabitsch 22/77Sie können auch lesen
