Lire une blockchain de façon critique

Une question de départ

Vous ouvrez un explorateur et lisez : « Transfert de 150 USDT d'Alice (Exchange X) à Bob, il y a 3 minutes, frais 0,40 $ ». Combien de ces mots sont des faits inscrits dans un bloc ? Très peu. Pour le voir, il faut suivre le chemin de la donnée.

Le chemin de la donnée

nœud (blocs, état)  ->  indexeur (décode, range)  ->  base de données
                    ->  API  ->  site web ou appli  ->  votre écran

1. Le nœud (le programme qui télécharge les blocs, vérifie les règles et détient l'état ; atelier 113) détient les blocs et l'état. C'est la seule étape où l'on trouve des octets consensuels.
2. L'indexeur est un logiciel qui lit les blocs, les décode (quelle fonction a été appelée ? quel montant ?), les range dans une base de données classique pour répondre vite à « toutes les transactions de cette adresse ». Il décide de ce qu'il garde et de la façon de l'afficher.
3. L'API et le site ajoutent des étiquettes, des prix, des horodatages convertis, des graphiques.

Chaque étape est un logiciel écrit par une équipe, avec ses bogues, ses retards et ses choix.

Tri de l'exemple

Sur six lignes, seuls le montant et le statut viennent de données consensuelles (le montant après décodage, le statut après lecture du reçu quand la chaîne en produit) ; l'heure relative, le nom du jeton, l'étiquette et le prix en dollars sont dérivés ou fournis par des tiers. Même le montant n'est pas « directement dans les octets » : pour un jeton, l'indexeur le calcule à partir d'un événement ou des données de l'appel, et d'une métadonnée du jeton (son nombre de décimales).

Ce qui est brut, ce qui ne l'est pas

Brut (consensuel) : l'en-tête et le corps d'un bloc, les transactions signées, le résultat des règles appliquées (l'état après le bloc, et les reçus quand le protocole en produit).

Dérivé : toute interprétation, tout regroupement, toute valeur en monnaie fiduciaire, toute étiquette (« Exchange X »), tout classement (« top holders »), tout « transfert interne » reconstitué par rejeu des appels.

Exemple : l'heure d'un bloc

Sur Bitcoin et les chaînes de type Ethereum, l'heure affichée est l'horodatage que le producteur du bloc a écrit dans l'en-tête, dans des limites que le protocole contrôle seulement grossièrement. Elle ne vient pas d'une horloge de confiance. (Sur CometBFT, l'heure vient d'un calcul entre validateurs : chaque famille de chaînes a sa règle.) L'explorateur la convertit dans un fuseau (souvent UTC ou celui de votre navigateur). Deux explorateurs peuvent donc afficher des heures « différentes » pour le même bloc sans qu'aucun ne mente : l'un affiche UTC, l'autre l'heure locale (UTC+1 au Cameroun, sans changement d'heure).

Ce que cela ne garantit PAS

• Un explorateur connu n'est pas une autorité : il peut être en retard, avoir un bogue, être piraté (page web ou domaine) ou être lent à se réorganiser avec la chaîne.
• Un chiffre cohérent entre trois sites n'est pas vérifié : ils peuvent lire le même indexeur, ou le même fournisseur de nœud.
• « C'est sur la blockchain » ne veut pas dire « c'est vrai » : cela veut dire « un participant l'a signé et la chaîne l'a accepté ».

À retenir

Pour chaque ligne d'un écran, demandez : ce fait est-il dans les octets du bloc, ou quelqu'un l'a-t-il calculé, deviné ou ajouté ? Seul le premier cas se vérifie directement contre un nœud.

Le problème

Un explorateur affiche : « Bloc 9 000 010, contient votre paiement, 12 confirmations ». Comment le vérifier sans croire l'explorateur ? En interrogeant un nœud — idéalement le vôtre (atelier 113) — par son interface JSON-RPC.

JSON-RPC 2.0 en trois lignes

JSON-RPC 2.0 est une convention : vous envoyez un objet JSON avec quatre champs principaux, le serveur répond par un objet avec le même id.

-> {"jsonrpc":"2.0","method":"chain_getBlockByNumber","params":[9000010,false],"id":7}
<- {"jsonrpc":"2.0","result":{"number":9000010,"hash":"0x…","txCount":142},"id":7}

• jsonrpc vaut toujours "2.0" ; method est le nom de l'appel ; params la liste des arguments ; id relie la réponse à la requête. Dans la spécification, params et id sont facultatifs (une requête sans id est une notification : le serveur n'y répond pas) ; dans ce cours, nous les écrivons toujours.
• En cas d'échec, la réponse contient error à la place de result. La spécification définit des codes standard : -32700 (JSON illisible), -32600 (requête invalide), -32601 (méthode inconnue), -32602 (paramètres invalides), -32603 (erreur interne). Les codes de -32000 à -32099 sont réservés aux erreurs propres au serveur : de vrais nœuds s'en servent pour leurs propres messages, d'où l'intérêt de lire leur documentation.

