Lorsque vous ouvrez un portefeuille, le solde s’affiche presque immédiatement. Beaucoup de personnes pensent naturellement que la blockchain stocke directement « combien de jetons une adresse possède actuellement », et que le portefeuille se contente de lire ce nombre.

Mais la première impression que la blockchain laisse souvent est plutôt une suite d’enregistrements de transactions : qui a transféré combien de jetons à qui et quand. La question se pose alors : si la chaîne enregistre principalement des transactions individuelles, pourquoi le portefeuille peut-il connaître immédiatement le solde actuel ? C’est précisément le point d’entrée pour comprendre le State (l’état) d’une blockchain.

Ce que le nœud regarde lorsque vous consultez votre solde

Commençons par une expérience de pensée. Supposons qu’une banque conserve uniquement l’historique de tous les virements et ne conserve pas le solde actuel de chaque compte. Chaque fois que vous consultez votre solde, la banque devrait repartir de la première transaction effectuée après l’ouverture de votre compte, additionner tous les encaissements, soustraire tous les débits, puis calculer un nombre. Une seule consultation peut être acceptable, mais si un grand nombre d’utilisateurs consultent leur solde chaque jour, le coût deviendrait rapidement impraticable.

Ainsi, une banque conserve généralement deux types d’informations en même temps :

• L’historique des transactions : il enregistre « ce qui s’est passé » dans l’ordre chronologique.
• Le solde des comptes : il enregistre « quel est le résultat maintenant ».

Une blockchain a besoin d’une distinction similaire. Un registre blockchain ne comporte pas seulement une couche « liste de transactions ». Il contient au moins deux types d’informations essentielles :

1. Un historique ordonné des transactions : les transactions sont regroupées en blocs et reliées dans l’ordre.
2. Le résultat actuel après exécution des transactions : c’est-à-dire l’état actuel du monde, souvent appelé State.

L’historique des transactions répond à la question « que s’est-il passé dans le passé » ; le State répond à la question « à quoi ressemble le monde maintenant, après l’exécution de ces transactions ».

Rappelons brièvement deux notions de contexte. Une transaction est une demande de modification du registre, par exemple « transférer 10 jetons de l’adresse A vers l’adresse B » ; un bloc est un ensemble de transactions organisées dans un certain ordre. Une adresse ressemble à un identifiant de compte, utilisé pour recevoir, détenir ou envoyer des actifs. Le State est souvent organisé autour des adresses pour représenter le résultat actuel.

L’analogie avec la banque aide à comprendre la différence entre « historique » et « solde », mais elle a ses limites : une banque est une base de données centralisée, tandis que l’état d’une blockchain doit être calculé et vérifié par plusieurs nœuds selon les mêmes règles. L’analogie ne permet pas d’expliquer les mécanismes de vérification d’une blockchain ; elle montre seulement pourquoi « ne conserver que l’historique » entraîne des coûts de requête.

Qu’est-ce que le State : un instantané du monde actuel

Dans le contexte de la blockchain, le State peut être compris comme : un instantané du résultat actuel du monde après l’exécution de toutes les transactions confirmées.

Dans une blockchain à modèle de comptes, le State comprend généralement :

• le solde de chaque adresse ;
• le nonce de chaque adresse ;
• les données stockées par les contrats intelligents, c’est-à-dire le stockage des contrats ;
• ainsi que d’autres informations de compte définies par le protocole.

Parmi elles, nonce peut être simplement compris comme le nombre de transactions qu’une adresse a déjà envoyées ; il sert à ordonner les transactions et à empêcher certaines formes de soumission répétée. Les différentes chaînes peuvent définir le nonce de manière légèrement différente, mais dans le modèle de comptes, il fait partie de l’état.

On peut le voir comme un tableau constamment mis à jour :

Adresse ou contrat	Une partie de l’état actuel
Adresse A	Solde 80
Adresse B	Solde 70
Contrat C	Une certaine valeur stockée est 42

