Qu'est-ce qu'une réorganisation de chaîne blockchain, et comment les indexeurs la gèrent-ils ?
Mis à jour en août 2026
Une réorganisation de chaîne — une « reorg » — se produit quand une blockchain remplace des blocs récemment acceptés par une chaîne alternative qui a accumulé plus de travail ou de mise. Les transactions des blocs écartés peuvent n'avoir jamais eu lieu du point de vue de la chaîne canonique.
Pour un indexeur, c'est le problème de justesse le plus difficile du métier, car l'échec est silencieux. Rien ne produit d'erreur. Vous vous retrouvez simplement à détenir des enregistrements dérivés de blocs qui n'existent plus.
Pourquoi les réorganisations se produisent-elles ?
Parce que la production de blocs est distribuée. Deux validateurs peuvent produire des blocs valides à des hauteurs presque identiques, et le réseau est brièvement en désaccord sur celui qui est canonique. Quand il converge, une branche est écartée avec tout ce qu'elle contenait.
La profondeur varie selon la chaîne et les conditions. La plupart des réorganisations font un ou deux blocs. Les plus profondes sont plus rares et plus dommageables, précisément parce qu'un indexeur naïf a eu plus de temps pour agir sur les mauvaises données.
Que se passe-t-il si on les ignore ?
Vos données dérivées divergent silencieusement de la chaîne.
Un swap que vous avez enregistré n'a pas eu lieu. Un solde que vous avez calculé est faux. Une notification s'est déclenchée pour une transaction qui n'existe plus. Rien de tout cela ne lève d'erreur — les enregistrements sont parfaitement bien formés, ils décrivent simplement une version de l'histoire que la chaîne a abandonnée.
Ces bugs remontent des semaines plus tard sous forme de totaux qui ne se réconcilient pas, et ils sont extrêmement difficiles à retracer jusqu'à leur cause.
Comment les indexeurs la gèrent-ils ?
| Stratégie | Fonctionnement | Compromis |
|---|---|---|
| Ignorer | Traiter chaque bloc comme définitif | Rapide, et faux |
| Profondeur de confirmation | Attendre N blocs avant de traiter | Simple, ajoute de la latence, échoue toujours sur les réorganisations profondes |
| Curseurs | Suivre la position exacte dans le flux, contexte de fork inclus | Correct, nécessite que la source le prenne en charge |
La profondeur de confirmation est le compromis courant — attendre douze blocs, ou trente-deux, et considérer que tout ce qui est plus ancien est stabilisé. Cela fonctionne la plupart du temps et coûte une latence proportionnelle à la marge de sécurité. Cela n'a aussi aucune réponse pour une réorganisation plus profonde que votre seuil.
La gestion par curseur est ce que fait Firehose. Chaque bloc porte un curseur identifiant sa position exacte, contexte de fork inclus. Quand une réorganisation se produit, le flux signale explicitement quels blocs ont été annulés plutôt que de continuer silencieusement, ce qui permet à un consommateur d'inverser les données dérivées. Un consommateur qui se déconnecte se reconnecte avec son dernier curseur et reprend exactement au bon endroit.
Cette distinction — être informé de ce qui a été annulé plutôt que de devoir le détecter soi-même — est ce qui rend la justesse atteignable sans en payer le prix en latence.
Que dois-je faire dans mon propre pipeline ?
Stocker le numéro et le hash du bloc avec chaque enregistrement dérivé. Sans cela, vous ne pouvez pas déterminer quoi annuler.
Rendre vos écritures réversibles. Les stores en append-only ont besoin d'une stratégie — une colonne de version avec remplacement de ligne, ou différer les écritures au-delà d'une profondeur de confirmation.
Gérer le signal d'annulation. Si votre source vous indique que des blocs ont été révoqués, agissez en conséquence plutôt que de vous contenter de journaliser et de continuer.
Le tester. Les réorganisations sont assez rares pour qu'un code de gestion non testé soit généralement un code de gestion défaillant.
Questions fréquentes
Jusqu'à quelle profondeur une réorganisation peut-elle aller ? Généralement un ou deux blocs. Les réorganisations plus profondes sont rares mais se produisent, et la profondeur varie selon la chaîne et le mécanisme de consensus.
Les réorganisations affectent-elles les données historiques ? Non. Les blocs profondément ancrés dans l'historique sont stabilisés. Le risque se limite aux blocs récents proches de la tête de chaîne.
La profondeur de confirmation est-elle suffisante ? Souvent, si vous pouvez accepter la latence et le risque résiduel d'une réorganisation plus profonde. La gestion par curseur offre la justesse sans ce compromis de latence.
Obtenez une clé API sur thegraph.market — aucune information personnelle requise.
Voir aussi : Comment fonctionnent les indexeurs blockchain ? · Polling vs streaming des données blockchain · Qu'est-ce qu'un Firehose blockchain ?