Le parrain du consensus : guide du proof-of-work

Points essentiels

Cet article retrace les origines et l’évolution du proof-of-work (PoW), expliquant comment il a d’abord servi à limiter les abus de ressources avant de devenir la base de la blockchain décentralisée de Bitcoin. Il détaille comment le PoW sécurise les transactions et empêche la double dépense grâce à des énigmes informatiques résolues par les mineurs, tout en mettant en lumière les défis de scalabilité et de consommation d’énergie. Pour répondre à ces limites, l’article évoque le développement de nouvelles couches blockchain et de mécanismes de consensus visant à améliorer l’efficacité tout en préservant sécurité et décentralisation.

Aujourd’hui, les réseaux décentralisés reposent sur de nombreux mécanismes de consensus, mais tout a commencé avec le proof-of-work (PoW). Nous allons vous raconter comment ce mécanisme est né, comment il fonctionne, et pourquoi il demeure l’un des algorithmes clés du Web3.

À l’origine, le proof-of-work n’a pas été conçu pour les réseaux décentralisés. Il n’avait aucun lien avec les cryptomonnaies et visait à protéger les utilisateurs de « ressources partagées » contre divers abus. Les créateurs du concept, proposé dès 1993, ont imaginé une solution limitant l’accès à une ressource en imposant aux participants la réalisation de calculs complexes. Il était également prévu que les résultats de ces calculs soient faciles et rapides à vérifier.

La première version exploitable dans la pratique n’a vu le jour que cinq ans plus tard, lorsque Adam Back a créé le projet Hashcash, dont l’objectif principal était de lutter contre le spam. L’idée était d’utiliser la cryptographie pour rendre l’envoi massif d’e-mails plus difficile. Avant chaque envoi, l’expéditeur devait effectuer des calculs complexes : trouver une valeur x telle que le hash SHA(x) contienne N zéros initiaux, puis inclure ce résultat (le proof-of-work) dans l’en-tête du message.

Pour que le courrier parvienne au destinataire, il fallait vérifier que l’expéditeur avait bien résolu le problème cryptographique. Cette vérification pouvait se faire très rapidement grâce à un calcul SHA-1 unique à partir d’un label préparé à l’avance. Ce label était généré par l’expéditeur avant de commencer à résoudre le problème et devenait accessible à tous les participants du système. Ainsi, envoyer quelques messages ne posait pas de difficulté, mais lancer une campagne massive exigeait une puissance de calcul importante.

Cela vous semble familier ? Ce principe a été repris en 2008 par Satoshi Nakamoto pour créer Bitcoin et sa blockchain proof-of-work.

Comment fonctionnent les blockchains PoW

Au cœur de l’idée de Nakamoto (on ignore s’il s’agit d’une personne ou d’un groupe) se trouvait la volonté de créer un système de paiement électronique décentralisé, indépendant des tiers. Il devait permettre d’envoyer de l’argent directement, sans passer par des intermédiaires comme les banques.

Les informations sur les transactions sont stockées dans un registre distribué entre les participants du système. Le processus de séquençage consiste à regrouper les transactions dans des blocs de taille limitée. Chaque bloc doit contenir des informations sur le bloc précédent. Pour cela, toutes les données pertinentes (transactions, hash du bloc précédent, horodatage, etc.) sont transformées en un code unique appelé hash. Cette opération s’effectue via une fonction de hachage, qui dans le cas de Bitcoin s’appelle SHA-256. Les « full nodes » gèrent la chaîne, tandis que les nœuds mineurs participent à la création de nouveaux blocs.

Il est important de noter que la fonction de hachage fonctionne de sorte qu’un même ensemble de données produira toujours le même hash. Même une modification minime génère un hash totalement différent.

Comme évoqué plus haut, les mineurs doivent calculer le hash d’un bloc pour l’ajouter à la chaîne. Ce calcul n’est pas très long en soi, donc pour éviter que le problème ne soit résolu trop rapidement, le réseau ajuste la difficulté toutes les 2 016 blocs, soit environ toutes les deux semaines. Cela permet de maintenir un temps de minage d’environ dix minutes par bloc, assurant la stabilité de la blockchain.

Comment cela se passe-t-il en pratique ? Les mineurs reçoivent des blocs en entrée et calculent leur hash. Cependant, le réseau exige que ce hash soit inférieur à une certaine valeur. Mais alors, le hash ne peut-il pas être modifié ? C’est ici qu’intervient le nonce (« number only used once »). Il est ajouté aux blocs et modifié par les mineurs lors des calculs, ce qui produit un hash différent. Les mineurs comparent ensuite le hash obtenu à la cible de difficulté ; si la valeur est supérieure, ils modifient à nouveau le nonce et recalculent le hash. Ce processus se répète jusqu’à obtenir un résultat égal ou inférieur à la cible, ce qui peut nécessiter des millions de tentatives.

