Bitcoin und Mitbestimmung

Ermöglicht Bitcoin Mitbestimmung bei der Geldpolitik?

Autor:

Frank Schnaible

1. Problemstellung

Fiat-Währungen, wie zum Beispiel der Euro und der Dollar, werden von einer Zentralbank als zentrale Instanz ausgegeben und kontrolliert. Durch die zentrale Kontrolle der Fiat-Währungen entsteht das Problem, dass die Zentralbanken allein über die Fiat-Währungen bestimmen können, während man als einfache, einzelne Person hierbei keine Mitbestimmung hat. Dadurch können Zentralbanken zum Beispiel die Geldmenge beliebig erhöhen. Als Folge davon wird der Wert der bereits im Umlauf befindlichen Geldmenge weniger. Diese Entwertung der bereits im Umlauf befindlichen Geldmenge betrifft jeden Einzelnen, der Geld in dieser Währung besitzt. Jedoch können diese sich nicht dagegen wehren, da sie keine Mitbestimmung haben und nur die Zentralbank als zentrale Instanz über die Geldmengenausweitung bestimmt. Im Endeffekt muss man darauf vertrauen, dass die Zentralbanken ihre zentrale Macht nicht ausnutzen oder missbrauchen (vgl. Pritzker 2019: 5-8). Wenn man aber die Vergangenheit betrachtet, gibt es viele Fälle bei denen Regierungen beziehungsweise Zentralbanken dieses Vertrauen gebrochen haben. Ein Beispiel hierfür ist Venezuela. Die Wirtschaft in Venezuela war sehr stark von den Exporteinnahmen durch Öl abhängig, da diese 90% ihrer Exporteinnahmen ausmachten. Diese Abhängigkeit von den Exporteinnahmen durch Öl führte zu einer Wirtschaftskrise in Venezuela, als der Ölpreis im Jahre 2014 um 30% abstürzte. Die Regierung von Venezuela entschied sich dazu, mehr Geld zu drucken, um die Wirtschaftskrise zu bekämpfen. Jedoch führte das Drucken von mehr Geld nicht zu einer Lösung der Wirtschaftskrise, sondern zu einer Hyperinflation. Im Jahre 2018 erreichte die Inflation in Venezuela 80 000%. Die Folge der Hyperinflation in Venezuela war, dass 9 von 10 Venezolanern in Armut lebten (vgl. Reilly 2020: 19-23).

Dieses Problem besteht bei Bitcoin nicht. Anstelle von einer zentralen Instanz, welche die Währung allein kontrolliert, entscheiden hier die Netzwerkteilnehmer selbst über Regeländerungen (vgl. Pritzker 2019: 60 f.).

Ein weiteres Problem von Fiat-Währungen ist die Notwendigkeit einer zentralen Instanz bei der Verwaltung von digitalem Geld (vgl. Hungerland et. al 2017: 50). Im Zusammenhang mit digitalem Geld ist diese zentrale Instanz zum Beispiel die Bank. Wenn man Geld an eine andere Person transferieren möchte, kann die Bank als zentrale Instanz und Vermittler die Transaktion genehmigen und durchführen oder die Durchführung der Transaktion verweigern (vgl. Pritzker 2019: 8). Die Bank hat somit die Kontrolle über das Geld und entscheidet, ob die Transaktion durchgeführt wird oder nicht.

Bei Bitcoin sind alle Teilnehmer im Netzwerk gleichgestellt. Im Gegensatz zu Fiat-Währungen gibt es keine zentrale Instanz und es braucht auch keinen Vermittler, um Transaktionen durchzuführen. Die Transaktionen werden Peer-to-Peer durchgeführt (vgl. Antonopoulos 2019: 30). Dadurch werden Transaktionen bei Bitcoin nicht durch eine dritte Partei kontrolliert, welche die Transaktionen zensieren könnte. Man hat durch digitale Signaturen selbst die Kontrolle über sein Geld und kann selbst über sein Geld bestimmen. Bei Fiat-Währungen könnte eine Bank das Geld von jemandem gegen seinen Willen einfrieren. Bei Bitcoin gibt es Niemanden, der dies machen könnte (vgl. Antonopoulos 2019: 34).

In dieser Seminararbeit wird die Frage „Ermöglicht Bitcoin Mitbestimmung bei der Geldpolitik?“ behandelt. Hierzu wird die These „Bitcoin ermöglicht den Nutzern Mitbestimmung bei Regeländerungen und vollständige Kontrolle über ihr Vermögen, wobei Bitcoin ohne zentrale Instanz funktioniert“ aufgestellt.

Die Schwerpunkte werden auf die Mitbestimmung bei Bitcoin und wie diese zustande kommt gelegt. Dabei ist ein wichtiger Schwerpunkt die Dezentralität und die Mitbestimmung über die Konsensregeln bei dieser Dezentralität. Ein weiterer Schwerpunkt in der Seminararbeit wird sein, wie man sein Vermögen in Bitcoin mithilfe von digitalen Signaturen selbst vollständig kontrolliert und wie die Technologie dahinter funktioniert. Des Weiteren wird behandelt, wie es bei Bitcoin zu einer Änderung der Konsensregeln kommen kann. Zu den Themen, welche nicht behandelt werden, gehört zum einem das Problem der Skalierung und mögliche Lösungen für dieses Problem. Demzufolge wird das Lightning Netzwerk in diese Seminararbeit nicht miteinbezogen. Des Weiteren werden die wirtschaftlichen Auswirkungen von Bitcoin nicht thematisiert. Zudem werden andere Anwendungen von Blockchains, wie zum Beispiel Smart Contracts, nicht behandelt. Aufgrund des beschränkten Rahmens dieser Seminararbeit werden nicht alle technischen Eigenschaften von Bitcoin behandelt und manche auch nicht im Detail erläutert.

Um die Leitfrage beziehungsweise Leitthese zu beantworten und die Schwerpunkte zu bearbeiten ist die Seminararbeit folgendermaßen aufgebaut. Zu Beginn wird ein Überblick über die Blockchaintechnologie und das Bitcoin Netzwerk gegeben. Anschließend wird auf die Entstehung von Schlüsselpaaren eingegangen. Dies dient auch gleichzeitig als Grundlage für das darauffolgende Kapitel, in welchem Transaktionen und der Eigentumsnachweis mit digitalen Signaturen erklärt wird. Darauffolgend wird behandelt, wie es bei Bitcoin trotz seiner dezentralen Struktur zu einem Konsens kommt und welche Vorteile diese dezentrale Struktur mit sich bringt. Zum Schluss der Seminararbeit wird darauf eingegangen, wie es bei Bitcoin zu einer Änderung der Konsensregeln kommt und wie die Netzwerkteilnehmer hierbei mitbestimmen.

2. Die Blockchaintechnologie und Bitcoin

2.1 Definition und Eigenschaften der Blockchain

Im Grunde ist die Blockchain eine Datenstruktur beziehungsweise Datenbank. Somit können auf der Blockchain Daten gespeichert werden, wie auch auf jeder anderen Datenbank (vgl. Antonopoulos 2018: 197). Anders als andere Datenbanken gehört die Blockchain zu den Distributed-Ledger-Technologien (DLTs). DLTs sind Datenbanken, welche eine Peer-to-Peer Architektur besitzen und eine dezentrale Speicherung von Daten ermöglichen. Dezentral bedeutet, dass die Blockchain nicht von nur einer Instanz gespeichert und betrieben wird, sondern von mehreren sich an verschiedenen Standorten befindenden Nodes. Hierbei hat jede Node eine Kopie der Blockchain und kann diese einsehen und überprüfen. Dadurch gibt es keine zentrale Instanz, welche die Daten speichert und verwaltet (vgl. Märkel et. Al. 2021: 4, Mindlberger 2019: 13). Im Vergleich zu anderen zentralen Datenbanken liegt der Vorteil einer Blockchain nicht in der Schnelligkeit oder Effizienz. Andere zentrale Datenbanken sind sogar viel effizienter und schneller als die Blockchain, welche eher langsam und ineffizient ist. Der große Vorteil der Blockchain liegt aber nicht in diesen Eigenschaften, sondern darin, nicht auf eine zentrale Instanz vertrauen zu müssen (vgl. Ammous 2019: Blockchain-Technologie).

