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.
2 Likes
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
1 Like
14 posts were merged into an existing topic: Migration du compte de poka ĞDev (demande de certifications !)
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 ><
vit est de retour, mais que fait Grandpa ? J’ai entendu que la finalisation pouvait se faire “d’un coup”, je me demande si ça prend du temps.
1 Like
À 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.
Ben sinon on la redémarre, j’ai industrialisé cette partie exprès pour ça. Je prépare une branche au cas où, je change de suite la clé sudo.
edit : c’est fait.
Ça recommence mais sur la ĞDev 701, depuis 17h40 :
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 
2 Likes
C’est bon ! Tout est rentré dans l’ordre à 22h20.
Je ne sais pas dire si c’est mon call qui a changé la donne, mais nous aurons peut-être plus d’informations demain.
1 Like
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.
1 Like
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.
Grâce à Extension duniter-connect (fork de polkadot{.js}), rester sur des clés v1 n’est pas gênant, d’autant plus que tu les prends aussi en charge dans Tikka.
1 Like
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! 
2 Likes
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. 
1 Like
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_keyssur 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
- Becoming smith (request_membership, claim_membership) - #15 by tuxmain
- …
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).
1 Like
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.
Une fois fait, je partagerai.
2 Likes
Un graphe que je peux copier/coller ici en attendant, qui montre une forte élévation durant la période de finalisation bloquée :
Je ne sais pas exactement de quoi il s’agit, mais ça fait peur.
J’imagine que tant que les blocs ne sont pas finalisés, Duniter ne peut pas élaguer les blocs, donc il les garde tous en attendant que la situation soit résolue. Mais c’est juste une supposition, je n’ai pas creusé.