SegWit2x: Bitcoin soll eine bessere Blockchain erhalten

tl;dr: Die Entscheidung ist gefallen: Das Bitcoin-Netzwerk will bei der Blockchain in Zukunft auf SegWit2x setzen. ComputerBase erklärt, wie die Entscheidung zustande gekommen ist, was sie inhaltlich bedeutet und warum es nach der Soft noch zum Hard Fork kommt. Ruhe im Netzwerk ist nicht in Sicht.

Bitcoin: SegWit2x ist die Zukunft der Blockchain

Ausgangspunkt für die heute beschlossene Umstellung war das Bitcoin Improvement Proposal 141 (BIP141). Es wurde offiziell am 15. November 2016 gestartet. Ziel war es, eine Unterstützung von 95 Prozent der Mining-Hashpower zu erhalten, um die Systemänderung im Anschluss durchzuführen. Allerdings kam der Vorschlag lange Zeit nicht über eine Zustimmung von 40 Prozent hinaus, erst vor Tagen nahm die Unterstützung zu.

Der Grund: Am 1. August 2017 sollte es mit dem BIP148 zu einer erneuten „Abstimmung“ kommen, bei der große Teilnehmer am Markt den Vorschlag ohne Unterstützung der breiten Masse hätten durchziehen können. Doch dazu kam es nicht, denn mit dem an BIP141 angelehnten und erweiterten BIP91 hat sich die breite Masse vor wenigen Stunden auf einen anderen Vorschlag geeinigt. Anders als bei BIP148 reicht hier eine „Zustimmung“ von 80 Prozent. Diese Hürde wurde mit über 95 Prozent über die letzten 24 Stunden deutlich übertroffen.

Was der enthält und wie die Umsetzung von Vorschlägen im Bitcoin-Netzwerk funktioniert, wird nachfolgend genauer herausgestellt.

• Zum Thema: Mining von Bitcoin und Ethereum einfach erklärt

Das Bitcoin Improvement Proposal

Beim BIP handelt es sich immer um ein Dokument, in dem es um neue Features für das Währungssystem geht. Das erste BIP war dementsprechend ein Dokument, in dem es um die Einführung des BIP ging. Da Bitcoin keine formelle oder zentrale Struktur besitzt, ist dies der gängige Weg, um Änderungen vornehmen zu können. Abgelegt werden sie auf GitHub.

Es gibt insgesamt drei verschiedene Arten des BIP:

• Standards Track: Dabei geht es um Änderungen an Netzwerkprotokoll, Blocks, Blockkette, Validierung usw.
• Informational: für Designfragen, Guidelines usw.
• Process: Vorschläge für Prozessänderungen außerhalb des Bitcoin-Protokolls

Abgestimmt wird über ein BIP, wie sollte es anders sein, über die Blockchain. Die Gewichtung der Stimmen erfolgt dabei über die Hashing-Power eines Nutzers bzw. Pools. Als Mehrheit für oder gegen einen Vorschlag werden in der Regel 75 bis 95 Prozent oder mehr der Stimmen veranschlagt.

Bei BIP141, BIP141 und BIP91 handelt es sich um Dokumente der ersten Kategorie. Ziel ist es, zunächst alle systemrelevanten Teilnehmer und schlussendlich alle Miner dazu zu bewegen, auf SegWit umzustellen. Außerdem sollen Verbesserungen an der Blockchain vorgenommen werden, sodass die Erstellung von Sidechains erschwert wird und die Geschwindigkeit verbessert werden kann. Und bei BIP91 kommt noch eine weitere Anpassung dazu.

SegWit2x und die Blockchain

SegWit wurde vom Bitcoin-Core-Team entwickelt und vorgestellt. Es bezeichnet eine Änderung am Bitcoin-Chainblock-Algorithmus. Dabei werden Signaturdaten (die Zeugen) aus den Transaktionen entfernt, um diese in der Dateigröße zu schrumpfen. Darüber hinaus ist nicht mehr die „Größe“, sondern das „Gewicht“ eines Blocks entscheidend um festzustellen, wie viele Transaktionen er maximal enthalten darf.