Trois vérifications que vous pouvez faire

1. Le bloc existe-t-il, avec cette empreinte ? Demandez le bloc au numéro donné et comparez son empreinte avec celle de l'explorateur. Si les empreintes diffèrent, l'un des deux suit une autre branche ou est en retard.
2. La transaction est-elle dans ce bloc ? Le corps est résumé par une racine de Merkle (atelier 106) dans l'en-tête. Un nœud complet peut vous donner la liste ; un client léger demande une preuve d'inclusion et la recalcule : feuille, frères, racine. Dans l'explorateur de Merkle, modifiez une feuille : la racine change, donc la preuve échoue. Avec l'outil de hachage, recalculez vous-même un nœud parent à partir de deux fils.
3. Quel est le résultat de l'exécution ? Sur les chaînes qui produisent des reçus, le « statut » est dans le reçu ; demandez le reçu au nœud, ne vous fiez pas à une icône verte.

Confirmations et finalité

« 12 confirmations » signifie en général que la transaction a 12 blocs au total depuis son bloc d'inclusion, ce bloc compris : il compte pour la première confirmation, puis 11 autres blocs ont été construits après lui (convention de l'atelier 109 ; certains outils comptent autrement). Ce n'est pas une garantie de finalité. Sur une chaîne à finalité déterministe (atelier 109), une transaction est finale quand le protocole le déclare, indépendamment du nombre de blocs. Sur une chaîne à finalité probabiliste, plus il y a de blocs, plus une réorganisation est improbable, sans devenir impossible.

Certaines interfaces de nœud permettent de demander l'état à une étiquette de finalité (« dernier », « finalisé » …). Quand votre chaîne en propose, utilisez-les : lire « le plus récent » et lire « le finalisé » sont deux affirmations différentes.

Exemple détaillé : trois sources, un désaccord

On vous donne :

• Explorateur A : bloc 9 000 010, empreinte commençant par 0x4f3a.
• Explorateur B : bloc 9 000 010, empreinte commençant par 0x4f3a.
• Votre nœud : bloc 9 000 010, empreinte commençant par 0x91c2.

Deux sources sur trois sont d'accord, donc A et B ont raison ? Non. Le désaccord est une question, pas un vote. Hypothèses : A et B lisent le même fournisseur ; votre nœud est encore en cours de synchronisation ; ou une réorganisation a eu lieu. On le résout en demandant à votre nœud la hauteur finalisée et en réinterrogeant plus tard, pas en comptant les voix.

Votre nœud lui-même est une hypothèse

Si vous interrogez un nœud d'un fournisseur, vous faites confiance à ce fournisseur. Si vous interrogez votre propre nœud, vous faites confiance à votre logiciel, à votre version et aux pairs auxquels il est connecté (un nœud entouré de pairs malveillants peut être trompé, voir atelier 113).

Ce que cela ne garantit PAS

• Une réponse de nœud n'est pas une preuve : c'est une réponse. Seule une preuve (Merkle, signatures) recalculée contre un en-tête de confiance en est une.
• Comparer des empreintes de blocs ne vérifie pas que les règles ont été respectées : seul un nœud complet qui rejoue le bloc le fait.
• Interroger une fois ne dit rien sur la finalité.

À retenir

