Beaucoup de personnes ont l’image intuitive d’un bloc de blockchain comme d’« un conteneur qui renferme de nombreuses transactions ». Cette compréhension n’est pas fausse, mais elle est incomplète. Si l’on ne voit un bloc que comme une liste de transactions, il devient difficile d’expliquer pourquoi la blockchain résiste à la falsification, pourquoi les nœuds peuvent vérifier rapidement la cohérence des données, et pourquoi les blocs des différentes chaînes semblent si différents.

Cet article répond à une question très concrète : de quelles parties un bloc est-il composé, quelle fonction chacune remplit-elle, et pourquoi « un bloc n’est pas seulement une liste de transactions ».

Décomposer un bloc : en-tête de bloc et liste de transactions

Pour comprendre la structure interne d’un bloc, on peut commencer par une analogie du quotidien : imaginons la blockchain comme un grand livre, et chaque bloc comme une page de ce grand livre. En haut de la page se trouvent des informations d’en-tête, comme la date, le numéro de la page précédente et un résumé du contenu de la page ; c’est seulement en dessous que figurent les écritures proprement dites.

Un bloc réel présente une structure à deux niveaux similaire :

• En-tête de bloc (block header) : il stocke des métadonnées et assure la liaison, la vérification et le consensus.
• Liste de transactions (transaction list) : elle stocke les opérations utilisateur ou les demandes de changement d’état que le bloc enregistre réellement.

Ici, les « métadonnées » ne sont pas les transactions elles-mêmes, mais des informations sur le bloc. Elles répondent aux questions suivantes : quelle page précède celle-ci ? À quoi ressemblent les transactions de cette page dans leur ensemble ? Quand cette page a-t-elle été assemblée ? Respecte-t-elle les règles de consensus du réseau ?

Cette structure « métadonnées + contenu » est la clé pour comprendre l’intérieur d’un bloc. L’en-tête de bloc joue le rôle d’une carte d’identité et d’un connecteur ; la liste de transactions constitue le corps du grand livre.

Il faut préciser que cette analogie a des limites évidentes. Un grand livre ne verrouille pas automatiquement ses pages les unes aux autres par la cryptographie, alors que les liens de hachage d’une blockchain sont des liaisons fortes au niveau cryptographique, qui ne reposent pas sur une vérification manuelle. L’analogie aide à se représenter la structure à deux niveaux, mais elle ne remplace pas l’explication des mécanismes qui suit.

L’en-tête de bloc : carte d’identité et connecteur de la page

Un en-tête de bloc contient généralement plusieurs champs clés. Ci-dessous, nous prenons la structure de l’en-tête de bloc de Bitcoin comme exemple pour en donner une vue simplifiée. Ce n’est pas un modèle universel pour toutes les blockchains, mais cela permet de voir à quoi sert chaque champ de l’en-tête.

Un en-tête de bloc Bitcoin simplifié contient généralement :

• numéro de version
• hash du bloc précédent (previous block hash)
• racine de Merkle (Merkle root)
• horodatage (timestamp)
• cible de difficulté (difficulty target)
• nonce

Ces champs semblent dispersés, mais on peut les comprendre en les regroupant selon trois fonctions : liaison, vérification et consensus.

Hash parent : pointer le bloc actuel vers le bloc précédent

Le hash du bloc précédent enregistre la valeur de hachage du bloc précédent. Une fonction de hachage peut transformer des données arbitraires en une empreinte de longueur fixe ; les mêmes données produisent la même empreinte, et si les données changent, l’empreinte change.

Le rôle du hash du bloc précédent est de permettre au bloc actuel de « se souvenir » de l’empreinte du bloc précédent. Ainsi, chaque bloc pointe vers celui qui le précède, formant une chaîne de l’arrière vers l’avant. Si le contenu du bloc précédent est modifié, son hash change, et le hash du bloc précédent enregistré dans le bloc actuel ne correspond plus. Cette référence en chaîne est l’un des fondements de la résistance à la falsification de la blockchain.

Racine de Merkle : compresser un ensemble de transactions en une empreinte

L’en-tête de bloc ne liste pas directement toutes les transactions ; il contient à la place une racine de Merkle. La racine de Merkle est un hash racine unique obtenu en hachant la liste de transactions couche par couche selon une structure spécifique.

Son rôle essentiel est de représenter l’ensemble des transactions par une petite empreinte. Si une seule transaction de la liste change, la racine de Merkle change également. L’en-tête de bloc peut ainsi lier l’intégrité de la liste de transactions sans avoir à stocker à nouveau chaque transaction dans l’en-tête.