Eine Transaktion bei Bitcoin beinhaltet aktuell drei wichtige Elemente: den Sender, den Empfänger und die Signaturen. Letztere werden landläufig auch als Zeugen bezeichnet. Sie machen einen großen Teil der Größe der Transaktion aus. Die Rede ist von ca. 60 Prozent der Datenmenge.

Aktuell sind knapp 7 Transaktionen die Sekunde möglich

Aktuell ist eine Transaktion inklusive Signatur/Zeuge rund 250 Byte groß. Ein Block wiederum fasst immer maximal 1 MB - das ist die Regel. In diesen 1-MB-Block passen demnach 4.000 Transaktionen hinein. Die Fertigstellung eines Blocks dauert im Netzwerk aktuell im Schnitt rund zehn Minuten. Effektiv erfolgen also 6,66 Transaktionen (= Überweisungen) pro Sekunde. Zum Vergleich: Bei Visa waren es schon im Jahr 2010 über 1.700 Transaktionen die Sekunde, bis zu 24.000 sollten damals in Stoßzeiten möglich sein.

„Überweisungen“ im Bitcoin-Netzwerk dauern so im schlimmsten Fall mittlerweile Tage, also möglicherweise auch länger als eine gewöhnliche SEPA-Banküberweisung. Man spricht hier auch vom Problem der Skalierbarkeit. So wächst zwar die Nutzerzahl von Bitcoin stetig, die Geschwindigkeit der Blockchain allerdings nicht. Ein für viele unhaltbarer Zustand, der auch einem größeren Einfluss der Währung im weltweiten Zahlungsverkehr entgegen steht.

SegWit lagert die Signatur aus und gewichtet anders

SegWit greift hier an zwei Stellen an: Erstens ist die Signatur nicht mehr Teil der eigentlichen Transaktion. Und zweitens wird das harte Größenlimit von einem Megabyte aufgehoben und ein Vier-Millionen-Byte-pro-Block-Limit eingeführt – es wird von „Gewicht“ statt „Größe“ gesprochen. Die ausgelagerten Witness-Daten zu einer Transaktion werden dabei als eine Einheit und die eigentlichen Transaktionsdaten als vier Einheiten gezählt. Signaturen werden bevorzugt, weil ihre Trennung von der Transaktion deutliche Vorteile für das Netzwerk hat.

Auf den ersten Blick klingt das neue trotzdem wie das bekannte harte Größenlimit, nur mit vier statt einem Megabyte. Dass das Gewicht ebenfalls in Bytes gemessen wird, ist in diesem Zusammenhang unglücklich. Denn auf Basis der alten Agorithmen bleibt das 1-MB-Limit unberührt.

4 × Größe Transaktionen inkl. Signatur + 1 × Größe SegWit-Signaturen <= 4.000.000 Byte

Für den Fall, das weiterhin nur alte Transaktionen vor SegWit gehandelt werden, lautet die Rechnung: Ein Block, der lediglich Transaktionen ohne SegWit enthält, ist weiterhin maximal ein Megabyte groß und enthält weiterhin 1.000 Transaktionen. Denn es gilt: 4 × 4.000 * 250 Byte + 1 × 0 = 4.000.000 Byte. In diesem Fall ist das alte Limit sogar 1:1 dasselbe.

Sind SegWit-Transaktionen darunter, sind mehr Transaktionen innerhalb derselben Limitierung möglich, denn ohne Signatur in der eigentlichen Transaktion fällt deren Größe um gut zwei Drittel von 250 auf unter 90 Byte und die herausgelöste SegWit-Signatur fließt wiederum nur einmal und nicht viermal in die Formel für das Gewicht des Blocks ein.

Wie es sich dabei konkret mit der Dateigröße und den enthaltenen Signaturen verhält, hängt dabei wesentlich vom Anteil der SegWit-Transaktionen und dem Anteil der Signatur an der Transaktionsgröße ab. Die Initiatoren gingen auf Basis des Limits von 4.000.000 Byte davon aus, dass mittelfristig 2 MB große Blöcke zum Standard werden – mit deutlich mehr enthaltenen Transaktionen.

