---
title: "Subjectivité faible : points de contrôle fiables et synchronisation PoS sûre"
description: "La subjectivité faible permet à un nœud en preuve d'enjeu de vérifier de manière objective l'avenir après avoir obtenu un point de contrôle fiable suffisamment récent. Découvrez pourquoi les anciennes signatures peuvent prendre en charge des historiques à long terme, comment la récence des points de contrôle et l'indépendance des sources sont vérifiées, et ce que la synchronisation des points de contrôle ne prouve pas."
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.

# Subjectivité faible : points de contrôle fiables et synchronisation PoS sûre

> À 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

La subjectivité faible est un modèle de sécurité proof-of-stake dans lequel un nœud peut vérifier les blocs, les transitions d'état, les votes et le choix de bifurcation selon les règles du protocole après avoir commencé à partir d'un point de contrôle suffisamment récent obtenu par un canal de confiance ou socialement corroboré. L'entrée subjective « faible » est le point de départ. Cela ne constitue pas une permission de choisir des blocs ultérieurs arbitraires : une fois ancré, le nœud doit rejeter les historiques qui ne contiennent pas le point de contrôle et vérifier normalement la progression.

Le problème est l'ambiguïté historique. Un adversaire qui obtient les clés de validateurs qui sont sortis et qui ne peuvent plus être punis économiquement peut construire une longue histoire alternative avec des signatures ayant l'apparence de la validité. Un nœud qui a observé la chaîne canonique pendant que ces validateurs pouvaient être sanctionnés conserve une mémoire utile. Un nœud tout neuf, un nœud dont la base de données a été supprimée ou un nœud hors ligne au-delà de la fenêtre de récence sûre du protocole peut ne pas être capable d'identifier l'histoire socialement canonique à partir des données de genèse et des messages des pairs uniquement.

Sur Ethereum, un point de contrôle de faible subjectivité est un `epoch` et `block_root` que le client considère comme une ancre absolue. Une synchronisation réussie doit prouver que le chemin canonique contient cette racine à cette époque ; une non-concordance est une défaillance critique, et non un vote de choix de fork. Un point de contrôle de faible subjectivité diffère également d'un point de contrôle finalisé ordinaire : si un nœud rencontre pour la première fois deux historiques finalisés conflictuels sans mémoire préalable, les règles de finalité seules n'identifient pas quel historique social est canonique.

Ne pas universaliser le mécanisme de Ethereum. Les clients légers CometBFT commencent à partir d'un en-tête de confiance au sein d'un `trusting_period` configuré et transfèrent la confiance en utilisant le chevauchement des ensembles de validateurs, les signatures, les limites temporelles et les témoins. La recherche Ouroboros Genesis définit plutôt une règle de sélection de chaîne destinée à démarrer à partir d'un bloc génésis de confiance sous son modèle de sécurité déclaré. "Proof of stake" n'implique donc pas un format de point de contrôle unique, une formule de période unique ou une procédure de démarrage unique.

Séparez également la subjectivité faible d'un raccourci de synchronisation. La synchronisation de point de contrôle peut réduire le temps de démarrage et le traitement de l'état historique, mais la vitesse n'est pas la définition de la sécurité. Une racine de confiance n'authentifie pas le site Web qui l'a fournie, ne valide pas une charge utile d'exécution en dehors des hypothèses déclarées par le client, ne restaure pas l'historique élagué, ne prouve pas la disponibilité des données, et ne rend pas honnête un ensemble de pairs éclipsé.

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

## Comment vérifier un bootstrap de faible subjectivité

### 1. Identifiez le protocole exact et le modèle de sécurité

Enregistrez le `network`, `chain ID`, la racine ou le hachage de la genèse, la fourche active ou le runtime, la version du client, le type de point de contrôle et la spécification du consensus. Déterminez si le protocole nécessite un point de contrôle social récent, un en-tête de confiance plus un ensemble de validateurs, une chaîne de preuve de finalité, ou seulement la genèse selon un modèle différent. Ne transplantez jamais le `compute_weak_subjectivity_period` du Ethereum ou le `trusting_period` du CometBFT dans une autre chaîne sans ses règles.

### 2. Décidez si la confiance existante est toujours actuelle