Il n’est pas nécessaire d’entrer ici dans la construction complète d’un arbre de Merkle ni dans la génération des preuves. Pour comprendre la structure interne d’un bloc, il suffit de savoir que la racine de Merkle est le « représentant condensé » de la liste de transactions dans l’en-tête de bloc.

Horodatage, difficulté et nonce : au service du consensus

L’horodatage enregistre le moment approximatif où le bloc a été assemblé, mais les différentes chaînes ont des règles de validation différentes concernant la précision temporelle et les plages acceptables. On ne peut pas considérer les règles d’une chaîne comme un standard universel.

Dans les chaînes à preuve de travail (PoW) comme Bitcoin, l’en-tête de bloc contient aussi une cible de difficulté et un nonce. Les mineurs doivent trouver un nonce tel que le hash de l’en-tête de bloc satisfasse la cible de difficulté actuelle. Le nonce est essentiellement une variable que les mineurs peuvent essayer de manière répétée, tandis que la cible de difficulté définit « à quel point il faut que ce soit difficile pour être valide ». Ces deux champs servent à la preuve de minage et à la validation du consensus, et non à l’enregistrement des transactions des utilisateurs.

Il faut souligner que le nonce et la cible de difficulté sont des choix liés à un mécanisme de consensus particulier. Les chaînes qui utilisent d’autres mécanismes de consensus peuvent avoir des champs totalement différents. Par exemple, après son passage à la preuve d’enjeu (PoS), Ethereum a modifié la structure de ses blocs : elle ne dépend plus du minage traditionnel par nonce comme Bitcoin, et son en-tête de bloc contient aussi une racine d’état, une racine de transactions, une racine de reçus et des champs liés au gas. Les champs précis d’Ethereum évoluent avec les versions du protocole ; pour en savoir plus, il faut consulter sa documentation protocolaire.

Ici, nous ne mentionnons la racine d’état qu’à titre de contexte : certaines chaînes doivent inscrire dans l’en-tête de bloc un résumé de l’état de la chaîne afin de vérifier la cohérence de cet état. La construction précise de l’arbre d’état sort du cadre de cet article.

La liste de transactions : l’ensemble d’événements réellement enregistrés par un bloc

La liste de transactions constitue la partie « contenu » du bloc. Les transactions représentent des opérations initiées par les utilisateurs, comme des transferts, des appels de contrats intelligents ou, plus généralement, des demandes de modification de l’état de la chaîne.

Un bloc regroupe généralement plusieurs transactions, plutôt que de consacrer un bloc à chaque transaction. L’avantage est l’efficacité du débit : regrouper plusieurs opérations sur une seule page est plus économique que de créer une page séparée pour chaque opération. Les différentes chaînes peuvent définir différemment le contenu des transactions, leur ordre et leur mode d’exécution, mais « un bloc contient un ensemble de transactions » est une pratique courante sur la plupart des chaînes.

La liste de transactions et l’en-tête de bloc sont liés par la racine de Merkle. Imaginons un scénario simplifié : un bloc regroupe trois transactions, Tx1, Tx2 et Tx3. Après hachage couche par couche, elles produisent une racine de Merkle, notée R. Cette valeur R est inscrite dans l’en-tête de bloc. Si l’une de ces transactions est modifiée, la racine recalculée devient R’, qui ne correspond plus à R enregistrée dans l’en-tête de bloc.

Cela explique pourquoi l’en-tête de bloc, bien qu’il ne contienne pas les transactions, aide le réseau à vérifier que la liste de transactions n’a pas été falsifiée.

Comment le hash de bloc relie les transactions et la chaîne

Nous pouvons maintenant répondre à une question clé : pourquoi la modification d’une transaction dans un bloc pose-t-elle problème à la chaîne qui suit ?

Il faut pour cela comprendre la relation entre trois éléments : le hash de bloc, la racine de Merkle et le hash parent.

Le hash de bloc est le hash de l’en-tête de bloc

Sur des chaînes comme Bitcoin, le hash de bloc est généralement un identifiant obtenu en hachant l’en-tête de bloc, et non en hachant directement la liste de transactions. Ce détail est important, car il détermine la manière indirecte dont les transactions influencent le hash de bloc.

La liste de transactions est d’abord compressée en une empreinte via la racine de Merkle, qui est inscrite dans l’en-tête de bloc ; puis l’en-tête de bloc entier est haché pour produire le hash de bloc. Ainsi, une modification des transactions change d’abord la racine de Merkle, puis le hash de bloc. Le sens de causalité est : transactions → racine de Merkle → en-tête de bloc → hash de bloc.

Si l’on inverse ce sens de causalité, en pensant que « le hash de bloc est calculé directement à partir du contenu des transactions », on omet le rôle des autres champs de l’en-tête de bloc et l’on ne peut pas expliquer correctement la relation en chaîne du hash parent.