Pour vérifier : demandez la donnée brute à un nœud, recalculez ce qui peut l'être, traitez tout désaccord comme une enquête, et distinguez « le plus récent » de « final ».

Le problème

Un tableau de bord annonce : « 1 000 adresses actives par jour ». Une jeune pousse s'en sert pour dire qu'elle a « 1 000 utilisateurs ». Est-ce vrai ? Pour le savoir, il faut connaître la définition, la fenêtre et la source de chaque chiffre.

Ce que fait un indexeur — et ce qu'il suppose

Un indexeur transforme des blocs en tables interrogeables. Ce faisant, il :

• décode les données : il doit connaître la structure des appels (l'interface d'un contrat). Si elle est inconnue ou fausse, il affiche des octets bruts ou un mauvais nom ;
• choisit quoi garder : certains ignorent les transactions échouées, les événements mal formés, ou les traces internes ;
• gère les réorganisations : quand un bloc est remplacé, il doit défaire ce qu'il a rangé. Un mauvais indexeur peut garder des données d'une branche abandonnée ;
• est en retard d'un nombre variable de blocs : il lit la chaîne, puis écrit en base ;
• ajoute des données externes : étiquettes d'entités, prix en monnaie fiduciaire, classements.

Ce sont des choix de conception, non des erreurs. Le danger est de lire le résultat comme un fait brut.

Métriques : poser trois questions

Devant tout chiffre :

1. Définition : qu'est-ce qui est compté exactement ?
2. Fenêtre : sur quelle période, avec quelle heure de coupure ?
3. Reproductibilité : puis-je recalculer le chiffre à partir de données de nœud ? Sinon, c'est une affirmation, pas une mesure.

Quatre pièges avec chiffres

1. « Adresses actives » ≠ utilisateurs. Une adresse est une clé, pas une personne (atelier 112). Une personne peut avoir des centaines d'adresses ; un script peut en créer des milliers en quelques minutes. Exemple : le tableau de bord indique 1 000 adresses actives ; une analyse montre que 600 d'entre elles sont contrôlées par un même opérateur. Il y a donc au plus 400 + 1 = 401 opérateurs distincts, et probablement moins. Le chiffre le plus flatteur n'est pas le chiffre le plus juste.

2. Le volume peut être fabriqué. Un acteur qui s'échange un actif à lui-même (wash trading) gonfle le « volume » sans changer qui détient quoi. Exemple : un compte A envoie 100 unités à un compte B qu'il contrôle, B les renvoie, et cet aller-retour se répète 50 fois : volume affiché 10 000 unités (50 × 2 × 100), capital réellement en jeu 100.

3. La valeur verrouillée peut être comptée plusieurs fois. Alice dépose 100 unités dans le protocole P1 et reçoit 100 jetons-reçus. Elle dépose ces jetons-reçus dans P2 et reçoit 100 jetons-reçus de P2, qu'elle dépose dans P3. Chaque protocole annonce 100 de « valeur verrouillée » : la somme du tableau de bord est 300 alors que le capital réel distinct est 100.

4. Les définitions off-chain. Une « offre en circulation » n'est pas dans la chaîne : l'équipe décide quels comptes ne comptent pas (réserves, verrouillés). C'est un jugement publié, pas un fait calculé par le protocole.

Exemple : refaire un calcul

Chiffre à vérifier : « 1 000 transactions par jour en moyenne ». Procédure : prendre les blocs d'un jour (heure de coupure fixée), compter les transactions de chaque bloc (txCount), additionner, comparer. Si l'écart dépasse quelques pour cent, cherchez la cause : transactions échouées comptées ou non ? fuseau horaire ? blocs en cours de réorganisation ?

Ce que cela ne garantit PAS

• Reproduire un chiffre ne le rend pas pertinent : une définition peut être cohérente et inutile pour votre question.
• Un indexeur « officiel » n'est pas plus consensuel qu'un autre : c'est un programme de plus.
• L'absence de manipulation visible n'en est pas la preuve : lisez la définition avant d'interpréter.

À retenir

Tout chiffre agrégé porte une définition, une fenêtre et des hypothèses. S'il n'est pas reproductible depuis des données de nœud, traitez-le comme une opinion avec une source, pas comme un fait.

