Finalisation des blocs en mode dev

Support Duniter-v2
1

Lorsqu’on lance un noeud en mode dev, si nous ne fournissons pas de genesis, laissant ainsi les données de dev par defaut (Alice, Bob ect …), alors tout va bien.

Cependant, si nous fournissons un genesis, avec la première identité par ordre alphabétique bien dans le groupe smith, alors BABE fonctionne correctement avec cette identité forgeant, mais grandpa ne finalise aucun bloc.

Dans les 2 cas le storage semble indiquer les mêmes états pour ce que je regarde, notamment grandpa.state() est “Live”, 1 onlineAuthorities, mais dans le seconds cas, pas de finalisation.

Voici le json genesis en question:

Et le docker compose utilisé: docker-compose.test.yaml · fuck-docker · nodes / duniter-indexer · GitLab

Globalement ça signifie que commenter simplement la ligne 15 de ce yaml change le comportement de granpa.

Quelqu’un serait dire pourquoi ce comportement ?
C’est embêtant pour travailler sur l’indexer v2s à partir d’une blockchain local dont ont maîtrise le genesis.

Certaines infos sur les forums parlent de la nécessité d’avoir au moins 2 noeuds validateurs en ligne pour déclencher la finalisation, mais ce n’est pourtant pas le cas en mode Alice alors que ça finalise dans ce cas.

2 Likes
2

Je vais creuser, mais ça me semble être un problème entre forgeron et autorité.

Dans le cas avec DUNITER_GENESIS_CONFIG, on appelle generate_genesis_data qui a un argument maybe_force_authority. Dans l’autre cas, on génère directement des chainspecs depuis un genesis créé par une fonction gen_genesis_for_local_chain.

Je ne sais pas encore d’où vient la différence.

C’est possible aussi que --force-authoring force à ajouter des blocs même en offline mais du coup la finalisation ne peut pas se faire.

1 Like
3

Pourtant je constate que test1, le premier smith, est online dans le chain state.

1 Like
4

Oui, je continue à creuser, en fait les initial_authorities sont pas les mêmes dans les deux cas.

Avec des chainspecs custom c’est une seule autorité online :

[node/src/chain_spec/gen_genesis_data.rs:370] initial_authorities.clone() = {
    1: (
        9e9f13d7110979ec2bd11396221895d36ef3743c538bea01e0f33f4978511d54 (5FeggKqw...),
        true,
    ),
}

Avec des chainspecs générées, c’est trois autorités (les forgerons) mais une seule online :

[node/src/chain_spec/gdev.rs:278] initial_authorities.clone() = {
    1: (
        d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d (5GrwvaEF...),
        true,
    ),
    2: (
        8eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a48 (5FHneW46...),
        false,
    ),
    3: (
        90b5ab205c6974c9ea841be688864633dc9ca8a357843eeacf2314649965fe22 (5FLSigC9...),
        false,
    ),
}
5

C’était tout con à résoudre, j’ai juste eu à ajouter des autorités offline au début : fix finalization when using custom genesis (4f456be8) · Commits · nodes / rust / Duniter v2S · GitLab

Tu peux utiliser cette branche, ça facilitera le boulot de dev sur l’indexeur !

Je t’ai mis comme reviewer sur la MR associée : fix finalization when using custom genesis (!154) · Merge requests · nodes / rust / Duniter v2S · GitLab

1 Like
6

je viens d’essayer depuis ta branche, malheureusement, ça ne semble toujours pas vouloir finaliser lorsqu’on renseigne un genesis custom:

DUNITER_GENESIS_CONFIG=gdev_test.json ./target/debug/duniter --dev

2023-04-18 18:54:48 ✨ Imported #14 (0xf9cc…8664)    
2023-04-18 18:54:50 💤 Idle (0 peers), best: #14 (0xf9cc…8664), finalized #0 (0x30d5…066a), ⬇ 0 ⬆ 0    
2023-04-18 18:54:54 🙌 Starting consensus session on top of parent 0xf9cca6c944512414ddf52bde3371b2c72909119bb97fa593ef09ff6223e88664    
2023-04-18 18:54:54 🎁 Prepared block for proposing at 15 (2 ms) [hash: 0xfbee9c02a45e7852b95261fd308de2611b47c538c26a4fda76758c105731cb5b; parent_hash: 0xf9cc…8664; extrinsics (1): [0x4b5e…2907]]    
2023-04-18 18:54:54 🔖 Pre-sealed block for proposal at 15. Hash now 0x50ee4b00dd1699dfd104d1ba0215514beeee40d84aaa3e2e1f34007fbbcddff1, previously 0xfbee9c02a45e7852b95261fd308de2611b47c538c26a4fda76758c105731cb5b.
7

Ah oui, merde, t’as raison, j’ai confondu mes deux résultats. Va falloir que je me replonge dedans :sob:

1 Like
8

Je galère bien sur ce bug, ça fait plus d’une journée que j’y suis. C’est pas perdu, j’ai appris des choses, et j’ai un peu avancé, on dirait qu’il y a une différence de session keys alors que dans les deux cas on devrait avoir celles d’Alice (j’ai remplacé test1 par Alice avec sa clé pour avoir moins de différences).

Genesis généré :

  "session": {
    "keys": [
      [
        "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
        "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
        {
          "grandpa": "5FA9nQDVg267DEd8m1ZypXLBnvN7SFxYwV7ndqSYGiN9TTpu",
          "babe": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
          "im_online": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
          "authority_discovery": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY"
        }

Genesis custom :

  "session": {
    "keys": [
      [
        "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
        "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
        {
          "grandpa": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
          "babe": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
          "im_online": "5FA9nQDVg267DEd8m1ZypXLBnvN7SFxYwV7ndqSYGiN9TTpu",
          "authority_discovery": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY"
        }

On note que dans le premier cas, c’est la clé grandpa qui est différente alors que dans le deuxième cas c’est la clé im_online. J’espère que le problème vient de là.

3 Likes
9

Grandpa utilise des clés Ed25519, et les autres Sr25519 :

const KEY_TYPES: [(KeyTypeId, CryptoScheme); 4] = [
    (KeyTypeId(*b"gran"), CryptoScheme::Ed25519),
    (KeyTypeId(*b"babe"), CryptoScheme::Sr25519),
    (KeyTypeId(*b"imon"), CryptoScheme::Sr25519),
    (KeyTypeId(*b"audi"), CryptoScheme::Sr25519),
];

donc on dirait qu’il y a effectivement un problème dans le genesis custom qui effectue un encodage / décodage des session keys.

1 Like
10

Il me semble qu’on utilise les mêmes clés pour Ed et Sr. De toute façon ce n’est que [u8; 32].

11

Trouvé !!

I finally found the exact reason of the bug: the development_chain_spec function was sending encoded AuthorityKeys to genesis_data_to_gdev_genesis_conf function which was expecting SessionKeys and decoding as such. The result was that Ed25519 grandpa keys were given to im_online instead, blocking the finalisation.

@poka, cette fois-ci j’espère que je ne te ferai pas de mauvaise surprise. Est-ce que tu peux tester à nouveau la branche et me dire si ça fonctionne ?

6 Likes
12

Bravo, mon nœud local finalise actuellement les blocs en mode dev, et avec test1 en smith, ça fonctionne !

4 Likes