Le hash parent fait fonctionner la résistance en chaîne à la falsification

L’en-tête de chaque bloc enregistre le hash du bloc précédent. Supposons qu’un attaquant modifie une transaction dans le bloc 9. Cette modification entraîne un changement de la racine de Merkle de ce bloc, puis un changement du hash de bloc du bloc 9. Le hash parent enregistré dans l’en-tête du bloc 10 est le hash d’origine du bloc 9 ; il ne correspond désormais plus. Pour que le bloc 10 reste valide, l’attaquant doit modifier le hash parent du bloc 10, ce qui change le hash du bloc 10, puis affecte le bloc 11, et ainsi de suite.

C’est l’effet de la liaison en chaîne : plus la modification est ancienne, plus le nombre de blocs suivants à recalculer est élevé.

L’immuabilité est calculatoire, pas absolue

Il faut ici corriger une affirmation courante mais trop absolue : le contenu d’une blockchain serait « absolument immuable ».

Une formulation plus exacte est la suivante : une falsification rompra la correspondance des hashes parents et des racines de Merkle dans les blocs suivants, elle sera donc facilement détectée par les nœuds ; toutefois, dans certains mécanismes de consensus, si un attaquant dispose d’une puissance de calcul suffisante, une réorganisation de la chaîne peut encore se produire. L’immuabilité de la blockchain est donc plus précisément une difficulté calculatoire et probabiliste à falsifier, et non une impossibilité logique absolue de modification. Comprendre ce point permet d’avoir des attentes raisonnables quant aux limites de sécurité de la blockchain.

Différentes blockchains, différents contenus de blocs

Une erreur fréquente consiste à croire que toutes les blockchains ont la même structure de bloc. En réalité, les champs des blocs peuvent varier considérablement d’une chaîne à l’autre.

Bitcoin et Ethereum, par exemple, ont des champs d’en-tête de bloc différents. L’en-tête de bloc de Bitcoin est relativement concis : il contient notamment le numéro de version, le hash du bloc précédent, la racine de Merkle, l’horodatage, la cible de difficulté et le nonce. L’en-tête de bloc d’Ethereum contient un hash parent, une racine d’état, une racine de transactions, une racine de reçus, des champs liés au gas, un horodatage, etc. ; après la mise à jour du Merge, la structure des blocs a changé et ne dépend plus du nonce traditionnel de la PoW.

Même lorsque des chaînes partagent une notion similaire d’« en-tête de bloc + liste de transactions », elles peuvent définir différemment l’ordre des transactions, leur exécution et l’enregistrement de l’état. Certaines chaînes peuvent utiliser d’autres structures de données, mais la plupart conservent une division en deux niveaux similaire.

Pour connaître précisément la structure des blocs d’une chaîne donnée, il faut consulter la documentation protocolaire de cette chaîne, et non considérer la liste des champs d’une chaîne comme un modèle universel pour toutes les blockchains.

Récapitulatif rapide : un modèle mental complet d’un bloc

Nous pouvons maintenant résumer la structure interne d’un bloc en un modèle mémorisable :

• Bloc = en-tête de bloc + liste de transactions. Un bloc n’est pas une simple collection de transactions.
• L’en-tête de bloc est constitué de métadonnées ; il assure la liaison avec le bloc précédent, lie l’intégrité des transactions et participe à la validation du consensus.
• La liste de transactions est le contenu ; elle enregistre les opérations utilisateur ou les demandes de changement d’état, et un bloc regroupe généralement plusieurs transactions.
• La racine de Merkle relie la liste de transactions et l’en-tête de bloc ; toute modification d’une transaction change la racine de Merkle, puis indirectement le hash de bloc.
• Le hash parent relie le bloc actuel au bloc précédent ; il rend la falsification facile à exposer et forme une structure de résistance en chaîne à la falsification.
• Le hash de bloc est généralement le hash de l’en-tête de bloc ; les transactions influencent indirectement le hash de bloc via la racine de Merkle.
• Les champs précis varient selon la chaîne, en particulier entre les chaînes PoW et PoS ; on ne peut pas considérer la conception d’une chaîne comme la structure universelle de toutes les blockchains.

Si l’on ne retient qu’une phrase : l’en-tête de bloc assure la « liaison et la vérification », la liste de transactions assure « l’enregistrement du contenu », et la racine de Merkle ainsi que le hash parent relient ces deux niveaux et toute la chaîne. Une fois cette structure comprise, lorsque l’on consulte les pages d’explorateurs de blocs de différentes chaînes, on peut distinguer quels champs sont des métadonnées et lesquels sont de véritables transactions, et l’on ne confond plus un bloc avec une simple liste de transactions.