Inventoriez le dernier point de contrôle finalisé vérifié localement du nœud, son époque ou hauteur et l'heure, la source de temps actuelle, ainsi que toute restauration de base de données. Calculez l'âge en utilisant les règles et l'état en direct du protocole, et non une estimation calendaire mémorisée. Pour Ethereum, le guide de Phase 0 teste `current_epoch <= ws_state_epoch + ws_period` ; Electra modifie le calcul de la période pour dépendre du solde actif total et du roulement des soldes. Si la confiance a expiré, obtenez une nouvelle ancre hors ligne plutôt que d'insister contre des pairs non fiables.

### 3. Acquérir et corroborer le point de contrôle

Obtenez le même point de contrôle à partir de canaux administrés et approvisionnés de manière indépendante : par exemple, un nœud que vous exploitez, un autre opérateur, plusieurs équipes clientes et des explorateurs avec une infrastructure distincte. Enregistrez chaque source, l'heure de récupération, le réseau, `epoch` et la racine complète. Cinq URL qui copient une seule source en amont constituent un seul domaine de défaillance. Une majorité de réponses simple ne remplace pas l'indépendance des sources, le transport authentifié ou la revue sociale des incidents.

### 4. Lier chaque champ de point de contrôle

Vérifiez le réseau et l'identité genesis avant la valeur du point de contrôle. Conservez la racine complète sans troncature et associez-la à l'époque ou à la hauteur exacte, à l'état si nécessaire, à la version du fork et au temps d'acquisition. Le guide de Ethereum utilise `block_root:epoch_number` ; l'initialisation de CometBFT lie également un en-tête et un ensemble de validateurs de confiance ainsi que des paramètres de confiance. Une racine correcte attachée à la mauvaise chaîne ou hauteur n'est pas une ancre valide.

### 5. Imposer un chemin de synchronisation en mode échec fermé

Configurez le point de contrôle via l'interface documentée du client et conservez les journaux de démarrage. Pendant la synchronisation, exigez que le chemin canonique à l'époque du point de contrôle soit égal au `block_root` fourni. Le guide Ethereum exige une erreur critique descriptive et la sortie du processus lorsque l'assertion échoue. Ne jetez pas silencieusement le point de contrôle, ne revenez pas à la majorité des pairs, ne le remplacez pas par une réponse plus récente d'un pair, et ne conservez pas une signature de validateur tant que sa vue du consensus est incertaine.

### 6. Séparez les couches qui ont été vérifiées de celles qui ne l'ont pas été

Suivez séparément la confiance des points de contrôle du consensus, la vérification des blocs de balises ou du consensus, le statut des charges d'exécution, la synchronisation de l'état d'exécution, le remplissage historique et les preuves d'application. La synchronisation optimiste Ethereum permet qu'un `ExecutionPayload` d'ancrage de point de contrôle soit supposé `VALID` sans d'abord le donner au moteur d'exécution, tandis qu'un nœud optimiste ne doit pas accomplir de fonctions de validateur. Le remplissage des points de contrôle Lighthouse vérifie l'intégrité de la chaîne de hachage historique et les signatures des proposeurs mais ne reconstruit pas tous les états historiques par défaut.

### 7. Actualiser, surveiller et répéter la récupération

Définissez une alerte et actualisez la marge confortablement à l'intérieur de la période applicable. Surveillez la finalisation, la santé de l'horloge, le désaccord des clients, le statut `execution_optimistic`, la diversité des pairs, l'âge du point de contrôle et les lacunes de remplissage arrière. Répétez la récupération d'une base de données supprimée, d'un point de contrôle expiré, de sources contradictoires et d'un fournisseur indisponible. Conservez des enregistrements signés des ancres et des décisions, mais ne laissez pas un point de contrôle archivé devenir un point de contrôle obsolète définitivement approuvé.

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

## Exemples travaillés

### Point de contrôle Ethereum avec marge restante

Utilisez un état illustratif dont le calcul de référence Electra applicable donne `ws_period = 3,532 epochs`. Supposons `current_epoch = 420,000` et que le point de contrôle corroboré indépendamment est `checkpoint_epoch = 418,200` :

`checkpoint_age = 420,000 - 418,200 = 1,800 epochs`.

Le test de récence du guide est `420,000 <= 418,200 + 3,532`, donc le point de contrôle est dans la période. À `32 slots * 12 seconds = 6.4 minutes per epoch`, son âge est `1,800 * 6.4 / 1,440 = 8 days`. La marge restante est `3,532 - 1,800 = 1,732 epochs`, ou `1,732 * 6.4 / 1,440 = 7.6978 days`. Cela utilise une période de tableau de référence, pas une promesse de réseau en direct ; le client doit calculer à partir du fork réel et de l'état.

