de
Zurück zur Liste

Hardforks und Softforks, Miner und Full Nodes

source-logo  bitcoinblog.de 10 Mai 2022 06:00, UTC

Was ist der Unterschied zwischen einer Hardfork und einer Softfork? Wie verhalten sich Miner und Full Nodes dazu? Können Full Nodes eine Softfork blockieren – oder nur eine Hardfork? Und was bedeutet eine URSF? Wir beantworten zentrale Fragen zur Regierung von Bitcoin.

Die Debatte um BIP-119 (CTV) hat ein Thema zurück aufs Parkett gebracht, das eigentlich schon vor Jahren abgeschlossen erschien. Es geht um Hardforks und Softforks, um Miner und Full Nodes, und, um es grundsätzlicher auszudrücken: darum, wie und durch wen das Bitcoin-Protokoll verändert wird, und bei wem dabei die Macht liegt.

Wir versuchen hier, das Thema systematisch und möglichst verständlich abzuarbeiten. Es ist nicht ganz einfach zu verstehen, aber gut zu wissen, wie die Adern der Macht in einem dezentralen System wie Bitcoin verlaufen.

Das Konsens-Protokoll

Im Herzen von Bitcoin ist ein Konsens-Protokoll. Dieses Protokoll beinhaltet alle Regeln, denen Transaktionen und Blöcke unterliegen, um gültig zu sein.

Die Miner erzeugen einen Block. Wenn sie diesen im Netzwerk verbreiten – man sagt dazu: propagieren – überprüft jeder Knoten im Netzwerk (englisch: Node), ob der Block und die Transaktionen in ihm valide sind. Die Miner tun also gut daran, sich an die Regeln des Konsens-Protokolls zu halten, wenn sie für ihre Arbeit bezahlt werden wollen.

Derzeit gibt es laut Bitnodes mehr als 15.000 erreichbare vollwertige Bitcoin-Knoten („Full Nodes“). Jeder einzelne validiert Blöcke, die er von Minern empfängt. So garantiert das Bitcoin-Netzwerk, dass alle Regeln des Protokolls mit jeder Transaktion und jedem Block eingehalten werden.

Diese Architektur schafft ein einzigartig starkes, mächtiges und resilientes Netzwerk. Sie hat aber ihren Preis. Denn es ist schwierig, das Konsens-Protokoll anzupassen oder zu ändern.

Hardforks & Softforks

Die einfachste und ehrlichste Weise, ein Konsens-Protokoll zu verändern, ist die Hardfork: Man entfernt oder ändert eine Regel durch ein Upgrade.

Eine Hardfork hat einen unangenehmen Effekt: Jeder Knoten, der das Upgrade ablehnt oder versäumt, wird noch denken, dass die alten Regeln in Kraft sind, und daher neuen Blöck ablehnen. Daher nennt man eine Hardfork auch „nicht abwärtskompatibel“. Damit sie reibungsfrei abläuft, muss jeder Knoten das Update zeitnah einspielen.

Um solche Disruptionen zu vermeiden, hat bereits Satoshi Upgrades nicht per Hardfork durchgeführt, sondern per „Softfork“. Softforks ändern alte Regeln nicht, sondern führen neue Regeln ein. Dies ermöglicht es, schreibt der Bitcoin Optech Newsletter, „im gesamten Netzwerk neue Regeln einzuführen, selbst wenn nicht jeder Knoten diese Regeln angenommen hat.“ Denken Sie an eine Radarfalle: Wenn ein Autofahrer eine Regel verletzt – wenn er etwa mit 120 durch eine 30er-Zone bretter – schießt die Radarfalle ein Foto. Wenn sich der Autofahrer aber die Regel auferlegt, in einer 30er-Zone mit Schrittgeschwindigkeit zu schleichen, juckt das die Radarfalle nicht.

Ausführlich dokumentiert wurde der Mechanismus 2012 durch BIP16. Full Nodes, die das Upgrade versäumten, sahen in den P2SH-Transaktionen lediglich „Pay-to-Anybody“-Transaktionen. Die Miner jedoch mussten das Upgrade einspielen. Sie mussten die Pay-to-Anybody-Transaktionen als P2SH-Transaktionen verstehen und jeden Block ablehnen, der diese neue Regel nicht umsetzte.

Eine Softfork macht den Full Nodes also vor, zu verstehen, was in einem Block passiert – während tatsächlich etwas anderes passiert. Dies hat den Effekt, dass Upgrades per Softfork viel weniger disruptiv ablaufen. Nur die Miner müssen sofort upgraden. Full Nodes können das irgendwann machen.

