Lancement de ĞDev iteration #2 ce Dimanche 7 août 2022 (runtime-300)

Networks ĞDev
,
1

Je viens de consacrer mon week-end à la préparation et au lancement de la 2ème itération de la ĞDev, cette 2ème itération marque un avancement significatif, avec plusieurs gros changements coté runtime.

Principaux changements cotés runtime

  • Le passage à la création manuelle du DU.
  • La création d’un comité technique qui propose et vote les runtime upgrade (les forgerons ne peuvent plus le faire).
  • la possibilité de modifier la clé publique associée à son identité.
  • La nécessité de réclamer son entrée dans la toile manuellement quand vous avez reçu suffisamment de certifications.

Et d’autres changements structurants notamment pour l’étalonnage des poids. Liste exhaustive des changements sur le gitlab: runtime-300 · nodes / rust / Duniter v2S · GitLab

:warning: Cela introduit de nombreux changements cassants pour les wallet, Ğecko et Tikka ne devrait plus fonctionner, il va falloir laisser le temps aux développeurs pour faire une nouvelle version qui s’adapte aux changements cassants.

Genesis state

La configuration du genesis est très similaire à la 1ère itération, le principal changement est le passage à 3 certifications pour entrer dans la toile, dans le but de simplifier la création de comptes de tests.

La configuration du genesis est ici: resources/gdev.json · release/runtime-300 · nodes / rust / Duniter v2S · GitLab

J’ai conservé les mêmes clés publiques pour tous les comptes qui était présent au genesis de la 1ère itération. Pour ceux qui avaient rejoins après le genesis, il faudra recréer votre compte.

Déployer un nœud sur le réseau ĞDev 2ème itération

:warning: :warning: :warning: ATTENTION: Si vous aviez déjà un nœud sur la 1ère itération, vous devez nécessairement supprimer votre base de donnée !! :warning: :warning: :warning:

J’ai mis à jours la documentation utilisateur ainsi que les docker compose:

Pour un nœud miroir: Files · master · nodes / rust / Duniter v2S · GitLab
Pour un nœud forgeron: docs/user/smith.md · master · nodes / rust / Duniter v2S · GitLab

Pour ceux qui n’utilisent pas docker, il vous faut compiler le binaire à partir du tag git v0.3.0.

Les options de ligne de commande sont sensiblement les mêmes, quelques changements toutefois:

  1. Il est désormais possible de ne pas garder tous les blocs/storages en tant que nœud forgeron, utilisez pour cela l’option --pruning=14400 pour ne garder que les 14400 derniers blocs/storages (1 journée).
  2. L’option --execution Wasm n’est plus nécessaire, c’est désormais configuré ainsi par défaut.
10 Likes
2

Wouha toi qui disais lancement peut être septembre/octobre, c’est bien plus tôt et c’est tant mieux!
Je songeais justement à lancer un nœud de dev local pour adapter gecko aux DU manuels et autres changements, mais pas besoin du coup, ça m’arrange.

Comme d’habitude je vais essayer de voir si je comprends instinctivement ces changements en explorant les extrinsincs disponibles via polkadot.js, si je bloque je te dirais (pas sûr que je m’y mette tout de suite, je fais un peu une pause).

Il faudrait aussi resync tous les nœuds RPC et reset les DB indexer de Cédric et Manu.
C’est marrant sur gecko mobile du coup en ce moment c’est un client multi-monnaie en quelque sorte, si vous choisissez le nœud de 1000i100 par exemple vous êtes sur la GD1, le nœud d’elois sur la GD2 ^^

C’est nouveau ça, je ne me souviens pas t’avoir déjà lu entendu à ce sujet. Toujours dans la même veine de “rien d’automatisé en blockchain” je suppose.

Si je comprends bien, ça signifie que le client doit exécuter l’extrinsic membership.claimMembership() une fois que le client aura détecté que le wallet a le bon nombre de certification ?
A chaud, est-il envisageable d’implémenter une subscription à ce genre d’événement “ready to claim membership” par adresse côté Duniter ? Est-ce pertinent ?
Ou tout simplement, est-ce que le champ status du storage identity.identites(u32) passe en status membershipReady ou quelquechose du genre ?