### Le point de contrôle expiré n'est pas réparé par davantage de pairs

Supposons `current_epoch = 500,000`, `checkpoint_epoch = 496,000`, et le `ws_period = 3,532 epochs` applicable :

`checkpoint_age = 500,000 - 496,000 = 4,000 epochs`.

Parce que `500,000 > 496,000 + 3,532`, le point de contrôle est périmé de `4,000 - 3,532 = 468 epochs`. À 6.4 minutes par époque, cela fait `468 * 6.4 / 60 = 49.92 hours` au-delà de la limite. Télécharger la même racine expirée depuis 100 pairs ne restaure pas l'hypothèse ; l'opérateur a besoin d'un point de contrôle suffisamment récent provenant de canaux fiables et corroborés.

### Nombre de sources contre indépendance des sources

Un opérateur reçoit cinq réponses. Quatre signalent `epoch = 600,000` et une racine complète identique étiquetée `root_A`, tandis qu'une autre signale une racine complète différente étiquetée `root_B`. L'enquête montre que trois sites Web concordants font tous office de proxy pour le même nœud hébergé ; le quatrième est le propre nœud de l'opérateur. L'accord apparent est `4 / 5 = 80%`, mais il ne représente que deux lignées indépendantes. Selon une politique exigeant trois chemins administratifs et de données indépendants, le point de contrôle n'est pas encore approuvé. Un troisième opérateur indépendant confirme `root_A`, le service dissident est isolé, et le registre de provenance explique la décision.

### budget de période de confiance de style CometBFT

Considérez une chaîne configurée avec `unbonding_period = 21 days` et un `trusting_period = 14 days` sélectionné par l'opérateur, conformément à l'exigence que la période de confiance soit plus courte que la période de désengagement. Un en-tête de confiance âgé `11 days` a `14 - 11 = 3 days` de marge. Un objectif de rafraîchissement quotidien laisse une marge opérationnelle. Si le client revient après `16 days`, l'en-tête est deux jours au-delà de sa période de confiance et doit être remplacé par une nouvelle initialisation de confiance ; les formules d'époque Ethereum ne décident pas de ce cas CometBFT.

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

## Risques et échecs de révision

- **Mauvais réseau :** Une racine valide issue d'un testnet, d'un fork, d'un clone ou d'une autre genèse peut ancrer le mauvais historique.
- **Point de contrôle périmé :** Une racine hors de la période applicable ne satisfait plus l'hypothèse sur les validateurs récents.
- **Formule de période incorrecte :** Les mises à niveau du fork, les soldes, le churn, le déliement et les paramètres de sécurité peuvent modifier la limite.
- **Source unique :** Plusieurs points de terminaison peuvent partager un nœud, un compte cloud, une base de données, un fournisseur DNS ou un opérateur.
- **Distribution compromise :** Une version, un site, un paquet, une réponse DNS ou un message d'assistance malveillant peut remplacer le point de contrôle.
- **Comparaison tronquée :** Comparer uniquement un préfixe, une capture ou un identifiant formaté peut masquer une racine complète différente.
- **Champs incompatibles :** La bonne racine avec une époque, une hauteur, un état, un fork ou une chaîne erronés n'est pas le même point de contrôle.
- **Repli sur la majorité des pairs :** Un nœud éclipsé peut voir de nombreux pairs adverses ; leur nombre ne prime pas sur l'ancre de confiance.
- **Repli silencieux :** Un client ou wrapper qui ignore un point rejeté annule le contrôle fail-closed.
- **Historiques finalisés conflictuels :** Un nouveau nœud ne résout pas une panne de consensus parce que les deux branches sont marquées finalisées.
- **Erreur d'horloge :** Une heure locale incorrecte fausse les contrôles de slot, époque, âge, période de confiance et en-têtes futurs.
- **Confusion d'état optimiste :** Un bloc de consensus importé peut encore contenir une charge d'exécution non entièrement validée.
- **Tâches prématurées du validateur :** Signer en état optimiste, non synchronisé ou sur une ancre incertaine peut provoquer des votes erronés ou du slashing.
- **Confusion sur l'exhaustivité historique :** La synchronisation et le backfill peuvent omettre des états historiques même si la tête actuelle est valide.
- **Signatures de backfill invalides :** Un bloc historique lié par hachage exige encore le contrôle de signature du proposant.
- **Preuve d'exécution ou d'application insuffisante :** L'ancrage du consensus ne prouve pas des valeurs RPC arbitraires, des affirmations de contrat ou des index hors chaîne.
- **Écart de disponibilité des données :** Connaître une racine d'état ne garantit pas l'accès à chaque corps, blob, témoin ou enregistrement historique.
- **Plan de récupération expiré :** Si l'expiration est découverte pendant une panne, aucune source indépendante ne sera peut-être disponible.
- **Capture de la coordination sociale :** Gouvernance, équipes client, explorateurs, plateformes d'échange et opérateurs peuvent partager incitations ou dépendances.
- **Fausse universalité :** Un autre modèle PoS peut utiliser des hypothèses, chaînes de preuves, périodes de confiance ou garanties d'amorçage depuis la genèse différentes.

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

