Slush Pool : l'idée praguoise contre la loterie des mineurs

À l'époque, Bitcoin récompensait le vainqueur d'un bloc avec cinquante pièces. C'était un mécanisme simple pour le réseau, mais une loterie difficile pour les individus. La probabilité de trouver un bloc correspondait à la part de leur puissance de calcul dans l'ensemble du réseau. À mesure que la puissance totale augmentait, un petit mineur pouvait attendre de plus en plus longtemps, même si sa machine fonctionnait sans interruption.

La moyenne à long terme pouvait paraître favorable, mais les factures d'électricité arrivaient chaque mois. Un individu devait supporter une grande variabilité : il recevait soit la récompense intégrale, soit rien pendant une longue période. Cela éliminait les personnes ayant une puissance plus faible, même si leur travail était aussi utile pour le réseau que celui d'une grande exploitation.

Palatinus connaissait le problème pour l'avoir vécu. Sur le forum, il a décrit comment un serveur commun pouvait combiner des milliers de petites tentatives et répartir les résultats. Un participant n'attendrait plus son propre succès rare ; il recevrait une petite part chaque fois que le bloc était trouvé par quelqu'un du groupe.

Le pool de mine ne change pas la probabilité du groupe dans son ensemble, ni ne crée plus de bitcoins. Il modifie la répartition des risques dans le temps. C'est la différence entre un seul billet avec une grande récompense et une part régulière d'un grand lot de billets. Pour un revenu plus stable, le mineur paie une commission et dépend de la comptabilité correcte de l'opérateur.

Slush n'a pas présenté son projet comme une victoire purement technique. Dès le premier fil, il a énuméré les avantages, les inconvénients et la confiance nécessaire. Le serveur devait mesurer correctement le travail effectué, ne pas voler les récompenses et rester accessible. Le pool éliminait une incertitude, mais ajoutait un intermédiaire que le consensus bitcoin lui-même ne contrôlait pas.

Pour un petit mineur, le plus grand problème n'était pas le rendement moyen, mais le temps. Statistiquement, il pouvait prétendre à une fraction de la récompense chaque jour, mais le protocole réel ne versait pas de fractions pour l'effort fourni. Soit sa machine trouvait un bloc valide et remportait les cinquante bitcoins entiers, soit elle ne gagnait rien. Une longue série d'échecs ne signifiait pas pour autant que l'appareil ne fonctionnait pas ; cela signifiait simplement que la loterie n'avait pas encore tourné en sa faveur. Le serveur commun convertissait cet événement irrégulier en parts plus petites selon le travail attesté. Le pool n'augmentait pas le nombre attendu de blocs trouvés, mais il modifiait le rythme des revenus, et c'est précisément cette différence qui pouvait déterminer si une personne pouvait se permettre de continuer à miner.

L'annonce du 27 novembre 2010 n'était pas un produit d'entreprise finalisé. Palatinus cherchait des personnes prêtes à tester le protocole, la connexion et le mode de rémunération. Le système devait accepter des preuves partielles de travail — des résultats trop faibles pour un bloc valide, mais suffisants pour prouver que le mineur effectuait réellement des calculs.

Ces résultats partiels, appelés shares, permettaient au pool d’estimer la contribution de chaque machine. Lorsqu’un participant trouvait un hachage satisfaisant la difficulté de l’ensemble du réseau, le pool recevait la récompense du bloc et la répartissait selon la règle comptable retenue. Pour un mineur ordinaire, cela remplaçait l’arrivée irrégulière de cinquante bitcoins par une succession de paiements plus modestes.

La première version du service fonctionnait sous le nom de Bitcoin.cz Mining Pool. Le site web, le serveur et le support étaient en grande partie l'œuvre d'une seule personne. Cela donne au prémier tchèque une dimension plus précise : il ne s'agissait pas d'un projet national ou d'un programme d'État, mais d'un programmeur qui, depuis Prague, résolvait un problème économique concret du réseau global.

Le pool devait également constituer un bloc candidat et envoyer aux mineurs la tâche à effectuer. Les machines individuelles fournissaient la puissance, mais l'opérateur déterminait sur quelle en-tête elles travaillaient et quelles transactions le modèle contenait. La répartition du matériel entre de nombreuses personnes ne garantissait pas nécessairement la répartition de la prise de décision.

Le développement ultérieur des protocoles de minage, y compris Stratum V1, a cherché à optimiser la communication entre les pools et les appareils. L'échange de base est resté le même : le pool vend une rémunération plus prévisible et le mineur lui confie une partie de la coordination. Le premier serveur a créé un modèle que les autres ont rapidement suivi.

