---
title: "Preuve de l'historique : ordre enregistré, ticks, emplacements et limites de consensus"
description: "Proof of History est l'horloge à chaîne de hachage séquentielle de Solana : elle rend vérifiables l'ordre enregistré et les décomptes de calcul d'un producteur, mais ne prouve à elle seule ni l'heure réelle, ni l'équité de l'ordre d'arrivée, ni le choix du fork, ni la 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.

# Preuve de l'historique : ordre enregistré, ticks, emplacements et limites de consensus

> À 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 preuve d'historique, ou PoH, est l'horloge cryptographique et la structure de données de classement du grand livre de Solana. Un producteur applique à plusieurs reprises une fonction de hachage afin que chaque sortie dépende de la sortie précédente, enregistre périodiquement les comptes et les états et mélange les données dérivées des transactions dans la chaîne. Un vérificateur peut recalculer ces transitions et confirmer l'ordre enregistré par cette chaîne particulière.

PoH n'est pas un algorithme de consensus autonome. Il ne choisit pas le fork canonique, ne fournit pas d'accord pondéré en fonction des enjeux, ne finalise pas les blocs ou ne prouve pas qu'une transaction a atteint le réseau à un moment civil particulier. Solana combine l'horloge avec les dirigeants planifiés, l'exécution des transactions, les votes des validateurs, le choix du fork et les verrouillages de style Tower BFT. Deux forks peuvent chacun contenir des séquences PoH valides en interne ; les règles de consensus déterminent l'historique suivi par le réseau.

La portée de cette garantie est limitée. Si une entrée engage les données d après l'état h2, l'état ultérieur h3 = H(h2 || d) ne peut pas être calculé sans cet engagement. Cela montre que le producteur connaissait d avant h3 et fixe sa position enregistrée par rapport aux sorties ultérieures. Cela ne prouve ni l'heure de réception de chaque validateur, ni l'équité de l'ordre d'arrivée, ni la véracité des données externes, ni le statut canonique de l'entrée.

La génération est séquentielle car l'entrée suivante n'est connue que lorsque le hachage précédent existe. Les états limites publiés permettent aux vérificateurs de rejouer des segments délimités séparés en parallèle, mais le travail de hachage global demeure. Pour cette raison, PoH est souvent comparé à une fonction de retard vérifiable, tandis que la propre explication de Solana, Tower BFT, l'appelle une utilisation vague de ce terme ; un VDF formel dispose normalement d'une interface d'évaluation et de vérification dont la vérification est efficace par rapport à l'évaluation séquentielle.

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

## Comment analyser la preuve d'historique

1. **Corriger le contexte réseau et logiciel.** Réseau d'enregistrement, hachage de genèse, emplacement, époque, Agave ou autre version client, et le temps d'observation. Lire les valeurs actives telles que hashes_per_tick, ticks_per_slot et ns_per_slot ; n'importez pas de constantes à partir d'un ancien article ou d'un autre cluster.
2. **Reconstruisez la chaîne de hachage.** Commencez à partir d'un état de prédécesseur approuvé et vérifiez le num_hashes de chaque entrée, le hachage et la liste de transactions résultants. Dans l'implémentation d'entrée de Agave, un identifiant d'entrée dépend de l'entrée précédente et, lorsque des transactions sont présentes, d'un hachage dérivé de leurs signatures.
3. **Validez les ticks et le placement des emplacements.** Vérifiez les entrées de tick, le nombre de hachages attendu, la hauteur des ticks et la hauteur maximale des ticks par rapport aux règles de la banque et de l'enregistreur. L'enregistreur mappe la hauteur des graduations dans une fente à l'aide du ticks_per_slot configuré ; les slots sont des intervalles de protocole, et non une preuve indépendante d'une horloge externe.
4. **Distinguer l'inclusion de l'arrivée.** Un engagement prouve que l'entrée était connue au plus tard lors de son insertion dans cette séquence. Pour revendiquer une limite inférieure, identifiez une référence arrière signée à un état PoH antérieur. Aucune des deux limites ne prouve l'ordre global de première visualisation, l'équité du pool de mémoire ou un horodatage UTC fiable.
5. **Séparez la génération de la vérification.** Mesurez la production séquentielle sur une chaîne de dépendances, puis mesurez la relecture à l'aide des limites de segments authentifiés et des cœurs disponibles. Signalez les hachages totaux, la latence du chemin critique, le travail global du vérificateur et les hypothèses relatives aux données limites plutôt que de dire simplement que la vérification est « rapide ».
6. **Tracez le chemin du consensus.** Identifiez le leader prévu, l'état de la banque, les votes, les lock-out, la règle de choix, l'état enraciné ou finalisé et le niveau d'engagement. Une chaîne PoH valide peut toujours appartenir à un fork perdant, et un compteur plus long ne constitue pas à lui seul un certificat de consensus.
7. **Cas contradictoires et opérationnels de stress.** Équivocation du leader du test, omission et réorganisation des transactions, emplacements ignorés, partitions, matériel plus rapide ou mal calibré, nombre de ticks invalides, relecture retardée, indisponibilité du grand livre, divergence des clients et contrôle corrélé de l'opérateur ou de l'infrastructure.

