Mining Pool

Anna besitzt eine Mining-Maschine. Strom bezahlt sie jeden Tag. Wenn sie allein schürft, kann sie jedoch sehr lange auf einen eigenen Block warten. Findet sie einen Block, den das Netzwerk akzeptiert, gehört ihr dessen Ertrag; bis dahin verdient sie mit diesem Mining nichts. Langes Warten bedeutet auch nicht, dass der Erfolg nun kurz bevorsteht. Bei unveränderten Bedingungen hat jeder neue Versuch dieselbe Chance. Im Pool arbeitet ihre Maschine mit anderen zusammen. Der Pool kann auch Miner bezahlen, die einen bestimmten Block nicht selbst gefunden haben: Er misst ihre Beiträge und wendet ein vereinbartes Vergütungsmodell an. Anna verzichtet darauf, den gesamten Ertrag ihres eigenen Blocks zu behalten, und erhält dafür kleinere, meist regelmäßigere Einnahmen. Die Netzwerkschwierigkeit sinkt dadurch nicht, und es entstehen keine zusätzlichen Belohnungen. Üblicherweise verlangt der Pool außerdem eine Gebühr. Ob die Einnahmen Strom und Gerät finanzieren, ist eine andere Frage. [6] [7]

Der Pool sieht nicht jede Berechnung von Annas Maschine. Er muss trotzdem prüfen können, ob sie arbeitet, und ihren Beitrag abschätzen. Deshalb stellt er eine leichtere Bedingung als das Bitcoin-Netzwerk. Ein Ergebnis, das sie erfüllt, heißt Mining Share, kurz Share. So kann die Maschine regelmäßig überprüfbare Ergebnisse melden, ohne einen Block gefunden zu haben. Aus akzeptierten Shares und ihrer Schwierigkeit schätzt der Pool die Arbeit statistisch. Das ist kein exakter Zähler aller Versuche. Bei unterschiedlicher Share-Schwierigkeit lassen sich die bloßen Anzahlen zweier Geräte nicht direkt vergleichen. Ein gewöhnlicher Share erzeugt weder einen Bitcoin-Block noch eine Zahlungsbestätigung. Erst ein seltenes Ergebnis, das auch die Netzwerkbedingung erfüllt, ermöglicht die Einreichung eines Blocks. Dieser muss auch alle übrigen Prüfungen bestehen. Ein Share belegt also Arbeit gegenüber dem Pool; er ist kein frisch erzeugtes Stück Bitcoin. [7] [9]

Anna kann dieselbe Maschine an verschiedene Pools anschließen und unterschiedliche Ertragsverläufe sehen. Ein Grund ist das Abrechnungsmodell. PPS, ausgeschrieben Pay Per Share, schreibt für jeden akzeptierten Share einen vorher festgelegten Erwartungswert entsprechend seiner Schwierigkeit gut. Anna muss nicht auf einen glücklichen Blockfund ihres Pools warten: Das Risiko zufälliger Schwankungen bei den Funden trägt der Betreiber. Das garantiert weder seine Zahlungsfähigkeit noch einen festen Stundenlohn. Die Zahl der Shares und die Mining-Bedingungen ändern sich weiterhin. FPPS, Full Pay Per Share, ergänzt den erwarteten Anteil an neu ausgegebenen Bitcoins meist um geschätzte Transaktionsgebühren. PPLNS, Pay Per Last N Shares, verteilt hingegen den Ertrag tatsächlich gefundener Blöcke nach der Arbeit in einem festgelegten zurückliegenden Fenster. Die Vergütung hängt damit stärker vom aktuellen Glück des Pools ab. Wie dieses Fenster bemessen wird, legen dessen Regeln fest; es ist nicht unbedingt einfach die letzte Stunde. Für einen Vergleich reicht das Kürzel allein nicht. Gebühren, Schätzverfahren, Fenstergröße und der Umgang mit Blöcken außerhalb der Haupthistorie, den Stale Blocks, zählen ebenfalls. Das Vergütungsmodell bestimmt Anspruch und Berechnung. Wann das Guthaben in die Wallet überwiesen wird, regelt der Pool gesondert. [7] [8]

Anna sieht ihr Kontoguthaben wachsen. Solange es nicht in ihrer Wallet angekommen ist, vertraut sie darauf, dass der Pool korrekt Buch führt und auszahlt. Sie sollte daher wissen, wann gezahlt wird, ob ein Mindestbetrag nötig ist, welche Gebühren anfallen und an welche Adresse das Geld geht. Dienste unterscheiden sich: Automatische Gutschriften bedeuten nicht automatisch sofortige Überweisungen. Auch der Betrieb verdient Aufmerksamkeit: akzeptierte und abgelehnte Shares, deren als Share Difficulty bezeichnete Schwierigkeit, erreichbare Server und Ersatzverbindungen. Die Firmware ist die Steuerungssoftware des Miners und muss mit dem Pool zusammenarbeiten. Längerfristige Pool-Aufzeichnungen mit eigenen Betriebsdaten und tatsächlichen Zahlungen zu vergleichen, hilft, Unstimmigkeiten zu entdecken. Gefundene Blöcke lassen sich auf der Blockchain prüfen; die vollständige interne Buchhaltung des Pools steht dort aber nicht. Wichtig sind außerdem die Möglichkeit, den Pool zu wechseln, und die Frage, wer die Transaktionen auswählt. [8] [9]

