Je sais que Eloïs en avait parlé sur le forum, justement avec 2 autorités réellement en ligne sur 3, et avait même donné l’explication en pensant que l’équipe Substrate n’avait peut-être pas géré ce cas.
Oui il est certains qu’il y a une histoire de nombre minimal d’autorité en ligne nécessaire pour que la finalisation ne bloque pas, mais jusqu’à maintenant c’est resté très obscure, ce serait bien d’avoir une réponse claire la raison de ça, ainsi que des chiffres précis.
Je peux redevenir smith mais pour ça il faut d’abords que je sois membre de la toile principale, je n’ai reçus que 2 certifications: 5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn
Désolé, j’ai fait sauter les plombs en faisant des travaux, et pas eu le temps de m’occuper du serveur.
Je viens de faire une demande de retour en ligne, je devrais générer des blocs vers 19h00…
Chouette parce que j’étais en train de me rendre compte que même si j’implémentais la proposition technical committee dans gcli, je n’arriverais pas à la soumettre facilement tant que la validation est bloquée ><
À quel bloc vois-tu vit de retour ? → 146771 pour moi, soit à 18:40:24 d’après la blockchain alors que ton message date de 17h50 . Histoire de fuseau horaire probablement. Le timestamp est 1,701,279,624.
Je crains qu’on ne soit bloqué si on n’arrive pas à soumettre une proposition et la voter pour débloquer la chaîne. Et avec Ğcli on dirait que je ne m’y prends pas bien : Soumission d'extrinsic avec nonce manuel
Donc si quelqu’un a une idée de comment débloquer la chaîne, je suis preneur, parce que moi je sèche.
Nous ne sommes pourtant que 2 autorités et online, je ne comprends pas
edit : je viens d’envoyer un sudo.call(grandpa.note_stalled(1000, 11379)) inspiré par le sujet Finalization stopped in Gdev. Le changement de session est dans 4 minutes, on va voir si ça débloque la situation.
edit 2 : non, ça n’a rien changé.
edit 3 : apparemment il faut attendre le bloc #14,840 (donc vers minuit) pour qu’il se passe éventuellement quelquechose, en tout cas c’est le nombre que donne le state grandpa.nextforced. Ce nombre correspond à mon appel précédent, réalisé au bloc #12,840.
edit 4 : ah mais c’est encore @vit qui a tout cassé ? sorti au bloc#11,812 soit … 17h39 ? hum bon là j’attends minuit, sinon @HugoTrentesaux il faudra que tu reprennes la main
Oui, offence au bloc 11812. @vit, le réseau est assez fragile à faible nombre de validateurs, donc il faudrait que tu fasses go_online quand tu es sûr de pas avoir de coupures de courant (ou alors sur un VPS haute dispo), ou sinon tu attends qu’on soit plus nombreux.
@cgeek j’ai vu le tutoriel de monitoring, mais comme je ne connais pas ces outils, j’ai eu un peu la flemme de le suivre. Est-ce que tu veux partager ta config pour avoir le monitoring du réseau ? Ou directement partager une instance de l’interface de monitoring ?
Je ne me sens pas compétent là dessus, en tout cas pas plus que @tuxmain ou toi.
Alors elle est bien fragile cette blockchain.
Pour info, j’ai envoyė une demande de go_online avec mon identité sur le compte v1, sans publier les sessions keys. Juste pour être sûr que cela ne fonctionnerais pas.
Je comptais refaire aujourd’hui le processus revoke smith membership/migration identité sur compte v2/publication des clefs et go_online.
Avec un faible nombre de validateurs, oui. Comme me disait @bgallois en MP :
Ça devrait fonctionner puisque v1 est smith et a des dummy session keys. Pour rappel, l’idée des systèmes distribués est qu’on ne peut pas avoir une tolérance à trop de byzantins. Donc les gens qu’on nomme forgeron ne sont pas censés essayer de casser le réseau (cf license forgeron). On peut en tolérer une certaine proportion, mais cette proportion est atteinte quand 1 forgeron sur 3 l’est.
Je testais l’affichage du statut autorité dans Tikka.
Je ne pensais pas casser la finalisation car j’etais certain de ne pas etre accepté.
Mais je l’ai été. A ma grande surprise. Puis rejeté.
J’arrête mes essais et attends donc un plus grand nombre de forgerons.
Encore désolé, et merci pour votre calme et votre patience!
Oui je compte faire quelque chose comme ça et ajouter de l’alerting. Là c’est un coup de bol d’avoir vu le blocage “tôt” parce que je surveillais les graphes. Je ne sais pas si la finalisation aurait pu repartir si nous avions attendu davantage, j’ai encore un faible niveau sur Grandpa.
Ne boudons pas ces évènements : ça nous forme à intervenir sur des incidents et nous sensibilise à la surveillance, mieux vaut que ça arrive sur la ĞDev.
Je pense que c’est ce qui avait motivé elois à ajouter les session keys à la demande d’adhésion forgeron, mais ça ajoutait de la complexité sans vraiment contraindre la validité des session keys (la blockchain ne peut pas vérifier a priori que le nœud validateur possède bien les clés qu’il annonce. Les mêmes erreurs sont possibles :
avoir fait rotate_keys sur un nœud miroir plutôt que forgeron
avoir fait une faute de copier-coller
mettre des session keys d’un autre réseau sans avoir vérifié que le validateur les avait bien
Mais il faut qu’on l’explique bien dans la licence forgeron : le but est de mettre à dispo du réseau une machine de confiance en prenant soin de suivre les recommandations.
j’étais agacé sur le moment parce que ça fait deux réseaux bloqués en peu de temps, et que ça nous force à passer de l’énergie à ça plutôt qu’à avancer sur d’autres choses, mais être confronté tôt à ces problèmes est une excellente formation et on apprend beaucoup grâce à ça.
Être amené à avoir besoin tôt du comité technique permet de se rendre compte de points sur lesquels il nous faut être vigilants si on ne veut pas avoir à recourir à un code substitute (Changement de la clé sudo).
Oui je fais le sage mais ça bouscule quand même je venais à peine de mettre en place la supervision Prometheus/Grafana, mais au moins j’ai tout de suite vu l’intérêt ! C’est aussi pour ça que je n’ai pas eu le temps de les mettre en public, je suis en train développer quelques indicateurs supplémentaires spécifiques à la ĞDev.