In welcher Reihenfolge erscheinen Transaktionen in einem Block? Liegt es am Bergmann?

Soweit ich das beurteilen kann, scheint es zufällig oder Sache des Miners zu sein.

Aber um Blöcke zu speichern, muss man die Reihenfolge der Transaktionen (in irgendeiner Positionsspalte usw.) beibehalten, da das erneute Generieren des Blocks für einen späteren Abruf es erfordert, die Transaktionen wieder in dieselbe Reihenfolge zu bringen. Ist das richtig?

Die Reihenfolge der Blöcke ist entscheidend (und wird berücksichtigt, da jeder Block mit einem bestimmten vorherigen Block verkettet ist), die Reihenfolge der Transaktionen innerhalb eines einzelnen Blocks jedoch nicht.

Antworten (1)

Die erste Transaktion muss die Belohnung des Miners sein . Die anderen Transaktionen können keine Miner-Belohnungen sein. Transaktionen müssen nach allen Transaktionen erscheinen, von denen sie abhängen. Ansonsten liegt die Reihenfolge beim Miner. Das Ändern der Reihenfolge der Transaktionen ist eines der Dinge, die ein Miner tun kann, um den Block-Hash zu ändern, nachdem er alle möglichen Werte von Nonce ausprobiert hat.

Ich weiß nicht, worauf Sie sich mit Ihrem "Neuerstellen des Blocks zum späteren Abrufen" beziehen. Soweit ich weiß, werden Blöcke nicht regeneriert. Sie werden von einem Miner erstellt, im Netzwerk weitergegeben und auf der Festplatte gespeichert. Sie müssen nicht regeneriert werden.

Transaktionen können von anderen Transaktionen abhängen. Zum Beispiel, wenn Sie Wechselgeld von einer vorherigen Ausgabe ausgeben, die noch nicht bestätigt wurde. In diesem Fall können beide Transaktionen in dieselben Blöcke abgebaut werden, aber die abhängige muss die letzte sein.
@PieterWuille Danke. Ich habe meine Antwort entsprechend aktualisiert.
Danke Chris für deine Antwort, das ist hilfreich. Um die Neugenerierung des Blocks zu verdeutlichen, denke ich darüber nach, die Blöcke in einer relationalen Datenbank zu speichern. Anstatt den Merkle-Baum in der Datenbank zu speichern (riesiger Textklecks), speichere ich die Reihenfolge der Transaktionen mit einer Positionsspalte in der Transaktionstabelle. Dann kann ich den Merkle-Baum neu generieren und müsste nicht alle TX-Hashes duplizieren. Aber ich diskutiere immer noch ... nur den Merkle-Baum in der Blocktabelle zu behalten, würde die Notwendigkeit zunichte machen, ihn jedes Mal neu zu generieren und die TX-Position zu speichern.
OK, Sie brauchen also eine Spalte, die die Reihenfolge der Transaktionen speichert. Wenn Sie den Block aus Ihrer Datenbank „regenerieren“ und an einen Peer weitergeben, möchte der Peer in der Lage sein, ihn zu hashen und sicherzustellen, dass der Hash kleiner als das erforderliche Ziel ist, was nicht der Fall ist, wenn Sie den neu geordnet haben Transaktionen.
@BrianArmstrong: Ich würde nicht empfehlen, den Block in ein anderes Format zu konvertieren und zu erwarten, den Block perfekt regenerieren zu können. Sofern Sie kein Protokoll verwenden, das speziell zur Unterscheidung entwickelt wurde, besteht immer das Risiko, dass etwas Ungewöhnliches im Block Ihren Versuch, ihn neu zu generieren, unterbricht. Mein Rat wäre, den Block entweder so zu speichern, wie er ist, oder nicht zu versuchen, ihn neu zu generieren.
Wie spezifiziert man diese Abhängigkeiten zwischen Transaktionen? Woher weiß ein Miner von Abhängigkeiten?
In welcher Reihenfolge erscheinen Transaktionen in einem Block? Liegt es am Bergmann?
AntwortenHierDatenschutz-Bestimmungen1y, 0v