In dieser Seminararbeit wird lediglich auf die Nutzung der Blockchain für das Feststellen beziehungsweise Übertragen von Eigentum an Kryptowährungen eingegangen. Neben dieser Anwendung bietet die Blockchaintechnologie jedoch noch viele weitere Anwendungsmöglichkeiten, auf die nicht eingegangen wird (vgl. Thiele 2016: 1, Drescher 2017: 35).

Die Blockchain besteht aus Datenblöcken, welche in einer Kette aneinandergereiht und rückwärtsverlinkt sind. Um dies nachzuvollziehen, muss man erst den Aufbau der einzelnen Blöcke kennen. Ein Block besteht aus einem Blockheader und einer Liste an Transaktionen, welche in diesem Block gespeichert sind (vgl. Antonopoulos 2018: 198). Der Blockheader besteht aus Metadaten wie zum Beispiel der Version, dem Target, der Nonce und dem Hashwert des vorangegangenen Blocks. Diese Metadaten werden zum Teil im weiteren Verlauf der Seminararbeit erläutert. Zudem besitzt jeder Block einen eigenen Hashwert als Kennung, welcher aus dem Blockheader mit einem Algorithmus berechnet wird. Wenn die Daten in einem Block verändert werden, dann ändert sich auch der Hashwert dieses Blockes. Dieser Hashwert dient zur eindeutigen Identifizierung von jedem einzelnen Block. Eine Kette an Blöcken entsteht dadurch, dass jeder Block in seinem Blockheader den Hashwert seines vorangegangenen Blockes enthält. Dadurch sind die Blöcke miteinander verbunden und bilden somit eine Kette an Blöcken. Das bedeutet, wenn die Daten in einem Block verändert werden, dann verändert sich der Hashwert dieses Blockes und auch der Hashwert der darauffolgenden Blöcke bis zum aktuellen Block (vgl. Antonopoulos 2018: 197-199, Märkel et. Al. 2021: 3 f.).

2.2 Definition und Eigenschaften von Bitcoin

Bitcoin verwendet eine Blockchain. Die Blockchain ist aber lediglich das öffentliche Kassenbuch, welches das Bitcoin Netzwerk für die Speicherung der Transaktionen verwendet. Im Grunde ist Bitcoin ein aus Nodes bestehendes dezentrales Peer-to-Peer Netzwerk, wobei diese Nodes alle das gleiche Protokoll ausführen und untereinander über das Internet kommunizieren. Hierbei ist wichtig, dass das Protokoll von Bitcoin Open-Source ist. Dadurch ist das Bitcoin Protokoll für jeden zugänglich. Zudem kann es von jedem eingesehen werden und jeder kann bei der Entwicklung mitwirken. Ein wichtiger Bestandteil des Bitcoin Protokolls sind Konsensregeln, welche für eine unabhängige Validierung von Transaktionen und Vermögen benötigt werden. Eine weitere wichtige Eigenschaft des Bitcoin Protokolls ist, dass es keine Nodes gibt, welche bevorzugt werden oder eine zentrale Kontrolle besitzen. Die Währung Bitcoin wird von den Netzwerkteilnehmern genutzt, um Wert zu transferieren und zu speichern (vgl. Antonopoulos 2018: 1-4, 173; Antonopoulos 2019: 22 f.; Pritzker 2019: 2).

3. Entstehung und Funktion von Schlüsselpaaren

Im Gegensatz zu dem aktuellen Geldsystem gibt es bei Bitcoin keine zentrale Instanz, welche den Besitz der Netzwerkteilnehmer verwaltet. Es gibt keine zentrale Instanz, welche sicherstellt, dass nur der rechtmäßige Eigentümer auf seinen Besitz zugreifen kann (vgl. Drescher 2017: 94; Pritzker 2019: 49 f.). Durch die dezentrale Architektur entsteht das Problem Eigentum eindeutig zu identifizieren, ohne die dezentrale Architektur einzuschränken. Um dieses Problem zu lösen wird Eigentum mithilfe von privaten und öffentlichen Schlüsseln identifiziert.

In diesem Kapitel wird auf die Erstellung von Schlüsselpaaren sowie deren Sicherheit eingegangen. Wie mithilfe der Schlüssel Eigentum identifiziert und eine digitale Signatur erstellt werden kann, wird in Kapitel 4 erklärt.

Bei Bitcoin wird zuerst ein privater Schlüssel erzeugt, aus welchem anschließend ein eindeutiger öffentlicher Schlüssel abgeleitet wird. Der private Schlüssel wird erstellt, indem man eine zufällige 256-Bit-Zahl generiert. Das bedeutet, dass der private Schlüssel lediglich eine zufällige Zahl zwischen 1 und 2256 ist. Dabei ist wichtig, dass die Methode zu der Generierung des privaten Schlüssels wirklich zufällig, also nicht vorhersehbar oder reproduzierbar ist (vgl. Antonopoulos 2018: 59 f.). Um sich diesen Vorgang besser vorstellen zu können, kann man die Erstellung mit dem Werfen einer Münze vergleichen. Man wirft die Münze 256-mal nach oben und schreibt jedes Mal auf, auf welcher Seite die Münze gelandet ist. Dabei hat Kopf den Wert Null und Zahl den Wert eins, was mit den Werten von einem Bit vergleichbar ist. Nach dem letzten Mal hochwerfen hat man die binären Ziffern eines privaten Schlüssels. Dabei stellt sich die Frage, ob man einen privaten Schlüssel einfach erraten kann oder zufälligerweise zweimal der gleiche private Schlüssel erstellt wird, da die Erstellung eines privaten Schlüssels lediglich auf Zufall basiert. Um diese Frage zu beantworten, muss man die Wahrscheinlichkeit für das Erraten oder zweimaligen Erstellens eines privaten Schlüssels errechnen. Die Wahrscheinlichkeit kann wieder mit dem Vergleich der hochgeworfenen Münze visualisiert werden. Die Wahrscheinlichkeit, dass die Münze auf Kopf landet, beträgt ½ oder 1 zu 2. Das gleiche gilt für die Wahrscheinlichkeit, dass die Münze auf Zahl landet. Man kann die Wahrscheinlichkeit für das Erraten oder zweimaligen Erstellens eines privaten Schlüssels also berechnen, indem man den Potenzwert von der Basis ½ mit dem Exponent 256 berechnet, was der Wahrscheinlichkeit 1 zu 2256 oder ungefähr 1 zu 1077 entspricht. Im Vergleich dazu hat das sichtbare Universum geschätzt 1080 Atome. Die Wahrscheinlichkeit für das Erraten beziehungsweise zweimalige Erstellen eines privaten Schlüssels ist also vergleichbar mit dem Erraten eines einzelnen Atoms im sichtbaren Universum, was nahezu unmöglich ist (vgl. Antonopoulos 2018: 60-62; Pritzker 2019: 51-53).

Ein öffentlicher Schlüssel wird aus einem privaten Schlüssel mithilfe von asymmetrischer Kryptografie berechnet. Durch die Verwendung der asymmetrischen Kryptografie kann ein öffentlicher Schlüssel recht einfach aus einem privaten Schlüssel berechnet werden. Jedoch ist es nahezu unmöglich die Funktion umzukehren und den privaten Schlüssel mithilfe von dem öffentlichen Schlüssel zu berechnen. Dies ist ungefähr genauso schwierig, wie den privaten Schlüssel zu erraten. Die Berechnung kann somit nur in eine Richtung erfolgen. Dabei ergibt sich aus einem privaten Schlüssel nach der Berechnung immer derselbe öffentliche Schlüssel. Durch diese Eigenschaft der asymmetrischen Kryptografie kann man den öffentlichen Schlüssel mit jedem teilen, ohne dass diese den privaten Schlüssel zu dem öffentlichen Schlüssel erfahren können (vgl. Antonopoulos 2018: 62-65).