Dabei spielen auch die für Transaktionen am Markt gebotenen Gebühren eine Rolle: Bisher enthielten Blöcke immer dasselbe Verhältnis aus Transaktionen und Signaturen, mit SegWit wird das nicht mehr der Fall sein. Einen Block möglichst groß zu machen, um möglichst viel Gebühren für dessen Fertigstellung zu erhalten, ist nicht mehr im Interesse, stattdessen rückt das Gewicht in den Fokus.

BIP 91 wird diese Veränderungen in „SegWit2x“ mit einer weiteren kombinieren: einer Verdoppelung der maximal erlaubten Größe eines Blocks. Diese Umstellung soll mit drei Monaten Versatz erfolgen. Der Grund: Hierbei handelt es sich nicht um eine Soft Fork sondern eine Hard Fork.

Soft Fork und Hard Fork

Eine Hard Fork („harte Gabelung“) beschreibt den Vorgang, dass eine Blockchain sich in zwei unterschiedliche Stränge aufteilt. Im Normalfall gibt es immer nur eine einzige Blockchain mit den darin enthaltenen Blocks und ihren Transaktionen. Ändert sich nun beispielsweise etwas am Validierungsprozess der Kette, etwa wenn das Protokoll überarbeitet wird und alte Blocks, die vorher als ungültig galten, nun gültig sind (eine Lockerung der Regeln), können Knoten, die noch nicht über das Update verfügen, bestimmte Blocks nicht mehr verifizieren. So entstehen zwei Stränge mit unterschiedlichen Regeln, die sich gegenseitig ausschließen; ein binäres System. Der Erste enthält Blocks erstellt von Knoten, die noch mit dem alten Algorithmus laufen. Der Zweite enthält Blocks, die mithilfe des neueren Regelwerks verifiziert wurden. Das Währungssystem wird letztendlich gespalten.

Eine Soft Fork („weiche Gabelung“) unterscheidet sich nun dahin gehend, dass alte Knoten neue Blöcke trotz Veränderung am System immer noch als gültig erkennen können, da es diesmal um eine Verschärfung der Regeln geht: Diese werden strenger, nicht lockerer, sodass auch alte Klienten einen Block als gültig anerkennen: Er erfüllt die Regeln für diese quasi über. Das heißt, dass streng genommen nicht alle Nutzer eines Netzwerkes auf das neue Protokoll aktualisieren müssen, da neue korrekte Blöcke von allen Teilnehmern als korrekt angesehen werden. Das führt zwar ebenfalls zu einer Gabelung, aber da Knoten mit alter Software und Knoten mit neuer Software beide die neue Blockchain unterstützen, während die alte lediglich von den alten Knoten erstellt werden kann, setzt sich normalerweise die neuere Kette durch. Im Anschluss ist es egal, ob ein Nutzer die aktualisierten Regeln verwendet oder nicht, da die Kette, die die neuen Regeln noch verletzte, „ausgetrocknet“ wurde. Die Umstellung auf SegWit entspricht verursacht im schlimmsten Fall eine Soft und keine Hard Fork.

Soft Fork	Hard Fork
Verschärfung der Regeln	Lockerung der Regeln
Rückwärtskompatibel	Nicht rückwärtskompatibel
Gabelung in Kette mit alten Regeln und Kette, die alte und neue, strengere Regeln erfüllt	Gabelung in Kette mit alten Regeln und Kette mit neuen, lockereren Regeln
Kette mit alten Regeln stirbt aus, Kette, die neue und alte Regeln akzeptiert, setzt sich durch.	Kette mit alten Regeln stirbt aus, Kette mit neuen Regeln setzt sich durch
Nutzer müssen dadurch nicht aktualisieren.	Nutzer müssen aktualisieren.
Hashing-Power wird zur Durchsetzung benötigt.	Hashing-Power wird zur Durchsetzung benötigt.

Der Vorteil der Soft Fork ist also, dass nicht alle Teilnehmer umstellen müssen; der Übergang geht einfacher, weicher vonstatten. Bei einer Hard Fork besteht die Gefahr, dass Nutzer von der Hauptkette abgespalten werden. Zwar droht bei einer Soft Fork auch die Verschwendung von Rechenkraft auf die falsche Kette, das ist aber meist nur kurzzeitig der Fall. Bei einer Hard Fork kann die Spaltung potenziell länger bestehen bleiben (da Upgrade notwendig) – wer nicht aufpasst, bleibt irgendwann alleine zurück. Nutzer können dann unter Umständen keine Transaktionen untereinander mehr durchführen, da die Blockchain gespalten ist. Es würden theoretisch zwei verschiedene Kryptowährungen entstehen.

