Running full local network for tests (duniter + indexer)

Support
21

Shouldn’t it be just “gdev” (or maybe just “dev” if for local chain - I never tried that)

DUNITER_CHAIN_NAME: "gdev"

Edit: I didn’t see the message of @poka above mentionning “gdev_dev”… No clue :thinking:

22

The summary of the different values for --chain argument can be found here: État des lieux des différentes chaînes - #17 by cgeek (:warning: the first post is out of date, make sure to check the post number 17).

It seems that framework upgrades discouraged the use of custom chains for local developement without --dev flag through multiple means:

  • the removal of automatic key generation for validator nodes
  • the requirement to provide a --public-address for validator node

The result is that you have to proceed in two steps:

  1. generate key at given position
$ duniter key generate-node-key --chain=dev --base-path /tmp/test-duniter-local
Generating key in "/tmp/test-duniter-local/chains/gdev_local/network/secret_ed25519"
12D3KooW9surMsDEaFvAfr13zsUzfQDbpkAWXJxK4dKDu4XaMCuH
  1. start duniter with a dummy public address
$ duniter --chain=dev --force-authoring --alice --public-addr /dns/localhost --base-path /tmp/test-duniter-local

This is for a simple dev chain. What you want here is a gdev_dev chain using a data file and a config file.

At the beginning, there was a single file genesis.json. But now, it has been split in two parts:

  • data (identities, wallets, initial monetary mass)
  • config (smith web of trust, session keys…)

Config file can be passed both in json or yaml. The files you can find in cucumber tests are a mix of both: end2end-tests/cucumber-genesis/default.json · master · nodes / rust / Duniter v2S · GitLab, that’s why they are passed in both environment variables: end2end-tests/tests/common/mod.rs · 315f93aea8aa909f21b55d567852870b5e1c7a14 · nodes / rust / Duniter v2S · GitLab.

You can use the same trick to have a single file with both data and config:

$ export EXAMPLE=/home/hugo/example.json
$ DUNITER_GENESIS_DATA=$EXAMPLE DUNITER_GENESIS_CONFIG=$EXAMPLE duniter key generate-node-key --chain=gdev_dev --base-path /tmp/test-duniter
Generating key in "/tmp/test-duniter/chains/gdev/network/secret_ed25519"
12D3KooWFdjdeRuFRcS7tNASm9vN9o4ZXrNNYZvTZJDqZMZQUtEw
$ DUNITER_GENESIS_DATA=$EXAMPLE DUNITER_GENESIS_CONFIG=$EXAMPLE duniter --chain=gdev_dev --force-authoring --alice --public-addr /dns/localhost --base-path /tmp/test-duniter
...

Some answers:

The monetary mass is data, not config.

What you generate here is chainspecs, which combines both config and data to give the state of block zero plus other things.

You can use a single file with this

      DUNITER_GENESIS_CONFIG: "/input/custom.json"
      DUNITER_GENESIS_DATA: "/input/custom.json"
    volumes:
      - duniter-data:/var/lib/duniter
      - ./input/custom.json:/input/custom.json
4 Likes
23

Merci beaucoup Hugo pour ta patience et tes explications détaillées !

J’ai utilisé le fichier que tu as mentionné (cucumber tests default.json) et avec la dernière image docker duniter/duniter-v2s-gdev-800 au 17/06/2025, il se passe ceci :

duniter-v2s-gdev-800  | thread 'main' panicked at node/src/chain_spec/gdev.rs:116:10:
duniter-v2s-gdev-800  | Genesis Data must be buildable: "Error parsing JSON gen conf file: missing field `distance_evaluation_period` at line 71 column 3"
duniter-v2s-gdev-800  | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