Ihren Namen haben die Schlüssel wegen der Rolle, die ihnen zugeteilt ist. Der öffentliche Schlüssel wird wie eine Adresse verwendet, an die jeder Bitcoin transferieren kann. Man muss diesen nicht geheim halten, sondern kann ihn mit jedem teilen. Den privaten Schlüssel sollte man hingegen immer geheim halten und mit niemanden teilen. Denn mit dem privaten Schlüssel kann man auf die an den öffentlichen Schlüssel gesendeten Bitcoin zugreifen und diese ausgeben (vgl. Drescher 2017: 94 f.). Die Funktionsweise und Technologie dahinter wird in Kapitel 4.2 genauer erklärt.

4. Transaktionen in einer dezentralen Kryptowährung

In diesem Kapitel wird darauf eingegangen, wie eine Transaktion aufgebaut ist und wie mit asymmetrischer Kryptografie sichergestellt wird, dass nur der rechtmäßige Eigentümer sein Eigentum ausgeben kann. Des Weiteren wird erklärt, wie man als Netzwerkteilnehmer die komplette Kontrolle über sein Eigentum hat und über dieses bestimmen kann.

4.1 Aufbau einer Transaktion

Eine Transaktion besteht aus einem oder mehreren Inputs und einem oder mehreren Outputs. Ein Input steht hierbei für das Abbuchen eines Betrages und ein Output steht für das Gutschreiben eines Betrages (vgl. Antonopoulos 2018: 18). In Wirklichkeit enthält ein Output einen Betrag und eine Bedingung, welche erfüllt werden muss, um diesen Output einlösen zu können. Diese Bedingung ist mit einem kryptografischen Rätsel vergleichbar, welches nur von dem Empfänger gelöst werden kann. Ein Input referenziert lediglich auf einen noch nicht eingelösten beziehungsweise ausgegebenen Output und enthält die Lösung für das kryptografische Rätsel zu diesem Output. Ein noch nicht eingelöster beziehungsweise ausgegebener Output wird als Unspent Transaction Output (UTXO) bezeichnet. Bei einer Transaktion werden vom Sender vorher empfangene UTXO als Input verwendet und neue Outputs erzeugt. Anschließend können die Empfänger der neu erzeugten Outputs diese wiederum als Input für eine andere Transaktion verwenden. Jeder Output kann dabei nur einmal eingelöst beziehungsweise ausgegeben werden. Dies ist wichtig, da hierdurch das zweimalige Ausgeben eines Betrages nicht möglich ist (vgl. Antonopoulos 2018: 123-125; Pritzker 2019: 53 f.). Der Betrag eines Outputs kann beliebig hoch sein. Jedoch sind Outputs, nachdem sie generiert wurden, nicht mehr teilbar und müssen in der nächsten Transaktion als Input vollständig verbraucht werden. Dadurch sind die Inputs meistens höher als der Betrag, den der Sender transferieren will. Um dieses Problem zu lösen, fügt der Sender der Transaktion einen Output an sich selbst in der Höhe des überschüssigen Betrages hinzu. Dieser Output wird als Wechselgeld bezeichnet (vgl. Antonopoulos 2018: 121 f.). Des Weiteren enthält eine Transaktion eine Transaktionsgebühr. Diese Transaktionsgebühr wird jedoch nicht in einem Feld oder Output ausgewiesen. Die Differenz zwischen der Summe aus Inputs und Outputs stellt die Transaktionsgebühr dar (vgl. Antonopoulos 2018: 131). Eine beispielhafte Transaktion kann wie folgt visualisiert werden:

InputsOutputs
0,0705 (Person A)
0,08 (Person A)		0,1 (Person B)
0,05 (Wechselgeld an Person A)
Summe: 0,1505Summe: 0,15
Transaktionsgebühr: 0,1505 – 0,15 = 0,005

4.2 Eigentumsnachweis mit digitalen Signaturen

Bei dezentralen Kryptowährungen gibt es keine dritte Partei oder zentrale Instanz, welche die Gültigkeit einer Transaktion überprüft und über diese entscheidet. Es gibt keine zentrale Instanz, die sicherstellt, dass nur der rechtmäßige Eigentümer auf seinen Besitz zugreifen kann. Bei Bitcoin überprüft dies viel mehr jeder Netzwerkteilnehmer selbst und unabhängig von allen anderen. Damit jeder das Eigentum von jemandem überprüfen kann, werden digitale Signaturen verwendet (vgl. Steffen 2018: 7; Drescher 2017: 94).

Die Verwendung von privaten und öffentlichen Schlüsseln beziehungsweise von asymmetrischer Kryptografie ist hierfür die Grundlage. Daten können mit einem der beiden Schlüssel verschlüsselt werden, aber immer nur mit dem jeweils dazugehörigen anderen Schlüssel entschlüsselt werden. Das heißt, wenn Daten mit einem privaten Schlüssel verschlüsselt werden, können diese nur mit dem dazugehörigen öffentlichen Schlüssel entschlüsselt werden (vgl. Steffen 2018: 8). Mithilfe von dieser Eigenschaft können digitale Signaturen erstellt werden.

Wie in Kapitel 4.1 beschrieben enthält ein Output eine Bedingung, um diesen einlösen beziehungsweise ausgeben zu können. Meist ist diese Bedingung mit dem öffentlichen Schlüssel des Empfängers versehen. Die Bedingung sagt also aus, dass nur der Besitzer des privaten Schlüssels zu dem in der Bedingung festgelegten öffentlichen Schlüssel den Output einlösen beziehungsweise ausgeben kann. Zum Beispiel hat Person Y in einer Transaktion einen Bitcoin Betrag an Person X gesendet. Der Output, welcher an Person X gesendet wurde, enthält eine Bedingung mit dem öffentlichen Schlüssel von Person X. Wenn Person X daraufhin den Output in einer Transaktion als Input verwenden will, muss Person X beweisen, dass er der Besitzer des privaten Schlüssels, zu dem in der Bedingung des Outputs festgelegten öffentlichen Schlüssels ist. Wie zuvor bereits beschrieben, können Daten, welche mit einem privaten Schlüssel verschlüsselt wurden, nur mit dem dazugehörigen öffentlichen Schlüssel entschlüsselt werden. Das heißt, dass nur der Besitzer des privaten Schlüssels zu dem in der Bedingung festgelegten öffentlichen Schlüssel die Daten so verschlüsseln kann, dass diese mit dem öffentlichen Schlüssel entschlüsselt werden können. Durch das Verschlüsseln mit seinem privaten Schlüssel signiert Person X also die Daten, was die digitale Signatur darstellt und beweist den Besitz des privaten Schlüssels. Jeder andere im Netzwerk kann daraufhin verifizieren, ob er der Besitzer des privaten Schlüssels, zu dem in der Bedingung des Outputs festgelegten öffentlichen Schlüssel ist, indem sie die digitale Signatur beziehungsweise die verschlüsselten Daten mit dem öffentlichen Schlüssel aus der Bedingung entschlüsseln. Wenn die entschlüsselten Daten mit den Daten des Inputs übereinstimmen, ist Person X der Besitzer des privaten Schlüssels zu dem in der Bedingung des Outputs festgelegten öffentlichen Schlüssels. (vgl. Drescher 2017: 105 f.; Linzner 2016: 36 f.; Pritzker 2019: 50 f.; Schützeneder 2016: 12 f.; Steffen 2018: 9). Hierdurch hat Person X den Besitz des privaten Schlüssels, zu dem in der Bedingung des Outputs festgelegten öffentlichen Schlüssels bewiesen, ohne seinen privaten Schlüssel offenzulegen. Er hat somit sein Eigentum nachgewiesen, ohne dass hierfür eine zentrale Instanz benötigt wurde. Dabei kann jeder andere dies validieren (vgl. Antonopoulos 2018: 143).

Mit dem Wissen, wie ein Eigentumsnachweis bei Bitcoin funktioniert, kann man recht einfach verstehen, wie bei Bitcoin Eigentum identifiziert wird. Bei Bitcoin gibt es keine Kontostände oder ähnliches. Eigentum wird identifiziert, indem UTXO zu Schlüssel zugeordnet werden. Es wird geschaut welche UTXO mit welchem öffentlichen Schlüssel als Bedingung versehen sind (vgl. Pritzker 2019: 53 f.). 

4.3 Kontrolle über das Vermögen