## Idées reçues

### Une subjectivité faible signifie-t-elle que les règles du protocole sont subjectives après le démarrage ?

Non. Le nœud accepte une ancre récente spécifique via un canal social ou de confiance, puis applique la validation déterministe et les règles de choix de fork ensuite. Les blocs qui entrent en conflit avec l’ancre sont rejetés.

### Est-ce qu'un point de contrôle finalisé est automatiquement un point de contrôle de démarrage sécurisé ?

Non. Il doit appartenir au réseau prévu et à l'histoire sociale canonique, être suffisamment récent selon les règles applicables, inclure les champs requis et provenir d'une voie fiable et corroborée. La finalité observée pour la première fois sur une histoire fournie par un attaquant n'établit pas la provenance.

### La synchronisation depuis la genèse supprime-t-elle le problème de l'attaque à longue portée ?

Pas pour un protocole dont le modèle de sécurité nécessite un point de contrôle de faible subjectivité récent. La relecture de signatures valides internes depuis la genèse n'indique pas à un nouveau nœud quelle des deux anciennes histoires finalisées la communauté a réellement suivie. D'autres protocoles peuvent fournir différentes garanties de démarrage à partir de la genèse sous des hypothèses différentes.

### La synchronisation du point de contrôle valide-t-elle toute l'exécution et l'état historiques ?

Non. Le comportement du client est stratifié et spécifique à l'implémentation. Le nœud peut faire confiance à l'ancre ou l'importer de manière optimiste, synchroniser séparément l'état d'exécution actuel, et remplir uniquement les liens de blocs et les signatures du proposeur sans reconstruire tous les états historiques.

### Un point de contrôle codé en dur peut-il être fiable pour toujours ?

Non. Un point de contrôle est lié à un réseau et c'est tout. Il peut rester utile en tant qu'enregistrement d'audit ou contrainte historique, mais un nœud dont l'hypothèse de confiance récente a expiré a besoin d'une ancre appropriée récente ou du processus de récupération prévu par ce protocole.

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

## Sujets liés

- [Finalité](/fr/crypto/finality/)
- [Règle de choix de branche](/fr/crypto/fork-choice-rule/)
- [Preuve d'enjeu](/fr/crypto/proof-of-stake/)
- [Tranchant](/fr/crypto/slashing/)
- [Client léger](/fr/crypto/light-client/)

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

## Sources

- [Subjectivité faible](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (consulté : 2026-08-19)
- [Phase 0 -- Guide Weak Subjectivity](https://ethereum.github.io/consensus-specs/specs/phase0/weak-subjectivity/) - Spécifications du consensus Ethereum (consulté : 2026-08-19)
- [Electra -- Guide Weak Subjectivity](https://ethereum.github.io/consensus-specs/electra/weak-subjectivity/) - Spécifications du consensus Ethereum (consulté : 2026-08-19)
- [Phase 0 -- Interface P2P](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Spécifications du consensus Ethereum (consulté : 2026-08-19)
- [Synchronisation optimiste](https://ethereum.github.io/consensus-specs/sync/optimistic/) - Spécifications du consensus Ethereum (consulté : 2026-08-19)
- [Synchronisation de point de contrôle](https://lighthouse-book.sigmaprime.io/advanced_checkpoint_sync.html) - Lighthouse Book (consulté : 2026-08-19)
- [Vérification du noyau CometBFT](https://docs.cometbft.com/v0.38/spec/light-client/verification/) - CometBFT (consulté : 2026-08-19)
- [Ouroboros Genesis : Blockchains Proof-of-Stake composables avec disponibilité dynamique](https://eprint.iacr.org/2018/378.pdf) - IACR Cryptology ePrint Archive (consulté : 2026-08-19)

Source: https://wiki.fcontext.com/fr/crypto/weak-subjectivity/index.mdx