---
title: "Règles de choix de branche : branches valides, poids et tête canonique"
description: "Une règle de choix de branche associe la vue locale validée d'un nœud à une tête canonique courante. Il faut analyser séparément validité, ascendance, travail ou poids des votes, points de contrôle, timing, départages, réorganisations et finalité."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Règles de choix de branche : branches valides, poids et tête canonique

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

<a id="answer"></a>

## Réponse directe

Une règle de choix de branche est la procédure protocolaire qui associe la vue locale validée d'un nœud sur des blocs et messages de consensus concurrents à une tête canonique courante. Son résultat est provisoire et relatif à l'observateur : deux nœuds honnêtes peuvent brièvement choisir des têtes différentes parce qu'ils ont reçu des blocs, votes ou événements temporels valides différents. Lorsque leurs vues admissibles convergent selon les hypothèses réseau du protocole, la règle est censée converger elle aussi.

Le choix de branche ne rend pas valide un bloc invalide. Les contrôles de transition d'état, d'autorisation, de preuve, d'ascendance et de disponibilité des données déterminent les candidats admissibles avant toute comparaison de poids. La tête choisie n'est pas nécessairement finalisée non plus. Le choix de branche indique la branche à prolonger maintenant ; une règle de finalité peut protéger un ancêtre plus ancien grâce à des preuves de sûreté plus fortes. Remplacer la tête courante peut relever du fonctionnement normal, tandis que remplacer un point de contrôle finalisé franchirait une autre limite du protocole.

« La chaîne la plus longue » n'est pas une formule universelle. Bitcoin choisit une chaîne valide ayant le plus de travail : le travail attendu cumulé de la preuve de travail, et non la hauteur brute, est décisif. LMD-GHOST d'Ethereum part d'un point de contrôle justifié, filtre les branches viables et suit gloutonnement l'enfant ayant le plus grand solde attestant au titre du dernier message, augmenté de tout proposer boost applicable ; seul le dernier message admissible de chaque validateur contribue. D'autres protocoles peuvent employer des certificats de disponibilité, des verrous de leader, des rounds ou des certificats de commit explicites plutôt qu'une compétition persistante entre branches les plus lourdes.

Le résultat dépend d'entrées exactes : chaîne et réseau, version du fork, ancrage de confiance, heure ou slot courant, blocs valides connus, liens de parenté, instantané du travail ou poids de vote, derniers messages, preuves d'équivoque, points de contrôle justifiés et finalisés, état de disponibilité, timing du proposeur et départages déterministes. Un badge d'explorateur ou un résultat RPC unique est l'observation du résultat d'un nœud, ni la règle elle-même ni une preuve indépendante de ses entrées.

<a id="mechanism"></a>

## Comment analyser une règle de choix de branche

1. **Fixer l'identité et la version.** Relever chaîne, réseau, fork de consensus, version du client, genèse ou ancrage de confiance, hauteur ou slot courant et règle exacte qui s'y applique. Ne pas transposer la logique du mainnet à un testnet, une sidechain, un rollup ou une proposition future.
2. **Construire le graphe des blocs admissibles.** Vérifier hachages, parents, preuves de consensus, transitions d'état, état de l'execution payload et disponibilité des données requise. Marquer explicitement les nœuds inconnus, optimistes, invalides et élagués : le poids ne peut pas sauver une branche invalide.
3. **Reconstruire ascendance et contraintes.** Trouver l'ancêtre commun et confirmer quels candidats descendent des points de contrôle, verrous ou certificats requis. Distinguer l'arbre brut observé de l'arbre filtré que la règle peut réellement considérer.
4. **Reproduire chaque entrée de poids.** Pour la PoW, décoder les cibles et additionner la preuve par bloc en travail cumulé. Pour les règles de vote, vérifier identité du validateur, solde effectif actif ou autre poids, domaine du message, racine cible, slot ou époque, remplacement du dernier message, traitement des équivoques et tout boost temporaire.
5. **Exécuter exactement sélection et départages.** Appliquer la récursion ou le comparateur prévu à chaque embranchement, avec l'arrondi et l'ordre déterministe du protocole. Noter si un poids égal autorise une préférence locale temporaire au lieu de présenter l'égalité comme un accord final.
6. **Réconcilier les changements de tête.** Lorsque le gagnant change, identifier les blocs détachés et attachés, annuler puis rejouer l'état, réconcilier reçus, journaux et mempool, et calculer la profondeur de réorganisation depuis l'ancêtre commun. Garder distincts les libellés head, safe, justified, committed et finalized.
7. **Tester sous contrainte et surveiller le système déployé.** Tester blocs retardés ou retenus, partitions, votes périmés, équivoques, équilibrage, timing du proposeur, désaccord des clients, points de contrôle faibles et données indisponibles. Comparer des nœuds indépendants et alerter sur une divergence inattendue de tête, une réorganisation profonde ou un conflit avec l'état finalisé avant toute action aval irréversible.

