Es ist eine offene Protokollfamilie, also ein Regelwerk für den Nachrichtenaustausch. Das Mining Protocol überträgt Aufgaben und Ergebnisse; die optionalen Teile Template Distribution und Job Declaration ermöglichen eigene Blockvorlagen. Eine V2-Verbindung allein garantiert diese Möglichkeit nicht.
Eva besitzt einen ASIC, ein auf Bitcoin-Mining spezialisiertes Gerät. Sie hat ihn mit einem Pool verbunden, der mehrere Miner koordiniert und Vergütungen verteilt. Die Geräte suchen ein Rechenergebnis, mit dem ein neuer Block, also ein Paket von Transaktionen, an Bitcoins Historie angefügt werden kann. Ihre Maschine soll die richtige Aufgabe erhalten, und ihre Ergebnisse sollen tatsächlich beim gewählten Pool ankommen. Später möchte Eva auch entscheiden, welche Transaktionen sie in einen Block aufzunehmen versucht. Stratum V2 regelt die Kommunikation zwischen diesen Beteiligten. Das Mining Protocol bildet die Grundlage; Template Distribution und Job Declaration sind optionale Teile für Blockdaten und die Vereinbarung eigener Aufgaben. Zwei Pools mit V2 im Angebot können deshalb unterschiedliche Möglichkeiten bieten. [1] [3]
Stratum V1 erleichterte die Zusammenarbeit von Minern, doch bei der üblichen unverschlüsselten Verbindung blieben Nachrichten unterwegs lesbar. Außerdem wählte meist der Pool die Transaktionen aus. 2019 stellten Jan Čapek und Pavel Moravec von Braiins gemeinsam mit Matt Corallo und weiteren Entwicklern Stratum V2 vor. Sie wollten geschützte, effizientere Kommunikation und mehr Selbstständigkeit für Miner. Die Spezifikation ist öffentlich, und die Entwicklung geht als offenes Projekt weiter. Daraus entstehen weder neue Gültigkeitsregeln für Bitcoin-Blöcke noch ein automatisches Versprechen höherer Einnahmen. [8] [6]
Ein Außenstehender auf dem Internetweg zwischen Eva und dem Pool soll Mining-Nachrichten nicht unbemerkt lesen oder verändern können. V2 verwendet deshalb Verschlüsselung mit einer Integritätsprüfung namens AEAD. Der anfängliche kryptografische Noise-Handshake ist laut Spezifikation für entfernte Verbindungen vorgeschrieben; im lokalen Netz kann seine Verwendung optional sein. Der Client prüft den Server anhand des öffentlichen Autoritätsschlüssels des Pools, den er über einen vertrauenswürdigen Weg bezogen hat. Mit diesem Schlüssel wird die digitale Signatur geprüft, mit der sich der Server ausweist. Geschützt wird die Übertragung: Der Pool sieht weiterhin die ihm übermittelten Daten. Die Verschlüsselung beweist weder sichere Firmware noch korrekte Abrechnung oder Zahlungsfähigkeit. [2] [10]
Eva muss nicht immer ihre Mining-Geräte ersetzen. Ein Translation Proxy ist ein Vermittler, der von einem älteren Gerät Stratum V1 empfangen und zum Pool hin V2 verwenden kann. Der Schutz dieses zweiten Abschnitts verändert die ursprüngliche Verbindung zwischen ASIC und Proxy nicht: Sie bleibt V1 und braucht eigenen Schutz. Ein Proxy kann außerdem mehrere Geräte gemeinsam bedienen und wiederholte Übertragungen derselben Daten reduzieren. Die Protokollübersetzung allein bedeutet noch nicht, dass Eva die Transaktionen auswählt. Dafür benötigt sie weitere Funktionen und einen mitwirkenden Pool. [7] [8]
Um Transaktionen auszuwählen, muss Eva zunächst wissen, welche gültig sind und auf welchen Block sie aufbauen soll. Diese Informationen kann ihr eigener Full Node liefern, der Bitcoins Regeln selbst prüft. Ein Template Provider ist Software, die eine Blockvorlage bereitstellt: den Entwurf eines künftigen Blocks, keinen fertigen Block. Er kann Bitcoin Core oder andere Node-Software mit der nötigen Unterstützung nutzen. Template Distribution übermittelt Aktualisierungen direkt, statt getblocktemplate wiederholt abzufragen. NewTemplate und SetNewPrevHash melden Vorlage und Vorgängerbezug; RequestTransactionData fordert Transaktionsdaten an, SubmitSolution gibt eine gefundene Lösung zurück. [5]
Eva nutzt einen Job Declarator Client. Dieses Programm empfängt ihre Vorlagen und vereinbart deren Verwendung mit einem Pool, der Job Declaration unterstützt. Im Modus Full-Template fordert es über AllocateMiningJobToken eine Arbeitskennung an, nennt die Transaktionen in DeclareMiningJob und beantwortet bei Bedarf ProvideMissingTransactions. Anschließend sendet es SetCustomMiningJob an den Mining-Server. Coinbase-only legt die Transaktionsliste nicht vorab offen und verwendet DeclareMiningJob nicht; dieser Modus arbeitet mit der zugeteilten Kennung und Angaben zur Coinbase, der besonderen Transaktion mit der Blockvergütung. Der Pool kann einen Vorschlag ablehnen, daher sind Ausweichverbindungen wichtig. Eigene Transaktionsauswahl kann Entscheidungen auf mehr Miner verteilen, hebt aber die Zahlungspflicht des Pools nicht auf. [4]
Das bisherige Beispiel lässt sich ohne Kenntnis der Nachrichtennamen verstehen. Beim Einrichten oder Entwickeln kommt es jedoch auf das genaue Format an. V2 überträgt Daten binär, in einer vereinbarten maschinenlesbaren Darstellung. Der Nachrichtenkopf umfasst 6 Bytes; extension_type, msg_type und msg_length kennzeichnen Erweiterung, Nachrichtentyp und Inhaltslänge. Nach Aufbau der kryptografischen Kommunikation ist SetupConnection die erste Protokollnachricht. Sie handelt Protokoll, Version und Funktionsanforderungen aus; SetupConnection.Success bestätigt den Erfolg. Das Etikett V2 ersetzt diese tatsächliche Vereinbarung zwischen konkreten Programmen nicht. [1]
Ein Kanal ist eine getrennte Mining-Sitzung innerhalb einer Verbindung, keine weitere Blockchain und kein Zahlungskanal. Ein Standard Channel weist Arbeit am Blockheader zu, einer kurzen Zusammenfassung der Blockdaten. Ein Extended Channel erlaubt einem Vermittler, mithilfe der Extranonce einen größeren Bereich möglicher Versuche aufzuteilen. Die Extranonce ist ein veränderlicher Teil der Coinbase-Transaktion. Ein Group Channel erleichtert die gemeinsame Aufgabenverteilung an mehrere Kanäle. OpenStandardMiningChannel und OpenExtendedMiningChannel eröffnen die entsprechenden Sitzungen. Der praktische Grund ist einfach: Würden zwei Geräte identische Möglichkeiten ausprobieren, verbrauchten sie Strom für dieselbe Arbeit. [3]
Der Pool muss Evas Beitrag laufend messen. Eine Mining Share ist ein Ergebnis, das die zugeteilte Schwierigkeitsschwelle erfüllt. Die meisten Shares erfüllen die strengere Netzwerkschwelle für einen Block nicht, einzelne können sie jedoch erreichen. NewMiningJob oder NewExtendedMiningJob liefert die Aufgabe, SetNewPrevHash aktiviert den Vorgängerbezug, und SetTarget legt die Schwelle des Kanals fest. SubmitSharesStandard oder SubmitSharesExtended übermittelt Ergebnisse mit Aufgabenkennung, Folgenummer und veränderlichen Headerdaten. Ein angenommenes Ergebnis ist noch keine Auszahlung an die Wallet. Poolvergütung und Blockgültigkeit nach Bitcoins Regeln bleiben getrennte Fragen. [3]
Zuerst prüft sie die Unterstützung durch Gerät, Software und gewählten Pool. Dann klärt sie, welcher Verbindungsabschnitt geschützt ist, woher der Prüfschlüssel stammt und ob sie nur eine sicherere Übertragung möchte oder auch die Transaktionen für einen Block selbst auswählen will. Für Letzteres müssen Template Provider, Job Declarator Client und passende Poolunterstützung zusammen funktionieren. Sie beobachtet Verzögerungen, abgelehnte und veraltete Shares, Fehlerprotokolle und das Verhalten bei Ausfällen. Die Anleitung muss zur eingesetzten Version passen. Stratum V2 kann die Mining-Koordination verbessern; es ersetzt weder sichere Geräteverwaltung noch verändert es die Regeln, mit denen Full Nodes Bitcoin prüfen. [6] [7]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bitcoin, Mining, Mining Pool, Braiins, Braiins Pool, ASIC Miner. Auf diesen Eintrag verweisen außerdem ASIC Miner, Mining Pool, Nonce, Marek „Slush“ Palatinus.