Warum das Bitcoin-Netzwerk im Jahr 2106 stehen bleiben wird!

Am Sonntag, den 07. Februar im noch weit entfernten Jahr 2106 ist es so weit: Das Bitcoin-Netzwerk kommt zu einem Stillstand. Sämtliche neu gefundenen Blöcke sind ungültig, keine Transaktionen können mehr verarbeitet werden und das fast 100 Jahre alt gewordene digitale Zahlungsnetzwerk bricht in sich zusammen. Was hat es mit diesem seltsamen Datum auf sich und was können wir daraus über die Veränderbarkeit des Bitcoin-Protokolls lernen? Schauen wir uns das Thema etwas genauer an!

Computer gehen grundlegend anders mit Zahlen um, als wir Menschen es tun: binär, mit Nullen und Einsen. Für Zeit- und Datumsangaben hat sich dafür die sogenannte Unixzeit etabliert, die schlichtweg die vergangenen Sekunden seit dem 01. Januar 1970 – auch The Epoch genannt – immer weiter hochzählt. Das funktioniert eigentlich auch ziemlich gut, zumindest so lange, bis der dafür freigegebene Speicherplatz ausgeschöpft wurde, was uns zu einem echten Klassiker der Informatik bringt: Das Jahr-2038-Problem.

Für die allermeisten Programme und Anwendungen ist dieses „Problem“ eigentlich vollkommen harmlos. Eine entsprechende Anpassung auf z. B. 64 Bit Ganzzahlen ist nicht nur sehr einfach, sondern wird auf den allermeisten modernen Systemen ohnehin standardmäßig bereits für die Uhrzeit verwendet – genug Platz für die nächsten knapp 300 Milliarden Jahre. Einige Schlagzeilen wird man vielleicht in den Nachrichten sehen, doch unterm Strich wird die Unixzeit weiter vor sich hin ticken.

Auch das Bitcoin-Netzwerk bleibt von Zeitangaben aus der echten Welt nicht verschont – allerdings mit einem kleinen Unterschied: Der Zeitstempel, der im Header eines jeden Bitcoin-Blocks stehen muss, ist eine vorzeichenlose Ganzzahl, und hat somit auch das höchstwertige 32. Bit zur freien Verfügung. Das Jahr-2038-Problem wird dadurch allerdings nicht gelöst, sondern lediglich ins Jahr 2106 verschoben – genauer gesagt auf den Sonntagmorgen des bereits erwähnten 07. Februars, wenn schlichtweg kein Platz mehr vorhanden ist, um die Sekunden seit 1970 weiter zu zählen.

Doch wieso genau ist das überhaupt ein Problem? Eine grundlegende Regel im Bitcoin-Protokoll ist, dass Blöcke mittelfristig einen steigenden Zeitstempel aufweisen müssen. Kurzfristig sind kleinere Unterschiede zwar kein Problem, ganz grundsätzlich können zukünftige Blöcke aber natürlich keinen Zeitstempel haben, der weit in der Vergangenheit zurückliegt. Bleiben die Zeitstempel allerdings im Jahr 2106 technisch bedingt stehen, dauert es nicht lange, bis neu gefundene Bitcoin-Blöcke vom Netzwerk als ungültig abgelehnt werden würden.

Um den Untergang des Bitcoin-Netzwerks im Jahr 2106 abzuwenden, braucht es früher oder später ein entsprechendes Update, welches die Regeln rund um den Block-Zeitstempel auflockert – z. B. durch eine Erweiterung des Feldes auf eine 64 Bit Ganzzahl. Solch eine Änderung kann allerdings nicht „einfach so nebenbei“ umgesetzt werden. Die Bitcoin-Software läuft auf tausenden weltweit verteilten Computern, betrieben von Nutzern, die selbst über die Regeln und Funktionsweise dieser Software entscheiden können. Auch würde man mit einer solchen Anpassung Regeln verändern, die über die Gültigkeit von Blöcken entscheiden, was zu Konflikten auf Netzwerk-Ebene führen kann und deshalb sorgfältig geplant werden sollte.

Der ein oder andere wird es sich bereits denken können: Eine Erweiterung des Zeitstempel-Feldes würde in die Kategorie Hard-Fork fallen – ein Block mit einem größeren 64 Bit Zeitstempel wäre nämlich aus der Sicht eines heutigen Bitcoin-Clients ungültig. Einige machen sich deshalb mehr Sorgen um das „Y2K106“ Problem, als eigentlich angebracht wäre und bauschen das Thema unnötig auf (so wie wir mit dem Titel dieses Artikels 😉️).

In der Geschichte von Bitcoin kam es bereits zu solchen Hard-Forks, z. B. mit Bitcoin Cash im Jahr 2017, als die Debatte über die Erhöhung der maximalen Blockgröße sowohl die Community als auch das Netzwerk spaltete. Der Begriff hat unter anderem deshalb einen schlechten Ruf und wird häufig sogar synonym mit einer Fork auf Netzwerk-Ebene verwendet. Doch ein entscheidender Aspekt der hitzigen Debatte im „Blocksize-War“ war eben genau das: Man war sich nicht einig – die Änderung war hoch kontrovers.

Doch anders als häufig angenommen, hat eine Hard-Fork nicht automatisch eine Spaltung des Netzwerks, also eine „Fork auf der Blockchain“ zur Folge. Eine hoch kontroverse Änderung kann nicht nur bei einer Hard-Fork, sondern auch bei einer Soft-Fork zu einer Spaltung des Netzwerks führen, es handelt sich schlichtweg um zwei unterschiedliche Konzepte. Im Kontext des „Jahr-2106-Problems“ bedeutet dies: Eine nicht kontroverse, eigentlich offensichtliche Änderung, wie das Verhindern des Untergangs von Bitcoin, kann problemlos mit einer Hard-Fork umgesetzt werden – ganz ohne Spaltung des Netzwerks.

Zur Planung haben die Nutzer und Entwickler von Bitcoin allerdings noch mehr als genug Zeit, weshalb es schlichtweg unsinnig wäre, sich schon heute wegen eines Problems verrückt zu machen, das man selbst nicht einmal miterleben wird. Trotzdem sollte das Beheben des Y2K106-Problems sorgfältig und wohlüberlegt geplant werden, damit der koordinierte Wechsel auf eine Bitcoin-Version mit „moderner Zeitrechnung“ reibungslos gelingt. Auch gibt es unterschiedliche Ansätze, um das gewünschte Ergebnis zu erzielen, die mehr oder weniger stark in das bestehende Bitcoin-Protokoll eingreifen – auch solche, die gar keine direkte Änderung am Feld des Zeitstempels benötigen.

Zusammenfassend lehrt uns diese Bitcoin-Anekdote vor allem eines: Die Konsensregeln des Bitcoin-Netzwerks sind sehr tief verwurzelt, was sowohl elementare Grundpfeiler, wie die Beschränkung auf fast 21.000.000 BTC, als auch triviale Bausteine wie die limitierte Zeitrechnung betrifft. Das Besondere ist aber, dass keine dieser Regeln unwiderruflich in Stein gemeißelt ist. Theoretisch könnte jede Regel beliebig verändert werden, es braucht dafür lediglich eine relevante ökonomische Mehrheit. Während dies bei einer Ausweitung der Gesamtmenge an Bitcoin an schierer Unmöglichkeit grenzt, wird es bei der Behebung des berühmt-berüchtigten Y2K-Problems wahrscheinlich kaum zu Streitigkeiten kommen und nicht mehr als eine nette Anekdote zurücklassen.