Timechain / Blockchain

Imaginez un historique comptable public dont des milliers d’ordinateurs peuvent vérifier chaque nouvelle page de façon indépendante. Une page correspond à un bloc. Elle contient un ensemble de transactions et une référence au bloc précédent ; les pages ont donc un ordre défini et ne peuvent pas être mélangées à volonté. La Timechain est cette suite complète et reliée, du premier bloc jusqu’à l’extrémité actuelle. Elle ne dit pas combien de bitcoins possède chaque personne nommément identifiée : elle conserve l’historique des transactions à partir duquel les nœuds déterminent les sorties de transaction encore non dépensées. Ce n’est pas non plus le serveur d’une entreprise. Tout Full Node (un nœud qui vérifie lui-même les transactions et les règles du réseau) peut en télécharger une copie et la vérifier. [1] [3]

Dans le contexte de Bitcoin, les deux termes désignent le même historique de blocs. Le code d’avant-lancement conservé, daté de novembre 2008, utilisait timechain dans des commentaires et des noms de variables ou de fonctions. Le whitepaper parle plutôt d’horodatage, de chaîne de blocs et de chaîne de Proof of Work ; le mot exact timechain n’y figure pas. Blockchain est ensuite devenu le terme courant dans le monde entier. Aujourd’hui, il sert aussi d’étiquette générale pour d’autres réseaux et bases de données, tandis que la Timechain de Bitcoin est la chaîne propre à Bitcoin. Les deux mots du titre ne nomment donc pas deux protocoles : ils conservent le nom historique à côté du terme aujourd’hui le plus répandu. [2] [1] [8]

Une signature numérique peut prouver qu’une transaction a été autorisée par le détenteur de la clé requise. À elle seule, elle n’empêche pas quelqu’un de signer deux transactions incompatibles qui tentent de dépenser la même sortie non dépensée d’une transaction antérieure, appelée UTXO. Un nœud peut recevoir d’abord le paiement destiné à un commerçant, tandis qu’un autre reçoit d’abord le renvoi de la même valeur vers l’expéditeur. Le réseau a donc besoin d’un historique commun qui détermine quelle dépense a été confirmée et laquelle ne peut plus être valide. Les blocs donnent aux transactions une place vérifiable dans cet ordre. Ils ne prouvent pas quel message a été créé en premier selon l’heure humaine ou le temps du réseau : les nœuds ont pu voir les transactions non confirmées dans des ordres différents. [1]

Le Block Header contient les données essentielles d’un bloc. Il comprend notamment le hash de l’en-tête précédent et le Merkle Root, qui réunit les identifiants des transactions du bloc en un hash. Un hash ressemble à une empreinte numérique : une modification minime des données produit un résultat différent. Modifier une ancienne transaction changerait le Merkle Root, le hash de ce bloc et la référence enregistrée par le bloc suivant. La modification ne resterait pas une simple ligne altérée ; elle briserait toute la suite. Un hash ne prouve pas à lui seul que les transactions respectent les règles. Les nœuds doivent aussi valider les transactions et chaque bloc doit satisfaire le Proof of Work requis. [3] [1]

Un nœud n’accepte pas une branche uniquement parce qu’elle est plus longue ou soutenue par un grand mineur. Il vérifie d’abord les règles : Proof of Work, liens avec les blocs précédents, récompense autorisée, transactions, conditions de dépense et absence de fonds déjà dépensés parmi ceux référencés par les entrées. Une branche invalide le reste, quelle que soit la puissance de calcul de son auteur. Ce n’est qu’entre candidats valides que le nœud choisit la chaîne ayant le plus de travail cumulé. Il est donc plus exact de parler de la branche valide ayant le plus de travail que de la simple « chaîne la plus longue ». Le champ chainwork estime le nombre attendu de hashes nécessaire pour produire la chaîne à la difficulté de chaque bloc ; il ne compte pas les essais réellement effectués par les mineurs. [4] [5] [6]

