Versions et mises à jour

ZooBC change de logiciel sans changer de chaîne. Les nouvelles versions sont annoncées sur la chaîne elle-même, chaque nœud les installe par un programme de mise à jour que son propriétaire contrôle, et les nouvelles règles de consensus ne s’activent qu’une fois que les deux tiers des producteurs les exécutent déjà. Personne ne peut pousser du logiciel sur un nœud, et une nouvelle version n’exige jamais une nouvelle chaîne.

Le registre des versions

L’autorité de publication, une clé désignée dans la genèse de la chaîne, enregistre chaque version avec RegisterRelease (type 32) : un libellé de version, un hachage de manifeste de 32 octets (l’empreinte des fichiers de la version) et une adresse de version. Une version est enregistrée par architecture et par chaîne, et son libellé désigne les deux. Un libellé de version ne peut être enregistré qu’une seule fois : un correctif exige donc une nouvelle version, et une version révoquée ne peut jamais revenir. L’autorité peut aussi révoquer une version (type 35) et transmettre son rôle à une autre clé, ce qui se fait en deux étapes : proposer (type 33), puis accepter (type 34).

Les sièges enregistrés exercent un contrôle sur cette clé :

• Veto. Lorsque les deux tiers des sièges enregistrés attestent «  veto  » pour une version, celle-ci est révoquée exactement comme si l’autorité l’avait révoquée : les nœuds à mise à jour automatique l’ignorent et l’installateur la refuse. Les sièges suspendus sont exclus du décompte : avec 11 sièges actifs, le veto en exige donc 8. Chaque vote est une attestation sans frais signée avec la clé de nœud, et les opérateurs l’émettent eux-mêmes ; rien ne vote automatiquement.
• Remplacement. Un vote désignant une nouvelle autorité de publication n’est compté qu’une fois que le plus ancien vote en faveur de cette adresse a une semaine (40 320 blocs), si bien que le détenteur actuel voit venir le changement. À deux tiers, le rôle passe à l’adresse désignée par le vote.

Enregistrements et révocations n’ont qu’une valeur indicative : ils guident les nœuds dont les propriétaires ont choisi la mise à jour automatique ; un opérateur qui fait tourner un binaire de son choix n’en est pas affecté. N’importe qui peut vérifier une version téléchargée par rapport au registre (vérifier un fichier téléchargé).

Le programme de mise à jour

L’installateur ZooBC ajoute un petit programme de mise à jour qui tourne à côté du nœud, pas à l’intérieur. Il s’exécute une première fois 15 minutes après le démarrage de la machine, puis environ toutes les 10 minutes (à 2 minutes près). À chaque passage, il demande /api/v1/release/list au nœud local et cherche la version enregistrée et non révoquée la plus récente pour sa chaîne et son type de machine (amd64 ou arm64), plus récente que celle qui tourne.

Le programme n’installe cette version que lorsqu’elle est due : à la hauteur d’enregistrement de la version, plus le délai de mise à jour, plus le créneau propre à ce nœud. Il télécharge alors la version, vérifie sa signature et son hachage de manifeste par rapport à la chaîne, l’installe à côté de la version en cours, redémarre le nœud et effectue un contrôle de santé. Si le contrôle échoue, il revient à l’ancienne version, et il retente une mise à jour échouée au bout de 12 heures.

• Le délai est de 2 jours (11 520 blocs) par défaut sur le mainnet. Chaque nœud fixe le sien, et l’autorité de publication ne peut pas le raccourcir. Il laisse le temps de révoquer une mauvaise version avant qu’elle ne se propage.
• Les créneaux ordonnent les nœuds par clé et étalent leurs heures de démarrage de sorte que, par défaut, 2 nœuds au plus commencent une mise à jour dans un même bloc. La chaîne ne perd jamais beaucoup de producteurs à la fois.
• L’interrupteur du propriétaire, auto_update, vaut on (par défaut), off ou chain. Avec chain, le programme de mise à jour suit un réglage que le propriétaire signe sur la chaîne depuis le portefeuille, de sorte qu’il peut activer ou désactiver les mises à jour sans se connecter au serveur.

Chaque opérateur est averti lorsqu’une version plus récente existe : le programme de mise à jour, même désactivé, la signale avec l’état de son seuil de préparation, le nœud écrit un avertissement quotidien dans son journal, la route /node/info du nœud l’indique, le portefeuille web affiche un bandeau et l’explorateur montre la version de chaque nœud.

Le seuil de préparation

Les nouvelles règles de consensus sont livrées dans une version sous forme de lot, avec un identifiant de lot supérieur à 0. Chaque bloc porte la version logicielle de son producteur, et le seuil de préparation la lit. Les règles du lot s’activent, sur tous les nœuds à la fois, à la première hauteur qui remplit toutes ces conditions :

• elle est égale ou postérieure à la hauteur prévue pour le lot, et se situe au moins 5 760 blocs (un jour) après l’enregistrement de la version ;
• au moins deux tiers des sièges enregistrés (arrondis à l’unité supérieure, sièges suspendus exclus) ont chacun produit un bloc avec une version égale ou supérieure à l’identifiant du lot pendant la fenêtre de signalement, qui est la plus grande de deux valeurs : 720 blocs ou 5 blocs par nœud ;
• la version n’a pas été révoquée ; une révocation arrête un lot en attente.

À partir de cette hauteur, les blocs portant une version plus ancienne sont refusés. Un nœud qui n’a pas été mis à jour ne bénéficie d’aucun délai de grâce : il manque ses tours, ne gagne rien et perd du score dès son premier tour refusé (tours manqués, suspension et expulsion). C’est pourquoi les opérateurs sont avertis de chaque nouvelle version.

Comme ce sont les producteurs qui sont comptés, et non les blocs, une minorité coupée du reste du réseau ne peut pas atteindre les deux tiers à elle seule. Aucune clé ne peut non plus forcer l’activation : l’autorité de publication ne signe aucun message d’activation, et une hauteur seule ne décide jamais tant que les producteurs n’ont pas bougé. Le seuil a des limites connues : il n’a pas d’échéance, si bien qu’un peu plus d’un tiers des sièges peut retenir une mise à niveau, et il ne détecte pas une version défectueuse ; c’est à cela que servent le délai et le veto.

Les chaînes lancées avec la version 0.5.8 ont leurs 121 règles de consensus toutes actives dès le bloc 0, et aucune règle n’y est groupée en lot : le seuil n’entre donc en jeu qu’avec une version ultérieure. Un nœud refuse aussi de démarrer si son binaire situe l’activation d’une règle autrement que ce que la chaîne a enregistré, et une version peut embarquer une épingle de version qui la rattache à un bloc dorsal connu.

Voir aussi

• Faire tourner un nœud
• Vérifier un fichier téléchargé
• L’épingle de version
• Les règles des deux tiers
• La ZooBC Foundation