Читать книгу Bitcoin, Blockchain & Co. — Die Wahrheit und nichts als die Wahrheit (überarbeitete Ausgabe 2021/22) - Joe Martin - Страница 54

Natürlich bietet das Bitcoin-System auch dafür eine passgenaue Lösung. Es ist im System intrinsich vorgegeben, dass dieser Split, den man auch als „Fork“ (englisch „Gabel“) bezeichnet, automatisch aufgelöst wird.

Die Auflösung erfolgt umgehend mit dem Block 11, denn der passt, entweder bei 10 A oder bei 10 B nicht mehr. Warum?

Ganz einfach, der Miner, der Block 11 berechnet hat, kennt entweder 10 A oder 10 B. Sein Node hat ihn doch zuvor informiert und ihm entweder 10 A oder 10 B übermittelt, damit er damit beginnen kann, Block 11 zu berechnen. Er beginnt also Block 11 zusammenzurechnen, unter Berücksichtigung des Hashs von Block 10 und zwar entweder des Blocks 10 A oder eben 10 B — beide kann er nicht haben. Damit passt dann, bei erfolgreicher Berech-nung des richtigen Hash-Wertes, sein Block bei einem Teil der von den Nodes gespeicherten Blockchain und bei dem anderen Teil eben nicht.

Wenn er Block 11 auf Basis von 10 A berechnet hat, dann passt 11 A bei allen Nodes, die vorher 10 A hatten, aber nicht bei denjenigen, die 10 B gespeichert haben. Diese werden Block 11 A als ungültig zurückweisen und auf einen Block 11 warten, der mit ihrem gespeicherten Block 10 B kompatibel ist. Verwirrt? Man muss das einige Male durchdenken, dann wird es logisch und leicht nachvoll-ziehbar.

Jetzt ist auch das Rennen gestartet. Wenn ein Block 11 B kommt, dann wird dieser von den 10 B-Nodes angehängt und von den 10 A-Nodes abgelehnt. Zum einen, weil sie schon einen Block 11 haben, nämlich 11 A und zum zweiten, weil 11 B weder zu 10 A noch zu 11 A passt. Wie schnell kommt jetzt ein passender Block 12 ?

In immer seltener werdenden Fällen kommen tatsächlich ein 11 A und ein 11 B und dann ein 12 A, aber das ist schon sehr sehr selten, weil sich bei jedem Verteilvorgang potenziell immer mehr Nodes umentscheiden.

Ein Node ist auch wirtschaftlich programmiert und durch die Software so gesteuert, dass er, wenn Block 12 kommt und er noch keinen Block 11 hat „stutzig“ wird. Er kennt ja nur Block 10 und kann Block 12 nicht an Block 10 anbauen. Also sucht er beim Nachbarn einen gültigen Block 11, der dann nicht nur auf 10 passen soll, sondern auch der richtige für den Block 12 ist. Hört sich ein bisschen kompliziert an, ist aber sehr einfach.

Wenn der Node eine längere Kette beim Nachbarn findet, als er selbst hat, dann storniert und löscht er seine eigene Kette, die er lokal gespeichert hat, und übernimmt ab der Fork den Teil der Kette vom Nachbarn, der länger als seiner ist und auf den Block 12 passt. Im Beispiel von oben wäre Block 9 noch ein gemeinsamer, Blocks 10 und 11 sind jedoch beim Nachbarn andere. Allerdings passt der irritierende Block 12 auf 10 und 11 des Nachbarn. Flugs entscheidet sich der Node, seine Blocks 10 und 11 zu löschen und diese vom Nachbar-Node zu nehmen und an seinen Block 9 anzubauen. Dann passt auch der neue Block 12 an seine lokale Kette. Genial, oder?

Die in den verworfenen Blocks 10 und 11 vorhandenen Trans-aktionen werden wieder aufgelöst und in den Transaktionspool zurückgespielt. Dabei schaut der Node natürlich nach, ob die Transaktionen nicht auch in den Blocks, die er vom Nachbarn genommen hat, vorhanden waren und löscht diese aus seinem Transaktionspool. Die Differenz bleibt dann übrig. Sollte also nun die Transaktion von Alice schon dabei sein, dann ist diese weg und kann nicht mehr ausgeführt werden, weil sie ja schon ausgeführt wurde.

In den allermeisten Fällen betrifft eine solche Fork tatsächlich nur einen Block, der quasi zeitgleich gemint wurde und dessen Trans-aktionen dann als doch nicht erledigt zurückgegeben werden. In seltenen Fällen sind es zwei aufeinanderfolgende Blocks und in ganz seltenen Fällen können es mehr werden, aber das ist schon wieder so selten, dass man es getrost vernachlässigen könnte.