Le point de vue de l’analyste sur une blockchain

Chaque constat sur la chaîne repose sur des données qu’une personne a récupérées, décodées et interprétées. Un analyste incapable de dire quel nœud a produit les données, quel logiciel les a décodées et qui leur a appliqué des étiquettes ne peut pas défendre un constat lorsqu’un collègue, un auditeur ou un tribunal demande comment il a été établi. Cette leçon présente l’origine des données de la blockchain et ce que chaque couche y ajoute, afin que vous choisissiez délibérément vos sources et puissiez reproduire vos résultats.

Trois couches de données de la blockchain

Les données de la blockchain se répartissent en trois couches, chacune reposant sur celle qui la précède.

Les données brutes du nœud constituent la référence absolue : tous les nœuds complets honnêtes qui suivent la même chaîne renvoient les mêmes octets pour le même hachage de bloc. La fiabilité des données décodées dépend de celle du décodeur : une adresse dérivée d’un script ou un montant de jetons dérivé d’un événement dépend de la capacité du décodeur à connaître le type de script ou l’interface du contrat (son ABI). Les données enrichies ajoutent une part de jugement : les prix proviennent d’un marché choisi, les étiquettes d’une source choisie, les clusters d’heuristiques choisies.

Plus la couche est élevée, plus les données sont utiles, mais plus elles reposent sur des hypothèses. Règle pratique : chaque affirmation d’un rapport doit pouvoir être retracée jusqu’aux données brutes, et chaque hypothèse ajoutée en remontant les couches doit être consignée.

Nœuds complets, nœuds d’archive et questions auxquelles ils peuvent répondre

Un nœud complet télécharge et valide chaque bloc. Les questions auxquelles il peut répondre dépendent des données qu’il conserve et indexe.

• Bitcoin Core conserve tous les blocs, sauf si l’élagage est activé, et renvoie n’importe quel bloc à partir de son hachage ou de sa hauteur. Pour rechercher une transaction confirmée quelconque à partir de son txid, il a besoin de l’index de transactions facultatif (txindex=1) ; sans cet index, il ne trouve que les transactions du mempool ou celles d’un bloc que vous indiquez. Bitcoin Core ne possède pas d’index d’adresses : il ne peut pas répertorier l’historique d’une adresse. La recherche d’adresses nécessite un indexeur distinct (parmi les exemples open source figurent Electrs, Fulcrum et Esplora).
• Les clients d’exécution Ethereum (Geth, Nethermind, Besu, Erigon, Reth) conservent les blocs, les transactions et les reçus, mais un nœud complet par défaut ne conserve l’état (soldes, stockage des contrats) que pour les blocs récents. Par exemple, le stockage par défaut de Geth fondé sur les chemins conserve une copie complète de l’état sur disque pour le bloc situé 128 blocs en arrière par rapport à la tête de chaîne, ainsi que les modifications en mémoire des blocs plus récents ; il ne peut donc répondre aux requêtes sur l’état que pour environ les 128 derniers blocs. Une demande de solde à un tel nœud pour un bloc datant de l’année dernière échoue. Un nœud d’archive conserve l’état historique de chaque bloc ; il est nécessaire pour les requêtes sur les soldes historiques, les appels de contrats sur des blocs anciens et la plupart des opérations de traçage d’anciennes transactions.

L’historique lui-même se réduit aussi sur les nœuds par défaut. Depuis juillet 2025, tous les principaux clients d’exécution Ethereum prennent en charge l’expiration partielle de l’historique dans le cadre de l’EIP-4444 : un nœud peut supprimer les corps de blocs et les reçus antérieurs à la Fusion (septembre 2022), tout en conservant chaque en-tête. Un nœud configuré ainsi ne peut pas fournir un reçu de 2019. Les analystes qui ont besoin des premières données historiques doivent utiliser un nœud qui les conserve ou une archive historique publiée.

Fournisseurs RPC et indexeurs

L’exécution de nœuds coûte en espace disque, en temps et en maintenance ; la plupart des analystes utilisent donc l’un de deux raccourcis.

Les fournisseurs RPC exécutent des nœuds et exposent les interfaces standard (RPC Bitcoin Core, JSON-RPC Ethereum) sur Internet. Ils sont pratiques, mais vous devez vous en remettre à leur configuration (complet ou archive, client utilisé, méthodes activées), à leurs limites de débit et à leurs erreurs. La leçon API de nœuds et accès aux données explique comment les utiliser et les vérifier.

Les indexeurs lisent continuellement les données des nœuds et les écrivent dans une base de données conçue pour les requêtes : une ligne par transaction, sortie, journal ou trace. Certains indexent tout (les pipelines ETL qui alimentent les jeux de données publics) ; d’autres indexent un seul protocole (un sous-graphe qui suit un seul marché de prêt). Les indexeurs répondent rapidement à des questions auxquelles un nœud ne peut pas répondre aussi vite, comme « chaque événement Transfer impliquant cette adresse sur cinq ans », mais ils ajoutent une dépendance : leur logique de décodage, leur gestion des réorganisations et la fraîcheur de leurs données.

Explorateurs de blocs et entrepôts de données

