Ich habe eine Frage zu Blöcken und Transaktionen, die im nächsten gelösten Block enthalten sind.
Nehmen wir theoretisch an, dass es einen neu propagierten gelösten Block gibt.
Und jetzt gibt es: tx0 und tx1 – nicht im propagierten Block mit der Transaktionszeit vor dem gelösten Block enthalten.
Tx2 – das 10 Sekunden nach dem Lösen des vorherigen Blocks weitergegeben wurde
Tx3 – das 60 Sekunden nach dem Lösen des vorherigen Blocks propagiert wurde
Nehmen die Miner nur Tx0 und tx1, machen Hash und beginnen mit dem Mining (haben bereits Hash davon) oder (ich nehme an, das ist nicht der Fall) fügen sie diese tx2 und tx3 hinzu, die in diesem „10-Minuten“-Fenster propagiert wurden?
Vermutlich müssten sie von vorne anfangen, aber es würde bedeuten, dass, wenn der Bergmann Informationen über einen neuen Block erhält, der von einem anderen Bergmann gelöst wurde, nicht mehr funktioniert, alle Transaktionsformularblöcke, die er gelöst hat, alle Transaktionen in den Pool (tx0 und tx1 in meinem Beispiel), überprüfen Sie, welche Transaktion sich bereits im gelösten Block befindet, und erinnert daran, dass tx Hash erstellt und mit dem Lösen beginnt. Ist das korrekt?
Also im Grunde ist meine Frage, enthält der nächste Block nur die Transaktionen, die weitergegeben wurden, BEVOR der aktuelle Block aufgelöst wurde und NACHDEM die Miner begonnen haben, den aktuellen Block zu finden (also in diesem „10-Minuten-Fenster“ oder gibt es andere Regeln? Ich habe versucht, sie zu finden Lösung in Dokumenten, aber kein Erfolg. (Wenn jemand eine Quelle kennt, wäre ich dankbar)
Mit freundlichen Grüßen
Es gibt keine wirklichen Regeln an sich, nur verschiedene Optimierungen.
ASICs sind schnell . Sie können die gesamten 2^32 möglichen Nonces für einen bestimmten Block in Sekunden durchbrennen, was erfordert, dass Miner das zusätzliche Nonce-Feld in der Coinbase-Transaktion verwenden, um einen neuen Block-Header zu generieren (da eine Änderung der Coinbase-Transaktion die Merkle-Root ändert) und es versuchen nochmal.
Dieser Prozess kann parallel durchgeführt werden – ein Miner kann den N+1-Block-Header vorbereiten, indem er die zusätzliche Nonce in der Coinbase-Transaktion ändert, während er die 2^32-Nonce-Werte des N-ten Block-Headers überprüft.
In ähnlicher Weise kann auch die Transaktionsauswahl parallel erfolgen – eine neue Blockvorlage kann erstellt werden, während ein Miner auf der vorherigen arbeitet, und der Blockheader der neuen Vorlage kann einfach verwendet werden, wenn der Miner die vorherige austauscht, nachdem die Nonce erschöpft ist Leerzeichen (es sei denn, sie finden einen gültigen Block, in diesem Fall muss die Vorlage erneut aktualisiert werden).
Dies ist, was die meisten Mining-Pools tun – die Generierung von Blockvorlagen erfolgt parallel durch den Mining-Pool, und sie geben kontinuierlich aktualisierte Blockvorlagen an alle ihre Miner weiter. Auf diese Weise können sie schnell Transaktionen mit hohen Gebühren in potenzielle Blöcke aufnehmen und gleichzeitig sicherstellen, dass sie jederzeit nach einer Lösung suchen.
Beim Mining gibt es wirklich keinen „Neuanfang“, denn Mining ist praktisch fortschrittsfrei, wie eine Lotterie und anders als ein Rennen. Beim Aktualisieren der Transaktionsliste geht nichts verloren, abgesehen von der vernachlässigbaren Verarbeitungsmenge, die erforderlich ist, um die neue Liste zu erstellen, und der Bandbreite, um sie zu übermitteln.
Der Miner fügt die zusätzlichen Transaktionen hinzu, wann immer er dazu kommt, normalerweise innerhalb von ein paar Sekunden – wobei die Verzögerung einfach Batching ist, um Bandbreite und CPU beim Senden aktualisierter Blockdaten an ihre Hardware zu sparen.