C’est un ensemble ouvert de protocoles, autrement dit des règles d’échange de messages. Mining Protocol transmet les tâches et les résultats ; Template Distribution et Job Declaration, facultatifs, permettent d’utiliser son propre modèle de bloc. Une connexion V2 ne garantit pas à elle seule cette possibilité.
Eva possède un ASIC, un appareil spécialisé dans le minage de Bitcoin. Elle l’a connecté à un pool qui coordonne plusieurs mineurs et répartit les récompenses. Les machines cherchent un résultat de calcul permettant d’ajouter un nouveau bloc, un ensemble de transactions, à l’historique de Bitcoin. Elle veut que sa machine reçoive les bonnes consignes et que ses résultats parviennent bien au pool choisi. Plus tard, elle souhaite aussi décider quelles transactions elle tentera d’inclure dans un bloc. Stratum V2 organise les échanges entre ces participants. Mining Protocol en constitue la base ; Template Distribution et Job Declaration sont des parties facultatives pour fournir les données du bloc et convenir d’un travail personnalisé. Deux pools annonçant V2 peuvent donc proposer des possibilités différentes. [1] [3]
Stratum V1 a facilité la coopération entre mineurs, mais sa connexion habituelle non chiffrée laissait les messages lisibles en chemin. Le pool choisissait aussi généralement les transactions. En 2019, Jan Čapek et Pavel Moravec, de Braiins, ont présenté Stratum V2 avec Matt Corallo et d’autres développeurs. Ils visaient une communication protégée, plus efficace, et davantage d’autonomie pour les mineurs. La spécification est publique et le développement se poursuit dans un projet ouvert. Cela n’introduit ni nouvelles règles de validité des blocs Bitcoin ni promesse automatique de revenus supérieurs. [8] [6]
Un tiers placé sur le trajet internet entre Eva et le pool ne doit pas pouvoir lire ou modifier discrètement les messages de minage. V2 emploie donc le chiffrement avec un contrôle d’intégrité des messages, appelé AEAD. La négociation cryptographique initiale Noise est obligatoire pour les connexions distantes selon la spécification ; son utilisation peut être facultative sur un réseau local. Le client vérifie le serveur à l’aide de la clé publique de l’autorité du pool, obtenue par une voie fiable. Cette clé sert à vérifier la signature numérique par laquelle le serveur prouve son identité. Cela protège le transfert : le pool voit toujours les données reçues. Le chiffrement ne prouve ni la sûreté du firmware, ni la justesse des comptes, ni la capacité du pool à payer. [2] [10]
Eva n’a pas toujours besoin de remplacer son matériel. Un Translation Proxy est un intermédiaire qui peut recevoir du Stratum V1 d’un ancien appareil et utiliser V2 vers le pool. Protéger cette seconde liaison ne transforme pas la communication entre l’ASIC et le proxy : elle reste en V1 et nécessite sa propre protection. Un proxy peut aussi servir plusieurs machines ensemble et limiter les transmissions répétées des mêmes données. Traduire les protocoles ne signifie pas qu’Eva choisit les transactions. Il faut pour cela des fonctions supplémentaires et un pool qui les accepte. [7] [8]
Pour choisir les transactions, Eva doit d’abord savoir lesquelles sont valides et sur quel bloc construire. Elle peut obtenir ces informations de son propre nœud complet, qui vérifie lui-même les règles de Bitcoin. Un Template Provider est un logiciel fournissant un modèle de bloc : une ébauche de futur bloc, pas un bloc terminé. Il peut s’appuyer sur Bitcoin Core ou un autre nœud doté du support nécessaire. Template Distribution transmet directement les mises à jour plutôt que d’interroger constamment getblocktemplate. NewTemplate et SetNewPrevHash annoncent le modèle et son rattachement au bloc précédent ; RequestTransactionData demande les données des transactions et SubmitSolution renvoie une solution trouvée. [5]
Eva utilise un Job Declarator Client, un programme qui reçoit ses modèles et convient de leur utilisation avec un pool prenant en charge Job Declaration. En mode Full-Template, il demande un identifiant de travail via AllocateMiningJobToken, énumère les transactions dans DeclareMiningJob et répond au besoin à ProvideMissingTransactions. Puis il envoie SetCustomMiningJob au serveur de minage. Le mode Coinbase-only ne communique pas la liste des transactions à l’avance et n’utilise pas DeclareMiningJob ; il s’appuie sur l’identifiant attribué et les données de la coinbase, la transaction particulière qui porte la récompense du bloc. Le pool peut refuser une proposition : les connexions de secours comptent aussi. Choisir soi-même les transactions d’un bloc peut répartir les décisions entre davantage de mineurs, sans supprimer l’obligation du pool de verser les récompenses. [4]
L’exemple précédent se comprend sans connaître les noms des messages. Pour configurer ou développer un programme, leur format exact devient toutefois important. V2 transmet les données en binaire, selon une représentation convenue entre machines. L’en-tête d’un message fait 6 octets ; extension_type, msg_type et msg_length indiquent l’extension, le type de message et la longueur du contenu. Une fois la communication cryptographique établie, SetupConnection est le premier message du protocole : il négocie le protocole, la version et les fonctions requises. SetupConnection.Success confirme la réussite. L’étiquette V2 d’un service ne remplace pas cet accord réel entre programmes précis. [1]
Un canal est une session de minage distincte dans une connexion, pas une autre blockchain ni un canal de paiement. Un Standard Channel attribue un travail sur l’en-tête du bloc, un bref résumé de ses données. Un Extended Channel permet à un intermédiaire de répartir un espace d’essais plus large grâce à l’extranonce, une partie variable de la transaction coinbase. Un Group Channel facilite l’envoi commun de tâches à plusieurs canaux. OpenStandardMiningChannel et OpenExtendedMiningChannel ouvrent les sessions correspondantes. La raison pratique est simple : deux machines essayant des possibilités identiques consommeraient de l’électricité pour le même travail. [3]
Le pool doit mesurer régulièrement la contribution d’Eva. Une mining share est un résultat qui respecte le seuil de difficulté attribué. La plupart des shares n’atteignent pas le seuil plus exigeant du réseau pour un bloc, mais certaines le peuvent. NewMiningJob ou NewExtendedMiningJob fournit le travail, SetNewPrevHash active le lien au bloc précédent et SetTarget fixe le seuil du canal. SubmitSharesStandard ou SubmitSharesExtended transmet les résultats avec l’identifiant de tâche, un numéro de séquence et les données variables de l’en-tête. Un résultat accepté n’est pas encore un versement au portefeuille. La rémunération du pool et la validité du bloc selon Bitcoin restent deux questions distinctes. [3]
Elle vérifie d’abord la compatibilité de son matériel, de son logiciel et du pool choisi. Puis elle détermine quelle liaison est protégée, d’où vient la clé de vérification et si elle veut seulement un transfert plus sûr ou aussi choisir elle-même les transactions d’un bloc. Ce second objectif demande un Template Provider et un Job Declarator Client opérationnels, ainsi que le support correspondant du pool. Elle surveille les délais, les shares refusées ou périmées, les journaux d’erreurs et le comportement en cas de panne. Les instructions doivent correspondre à la version utilisée. Stratum V2 peut améliorer l’organisation du minage ; il ne remplace pas une gestion sûre du matériel et ne change pas les règles de vérification de Bitcoin par les nœuds complets. [6] [7]
Pour une vision complète, lisez aussi Bitcoin, Minage, Mining Pool, Braiins, Braiins Pool, ASIC Miner. Cette entrée est également citée par ASIC Miner, Mining Pool, Nonce, Marek « Slush » Palatinus.