Wie in dem vorherigen Kapitel erklärt wurde, braucht man den privaten Schlüssel, um das Eigentum an den zu dem dazugehörigen öffentlichen Schlüssel transferierten Bitcoins nachzuweisen. Demzufolge braucht man auch nur den privaten Schlüssel, um diese Bitcoins auszugeben beziehungsweise transferieren zu können. Man braucht nur den privaten Schlüssel zu kennen, um das dazugehörige Vermögen zu kontrollieren und kann über dieses bestimmen. Solange niemand anderes den privaten Schlüssel kennt, gibt es niemanden, der auf dieses Vermögen zugreifen kann. Die Person, welche den privaten Schlüssel besitzt, hat im Endeffekt die komplette Kontrolle über die Bitcoins. Es gibt also keine zentrale Instanz, die Kontrolle über diese Bitcoins hat und der man vertrauen muss (vgl. Antonopoulos 2018: 57; Pritzker 2019: 8 f.).

Daraus ergibt sich ebenfalls, dass man nur die privaten Schlüssel benötigt, aus welchen man die öffentlichen Schlüssel ableiten kann, um sein Vermögen aufzubewahren. Dabei gibt es mehrere Möglichkeiten, um seine privaten Schlüssel aufzubewahren. Jede dieser Möglichkeiten seine Schlüssel aufzubewahren, werden als „Wallet“ bezeichnet (vgl. Pritzker 2019: 55). Eine Wallet stellt zudem eine Node im Netzwerk dar. Sie kann eine Transaktion aufbauen und diese im Netzwerk verteilen (vgl. Antonopoulos 2018: 95).

5. Konsens in einem dezentralen Netzwerk ohne Vertrauen

5.1 Problemstellung und Lösungsansatz

Das aktuelle Geldsystem basiert auf einem Vertrauensmodell. Bei Bitcoin gibt es aber keine zentrale Instanz, welcher vertraut werden muss. Es wird prinzipiell keinem anderen Netzwerkteilnehmer vertraut, sondern misstraut. Jeder Netzwerkteilnehmer beziehungsweise jede Node hat eine eigene Kopie der Blockchain. Für jeden Netzwerkteilnehmer gelten nur die Transaktionen in der von ihm gespeicherten Blockchain als bestätigt und durchgeführt. Wie kommt es aber zu einem Konsens unter den Netzwerkteilnehmern über den Zustand der Blockchain und den bestätigten Transaktionen oder anders ausgedrückt zu einer Übereinstimmung der von den Netzwerkteilnehmern gespeicherten Blockchains, wenn man keinem der anderen Netzwerkteilnehmer vertrauen kann? Es braucht also einen Mechanismus, durch den jeder Netzwerkteilnehmer die gleiche Kopie der Blockchain aufbaut, ohne dass diese sich untereinander vertrauen müssen (vgl. Antonopoulos 2018: 219; Drescher 2017: 155; Linzner 2016: 66, Pritzker 2019: 16).

Das beschriebene Problem wird bei Bitcoin wie folgt gelöst. Wie in Kapitel 2.1 erläutert, besteht eine Blockchain aus aneinandergereihten und miteinander verbundenen Datenblöcken, welche neben dem Blockheader zudem Transaktionen enthalten. Demzufolge muss, um neue Transaktionen hinzuzufügen, ein neuer Datenblock mit neuen Transaktionen an die Blockchain angefügt werden. Zudem wurde in Kapitel 4 erläutert, dass eine Wallet Transaktionen erstellen und versenden kann. Wenn eine Wallet eine Transaktion erstellt und im Netzwerk verteilt, wurde die Transaktion aber noch nicht wirklich durchgeführt. Es gelten nur die Transaktionen, welche in der Blockchain eingetragen und gespeichert sind, als bestätigt. Es muss also ein Konsens über alle Datenblöcke gefunden werden. Da der Konsens über die vorherigen Blöcke bereits bei dem Hinzukommen dieser gefunden wurde, braucht es nur bei jedem Hinzukommen eines neuen Blockes zu einem Konsens über diesen zu kommen. Dadurch, dass alle Nodes immer den gleichen Block an ihre eigene Kopie der Blockchain anhängen, bauen alle Nodes die gleiche Kopie der Blockchain auf und haben so einen Konsens über diese. Um einen Konsens über einen neu hinzugefügten Datenblock zu erlangen, wird bei Bitcoin folgendes Konzept verwendet:

  1. Unabhängige Verifikation jeder Transaktion durch jeden Netzwerkteilnehmer beziehungsweise jede Node.
  2. Erstellung eines Datenblockes, welcher Transaktionen enthält, durch einen Miner, der den Beweis für die Berechnung des Proof-of-Work hat.
  3. Unabhängige Verifikation jedes neuen Datenblockes durch jeden Netzwerkteilnehmer beziehungsweise jede Node und anfügen an die eigene Blockchain.
  4. Unabhängige Wahl der längsten Blockchain von jedem Netzwerkteilnehmer beziehungsweise jeder Node

(vgl. Antonopoulos 2018: 215-220; Linzner 2016: 66 f.; Pritzker 2019: 31 f.; Steffen 2018: 14 f.).

Dieses Konzept wird in den folgenden Kapiteln genauer erklärt.

5.2 Schritt 1: Unabhängige Verifikation von Transaktionen

Bevor Transaktionen in einem Block zusammengefasst werden können, müssen diese Transaktionen zuerst erstellt werden. Wie in Kapitel 4.3 bereits beschrieben, kann eine Wallet Transaktionen erstellen. Nachdem die Wallet eine Transaktion erstellt hat, verbreitet sie diese im Bitcoin Netzwerk. Das bedeutet, die Wallet schickt die Transaktion an andere Nodes im Netzwerk. Die Nodes, welche die Transaktion von der Wallet erhalten haben, schicken diese dann wieder an andere Nodes weiter. So verteilt sich die Transaktion sehr schnell im gesamten Netzwerk. Jedoch schicken die Nodes nicht jede Transaktion einfach weiter. Da eine Node keiner anderen vertraut, überprüft sie jede Transaktion unabhängig von allen anderen Nodes. Dazu hat jede Node eine lange Checkliste mit vielen Bedingungen, welche die Transaktion erfüllen muss. Mithilfe von diesen Bedingungen kann eine Node feststellen, ob die Transaktion valide ist. Wenn eine Transaktion alle Bedingungen erfüllt und somit valide ist, schickt die Node diese an andere Nodes weiter. Wenn aber auch nur eine Bedingung nicht erfüllt ist, ist die Transaktion invalide und wird von der Node nicht an andere Nodes weitergeleitet. Zum Beispiel erstellt ein Netzwerkteilnehmer eine Transaktion, bei der er einen Output als Input verwendet, welcher aber nicht mit seinem privaten Schlüssel eingelöst werden kann. Er will damit Bitcoins transferieren, welche gar nicht ihm gehören. Er schickt diese Transaktion an andere Nodes. Da er jedoch nicht die digitale Signatur zu dem in der Bedingung des Outputs festgelegten öffentlichen Schlüssels erzeugen kann, ist die Transaktion invalide. Deshalb wird diese nicht an andere Nodes weitergeschickt. Durch diese unabhängige Verifikation jeder Transaktion durch jede Node werden nur valide Transaktionen im Netzwerk verteilt.

Wenn eine Node eine valide Transaktion erhält, fügt sie diese zudem zu ihrer eigenen Sammlung an noch nicht bestätigten Transaktionen hinzu. In dieser Sammlung sind Transaktionen enthalten, welche valide sind, aber noch nicht in einem Block in der Blockchain enthalten und somit noch nicht bestätigt sind. Demzufolge werden auch Transaktionen aus der Sammlung entfernt, wenn sie in einem zukünftigen Block enthalten und somit bestätigt sind. Dadurch, dass dies jede Node macht, baut jede Node eine Sammlung an noch nicht bestätigten, aber validen Transaktion auf und muss dabei keiner anderen Node vertrauen (vgl. Antonopoulos 2018: 220 f.; Linzner 2016: 67; Steffen 2018: 14).

5.3 Schritt 2: Das Mining von Blöcken

