Je confirme:
Merci @poka, pour tester je viens de certifier @vincentux avec Elois2 et ça fonctionne
Du coup il me reste 4 certifs à trouver…
Non 3, puisque je t’avais déjà certifié avec mon 1er compte (créer une identité implique de la certifier).
Tu peut d’ailleurs le vérifier dans polkadotjs:
Ha oui pardon
@cgeek puis-je ajouter ton nœud validateur à la liste des bootnodes ?
J’aimerais ajouter précisément ce endpoint:
/dns/gdev.cgeek.fr/tcp/30333/p2p/12D3KooWF4QpicSWSD32f6yaqdr4eSqudrK7AbR9LvgUDGdSqukc
Car pour le moment il n’y a que mon nœud dans les bootnodes, ça fait centralisé
Oui aucun soucis, c’est un nœud monitoré permanent.
Puis-je avoir d’autre certif ? Please
5FKoEykLwgwpuHzwKngCU1bX8KbtjLxcAdPkprdNEzsadfuh
Fait à l’instant via Ğecko !
Il m’en manque une dernière…
Fait, tu es membre !
Merci
16 messages ont été scindés en un nouveau sujet : Revocation mechanics
D’ailleurs cette réévaluation du DU m’a fait découvrir un 2ème bug: on voit 15 membres comptabilisés alors qu’il n’y en a que 14.
C’est ma révocation explicite qui n’a pas été déduite du UdAccountsStorage, je viens de créer une issue: bug: identity explicitly revoked stay in the ud accounts storage (#57) · Issues · nodes / rust / Duniter v2S · GitLab
J’ai identifié la cause dans le code, mais le problème c’est que fixer ce bug va demander un gros refactoring d’une pallet qui ne sert que pour la création automatique du DU, je réfléchis donc à ne pas corriger ce bug mais plutôt à migrer directement en création manuelle du DU, je vais probablement implémenter ça dès ce week-end, et livrer un runtime-200 la semaine prochaine !
EDIT: comme c’est une nouvelle feature, je doit incrémenter au runtime 200 et non 102.
La folle histoire du debugging de la ĞDev continue, je ne vous raconte pas tous les détails, car ce serait trop long, mais hier soir avec @poka on a identifié un autre bug, donc je ne comprenais pas l’origine: dans certains cas, les frais de création de compte ne sont pas prélevés, je donnerai plus de détail dans le sujet sur le runtime-103, que je vais essayer de rédiger en fin d’après-midi.
C’est ce que je croyais lors de la 1ère investigation hier, mais avec la journée de boulot en parrallèle, et la préparation de la visio du soir et du runtime-102, des éléments m’ont échappés: j’avais bien identifié ce qui causait le bug, mais sur le moment je ne voyais pas de moyen de le corriger sans un gros refactoring.
Ce matin, pendant que j’investiguai l’autre bug (celui qu’on a trouvé avec poka hier et que j’expliquerai dans le futur sujet sur le runtime-103), j’ai finalement eu une idée pour corriger “simplement” ce bug (#57), que j’ai implémentée ce matin et d’après mes tests ça fonctionne.
Donc changement de programme, je ne vais pas implémenter les DU manuels pour le moment, ni aucune nouvelle feature, je préfère d’abord fixer tous les bugs connus pour consolider la base avant d’aller plus loin !
En fin d’aprem, ou début de soirée, je proposerai un runtime-103 qui inclura les fix pour ces 2 bugs, avec davantage d’explications, ainsi que preimage-provider (car c’est un bug que de pouvoir schedule le hash d’un call mais sans pouvoir publier le call).
Mais la, j’ai besoin d’une pause
Bravo pour tout ce taf @elois, ça nous donne déjà de quoi faire sur les indexers/wallets/outils, et je suis sûr que ça va motiver du monde à contribuer à v2s
Le serveur de @cgeek est down, le viens de le prévenir par SMS, et de call goOffline pour lui afin de minimiser l’impact sur le réseau, mais ce ne sera appliqué que dans 2 epochs, donc le temps entre deux blocs va être plus long pendant environ 2h.
On vient de perdre 25% des authorités, c’est absolument énorme, donc l’impact sur le temps entre deux blocs est massif !!
C’est aussi pour cela que dans une monnaie de production il faudra beaucoup plus d’autorités (pour minimiser l’impact de la perte de l’une d’entre elles).
Une offence va être automatiquement générée, dans une vraie monnaie @cgeek serait sanctionné, mais il n’y a pas encore de sanctions !
Je voulais justement me créer une alerte pour être notifié de ce genre de cas, mais j’aurais de toute façon placé le seuil plus haut, le temps entre 2 blocs n’a pas suffisamment ralenti pour que ce soit alarmant.