Arbeiten in Stratum-Mining-Pools die meisten Miner an denselben Transaktionen?

Wenn Miner sich mit dem Server verbinden, erhalten sie eine „Job“-Nachricht mit einem merkle_branch-Feld zurück, das Hashes enthält, die Transaktionen entsprechen, die in den Block aufgenommen werden, an dem gearbeitet wird.

Was ich mich frage, ist, stört sich der Pool-Server sehr oft daran, diesen Transaktionssatz zu ändern, oder warten sie nur darauf, dass ein Block gelöst wird, und übertragen erst dann einen neuen Job mit einer anderen Liste?

Mit anderen Worten: Arbeiten zwischen den Blocklösungen alle im Pool im Allgemeinen an denselben Transaktionen?

Antworten (1)

Die Stratum-Pool-Verwaltungssoftware, mit der ich vertraut bin, ist https://github.com/zone117x/node-stratum-pool , also kann ich Ihnen sagen, was sie tun. Stratum ist jedoch ein Protokoll, sodass mehrere Softwareteile es unterschiedlich implementieren könnten.

Dieser Parameter wird durch das in der config gesteuert blockRefreshInterval. Alle blockRefreshIntervalMillisekunden prüft der Stratum-Server den Bitcoin-Kernknoten über RPC auf neue Blöcke mit getblocktemplate. Wenn es seit dem letzten Aufruf keinen neuen Block gegeben hat getblocktemplate, setzt er den aktuellen Job, der an alle neuen Arbeitsanforderungen zurückgegeben wird.

Das in der Konfiguration vorgeschlagene Abfrageintervall beträgt alle 1 Sekunde. Bergleute können auch Arbeit zu sehr unterschiedlichen Raten anfordern, so dass einige möglicherweise an älteren Arbeiten arbeiten. Solange es für den nächsten Block funktioniert, gilt es jedoch als gültig. Der Pool verwendet jedoch dieselben Node- und Mempool-Daten, um Blöcke zu erstellen. Angesichts all dieser Variablen werden Miner also höchstwahrscheinlich nicht an genau demselben Transaktionssatz arbeiten .

Relevante Codebits:

Ok, danke, das ist eine gute Sache. Von dem, was ich anfangs sehe (es könnte eine Weile dauern, bis ich das verdaut habe), gibt processTemplate nur false zurück, wenn sich der Block nicht geändert hat. Mir fehlt also immer noch, wo die Daten aktualisiert werden, wenn sich der Block nicht geändert hat. Es scheint, als würde es die gleichen Daten behalten, es sei denn, der Block ändert sich, was bedeutet, dass alle Miner im Wesentlichen am gleichen Job und am gleichen Satz von TXs arbeiten würden. Ich werde es mir aber weiter anschauen.
Jetzt, wo ich es mir noch einmal ansehe, gebe ich dir recht. Dies scheint jedoch eine schlechte Strategie zu sein, da neuere Transaktionen nicht abgebaut würden. Es könnte absichtlich gemacht werden, wenn es einen Vorteil für die Miner hätte, aber ich sehe keine Vorteile auf Anhieb. Die reguläre Get-Block-Template-Abfrage scheint das Ergebnis nur zu verwenden, wenn es einen neuen Block gegeben hat. Vielleicht sollten wir dazu ein Github-Issue eröffnen.
Nach ihrem Commit-Log und der Liste der nicht gepflegten Probleme zu urteilen, glaube ich jedoch nicht, dass es etwas nützen wird. Sie können versuchen, sich github.com/int6/CoiniumServ oder github.com/slush0/stratum anzusehen .
Unnötig zu erwähnen, dass die Art und Weise, wie es in jedem anständig implementierten Stratum-Server funktionieren sollte, darin besteht, dass Sie regelmäßig nach neuen Transaktionen suchen (damit neue Transaktionen abgebaut werden) und den aktuellen Job aktualisieren, der von hier aus ausgegeben wird (bis ein neuer Block ist gefunden). Alle Arbeiten, die für alle vergebenen Jobs ausgeführt werden, die auf dem letzten Block aufbauen, sind gültig. Im erwarteten Verhalten würden Miner also die meiste Zeit nicht genau denselben Transaktionssatz abbauen.
OK danke. Ich werde dies als Antwort markieren. Ich denke, mit den obigen Kommentaren bietet es genug Informationen. Natürlich gibt es auch andere Stratum-Pool-Implementierungen, die möglicherweise anders funktionieren als diese Codebasis. Letztendlich muss ich also vielleicht herausfinden, was die Top-Mining-Pools tun.
Arbeiten in Stratum-Mining-Pools die meisten Miner an denselben Transaktionen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v