Blockvorlagen und Stratum V2

Neugier

1. Warum verlässt sich ein Miner mit dedizierter Hardware immer noch auf einen Pool-Betreiber, um zu entscheiden, welche Transaktionen in einen Block aufgenommen werden?
2. Was ermöglicht es einem Miner in einem Pool, die Transaktionen in seinen eigenen Blöcken auszuwählen und dennoch an den Belohnungen des Pools beteiligt zu bleiben?
3. Wie adressiert der Wechsel von JSON zu Binärprotokollen sowohl die Sicherheit als auch die Effizienz im Hochgeschwindigkeits-Mining?

Erkunden

1. Seit es das Protokoll gibt, erfordert jeder gültige Block eine Auswahl von Transaktionen. In den Anfangsjahren trafen Miner, die Full Nodes betrieben, diese Auswahl selbst. Bis 2012, als die Hardware spezialisiert und teuer geworden war, hatten sich die meisten Miner Pools angeschlossen. Das im selben Jahr von Slush eingeführte Stratum-Protokoll standardisierte, wie Pool-Server Arbeit an ihre Mitglieder verteilten. Pools bauten die Blöcke bereits seit 2010; Stratum machte dieses Arrangement weitaus effizienter und übernahm die damit verbundene Zentralisierung der Blockerstellung.
2. Unter Stratum V1 ist der Pool-Betreiber der alleinige Architekt jedes Kandidatenblocks. Der Server sammelt Transaktionen aus seinem eigenen Mempool und schickt den Minern die Bestandteile eines Jobs: die beiden Hälften der Coinbase-Transaktion, den Merkle-Branch, den Hash des vorherigen Blocks, das Target und die Zeit. Der Miner fügt seine eigene Extranonce ein, berechnet die Merkle-Root und sucht nach einem gültigen Hash, hat aber kein Mitspracherecht darüber, welche Transaktionen aufgenommen werden.
3. Diese Architektur verleiht Pool-Betreibern erhebliche Macht über die Transaktionsauswahl. Ein Pool, der einen beträchtlichen Teil der Hashrate des Netzwerks kontrolliert, kann Transaktionen faktisch zensieren, indem er sie einfach aus seinen Vorlagen ausschließt. Auch wenn dies selten geschieht, besteht die strukturelle Möglichkeit dazu. Es bedeutet außerdem: Fällt ein Pool-Server aus oder wird Ziel eines Denial-of-Service-Angriffs, stehen alle verbundenen Miner still – ein Single Point of Failure für ihre Einnahmen.
4. 2012 führten BIP22 und BIP23 `getblocktemplate` ein, womit Mining-Software eine vollständige Blockvorlage von einem Node anfordern konnte; das Verfahren war so konzipiert, dass Pool-Mitglieder ihre eigenen Blöcke bauen konnten. Pools nutzen getblocktemplate intern, um Vorlagen von ihren eigenen Nodes abzurufen, doch Mitgliedern den Bau eigener Blöcke zu erlauben, erschwerte die Validierung und die Abrechnung der Shares, und nur wenige Pools boten es an (Eligius war eine Ausnahme).
5. Stratum V2, ab 2019 unter anderem von Braiins und Matt Corallo entwickelt, gestaltete das Protokoll neu, um diese Probleme anzugehen. Es führt ein Binärformat für geringeren Overhead und Verschlüsselung für mehr Sicherheit ein. Entscheidend ist, dass es das Job Declaration Protocol enthält. Damit kann ein Miner, der seinen eigenen Full Node betreibt, dem Pool-Server seine eigene Blockvorlage mitteilen. Der Pool akzeptiert dann Shares aus diesem individuellen Job und verteilt die Belohnungen nach seinem üblichen Modell, während der Miner die Kontrolle darüber behält, welche Transaktionen aufgenommen werden.
6. Alternative Ansätze wie Oceans DATUM-Protokoll (2024) verfolgen ähnliche Ziele bei der Dezentralisierung der Vorlagenerstellung. Lesen Sie den Abschnitt zur Job Declaration in der Stratum-V2-Spezifikation und vergleichen Sie ihn damit, wie ein Pool, den Sie kennen, seine Vorlagen erstellt. Wo diese Protokolle eingesetzt werden, wandert die Auswahl der Transaktionen zurück zu den Besitzern der Hardware.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• BIP22: getblocktemplate – Fundamentals (2012)
• BIP23: getblocktemplate – Pooled Mining (2012)
• Stratum V2 Specification (stratumprotocol.org, from 2019)
• OCEAN mining pool, DATUM protocol documentation (2024)