Un Stale Block respecte les règles de Bitcoin, mais ne fait pas partie de la chaîne active : l’historique qu’un nœud, un ordinateur qui vérifie les blocs et les transactions, utilise pour compter les confirmations et déterminer quels fonds peuvent être dépensés. Le choix dépend du travail de minage accumulé par les branches valides. Pour le destinataire d’un paiement, cela peut signifier perdre une confirmation et devoir patienter, pas perdre automatiquement ses bitcoins.
Imaginons deux mineurs, Anna et Pavel. Tous deux cherchent à prolonger le même dernier bloc. Anna trouve un nouveau bloc, mais avant que Pavel en soit informé, il trouve le sien. Les deux peuvent être valides, avec des sélections de transactions légèrement différentes. Les nœuds qui vérifient les blocs et les transactions les découvrent dans un ordre différent. Pendant un moment, ils suivent donc des extrémités différentes de la chaîne. Dès qu’une branche valide accumule davantage de travail et que les nœuds l’ont vérifiée, ils la suivent. Le bloc resté sur la branche abandonnée est un Stale Block. [1]
Bitcoin a besoin d’un historique commun pour empêcher que les mêmes fonds soient dépensés deux fois avec succès. Vérifier que chaque bloc respecte les règles ne suffit donc pas. Le nœud doit aussi choisir quelle branche valide suivre. La validité d’un bloc et la sélection de la chaîne sont deux questions distinctes. Un Stale Block peut présenter une preuve de travail correcte (Proof of Work), des transactions et des signatures valides, tout en restant hors de l’historique retenu. Cela ne le rend ni défectueux ni frauduleux. [1] [2]
Supposons que le bloc de Pavel contienne votre paiement et que votre portefeuille affiche une confirmation. Si la branche d’Anna l’emporte, la suite dépend de son contenu. La même transaction peut s’y trouver aussi et rester confirmée. Sinon, elle peut retourner dans le Mempool, la liste locale des transactions non confirmées d’un nœud, puis attendre un autre bloc. Ce retour n’est pas garanti : elle doit rester admissible et ne pas contredire le nouvel historique. Si celui-ci contient déjà une autre transaction dépensant les mêmes fonds, le paiement initial ne peut pas y être confirmé en même temps. [2]
Un paiement ordinaire se distingue de la Coinbase Transaction, la première transaction du bloc, qui attribue sa récompense au mineur. Celle-ci comprend les bitcoins nouvellement émis et les frais des transactions. Si le bloc de Pavel reste hors de la chaîne active, sa récompense coinbase ne peut pas être dépensée dans cet historique. Elle ne rejoint pas le Mempool comme un paiement ordinaire. Pavel ne récupère pourtant pas l’électricité consommée. Les mineurs cherchent donc non seulement à trouver un bloc, mais aussi à le faire connaître rapidement aux autres. [1] [2]
Certains articles et explorateurs emploient Orphan Block pour désigner un Stale Block. Les termes sont souvent utilisés comme synonymes, mais leur sens précis mérite d’être distingué. Un Orphan Block est un bloc dont le nœud ne connaît pas encore le prédécesseur et qu’il ne peut donc pas encore rattacher. Un Stale Block peut avoir un prédécesseur connu et être valide ; il se trouve simplement hors de la branche choisie. Le mot orphan s’applique aussi aux transactions lorsque le nœud ne dispose pas de transactions antérieures nécessaires pour vérifier leurs entrées. Il faut donc regarder le sens retenu par la source. [1]
Si un nœud utilisait déjà le bloc de Pavel puis le remplace par la branche d’Anna, il effectue un Reorg : il change une partie de l’historique qu’il considère comme actif. Le nombre de confirmations affiché par le portefeuille peut alors changer. Une courte course comme dans notre exemple peut survenir entre mineurs honnêtes. Un attaquant peut toutefois essayer d’exploiter un changement d’historique pour un Double Spend : faire passer un autre paiement utilisant les mêmes fonds. Un Stale Block ne démontre pas à lui seul cette intention. Il faut examiner le déroulement des faits et les éventuelles transactions concurrentes. [1] [2]
La nouvelle d’un bloc ne fait pas instantanément le tour du monde. Plus elle met de temps à circuler, plus d’autres mineurs peuvent continuer à travailler sur le même prédécesseur sans le savoir. La vitesse de transmission, les connexions entre nœuds et le délai de propagation par rapport à l’intervalle entre blocs comptent. Stale Rate désigne la part des blocs valides découverts qui ne restent pas dans la chaîne active. Ce n’est pas un pourcentage fixé par Bitcoin. Une comparaison dépend aussi de la période observée et des blocs effectivement repérés par l’observateur. [1] [3]
La spécification BIP152 décrit Compact Block Relay. Un nœud connaît souvent déjà, grâce à son Mempool, la plupart des transactions du nouveau bloc. Inutile de renvoyer tout leur contenu : des identifiants courts permettent de reconstituer le bloc à partir des données disponibles, puis de demander les transactions manquantes. Cela économise de la bande passante et peut, dans de bonnes conditions, faire connaître les nouveaux blocs plus vite. C’est une amélioration de la transmission, sans modification des règles de validité. Elle ne peut pas empêcher complètement deux découvertes presque simultanées. [3]
Le travail accumulé par une branche s’appelle techniquement chainwork. Il ne mesure pas l’électricité réellement consommée et ne compte pas des votes d’ordinateurs. Chaque bloc ajoute une valeur calculée à partir de la difficulté de son Proof of Work, la preuve du travail de minage. Dire « la chaîne la plus longue gagne » est donc moins précis que « la branche valide avec le plus de chainwork gagne ». Le nœud doit vérifier les règles : même beaucoup de travail ne rend pas valides des transactions invalides. Le qualificatif stale dépend aussi de l’historique choisi à cet instant par un nœud donné. [1] [2]
Un explorateur de blocs donne un aperçu utile, mais présente la vision de son service. Votre propre Full Node, un nœud qui vérifie les règles, permet de consulter l’historique que vous avez accepté indépendamment. Si le nœud possède les données du bloc, getblock de Bitcoin Core renvoie confirmations: -1 lorsque ce bloc est hors de la chaîne active. Si les données manquent, par exemple parce que le mode pruning les a supprimées pour libérer de l’espace, la commande renvoie une erreur. Cette valeur ne prouve pas à elle seule qu’il a passé toutes les vérifications de validité. Pour le situer, examinez aussi son hash — son identifiant —, le bloc précédent, sa hauteur (le nombre de blocs qui le précèdent) et son chainwork ; vérifiez séparément le sort de chaque paiement. Deux blocs peuvent avoir la même hauteur et des hash différents. [4] [5]
Pour une vision complète, lisez aussi Reorg, Confirmation, Block, Block Header, Proof of Work, Minage. Cette entrée est également citée par Reorg, Mining Pool, Hashrate, Selfish Mining.