L'exploitation à plein régime a commencé le 16 décembre 2010. Ce jour-là, le pool a extrait le bloc 97 834. L'enregistrement de la chaîne montre aujourd'hui le résultat, mais pas la tension qui a précédé : le serveur allait-il correctement accepter le travail, reconnaître un bloc valide et attribuer des parts aux personnes qui lui avaient fourni de la puissance ?

Le premier bloc a confirmé que la coordination fonctionnait, non seulement dans les tests. La récompense pouvait être répartie entre les participants, dont la plupart n'auraient rien gagné seuls à ce moment-là. Pour les petits mineurs, c'était une preuve tangible que leurs machines plus faibles n'étaient pas immédiatement éliminées de l'économie du réseau.

La date est importante à distinguer de l'annonce de novembre. L'idée, les tests publics et le résultat à plein régime étaient trois étapes distinctes. L'histoire ne commence pas par la découverte soudaine d'un bloc, mais par les semaines qui ont précédé, lorsque Slush a décrit ouvertement son projet et a demandé à la communauté de l'aider à trouver des erreurs.

Le succès a attiré plus de puissance et, avec elle, la responsabilité. Plus le pool regroupait une grande partie du réseau, plus chaque défaillance ou mauvaise décision était sensible. Le service devait protéger les comptes, calculer les récompenses et réagir aux attaques. Ce n'était plus seulement un script pour égaliser la chance ; c'était une infrastructure dont la comptabilité était cruciale pour les gens qui y faisaient confiance.

Le bloc 97 834 n'est donc pas important pour sa valeur. D'autres mineurs gagnaient les mêmes cinquante bitcoins. Ce qui était exceptionnel, c'était la façon dont ils l'ont obtenu et comment ils l'ont réparti. Une seule ligne de la blockchain représentait le travail commun de nombreuses machines et la première preuve pratique que le regroupement pouvait fonctionner sur un réseau public.

Le projet a plus tard changé de nom pour devenir Slush Pool et Braiins Pool. L'équipe Braiins a professionnalisé le service, tandis que Marek Palatinus consacrait plus d'énergie à SatoshiLabs et à la wallet matérielle Trezor. Du serveur original, cependant, est restée une ligne historique ininterrompue menant à l'un des noms les plus anciens de la mine bitcoin.

Le regroupement a élargi la possibilité de miner, mais a également concentré la création de modèles de blocs dans un nombre plus restreint de services. Un mineur solo décide lui-même quel bloc il construit. Un participant à un pool ordinaire ne fait souvent que calculer la tâche qu'il a reçue. La puissance physique peut être dispersée, tandis que la décision de coordination reste centralisée.

Cette concentration ne signifie pas que le pool possède tous les appareils connectés. Les mineurs peuvent rediriger leur puissance ailleurs s'ils ne sont pas d'accord avec les frais, la censure ou le comportement de l'opérateur. Cependant, le changement nécessite des informations et la volonté de réagir. La décentralisation se mesure donc non seulement par le nombre d'appareils, mais aussi par qui construit les blocs et à quel point il est facile de changer de coordinateur.

Le premier texte de Slush n'a pas caché ce compromis. Il a offert une solution au problème économique et a nommé la confiance que la solution exigeait. C'est justement cette ouverture qui aide à lire l'histoire sans le triomphalisme ultérieur : le pool n'était pas la réponse finale, mais un nouvel outil avec des coûts clairs.

Le projet praguois a changé la mine en séparant le travail de la chance. Un individu n'avait plus besoin de gagner tout un bloc pour que son taux de hachage obtienne un prix en cours. En même temps, il a montré que même un système conçu sans banque centrale créera des services auxquels les gens confieront la coordination. La question n'est pas de savoir s'ils émergeront, mais si les participants seront capables de les contrôler, de les quitter et de les remplacer.

La concentration des pools ne peut donc pas se mesurer uniquement au nombre de machines connectées. Ce qui compte, c'est qui assemble le modèle de bloc, sélectionne les transactions, fixe les règles de paiement et parvient à convaincre les participants de changer de logiciel en cas de problème. Un mineur ne peut quitter un pool que s'il dispose d'une autre option utilisable et qu'il suit réellement ce que fait le service. La description originelle de la confiance par Slush reste pertinente à cet égard. Le pooling a résolu un problème économique réel et a simultanément créé un nouveau domaine dans lequel la concurrence, la transparence et la possibilité de se retirer sont nécessaires. La décentralisation ne se maintient pas en interdisant la coordination, mais en ne laissant pas celle-ci se figer en un pouvoir incontrôlable.