Im Bitcoin Netzwerk gibt es verschiedene Nodes, welche verschiedene Funktionen besitzen. Manche dieser Nodes fassen zusätzlich valide, aber noch nicht bestätigten Transaktionen aus ihrer in Kapitel 5.2 beschriebenen Sammlung in einem sogenannten Anwärterblock zusammen. Diese besondere Art von Nodes wird Miner genannt. Ein Anwärterblock ist dabei ein noch nicht an die Blockchain angehängter Block. Er ist erst bestätigt, wenn der Block von allen anderen Nodes im Netzwerk akzeptiert und von allen Nodes an ihre eigene Blockchain angehängt wird. Im Prinzip hängt also nicht der Miner den Block an die Blockchain an, sondern die Nodes hängen diesen an ihre eigene Kopie der Blockchain an. Das Ziel von einem Miner ist es dabei, dass der von ihm erstellte Block von allen Nodes an ihre eigene Blockchain angehängt wird und der Block damit bestätigt ist. Dieses Ziel haben aber auch noch viele andere Miner, welche ebenfalls einen Anwärterblock erstellt haben. Dabei kann immer nur ein Block eines Miners als nächstes an die Blockchain angehängt werden. Alle Miner bestreiten also einen Wettkampf darüber, wessen Block als nächstes an die Blockchain angehängt wird. Jeder kann eine Mining-Node betreiben und an diesem Wettkampf teilnehmen (vgl. Antonopoulos 2018: 222-224).

Wie wird aber entschieden, welcher Miner seinen Anwärterblock an die Blockchain anhängen darf?

Im Grunde wird der Anwärterblock des Miners, welcher seit dem letzten Block als erstes einen Beweis für eine geleistete Arbeit liefert, an die Blockchain angehängt. Durch die geleistete Arbeit entstehen Kosten für den Miner. Es braucht also einen Mechanismus, bei dem man Arbeit leisten muss, um eine Lösung zu finden. Gleichzeitig müssen die anderen Nodes aber die Lösung leicht und mit wenig Aufwand verifizieren beziehungsweise überprüfen können (vgl. Linzner 2016: 60; Pritzker 2019: 21).

Bei Bitcoin wird dies mithilfe von dem Konsensalgorithmus Proof-of-Work durchgeführt. Genau genommen wird die Hashfunktion SHA256 verwendet. Diese Hashfunktion hat dabei Eigenschaften, welche sehr wichtig sind:

  • SHA256 ist eine deterministische Funktion. Das bedeutet, dass mit derselben Eingabe immer derselbe Hashwert rauskommt.
  • Man kann nicht vorhersehen, welcher Hashwert bei einer Eingabe rauskommt. Wenn man auch nur eine kleine Veränderung an der Eingabe vornimmt, kommt ein völlig anderer und nicht vorhersehbarer Hashwert raus. Um einen Hashwert zu finden, bleibt einem also nichts anderes übrig, als zufällige Eingabewerte auszuprobieren.
  • Wenn man einen Hashwert hat, kann man mit diesem nicht den Eingabewert berechnen. Es handelt sich also um eine Einwegfunktion.
  • Es ist leicht mit einem Eingabewert einen Hashwert zu berechnen

(vgl. Pritzker 2019: 26; Steffen 2018: 11 f.; Linzner 2016: 60).

Des Weiteren hat die Hashfunktion SHA256 sehr viele mögliche Hashwerte. Um genau zu sein sind es 2256 mögliche Hashwert. Die Wahrscheinlichkeit einen bestimmten Hashwert herauszubekommen ist also gleich wie die Wahrscheinlichkeit in Kapitel 3 einen privaten Schlüssel zu erraten. Es ist hier also wieder vergleichbar mit dem Erraten eines einzelnen Atoms im sichtbaren Universum und somit nahezu unmöglich (vgl. Pritzker 2019: 26-29).

Der Beweis für die geleistete Arbeit ist es einen Eingabewert für die Hashfunktion SHA256 zu finden, bei dem ein Hashwert rauskommt, der kleiner als das Target ist. Der Eingabewert ist hierbei der Blockheader des Anwärterblocks. Wie in Kapitel 2.1 beschrieben wurde, besteht ein Blockheader aus Metadaten zu denen auch die Nonce gehört. Diese Nonce ist eine variable, die der Miner anpassen kann. Mit dieser Nonce kann der Miner den Eingabewert immer wieder verändern. Das Target ist ein Schwellenwert, unter dem der Hashwert liegen muss. Dieses Target bestimmt die Schwierigkeit eine passende Nonce zu finden. Bei einem niedrigeren Target gibt es weniger mögliche Lösungen, wodurch die Schwierigkeit steigt. Bei einem höheren Target sinkt dementsprechend die Schwierigkeit. Zudem passt sich das Target der Rechenleistung der Miner an, sodass im Durchschnitt alle 10 Minuten ein Block an die Blockchain angehängt wird (vgl. Pritzker 2019: 37 f.; Linzner 2016: 63). Durch die Eigenschaften der Hashfunktion SHA256 ist es für den Miner am schnellsten mit zufälligen Eingabewerten einen Hashwert zu finden, welcher kleiner als das Target ist. Der Miner berechnet also den Hashwert immer wieder mit einer anderen Nonce, bis ein Hashwert rauskommt, der kleiner als das Target ist. Dies dient als ein Beweis für eine geleistete Arbeit, da der Miner jedes Mal beim Berechnen eines Hashwertes Strom und Hardware investieren muss und so für ihn Kosten entstehen. Um zu verifizieren, dass der Miner eine passende Nonce gefunden hat, müssen die anderen Nodes jedoch fast keinen Aufwand betreiben. Sie müssen lediglich den Blockheader mit der vom Miner eingetragenen Nonce als Eingabewert verwenden. Wenn dann ein Hashwert rauskommt, der kleiner ist als das Target, können sie verifizieren, dass der Miner die Arbeit geleistet hat, um eine passende Nonce zu finden. (vgl. Linzner 2016: 59-61; Pritzker 2019: 29-32; Schützeneder 2016: 32 f.; Steffen 2018: 16 f.).

Durch die entstandenen Kosten braucht es auch einen Anreiz für die Miner, diese auf sich zu nehmen. Wenn es keinen Anreiz dafür geben würde, würde niemand Mining betreiben, da man nur Verluste durch die Kosten auf sich nehmen würde. Bei Bitcoin gibt es daher eine Belohnung für den Miner, wenn sein Block an die Blockchain angehängt wird. Die Belohnung besteht zum einem aus neu geschaffenen Bitcoins, welche der Miner erhält. Zum anderen erhält der Miner alle Transaktionsgebühren der in dem Block enthaltenen Transaktionen (vgl. Antonopoulos 2018: 224-226; Drescher 2017: 156 f.; Linzner 2016: 64 f.). Auf die Höhe und wirtschaftlichen Auswirkungen der Belohnung wird im Rahmen dieser Seminararbeit nicht weiter eingegangen.

Das Aufbringen an Kosten und der daraus resultierenden Belohnung wird als Mining bezeichnet. Wichtig ist, dass das Mining dezentral ist. Jeder kann als Miner tätig sein. Alle Miner konkurrieren untereinander, um den nächsten Block an die Blockchain anzuhängen. Es gibt also keine zentrale Instanz, welche als Einzige Blöcke an die Blockchain anhängen kann (vgl. Antonopoulos 2018: 215 f.; Linzner 2016: 59).

5.4 Schritt 3: Unabhängige Verifikation von Blöcken

Wenn ein Miner eine passende Nonce gefunden und somit seine geleistete Arbeit bewiesen hat, bedeutet dies aber nicht, dass der Block von jeder Node an seine Blockchain angehängt und im Netzwerk verteilt wird. Blöcke werden ähnlich wie Transaktionen von jeder Node unabhängig überprüft und dann weiter im Netzwerk verteilt. Demzufolge schickt der Miner seinen Block an andere Nodes im Netzwerk, welche diesen dann weiter im Netzwerk verteilen. Diese Nodes vertrauen aber niemanden und überprüfen deshalb den Block zuerst. Hierzu hat jede Node eine lange Checkliste mit Bedingungen, welche der Block erfüllen muss, um valide zu sein. Mit diesen Bedingungen überprüfen die Nodes den Block auf seine Richtigkeit beziehungsweise Gültigkeit. Wenn der Block invalide ist, verbreiten die Nodes diesen nicht und hängen ihn auch nicht an ihre Blockchain an. Dadurch wird ein invalider Block nicht im Netzwerk verteilt und auch nicht an die Blockchain angehängt. Wenn der Block valide beziehungsweise gültig ist, verbreiten sie diesen im Netzwerk weiter und hängen ihn an ihre selbst geführte Blockchain an. Dabei schickt jede Node den validen Block an andere Nodes weiter, bis alle Nodes den Block erhalten haben. Dadurch haben dann alle Nodes im Netzwerk nun den gleichen Stand der Blockchain, also einen Konsens über den Stand der Blockchain, ohne jemandem vertraut zu haben.

