Développements avec docker duniter/duniter-v2s-gdev (Alice, Bob, etc)

Networks ĞDev
1

Je crée ce fil pour ceusses qui développent avec l’image docker duniter/duniter-v2s-gdev.

J’utilise la commande suivante :

docker run -p 9944:9944 duniter/duniter-v2s-gdev

L’intitulé dans Polkadot.js est :

Ğdev Local Testnet
gdev/800
#425

Contrairement au nœud duniter-v2s:latest qui est en 801. Est-il à jour ?

Format SS58 à Null !!

system.properties: ChainProperties

{
  isEthereum: false
  ss58Format: null
  tokenDecimals: [
    2
  ]
  tokenSymbol: [
    ĞD
  ]
}

Le format ss58 est à null, ce qui me donne des adresses pour Alice, Bob et les autres différentes que dans Tikka (ss58 format 42).

Avec le client RPC Python j’ai une erreur si je veux obtenir une adresse à partir d’un mnémonique avec le ss58Format à None.

Dans Polkadot.js, il détecte Alice, Bob et les autres avec des adresses au ss58format à Null que je ne peux pas reproduire en Python. Moi je dois donner un numéro de format ss58.

Soit je soumet le problème au mainteneur du client Python (accepter un ss58 format à null), soit on met un numéro ss58 dans la gdev (42?). Qu’en pensez vous ?

Peut-être l’option 1, sachant que gcli a l’air aussi de bien supporter le ss58 à null.

[EDIT]
Je faisais une erreur sur la dérivation, il faut une majuscule à //Alice ! Du coup j’ai les bonnes adresses.
Reste à savoir pourquoi il y a ss58format=null dans la blockchain, mais cela ne devrait pas me bloquer…

2
  1. Bob invite Dave à être forgeron. (Dave status = Invited, expiresOn: 48)
  2. Dave accepte l’invitation. (Dave status = Pending, expiresOn: 48)
  3. Bob certifySmith Dave (Dave status = Pending, expiresOn: 48)
  4. Alice certifySmith Dave (Dave status = Smith, expiresOn: 48)
smithMembers.smiths: Option<PalletSmithMembersSmithMeta>

{
  status: Smith
  expiresOn: 48
  issuedCerts: []
  receivedCerts: [
    1
    2
  ]
}

A quoi correspond la valeur en blocs expiresOn ?

J’ai laissé Dave longtemps à Pending, puis une fois le bloc largement dépassé, son status n’avait pas bougé et j’ai pu le certifier…

3

On dirait que tu utilises une version du runtime antérieure à la correction de #194. C’est un nombre de sessions, et pas de blocs (donc 48h) mais c’est vrai que ce n’est pas documenté dans le code :scream: : /pallets/smith-members/src/lib.rs#L125.

1 Like
4

Oui, c’est ce que je précise dans mon premier post : l’image docker duniter/duniter-v2s-gdev:latest de la gdev locale avec Alice n’est pas à jour (runtime 800 au lieu de 801).

5

Oups, désolé, je suis allé un peu vite, j’avais oublié ce post. En fait on a publié le runtime 801 sur le réseau ğdev mais sans publier de nouveau client qui intègre ce runtime dès le genesis. C’est lié à #195.

Pour le format ss58, il faudrait l’ajouter dans les client specs : node/specs/gdev_client-specs.yaml · master · nodes / rust / Duniter v2S · GitLab.

1 Like
6

Cela avait déjà été signalé, et @cgeek avait confirmé ce comportement de Duniter, que quand on fait go_online, le statut Autorité devient Online, mais dans les faits l’identité n’est pas encore Online.

Je viens de voir de nouveau ce comportement avec Tikka.

  • Alice invite Dave, qui accepte et est certifié par Alice.
  • Bob veut certifier Dave aussi mais n’est pas online : message d’erreur “Only online Smiths can certify other Smiths”.
  • Bob envoie go_online. En quelques secondes il est statut autorité online.
  • Bob certifie aussitôt, mais impossible, même message : “Only online Smiths can certify other Smiths”.

Il semble y avoir une différence entre l’information du statut de l’autorité et son statut réel online/offline .

7

C’est comme ça que cgeek a conçu le privilège de certification. Il faut être online, pas seulement annoncer qu’on va le devenir. Plus précisément, expire_on est mis à None quand on_smith_goes_online est appelé, ce qui est le résultat du hook on_incoming_member qui est appelé par new_session de la pallet authority-members quand il lit IncomingAuthorities. Le changement du set des validateurs se fait session par session car c’est lui qui sert de base au calcul de la VRF. Cf Axiom_conf_tech-Elois-BABE-GRANDPA-nov_22 - P2Tube pour plus de détails.

À quel niveau lis-tu ce statut ?

8

Avec un “query” authorityMembers.onlineAuthorities sur les données de la chaine (le storage) :

Je viens de faire go online avec Bob (identité 2) :

authorityMembers.onlineAuthorities: Vec

[
1
2
]

9

Je n’ai pas le même comportement chez moi.

> duniter --dev
# authorityMembers.onlineAuthorities vaut [1]
> gcli --no-indexer -n local -S predefined -s Bob smith go-online
transaction submitted to the network, waiting 6 seconds...
smith went online MemberGoOnline { member: 2 }
#  authorityMembers.onlineAuthorities vaut toujours [1]
10

C’est une bonne nouvelle si ton environnement est plus à jour que le mien. :slightly_smiling_face:
Quand l’image docker duniter-v2s-gdev sera à jour en 801, je ressaierai.