Le problème

Une personne reçoit 200 « BACUSD » dans son portefeuille et croit à un cadeau. Le jeton est sans valeur : c'est un leurre, et la page « d'approbation » qu'on lui propose ensuite peut servir à obtenir une signature qui donne accès à des fonds de valeur. Les pièges d'affichage exploitent un fait simple : les noms ne sont pas des identités.

Identité d'un jeton = adresse du contrat

Le nom (« BACUSD ») et le symbole d'un jeton sont des chaînes de caractères choisies par celui qui déploie le contrat. Rien dans le protocole n'empêche deux contrats d'avoir le même nom ou le même logo. L'identité, c'est la chaîne + l'adresse du contrat, à comparer avec la source officielle du projet (sa documentation ou son dépôt).

Exemple fictif :

Contrat officiel du jeton (d'après la documentation du projet) :  0xAAAA...0001
Transferts de jetons reçus par votre compte :
 +500  « BACUSD »  du contrat 0xAAAA...0001
 +200  « BACUSD »  du contrat 0xBBBB...0042

Les deux lignes s'affichent pareil ; une seule est le vrai jeton. Un symbole identique, un logo copié, une pastille « vérifié » sur une plateforme : aucun de ces éléments ne remplace la comparaison d'adresse.

Autres pièges classiques

• Adresse trompeuse (address poisoning) : un attaquant vous envoie une transaction minuscule depuis une adresse dont le début et la fin ressemblent à celles de votre contact. Plus tard, vous copiez l'adresse « dans l'historique » et envoyez à l'attaquant. Défense : comparer l'adresse entière, caractère par caractère ou par l'intermédiaire d'un carnet d'adresses de confiance, et ne jamais copier depuis l'historique.
• Contrats homonymes : un contrat porte un nom proche de celui d'un projet connu. Le nom d'un contrat n'est pas unique.
• Transferts non sollicités : n'importe qui peut vous envoyer un jeton ; le recevoir ne signifie pas que vous l'avez demandé ni qu'il a de la valeur. Une interaction (approuver, signer) est un acte distinct.
• Valeurs en dollars sans marché : un jeton sans liquidité peut afficher un prix fantaisiste. La valeur affichée vient d'un fournisseur, non de la chaîne.

Centralisation et hypothèses de confiance

Un explorateur ou un fournisseur de nœud est un service centralisé : une entreprise, un domaine, des serveurs, une équipe.

Un tableau de bord présenté comme « décentralisé » peut dépendre d'un seul fournisseur de nœud ou d'une seule base de données. Avant de croire un système, cherchez son point de défaillance unique.

Ce qu'un explorateur peut — et ne peut pas — prouver

Un explorateur ne prouve rien par lui-même : c'est un témoin, pas une preuve. Il peut vous orienter vers un bloc et une transaction que vous vérifiez ensuite (leçon 2). Il ne peut pas prouver :

• que l'étiquette « Exchange X » est exacte ;
• que le bloc est final (il montre souvent le plus récent) ;
• que le jeton affiché est le bon ;
• que le prix en dollars est celui d'un marché réel ;
• que vous voyez la même chose que tout le monde.

Une pratique raisonnable

Pour toute décision qui engage de l'argent : (1) lire l'adresse complète et celle du contrat ; (2) confirmer la donnée sur un second chemin indépendant, idéalement votre nœud ; (3) attendre la finalité adaptée au montant ; (4) ne rien signer d'incompris.

Ce que cela ne garantit PAS

• Comparer l'adresse d'un contrat avec la documentation officielle ne protège pas si la documentation est elle-même usurpée : vérifiez que vous êtes bien sur la source officielle (adresse du site tapée à la main ou dépôt officiel de l'organisation).
• Un contrat vérifié (code source publié) n'est pas un contrat honnête : « vérifié » veut dire que le code publié correspond au code déployé, non qu'il est sûr.
• Ces règles réduisent le risque, elles ne le suppriment pas.

À retenir

Les noms et les logos ne sont pas des identités ; l'adresse l'est. Un explorateur est un témoin centralisé. Pour une décision d'argent, confirmez par un chemin indépendant.