
Un timestamp est une valeur numérique croissante qui indique un instant précis, généralement exprimée comme le nombre de secondes ou de millisecondes écoulées depuis « 00:00 UTC le 1er janvier 1970 ». Il s’agit d’un repère universel permettant de synchroniser et comparer le temps entre différents systèmes.
Dans la blockchain, les timestamps figurent dans les en-têtes de bloc, les détails de transaction, les journaux d’événements et les réponses d’API. Indépendants de la langue et de la localisation, ils sont parfaitement adaptés au traitement automatisé et au stockage multi-systèmes.
Les timestamps consignent le moment où un événement se produit et constituent la base de nombreux processus on-chain : plannings de déverrouillage de tokens, échéances d’enchères, horaires de snapshots, dates d’expiration de staking, génération des carnets d’ordres et des graphiques en chandeliers (K-lines).
Par exemple, une annonce de projet peut préciser l’« heure de déverrouillage » d’un token au format timestamp. En consultant le bloc et l’événement correspondants on-chain, il est possible de retrouver la fenêtre exacte de survenue. Pour l’analyse de marché, les horaires d’ouverture et de clôture des K-lines reposent sur les timestamps, ce qui facilite la concordance des données entre plateformes.
Sur les blockchains publiques, le timestamp d’un bloc est inscrit dans l’en-tête par le producteur du bloc—mineur ou validateur —et les règles de consensus encadrent la marge de déviation admise par rapport à l’horloge réseau. Sur Ethereum, par exemple, « block.timestamp » indique l’heure du bloc courant et peut être utilisée par les smart contracts.
Les systèmes hors chaîne génèrent aussi des timestamps, comme les horaires serveur des ordres sur les plateformes de trading ou les temps d’échantillonnage des flux de données. Ceux-ci sont généralement alignés sur l’UTC mais leur précision (secondes ou millisecondes) peut varier ; il est donc essentiel de vérifier l’unité utilisée.
Un timestamp désigne un instant précis, tandis que la hauteur de bloc correspond au numéro d’ordre d’un bloc. Bien qu’associés, ils ne sont pas équivalents : chaque hauteur de bloc possède un timestamp, mais l’intervalle entre deux blocs n’est pas constant.
Pour analyser des déverrouillages ou des snapshots, choisir la hauteur de bloc comme référence implique que le timing dépendra de la cadence de production des blocs ; s’appuyer sur les timestamps nécessite de prendre en compte les variations et tolérances du temps de bloc. Le choix dépend du niveau de précision temporelle requis par votre application.
La procédure consiste à : identifier l’unité (secondes ou millisecondes), interpréter en UTC, puis ajouter le décalage horaire (China Standard Time = UTC+8).
Étape 1 : Déterminer l’unité. Sur blockchain, « block.timestamp » est généralement en secondes ; certaines API utilisent les millisecondes.
Étape 2 : Si le timestamp est en millisecondes, divisez par 1 000 pour obtenir des secondes ; s’il est déjà en secondes, conservez-le tel quel.
Étape 3 : Convertissez les secondes en date-heure UTC, puis ajoutez 8 heures pour obtenir l’heure de Pékin. La plupart des block explorers affichent l’UTC par défaut : il suffit d’ajouter 8 heures pour obtenir l’heure locale.
Étape 4 : Vérifiez les cas particuliers. Il n’est pas nécessaire de gérer manuellement les changements de jour, de mois ou les secondes intercalaires : les systèmes courants comptent le temps en secondes UTC, et l’heure d’été n’a pas d’impact pour un usage quotidien.
Les principaux risques sont la « manipulabilité limitée », l’« imprécision » et la « dérive d’horloge entre nœuds ». Sur des blockchains comme Ethereum, les producteurs de blocs peuvent ajuster légèrement le block.timestamp dans les limites du consensus.
En conséquence, l’utilisation de timestamps pour des coupures strictes (par exemple, clôture d’enchères à la seconde près) peut exposer à une manipulation en limite. Les approches plus robustes incluent :
Étape 1 : Utiliser « >= un certain timestamp avec une marge de sécurité » plutôt que « == un certain timestamp » dans la logique sensible au temps.
Étape 2 : Lorsque possible, estimer les fenêtres à partir de la hauteur de bloc et du temps moyen de bloc, ou prévoir une période tampon.
Étape 3 : Ne pas s’appuyer uniquement sur les timestamps pour l’aléa ou les contrôles de sécurité critiques ; privilégier des sources aléatoires vérifiables ou des oracles.
Étape 4 : Dans les annonces publiques, indiquer des « fenêtres attendues » plutôt que des horaires à la seconde pour limiter les contestations.
Les différences tiennent principalement aux règles de génération et à la cadence de production des blocs. Par exemple, le temps moyen d’un bloc Ethereum est d’environ 12 secondes (données publiques Ethereum et observations clients en 2024), contre environ 10 minutes pour Bitcoin (documentation Bitcoin Core, constance historique). En raison de l’aléa de production, les timestamps n’évoluent pas de façon strictement linéaire.
Bitcoin applique la règle « Median Time Past » (MTP), basée sur la médiane des timestamps des blocs récents, afin de limiter la manipulation par un mineur isolé. Les chaînes à haut débit comme Solana peuvent combiner des sources temporelles externes avec des mécanismes de vérification pour garantir la progression temporelle. Il est recommandé de consulter la documentation développeur et les règles de consensus propres à chaque blockchain.
Sur les plateformes de trading, les timestamps sont présents dans les historiques d’ordres, les transactions, les journaux de fonds et les données de marché. Par exemple, sur Gate, les interfaces affichent « heure de transaction » et « heure de placement d’ordre », tandis que les systèmes et API stockent généralement les horaires en UTC avec une précision à la milliseconde.
Si vous exploitez les API K-line ou d’ordres de Gate pour du trading quantitatif, vérifiez les unités et les labels de fuseau horaire :
Étape 1 : Consultez la documentation API pour déterminer si le « timestamp » est en millisecondes.
Étape 2 : Normalisez tous les horaires en UTC dans votre code avant de les convertir dans votre fuseau local pour l’affichage si nécessaire.
Étape 3 : Pour rapprocher plusieurs sources, utilisez une clé composite « timestamp + paire de trading + direction » plutôt qu’un simple rapprochement sur la chaîne horaire locale.
La fiabilité dépend de la possibilité de recouper on-chain. Utilisez un block explorer pour faire correspondre les timestamps annoncés avec les événements on-chain correspondants.
Étape 1 : Repérez le timestamp ou la hauteur de bloc dans l’annonce.
Étape 2 : Ouvrez l’explorer de la chaîne concernée, localisez le bloc ou la transaction, et consultez le « Block Time/Date (UTC) ».
Étape 3 : Si l’annonce indique l’heure de Pékin, convertissez-la en UTC et vérifiez si l’écart reste dans la tolérance de production des blocs.
Étape 4 : Pour les événements majeurs (déverrouillage de tokens, etc.), vérifiez également les logs d’événements du contrat (Transfer, Unlock…) pour confirmer la survenue dans la fenêtre annoncée.
Étape 5 : En cas d’écarts notables, vérifiez si l’annonce mentionnait une « fenêtre estimée » ou si la congestion réseau a causé des retards.
Les timestamps sont le point de jonction entre le temps réel et les événements on-chain. Maîtriser leurs unités (secondes/millisecondes), fuseaux horaires (UTC/local), sources (blockchain/serveur) et contraintes propres à chaque blockchain est essentiel pour la conception de smart contracts, l’analyse de données et la gestion des risques.
Parcours conseillé : commencez par les timestamps UNIX et l’UTC, puis étudiez « block.timestamp » sur Ethereum et les règles de timestamp sur Bitcoin. Enfin, exercez-vous à convertir et aligner les champs de données via les API de plateformes réelles (ex : Gate). Pour les opérations sensibles impliquant des fonds, implémentez toujours des marges de sécurité et des étapes de validation autour de la logique des timestamps pour limiter les risques aux frontières.
La longueur dépend de la précision. Un nombre à 10 chiffres correspond à un timestamp Unix à la seconde (ex : 1 704 067 200 pour le 1er janvier 2024). Un nombre à 13 chiffres indique une précision à la milliseconde (ex : 1 704 067 200 000). Dans la blockchain, la plupart des timestamps de transaction comportent 10 chiffres (secondes), tandis que les plateformes de trading à haute fréquence utilisent les millisecondes pour une granularité accrue.
La longueur est un bon indicateur : 10 chiffres correspondent généralement à une précision à la seconde (soit environ 950 000 000 à 990 000 000, couvrant les années 1973 à 2286), alors que 13 chiffres indiquent la milliseconde (environ 1 000 fois plus grand). Utilisez les outils de conversion des plateformes comme Gate pour obtenir instantanément la date et l’heure correspondantes, sans calcul manuel.
Il est extrêmement rare que deux blocs partagent strictement le même timestamp. Même si deux transactions surviennent à la même seconde, les blockchains les différencient par la hauteur de bloc, l’ordre des transactions ou d’autres mécanismes. Certaines chaînes autorisent plusieurs blocs par seconde mais s’appuient sur des protocoles de consensus pour garantir l’ordre chronologique et l’immutabilité.
Cela s’explique par le fait que chaque plateforme enregistre des étapes distinctes d’un événement. Des exchanges comme Gate peuvent noter l’heure de soumission locale de l’ordre, l’envoi on-chain, ou la confirmation du bloc. Le timestamp de référence est celui fixé par les mineurs/validateurs lors de l’inclusion on-chain ; des écarts peuvent apparaître à cause des paramètres de fuseau horaire serveur ou de délais de synchronisation.
Les timestamps sont fixés par les mineurs ou validateurs et leur altération malveillante est difficile—toute tentative serait rapidement détectée par les autres nœuds. Toutefois, une manipulation pourrait perturber la logique des smart contracts sensibles au temps (par exemple, un airdrop limité dans le temps pourrait échouer). Il est donc recommandé de ne pas s’appuyer exclusivement sur les timestamps pour les décisions critiques de sécurité, mais de les compléter par d’autres mécanismes de vérification, comme la hauteur de bloc, afin d’assurer l’authenticité des transactions.