Le Proof of Work coûte du temps, de l’électricité et de la puissance de calcul, alors que son résultat se vérifie rapidement. Quiconque modifierait un ancien bloc devrait produire pour lui un nouveau Proof of Work valide, relier de nouveau tous les blocs suivants et continuer à rattraper le travail que la branche honnête ajoute sans cesse. Plus un bloc est enfoui sous l’extrémité, plus l’historique suivi dispose d’avance. Ce n’est pas une promesse mathématique que le passé ne changera jamais. C’est une défense économique et probabiliste : chaque bloc supplémentaire rend généralement une réécriture réussie beaucoup plus coûteuse. Un attaquant ne peut pas non plus insérer n’importe quel paiement invalide ni créer trop de bitcoins dans la branche de remplacement, car les autres nœuds rejetteraient le bloc. [1] [4]

Un mineur place un timestamp dans le Block Header. Les règles de consensus laissent une certaine marge ; la valeur time ne prouve donc pas exactement quand un bloc ou une transaction donnée a été créé. Le timestamp d’un bloc ne doit même pas nécessairement être supérieur à celui de son prédécesseur direct. Pour certaines règles, Bitcoin utilise donc Median Time Past : la médiane des timestamps des 11 blocs précédents. La médiane s’obtient en triant ces horodatages et en prenant la valeur du milieu. Elle progresse plus régulièrement que les valeurs individuelles. L’intervalle moyen de dix minutes entre les blocs n’est pas non plus un horaire. Deux blocs peuvent arriver presque ensemble, puis le suivant beaucoup plus tard. La hauteur donne une position exacte dans la chaîne, pas une heure exacte dans le calendrier. [4] [7]

Deux mineurs peuvent trouver presque au même moment deux blocs valides différents à la même hauteur. Certains nœuds voient une branche en premier, d’autres l’autre. Lorsque le Proof of Work ultérieur crée un écart entre ces branches valides, les nœuds passent à celle qui cumule le plus de travail. Ce changement s’appelle un Reorg. Les transactions du bloc déconnecté peuvent être confirmées dans la nouvelle branche, revenir dans le Mempool ou devenir invalides si le nouvel historique confirme une dépense incompatible. L’inclusion dans un bloc constitue la première confirmation ; chaque bloc ajouté au-dessus en apporte une autre. Il n’existe pas de nombre magique universel pour tous les paiements. Le niveau de confiance approprié dépend de la valeur, du risque et de la possibilité d’attendre. [1] [3]

Bitcoin permet de créer une transaction qui ne peut être confirmée qu’à partir d’une certaine hauteur de bloc ou après un temps donné. Un Timelock n’ordonne pas l’exécution automatique de la transaction à cette minute. Il fixe seulement le premier point à partir duquel un bloc valide peut l’inclure. Pour un nLockTime fondé sur le temps, BIP 113 utilise le Median Time Past du bloc précédent plutôt que le timestamp facilement décalable du bloc en cours de création. La condition repose ainsi sur l’historique de plusieurs blocs. Même une fois satisfaite, la transaction doit être diffusée, acceptée par les nœuds et choisie par un mineur ; son inclusion dans un bloc précis n’est pas garantie. [7] [4]

RPC est une interface permettant d’envoyer des commandes au nœud et de lire ses réponses. Un Full Node n’a pas à croire un explorateur public lorsqu’il affirme qu’un bloc ou une transaction appartient à l’historique actuel. Pour un hash donné, le RPC getblock peut afficher height, le nombre de confirmations, Merkle Root, time, mediantime, le hash précédent, la difficulté et chainwork. Chaque champ répond à une question différente : height indique la position ; previousblockhash montre l’ascendance ; confirmations mesure la profondeur sous l’extrémité actuelle ; time est la valeur de l’en-tête ; mediantime est une médiane ; chainwork représente le travail attendu cumulé. Aucun nombre ne suffit isolément. La Timechain permet justement au nœud de vérifier ensemble leurs relations et toutes les règles de consensus. [6] [4]