User Activated Soft Fork und Miner Activated Soft Fork

Eine User Activated Soft Fork (UASF) ist eine Gabelung, die an einem bestimmten Datum vorgenommen wird und auf eine bestimmte Nutzerzahl an Full Nodes („vollwertige Knoten“) angewiesen ist, die diese Regeln auch durchsetzt, um den Erfolg der Gabelung zu erzwingen. Das bezieht sich zunächst nicht auf die Mehrheit in der Hashing-Kraft, sondern auf die 'wirtschaftliche Mehrheit' (Economic Majority, Anzahl der Transaktionen). Wenn die Betreiber nicht mitmachen, wird sich eine Änderung schlicht nicht durchsetzen und die neue Blockchain automatisch kürzer als die alte werden und schließlich verwaisen.

Das hat folgenden Grund: Alle mit dem Bitcoin-Netzwerk verbundenen Computer bezeichnet man als Node. Nodes, die die Regeln des Netzwerkes durchsetzen und die Einhaltung kontrollieren, sind Full Nodes (Händler, Tauschbörsen usw.). Die meisten Knoten des Netzwerkes sind folglich „einfache Mitglieder“ (Lightweight Nodes, beispielsweise für Wallets), die zwar teilnehmen, aber keinen Beitrag zur Erhaltung oder gar zum Ausbau der Währung liefern. Liegt nun die wirtschaftliche Mehrheit auf der Durchsetzung eines neuen Systems wie SegWit, würde auch ein Gros der Hashing-Power eine alte Blockchain schwerlich durchsetzen können.

Demgegenüber steht die Miner Activated Soft Fork (MASF). Hier wird gewartet, bis ein bestimmter Prozentsatz der Miner (75-95 Prozent) die Bereitschaft zur Gabelung signalisiert (BIP141 oder BIP91). Sobald dies der Fall ist, werden nur noch Blöcke akzeptiert, die ihre Bereitschaft zur Umstellung signalisieren. Alle anderen werden ignoriert. Das Signal ist nicht mit einem tatsächlich bereits durchgeführten Update zu verwechseln. So können auch Miner ihre Bereitschaft signalisieren, die eine ältere Version der Blockchain betreiben, was im Falle einer Soft Fork allerdings kein Ausschlussgrund ist, da ein Update nicht zwingend erforderlich ist. Hat sich die aktualisierte Kette durchgesetzt, findet später die tatsächliche Umstellung statt.

Komplizierter wird es, wenn sich tatsächlich einmal keiner der zwei Stränge einer Soft Fork durchsetzen sollte. Dann existieren alle Münz-Token, die vor der Gabelung existierten, plötzlich zweimal. Die in der jeweiligen Chain neu erstellten Münzen würden aber nur in ihrer eigenen Kette Gültigkeit besitzen. Und sollte sich schlussendlich die neue Kette durchsetzen (dafür muss sie einen Block länger werden als die ursprüngliche), werden alle Transaktionen der älteren Kette ungültig und der Wert der Token verfällt.

BIP148 ist also eine Mischung aus UASF und MASF. Wäre BIP148 eine reine UASF, würden die Regeln sofort erzwungen werden. Signalisieren genug Miner die Bereitschaft, auf SegWit umzusteigen, versuchen die Full Nodes im Anschluss, die Regeln durchzusetzen. Das Signal heißt wie bereits erwähnt nicht, dass die Miner die neuen Regeln selbst durchsetzen können/wollen (auf der Software-Seite), allerdings bereit sind, die Änderungen mitzumachen. Dafür müssen sie ihre eigenen Routinen selbst nicht aktualisieren, da neue Blocks immer noch richtig erkannt werden. Die alte Blockchain stirbt im besten Fall schlussendlich aus. BIP91 ist eine MASF.