Le résultat de l'examen doit distinguer quatre affirmations : la validité de la séquence, l'heure du protocole configuré, l'état du consensus et l'heure externe. Indiquez quelles données de hachage et de grand livre de départ ont été fiables, quels hachages ont été recalculés, quelles preuves de vote ou d'engagement ont été vérifiées et quelles observations provenaient d'horloges locales ou de services tiers.

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

## Exemples pratiques

### 1. L'insertion de données corrige une position enregistrée

Considérez h1 = H(h0), puis h2 = H(h1). Un producteur insère un engagement dérivé de la transaction d et calcule h3 = H(h2 || d), suivi de h4 = H(h3). Quiconque rejoue les mêmes opérations peut vérifier que la chaîne enregistrée engage d entre h2 et h3, et que h4 dépend du résultat.

L'énoncé de la limite supérieure est étroit : le producteur connaissait d avant de calculer h3. Si la transaction signée elle-même fait référence à h1, un vérificateur peut également démontrer qu'elle a été formée après avoir pris connaissance de cet état antérieur, sous réserve de contrôles de signature et de provenance. Sans une telle référence arrière, PoH ne fournit à lui seul aucune limite inférieure. Aucun des deux cas ne prouve quand un autre nœud a reçu la transaction pour la première fois.

### 2. La relecture de segment réduit la latence, pas le travail global

Supposons qu'un intervalle enregistré contienne 1 000 000 de hachages et que des points de contrôle authentifiés le divisent en 10 segments de 100 000 hachages. Avec suffisamment de cœurs, dix segments peuvent être relus simultanément, de sorte que la latence de vérification de l'horloge murale peut approcher la durée d'un segment plus la surcharge.

Les vérificateurs exécutent collectivement toujours 1 000 000 de hachages ; les points de contrôle exposent des états de départ indépendants mais ne transforment pas la chaîne en une preuve succincte. Les performances dépendent du matériel, de la planification, du mouvement de la mémoire et de la confiance dans les limites. C'est pourquoi une relecture parallèle de PoH ne doit pas automatiquement être décrite comme l'algorithme de vérification efficace de chaque construction formelle de VDF.

### 3. L'arithmétique des ticks et des emplacements dépend de la configuration

Supposons une configuration illustrative avec hashes_per_tick = 100,000 et ticks_per_slot = 8. Un emplacement entièrement haché contient alors des hachages 100,000 * 8 = 800,000, avec des limites de ticks après chaque intervalle configuré. La modification de l'un ou l'autre paramètre modifie le mappage ; cet exemple n'est pas une constante actuelle du réseau principal.

Agave prend aussi en charge des configurations que cette multiplication simplifiée ne décrit pas. Un réviseur doit lire les champs réels de Bank et valider les entrées selon les règles du logiciel client. La conversion d'un slot ou d'un décompte en secondes dépend aussi de l'étalonnage de la durée cible et de l'exécution observée, pas seulement de la vérification cryptographique.

### 4. L'ordre enregistré n'est pas un ordre d'arrivée ou une finalité

Supposons que la transaction A atteigne un leader avant la transaction B, mais que le leader enregistre B près de 300 000 et A près de 450 000. Un PoH valide prouve que B précède A dans cette séquence produite. Cela ne prouve pas que B est arrivé le premier, que l'ordre était juste ou qu'un autre leader a observé le même ordre.

Supposons maintenant qu'une partition produise un fork X et un fork Y, chacun avec une séquence valide. La validation PoH peut rejeter les entrées mal formées sur l'un ou l'autre fork, mais elle ne sélectionne pas X ou Y. Le calendrier des leaders, les votes pondérés en fonction des enjeux, les lock-out, le choix du fork et le niveau d'engagement demandé déterminent le résultat du consensus ; les applications ne doivent pas remplacer un décompte PoH comme preuve de confirmation ou de caractère définitif.

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

## Risques et échecs d'examen

### Erreurs cryptographiques et de synchronisation

- Appeler PoH à une horloge murale de confiance ou revendiquer un décompte de hachage prouve indépendamment un horodatage UTC.
- Dire que l'inclusion des transactions prouve le temps de réception à l'échelle du réseau, l'ordre de première visualisation ou la vérité des données externes.
- En supposant que la génération séquentielle empêche un producteur de retenir, d'omettre ou de choisir quand insérer des données connues.
- Traiter la résistance aux collisions seule comme une limite complète sur la vitesse du matériel, la dérive d'étalonnage ou la variance de mise en œuvre.
- Décrire la relecture de segments parallèles comme zéro travail ou comme preuve succincte sans compter les hachages agrégés.
- Appeler PoH un VDF formel sans indiquer la construction, l'interface de preuve et les hypothèses de vérification comparées.
- Faire confiance aux limites des points de contrôle, aux hachages prédécesseurs ou aux segments de grand livre téléchargés sans authentifier leur provenance.

