Bits de version

Un bit de version représente un soft fork en attente, comptabilisé sur une fenêtre fixe de blocs. Le BIP-9 propose les bits 0 à 28, et un déploiement se verrouille une fois que 1 916 blocs sur une période de 2 016 blocs ont activé son bit, ou échoue à un délai suggéré d'un an. Lire ces signaux permet de savoir des mois à l'avance si une fonctionnalité attendue par votre portefeuille est en train de devenir une règle du réseau.

Comment cela fonctionne

Les bits de version fonctionnent comme un automate à cinq états que chaque nœud calcule lui-même, une fois par période de réajustement, pour chaque déploiement qu'il connaît.

Ces états sont DEFINED, STARTED, LOCKED_IN, ACTIVE et FAILED. Chaque bloc à l'intérieur d'une période de réajustement de 2 016 blocs partage un même état, de sorte qu'une transition ne peut se produire qu'à une hauteur qui est un multiple de 2 016. Un déploiement quitte DEFINED pour STARTED lorsque la médiane des horodatages passés du bloc précédent dépasse l'heure de début configurée, la médiane des horodatages passés étant la médiane des horodatages d'un bloc et de ses dix prédécesseurs.

Une fois STARTED, un nœud remonte exactement 2 016 ancêtres et compte les blocs dont les trois bits de version supérieurs valent 001 et dont le bit de déploiement est activé. Tout le reste compte pour zéro, de sorte qu'un mineur utilisant un autre schéma de version ne peut pas signaler par accident. Le réseau principal en exige 1 916, le réseau de test 1 512. Si la barre n'est pas atteinte avant que la médiane des horodatages passés ne dépasse le délai, le déploiement passe définitivement à FAILED. Le BIP-9 suggère de fixer ce délai à 31 536 000 secondes, soit un an, après l'heure de début, afin qu'une proposition bloquée libère son bit plutôt que de bloquer la file indéfiniment.

Un détail surprend les gens. L'état d'un bloc ne dépend jamais de son propre champ de version, seulement de celui de ses ancêtres, de sorte qu'un mineur ne peut pas voter pour une règle et voir ce vote engager le bloc qui le porte. Fixer les trois bits supérieurs à 001 fixe aussi la version d'un bloc de signalement dans la plage 0x20000000 à 0x3FFFFFFF, laissant les motifs 010 et 011 libres pour tout mécanisme qui finira par remplacer les bits de version.

Les bits sont recyclés plutôt que consommés. Une fois qu'un déploiement est activé ou a expiré, son bit peut porter une proposition ultérieure, après une pause de jachère que le BIP-9 recommande afin que les logiciels défectueux soient détectés d'abord. La spécification demande aussi aux nœuds de suivre les bits qu'ils ne reconnaissent pas et d'avertir clairement lorsqu'un déploiement inconnu se verrouille, ce qui est la façon dont un logiciel non mis à jour vous avertit qu'une règle qu'il ne peut pas appliquer approche.

Où le voit-on

Deux déploiements ont tourné sur le réseau principal de bitcoin selon les paramètres du BIP-9, et la liste des déploiements de ce BIP les répertorie tous les deux.

Le premier, nommé csv, a pris le bit 0 avec une heure de début au 2016-05-01 et une expiration au 2017-05-01, et est devenu actif au bloc 419 328. Il regroupait les BIP-68, BIP-112 et BIP-113, trois des changements que le BIP-9 liste comme rendant invalides des transactions auparavant valides. Le second, segwit, a pris le bit 1 avec une fenêtre allant du 2016-11-15 au 2017-11-15, et est devenu actif au bloc 481 824, dans les délais d'une échéance qu'il aurait pu manquer.

Le schéma est aussi visible dans la plomberie du minage. Le BIP-9 a étendu l'appel getblocktemplate avec un tableau rules nommant les déploiements déjà actifs, un objet vbavailable associant le nom de chaque déploiement en attente à son bit, et un masque facultatif vbrequired des bits exigés par le serveur. Un pool lit ces clés pour décider quoi signaler, ce qui transforme une version publiée en pourcentage de suivi.

Bits de version vs bloc de version 2

Un bloc de version 2 porte un compteur dans le champ de version ; les bits de version portent un vecteur de bits dans les mêmes quatre octets. Sous le BIP-34, le champ était comparé comme un entier, de sorte qu'une seule mise à niveau pouvait être en cours à la fois et que chaque succès consumait définitivement des valeurs qu'un bloc valide pouvait utiliser. Le BIP-9 chiffre la facture : après les BIP-34, BIP-66 et BIP-65, il ne restait que 0x7FFFFFFB valeurs de version, ce qui plafonne tout schéma à vecteur de bits à 30 déploiements indépendants. Fixer plutôt les trois bits supérieurs a transformé ce qui restait en 29 voies qui fonctionnent en parallèle et peuvent être réutilisées.