Eine Softfork schützt Full Nodes. Der Preis dafür ist aber, dass sie ihr Mitspracherecht verlieren.

Hardforks und Softforks

Bitcoin ist ein nicht-politisches Geld, und das bedeutet, dass ALLES politisch ist. Ganz besonders Upgrades des Protokolls.

Was wäre, wenn jemand die maximale Anzahl an Bitcoins auf mehr als 21 Millionen erhöht? Wenn jemand eine Art von Identifizierungspflicht in Transaktionen einbaut? Oder die Größe der Blöcke auf 0,1 Megabyte reduziert, so dass Bitcoin nur 25.000 anstatt rund 300.000 Transaktionen am Tag verarbeiten kann? Nur die Phantasie begrenzt den Schaden, den ein bösartiger Akteur durch Protokoll-Änderungen verursachen kann.

Full Nodes gelten weithin als Hüter der Regeln. Sie wachen darüber, dass das Protokoll nicht willkürlich verändert wird. Sie erkennnen, wenn ein Block wider die Regel geht, und machen den Regelverstoß transparent. Aber welche Sanktionsmöglichkeiten haben sie darüber hinaus?

Diese Frage ist nicht ganz einfach zu beantworten. Sie ist eher politisch als technisch. Denn technisch haben Full Nodes nur die Option, sich selbst aus dem Netzwerk zu entfernen. Wenn ein Miner beispielsweise seinen Blockreward von 6,25 auf 50 Bitcoins erhöht, können Full Nodes zunächst nur eines machen: Sie lehnen den Block ab, wie auch jeden weiteren, der auf ihm aufbaut. Für sie hört die Blockchain in diesem Moment auf, zu wachsen. Man kann sich dies wie einen Hungerstreik vorstellen.

Technisch gesehen ist das ein ziemlich stumpfes Schwert. Ökonomisch betrachtet wird die Sanktion aber schärfer: Um die Coins, die sie verdienen, auch zu verkaufen, müssen die Miner sie an Börsen oder Händler überweisen. Wenn diese auch einen Full Node betreiben, aber das Upgrade nicht mittragen, kommen die Coins niemals bei ihnen an. Der Miner risikiert, auf seinen Coins sitzenzubleiben.

Vor allem aber sind Full Nodes eine Art Indikator, der anzeigt, wie die „Community“  oder das „Ökosystem“ zu dem Upgrade steht. Wenn die Full Nodes ein Upgrade ablehnen, setzen sie Anreize für Miner, einen Block nach den alten Regeln zu erzeugen, was effektiv bedeutet, dass sich die Blockchain teilt. Besser gesagt: sie gabelt sich (fork). Daher sind Hardforks auch so gefürchtet. Sie können die Blockchain selbst dann spalten, wenn ein Großteils des Netzwerks zustimmt.

Anders bei einer Softfork: Diese gaukelt Full Nodes vor, eine Transaktion zu verstehen, obwohl diese mit neuen Regeln gebildet wurde, denen sie niemals zugestimmt haben. Daher ist es für Full Nodes unmöglich, eine Softfork abzulehnen. Ein Full Node erkennt die Regeländerung nicht und kann sie daher auch nicht blockieren. Er sieht nur gültige Transaktionen und Blöcke; eine Radarfalle reagiert nur auf Verstöße gegen bestehende Regeln, nicht aber, wenn sich Autofahrer selbst neue Regeln auferlegen.

Daher setzt eine Softfork das Mitbestimmungsrecht der Full Nodes über ein Upgrade der Konsens-Regeln außer Kraft. Wenn sich die Entwickler und die Miner verabreden, können sie durch eine Softfork fast alles einführen, von KYC-Regeln über eine Eskalation der Gebühren zur Reduktion der Blockgröße, und die Full Nodes bleiben machtlos.

Oder?

UASF & URSF

Im ersten Schritt können Full Nodes tatsächlich nichts machen. Bei einer Hardfork bedeutet Passivität Ablehnung, bei einer Softfork Zustimmung. Um sich zu wehren, müssen Full Nodes aktiv werden: Sie müssen eine Software installieren, die eine unerwünschte Protokoll-Änderung blockiert oder rückgängig macht. Eine Fork wird mit einer Fork beantwortet.

Im einfachsten Fall wäre dies eine Hardfork: Die Full Nodes installieren eine Software, die die neue Regel aufhebt. Sie machen es wieder legitim, die „Pay-to-Anyone“-Transaktionen wörtlich zu verstehen. Wenn die Full Nodes dafür die Mehrheit der Miner gewinnen, können sie das Upgrade rückgängig machen.

