Le 23 mars 2026 à 15:49 UTC, le bloc 941 881 de Bitcoin, miné par AntPool, atteint les nœuds de surveillance ; deux minutes plus tard, le bloc 941 882 de ViaBTC se pose par-dessus. Les portefeuilles affichent les transactions comme confirmées, une fois puis deux. Vers 15:55, Foundry publie une branche de trois blocs, tous les nœuds basculent dessus et les deux blocs sortent de la chaîne. Rien n’a été volé, aucune règle n’a été violée, et pourtant deux confirmations se sont évaporées : c’est tout l’enjeu de la finalité blockchain (finality en anglais). Selon le fil du Bitcoin Network Operations Collective consacré à l’événement, la précédente réorganisation de deux blocs connue datait de mai 2023.
Une transaction peut être vue, incluse dans un bloc, enfouie sous d’autres blocs, déclarée finale par un vote de validateurs, ou jugée finale par une loi, et chaque réseau s’arrête sur un échelon différent de cette échelle. Bitcoin n’atteint jamais la finalité absolue : un paiement devient seulement plus coûteux à annuler à chaque bloc. Ethereum finalise par un vote de ses validateurs, au moins 12,8 minutes après l’arrivée d’une transaction et environ 15 minutes en pratique. Solana a activé le 21 octobre 2026 un nouveau système de vote dont ses développeurs attendent une finalité en une fraction de seconde, un objectif qui n’a pas encore été mesuré sur le réseau principal. Les chaînes Cosmos, elles, cessent de produire des blocs plutôt que de se scinder.
Cette leçon avancée donne trois questions pour juger n’importe quelle chaîne. Comment un bloc que je vois aujourd’hui peut-il disparaître ? À quelle profondeur cela s’est-il déjà produit ? Que faudrait-il dépenser pour le provoquer exprès ? Elle prolonge notre leçon sur le problème de la double dépense, qui montrait comment un attaquant se sert d’une réorganisation pour dépenser deux fois les mêmes pièces ; ici, on regarde les réorganisations elles-mêmes et les règles de finalité conçues pour les empêcher.
Finalité blockchain : trois garanties très différentes
Le mot « final » recouvre trois garanties de force très inégale. Les ingénieurs les rangent en familles, et chaque chaîne que vous utilisez appartient à l’une d’elles, parfois à deux à la fois.
Première famille, la finalité probabiliste, celle des chaînes à preuve de travail comme Bitcoin, Litecoin ou Monero. Aucun bloc n’est jamais final par règle. smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il devient plus difficile à remplacer à mesure que des blocs s’empilent dessus, car une branche concurrente devrait refaire tout ce travail puis dépasser la chaîne honnête. Les chances d’un retour en arrière chutent à peu près exponentiellement avec la profondeur, sans jamais atteindre zéro. La Banque des règlements internationaux l’a formulé sans détour dans un rapport de 2017 de son comité des paiements (CPMI) : « In arrangements that use a proof-of-work model, settlement is probabilistic. » (en anglais : avec une preuve de travail, le règlement est probabiliste).
Deuxième famille, la finalité économique, celle d’Ethereum. Des validateurs qui ont immobilisé des ethers en dépôt votent sur des points de contrôle. Quand deux tiers de la mise ont voté pour un point de contrôle, l’annuler exigerait qu’au moins un tiers de tous les ethers stakés enfreigne les règles de vote d’une manière que le protocole peut prouver et sanctionner. Un retour en arrière reste possible, mais les attaquants perdraient leurs dépôts, et c’est précisément le but.
Troisième famille, la finalité déterministe, que l’on vend parfois comme « finalité instantanée », vient du vote classique des protocoles tolérants aux pannes byzantines, comme dans CometBFT (ex-Tendermint), les jalons (milestones) de Polygon PoS et le nouveau consensus Alpenglow de Solana. Un bloc est final dès qu’un large quorum de mise l’a signé, en général au sein d’un seul bloc. Pas de durcissement progressif : avant le quorum, le bloc n’est pas final ; après, les règles interdisent tout bloc en conflit.
Deux mots aident à comparer. La sûreté (safety) signifie que deux nœuds honnêtes n’acceptent jamais des historiques contradictoires. La vivacité (liveness) signifie que la chaîne continue d’ajouter des blocs. Bitcoin privilégie la vivacité : il produit toujours des blocs, et la sûreté est affaire de probabilité. Les chaînes BFT privilégient la sûreté : si trop de validateurs se taisent, elles s’arrêtent. Ethereum tente de garder les deux, avec une règle de choix de fourche qui maintient l’arrivée des blocs et un module de finalité distinct qui peut se mettre en pause pendant que la chaîne avance, comme mai 2023 l’a montré.
Si vous voulez revoir pourquoi deux blocs valides peuvent apparaître à la même hauteur, notre guide sur le fonctionnement d’une blockchain expose la règle de base pour se mettre d’accord sur une seule chaîne. Pour le coût d’une réécriture de l’historique et les bases des attaques à 51 %, voyez pourquoi une blockchain est dite immuable.
Réorganisation de la blockchain (reorg) sur Bitcoin
Deux blocs valides, une seule chaîne qui survit
Un bloc Bitcoin met du temps à traverser le réseau. Si deux mineurs trouvent un bloc valide presque au même instant, une partie du réseau apprend l’existence de l’un en premier, une autre partie celle de l’autre. Les deux sont valides. Chaque nœud continue de construire sur le premier qu’il a vu et garde l’autre en mémoire. L’égalité se rompt à l’arrivée du bloc suivant : les nœuds suivent la branche qui cumule le plus de travail, en pratique souvent la plus longue. Le bloc perdant devient un bloc obsolète (stale block). Beaucoup disent « bloc orphelin », un usage plus lâche du mot que la prochaine leçon de ce parcours, consacrée aux forks, remet en ordre.
Le basculement s’appelle une réorganisation de la chaîne, ou reorg. Un nœud déconnecte le ou les blocs perdants, annule leur effet sur son registre des pièces non dépensées, connecte les blocs gagnants et remet dans sa mempool toutes les transactions qui figuraient dans les blocs perdus mais pas dans les nouveaux. La plupart sont minées de nouveau en quelques minutes, parce que le mineur gagnant les avait souvent aussi. Une transaction en conflit avec une transaction de la nouvelle chaîne est abandonnée pour de bon : c’est exactement ce qu’espère un fraudeur à la double dépense.
La latence est la première cause des blocs obsolètes accidentels, ce qui explique que les mineurs investissent dans la diffusion rapide des blocs. Notre leçon sur les réseaux pair à pair explique comment les blocs voyagent et pourquoi une propagation lente rend les blocs obsolètes plus probables.
Combien de fois, et à quelle profondeur : le relevé de Bitcoin
Personne ne voit tous les blocs obsolètes, car un nœud n’apprend que l’existence des blocs concurrents qui lui parviennent. Le meilleur relevé public est le jeu de données bitcoin-data/stale-blocks sur GitHub, alimenté par des opérateurs de nœuds qui conservent les blocs que leur nœud a vus puis écartés (en anglais). Lu le 7 novembre 2026, il contenait 4 194 entrées. En les comptant d’après l’horodatage de chaque en-tête de bloc, on obtient ce tableau.
| Année | Blocs obsolètes recensés | Année | Blocs obsolètes recensés |
|---|---|---|---|
| 2015 | 572 | 2021 | 83 |
| 2016 | 175 | 2022 | 28 |
| 2017 | 195 | 2023 | 70 |
| 2018 | 89 | 2024 | 49 |
| 2019 | 68 | 2025 | 93 |
| 2020 | 123 | 2026 (au 3 novembre) | 61 |
Deux réserves. Le jeu de données sous-estime la réalité, puisqu’il dépend de qui contribue et quand ; comparer une année à l’autre reste approximatif. Anthony Towns, développeur de Bitcoin Core, a noté dans le fil du BNOC que son propre nœud n’avait jamais vu les blocs concurrents de Foundry avant la réorganisation, ce qui pourrait signifier que les blocs obsolètes isolés sont plus fréquents que le relevé ne le montre. Bitcoin produit environ 52 500 blocs par an ; les 93 entrées de 2025 suggèrent donc de l’ordre d’un bloc sur cinq cents devenu obsolète : une estimation tirée de ce jeu de données, pas un taux mesuré. La dernière entrée, à la hauteur 974 400, date du 3 novembre 2026.
Presque toutes ces réorganisations ne touchent qu’un bloc. Deux blocs de profondeur, c’est rare. Dans le fil du BNOC sur l’événement de mars 2026, le développeur Anthony Towns a énuméré les chaînes obsolètes de deux blocs antérieures présentes dans le jeu de données : octobre 2013, juin 2015, novembre 2020 et mai 2023. Son estimation approximative de la fréquence : « every 3 years or 150k blocks? », point d’interrogation compris. Foundry a ensuite miné sept blocs d’affilée dans l’après-midi. Quand un site public de surveillance du stratum n’a montré aucun travail de Foundry sur les blocs concurrents, l’auteur du fil, b10c, a évoqué une configuration régionale, un bogue de surveillance ou du minage égoïste ; l’exploitant du site a alors expliqué qu’il n’avait jamais pu collecter les modèles de blocs de Foundry. Aucune cause n’a été établie dans le fil.
Les réorganisations plus profondes de Bitcoin sont venues de bogues, pas de courses entre mineurs. En août 2010, un bogue de dépassement de valeur a permis au bloc 74 638 de créer environ 184 milliards de bitcoins ; un client corrigé est sorti en quelques heures et la chaîne rectifiée a dépassé la mauvaise à la hauteur 74 691, remplaçant environ 53 blocs d’après notre calcul à partir des deux hauteurs que donne le wiki Bitcoin (en anglais), la plus profonde réorganisation de l’histoire de Bitcoin (toute l’histoire est dans notre guide sur le piratage des blockchains). En mars 2013, un bloc comportant plus d’entrées de transactions que les anciens logiciels ne pouvaient en gérer a été accepté par les nœuds en version 0.8 et rejeté par de nombreux nœuds en 0.7, comme l’explique l’analyse a posteriori de Gavin Andresen, la BIP 50 (en anglais). Deux gros pools, BTCGuild et Slush, sont repassés en 0.7 pour que l’essentiel de la puissance de calcul soutienne l’ancienne chaîne. La branche 0.8, que Bitcoin Magazine donnait à un moment avec 13 blocs d’avance, a été abandonnée : la scission a duré 24 blocs à partir de la hauteur 225 430, soit environ six heures.
Pourquoi la profondeur sécurise un paiement sans jamais le garantir
Chaque bloc supplémentaire multiplie le travail qu’une branche rivale doit refaire. Pour un attaquant qui ne détient qu’une minorité de la puissance de calcul, la probabilité de rattraper son retard fond très vite avec la profondeur, ce qui fonde la convention des six confirmations ; notre leçon sur la mempool et les frais de transaction passe en revue le tableau de probabilités du livre blanc lui-même. Ce que la profondeur ne peut pas faire, c’est transformer une probabilité en certitude. Un attaquant qui détiendrait plus de la moitié de la puissance de calcul peut, en principe, dépasser la chaîne honnête à n’importe quelle profondeur, tant qu’il paie l’énergie et le matériel.
Ce n’est pas de la théorie sur les petites chaînes à preuve de travail, où louer assez de puissance coûte moins cher. Ethereum Classic a subi en août 2020 des réorganisations de plusieurs milliers de blocs, et Bitcoin Gold a été frappé en 2018 ; ces attaques à 51 % sont racontées dans notre guide sur le piratage des blockchains, cité plus haut. Un cas plus récent vient de Monero. Le 14 septembre 2025, le Monero Research Lab, un groupe de recherche non officiel, a donné l’alerte sur une réorganisation de 18 blocs à partir de la hauteur 3 499 659, selon The Block (en anglais), qui a compté environ 117 à 118 transactions restées sur la branche abandonnée pendant près de 40 minutes. Des témoignages de la communauté pointaient le projet de minage Qubic, dont le fondateur a rejeté une partie de ces affirmations ; The Block écrit que la responsabilité n’a pas été établie.
La leçon pour celui qui reçoit un paiement est que la profondeur doit être proportionnée à la valeur en jeu et au coût d’une attaque contre cette chaîne précise. Six blocs sur Bitcoin, qui dispose de la plus grande puissance de calcul de tous les réseaux à preuve de travail, apportent bien plus de sécurité que six blocs sur une petite chaîne qui partage son algorithme de minage avec une plus grande.
Finalité Ethereum : un vote adossé à un tiers de la mise totale
Slots, epochs et points de contrôle
Le consensus à preuve d’enjeu d’Ethereum, appelé Gasper, comporte deux parties. Une règle de choix de fourche, LMD-GHOST, désigne la tête de la chaîne à chaque slot en suivant la branche qui a reçu les votes de validateurs les plus récents. Un module de finalité, Casper FFG, travaille à un rythme plus lent. Les spécifications du consensus (en anglais) fixent un slot à 12 secondes et une epoch à 32 slots : une epoch dure donc 6,4 minutes.
Le premier bloc de chaque epoch est un point de contrôle. Pendant l’epoch, chaque validateur actif émet une attestation, qui vote aussi pour un couple de points de contrôle : une source et une cible. Quand des validateurs détenant deux tiers des ethers stakés votent pour la même cible, ce point de contrôle est justifié. Quand un point de contrôle justifié est suivi d’un point de contrôle justifié à l’epoch suivante, le premier devient finalisé, avec tous les blocs qui le précèdent.
Dans le cas normal, une transaction est donc finale à la fin de l’epoch qui suit celle où elle a été incluse ; l’attente dépend de l’endroit de l’epoch où elle est tombée. Le plancher est de deux epochs, soit au moins 12,8 minutes ; en pratique, c’est environ 15 minutes, le chiffre que donne ethereum.org, et la documentation de Circle prévoit 15 à 19 minutes. Une lecture en direct de la beacon chain à 09:53 UTC le 7 novembre 2026 a montré le schéma habituel : tête dans l’epoch 487 555, dernière epoch justifiée 487 554, dernière epoch finalisée 487 553.
Les applications voient ces étapes à travers les étiquettes de bloc de l’interface JSON-RPC d’Ethereum. La spécification execution-apis (en anglais) dit que le bloc latest « may be re-orged out of the canonical chain even under healthy/normal conditions » (il peut être écarté de la chaîne canonique même en conditions saines). Le bloc safe est protégé des reorgs sous l’hypothèse d’une majorité honnête et de certaines hypothèses de délais réseau. Le bloc finalized est le plus récent qui « cannot be re-orged outside of manual intervention driven by community coordination » (ne peut être écarté sans une intervention manuelle pilotée par la coordination de la communauté). Un portefeuille qui affiche une coche verte après un bloc vous montre l’état « latest », le plus faible des trois.
Ce qu’il en coûterait d’annuler un bloc finalisé
Deux points de contrôle en conflit ne peuvent pas être finalisés tous les deux, sauf si au moins un tiers de la mise a signé des votes contradictoires. Ces votes sont des preuves : n’importe qui peut les soumettre, et le protocole sanctionne (slashing) les validateurs impliqués, en brûlant une partie de leur dépôt et en les excluant. La conception d’Ethereum admet qu’un attaquant assez puissant pourrait malgré tout finaliser un historique concurrent, mais elle garantit qu’il perdrait au moins un tiers de tous les ethers stakés. Notre fiche de glossaire sur la preuve d’enjeu (proof of stake) présente le modèle de dépôt et de pénalités en général.
La formule d’execution-apis citée plus haut, « manual intervention driven by community coordination », est la note de bas de page honnête. Si une supermajorité finalisait un jour une mauvaise chaîne, la sortie serait une décision sociale des opérateurs de nœuds de la rejeter, pas une règle automatique. Cela ne s’est jamais produit sur le réseau principal d’Ethereum.
Quand la tête bouge : la reorg de sept blocs de mai 2022
Les anciens blocs sont protégés par la finalité ; la tête de la chaîne, elle, peut encore bouger. Le 25 mai 2022, entre 08:55 et 08:57 UTC, la beacon chain a réorganisé sept blocs, les slots 3 887 075 à 3 887 081. C’était avant la fusion (le Merge) : la beacon chain ne portait pas encore de transactions d’utilisateurs. Dans son analyse de l’événement (en anglais), Barnabé Monnot, chercheur à l’Ethereum Foundation, l’impute à un bloc tardif et à un déploiement partiel d’une modification de la règle de choix de fourche appelée proposer boost : certains clients l’appliquaient, d’autres non, et ils ont divergé sur la tête pendant quelques slots. La finalité n’a pas été retardée.
Quand la finalité s’arrête : mai 2023 et la fuite d’inactivité
La panne inverse s’est produite deux fois en mai 2023. Les blocs continuaient d’arriver, mais la chaîne ne parvenait plus à finaliser. D’après l’analyse a posteriori du client Prysm et une analyse de Thomas Thiery sur ethresear.ch (en anglais), certains clients de consensus, dont Prysm et Teku, géraient mal des attestations valides qui pointaient vers d’anciens points de contrôle : chacune les obligeait à reconstruire un ancien état, et quand ces attestations sont arrivées en nombre, les nœuds Prysm ont manqué de ressources. Lighthouse écartait ces attestations et a continué de tourner.
Le 11 mai, à partir d’environ 20:07 UTC, la finalité s’est arrêtée pendant environ quatre epochs, soit à peu près 25 minutes, avec une participation tombée à environ 40 % et quelque 47 blocs manqués. Le 12 mai, à partir de 17:20 UTC, elle s’est arrêtée pendant environ neuf epochs, un peu plus d’une heure. La participation est tombée à 30,7 %, ce que l’analyse de Prysm présente comme le plus bas niveau de toute epoch du réseau principal, et environ 149 blocs ont été manqués. Les deux fois, la chaîne s’est rétablie sans intervention manuelle, et Prysm v4.0.4 a livré les correctifs. Selon l’analyse, les transactions des utilisateurs finaux n’ont été que très peu touchées : les blocs continuaient d’arriver, et ce sont les services qui attendent des blocs finalisés qui ont dû patienter.
Le second incident a déclenché la fuite d’inactivité (inactivity leak). Quand la chaîne passe plus de quatre epochs sans finalité, le protocole se met à ponctionner le solde des validateurs qui ne votent pas, d’autant plus vite que la panne dure. Le but est de réduire la part des hors-ligne jusqu’à ce que les validateurs encore en ligne détiennent de nouveau deux tiers de la mise restante, pour que la finalité reprenne même si un tiers du réseau avait disparu pour de bon. D’après l’estimation de l’analyse, les validateurs ont payé environ 28 ETH de pénalités et manqué 55 ETH ou plus de revenus potentiels.
Une alerte sérieuse est survenue quelques heures après la mise à jour Fusaka, activée tard le 3 décembre 2025. À partir d’environ 02:45 UTC le 4 décembre, presque tous les nœuds Prysm ont manqué de ressources en vérifiant certaines attestations, rapporte la même page d’analyse. Sur les 42 epochs qu’elle compte comme touchées, 248 slots sur 1 344 n’ont pas eu de bloc, la participation est descendue jusqu’à 75 % et les validateurs ont manqué environ 382 ETH de récompenses d’attestation ; l’incident a été considéré comme maîtrisé à 07:12 UTC. L’équipe Prysm attribue les dégâts limités à la diversité des clients et dit ce qui était en jeu : un client détenant plus d’un tiers du réseau « would have caused a temporary loss in finality » (aurait provoqué une perte temporaire de finalité), et un client détenant plus des deux tiers « could finalize an invalid chain » (pourrait finaliser une chaîne invalide).
Le même document ajoute un avertissement. Citant des données de Miga Labs du 12 décembre 2025, il indique que Lighthouse pourrait faire tourner plus de 56 % du réseau, ce qu’il juge dangereusement proche du niveau à partir duquel le bogue d’un seul client pourrait finaliser une chaîne invalide.
Une finalité plus rapide reste de la recherche
Quinze minutes, c’est long pour un paiement, et les chercheurs d’Ethereum travaillent depuis des années sur la finalité en un seul slot, qui finaliserait chaque bloc dans son propre slot. Au 7 novembre 2026, ethereum.org dit toujours que la finalité en un slot est en phase de recherche et qu’elle n’est pas attendue avant plusieurs années. Des chercheurs ont aussi proposé des conceptions qui finalisent en quelques slots, comme le protocole de finalité en trois slots publié par D’Amato, Saltini, Tran et Zanolini en novembre 2024 (en anglais). Rien de tout cela n’est programmé : la prochaine mise à jour prévue, Glamsterdam, n’avait toujours pas d’epoch d’activation sur le réseau principal dans la spécification du consensus au 7 novembre 2026.
Finalité déterministe : les chaînes qui s’arrêtent plutôt que de se scinder
CometBFT et les chaînes Cosmos
La plupart des chaînes Cosmos font tourner CometBFT, le moteur autrefois appelé Tendermint. Les validateurs enchaînent des tours de proposition et de vote pour chaque hauteur, et un bloc n’est validé que lorsque plus de deux tiers du pouvoir de vote l’ont signé. La documentation de CometBFT (en anglais) promet que, si moins d’un tiers des validateurs est défaillant, « validators will never commit conflicting blocks at the same height. » (les validateurs ne valideront jamais de blocs en conflit à la même hauteur). Il n’y a pas de reorg à attendre : un bloc validé est final en un bloc, en général quelques secondes.
Le prix à payer est la vivacité. Les validateurs n’avancent qu’après avoir entendu plus des deux tiers de l’ensemble ; si plus d’un tiers est hors ligne ou isolé par une panne réseau, aucun bloc n’est produit. La chaîne s’arrête jusqu’au retour d’assez de validateurs. Pour une plateforme d’échange ou un pont, c’est la panne la plus aimable : une chaîne gelée fait perdre du temps, alors qu’une chaîne qui se scinde peut faire perdre de l’argent.
Solana : de 32 slots à Alpenglow
Solana expose la finalité sous trois niveaux d’engagement (commitment) que les portefeuilles et les applications demandent à leur nœud. Sous le consensus Tower BFT, qui a tourné jusqu’en octobre 2026, la documentation d’Anza (en anglais) les définit ainsi : processed signifie qu’un nœud a reçu le bloc sur la fourche majoritaire ; confirmed signifie que 66 % ou plus de la mise a voté pour lui ; finalized signifie qu’au moins 31 blocs confirmés ont été construits par-dessus. Au rythme nominal de 400 millisecondes par slot, ces 32 blocs représentent environ 12,8 secondes.
Le 21 octobre 2026 à 13:36 UTC, au slot 459 648 000, premier slot de l’epoch 1064, le réseau principal de Solana a activé le drapeau de fonctionnalité Alpenglow, comme le montre le compte de fonctionnalité sur la chaîne. Anza appelle Votor la partie vote et finalité d’Alpenglow ; une autre partie, Rotor, change la façon dont les blocs se diffusent sur le réseau. Sous les nouvelles règles, la même documentation fusionne confirmed et finalized : les deux exigent que 60 % de la mise vote pour finaliser, ou que 80 % vote pour notarier un bloc, et les deux signifient que la transaction ne peut plus être annulée. Dans son annonce de mai 2025 (en anglais), Anza écrivait attendre d’Alpenglow qu’il « can achieve actual finality in about 150 ms (median) » (puisse atteindre une vraie finalité en environ 150 ms, valeur médiane), parfois jusqu’à 100 ms. Il faut lire ces chiffres comme l’objectif des développeurs, écrit plus d’un an avant l’activation, et non comme un résultat mesuré sur le réseau principal.
La même annonce précise que Votor finalise en un seul tour de vote quand 80 % de la mise participe, et en deux tours quand seulement 60 % répond.
Polygon PoS : d’une reorg de 157 blocs aux jalons
Polygon PoS montre pourquoi une chaîne rapide sans finalité forte rend les ponts nerveux. Le 22 février 2023, au bloc 39 599 624, la chaîne a réorganisé 157 blocs, environ cinq minutes d’historique. Un message sur le forum de Polygon (en anglais) a relié cette longue reorg à une panne partielle du réseau. Pour qui avait crédité des dépôts après quelques dizaines de blocs, cinq minutes d’historique annulé représentaient une exposition réelle.
Polygon a ensuite ajouté des jalons (milestones) : les validateurs votent sur les blocs récents, et dès que deux tiers du pouvoir de vote sont d’accord, la documentation de Polygon indique que toute transaction jusqu’à ce jalon est finale, avant même que le point de contrôle périodique soit écrit sur Ethereum. Les jalons peuvent aussi défaillir. En septembre 2025, ils ont pris 10 à 15 minutes de retard à cause d’un bogue de nœud, et le réseau a livré un hard fork d’urgence le 10 septembre à 15:00 UTC, selon The Block (en anglais) ; aucune reorg n’a été signalée, seulement une finalité plus lente.
Réseaux de couche 2 : trois sens du mot « confirmé »
Les rollups ajoutent leur propre échelle par-dessus celle d’Ethereum. Si la différence entre une chaîne de base et un rollup est nouvelle pour vous, notre comparaison entre couche 1 et couche 2 l’explique. Ce qui compte ici, c’est ce que veut dire « confirmé » à chaque étape.
La documentation de l’OP Stack (en anglais) décrit trois stades pour des chaînes comme OP Mainnet et Base. Une transaction est unsafe au bout d’environ deux secondes, quand le séquenceur l’a placée dans un bloc qui n’est pas encore publié sur Ethereum. Elle devient safe en quelques minutes, quand ses données figurent dans un bloc d’Ethereum. Elle est finalized au bout d’environ 15 à 30 minutes, quand Ethereum a finalisé ce bloc. La documentation d’Arbitrum décrit le flux du séquenceur de la même façon : « a sub-second provisional confirmation that depends on the Sequencer behaving honestly » (une confirmation provisoire en moins d’une seconde, qui dépend de l’honnêteté du séquenceur), puis une finalité ferme une fois le lot final sur Ethereum.
Une erreur courante consiste à confondre finalité et fenêtre de contestation. Sur les rollups optimistes, les retraits vers Ethereum par le pont officiel attendent environ une semaine pour que les fraudes puissent être contestées ; la documentation de l’OP Stack donne un minimum de sept jours pour son Standard Bridge. Ce délai s’applique au retrait, pas à la transaction elle-même : selon cette documentation, la période de contestation « does not impact transaction finality on the OP Stack chain » (n’a pas d’effet sur la finalité des transactions de la chaîne OP Stack). Un transfert sur un rollup est final dès que le bloc d’Ethereum qui porte ses données est finalisé.
Combien de confirmations : ce qu’attendent plateformes, ponts et commerçants
Tout service qui accepte des cryptos choisit un échelon et assume le risque situé en dessous. Le tableau récapitule l’origine de la finalité de chaque chaîne, au 7 novembre 2026.
| Chaîne | Type de finalité | Ce qui rend un bloc final | Délai typique |
|---|---|---|---|
| Bitcoin | probabiliste | plus de travail empilé par-dessus ; jamais absolue | environ 10 minutes par bloc ; le receveur choisit la profondeur |
| Ethereum | économique (Gasper) | point de contrôle finalisé par deux tiers des ethers stakés | au moins 12,8 minutes, environ 15 en pratique |
| Solana (Alpenglow Votor, depuis le 21 octobre 2026) | vote déterministe | 60 % de la mise vote « finalize » ou 80 % vote « notarize » | environ 150 ms en médiane, objectif d’Anza ; pas une mesure sur le réseau principal |
| Chaînes Cosmos (CometBFT) | déterministe (BFT) | plus de deux tiers du pouvoir de vote signent le bloc | un bloc, quelques secondes ; arrêt si plus d’un tiers est hors ligne |
| Polygon PoS | jalons plus points de contrôle Ethereum | deux tiers du pouvoir de vote sur un jalon | Circle attend 2 à 3 blocs, environ 8 secondes |
| OP Mainnet, Base, Arbitrum One | héritée d’Ethereum | Ethereum finalise le bloc qui porte les données du rollup | souple en 2 secondes environ ou moins ; finale en 15 à 30 minutes environ |
Plateformes d’échange : une profondeur par actif
Les plateformes d’échange centralisées publient le nombre de confirmations qu’elles attendent avant de créditer un dépôt, et ces nombres varient selon l’actif et au fil du temps. La page de support de Kraken sur les délais de dépôt (en anglais), lue le 7 novembre 2026, prend Bitcoin en exemple : les dépôts sont crédités après trois confirmations, qu’elle estime à environ 45 minutes. La plateforme assume elle-même le risque d’une reorg plus profonde : si le dépôt disparaît après que vous avez vendu vos pièces, c’est la plateforme qui est à découvert. Consultez toujours la page de dépôt de la plateforme pour l’actif et le réseau que vous utilisez plutôt qu’un chiffre lu sur un forum ; notre guide sur le fonctionnement des plateformes d’échange centralisées explique le circuit d’un dépôt.
Ponts : payer avant que la chaîne d’origine soit finale
Les ponts portent le plus de risque de reorg, parce qu’ils débloquent des fonds sur une chaîne en échange d’un événement survenu sur une autre. Si la chaîne d’origine se réorganise après que la destination a payé, le pont a versé de l’argent contre un dépôt qui n’existe plus. La documentation du Cross-Chain Transfer Protocol de Circle (en anglais), lue le 7 novembre 2026, montre l’arbitrage entre ses deux modes.
| Chaîne d’origine | Fast Transfer | Standard Transfer (finalité ferme) |
|---|---|---|
| Ethereum | 2 blocs, environ 20 secondes | environ 65 blocs, environ 15 à 19 minutes |
| Arbitrum, Base, OP Mainnet | 1 bloc, environ 8 secondes | environ 65 blocs Ethereum, environ 15 à 19 minutes |
| Solana | 2 à 3 blocs, environ 0,4 à 0,6 seconde | 32 blocs, environ 17 secondes |
| Polygon PoS | non proposé | 2 à 3 blocs, environ 8 secondes |
| Avalanche | non proposé | 1 bloc, environ 8 secondes |
Un transfert rapide paie avant que la chaîne d’origine soit finale : l’opérateur prend donc à sa charge le risque d’une réorganisation, et le fait en général payer. Là où il n’existe pas de mode rapide, l’explication de Circle est que l’attente standard est déjà courte sur ces chaînes. La ligne Solana affiche toujours 32 blocs, la règle de Tower BFT, deux semaines après l’entrée en service d’Alpenglow : les services ne mettent pas tous à jour leurs délais le jour où une chaîne change de consensus. Notre guide sur les ponts et les intentions inter-chaînes détaille leurs architectures et leurs risques.
Commerçants et particuliers : adapter l’attente au montant
Pour un café payé en bitcoin, un paiement non confirmé ou à une confirmation est un petit risque. Pour une voiture, non. Les attaques par course, Finney et reorg décrites dans notre leçon sur la double dépense exploitent toutes un receveur qui tient un bloc peu profond pour final. Des règles simples découlent des sections précédentes : sur Bitcoin, attendre plus de blocs à mesure que le montant grandit ; sur Ethereum et les rollups, traiter « finalized » comme la ligne à franchir pour les grosses sommes et « latest » comme provisoire ; sur les chaînes BFT, un bloc validé est final, mais il faut vérifier que la chaîne produit bien des blocs. Surtout, sachez quel niveau votre portefeuille ou votre service vous montre réellement.
Finalité en droit et finalité sur la chaîne : deux choses distinctes
Les banques et les infrastructures de marché emploient le même mot avec un sens juridique. Dans l’Union européenne, la directive 98/26/CE sur le caractère définitif du règlement rend les ordres de transfert introduits dans un système désigné de paiement ou de règlement-livraison de titres juridiquement opposables et opposables aux tiers, même si un participant devient insolvable. Le Royaume-Uni a son propre équivalent, les Financial Markets and Insolvency (Settlement Finality) Regulations 1999. Cette finalité-là est une règle qu’un tribunal fait respecter.
La directive a été écrite pour des systèmes désignés, gérés par des opérateurs identifiables ; rien sur une chaîne publique n’est final par la loi. La finalité de Bitcoin est une probabilité, celle d’Ethereum une pénalité, celle d’une chaîne BFT une règle de vote. Le rapport de la BRI cité plus haut en tire la conséquence pratique pour la preuve de travail : « the more times the transaction is confirmed in the ledger, the less likely it will be revoked. » (plus une transaction est confirmée dans le registre, moins elle risque d’être révoquée). Chaque modèle a connu son mauvais jour : Bitcoin une reorg de 53 blocs en 2010, Ethereum une heure sans finalité en 2023, Polygon, avant ses jalons, une reorg de 157 blocs la même année.
Le tableau ci-dessous rassemble les incidents datés traités dans cette leçon.
| Date (UTC) | Chaîne | Événement | Profondeur ou durée |
|---|---|---|---|
| 15-16 août 2010 | Bitcoin | bogue de dépassement de valeur, bloc 74 638 | environ 53 blocs |
| 11-12 mars 2013 | Bitcoin | scission de base de données 0.7 / 0.8, à partir du bloc 225 430 | 24 blocs, environ 6 heures |
| 25 mai 2022 | Beacon chain Ethereum (avant le Merge) | déploiement partiel du proposer boost | 7 blocs ; finalité non retardée |
| 22 février 2023 | Polygon PoS | reorg au bloc 39 599 624 après une panne partielle | 157 blocs, environ 5 minutes |
| 8 mai 2023 | Bitcoin | chaîne obsolète de deux blocs | 2 blocs |
| 11 mai 2023 | Ethereum | perte de finalité, bogue de Prysm | environ 4 epochs, environ 25 minutes |
| 12 mai 2023 | Ethereum | perte de finalité, participation à 30,7 % | environ 9 epochs, un peu plus d’une heure |
| 10 septembre 2025 | Polygon PoS | retard des jalons, hard fork d’urgence | finalité retardée de 10 à 15 minutes, pas de reorg |
| 14 septembre 2025 | Monero | chaîne alternative à partir du bloc 3 499 659, origine non établie | 18 blocs |
| 4 décembre 2025 | Ethereum | bogue de Prysm après Fusaka, participation jusqu’à 75 % | 42 epochs dégradées, 248 slots sans bloc |
| 23 mars 2026 | Bitcoin | branche de Foundry qui remplace les blocs d’AntPool et de ViaBTC | 2 blocs, quelques minutes |
La prochaine leçon de ce parcours s’intéresse aux forks, ces changements de règles programmés, soft ou hard, qui scindent une chaîne volontairement, ainsi qu’au vocabulaire bloc obsolète contre bloc orphelin que cette leçon a emprunté. D’ici là, le contrôle le plus rapide que vous puissiez faire est d’ouvrir votre portefeuille ou votre plateforme et de regarder si elle vous montre l’état latest, safe ou finalized.
