Modèles de blocs et Stratum V2

Curiosité

1. Pourquoi un mineur disposant d’un matériel dédié compte-t-il encore sur un opérateur de pool pour décider quelles transactions entrent dans un bloc ?
2. Qu’est-ce qui permet à un mineur en pool de choisir les transactions de ses propres blocs tout en partageant les récompenses du pool ?
3. Comment le passage de JSON à des protocoles binaires améliore-t-il à la fois la sécurité et l’efficacité du minage à haut débit ?

Explorer

1. Depuis la création du protocole, chaque bloc valide nécessite une sélection de transactions. Au début, les mineurs qui faisaient tourner des nœuds complets choisissaient eux-mêmes ces transactions. En 2012, le matériel étant devenu spécialisé et coûteux, la plupart avaient rejoint des pools. Le protocole Stratum, introduit par Slush cette même année, a standardisé la manière dont les serveurs des pools distribuaient le travail à leurs membres. Les pools construisaient les blocs depuis 2010 ; Stratum a rendu ce fonctionnement bien plus efficace et en a hérité la centralisation de la construction des blocs.
2. Avec Stratum V1, l’opérateur du pool est l’unique architecte de chaque bloc candidat. Le serveur agrège les transactions de son propre mempool et envoie aux mineurs les éléments d’une tâche (job) : les deux moitiés de la transaction coinbase, la branche de Merkle, le hash du bloc précédent, la cible et l’horodatage. Le mineur insère son propre extra-nonce, calcule la racine de Merkle et cherche un hash valide, mais n’a pas son mot à dire sur les transactions incluses.
3. Cette architecture confère aux opérateurs de pools un pouvoir considérable sur la sélection des transactions. Un pool contrôlant une part importante du hashrate du réseau peut de fait censurer des transactions en les excluant simplement de ses modèles. Bien que ce pouvoir soit rarement exercé, la capacité structurelle existe. Cela signifie aussi que si le serveur d’un pool tombe en panne ou subit une attaque par déni de service, tous les mineurs qui y sont connectés se retrouvent à l’arrêt, ce qui crée un point de défaillance unique pour leurs revenus.
4. En 2012, BIP22 et BIP23 ont introduit `getblocktemplate`, qui permettait à un logiciel de minage de demander un modèle de bloc complet à un nœud et avait été conçu pour que les membres des pools puissent construire leurs propres blocs. Les pools utilisent getblocktemplate en interne pour obtenir des modèles de leurs propres nœuds, mais laisser les membres construire leurs propres blocs compliquait la validation et la comptabilisation des parts, et rares sont les pools qui l’ont proposé (Eligius faisait exception).
5. Stratum V2, développé à partir de 2019 notamment par Braiins et Matt Corallo, a repensé le protocole pour résoudre ces problèmes. Il introduit un format binaire, plus léger, et le chiffrement pour la sécurité. Surtout, il inclut le Job Declaration Protocol, qui permet à un mineur faisant tourner son propre nœud complet de déclarer son propre modèle de bloc au serveur du pool. Le pool accepte alors les parts issues de cette tâche personnalisée et répartit les récompenses selon son mode de rémunération habituel, tandis que le mineur garde le contrôle des transactions incluses.
6. D’autres initiatives, comme le protocole DATUM d’Ocean (2024), poursuivent des objectifs similaires de décentralisation de la construction des modèles de blocs. Lisez la section Job Declaration de la spécification Stratum V2 et comparez-la à la manière dont un pool que vous connaissez construit ses modèles. Là où ces protocoles sont adoptés, le choix des transactions revient vers les propriétaires du matériel.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

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