Au sens précis, un Orphan Block est un bloc dont le prédécesseur immédiat est inconnu du nœud considéré. Plus largement, ce terme désigne parfois un Stale Block, hors de la chaîne active. Aucune de ces étiquettes ne suffit à conclure à une fraude ou à un bloc défectueux : il faut d’abord connaître les données du nœud et le sens employé.
Le bloc précédent est parfois appelé parent. Pour un véritable Orphan Block, le nœud de Jana ne le connaît pas et ne peut pas finir de vérifier le raccordement. Un Stale Block peut avoir un parent connu et être entièrement valide ; le nœud suit simplement une autre branche comme historique actif. Le Bitcoin Developer Guide distingue explicitement ces sens. Quand Jana lit orphan dans un explorateur, elle cherche donc d’abord à savoir si le prédécesseur manque ou si le bloc n’est simplement pas resté dans la chaîne principale. [1]
La différence apparaît aussi dans Bitcoin Core, un logiciel permettant de faire fonctionner un nœud qui vérifie les blocs et les transactions selon les règles de Bitcoin. Dans Bitcoin Core 29, AcceptBlockHeader recherche le prédécesseur avec hashPrevBlock, la référence à son empreinte d’identification. S’il manque dans l’index, la fonction renvoie prev-blk-not-found. Si le parent est connu et marqué invalide, elle renvoie bad-prevblk. Le premier cas signifie « il me manque le contexte », le second « tu t’appuies sur un bloc invalide ». Fournir le prédécesseur manquant permet d’autres vérifications, sans garantir à lui seul l’acceptation du bloc entier. [2]
Un bloc comporte un en-tête, un court ensemble de données d’identification et de liaison, et un corps contenant les transactions. Bitcoin Core 0.10.0 a introduit la synchronisation headers-first : les en-têtes sont récupérés et vérifiés d’abord, puis les blocs peuvent être téléchargés en parallèle. Le nœud de Jana peut donc connaître l’en-tête du prédécesseur sans posséder tout son bloc sur disque. Un corps de bloc manquant n’est pas un prédécesseur inconnu ; confondre les deux ferait paraître mystérieux un téléchargement ordinaire. [3]
La commande getchaintips de Bitcoin Core 29 permet à Jana de voir quelles extrémités de branches son nœud connaît. active désigne la chaîne active ; valid-fork, une branche inactive entièrement validée. valid-headers signifie que les blocs sont disponibles, mais n’ont pas été complètement validés ; headers-only indique que certains blocs manquent. invalid désigne une branche contenant un bloc invalide. Ce n’est donc pas une liste de problèmes tous identiques. Même l’expression orphaned branches dans l’aide n’efface pas ces différences. [4]
Imaginons deux blocs différents, A et B, à la hauteur 900000. C’est notre propre exemple, pas le récit d’un événement particulier. La hauteur est une position dans la chaîne que des blocs concurrents peuvent partager. Jana les distingue grâce à hash, l’empreinte d’identification du bloc, et à previousblockhash, la référence au précédent. Le choix entre branches valides dépend du travail cumulé, pas seulement de la hauteur. L’interface RPC permettant de commander le logiciel le présente comme chainwork : le travail attendu cumulé correspondant aux difficultés des blocs. [1] [5]
Lorsque Jana interroge avec getblock un bloc hors de la chaîne principale, Bitcoin Core 29 peut indiquer confirmations = -1. C’est un marqueur d’état particulier, pas un nombre ordinaire de confirmations. Il ne s’agit ni d’un compte à rebours ni d’une profondeur négative de réorganisation. Cela ne prouve pas non plus que le prédécesseur manque. Jana doit lire ce chiffre avec l’identité du bloc et l’état de sa branche ; son nœud ne possède d’ailleurs pas forcément tous les blocs jamais vus par les autres participants. [5]
La récompense du bloc est créée par une première transaction spéciale appelée coinbase, sans rapport avec la plateforme d’échange du même nom. Une sortie de transaction enregistre un montant en bitcoins et les conditions à remplir pour le dépenser. Dans Bitcoin Core 29, COINBASE_MATURITY vaut 100 : une sortie créée à la hauteur H peut être dépensée pour la première fois dans un bloc valide à la hauteur H+100. C’est la différence de hauteur qui compte, pas les minutes écoulées. Cette attente ne remplace toutefois pas l’inclusion dans la chaîne active. Tant que le bloc de récompense reste sur une branche inactive, sa sortie est absente de l’ensemble UTXO actif, le registre des sorties non dépensées. Des blocs supplémentaires ailleurs ne rétablissent pas cet argent à eux seuls. [6] [7] [1] [8]
Jana conserve le hash du bloc, son prédécesseur, l’état de la branche et la version du logiciel. Elle ajoute les réponses de getchaintips et getblock ainsi que l’heure où elle les a obtenues. Celle-ci reste distincte du champ time de l’en-tête : l’horodatage du bloc n’est pas le moment où son ordinateur l’a observé. Le relevé aide à comparer d’autres observations, mais ne prouve à lui seul ni attaque, ni panne précise du réseau, ni taux mondial de blocs orphan. Il décrit d’abord l’état d’un nœud à un instant donné. [4] [5]
Pour une vision complète, lisez aussi Stale Block, Reorg, Block Propagation, Proof of Work, Bitcoin. Cette entrée est également citée par Stale Block.