Désolé j’ai déjà une autre question, pourquoi le user poka a déjà 100 GD en free balance alors que je n’ai pas réclamé ce DU manuellement ? Tu l’as fait pour nous pour ce premier DU ?

Bravo en tout cas pour cette nouvelle itération, on sent que ça avance !

2 Likes
3

Le bloc genesis indiquait que les membres de ce bloc créent un DU de 100 GD.

1 Like
4

Ça peut aussi être le cinquième certificateur qui exécute cette transaction (après avoir vérifié la règle de distance pour éviter que la transaction échoue pour cette raison).

5

Fait de mon côté, https://idx.gdev.cgeek.fr upgradé en v0.2.0 et données réinitialisées.

https://gecko.axiom-team.fr reflète déjà bien le reset de la blockchain.

Je vois pour mon nœud d’ici demain au plus tard.

2 Likes
6

J’ai toujours la même clé.
5FPRZxVJGSzi8f8o5ue6uBbnQidMGm2XTLrESiQhWFJRLwdC
Si quelqu’un veut bien me faire quelque dons, voire me certifier…

7

Je t’ai envoyé 10ĞD pour te créer.
Je te certifie dans 3 heures et 35 minutes:

image

Il y a 0.05 ĞD d’Elois que je n’explique pas:

image

On a fait exactement les même transactions pourtant, la symétrie n’est pas respecté je me sens floué de 0.05 ĞD !
Je soupçonne Elois d’avoir trafiqué cette itération pour disposer de 0.05ĞD supplémentaire de manière à être plus riche que nous et nous arnaquer, aucune autre explication.

8

Le reset de la Ğdev je l’avais bien annoncé courant aout lors de la réunion visio de juillet.

Non ce sera le call identity.validateIdentity, et le mieux c’est que ce soit le 5ème certificateur qui le batch avec la 5ème certification, car ça peut-être appelé par n’importe-qui.

Le 1er DU est présent dans l’état initial du genesis, car il n’est pas possible de démarrer une blockchain substrate sans monnaie.

Je pense que ce ne sera pas nécessaire, quand la règle de distance sera implémentée, le call déclenchera la mise en queue pour la vérification de la distance, donc le call réussira tant que l’identité à reçu suffisamment de certifications.

C’est pourtant un mécanisme qui était déjà en place dans la 1ère itération: les frais de transactions sont pour le moment versés au forgeur du bloc, donc à moi tant que je suis le seul forgeron.

1 Like
9

Je me suis rendu compte que j’avais oublié d’autoriser goOnline, j’avais fait le changement mais pas entièrement.

Je viens de livrer un runtime 301 qui autoriser désormais le call authorityMembers.goOnline:

C’était littéralement une seule ligne de code à supprimer:

Je viens de déployer ce nouveau runtime sur la blockchain avec sudo.
À la rentrée on fera marcher le comité technique pour que vous puissiez voir comment ça marche, mais je me suis dit que ça ferait trop de choses en même temps de l’utiliser maintenant.

2 Likes
10

Voilà c’est fait

11

C’est bon mon nœud est UP et goOnline() a été appelé. Mon 1er bloc devrait arriver à la prochaine session dans 1h je pense.

1 Like
12

Aïe aïe aïe tu n’as pas publié tes sessions keys @cgeek, du coup ton nœud ne pourra pas produire de bloc, je viens de te goOffline mais la blockchain va quand même devoir avancer avec seulement 50% de validateurs pendant 2h :confused:

C’est pourtant bien précisé dans la doc, faites plus attention.

Et demandez-moi mon aval avant de call goOnline, que je puisse vérifier si tout va bien, je crois que j’ai rendu ce call public trop tot…

2 Likes
13

Désolé :confused: certes c’est écrit mais vu l’importance cette partie gagnerait à être mise plus en avant.

Bon, j’ai publié les sessionKeys cette fois, je te laisse vérifier.

