Unter Beschneiden der Zweige in Merkle Tree schreibt Nick ODell: "Ein Blatt (eine Transaktion) kann beschnitten werden, wenn alle seine Ausgaben ausgegeben wurden." Ich dachte also, wenn eine Transaktion eine der letzten in einem Block ist, kann ein Miner die Transaktion in den neuen Block kopieren, der abgebaut wird. Auf diese Weise benötigt der Miner (und der Rest des Netzwerks) diesen Block nicht mehr zur Validierung und er kann in den Äther freigegeben werden.
Nick schrieb auch, dass der Bitcoin-Kern sowieso nicht auf diese Weise beschnitten wird, weil er „unter der Annahme arbeitet, dass Sie alle Blöcke herunterladen und validieren“. Ich untersuche die Gründe dafür , um zu sehen, ob sie angegangen werden können, ohne alles zu behalten.
Die Idee hinter dem Herunterladen der gesamten Blockchain vor dem Start des Pruning-Modus ist, dass Sie sicherstellen möchten, dass das, womit Sie beginnen, gültig ist. Der einzige bekannte Weg, dies zu tun, besteht darin, das Ganze zu erhalten. Oder ist es? Es scheint, dass die Allgegenwart der Blockchain selbst mit der Allgegenwart des gültigen UTXO-Sets übereinstimmt. Wenn Sie also ein gültiges UTXO-Set erhalten und es mit dem übereinstimmt, was jeder andere Knoten sagt, können Sie loslegen. Abgesehen von Sybil-Angriffen, richtig? Würde ein so erfolgreicher Sybil-Angriff auch eine Fälschung der Blockchain selbst ermöglichen?
Eine Schwierigkeit bei meinem Move-a-Transaction-Ansatz besteht darin, dass ein neuer Knoten, wenn er die Blockchain herunterlädt (wie viel davon noch benötigt wird), jeden Block überprüfen möchte, und wenn Block X fehlt, dann alle Blöcke, die enthalten Eingaben, die in Block X erstellt wurden, können nicht validiert werden, wenn dies bedeutet, dass die darin enthaltenen Transaktionen validiert werden müssen. Der Blockheader selbst kann jedoch noch validiert werden. Der Header von Block X kann nicht validiert werden, da sein Inhalt fehlt. Aber reicht die Tatsache, dass der Hash von Block X in Block X+1 benötigt wird, nicht aus, um darauf zu vertrauen, dass Block X gültig war, und dass daher auch die Blöcke X+1, X+2, X+3 usw. , bis hin zu und einschließlich dem zu validierenden Block, der eine Transaktion enthält, die eine (vermutlich) in Block X erstellte Ausgabe verwendet?
Wenn schließlich eine Transaktion auftaucht, die eine nicht verbrauchte Ausgabe der verschobenen Transaktion ausgibt, kann sie nicht validiert werden, da Block X fehlt. Wenn jedoch der Index, der identifiziert, welcher Block welche Transaktion enthält, von dem Miner aktualisiert wurde, der die Transaktion verschiebt, dann ist dies einfach zu lösen.
Müsste diese Indexaktualisierung auch alle unmittelbar untergeordneten Transaktionen der verschobenen Transaktionen adressieren, damit bestehende, zuvor gültige Transaktionen noch validiert werden könnten, indem die Quelltransaktion im neu abgebauten Block gefunden wird? Ich denke nicht, dass es notwendig ist, Transaktionen, die sich in Blöcken mit validierten Headern befinden, erneut zu validieren, oder?
Dies scheint eine Menge Aufwand für absolut keinen Nutzen zu sein.
Im Bitcoin-Pruning-Modell verwerfen Sie sowieso ALLE diese alten Blöcke und behalten NUR das utxo-Set. Es spielt keine Rolle, ob sich ein utxo in einem alten oder einem neuen Block befindet, Sie behalten es immer noch im utxoset. Alle Blöcke, die Sie aufbewahren, dienen lediglich der Bequemlichkeit und der Unterstützung anderer Knoten, die diese Blöcke anfordern.
Die einfache Antwort ist JA, aber es gibt bessere Lösungen. Während alle Transaktionen in neueren Blöcken dargestellt werden können, ist das Vorhandensein einer Transaktion in einem sehr alten Block NICHT das, was die Art der Beschneidung verhindert, die ich mir vorgestellt habe. Um die frühesten Blöcke für die Validierung der Geschichte von Bitcoin unnötig zu machen, ist nur der Nachweis erforderlich, dass UTXOs in ihnen tatsächlich existieren und dass sie noch nicht ausgegeben wurden. Ein aktuelles UTXO-Set würde das schaffen, muss sich aber beweisen. Jonas Schnelli schlug im Februar etwas ganz Ähnliches vor.
Murch
Murch