Un explorateur de blocs est un indexeur doté d’une interface Web. C’est l’outil qui convient pour un premier examen : confirmer qu’une transaction existe, vérifier son statut, lire ses événements décodés. En revanche, il ne faut pas s’y fier exclusivement, et ce pour trois raisons. Ses méthodes de décodage et d’étiquetage sont rarement documentées avec le niveau de détail requis pour un rapport. Ses vues évoluent au fil du temps, de sorte qu’une étiquette ajoutée cette année apparaît sur des transactions datant de plusieurs années. Enfin, les explorateurs ne s’accordent pas sur des chiffres dérivés tels que les « transactions internes », les soldes de jetons ou l’adresse indiquée pour un script non standard.

Un entrepôt de données (une base de données en colonnes contenant des données de chaîne indexées) est l’outil qui convient pour les questions portant sur de nombreuses transactions : totaux, séries chronologiques, toutes les contreparties d’un cluster. La qualité de ses tables dépend de celle du processus ETL qui les a alimentées ; les résultats de l’entrepôt doivent donc être vérifiés sur un échantillon de lignes à l’aide d’un nœud. La leçon La pile de données analytiques compare les options d’entrepôts.

Une méthode fiable combine les trois : un explorateur pour s’orienter, un entrepôt pour traiter les données à grande échelle et un nœud pour vérifier les transactions précises sur lesquelles repose un constat.

Exemple pratique : une question, trois réponses

On demande à une analyste quelle quantité d’ETH l’adresse 0xA1b2…9F a reçue en mars 2025. Trois sources donnent trois chiffres :

• Le relevé des transactions d’un explorateur totalise 41,20 ETH.
• Une requête sur la table transactions d’un entrepôt totalise 41,20 ETH.
• Une requête sur l’entrepôt qui ajoute la valeur transférée par les appels internes, à partir de la table traces, totalise 53,70 ETH.

Aucune des sources n’est erronée. Les deux premières ne comptent que les transactions de premier niveau où l’adresse figurait dans le champ to. Les 12,50 ETH supplémentaires sont arrivés par des appels de contrats, ici un retrait depuis un portefeuille de contrat intelligent, et n’apparaissent que dans les traces. Une quatrième réponse apparaîtrait si l’on incluait l’ETH enveloppé (WETH) : le WETH est un jeton et n’apparaît que dans les journaux d’événements. Une cinquième réponse, erronée si elle est obtenue sans précaution, compterait la valeur des appels qui ont échoué ; les traces les enregistrent aussi, alors qu’aucune valeur n’a été transférée.

L’idée n’est pas qu’un chiffre soit le bon. Il faut préciser la définition des données : quelle couche, quelles tables, quelle plage de blocs, quel actif. « 53,70 ETH reçus sous forme de valeur native dans les blocs X à Y, transferts internes réussis inclus et WETH exclu » est une réponse qu’un autre analyste peut reproduire.

La reproductibilité, premier devoir de l’analyste

La reproductibilité signifie qu’un autre analyste compétent, à partir de vos notes, obtient le même résultat. Les données de la blockchain permettent cela plus facilement que d’habitude, car la couche brute est publique et ne change plus une fois finalisée. Ce qui compromet la reproductibilité, c’est tout ce qui l’entoure :

• Éléments évolutifs. « Le plus récent » change toutes les quelques secondes. Ancrez chaque requête à une hauteur de bloc et consignez le hachage de ce bloc.
• Sources non consignées. Notez le nœud ou le fournisseur, le client et sa version, ainsi que la version du jeu de données et de la table.
• Transformations non consignées. Conservez la requête ou le script exact, y compris les filtres et les conversions d’unités.
• Étiquettes modifiables. Consignez la source de chaque étiquette et la date à laquelle vous l’avez consultée ; les étiquettes sont révisées.
• Données non finalisées. Les blocs récents peuvent être remplacés ; consultez la leçon Les blocs et les en-têtes comme données.

Considérez ces pratiques comme des habitudes, et non comme de la paperasserie. Un constat fondé sur « l’explorateur l’a indiqué mardi dernier » ne peut pas être vérifié ; un constat fondé sur un hachage de bloc précis, une requête sauvegardée et une version de client consignée peut être vérifié par toute personne disposant d’un nœud. La leçon Qualité, normalisation et provenance des données transforme ces points en un enregistrement de provenance que vous pouvez joindre à chaque jeu de données.

Points clés pour l’examen : les trois couches de données (brutes, décodées, enrichies ou étiquetées) et les hypothèses ajoutées par chacune ; les questions auxquelles un nœud complet Bitcoin peut répondre, le rôle de txindex et l’absence d’index d’adresses ; les différences entre les nœuds complets et d’archive Ethereum et la raison pour laquelle l’état historique nécessite un nœud d’archive ; l’expiration partielle de l’historique (EIP-4444) et les données antérieures à la Fusion ; les points forts et les points faibles des fournisseurs RPC, des indexeurs, des explorateurs et des entrepôts ; les raisons pour lesquelles les transferts natifs, internes et de jetons donnent des totaux différents ; et l’ancrage de chaque requête à une hauteur et à un hachage de bloc pour assurer la reproductibilité.