Édit : mais je vais scripter tout cela, les actions OPS ça ne s’improvise pas. D’ailleurs la Gdev précédente s’est éteinte à cause d’un oubli de rotateKeys justement.

3 Likes
14

C’est surtout important pour les membres forgerons inscrit dans le genesis, car mon code injecte des clés publiques bidons afin de ne pas avoir besoin de vous demander a tous vos sessions keys pour les copier dans la genesis conf.

Pour les membres forgerons qui rejoignent après le genesis, il est impossible d’oublier de publier ses sessions keys, puisque c’est une condition nécessaire pour devenir membre forgeron.
On peut éventuellement oublier de les mettre à jour, mais c’est moins grave (voir plus bas).

Ce n’est pas exact, la ĞDev ne s’est pas éteinte, elle était bloquée mais restaurable en ajoutant un runtime substitute dans les chain spec et en livrant un nouveau binaire, il aurait aussi fallu gérer le storage inconsistant, ça aurait été beaucoup de boulot, mais c’était faisable et je sais comment faire. J’ai choisi de ne pas le faire car un reset était déjà prévu.

Ici en revanche, nous avons un problème beaucoup plus grave que je ne sais pas régler, je pense après d’intenses recherches depuis 3h qu’il n’est pas réglable:

La finalisation est définitivement bloquée sur la gdev2 car il faut nécessairement la signature d’au moins 66% des autorités. Or la signature doit se faire avec la clé GRANDPA, l’une des 4 sessions keys, et il est impossible de fournir une signature valide pour une clé publique bidon, donc @cgeek ne peut pas débloquer la situation quoi qu’il fasse.

Après 3h d’intenses recherches, je n’ai trouvé absolument aucune solution, et tout semble m’indiquer dans le code de substrate que ce cas n’a pas été prévu, donc parity et tous les projets utilisateurs de GRANDPA n’ont jamais rencontrés ce problème.

Pour être plus clair, on peut perdre plus de 33% des validateurs temporairement (même plusieurs heures/jours), ça va juste bloquer la finalisation, qui reprendra quand suffisamment de validateurs seront de nouveau up et synchro, mais à condition que les validateurs concernés soient en mesure de fournir une signature GRANDPA valide, ce qui nécessite de posséder réellement la clé privée associée à la session key en blockchain.

Pour éviter ce problème en réseau de production, je désactiverai le code qui génère des sessions keys bidon si elles ne sont pas renseignées dans la genesis conf, ce qui implique que ce champ va devenir obligatoire pour tous les membres forgerons présents au genesis.

Je me suis créé une issue: Make field session_keys mandatory for every genesis smith (#87) · Issues · nodes / rust / Duniter v2S · GitLab

Tout ça pour dire que je suis dans l’obligation de reset encore une fois la gdev, ce que je viens de faire.

Il faut donc désormais vous baser sur le tag v0.3.0, l’image docker devrait être publiée par la CI dans la nuit.

5 Likes
15

C’est bon :

  • Indexeur upgradé en v0.3.0 et relancé sur la GDev
  • Nœud cgeek upgradé en v0.3.0, clés de session republiées : @elois je te laisse vérifier cette fois.
4 Likes
16

Je vois que tu as bien publié des session keys au bloc 6232, mais je ne peux pas vérifier si ces session keys sont bien dans ton keystore.

Tu peux le vérifier via le RPC call author.hasSessionKeys sur l’API RPC privée de ton nœud validateur.

17

Ça me semble bon :

image
image1186×534 57.2 KB

Je lance le goOnline() ?

18

Oui ça me semble bon cette fois ci :slight_smile:

1 Like
19

À qui correspond la clé 5GFEEx7kqvP4QEPCAXkALeYCG7m8DiA5LQ4YzW62j7FytQyg ?

image
image1436×264 32.4 KB

20

C’est mon 2ème compte membre forgeron Elois2, tu peux le vérifier dans la genesis conf: resources/gdev.json · release/runtime-300 · nodes / rust / Duniter v2S · GitLab

1 Like