Ce tableau n’est qu’illustratif. Dans les systèmes réels, l’organisation de l’état est plus complexe, et différentes blockchains peuvent utiliser différents modèles. Par exemple, certaines chaînes utilisent le modèle UTXO, tandis que d’autres utilisent le modèle de comptes. Cet article ne développe pas une comparaison complète des deux, mais retient l’idée commune : le State représente « qui possède quoi maintenant, et ce qui est stocké dans les contrats ».

Il faut particulièrement souligner que le State n’existe pas par magie et n’est pas immuable. Il est le résultat de l’exécution de l’historique des transactions selon des règles. Lorsque de nouvelles transactions arrivent, l’état passe d’une version à une autre.

Autrement dit, l’« immutabilité » de la blockchain désigne principalement le fait que l’ordre historique des transactions et les règles de transition d’état sont difficiles à réécrire à volonté, et non le fait que les soldes actuels ne changent jamais. Les soldes changent bien sûr ; ce qui change, c’est l’état actuel, tandis que ce qui ne doit pas être réécrit à volonté, c’est l’historique des transactions qui provoque ces changements.

Les transactions entraînent des transitions d’état

Après avoir compris que le State est « le résultat actuel », il faut aussi comprendre comment il change.

On peut voir une blockchain comme une machine à états déterministe. Une machine à états possède un état actuel, des entrées et un nouvel état obtenu après traitement des entrées selon des règles. Pour une blockchain :

• l’état actuel est S1 ;
• l’entrée est une transaction ;
• les règles d’exécution sont définies par le protocole et les contrats ;
• la sortie est le nouvel état S2.

Prenons un ensemble de nombres simples. Supposons que l’état initial soit :

• Alice : 100
• Bob : 50

Première transaction : Alice transfère 20 à Bob. Après exécution, l’état devient :

• Alice : 80
• Bob : 70

Deuxième transaction : Bob transfère 10 à Alice. Après exécution, l’état devient :

• Alice : 90
• Bob : 60

Le point clé ici n’est pas seulement le changement des nombres, mais l’ordre. Les transactions d’une blockchain sont exécutées selon l’ordre à l’intérieur d’un bloc, et le résultat de la transaction précédente devient la condition préalable de la transaction suivante. Si l’ordre change, le résultat peut changer.

Plus important encore, ce processus est déterministe : avec le même état initial, le même ordre de transactions et les mêmes règles d’exécution, tout exécutant honnête obtiendra le même nouvel état. C’est précisément la base qui permet aux nœuds de vérifier les résultats les uns des autres. Les nœuds n’ont pas besoin de faire confiance à une institution centrale qui dirait « le solde est maintenant comme ceci » ; ils peuvent exécuter eux-mêmes les transactions, calculer l’état et vérifier que le résultat est cohérent.

Les transactions valides entraînent des changements d’état. Les transactions invalides n’entraînent pas les changements d’actifs ou d’état de contrat attendus ; toutefois, dans les systèmes réels, le traitement des transactions échouées dépend des règles de la chaîne concernée. Certaines chaînes incluent les transactions échouées dans les blocs, ce qui peut entraîner des frais ou mettre à jour le compteur de transactions de l’expéditeur. Pour comprendre le flux principal, retenons d’abord l’essentiel : les transactions sont les entrées des transitions d’état, et l’état est le résultat après exécution.

Cet exemple numérique comporte aussi des simplifications : il ignore les frais, le stockage interne des contrats, les transactions échouées et d’autres détails ; il sert uniquement à illustrer « comment une séquence de transactions modifie de manière déterministe un instantané d’état ».

Pourquoi ne pas enregistrer uniquement les transactions ?

Puisque l’historique des transactions enregistre déjà chaque étape, pourquoi les nœuds doivent-ils maintenir spécifiquement un State ?

La raison réside dans l’efficacité et la vérifiabilité.

