After pushing the button “Claim membership” in Tikka, my smith membership status is validated, and with an expiring block info ! 
GUI is a WIP and will be improved over time (“expire on” will display a proper date…).
3 Likes
Currently the expiration really happens at this block number. Future block times can be estimated quite precisely but it’s still an estimation, so I think the block number should be displayed along with the date, and something somewhere should say the date is estimated. (maybe a little icon after the value, that switches block number or date display, so it’s still selectable)
3 Likes
I sent the go_online command from Tikka and 2 hours later, I am writing blocks !
1,635,182 0x4f4b07e5d5b009c0ed324a950ab876148240c78f76c5a305b1f4da662f3d15dc
SMITH (EXTENSION)
4 Likes
My session keys string was stored in Tikka DB, then I destroyed it to modify tables… 
So, can I find session_keys string somewhere in storage ?
I found session.nextKeys() with some string, and under my address, the same in session.queuedKeys().
session.nextKeys: Option<GdevRuntimeOpaqueSessionKeys>
{
grandpa: 0x08843a9bb395a4565ab4d5453df6ac7491e529b43a8993d67e7727fb5d1a9d14
babe: 0x886fcbdd8751185322b663c702585fa09ea93fdedcebd1f51190d0b2eb44cd41
imOnline: 0x7eff459774a18625abff2be729838bc046c9aa365771fa1091861a133659307a
authorityDiscovery: 0x7edd040fd19ce89fbb0dd11f40c3b81369956c3c821909bfaa7a5dc24488d348
}
But this is not the long string I got with rotate_keys().
As a workaround, I can use rotate_keys(), then set_keys() to change them and store them again in Tikka DB…
Your private keys are in the keystore folder of your server. What you get with rotate_keys() is only the public keys. You can check that your node still has the private keys corresponding to your public keys by calling the rpc method author.hasSessionKeys(sessionKeys) on your smith node (here sessionKeys means “public keys”).
There is no need to store your public keys anywhere as they are declared publicly.
[edit]
you declared the session keys 0x08843a9bb395a456... in block 1606142.
I do not know if you called setSessionKeys() after that since this call does not emit an event and that we do not index called extrinsics yet.
1 Like
Thanks for retrieving it from your archive node ! 
I get my response indirectly, because I suspected session.nextKeys to be a split form of the session keys returned by rotate_keys(). And it is indeed !
If I concatenate the four keys, I get the right key found in the block :
08843a9bb395a4565ab4d5453df6ac7491e529b43a8993d67e7727fb5d1a9d14886fcbdd8751185322b663c702585fa09ea93fdedcebd1f51190d0b2eb44cd417eff459774a18625abff2be729838bc046c9aa365771fa1091861a133659307a7edd040fd19ce89fbb0dd11f40c3b81369956c3c821909bfaa7a5dc24488d348
I need to store the session keys in Tikka to transfer the “Rotate keys” button result to the “Request membership” button which requires it (and “Publish Keys” button requires it too, as it is set_keys(session_keys) command).
May be one day I will hide the session keys under the hood, but for now, it is helpful to show it for debug…
1 Like
Indeed the session keys are just the individual keys concatenated.
Each pallet can define session keys. If we add a pallet that needs another key, we will have longer session keys.
1 Like
My nodes were up but stuck, and no more on telemetry. Thanks to @Pini to report it to me.
I restarted both, and today there are both on telemetry, RPC node is fine, but Validator node is stuck.
So today I tried to send goOffline to the Validator node with Tikka. But as it is stuck, it does not process correctly the RPC request, and the python request code is stuck infinitely awaiting a response.
So I changed my connection to the RPC node and sent the goOffline command with Tikka.
This works fine !
goOffline is an extrinsic, an operation on blockchain, you submit it to the network, it does not matter which node you’re sending it to. Not to mix up with rpc calls which is a way to interact with a specific node.
2 Likes
Les métadonnées d’adhésion ne sont utilisées que pour l’instance forgeron de la pallet membership. Ces métadonnées contiennent :
owner_key(peut être déduit du callrequest_membership)p2p_endpoint(purement informatif, la seule vérification faite est humaine, par le certificateur)session_keys(pourrait être intégré à un call de authority members)
Je propose donc de les supprimer et de revoir dès maintenant le processus d’adhésion forgeron, je vous tiens au courant.
Je découvre que la couverture de tests sur les adhésions forgeron était insuffisante parce qu’en supprimant les métadonnées, tous les tests passent (unitaire et intégration) sur ma branche hugo-remove-membership-metadata. Il va falloir plus de tests d’intégration et aussi des tests end2end si on veut pas se retrouver bloqués sans forgerons !
Bah non en fait, les métadonnées étaient juste complètement inutiles. La pallet authority-members vérifie bien qu’une identité est membre de la toile forgeron sur set_session_keys() et go_online(), et les conséquences de claim_membership() sur la toile forgeron étaient juste set_session_keys(). Donc retirer les métadonnées ne change rien.
Conclusion, la nouvelle méthode pour devenir forgeron est :
smith_membership.request_membership()pour demander à rejoindre la toile forgeron- obtenir les certifications forgeron
smith_cert.add_cert() smith_membership.claim_membership()pour valider une demande d’identité forgeronauthority_members.set_session_keys()pour mettre des vraies session keysauthority_members.go_online()pour commencer à calculer des blocs
(reste un peu de boulot pour nettoyer le code)
2 Likes
Est-ce que tu veux intégrer cela avant le reboot de la ĞDev ou pas ?
Je vais voir, mais à cause de #129 ça me semble prioritaire. Sinon dès qu’on aura une expiration de membre forgeron la blockchain sera bloquée. Ou alors on opte pour un fix plus simple comme implémenter un default bidon à la place du unreachable. J’avance le plus possible d’ici vendredi et on avise ce weekend ou en visio développeurs.
1 Like
Clarification : la MR !192 retire les metadata, mais ne change pas le problème des certifications sans demande d’adhésion, elle souligne juste le problème dans un fichier de test dédié : runtime/gdev/tests/fixme_tests.rs lié au ticket #136. Et elle est prête à être fusionnée après relecture.
Cette commande ne fonctionne plus dans Tikka pour la gDev 700.
Dans l’implémentation précédente, le paramètre à passer était la chaîne retournée par author.rotate_keys(), consistant en quatre clefs concaténées en une seule chaîne.
Tikka a conservé cette chaîne en DB, mais ne peut plus l’envoyer telle quelle. Elle doit être splittée en quatre clefs indépendantes d’après Polkadot.js.
Avant de faire ce boulot, je voudrais confirmation que je dois bien le faire et qu’il est réalisable… 
C’était mieux avant (boomer!), je n’avais pas à transformer la donnée avant de la renvoyer… 
1 Like
Effectivement, avant, le split était fait côté Duniter, j’aurais peut-être dû conserver un wrapper d’ailleurs. Mais oui, les session keys sont quatre clés publiques concaténées, donc le split est possible, c’est d’ailleurs comme ça que j’ai fait dans Ğcli.
1 Like