Dans Bitcoin Core actuel, l'ordre des candidats compare d'abord `nChainWork` ; à travail égal, ils sont ensuite ordonnés par la première séquence activable, avec un départage interne de repli. Le champ RPC `blocks` est la hauteur de la chaîne au travail maximal entièrement validée, tandis que `bestblockhash` identifie sa pointe. Dans la spécification actuelle du choix de branche d'Ethereum, `get_head(store)` part de `justified_checkpoint`, parcourt un arbre filtré et choisit à chaque étape l'enfant qui maximise `(get_weight(store, child), child.root)`. Ces détails dépendent du protocole et de sa version ; ce ne sont pas des définitions génériques du consensus.

<a id="example"></a>

## Exemples détaillés

### 1. Basculement par travail cumulé dans Bitcoin

Deux branches valides partagent l'ancêtre commun `C`. Les pointes courantes ont `chainwork(A)=240` et `chainwork(B)=235` ; le nœud choisit donc `A`, même si un simple affichage de hauteur donne aux branches une apparence similaire. Un nouveau bloc valide ajoute un travail de `10` à la branche B :

`chainwork(B') = 235 + 10 = 245`

Puisque `245 > 240`, B devient le candidat au travail maximal. Le nœud déconnecte les blocs de A après `C`, connecte B jusqu'à `B'` et réconcilie les transactions. Le nombre brut de blocs ne suffit pas lorsque les cibles par bloc diffèrent, et un travail égal est un cas de départage temporaire, non une preuve de finalité.

### 2. Sous-arbre observé le plus lourd par choix glouton

Prenons un arbre LMD-GHOST simplifié enraciné au point de contrôle justifié `J`. Ses enfants sont `A` et `B`. Les derniers messages admissibles des validateurs donnent à tout le sous-arbre A un poids de `61` et au sous-arbre B un poids de `39` ; la première étape gloutonne choisit donc `A`. A a pour enfants `A_1` et `A_2`, de poids de sous-arbre `34` et `27` ; l'étape suivante choisit `A_1`.

La tête se trouve en choisissant à plusieurs reprises l'enfant le plus lourd, et non en comptant la longueur de la branche ou en sélectionnant la feuille ayant le plus grand vote direct isolé. Les règles de production comprennent aussi le filtrage de viabilité, les instantanés de soldes, la gestion des équivoques, le timing du proposeur et les départages omis dans cet arbre pédagogique.

### 3. Remplacement du dernier message

Supposons que les derniers messages admissibles donnent initialement à la branche A un poids de `55` et à la branche B un poids de `45`. Un validateur de poids `20` envoie ensuite un message admissible plus récent soutenant un descendant de B. La comptabilité du dernier message retire son ancien soutien à A et l'ajoute à B :

`A: 55 - 20 = 35; B: 45 + 20 = 65`

Le poids n'est compté qu'une fois, pas sur les deux branches, si bien que le chemin sélectionné peut changer. Cela n'autorise pas un vote incohérent : si une preuve valide d'attester slashing établit une équivoque, le store Ethereum actuel suit le validateur fautif et exclut ce poids du calcul ordinaire des attestations.

### 4. Filtrage par point de contrôle et proposer boost

Supposons qu'un nœud observe un poids brut du dernier message de `70` sur une branche en conflit avec son point de contrôle finalisé et un poids de `30` sur un descendant viable. La branche conflictuelle est exclue avant le choix de la tête ; une majorité de poids brut ne peut pas contourner la contrainte du point de contrôle finalisé par le choix de branche ordinaire.

Considérons maintenant deux enfants viables dans le slot courant, de poids d'attestation `35` et `50`. Dans la configuration Ethereum citée, un proposer boost ponctuel vaut `40%` du poids d'un comité, et non 40 % de la participation totale. Si le poids du comité est `100` et que le boost s'applique à l'enfant de poids 35, son score de comparaison devient `35 + 40 = 75` et dépasse donc `50` à cette étape. Le boost est temporaire et propre au fork ; il ne constitue ni un vote supplémentaire ni la finalité.

<a id="risks"></a>

## Risques et erreurs de contrôle

### Ensemble de candidats et preuves

- Comparer le poids des branches avant de valider parents, transitions d'état, preuves, état du payload ou données requises.
- Traiter une exécution inconnue ou optimiste, des données indisponibles ou une vue limitée aux en-têtes comme un état entièrement validé.
- Substituer hauteur, horodatage, nombre de transactions, frais ou popularité sur un explorateur au poids spécifié.
- Additionner la difficulté affichée au lieu de reproduire la preuve par bloc et le travail cumulé avec les bonnes cibles.
- Compter tous les votes historiques au lieu du dernier message admissible de chaque validateur avec le bon instantané de poids.
- Ignorer domaine, racine, slot, époque, ponctualité et signature du message, ainsi que les preuves d'équivoque et de slashing.
- Comparer des branches brutes rendues inéligibles par le filtre de point de contrôle, verrou, certificat ou disponibilité du protocole.
- Appliquer une spécification future, un paramètre d'un autre réseau ou une optimisation d'implémentation comme règle de consensus actuelle.

### Sélection et défaillance opérationnelle

- Décrire la règle de Bitcoin comme la simple « hauteur la plus longue » ou celle d'Ethereum comme un vote de tête aux deux tiers.
- Remplacer la récursion gloutonne du sous-arbre par un score global des feuilles, ou omettre proposer boost, arrondi et départage par racine.
- Supposer que des nœuds dont l'ordre d'arrivée, les horloges ou les vues des messages diffèrent doivent immédiatement signaler la même tête.
- Ne pas déconnecter et rejouer correctement état, reçus, journaux, index et entrées du mempool pendant une réorganisation.
- Laisser les clients diverger sur validité, viabilité des points de contrôle, derniers messages, timing ou départages.
- Manquer les conditions d'équilibrage, de rétention, d'équivoque, de partition, d'éclipse, de votes retardés et de réorganisation par proposeur.
- Faire confiance à un seul RPC, explorateur, relais, type de client, cloud ou opérateur de validateurs comme vue indépendante du consensus.

### Finalité et inadéquation applicative

- Qualifier la tête choisie de finalisée, irréversible ou sûre sans les preuves de finalité distinctes du protocole.
- Libérer dépôts, messages de pont ou transactions irréversibles sur une tête transitoire sans politique proportionnée à la valeur.
- Supposer qu'un ancêtre finalisé garantit exactitude ou disponibilité de toute tête, payload, oracle ou résultat applicatif plus récent.
- Employer un nombre fixe de confirmations sur des chaînes aux modèles de travail, vote, point de contrôle et récupération différents.
- Traiter points de contrôle d'urgence, ancrages de faible subjectivité ou récupération sociale comme des entrées ordinaires du choix de branche sans limite de confiance.

<a id="misconceptions"></a>

## Idées fausses courantes

- **La branche la plus longue gagne toujours.** Le protocole peut comparer travail cumulé, derniers messages pondérés, certificats ou autre score ; la hauteur brute n'est pas universelle.
- **La branche observée la plus lourde est automatiquement valide.** Validité et disponibilité filtrent les candidats avant que le poids puisse les départager.
- **Choix de branche et finalité sont la même règle.** Le choix de branche désigne la tête courante à prolonger ; la finalité protège un ancêtre sous des conditions de sûreté supplémentaires.
- **Chaque vote d'un validateur reste éternellement dans le total.** Dans les règles du dernier message, un nouveau message admissible remplace le soutien antérieur du validateur.
- **Un explorateur prouve la chaîne canonique.** Il rapporte la vue d'une pile d'infrastructure ; validation et réconciliation indépendantes restent nécessaires.

<a id="related"></a>

## Sujets connexes

- [Réorganisations de chaîne](/fr/crypto/chain-reorg/)
- [Mécanismes de consensus](/fr/crypto/consensus-mechanism/)
- [Ajustement de la difficulté](/fr/crypto/difficulty-adjustment/)
- [Finalité](/fr/crypto/finality/)
- [Faible subjectivité](/fr/crypto/weak-subjectivity/)

<a id="sources"></a>

## Sources

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté : 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consulté : 2026-08-19)
- [Bitcoin Core: validation.h](https://github.com/bitcoin/bitcoin/blob/master/src/validation.h) - Bitcoin Core (consulté : 2026-08-19)
- [Bitcoin Core: blockstorage.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/node/blockstorage.cpp) - Bitcoin Core (consulté : 2026-08-19)
- [Bitcoin Core RPC: getblockchaininfo](https://developer.bitcoin.org/reference/rpc/getblockchaininfo.html) - Bitcoin Project (consulté : 2026-08-19)
- [Ethereum Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (consulté : 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (consulté : 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (consulté : 2026-08-19)

Source: https://wiki.fcontext.com/fr/crypto/fork-choice-rule/index.mdx