L’idée est de détailler la question suivante : peut-on arrêter son nœud forgeron ?
S’il forge : non, faites go_offline() avant et attendez deux sessions
Sinon : oui, si vous n’avez pas fait go_online()
[à venir]
[à venir]
Déjà pour avoir quelques bases sur la VRF et le choix des auteurs des blocs, je recommande la vidéo de Elois sur le sujet : Vidéo présentation de Elois sur BABE/GRANPA (2022).
Ensuite pour les définitions de “epoch”, “session”, Elois avait aussi fait une feuille de vocabulaire : Vocabulaire de base pour comprendre Duniter-v2s (lecture fortement recommandée pour tous).
Il faudrait que je détaille ce qui se passe précisément lorsque l’on appelle go-online et go-offline, mais en gros :
Je viens de regarder la vidéo d’Elois sur Babe/Grandpa, c’était bien intéressant.
Je me pose tout de même toujours quelques questions:
Comment savoir a quel moment après l’appel go-offline on peut être certain que notre noeud SMITH n’est plus dans les authorités actives (et peut donc être stoppé pour maintenance / mise à jour, …) ?
Cas concret plus tôt dans la journée; j’avais fais la commande pour go-offline, ensuite j’ai bien vu que j’étais mentionné dans les “outgoing” (et toujours dans les “online”), et assez rapidement après, je n’étais plus mentionné ni dans les noeuds “online”, ni dans les “outgoing”.
Par contre, en regardant les blocks arriver sur mon noeud ARCHIVE; je suis quasiment sur que je voyais toujours des blocks signés par mon SMITH arriver…
Autre question, qui est un peu discutée dans la vidéo également mais pas spécifiquement lié aux mises-à-jour: comment peut-on être sur de ne pas rester bloqué si on a une mise a jour à faire et que (pas de bol) tous les forgerons font un go-offline dans la même session ?
On se retrouverait alors dans la session N+2 sans aucun noeud SMITH “online”…
Et on peut également se poser la même question avec comme aujourd’hui le fait que l’image docker 900-0.9.0 ne fonctionnait pas en mode SMITH; on aurait pu avoir une situation ou au final plus aucun SMITH “online” ne sait traiter des blocks.
Il y a peut-être quelque chose déjà en place pour ça; ou bien il faut s’assurer de garder un certain nombre de noeuds SMITH en version précédente et “online” jusqu’a être sûr que la mise à jour est stable et qu’il y ait déjà suffisament de noeuds SMITH en nouvelle version et online…
Le mieux tant qu’il n’y a pas de client qui l’affiche clairement est d’aller voir directement dans le storage. Je crois que session.validators() devrait permettre de voir les validateurs actuels. Je ne connais pas par cœur le fonctionnement et quand j’ai besoin de comprendre les pallets qui ne sont pas les nôtres, je vais lire le code. Mais c’est clairement une amélioration à prévoir sur Duniter Panel, je le ferai prochainement.
Si les forgerons se mettent d’accord pour arrêter de forger, la blockchain ne peut pas continuer. Pour rattraper une telle situation, il faut que des non forgerons déploient un “runtime substitute” pour devenir forgeron de force, et ça fait un fork, mais en l’occurrence, le seul qui continue à avancer.
C’est à ceux qui votent les runtime upgrade de faire en sorte que ça n’arrive pas 
Plus sérieusement, on peut en effet choisir le scénario de mise à jour qui convient le mieux à l’état du réseau et à ce qu’on veut en faire. D’où les réseaux de tests qui permettent de voir ce qui passe ou pas en pratique.