Ein weiterer wichtiger Aspekt ist, dass die Belohnung für einen Miner erst gültig ist, wenn dessen Block von allen anderen Nodes akzeptiert und an ihre eigene Blockchain angehängt wurde. Demzufolge bleibt ein Miner auf seinen Kosten sitzen, wenn er invalide Blöcke erstellt.

Wenn jemand den Beweis für die geleistete Arbeit liefern konnte und dadurch einen validen Block an die Blockchain angehängt hat, beginnt der gesamte Ablauf von vorne. Es versuchen also wieder alle Miner einen Beweis für die geleistete Arbeit zu finden, um den nächsten Block an die Blockchain anhängen zu dürfen. Dabei ist das Anhängen eines Blockes an die Blockchain der Startschuss für den Wettkampf um den nächsten Block (vgl. Antonopoulos 2018: 240 f.; Drescher 2017: 157).

5.5 Schritt 4: Unabhängige Wahl der längsten Blockchain von jeder Node

Beim Mining kann es passieren, dass zwei Miner mehr oder weniger gleichzeitig eine passende Nonce finden und anschließend ihren Block in dem Netzwerk verteilen. Zum Beispiel finden Miner A und Miner B gleichzeitig eine passende Nonce für ihren Anwärterblock und verteilen diesen anschließend im Netzwerk. Dabei sind beide Blöcke valide und werden dementsprechend von den Nodes an ihre Blockchain angehängt und im Netzwerk weiter verteilt. Das Weiterleiten eines Blockes zwischen Nodes braucht eine gewisse Zeit, wodurch eine Verzögerung entsteht. Durch diese Verzögerung gibt es Nodes im Netzwerk, welche zuerst den Block von Miner A und danach erst den Block von Miner B erhalten. Gleichzeitig gibt es aber auch Nodes, welche zuerst den Block von Miner B und danach erst den Block von Miner A erhalten. Die Nodes haben nun also zwei valide Blöcke, welche sich beide im Blockheader auf den gleichen vorangegangenen Block beziehen. Auf diesen vorangegangenen Block folgen also zwei Blöcke. Aber auf einen Block kann immer nur ein Block folgen. Die Nodes müssen nun also entscheiden, welcher Block der richtige ist. Jedoch sind beide Blöcke valide. Es gibt also keinen richtigen und keinen falschen Block. Deshalb sehen die Nodes nun den Block, welchen sie zuerst erhalten haben als den richtigen an. Hierdurch ist nun aber der Konsens des Netzwerks gestört. Ein Teil des Netzwerks sieht den Block von Miner A als richtig an, während ein anderer Teil des Netzwerks den Block von Miner B als richtig ansieht. Es besteht also kein Konsens über den Stand der Blockchain. Ein Teil des Netzwerkes hat eine Blockchain, bei der der Block von Miner A der neuste Block ist und der andere Teil hat eine Blockchain, bei der der Block von Miner B der neuste Block ist. Die Blockchain hat sich in zwei Teile aufgespaltet.

Damit es wieder zu einem Konsens über den Stand der Blockchain kommt, ist in den Konsensregeln von Bitcoin festgeschrieben, dass jede Node die Blockchain mit dem höchsten kumulierten Proof-of-Work wählt. Vereinfacht gesagt wählt jede Node die längste Blockchain.

Zum einen bauen die Miner, welche zuerst den Block von Miner A erhalten haben, einen Anwärterblock auf, welcher sich im Blockheader auf den Block von Miner A bezieht. Zum anderen bauen die Miner, welche zuerst den Block von Miner B erhalten haben, einen Anwärterblock auf, welcher sich im Blockheader auf den Block von Miner B bezieht. Daraufhin versuchen alle Miner eine passende Nonce für ihren Block zu finden. Wenn nun ein Miner eine passende Nonce für seinen Block gefunden hat, entscheidet dieser darüber, welche Blockchain von den Nodes gewählt wird. Je nachdem auf welchen vorangegangenen Block sich der neue Block im Blockheader bezieht, wird die Blockchain mit diesem Block gewählt. Durch diesen neuen Block gibt es nämlich nun eine Blockchain die länger ist als die andere. Wenn zum Beispiel ein Miner, dessen Block sich auf den Block von Miner A bezieht, als erstes eine passende Nonce findet, hängt sich dieser Block an die Blockchain mit dem Block von Miner A an. Dadurch, dass jede Node die längste Blockchain wählt, sieht nun jede Node die Blockchain mit dem Block von Miner A als die richtige Blockchain an. Die Nodes, welche zuerst den Block von Miner B erhalten haben bemerken, dass es eine längere Blockchain gibt. Deshalb aktualisieren diese Nodes anschließend ihre Kopie der Blockchain auf die längere Blockchain. Hierdurch haben alle Nodes wieder die gleiche Kopie der Blockchain und somit besteht wieder ein Konsens über den Stand der Blockchain.

Aus diesem Mechanismus lässt sich ableiten, dass ein Miner mit seiner Rechenleistung für die Blockchain abstimmt, an welche er seinen Block anhängt (vgl. Antonopoulos 2018: 241-250; Drescher 2017: 168-172; Linzner 2016: 68 f.; Pritzker 2019: 44-46).

5.6 Mitbestimmung durch die dezentrale Architektur von Bitcoin

Durch diese dezentrale Architektur zur Bestätigung beziehungsweise zum Anhängen von neuen Blöcken und den darin enthaltenen Transaktionen an die Blockchain gibt es keine zentrale Instanz, welche über diese entscheidet. Es gibt keine zentrale Instanz, welche allein darüber bestimmt, welche Transaktionen gültig sind und welche nicht. Bei Bitcoin überprüfen die Netzwerkteilnehmer beziehungsweise Miner, welche Transaktionen gültig sind und welche nicht. Zudem gibt es niemanden, der Transaktionen zensieren kann. Im Grunde bestimmen die Miner darüber welche Transaktionen mit in einen Block aufgenommen und bestätigt werden. Demzufolge bestimmen sie auch den Stand der Blockchain. Dabei hat ein Miner je nach Anteil seiner Rechenleistung an der gesamten Rechenleistung Mitbestimmung. Jedoch gibt es keinen Miner, welcher immer als erstes eine passende Nonce findet. Wenn ein Miner eine Transaktion nicht in seinen Block mit aufnimmt, können es die anderen Miner trotzdem machen. Bitcoin ist ein offenes Netzwerk, bei dem jeder teilhaben kann. Durch diese Dezentralisierung liegen die Verantwortung und Kontrolle über dieses Netzwerk bei den Netzwerkteilnehmern und nicht bei einer zentralen Instanz (vgl. Antonopoulos 2018: 273).

6. Die Konsensregeln ändern

Die Konsensregeln sind die Regeln vom Bitcoin Netzwerk, nach welchen die Netzwerkteilnehmer beziehungsweise Nodes agieren. Dabei ist zum Beispiel in diesen Regeln festgelegt, welche Bedingungen eine Transaktion oder ein Block erfüllen muss, um valide zu sein. Die Konsensregeln sind jene Regeln, durch die alle Nodes die gleichen Transaktionen und Blöcke als valide und gültig ansehen und so zu einem Konsens über den Stand der Blockchain gelangen (vgl. Antonopoulos 2018: 260). Dabei sind die Konsensregeln in dem Protokoll beziehungsweise in der Software von Bitcoin festgeschrieben. Wie in Kapitel 2.2 beschrieben, führen alle Nodes das gleiche Protokoll beziehungsweise die gleichen Konsensregeln aus, während sie untereinander kommunizieren und so das Bitcoin Netzwerk bilden.