Allerdings würde an dieser Stelle eine unangenehme Mechanik greifen: Die Knoten, die die Softfork mittragen, lehnen alle Blöcke ab, die nicht den neuen Regeln entsprechen. Knoten, die die Softfork mit einer Hardfork beantworten, erlauben lediglich, die neuen Regeln zu verletzen, verbieten aber nicht, ihnen zu folgen. Denken Sie noch mal an die Radarfalle: sie wird niemanden blitzen, weil er 15 anstatt 30 Kilometer fährt.

Daher sind nicht alle Forks gleich. Folgt die Mehrheit der Miner – der Hashrate – einer Hardfork, besteht die alte Blockchain fort. Ihre Blöcke sind unabhängig von der Hashrate gültig, weil die Blöcke der Hardfork-Blockchain immer ungültig sind. Eine Hardfork KANN eine überbleibende Blockchain nicht auslöschen. Dies kann nur eine Softfork. Denn sobald eine Blockchain mit schärferen Regeln die Mehrheit der Hashrate hat, wird sie für alle zur verbindlichen Blockchain. Die alte Blockchain kann sich nicht wehren: Sie stirbt ab.

Dies war die spieltheoretische Drohung der sogenannten „User Activated Soft Fork“ (UASF), mit der die Full Nodes 2017 versuchten, das SegWit-Upgrade durchzusetzen. Die Nodes drohten, per Softfork alle Blöcke abzulehnen, die nicht die Regeln des SegWit-Upgrades umsetzten. Wenn nur ein Miner der Softfork folgt, entsteht eine neue Blockchain; wenn die Mehrheit der Miner ihr folgt, egal wann, wird die alte Blockchain ausgelöscht.

Aus diesem Grund hat Bitcoin Cash (BCH) bei der Abspaltung von Bitcoin eine Hardfork mit einer Softfork verbunden: Auf der einen Seite wurde das Blocksize-Limit von 1MB aufgehoben (Hardfork) – auf der anderen Seite wurde die Regel gesetzt, dass ein bestimmter Block größer als 1MB sein musste (Softfork).

Im Falle von BIP-119 denken die Entwickler daher darüber nach, die Softfork mit einer Softfork zu kontern: Man akzeptiert die neu eingeführte Regeln, ergänzt sie aber um die Regel, dass es verboten ist, sie anzuwenden. Das wäre die URSF – die User Resistet Soft Fork. Michael Folkson hat sie als Reaktion auf BIP-119 in der Mailing-List vorgeschlagen:

„Wenn durch einen Zufall CTV durch eine andere Software aktiviert wird, würde Bitcoin Core die CTV-Regeln nicht anwenden, aber auch keine Blöcke ablehnen, die durch CTV-Regeln erzeugt wurden. Daher ist es umsichtig, sich darauf vorzubereiten, dass die Miner die Schwelle erreichen, aber die Community die Aktivierung der Softfork verhindern möchte. Ich nenne dies provisorisch eine User Resisted Soft Fork (URSF), bin aber offen für bessere Namen …“

Keagan McClelland erklärt in einer Folgemail: „Es gibt zwei Wege, Widerstand gegen diese Änderung zu leisten: 1. man lehnt alle Blöcke während der Aktivierungsperiode ab, und 2. man lehnt alle Blöcke ab, die OP_CTV im Script enthalten.“

Es ist also für Full Nodes möglich, die Aktivierung einer Softfork zu verhindern oder sie quasi rückgängig zu machen. Es ist aber ein sehr viel härterer Eingriff als bei einer Hardfork, der nachträglich fast garantiert zu einer Spaltung der Blockchain führt. Darüber hinaus ist er sehr viel schwieriger, da die Full Nodes aktiv updaten müssen, anstatt passiv zu bleiben.


Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder

Christoph hat vor kurzem sein zweites Buch veröffentlicht: „Das Bitcoin-Kompendium: Netzwerk und Technologie“. Es ist eine überarbeitete Auslese seiner besten Artikel für dieses Blog. Ihr könnt das Kompendium direkt auf der Webseite Bitcoin-Buch.org bestellen – natürlich auch mit Bitcoin – oder auch per Amazon.

Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Für verschlüsselte Nachrichten nutzt bitte meinen PGP-Schlüssel — Auf Telegram! könnt ihr unsere News abonnieren.

bitcoinblog.de