Pour répondre à la question « quel est le solde d’Alice maintenant », si l’on ne dispose que de l’historique des transactions, un nœud doit partir du bloc genesis, rejouer toutes les transactions concernées dans l’ordre et calculer jusqu’à la plus récente. Supposons qu’une chaîne fonctionne depuis plusieurs années, avec des millions de transactions chaque année ; alors une seule consultation de solde pourrait nécessiter de recalculer une grande quantité d’historique. Pour les portefeuilles, les plateformes d’échange, les explorateurs de blocs et les interactions avec les contrats intelligents, ce coût est inacceptable.

La vérification d’une nouvelle transaction nécessite aussi l’état actuel. Par exemple, si Alice veut transférer à nouveau 100 jetons, le nœud doit vérifier rapidement :

• le solde actuel d’Alice est-il suffisant ?
• le nonce de cette transaction correspond-il à ce qui est attendu ?
• les conditions requises pour l’appel de contrat sont-elles remplies ?
• la transaction violerait-elle les règles du protocole ?

Si chaque vérification rejouait tout l’historique, le système deviendrait très inefficace. Maintenir l’état actuel revient à permettre aux nœuds de conserver un « dernier résultat », afin de vérifier rapidement si les nouvelles transactions sont valides.

Ainsi, l’historique des transactions et le State ne se substituent pas l’un à l’autre :

• L’historique des transactions sert à l’audit, à la traçabilité et au rejeu ;
• Le State sert à interroger efficacement le résultat actuel et à vérifier les nouvelles transactions.

En théorie, l’état peut être recalculé à partir de l’historique des transactions. Si les nœuds complets maintiennent un état, ce n’est pas parce que l’historique des transactions n’a aucune valeur, mais parce que l’usage réel exige d’obtenir rapidement le résultat actuel. Qualifier le State de « cache superflu » serait inexact ; il s’agit d’une conception nécessaire pour qu’une blockchain puisse prendre en charge les requêtes quotidiennes et l’exécution de contrats.

Comment la blockchain s’engage sur le State : la racine d’état

La question suivante est la suivante : l’état peut être volumineux et contenir de nombreuses données de comptes et de contrats. Une blockchain ne peut tout de même pas copier l’état complet dans chaque bloc, n’est-ce pas ?

En général, non. Ce qui est stocké dans l’en-tête de bloc est un engagement cryptographique sur l’état actuel, souvent sous la forme d’une racine d’état (state root).

Un condensé de hachage peut être simplement compris comme une « empreinte digitale » d’un ensemble de données : si les données ne changent pas, l’empreinte ne change pas ; si les données changent, l’empreinte change généralement. La racine d’état est l’engagement obtenu en condensant cryptographiquement l’état actuel du monde. Elle ne contient pas le solde complet de chaque compte, mais elle peut servir à vérifier qu’un certain état est cohérent avec le résultat reconnu par la chaîne.

Prenons Ethereum comme exemple : son en-tête de bloc contient un champ stateRoot, utilisé pour engager l’état du monde après l’exécution des transactions. Après avoir exécuté les transactions d’un bloc, les nœuds calculent la nouvelle racine d’état et la comparent à la racine d’état présente dans l’en-tête de bloc. Si les deux ne correspondent pas, cela signifie que le résultat d’exécution ne correspond pas au résultat revendiqué par le producteur du bloc, et le bloc est rejeté.

Cela explique aussi un malentendu courant : une blockchain n’écrit pas directement le solde actuel complet de chaque compte dans chaque bloc. L’état complet est généralement maintenu localement par les nœuds complets ; l’en-tête de bloc stocke un engagement condensé tel que la racine d’état. Lorsqu’un portefeuille consulte un solde, il lit généralement l’état maintenu par un nœud à travers ce nœud, plutôt que de lire directement le solde dans un champ de l’en-tête de bloc.

La racine d’état apporte également des avantages en matière de vérification. Grâce à la racine d’état et aux preuves correspondantes, les nœuds légers peuvent vérifier si un compte ou une valeur de stockage appartient à cet état sans conserver eux-mêmes l’état complet. La structure précise des preuves implique des structures de données plus complexes, que cet article ne développe pas ; l’essentiel est de comprendre : la blockchain prend un engagement vérifiable sur l’état actuel, plutôt que d’insérer l’état complet dans chaque bloc.

