Was passiert mit alten Transaktionen im Falle eines Forks?

Ich bin verwirrt über Forking. Was passiert mit der „alten“ Version einer Blockchain und zugehörigen Transaktionen/Daten im Falle eines Forks? Können sie noch gelöscht werden oder ist der neue Zweig noch auf sie angewiesen, um die Kontinuität zu gewährleisten?

Nach welcher Art Gabel fragst du? Es gibt kurzlebige Gabeln, bei denen einige Blöcke entweder versehentlich oder absichtlich verwaisen (veraltet wurden); es gibt Soft Forks, die die Konsensregeln abwärtskompatibel ändern; und es gibt Hard Forks, die die Konsensregeln rückwärtsinkompatibel ändern.
Ich bin neugierig darauf, sowohl in Bezug auf Soft- als auch Hard-Forks. Danke!

Antworten (2)

Was passiert mit der „alten“ Version einer Blockchain und zugehörigen Transaktionen/Daten im Falle eines Forks? Können sie noch gelöscht werden

Bei einem Soft Fork müssen historische Daten aufbewahrt werden. Im Falle einer Hard Fork ist es nicht unbedingt erforderlich, historische Daten aufzubewahren, aber sie werden fast immer beibehalten.

Etwas mehr ins Detail gehen: Ein Soft Fork ändert die Regeln, denen alle folgen, rückwärtskompatibel, indem sie die Regeln nur strenger macht. Beispielsweise haben Miner Zugriff auf ein Feld namens "Coinbase", in das sie früher beliebige Serien von 2 bis 100 Bytes stecken konnten; später wurde eine Regel hinzugefügt, die in der BIP34-Softfork spezifizierte, dass die ersten paar Bytes dieses Felds die Höhe des aktuellen Blocks sein mussten (Abstand vom ersten Block). Dies ist strenger, sodass jeder, der die neue Regel befolgt, auch automatisch die alten Regeln befolgt. Dies ist abwärtskompatibel, da jeder, der die alten Regeln befolgt hat und nicht bereits gegen die neuen Regeln verstößt, seine Software weiterhin normal verwenden kann.

Damit diese Abwärtskompatibilität jedoch zutrifft, müssen die in der Blockchain verfügbaren Daten nicht nur verfügbar bleiben, sondern im Grunde im gleichen Format bleiben. Sie können damit manchmal tricksen, wie es Segwit getan hat, indem Sie Signaturen in ein neues Feld in Transaktionen verschoben haben, aber der Umfang der Änderungen, die Sie vernünftigerweise vornehmen können, ist begrenzt.

Bei Hard Forks werden die Regeln rückwärtsinkompatibel geändert, sodass sowieso jeder upgraden muss. Dies gibt Ihnen eine leere Tafel, auf der Sie Änderungen am gewünschten System vornehmen können. In Bezug auf den alten Blockchain-Verlauf können Sie sich auf den aktuellen Zustand des Systems festlegen und den gesamten Verlauf verwerfen, der verwendet wurde, um diesen Zustand zu erreichen.

Stellen Sie sich zum Beispiel vor, Alice schürft einen Bitcoin und zahlt diesen Bitcoin dann an Bob. Die Blockchain wird sowohl die Mining-Transaktion als auch die Zahlungstransaktion beinhalten, aber wenn sowieso alle upgraden, ist es einfach, einfach zu sagen „Bob beginnt mit 1 Bitcoin“ und Alices Mining-Transaktion wegzuwerfen.

Wenn Sie historische Daten wegwerfen und nach einer Bitcoin-Hardfork nur den aktuellen Stand beibehalten würden, könnten Sie die aktuelle Blockkettengröße um etwa 98 % auf nur wenige Gigabyte reduzieren.

Mir ist jedoch kein Hard Fork von Bitcoin oder Altcoin bekannt, der jemals die historischen Daten weggeworfen und sich einfach auf den aktuellen Stand festgelegt hat. Ich weiß nicht, warum das so ist.

Wenn Sie die frühere Transaktion verwerfen und mit einem neuen Status beginnen, würde sich das nicht auf das 1: 1-Coin-Verteilungsschema auswirken, das mit jeder Hard Fork geliefert wird.

„Was passiert mit alten Transaktionen im Falle eines Forks?“ Nichts. die "alten" Transaktionen sind weiterhin verfügbar. ansonsten ist es keine Gabel. Beide Zweige der Fork haben bis zum Zeitpunkt der Fork die gleiche Historie.

"Können sie noch gelöscht werden oder ist der neue Zweig immer noch auf sie angewiesen, um die Kontinuität zu gewährleisten?" Nach heutigem Stand werden Transaktionen generell nicht gelöscht. Die alten Transaktionen sind erforderlich, um die Integrität zu gewährleisten, da Sie sie benötigen, um den Verlauf Ihrer Bitcoins zu verfolgen und die Hash-Werte aller Blöcke erneut zu validieren.