Ändert sich die Aufgabe, bevor das Ergebnis eintrifft, kann der Pool es möglicherweise nicht mehr anrechnen. Latenz bezeichnet hier die Kommunikationsverzögerung zwischen Gerät und Pool. Ein share kann als veraltet (stale), doppelt, fehlerhaft aufgebaut oder nicht zur zugewiesenen Aufgabe passend abgelehnt werden. Höhere Latenz zwischen Miner und Pool, langsame Aktualisierungen der Aufgaben und Netzwerkausfälle erhöhen die verlorene Arbeit. Der Anteil der stale shares sagt deshalb etwas über die betriebliche Effizienz der Verbindung zwischen Miner und Pool aus; er ist nicht dasselbe wie ein Stale Block in der Blockchain. [9]

Die Blockbelohnung wird in einer besonderen ersten Transaktion erfasst, der Coinbase Transaction. Ihre Outputs legen Beträge und die Bedingungen fest, unter denen sie später ausgegeben werden können. Die Belohnung kann somit an einen oder mehrere Empfänger gehen. Das Block Template ist der Blockentwurf einschließlich der ausgewählten Transaktionen. In einem klassischen Pool erstellt gewöhnlich der Pool-Betreiber das Block Template und bestimmt auch den Empfänger des Coinbase-Outputs. Der Miner probiert vor allem verschiedene Werte innerhalb der zugeteilten Aufgabe aus und sucht ein Ergebnis, das die Bedingung des Netzwerks erfüllt. Dadurch gewinnt der Pool Einfluss auf die Transaktionsauswahl, aber nicht die Fähigkeit, einen ungültigen Block durchzusetzen; jeder Full Node prüft den Block unabhängig. Ein Full Node ist ein Programm, das Blöcke und Transaktionen nach den Bitcoin-Regeln überprüft. [6] [10]

Neben der Auszahlung zählt, wer entscheidet, welche Zahlungen in Blöcke gelangen. Werden bestimmte Transaktionen ausgelassen, kann sich ihre Bestätigung verzögern. Die Konzentration von Pools ist wichtig, weil eine kleine Zahl von Koordinatoren die Aufnahme von Transaktionen, die Einführung von Software und die kurzfristige Verteilung der Hashrate beeinflussen kann. Hashrate bezeichnet die Zahl der Mining-Berechnungen pro Sekunde. Die Hashrate eines Pools ist jedoch nicht mit dem Eigentum an Mining-Geräten gleichzusetzen: Betreiber spezialisierter Mining-Maschinen, sogenannter ASICs, können ihre Geräte mit einem anderen Pool verbinden. Das Risiko steigt, wenn Wechselkosten, Verträge oder Firmware diese Möglichkeit einschränken. [6] [10]

Stratum legt die Kommunikation zwischen Miner und Pool fest. Verschlüsselung schützt die übertragenen Nachrichten; Authentifizierung hilft, die Gegenstelle zu überprüfen. Stratum V1 dient zur Vergabe von Mining-Arbeit, und die Kontrolle über die Vorlage bleibt gewöhnlich beim Pool. Stratum V2 trennt die Rollen deutlicher und unterstützt verschlüsselte sowie authentifizierte Kommunikation. Das optionale Job Declaration Protocol erlaubt dem Miner, eine eigene Vorlage mit eigener Transaktionsauswahl einzureichen, sofern sowohl Miner als auch Pool die entsprechenden Komponenten unterstützen. Das Mining Protocol von Stratum V2 allein kann ohne diese Möglichkeit betrieben werden; die Bezeichnung Stratum V2 garantiert daher für sich genommen keine unabhängige Transaktionsauswahl. [10]

Für technisch Interessierte: Ein Block Template ist ein Entwurf für den Inhalt eines Blocks. Worker bezeichnet ein angeschlossenes Mining-Gerät oder das Konto, unter dem seine Arbeit erfasst wird. Der Header fasst die wesentlichen Blockdaten zusammen. Eine Mining-Aufgabe basiert auf einem Block Template oder einer vergleichbaren Konstruktion eines Kandidatenblocks. BIP22 beschreibt getblocktemplate und BIP23 dessen Erweiterungen für Pool-Mining. Das Pool-Protokoll übermittelt den Workern die erforderlichen Felder, Daten der Coinbase-Transaktion und den Suchraum. Ein ASIC Miner probiert verschiedene Header aus und berechnet ihren Hash, einen numerischen Fingerabdruck. Für Proof of Work, den Nachweis von Rechenarbeit, darf dieser Hash höchstens so groß sein wie der vom Netzwerk vorgegebene Grenzwert, das Target. Der Block muss außerdem die übrigen Bitcoin-Regeln erfüllen. [1] [2] [5]

Technischer Hintergrund: Der target ist eine Zahl, die der Hash als Ergebnis der Mining-Berechnung nicht überschreiten darf; Gleichheit genügt ebenfalls. VarDiff bedeutet variable Share-Schwierigkeit. Der Pool setzt einen leichteren share target, damit er häufig genug Ergebnisse zur Messung erhält. Der Netzwerk-target von Bitcoin ist wesentlich schwieriger zu erfüllen. Ein akzeptierter Share, der nur den Pool-target erfüllt, wird nach den Vergütungsregeln des Pools angerechnet; erfüllt derselbe Hash auch den Netzwerk-target, kann ein Kandidatenblock eingereicht werden. VarDiff verändert die Schwierigkeit der shares und damit ihre Häufigkeit, nicht die Konsens-Difficulty von Bitcoin. [9]