Merci hugo pour la création, je viens de confirmer l’identity, je vais pouvoir donner les 2 certifs manquaunte avec poka et ChristCosmic 
Enfin si d’autres peuvent le certifier avant, car je dois attendre 6h et 11h avant de pouvoir recertifier…
Certif émise !
1 Like
Je crois que je ne suis toujours pas membre.
5FPRZxVJGSzi8f8o5ue6uBbnQidMGm2XTLrESiQhWFJRLwdC
Est-ce qu’une certif de plus ferais l’affaire ?
Sisi tu es membre depuis hier 
Je ne comprends pas pourquoi mon transferAll('5G27hLdxFgtaZtwFDhs6iMp5fBgwCaoEXaKFJzk16wV6MhnG', false) depuis l’adresse 5EcqPZR3LeeFBT5rBVsmZ4Gqjwdzij5GqTrVWXB8fH6ygcCW à laissé 2ĞD sur le compte, alors que keepAlive est à false ?
C’est parcequ’il y avais encore un consumer actif sur cette adresse ?
Habituellement mon code check les consumer avant la suppression de wallet, mais pour mon test de migration csToV2 je ne l’ai pas fait, mais je pensais que la transaction échouerait à cause du consumer, pas que ça marcherait en laissant le solde existentiel.
Pour rappel, le consumer se libère à la fin de l’époch en cours c’est ça ?
Donc si il reste 2 minutes à l’époch actuelle, alors le consumer se libère 2 minutes plus tard ?
Ca me permettrait d’afficher à l’utilisateur le temps d’attente avant de pouvoir supprimer le compte (le vider).
EDIT: Oui c’était bien à cause du consumer, après avoir retenté le même call en testant cette fois la présence du consumer, ce dernier étant 0, la transaction a bien vidé complètement le compte.
@elois Comment je peux récupérer le numéro de bloc du prochain slot ?
Je vois par exemple le storage babe.currentSlot(), mais je ne vois pas comment déduire la fin de ce slot/début du prochain.
oui, transferAll va retirer le maximum de fonds possibles avec la configuration demandée, sans jamair échouer. keepAlive=false ne signifie pas “le compte doit être détruit”, mais “j’autorise la destruction éventuelle du compte”.
Non, le consumer est décrémenter quand le truc qui à incrémenter consumer n’a plus besoin de l’existence du compte.
Il n’existe pas de règle générale permettant de savoir si et quand les consumers seront décrémentés.
Il faut juste griser/désactiver la destruction du compte tant qu’il a au moins 1 consumer.
Tu ne peux pas. La notion de slot permet juste de déterminer qui est éligible à produire un bloc dans ce slot, ça ne garantit pas qu’un bloc sera effectivement produit.
2 Likes
C’est un point sur lequel j’avais buté d’ailleurs.
1 Like
Bonjour !
Pouvez-vous m’inviter et me certifier sur GDev cette adresse ? 5FsLPrnNeXYEAzpt7ajhf6cYnLvkwdVPFnUTTMyKkomvPcLA
Et je veux bien quelques unités
Merci d’avance !
2 Likes
Fait, tu peux confirmer ton identité
1 Like
Fait. Merci !
Et 3 certif
1 Like
et j’ai t’es vue passer membre dans gecko en live, donc ce btach fonctionne enfin…
2 Likes
Nouveau nœud miroir pour la gdev : wss://gdev.trentesaux.fr:443/ws.
3 Likes
C’est curieux comme la cadence des meilleurs blocs semble pertubé depuis quelques jours, vous ne trouvez pas ?
ça trottine un peu si vous regardez bien. Je suppose que @elois a des outils pour monitorer ça
1 bloc toutes les 8 à 15s en moyenne quand j’observe rapidement
Est-ce dû au fait qu’il n’y que 3 noeuds forgerons ?
1 Like
Des fois 6s, des fois 12s, et 3 forgerons alors que authorityMembers.authoritiesCounter=4, je suppose que ça veut dire qu’un des forgerons n’écrit pas de blocs.
2 Likes
Oui, étrange ce authorityMembers.authoritiesCounter=4 alors que authorityMembers.onlineAuthorities=[3, 4, 8].
Il n’y a bien que 3 autorités, le compteur authoritiesCounter est buggé. En me temps il ne sert qu’à vérifier la limite MaxAuthorities je vais le supprimer.
Concenant le blocktime, je pense que ça à cause de l’arrêt de la finalité qui est bloquée depuis que le noeud de cgeek à été hors-ligne pendant 1 round. On voit l’offence au bloc 275971.
Le consensus GRANDPA ne supporte la perte de 33% des validateurs ou plus. Il en faut toujours plus de 66,6% en ligne.
Donc s’il y a 3 autorités on ne peut pas en perdre. S’il ya 4 autorités on ne peut en perdre qu’une, etc.
Je ne sais pas s’il est possible de régler ça sans reset la blockchain 
3 Likes
Si il faut reset allons y, c’est fait pour !
Par contre avant, pour éviter que ce problème se reproduise, je propose qu’on s’occupe de faire une doc complète et claire sur comment devenir forgerons v2s de A à Z, je veux bien le faire avec Hugo par exemple, tout en montant mon premier noeud forgerons en parallèle.
Puis on lancera un appel ici à lancer plus de noeud GD, je pense que c’est le moment.
Mais je trouve ça très bien qu’on ai commencé avec très peu de noeud et qu’on ai eu ces problèmes, perso la plupart du temps pour comprendre quelque chose, j’ai besoin de me manger des murs… Sinon ça rentre pas 
3 Likes
La doc de @1000i100 est déjà pas mal : docs/user/smith.md · master · nodes / rust / Duniter v2S · GitLab
Mais je veux bien faire une vidéo “walktrough” pour donner un peu plus de contexte et un article plus grand public en français.
2 Likes
Moi je veux bien héberger un nœud, mais il faut s’attendre à des pannes régulières.
Je pense que ce n’est souhaitable qu’à partir d’un minimum de forgerons dans le réseau. Cela permet de tester la résilience du réseau en cas d’instabilité d’un nœud, mais il ne faut pas que cela mette en carafe le dit réseau.
1 Like