Pour mieux visualiser l’ampleur de la tâche, voici le nombre de combinaisons possibles d’un hash SHA-256 :

115792089237316195423570985008687907853269984665640564039457584007913129639936

Cela équivaut au nombre d’étoiles dans l’univers, multiplié par 115 milliards.

La chaîne des transactions

Voyons à présent comment cela fonctionne lors d’une transaction classique. Supposons que vous envoyiez des fonds en BTC. Après avoir généré et signé la transaction avec votre clé privée, elle est transmise au réseau. Le full node vérifie sa validité et, en l’absence de problème, la laisse circuler sur le réseau. Les autres nœuds effectuent également des vérifications et placent la transaction dans la file d’attente des transactions non confirmées (mempool).

Les mineurs sélectionnent les transactions du mempool (en privilégiant celles offrant la plus grosse commission), les regroupent dans un bloc et commencent les calculs. Lorsqu’un mineur trouve la solution, les full nodes vérifient le résultat et, s’il est correct, le mineur reçoit une récompense. À ce stade, le bloc est considéré comme « miné » et ajouté à la blockchain, puis l’information est diffusée à tous les participants du réseau. Ensuite, les mineurs s’attaquent au bloc suivant. Plus il y a de blocs ajoutés après celui contenant votre transaction, plus son niveau de confirmation est élevé.

Pour faire simple, une transaction n’est considérée comme valide que si la majorité des nœuds du réseau s’accorde à dire que le bloc qui la contient a été calculé correctement.

Tout cela est-il indispensable ?

Nakamoto n’est pas le premier à avoir voulu créer un système décentralisé, mais il est le premier à avoir choisi le consensus proof-of-work. Sans lui, il serait impossible de résoudre le problème de la double dépense, qui survient lorsqu’un expéditeur utilise deux fois les mêmes fonds avant que le système ne valide la transaction. Les mineurs vérifient chaque transaction pour détecter une éventuelle double dépense dès qu’ils la reçoivent du mempool.

Il arrive que, sur une blockchain PoW, deux mineurs minent le même bloc. Ce n’est pas forcément malveillant : cela peut se produire si deux mineurs terminent leur calcul presque simultanément et que l’un d’eux ne reçoit pas à temps l’information que le bloc a déjà été miné. Dans ce cas, une chaîne parallèle apparaît à partir du bloc erroné. Pour éliminer la mauvaise « branche », le mécanisme de consensus compare les deux chaînes et privilégie la version la plus longue.

Problèmes et limites

Le principal problème du PoW – du moins dans sa forme pure – est la scalabilité. Par exemple, la blockchain Bitcoin traite environ 7 transactions par seconde, ce qui est faible. Ainsi, lors des pics d’activité, le mempool se remplit et les transactions avec des frais faibles peuvent rester bloquées plusieurs heures, voire plusieurs jours. À première vue, on pourrait penser qu’il suffirait d’augmenter la taille des blocs pour y inclure plus de transactions, ou simplement de les miner plus rapidement.

Mais augmenter la taille des blocs n’est pas sans conséquence : il faudrait alors une puissance de calcul considérable pour les créer, ce qui réserverait le réseau aux gros mineurs ou pools de minage, réduisant la décentralisation.

Si l’on réduit le temps de traitement, il existe un risque que les nœuds du réseau n’aient pas le temps de parvenir à un consensus avant l’apparition du bloc suivant. Cela multiplierait les « branches » de la blockchain et rendrait possible la double dépense.

Tout cela illustre le trilemme de la blockchain : un réseau décentralisé ne peut garantir que deux de ses trois piliers à la fois : décentralisation, sécurité et scalabilité. Pour y remédier dans le cadre du PoW, on utilise des couches blockchain, qui fonctionnent « au-dessus » du système principal et accélèrent le traitement des transactions.

De nouveaux protocoles de consensus sont également développés pour fonctionner en parallèle du PoW. Par exemple, Kaspa utilise le PoW comme mécanisme de sécurité du réseau, mais les blocs sont regroupés dans un graphe acyclique orienté (DAG) plutôt que dans une blockchain, permettant aux mineurs de travailler sur plusieurs blocs en parallèle.

Enfin, il existe une question plus terre-à-terre : plus une blockchain accumule de puissance de calcul, plus la complexité des calculs et la consommation d’énergie pour le minage augmentent.