La répartition des rôles entre l’historique des transactions et le State

À ce stade, un autre malentendu peut facilement apparaître : puisque le State est si important, la blockchain enregistre-t-elle principalement le State plutôt que les transactions ?

Pas exactement. Une formulation plus précise est la suivante : la blockchain conserve à la fois un historique ordonné des transactions et s’engage sur le résultat d’état après exécution des transactions.

L’historique des transactions ressemble à un enregistrement vidéo complet, qui consigne ce qui s’est passé à chaque étape ; le State ressemble au score actuel, qui vous indique le résultat maintenant. L’enregistrement permet de reconstituer le score, mais lorsque le match doit continuer, s’appuyer uniquement sur le score actuel est plus efficace. Cette métaphore a aussi ses limites : l’état d’une blockchain n’est pas maintenu par un seul arbitre, mais calculé et vérifié par plusieurs nœuds selon des règles.

La répartition des rôles peut être comprise ainsi :

• L’historique des transactions fournit une séquence d’événements auditable ;
• Le State fournit un résultat actuel interrogeable et vérifiable ;
• L’état peut être recalculé à partir de l’historique des transactions, de sorte que les nœuds complets peuvent vérifier au lieu de faire aveuglément confiance ;
• Les nœuds peuvent aussi choisir de conserver des états plus anciens, ou de reconstruire l’état en rejouant les transactions, mais cela exige des coûts de stockage et de calcul.

Dans les systèmes réels, différents nœuds stockent des contenus différents. Les nœuds complets maintiennent généralement l’état actuel et vérifient les transactions ; les nœuds d’archive conservent davantage d’états historiques pour interroger les données à un moment passé ; les nœuds légers ne stockent qu’une petite quantité d’informations et s’appuient sur les racines d’état et les preuves pour vérifier. Il n’est pas nécessaire d’entrer ici dans les détails d’implémentation de chaque type de nœud ; il suffit de savoir que l’historique des transactions et le State forment ensemble un registre complet, et qu’il ne s’agit pas d’un choix exclusif.

Replacer le State dans le modèle mental de la blockchain

Nous pouvons maintenant revenir à la question initiale : pourquoi la blockchain enregistre-t-elle le State, et pas seulement les transactions ?

Parce que les transactions décrivent des changements, tandis que le State décrit le résultat après ces changements. Pour prendre en charge la consultation des soldes, la vérification de nouvelles transactions et l’exécution de contrats intelligents, une blockchain doit connaître l’état actuel. Conserver uniquement l’historique des transactions permet théoriquement de recalculer l’état, mais le coût augmente avec l’historique et ne peut pas soutenir un usage réel.

La relation essentielle peut être résumée en une phrase :

Les transactions répondent à « que s’est-il passé » ; l’état répond à « qu’est-ce qui est maintenant ».

Les transactions sont des événements, le State est le résultat ; les transactions sont des entrées, les transitions d’état sont des sorties. Grâce à des transactions ordonnées et à des règles déterministes, une blockchain déduit un nouvel état à partir d’un ancien état, et utilise les racines d’état pour prendre des engagements cryptographiques sur le résultat actuel. L’historique des transactions reste important ; il sert à l’audit et au rejeu. Mais le State fait d’une blockchain un système de paiement et de calcul utilisable, et pas seulement un journal historique qui ne cesse de croître.

Lorsque vous verrez à l’avenir des données telles que les soldes de comptes, le stockage de contrats ou la TVL, vous pourrez les comprendre comme des références à un certain état ou des calculs effectués sur celui-ci. Lorsque vous rencontrerez des sujets plus avancés comme la croissance de l’état, l’expiration de l’état ou les clients sans état, vous pourrez aussi revenir à ce modèle de base : une blockchain ne doit pas seulement se souvenir de ce qui s’est passé dans le passé, elle doit aussi savoir ce qui est maintenant.