Ebenfalls wurde in dem Kapitel 2.2 erklärt, dass das Protokoll von Bitcoin Open-Source ist. Dadurch kann das Protokoll und somit die Konsensregeln von jedem eingesehen werden. Jeder kann das Protokoll und somit auch die Konsensregeln von Bitcoin verändern und dieses veränderte Protokoll mit seiner Node ausführen.

In diesem Kapitel soll erklärt werden, was passiert, wenn ein Teil des Netzwerkes ein anderes Protokoll mit anderen Konsensregeln ausführt. Damit einhergehend wird beschrieben, wie bei Bitcoin ein Update durchgeführt wird. Ebenfalls wird erläutert, welche Mitbestimmung verschiedene Personen hierbei haben.

6.1 Erklärung von Hard und Soft Fork

Wenn ein Teil des Netzwerkes ein anderes Protokoll mit anderen Konsensregeln ausführt, gibt es zwei verschiedene mögliche Folgen. Welche von diesen zwei Möglichkeiten eintrifft, ist von der Veränderung der Konsensregeln abhängig. Die Veränderung in den Konsensregeln kann rückwärtskompatibel sein oder auch nicht. Rückwärtskompatibel bedeutet hierbei, dass die alten Konsensregeln mit den neuen, veränderten Konsensregeln koexistieren können. Genauer sind bei einer rückwärtskompatiblen Veränderung der Konsensregeln zum Beispiel Transaktionen und Blöcke, welche nach den neunen Konsensregeln erstellt werden, auch nach den alten Konsensregeln valide und gültig. Wohingegen dies bei einer nicht rückwärtskompatiblen Veränderung der Konsensregeln nicht der Fall ist (vgl. Pritzker 2019: 68 f.; Himmer et al. 2018: 3).

Als Erstes werden die Folgen von einer nicht rückwärtskompatiblen Veränderung der Konsensregeln thematisiert. Angenommen es wurde ein neues Protokoll mit anderen Konsensregeln entwickelt. Dabei sind die Veränderungen der Konsensregeln nicht rückwärtskompatibel. Dieses Protokoll wird anschließend von einem Teil des Netzwerkes übernommen und ausgeführt. Dadurch, dass die Veränderungen der Konsensregeln nicht rückwärtskompatibel sind, werden von den Netzwerkteilnehmern mit den neuen Konsensregeln erstellte Transaktionen und Blöcke von den Netzwerkteilnehmern mit den alten Konsensregeln nicht als valide angesehen und deshalb abgelehnt. Des Weiteren werden nach einer gewissen Zeit alle Nodes die Verbindung mit anderen Nodes trennen, welche ihnen invalide Transaktionen oder Blöcke senden. Um mit den Netzwerkteilnehmern, welche die neuen Konsensregeln ausführen, weiterhin in Verbindung zu bleiben, muss man selbst auch die neuen Konsensregeln ausführen. Demzufolge trennen die Netzwerkteilnehmer mit den alten Konsensregeln die Verbindung zu den Netzwerkteilnehmern mit den neuen Konsensregeln. Infolgedessen kommt es zu einer Spaltung des Netzwerks. Netzwerkteilnehmer mit den alten Konsensregeln bleiben nur mit anderen Netzwerkteilnehmern mit den alten Konsensregeln verbunden und Netzwerkteilnehmer mit den neuen Konsensregeln verbinden sich nur mit anderen Netzwerkteilnehmern mit den neuen Konsensregeln. Das ursprüngliche Netzwerk teilt sich also in zwei Netzwerke auf. Zudem spaltet sich die Blockchain auch in zwei Teile auf. Ab dem Zeitpunkt der Netzwerkspaltung werden aus einer Blockchain zwei Blockchains. Die Miner aus dem Netzwerk mit den alten Konsensregeln erstellen neue Blöcke nach den alten Konsensregeln. Währenddessen die Miner des Netzwerks mit den neuen Konsensregeln neue Blöcke nach den neuen Konsensregeln erstellen. So eine nicht rückwärtskompatible Veränderung der Konsensregeln wird als Hard Fork bezeichnet (vgl. Antonopoulos 2018: 260-263).

Nun werden die Folgen einer rückwärtskompatiblen Veränderung der Konsensregeln beschrieben. So eine rückwärtskompatible Veränderung der Konsensregeln wird als Soft Fork bezeichnet. Anders als bei einem Hard Fork kommt es bei einem Soft Fork jedoch nicht zu einer Spaltung des Netzwerks und auch zu keiner Spaltung der Blockchain. Dadurch, dass es sich um rückwärtskompatible Veränderungen handelt, sind Transaktionen oder Blöcke, welche nach den neuen Konsensregeln erstellt werden, nach den alten Konsensregeln immer noch valide. Dadurch trennen die Netzwerkteilnehmer mit den alten Konsensregeln nicht die Verbindung zu den Netzwerkteilnehmern mit den neuen Konsensregeln. Um mit den Netzwerkteilnehmern, welche die neuen Konsensregeln ausführen, in Verbindung zu bleiben, kann man also einfach weiterhin die alten Konsensregeln ausführen und muss nicht die neuen Konsensregeln verwenden. Demzufolge können Netzwerkteilnehmer mit den neuen und Netzwerkteilnehmer mit den alten Konsensregeln in einem Netzwerk koexistieren. Jedoch sind nur bestimmte Veränderungen rückwärtskompatibel. Eine Veränderung der Konsensregeln kann diese nur beschränken, um rückwärtskompatibel zu sein. Eine Veränderung, welche die bisherigen Konsensregeln erweitert, ist nicht rückwärtskompatibel. Zum Beispiel wurde bei einem Soft Fork des Bitcoin Netzwerkes im Jahre 2010 eine Veränderung an den Konsensregeln vorgenommen, dass Blöcke nur noch maximal 1 MB groß sein dürfen. Davor waren Blöcke mit jeder Größe valide. Durch die Veränderung der Konsensregeln wurden die alten Konsensregeln aber nur weiter beschränkt. Jeder Block nach den neuen Konsensregeln ist auch nach den alten Konsensregeln valide.

Jedoch ist ebenfalls zu beachten, dass Transaktionen oder Blöcke nach den alten Konsensregeln für Netzwerkteilnehmer, welche die neuen Konsensregeln ausführen, eventuell invalide sind. Wie in Kapitel 5.5 beschrieben, wählt jede Node die Blockchain mit dem am höchsten kumulierten Proof-of-Work. Damit der Soft Fork funktioniert und die neuen Konsensregeln verwendet werden können, muss also die Blockchain nach den neuen Konsensregeln die Blockchain mit dem höchsten kumulierten Proof-of-Work sein. Denn dadurch wählen alle Netzwerkteilnehmer, egal ob sie die neuen oder alten Konsensregel ausführen, diese nun als richtige Blockchain. Es braucht also die Mehrheit der Rechenleistung, um einen Soft Fork durchzuführen (vgl. Antonopoulos 2018: 264-266; Pritzker 2019: 68 f.).

6.2 Mitbestimmung bei der Änderung der Konsensregeln

Wie wird nun aber entschieden, welche Konsensregeln die richtigen sind und welche Mitbestimmung haben einzelne Personen bei dieser Entscheidung?

Bei Bitcoin kann jeder Netzwerkteilnehmer selbst und unabhängig entscheiden, welche Konsensregeln er auf seiner Node ausführt. Ein Hard Fork entsteht nur, wenn sich ein Teil der Netzwerkteilnehmer dazu entscheidet, andere Konsensregeln auszuführen. Und wenn es zu einem Hard Fork kommt, kann jeder Netzwerkteilnehmer selbst entscheiden, die alten oder die neuen Konsensregeln auszuführen. Je mehr Netzwerkteilnehmer dieselben Konsensregeln ausführen, desto etablierter wird das Netzwerk mit diesen Konsensregeln. Ein Netzwerk braucht Miner, welche ihre Rechenleistung bereitstellen, Netzwerkteilnehmer und deren wirtschaftlichen Aktivitäten und Entwickler, um fortzubestehen, sich weiterentwickeln und verbreiten zu können. Demzufolge stimmen Miner, Netzwerkteilnehmer und Entwickler für das Fortbestehen und die Verbreitung eines Netzwerks und dessen Konsensregeln. Vor allem bei einem Hard Fork haben sie dadurch eine Mitbestimmung, welches der Konsensregeln beziehungsweise Netzwerke sich durchsetzen kann.

