Lancement de la blockchain ĞDev le 27 mai 2022 (runtime-100)

Fait à l’instant via Ğecko !

4 Likes

Il m’en manque une dernière…

Fait, tu es membre !

1 Like

Merci :wink:

4 Likes

16 messages ont été scindés en un nouveau sujet : Revocation mechanics

La 1ère réévaluation du DU a bien eu lieu ce matin au bloc #100800:

Le nouveau DU est de 100,21 ĞD :slight_smile:

6 Likes

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.

7 Likes

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 :melting_face:

7 Likes

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 :artificial_satellite:

4 Likes

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.

1 Like

Le nœud est de nouveau UP. J’ai eu une coupure de courant, j’avais d’autres problèmes à gérer avant le redémarrage du serveur, mais là c’est bon.

1 Like

Très bien, je vois que tu produis de nouveau des blocs, je cancel le goOffline (il suffit de refaire goOnline) :slight_smile:

Ah ouai je voyais des pics de 18s entre 2 blocs pendant ce down !
C’est énorme.
Je suis désolé actuellement je n’ai plus de serveur pour faire tourner un noeud ĞDev, il faudrait que je trouve un micro PC type raspi mais non ARM, là j’ai qu’un rapsi…


Est-ce que vous pouvez certifier ce compte svp pour mes tests ?
poka2: 5CJKhFCpdSpumgWjSZ3TQmejJuHV6iELJrtdrfs38SXuiQeB
image

merci ^^

2 Likes

Fait :wink:

1 Like

Manque plus qu’une :slight_smile:

Non c’est pas poka2 c’est “ChristCosmic”, c’est le nom que tu as publié en blockchain au bloc #24096 :stuck_out_tongue:

1 Like

J’ai certifié le ChristCosmic sans le savoir ! :star_struck:

1 Like

Dans mon Grafana je vois clairement l’impact du downtime du nœud autorité de cgeek :

image

J’en déduis que la coupure de courant est arrivée aux alentours de 18h30, au plus bas on est descendu vers 7,5 blocs / min, ça variait, car il y a une part d’aléatoire dans le consensus BABE, donc ça dépendait du nombre de slot où cgeek était le seul sélectionné.

Par contre, malgré cet « incident », la finalisation n’a pas subi de lag, au contraire, un bloc est toujours finalisé en 2 à 3 blocs :

image

Ce sera sans doute plus quand on aura plus de validateurs, ce sera l’un des trucs à tester quand la ĞDev sera plus stable :slight_smile:

4 Likes

La blockchain a bien reporté automatiquement une offence au bloc #120388:

À l’avenir, ce genre d’offences déclenchera des sanctions, actuellement ça ne déclenche rien car le handler des offences n’a pas été implémenté (c’est une fonction vide qui ne fait rien).

À nous de définir les modalités des sanctions selon la nature de l’offence, la proportion de « rapporteurs », et tout autre critère que l’on peut déduire du storage on-chain, quitte à le stocker exprès pour, comme par exemple mémoriser des offences passées pour savoir si c’est une « récidive ».

Pour le cas de l’offense « hors-ligne » par exemple, substrate recommande de ne sanctionner que si plus de 10% des authorités sont hors-ligne, donc dans la pratique un incident isolé comme la coupure de courant de @cgeek ne devrait pas causer de sanction (car en prod on aura bien plus de 10 authorités), à condition qu’il ne soit pas trop fréquent bien sur :slight_smile:

Et il n’ y à pas que les sanctions, on peut par exemple trigger automatiquement on goOffline si une offence « hors-ligne » à suffisamment de rapporteurs, ça permettrait de ne pas impacter le réseau dans la durée si le membre forgeron concerné ne peut pas rétablir la situation rapidement.

5 Likes

Sanctionner les forgeront, dans le cas de substrate/BABE ça me semble indispensable.
Par contre qui dit sanction pour “mauvaise conduite” dit récompenses pour “bonne conduite” ou pour “conduite” tout court ^^

J’imagine que tu as déjà pensé à tous ça avec la trésorerie commune.


J’ai lu quelque par que Polkadot avait commencé avec une pool de 20 authorités, qu’ils sont maintenant autour de 980 et qu’ils visent les 2000 à terme.

Vue le niveau d’engagement et les ressources nécessaires pour forger v2s comparé à v1, il ne faut pas s’attendre à avoir autant de forgeront qu’en v1.

Quand tu dis bien plus de 10, as-tu déjà des ordres de grandeurs en têtes pour la prod ?