J’ajoute alors le champ distance_evaluation_period at line 71, avec une valeur au pif de 1000 :

    "wot_min_cert_for_create_idty_right": 2,
    "wot_min_cert_for_membership": 2,
    "distance_evaluation_period": 1000
  },
  "clique_smiths": [
    {
      "name": "Alice"
    },

Duniter se lance, mais ne crée pas de blocs… :cry:

Mais il me crée encore une node key automatiquement et ne se plaint pas de l’adresse publique non déclarée. Et il m’expose bien l’état de la wot et des forgerons tel que définis dans le fichier.
Je ne suis plus très loin du but !

duniter-v2s-gdev-800  | Generating node key file '/var/lib/duniter/node.key'...
duniter-v2s-gdev-800  | 12D3KooWGzfPQbzPh4QgwZ6iiFgvVTDD3HyH7v9tV8gh3Lrf32ct
duniter-v2s-gdev-800  | Node peer ID is '12D3KooWGzfPQbzPh4QgwZ6iiFgvVTDD3HyH7v9tV8gh3Lrf32ct'.
duniter-v2s-gdev-800  | Starting duniter with parameters: --name tikka_tests --node-key-file /var/lib/duniter/node.key --rpc-cors all --rpc-methods Unsafe --validator --state-pruning archive --blocks-pruning archive --chain gdev_dev -d /var/lib/duniter --unsafe-rpc-external
duniter-v2s-gdev-800  | It isn't safe to expose RPC publicly without a proxy server that filters available set of RPC methods.
duniter-v2s-gdev-800  | 2025-06-17 15:11:41 Duniter    
duniter-v2s-gdev-800  | 2025-06-17 15:11:41 ✌️  version 0.10.1-unknown    
duniter-v2s-gdev-800  | 2025-06-17 15:11:41 ❤️  by librelois <c@elo.tf>:tuxmain <tuxmain@zettascript.org>:c-geek <https://forum.duniter.org/u/cgeek>:HugoTrentesaux <https://trentesaux.fr>:bgallois <benjamin@gallois.cc>:Duniter Developers <https://duniter.org>:Axiom-Team Developers <https://axiom-team.fr>, 2021-2025    
duniter-v2s-gdev-800  | 2025-06-17 15:11:41 📋 Chain specification: Development    
duniter-v2s-gdev-800  | 2025-06-17 15:11:41 🏷  Node name: tikka_tests    
duniter-v2s-gdev-800  | 2025-06-17 15:11:41 👤 Role: AUTHORITY    
duniter-v2s-gdev-800  | 2025-06-17 15:11:41 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 🔨 Initializing Genesis block/state (state: 0x74f7…a5b9, header-hash: 0xe8ee…a0dc)    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47  creating SingleState txpool Limit { count: 8192, total_bytes: 20971520 }/Limit { count: 819, total_bytes: 2097152 }.    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 👶 Creating empty BABE epoch changes on what appears to be first startup.    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 Using default protocol ID "sup" because none is configured in the chain specs    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 Local node identity is: 12D3KooWGzfPQbzPh4QgwZ6iiFgvVTDD3HyH7v9tV8gh3Lrf32ct    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 Running litep2p network backend    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 👶 Starting BABE Authorship worker    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 Operating system: linux    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 CPU architecture: x86_64    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 Target environment: gnu    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 CPU: Intel(R) Core(TM) i3 CPU       M 370  @ 2.40GHz    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 CPU cores: 2    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 Memory: 7828MB    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 Kernel: 4.15.0-213-generic    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 💻 Virtual machine: no    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 📦 Highest known block at #0    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 〽️ Prometheus exporter started at 127.0.0.1:9615    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 Running JSON-RPC server: addr=0.0.0.0:9944,[::]:37025    
duniter-v2s-gdev-800  | 2025-06-17 15:11:47 ***** Duniter has fully started *****    
duniter-v2s-gdev-800  | 2025-06-17 15:11:48 🧙 [distance inherent] No published result at this block.    
duniter-v2s-gdev-800  | 2025-06-17 15:11:52 💤 Idle (0 peers), best: #0 (0xe8ee…a0dc), finalized #0 (0xe8ee…a0dc), ⬇ 0 ⬆ 0    
duniter-v2s-gdev-800  | 2025-06-17 15:11:54 🧙 [distance inherent] No published result at this block.    
duniter-v2s-gdev-800  | 2025-06-17 15:11:57 💤 Idle (0 peers), best: #0 (0xe8ee…a0dc), finalized #0 (0xe8ee…a0dc), ⬇ 0 ⬆ 0    
duniter-v2s-gdev-800  | 2025-06-17 15:12:00 🧙 [distance inherent] No published result at this block.    
duniter-v2s-gdev-800  | 2025-06-17 15:12:02 💤 Idle (0 peers), best: #0 (0xe8ee…a0dc), finalized #0 (0xe8ee…a0dc), ⬇ 0 ⬆ 0    
duniter-v2s-gdev-800  | 2025-06-17 15:12:06 🧙 [distance inherent] No published result at this block.    
duniter-v2s-gdev-800  | 2025-06-17 15:12:07 💤 Idle (0 peers), best: #0 (0xe8ee…a0dc), finalized #0 (0xe8ee…a0dc), ⬇ 0 ⬆ 0

Si quelqu’un a une idée de ce que j’ai oublié…

      DUNITER_GENESIS_CONFIG: "/input/cucumber_default.json"
      DUNITER_GENESIS_DATA: "/input/cucumber_default.json"
    volumes:
      - duniter-data:/var/lib/duniter
      - ./input/cucumber_default.json:/input/cucumber_default.json
1 Like
24

Moi aussi j’ai l’impression que désormais, DUNITER_GENESIS_DATA n’est plus considéré par duniter sur une chain de dev local.

Voici mon compose:

services:
  duniter-v2s-gecko-tests:
    container_name: duniter-v2s-gecko-tests
    image: duniter/duniter-v2s-gtest-1000:1000-0.11.1
    command: --alice --force-authoring --reserved-only --no-mdns
    #--sealing=manual
    ports:
      - "127.0.0.1:9615:9615"
      - "127.0.0.1:9933:9933"
      - "0.0.0.0:9944:9944"
      - "30333:30333"
    environment:
      DUNITER_INSTANCE_NAME: "gecko_tests"
      DUNITER_CHAIN_NAME: "dev"
      DUNITER_GENESIS_CONFIG: "/var/lib/duniter/gecko_config.json"
      DUNITER_GENESIS_DATA: "/var/lib/duniter/gecko_data.json"
    volumes:
      - ./data:/var/lib/duniter

Et mon /var/lib/duniter/gecko_data.json:

{
  "initial_monetary_mass": 90100,
  "current_block": {
    "number": 0,
    "medianTime": 1700000000
  },
  "identities": {
    "test1": {
      "index": 7,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "next_cert_issuable_on": 0,
      "certs_received": {
        "test2": 2700000000,
        "test3": 2700000000,
        "test4": 2700000000
      },
      "owner_pubkey": "BgC76sdA6zxPSAMW6sZ1e3NEntLrkLT8DY3z2MEmJJgK"
    },
    "test2": {
      "index": 1,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "next_cert_issuable_on": 0,
      "certs_received": {
        "test1": 2700000000,
        "test3": 2700000000,
        "test4": 2700000000
      },
      "owner_pubkey": "6xNFhRFHKyx9iZ3ucc3AFf5cjsWw5jH3p6EnFXw3D8T6"
    },
    "test3": {
      "index": 2,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "next_cert_issuable_on": 0,
      "certs_received": {
        "test1": 2700000000,
        "test2": 2700000000,
        "test4": 2700000000
      },
      "owner_pubkey": "BpSSPEVE1yze9wrfjkU4wfnFa7WgKNysHxe3H9iT9fvx"
    },
    "test4": {
      "index": 3,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "next_cert_issuable_on": 0,
      "certs_received": {
        "test1": 2700000000,
        "test2": 2700000000,
        "test3": 2700000000
      },
      "owner_pubkey": "5LqbvutJtRTHvnforyndwPbkC4Kf5cJtdRQaDcHoMi8S"
    },
    "test5": {
      "index": 4,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "next_cert_issuable_on": 0,
      "certs_received": {
        "test1": 2700000000,
        "test2": 2700000000,
        "test3": 2700000000
      },
      "owner_pubkey": "6FgzG8NwatTWHo7rM7sPP6P4Q95R2ZQNqYiHCs38RT21"
    },
    "test6": {
      "index": 5,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "next_cert_issuable_on": 0,
      "certs_received": {
        "test1": 2700000000
      },
      "owner_pubkey": "FZ8URw5rPqpWegWnufpcBDkg6tMpc2JmNZVCuPA9g3nq"
    },
    "testCesium1": {
      "index": 6,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "next_cert_issuable_on": 0,
      "certs_received": {
        "test1": 2700000000,
        "test2": 2700000000,
        "test3": 2700000000,
        "test4": 2700000000,
        "test5": 2700000000
      },
      "owner_pubkey": "DCovzCEnQm9GUWe6mr8u42JR1JAuoj3HbQUGdCkfTzSr"
    },
    "Alice": {
      "index": 8,
      "balance": 10000,
      "revoked": false,
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "certs_received": {
        "test1": 2700000000,
        "test2": 2700000000,
        "test3": 2700000000,
        "test4": 2700000000,
        "test5": 2700000000,
        "test6": 2700000000,
        "testCesium1": 2700000000
      },
      "owner_address": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
      "next_cert_issuable_on": 0
    }
  },
  "wallets": {
    "BPKBoTrrLD1XWmpZdRsfDnDT1M6PBBvgzPxAKNdutVV2": 10000
  }
}

Ici DCovzCEnQm9GUWe6mr8u42JR1JAuoj3HbQUGdCkfTzSr n’est pas membre et vide, alors qu’il devrait l’être au vue de ces data.

Je n’ai rien dans les logs duniter qui m’alerte d’une quelquonque erreur, même si je met n’importe quoi dans le json, des champs qui n’existent pas, ce qui n’est pas normal.

Ceci fonctionnait tel quel il y a un an.

Mais je vois par exemple que dans l’exemple pointé par @HugoTrentesaux on a des owner_address, alors que je suis sur des owner_pubkey en b58 de mon côté, donc je ne suis pas sûr de ce qui est attendu.

25

Pour que les fichiers soient pris en compte, il faut maintenant mettre ce nom pour la gdev :

DUNITER_CHAIN_NAME: "gdev_dev"

Je suppose donc qu’il faut mettre, pour la gtest :

DUNITER_CHAIN_NAME: "gtest_dev"

Pas pris le temps de tester de mon côté.
My two cents.

1 Like
26

DUNITER_CHAIN_NAME: "gdev_dev"
ou
DUNITER_CHAIN_NAME: "gtest_dev"

→ 

duniter-v2s-gecko-tests  | Node key file '/var/lib/duniter/node.key' exists.
duniter-v2s-gecko-tests  | Node peer ID is '12D3KooWMh72T1jqMBy9qbgRKmP9f8wwQ74kknExQxEDgidZc5A5'.
duniter-v2s-gecko-tests  | Starting duniter with parameters: --alice --force-authoring --reserved-only --no-mdns --name gecko_tests --node-key-file /var/lib/duniter/node.key --rpc-cors all --chain gdev_dev -d /var/lib/duniter --unsafe-rpc-external
duniter-v2s-gecko-tests  | thread 'main' panicked at node/src/command.rs:196:26:
duniter-v2s-gecko-tests  | unknown runtime
duniter-v2s-gecko-tests  | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
1 Like
27

Bon, je viens de tester en modifiant le fichier cucumber defaut.json avec les adresses au format gtest pour Alice, Bob et compagnie.

Maintenant l’image duniter/duniter-v2s-gtest-1000 crash en se plaignant que Bob est un membre inactif du comité technique…

duniter-v2s-gtest-1000  | Generating node key file '/var/lib/duniter/node.key'...
duniter-v2s-gtest-1000  | thread 'main' panicked at node/src/chain_spec/gen_genesis_data.rs:986:13:
duniter-v2s-gtest-1000  | Bob is an inactive technical commitee member
2 Likes
28

Edit: Oups là je suis aller un peu vite, en fait le runtime gtest_dev fonctionne sur les images pour gtest.

J’ai une autre erreur bien plus rassurante:

duniter-v2s-gecko-tests  | thread 'main' panicked at node/src/chain_spec/gen_genesis_data.rs:986:13:
duniter-v2s-gecko-tests  | test1 is an inactive technical commitee member

J’ai le même problème que toi du coup @vit

Le check existe dans Duniter depuis 20 mois par cgeek, mais ne faisait que loguer une erreur. Ca a été changé il y a 4 jours par Elois pour throw un panic à la place.

2 Likes
29

J’ai été très surpris par cette erreur, et je vois que ce paramètre est apparu dans le commit

que je n’avais pas regardé assez attentivement.

De toute façons c’est assez spécifique à la gdev qui permet de renseigner les paramètres de manière dynamique. Dans la gtest ce sera uniquement dans les constantes du runtime.

Je crois que c’est le entrypoint docker qui crée la clé si elle n’est pas là.

Je ne sais plus où on en est de ce paramètre, mais ça ne m’étonnerait pas qu’en mode dev substrate ne se plaigne pas.

On dirait que ton nœud ne crée pas de blocs parce qu’il n’a pas les session keys d’Alice qui sont dans le genesis. Il manque a priori une option --alice.

30

En mode “dev”, seul le compte Alice est automatiquement forcé comme identité active par défaut.
Si vous souhaitez intégrer d’autres comptes au comité technique, alors votre fichier indiqué par DUNITER_GENESIS_DATA doit déclarer comme identité membre non expirée tous les comptes qui sont membres du comité technique (sauf Alice).

Pour qu’une identité soit considérée comme non expirée, le fichier JSON indiqué par DUNITER_GENESIS_DATA doit définir le champ membership_expire_on pour ces identités à une valeur strictement supérieure à zéro.
Je recommande de définir cette valeur à celle du paramètre MembershipPeriod.

3 Likes
31

Les deux sont autorisés :

/// identities
#[derive(Clone, Deserialize, Serialize)]
struct IdentityV1 {
    /// indentity index matching the order of appearance in the Ǧ1v1 blockchain
    index: u32,
    /// Base58 public key in Ğ1v1
    owner_pubkey: Option<PubkeyV1>,
    /// Ğ1v2 address
    owner_address: Option<AccountId>,
    /// Optional Base58 public key in Ğ1v1
    old_owner_key: Option<PubkeyV1>,
    /// timestamp at which the membership is set to expire (0 for expired members)
    membership_expire_on: TimestampV1,
    /// timestamp at which the identity would be set as revoked (value in the past for already revoked identities)
    membership_revokes_on: TimestampV1,
    /// whether the identity is revoked (manually or automatically)
    revoked: bool,
    /// balance of the account of this identity
    balance: u64,
    /// certs received with their expiration timestamp
    certs_received: HashMap<String, TimestampV1>,
}

// [...]

genesis_data.identities.iter().for_each(|(name, i)| {
    if i.owner_pubkey.is_some() && i.owner_address.is_some() {
        log::warn!(
            "{} both has a pubkey and an address defined - address will be used",
            name
        );
    }
    if i.owner_pubkey.is_none() && i.owner_address.is_none() {
        log::error!("{} neither has a pubkey and an address defined", name);
    }
});

Ouf ça me rassure, j’étais en train de me demander ce qui pouvait se passer…

Et du coup la réponse d’elois suffit.

1 Like
32
  1. Le default.json cucumber de duniter semble être sur un ancien format car le block Identity est présent dans le fichier, alors qu’il me semble que désormais il est séparé dans un autre json DUNITER_GENESIS_DATA. Duniter ne veut pas démarrer sans fournir ce fichier. Je reprend donc ce json en déportant les identity dans un fichier data pour être sûr d’être sur une base commune.
  2. Malgré ça, sans rien changer au data, j’ai l’erreur:
duniter-v2s-gecko-tests  | Starting duniter with parameters: --alice --force-authoring --reserved-only --no-mdns --name gecko_tests --node-key-file /var/lib/duniter/node.key --rpc-cors all --chain gtest_dev -d /var/lib/duniter --unsafe-rpc-external
duniter-v2s-gecko-tests  | thread 'main' panicked at node/src/chain_spec/gen_genesis_data.rs:986:13:
duniter-v2s-gecko-tests  | Bob is an inactive technical commitee member
duniter-v2s-gecko-tests  | stack backtrace:
duniter-v2s-gecko-tests  |    0: rust_begin_unwind
duniter-v2s-gecko-tests  |    1: core::panicking::panic_fmt
duniter-v2s-gecko-tests  |    2: duniter::chain_spec::gen_genesis_data::smiths_and_technical_committee_checks
duniter-v2s-gecko-tests  |    3: duniter::chain_spec::gen_genesis_data::generate_genesis_data
duniter-v2s-gecko-tests  |    4: duniter::chain_spec::gtest::development_chainspecs
duniter-v2s-gecko-tests  |    5: duniter::command::<impl sc_cli::SubstrateCli for duniter::cli::Cli>::load_spec
duniter-v2s-gecko-tests  |    6: sc_cli::config::CliConfiguration::create_configuration
duniter-v2s-gecko-tests exited with code 101
duniter-v2s-gecko-tests  |    7: duniter::command::run

Voici mes données donc:

docker compose:

services:
  duniter-v2s-gecko-tests:
    container_name: duniter-v2s-gecko-tests
    image: duniter/duniter-v2s-gtest-1000:1000-0.11.1
    command: --alice --force-authoring --reserved-only --no-mdns
    #--sealing=manual
    ports:
      - "127.0.0.1:9615:9615"
      - "127.0.0.1:9933:9933"
      - "0.0.0.0:9944:9944"
      - "30333:30333"
    environment:
      RUST_BACKTRACE: "1"
      DUNITER_INSTANCE_NAME: "gecko_tests"
      DUNITER_CHAIN_NAME: "gtest_dev"
      DUNITER_GENESIS_CONFIG: "/var/lib/duniter/gecko_config.json"
      DUNITER_GENESIS_DATA: "/var/lib/duniter/gecko_data.json"
    volumes:
      - ./data:/var/lib/duniter

gecko_config.json:

{
  "first_ud": null,
  "first_ud_reeval": null,
  "genesis_parameters": {
    "genesis_certs_expire_on": 1000,
    "genesis_certs_min_received": 2,
    "genesis_memberships_expire_on": 1000,
    "genesis_smith_certs_expire_on": 1000,
    "genesis_smith_certs_min_received": 2,
    "genesis_smith_memberships_expire_on": 100000
  },
  "parameters": {
    "babe_epoch_duration": 30,
    "cert_period": 15,
    "cert_max_by_issuer": 10,
    "cert_min_received_cert_to_issue_cert": 2,
    "cert_validity_period": 1000,
    "idty_confirm_period": 40,
    "idty_creation_period": 50,
    "membership_period": 1000,
    "membership_renewal_period": 500,
    "ud_creation_period": 60000,
    "ud_reeval_period": 600000,
    "smith_cert_max_by_issuer": 8,
    "smith_inactivity_max_duration": 48,
    "smith_wot_min_cert_for_membership": 2,
    "wot_first_cert_issuable_on": 20,
    "wot_min_cert_for_create_idty_right": 2,
    "wot_min_cert_for_membership": 2
  },
  "clique_smiths": [
    {
      "name": "Alice"
    },
    {
      "name": "Bob"
    },
    {
      "name": "Charlie"
    }
  ],
  "sudo_key": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
  "technical_committee": [
    "Alice",
    "Bob",
    "Charlie"
  ],
  "treasury_funder_pubkey": "FHNpKmJrUtusuvKPGomAygQqeiks98bdV6yD61Stb6vg",
  "ud": 1000,
  "initial_monetary_mass": 3000,
  "current_block": {
    "number": 0,
    "medianTime": 1700000000
  }
}

gecko_data.json:

{
  "initial_monetary_mass": 4000,
  "current_block": {
      "number": 0,
      "medianTime": 1700000000
  },
  "identities": {
    "Alice": {
      "index": 1,
      "balance": 1000,
      "certs_received": {
        "Bob": 2700000000,
        "Charlie": 2700000000
      },
      "owner_address": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY",
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "revoked": false,
      "next_cert_issuable_on": 0
    },
    "Bob": {
      "index": 2,
      "balance": 1000,
      "certs_received": {
        "Alice": 2700000000,
        "Charlie": 2700000000
      },
      "owner_address": "5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty",
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "revoked": false,
      "next_cert_issuable_on": 0
    },
    "Charlie": {
      "index": 3,
      "balance": 1000,
      "certs_received": {
        "Alice": 2700000000,
        "Bob": 2700000000
      },
      "owner_address": "5FLSigC9HGRKVhB9FiEo4Y3koPsNmBmLJbpXg2mp1hXcS59Y",
      "membership_expire_on": 2700000000,
      "membership_revokes_on": 2700000001,
      "revoked": false,
      "next_cert_issuable_on": 0
    }
  },
  "wallets": {
      "BPKBoTrrLD1XWmpZdRsfDnDT1M6PBBvgzPxAKNdutVV2": 1000
  }
}

Je vous met tout ça car je bloque dessus depuis 1h30 a essayer plein de truc, malgré les conseils d’elois je ne comprends pas, mes identités sont censé être membre, Alice est présente au comité, et de toute façon je n’ai fait que copier l’exemple du test cucumber de Duniter sans rien changer, donc je ne comprends pas.

33

@poka Le runtime gtest ne permet pas de configurer dynamiquement les paramètres de la WoT ; seul le runtime gdev le permet.

Tes trois comptes ne sont pas membres, car dans la gtest, le paramètre MinReceivedCertToBeAbleToIssueCert vaut 5.

Il te faut donc une clique d’au moins six membres.

EDIT: Même logique pour tout le reste : tu dois t’assurer que ta WoT initiale respecte tous les paramètres de la gtest.

2 Likes
34

Merci je pense effectivement que le soucis venait de là.
Du coup je vais rester sur les images gdev pour mes tests locaux, car j’aimerais pouvoir définir les valeurs de wot que je veux.

Je partirai donc sur cette image demain à priori, qui semble la plus à jour pour la gdev, d’il y a 3 mois.

edit: oui en fait ça fonctionne très bien sur cette image. Merci pour ces précieuses infos.

1 Like
35

Merci à tous les deux, ça fonctionne aussi chez moi ! C’était le paramètre command du docker que j’avais commenté il y a longtemps et qui manquait pour calculer des blocs.

Mais je tombe sur une bizarrerie qui fait planter Tikka qui s’attend à un entier pour le Babe.EpochIndex (pour le calcul des expirations données en epoch) :

Babe.EpochIndex == None au lieu de 0.

Pourtant les logs parlent bien d’un epoch index à #0 :

duniter-v2s-gdev-800  | 2025-07-18 13:25:06 👶 New epoch 0 launching at block 0xba98…e50e (block slot 292140851 >= start slot 292140851).    
duniter-v2s-gdev-800  | 2025-07-18 13:25:06 👶 Next epoch starts at slot 292140881    
duniter-v2s-gdev-800  | 2025-07-18 13:25:06 🏆 Imported #1 (0x74d0…e431 → 0xba98…e50e)

L’epoch suivant est bien à 1, lui.

36

Bon ben les soucis continuent…

Avec la dernière image docker de la gdev en local (“gdev_dev” avec fichier config custom) :

Attaching to duniter-v2s-gdev-800
duniter-v2s-gdev-800  | Generating node key file '/var/lib/duniter/node.key'...
duniter-v2s-gdev-800  | 12D3KooWJFnW2zD1PVq8NRtMgPdXzWzKXQeAKnkThcgK6JbV8319
duniter-v2s-gdev-800  | Node peer ID is '12D3KooWJFnW2zD1PVq8NRtMgPdXzWzKXQeAKnkThcgK6JbV8319'.
duniter-v2s-gdev-800  | Starting duniter with parameters: --alice --force-authoring --reserved-only --no-mdns --name tikka_tests --node-key-file /var/lib/duniter/node.key --rpc-cors all --rpc-methods Unsafe --validator --state-pruning archive --blocks-pruning archive --chain gdev_dev -d /var/lib/duniter --unsafe-rpc-external
duniter-v2s-gdev-800  | It isn't safe to expose RPC publicly without a proxy server that filters available set of RPC methods.
duniter-v2s-gdev-800  | 2025-07-21 18:53:08 Duniter    
duniter-v2s-gdev-800  | 2025-07-21 18:53:08 ✌️  version 0.10.1-unknown

L’envoi d’un extrinsic pour inviter un membre à être forgeron remonte une erreur de runtime !

Alice (forgeron et authoritée) invite Dave (membre non forgeron) à être forgeron.

DEBUG:root:socket 40 - retry 0 - RPC request #5: "author_submitAndWatchExtrinsic"
DEBUG:root:RPC request #5 params: "['0xb1018400d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d0174458ba06a0498224690bfcbc58d30e3b7a928e2a569bc94ead67ae84f40e5060d7c08e4cc88f3bb03ca001b3215ca1606c60e2a52f141af52271e714e9d37850000000a0004000000']"
ERROR:root:{'code': 1002, 'message': 'Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\nWASM backtrace:\nerror while executing at wasm backtrace:\n    0: 0x22b14d - gdev_runtime.wasm!rust_begin_unwind\n    1: 0xa243 - gdev_runtime.wasm!core::panicking::panic_fmt::he59b74c39a87eed5\n    2: 0x2082c7 - gdev_runtime.wasm!TaggedTransactionQueue_validate_transaction', 'data': 'RuntimeApi("Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\\nWASM backtrace:\\nerror while executing at wasm backtrace:\\n    0: 0x22b14d - gdev_runtime.wasm!rust_begin_unwind\\n    1: 0xa243 - gdev_runtime.wasm!core::panicking::panic_fmt::he59b74c39a87eed5\\n    2: 0x2082c7 - gdev_runtime.wasm!TaggedTransactionQueue_validate_transaction")'}

Ne serait-ce pas le besoin de faire tourner un oracle maintenant ?

Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed

EDIT :
J’ai cette erreur sur tous les extrinsics que j’envoie sur le docker local (même un simple virement)…!!!
Même avec un container dont le chain name est “dev”, sans fichiers de config/data custom.
Alors que Tikka fonctionne sur les blockchains gtest et gdev non locales.

37

J’ai résolu le problème de l’erreur 1002 !

Tikka télécharge les metadata depuis le serveur Duniter et les sauve sous la version du runtime.
Pour le container docker de la gdev, la version sauvegardée depuis mars/avril était la 900.

Si un fichier de metadata existe déjà sur le disque, Tikka ne télécharge pas les métadata, mais les charge depuis le disque.

Le problème était que les metadatas sauvegardée pour le runtume 900, étaient obsolètes !
Effacer le fichier pour forcer Tikka à télécharger à nouveau les metadatas a corrigé le problème !

Il y a donc eu des modifications de metadata entre deux runtimes 900.

Comment faire pour être sûr que les metadatas en cache sur le disque correspondent à la même version du runtime que celle du serveur ?
Via un hash racine des metadatas ou une donnée de version de runtime plus fine que le 900 ?

Je vais chercher de mon côté, mais si quelqu’un a une idée pour que je gagne du temps…
[EDIT]
Corrigé ! il n’existe pas de hash des metadatas apparemment, mais je me base maintenant sur l’appel RPC system_version qui est bien plus précis en terme de versioning.

2 Likes
38

Pour information, les addresses des comptes Alice, Bob, Eve, etc semblent être en SR25519 dans l’image docker de dev de la gtest.

Ne devraient-elles pas être en ED25519 comme les addresses issues de la V1 de la gtest en ligne ?

2 Likes