Wenn bei einem Hard Fork der größte Teil der Netzwerkteilnehmer, Miner und Entwickler die neuen Konsensregeln als richtig ansehen, kann das Netzwerk mit den alten Konsensregeln wahrscheinlich nicht fortbestehen. Dies kann zum Beispiel bei einem Update, welches von jedem als sinnvoll erachtet wird, der Fall sein. Des Weiteren kann es sein, dass ein Großteil der Netzwerknutzer, Miner und Entwickler weiterhin die alten Konsensregeln als richtig ansehen und somit sich diese vor den neuen Konsensregeln durchsetzen. Eine weitere Möglichkeit ist es, dass etwa die Hälfte die neuen und die andere Hälfte die alten Konsensregeln als richtig ansehen. In diesem Fall können auch beide Netzwerke mit ihren Konsensregeln fortbestehen. Bei einem Soft Fork ist dies ähnlich. Wie in Kapitel 6.1 beschrieben braucht es für einen Soft Fork die Mehrheit der Rechenleistung. Die Miner haben hier also eine schwerwiegende Mitbestimmung. Jedoch sind sie auch an die wirtschaftlichen Leistungen und die Nutzung des Netzwerks durch die Netzwerkteilnehmer gebunden. Denn ohne diese würde die Belohnung der Miner an Wert verlieren. Eine wie in Kapitel 1 behandelte Geldmengenausweitung kann bei Bitcoin demzufolge nicht allein von einer Regierung oder sonstigen zentralen Instanz durchgesetzt werden (vgl. Antonopoulos 2018: 270; Pritzker 2019: 60-62).

7. Fazit

Zusammenfassend können aus dieser Seminararbeit folgende Ergebnisse gezogen werden. Bitcoin als Beispiel für Kryptowährungen ist ein offenes und dezentrales Netzwerk, an dem jeder teilnehmen kann. Mithilfe von asymmetrischer Kryptografie und digitalen Signaturen kann Eigentum ohne zentrale Instanz identifiziert werden, wobei man selbst die komplette Kontrolle über sein Vermögen hat. Des Weiteren kommen alle Netzwerkteilnehmer in einem dezentralen Netzwerk auf einen Konsens über den Stand der Blockchain, ohne jemanden vertrauen zu müssen. Zudem entscheiden die Miner, Netzwerkteilnehmer und Entwickler selbst über eine Änderung der Konsensregeln und haben dabei eine Mitbestimmung.

Der in der Problemstellung aufgestellten These „Dezentrale Kryptowährungen auf Basis der Blockchaintechnologie ermöglichen den Nutzern dieser Kryptowährungen Mitbestimmung bei Regeländerungen und vollständige Kontrolle über ihr Vermögen, wobei sie ohne zentrale Instanz funktionieren“ kann zugestimmt werden. Es wird in der Seminararbeit belegt, dass man mithilfe des privaten Schlüssels selbst komplett über sein Vermögen bestimmen kann, da man nur mit diesem privaten Schlüssel digitale Signaturen erstellen kann. Des Weiteren wird nachgewiesen, dass Bitcoin mithilfe von verschiedenen Technologien ohne zentrale Instanz funktioniert und die Nutzer hierdurch eine Mitbestimmung bei der Verwaltung haben. Hinzukommend wird die Mitbestimmung der Miner auf den Stand der Blockchain durch das Bereitstellen von Rechenleistung erklärt. Außerdem wird die Funktionsweise von Konsensregeländerungen erklärt und die daraus folgende Mitbestimmung der Nutzer bei einer Konsensregeländerung aufgezeigt. Aus diesen Aspekten lässt sich schließen, dass die Nutzer bei Bitcoin eine Mitbestimmung bei der Geldpolitik haben. Jede Entscheidung wird von den Netzwerkteilnehmern selbst getroffen und nicht von zentralen Instanzen. Dadurch lässt sich die in der Problemstellung gestellte Frage „Ermöglichen dezentrale Kryptowährungen auf Basis der Blockchaintechnologie Mitbestimmung bei der Geldpolitik?“ mit ja beantworten.

Diese Ergebnisse sind jedoch nicht für alle Kryptowährungen zutreffend. Viele Kryptowährungen verwenden zwar eine ähnliche Technologie wie Bitcoin, sind aber keine wirklich dezentralen Netzwerke. Zudem hat eine für jeden zugängliche, nicht zensierbare und dezentrale Währung nicht nur Vorteile. Zum Beispiel dauert es oftmals sehr lange Updates zu implementieren. Dennoch sind dezentrale Kryptowährungen und allen voran Bitcoin eine interessante Technologie, welche eine zukünftige Alternative zu zentral geführten Währungen darstellen könnten. Mit Bitcoin kann man sich durch das Fehlen zentraler Instanzen vor den Entscheidungen Einzelner über zum Beispiel eine Geldmengenausweitung schützen.

Literaturverzeichnis

Ammous, Saifedean (2019): der bitcoin standard die dezentrale alternative zum zentralbankensystem, New Jersey: Aprycot Media

Antonopoulos, Andras M. (2018): Bitcoin und Blockchain – Grundlagen und Programmierung. Die Blockchain verstehen Anwendungen entwickeln, Aufl. 2, Heidelberg: O’Reilly.

Antonopoulos, Andreas M. (2019): Das Internet des Geldes. Eine Sammlung der Vorträge von Andreas M. Antonopoulos, Bd. 1, o.O: Merkle Bloom LLC.

Drescher, Daniel (2017): Blockchain Basics A Non-Technical Introduction in 25 Steps, Frankfurt am Main: Apress

Himmer, Klaus et al. (2018): Soft und Hard Forks: Was sind die wirtschaftlichen und steuerrechtlichen Auswirkungen, [online] http://www.explore‑ip.com/2018_Implikationen-Soft-und-Hard-Forks.pdf [11.03.2022].

Hungerland, Fabian et al. (2017): Die Zukunft des Geldes – das Geld der Zukunft, [online] https://www.econstor.eu/bitstream/10419/162390/1/890366063.pdf [06.01.2022].

Linzner, Manfred (2016): Bitcoin Eine Analyse von Kryptowährungen und deren Anwendung im Onlinehandel, [online] https://repositum.tuwien.at/bitstream/20.500.12708/5897/2/Linzner%20Manfred%20‑%202016%20‑%20Bitcoin%20eine%20Analyse%20von%20Kryptowaehrungen%20und%20deren…pdf [06.03.2022]

Märkel, Christian et al. (2021): Einsatz von Blockchain in KMU: Chancen & Hemmnisse, [online] https://www.econstor.eu/bitstream/10419/248433/1/1783946288.pdf [18.02.2022]

Mindlberger, Lukas (2019): Dezentralisierte Applikationen: Protokolle, Anwendungen, Vergleich, [online] https://epub.jku.at/obvulihs/download/pdf/4590855 [18.02.2022]

Pritzker, Yan (2019): Inventing Bitcoin. The technology behind the first truly scarce and decen-tralized money explained, Selbstverlag

Reilly, Sean Gregory (2020): Hyperinflation in Venezuela: How to Address the Problem, [online] https://repositories.lib.utexas.edu/bitstream/handle/2152/81586/Reilly%2c%20Sean%20-%20THESIS.pdf [06.01.2022].

Schützeneder, Phillip (2016): Anonymität von Kryptowährungen, [online] https://epub.jku.at/obvulihs/content/titleinfo/1451125/full.pdf [28.02.2022]

Steffen, Torben (2018): Einsatzmöglichkeiten der Blockchain-Technologie in der Logistik, [online] https://opus.ostfalia.de/frontdoor/deliver/index/docId/1012/file/Steffen_2018_Einsatzm%c3%b6glichkeiten_Blockchain-Technologie_Logistik.pdf [05.03.2022]

Thiele, Daniel (2016): Blockchain, [online] https://web.archive.org/web/20210724110602id_/https://publikationen.bibliothek.kit.edu/1000127175/121428344 [06.01.2022]