Konsensregeln und Validierung

Neugier

1. Was hindert einen Miner mit der meisten Rechenleistung daran, unbegrenzt Coins zu erzeugen?
2. Warum kann eine Transaktion, die Ihr Node nicht weiterleitet, trotzdem in einem gültigen Block landen?
3. Wenn sich der Konsenscode ändert, müssen dann alle genau in derselben Sekunde upgraden?

Erkunden

1. Konsensregeln sind die strengen Kriterien, anhand derer jeder Full Node Blöcke validiert. Sie legen fest, was technisch möglich ist: den Ausgabeplan neuer Coins, das Blockgewichtslimit von 4.000.000 Einheiten, die Proof-of-Work-Difficulty und die Gültigkeit von Signaturen. Ein Block, der auch nur eine Regel verletzt, wird von jedem ehrlichen Node abgelehnt, unabhängig davon, wie viel Hashrate ihn erzeugt hat. Miner schlagen Blöcke vor; Nodes entscheiden, ob sie zählen. Diese Trennung stellt sicher, dass keine Instanz den Zustand des Hauptbuchs einseitig ändern kann.
2. Policy-Regeln bestimmen, was ein Node vor dem Mining an seine Peers weiterleitet. Dazu gehören Dust-Schwellen, Mindestgebühren für das Relay und Standard-Skripttypen. Eine Transaktion, die gegen die Policy verstößt, wird von den meisten Nodes verworfen, bleibt aber gültig, wenn ein Miner sie in einen Block aufnimmt. Diese Unterscheidung ist wichtig: Sich zur Sicherheit auf die Ablehnung durch die Policy zu verlassen, ist riskant, denn ein entschlossener Akteur kann die Filter der Peers umgehen und Transaktionen direkt bei Minern einreichen. So muss das Netzwerk nicht standardkonforme Transaktionen akzeptieren, solange sie die Konsensregeln erfüllen.
3. Der Code ist die Spezifikation. Die Regeln sind das, was die weit verbreitete Node-Software tatsächlich durchsetzt, einschließlich aller Randfälle. Deshalb ändert sich Konsenscode nur langsam und wird intensiver geprüft als alles andere in Bitcoin Core. Konsensfehler werden als Notfälle behandelt: Der Value-Overflow-Bug von 2010 und der Inflation-Bug von 2018 wurden beide unter Zeitdruck mit koordinierten Releases behoben.
4. Änderungen an diesen Regeln erfordern eine koordinierte Übernahme. Soft Forks verschärfen die Regeln, sodass nicht aktualisierte Nodes die neuen Blöcke weiterhin akzeptieren; Hard Forks lockern oder ändern sie, sodass jeder Node upgraden muss oder abgespalten wird. Eine spätere Lektion behandelt beide ausführlich. SegWit (August 2017) war ein Soft Fork; Bitcoin Cash (August 2017) entstand aus einem Hard Fork infolge eines Streits über das Blockgrößenlimit.
5. Einen Block zu erzeugen ist teuer, ihn zu prüfen ist billig. Ein Miner, der einen ungültigen Block erzeugt, verliert die Belohnung und die aufgewendete Energie, weil jeder validierende Node ihn verwirft; Regelverstöße werden so zu einem kostspieligen Glücksspiel. Diese Kosten untermauern die Strenge der Validierung: Die Sicherheit des Netzwerks beruht darauf, dass Tausende unabhängiger Nodes jeden Header und jede Transaktion prüfen, sodass kein Single Point of Failure den gemeinsamen Zustand verfälschen kann.
6. Öffnen Sie einen Block-Explorer wie mempool.space oder blockchain.com. Wählen Sie einen beliebigen aktuellen Block und sehen Sie sich das Feld 'weight' an. Vergleichen Sie diesen Wert mit dem in BIP141 festgelegten Limit von 4.000.000 Weight Units. Beobachten Sie, wie nah moderne Blöcke an diese Obergrenze heranreichen: Miner maximieren den Ertrag pro Byte und bleiben dabei innerhalb der Konsensgrenzen, die jeder Node durchsetzt.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 12
• E. Lombrozo, J. Lau & P. Wuille, BIP141: Segregated Witness (Consensus layer) (2015)
• Bitcoin Core source code: validation.cpp and policy.cpp
• Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, section 5