### Consensus et protocole erreurs

- Appeler le consensus PoH, la preuve d'enjeu, le Tower BFT, l'élection du leader, le choix du fork et la finalité du même mécanisme.
- En supposant que la séquence valide avec le décompte le plus élevé doit être canonique sans examiner les votes et l'état du choix du fork.
- Traiter une entrée relue localement comme confirmée et enracinée. ou finalisé sans vérifier la sémantique d'engagement demandée.
- Utilisation des valeurs historiques de hashes_per_tick, ticks_per_slot ou de durée d'emplacement comme constantes actuelles universelles.
- Ignorer les emplacements ignorés, la rotation des leaders, les partitions, les équivocations et les différences de version client lors de la reconstruction de l'ordre.
- Comparaison des décomptes de des fourches ou des états de départ sans rapport comme s'ils appartenaient à une séquence authentifiée.
- En supposant que le blockhash récent d'une transaction est simplement un horodatage d'horloge murale plutôt qu'un contexte de validité de protocole.

### Erreurs d'opérations, de performances et de contrôle

- Analyser uniquement la génération de hachage en ignorant l'exécution, la vérification de signature, la relecture, la bande passante et le stockage.
- Équilibrer le parallélisme théorique des segments avec le rattrapage observé du validateur sous CPU, I/O et les conflits de mémoire.
- Ignorer les échecs de validation des ticks, les blocages de l'enregistreur, les retards bancaires, les écarts du grand livre, la confiance des instantanés et l'état corrompu.
- Compter les identités des validateurs comme indépendantes lorsque le client, l'hébergement, le réseau, l'infrastructure leader ou le contrôle sont partagés.
- En supposant qu'un matériel plus rapide supprime la latence du réseau, la perte de paquets, la censure, le déni de service ou le risque de concentration des enjeux.
- Présenter une durée de créneau cible, une estimation de débit ou un ancien benchmark comme garantie de niveau de service.

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

## Idées fausses courantes

- **PoH est l'algorithme de consensus complet de Solana.** PoH fournit une séquence enregistrée vérifiable ; le vote du validateur, les verrouillages, le choix de fork et d'autres règles de consensus déterminent l'historique suivi par le réseau.
- **PoH prouve l'heure exacte et réelle de chaque transaction.** Il prouve la dépendance et le décompte au sein d'une séquence authentifiée ; le mappage de cette séquence à l'heure civile nécessite une configuration et des observations externes.
- **PoH garantit un ordre équitable des transactions.** Un leader peut sélectionner, retarder, réorganiser ou omettre des entrées dans le cadre de contraintes de protocole et de ressources ; PoH rend l'ordre enregistré résultant vérifiable.
- **PoH est une extraction de preuve de travail avec un autre nom.** Les deux utilisent le hachage, mais le rôle principal de PoH est une horloge séquentielle, pas une course parallèle ouverte dont le travail gagnant choisit le chaîne.
- **Toute séquence PoH valide est finale.** Les forks concurrents peuvent chacun être valides en interne ; la confirmation et le caractère définitif nécessitent des preuves consensuelles du réseau.

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

## Sujets connexes

- [Mécanismes de consensus](/fr/crypto/consensus-mechanism/)
- [Preuve d'enjeu](/fr/crypto/proof-of-stake/)
- [Validateurs](/fr/crypto/validator/)
- [Règles de choix du fork](/fr/crypto/fork-choice-rule/)
- [Temps de blocage](/fr/crypto/block-time/)

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

## Sources

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté : 2026-08-19)
- [Solana: A New Architecture for a High Performance Blockchain](https://solana.com/solana-whitepaper.pdf) - Solana (consulté : 2026-08-19)
- [Tower BFT: Solana's High Performance Implementation of PBFT](https://solana.com/news/tower-bft--solana-s-high-performance-implementation-of-pbft) - Solana (consulté : 2026-08-19)
- [Agave Entry Module](https://github.com/anza-xyz/agave/blob/master/entry/src/entry.rs) - Anza (consulté : 2026-08-19)
- [Agave Proof-of-History Recorder](https://github.com/anza-xyz/agave/blob/master/poh/src/poh_recorder.rs) - Anza (consulté : 2026-08-19)
- [Agave Bank Runtime](https://github.com/anza-xyz/agave/blob/master/runtime/src/bank.rs) - Anza (consulté : 2026-08-19)
- [Transaction Confirmation and Expiration](https://solana.com/developers/cookbook/transactions/confirmation) - Solana (consulté : 2026-08-19)
- [Verifiable Delay Functions](https://eprint.iacr.org/2018/601) - Archive ePrint de cryptologie IACR (consulté : 2026-08-19)

Source: https://wiki.fcontext.com/fr/crypto/proof-of-history/index.mdx