$ cat data/gtest.json | jq .identities[].certs[] | grep "7Daniel" | wc -l
9
$ DUNITER_GENESIS_CONFIG=data/gtest.json cargo run -- --tmp --chain dev
Finished dev [unoptimized + debuginfo] target(s) in 0.51s
Running `target/debug/duniter --tmp --chain dev`
[node/src/chain_spec/gen_genesis_data.rs:264] receiver_certs = {}
Error: Input("Identity n°12 “7Daniel” has received only 0/1 certifications)")
Ah mais j’ai compris je pense !
C’est que la fonction de parsing qui fait ça côté v2s le fait de manière linéaire, donc il y aura forcément des identité déclarés avant qu’elles aient reçus leurs certifications !
Je ne sais pas comment ordonner ça du coup, je ne sais même pas si il y a un ordre possible pour ça !
J’ai l’impression que cela nécessite de changer un peu le parsing ici côté v2s.
Sinon il faut mettre genesis_certs_min_received à 0, du coup le parsing passe, la blockchain démarre, et finit avec ce panic:
$ DUNITER_GENESIS_CONFIG=data/gtest.json cargo run -- --tmp --chain dev
Finished dev [unoptimized + debuginfo] target(s) in 0.51s
Running `target/debug/duniter --tmp --chain dev`
2022-10-06 23:05:52 Duniter
2022-10-06 23:05:52 ✌️ version 0.3.0-3761ec6efe7
2022-10-06 23:05:52 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2022
2022-10-06 23:05:52 📋 Chain specification: Development
2022-10-06 23:05:52 🏷 Node name: false-gate-0190
2022-10-06 23:05:52 👤 Role: FULL
2022-10-06 23:05:52 💾 Database: ParityDb at /tmp/substrateYfre3H/chains/gdev/paritydb/full
2022-10-06 23:05:52 ⛓ Native runtime: gdev-400 (duniter-gdev-1.tx1.au1)
====================
Version: 0.3.0-3761ec6efe7
0: sp_panic_handler::panic_hook
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/primitives/panic-handler/src/lib.rs:166:18
1: sp_panic_handler::set::{{closure}}
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/primitives/panic-handler/src/lib.rs:62:12
2: std::panicking::rust_panic_with_hook
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panicking.rs:702:17
3: std::panicking::begin_panic_handler::{{closure}}
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panicking.rs:586:13
4: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/sys_common/backtrace.rs:138:18
5: rust_begin_unwind
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panicking.rs:584:5
6: core::panicking::panic_fmt
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/core/src/panicking.rs:142:14
7: <pallet_session::pallet::GenesisConfig<T> as frame_support::traits::hooks::GenesisBuild<T>>::build
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/frame/session/src/lib.rs:469:4
8: <pallet_session::pallet::GenesisConfig<T> as sp_runtime::BuildModuleGenesisStorage<T,()>>::build_module_genesis_storage::{{closure}}
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/frame/session/src/lib.rs:429:12
9: environmental::using::{{closure}}
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/environmental-1.1.3/src/lib.rs:125:3
10: std::thread::local::LocalKey<T>::try_with
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/thread/local.rs:443:16
11: std::thread::local::LocalKey<T>::with
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/thread/local.rs:419:9
12: environmental::using
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/environmental-1.1.3/src/lib.rs:106:2
13: sp_externalities::scope_limited::ext::using
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/environmental-1.1.3/src/lib.rs:252:5
14: sp_externalities::scope_limited::set_and_run_with_externalities
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/primitives/externalities/src/scope_limited.rs:31:2
15: sp_state_machine::basic::BasicExternalities::execute_with
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/primitives/state-machine/src/basic.rs:95:3
16: sp_state_machine::basic::BasicExternalities::execute_with_storage
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/primitives/state-machine/src/basic.rs:84:11
17: <pallet_session::pallet::GenesisConfig<T> as sp_runtime::BuildModuleGenesisStorage<T,()>>::build_module_genesis_storage
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/frame/session/src/lib.rs:364:1
18: <gdev_runtime::GenesisConfig as sp_runtime::BuildStorage>::assimilate_storage
at runtime/gdev/src/lib.rs:269:1
19: sp_runtime::BuildStorage::build_storage
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/primitives/runtime/src/lib.rs:188:3
20: <sc_chain_spec::chain_spec::ChainSpec<G,E> as sp_runtime::BuildStorage>::build_storage
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/client/chain-spec/src/chain_spec.rs:105:28
21: sc_service::client::client::Client<B,E,Block,RA>::new
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/client/service/src/client/client.rs:364:5
22: sc_service::builder::new_client
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/client/service/src/builder.rs:310:2
23: sc_service::builder::new_full_parts
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/client/service/src/builder.rs:239:16
24: duniter::service::new_partial
at node/src/service.rs:262:9
25: duniter::service::new_full
at node/src/service.rs:373:9
26: duniter::command::run::{{closure}}::{{closure}}
at node/src/command.rs:406:25
27: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/core/src/future/mod.rs:91:19
28: tokio::park::thread::CachedParkThread::block_on::{{closure}}
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/park/thread.rs:263:54
29: tokio::coop::with_budget::{{closure}}
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/coop.rs:102:9
30: std::thread::local::LocalKey<T>::try_with
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/thread/local.rs:443:16
31: std::thread::local::LocalKey<T>::with
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/thread/local.rs:419:9
32: tokio::coop::with_budget
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/coop.rs:95:5
tokio::coop::budget
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/coop.rs:72:5
tokio::park::thread::CachedParkThread::block_on
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/park/thread.rs:263:31
33: tokio::runtime::enter::Enter::block_on
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/runtime/enter.rs:152:13
34: tokio::runtime::thread_pool::ThreadPool::block_on
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/runtime/thread_pool/mod.rs:90:9
35: tokio::runtime::Runtime::block_on
at /home/poka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.20.0/src/runtime/mod.rs:484:43
36: sc_cli::runner::Runner<C>::run_node_until_exit
at /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/client/cli/src/runner.rs:148:26
37: duniter::command::run
at node/src/command.rs:385:13
38: duniter::main
at node/src/main.rs:29:5
39: core::ops::function::FnOnce::call_once
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/core/src/ops/function.rs:248:5
40: std::sys_common::backtrace::__rust_begin_short_backtrace
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/sys_common/backtrace.rs:122:18
41: std::rt::lang_start::{{closure}}
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/rt.rs:145:18
42: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/core/src/ops/function.rs:280:13
std::panicking::try::do_call
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panicking.rs:492:40
std::panicking::try
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panicking.rs:456:19
std::panic::catch_unwind
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panic.rs:137:14
std::rt::lang_start_internal::{{closure}}
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/rt.rs:128:48
std::panicking::try::do_call
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panicking.rs:492:40
std::panicking::try
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panicking.rs:456:19
std::panic::catch_unwind
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/panic.rs:137:14
std::rt::lang_start_internal
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/rt.rs:128:20
43: std::rt::lang_start
at /rustc/4ca19e09d302a4cbde14f9cb1bc109179dc824cd/library/std/src/rt.rs:144:17
44: main
45: __libc_start_main
at /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
46: _start
Thread 'main' panicked at 'Empty validator set for session 0 in genesis block!', /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/frame/session/src/lib.rs:469
This is a bug. Please report it at:
support.anonymous.an
Et j’ai l’impression que c’est un autre soucis Empty validator set for session 0 in genesis block!, donc ça « corrigerais » ce premier problème.
Sur ce second soucis, je ne comprends pas car il y a bien suffisament de smiths:
"smiths": {
"poka": {
"certs": [
"elois",
"HugoTrentesaux",
"vit",
"tuxmain"
]
},
"elois": {
"certs": [
"HugoTrentesaux",
"vit",
"tuxmain",
"poka"
]
},
"HugoTrentesaux": {
"certs": [
"elois",
"vit",
"tuxmain",
"poka"
]
},
"vit": {
"certs": [
"elois",
"HugoTrentesaux",
"tuxmain",
"poka"
]
},
"tuxmain": {
"certs": [
"elois",
"HugoTrentesaux",
"vit",
"poka"
]
}
},
Et je n’ai jamais eu besoin de configurer de session_keys ou autre pour les blockchains de dev local
Non, il y a bien une première boucle qui indexe les identités, puis une autre pour les certifications. C’est bizarre…
1 Like
C’est ce que j’ai vue à l’instant du coup, obligé sinon la première identité ne passerais forcément pas…
En fait j’ai l’impression que pour chaque identité, on liste ses certificateurs (donc on a dû mettre certaines certifs à l’envers dans gdev.json).
Pour vérifier par l’expérience : dans gdev.json il y a 7 certifications sur mon identité, et je suis référencé par 9 identités. En lançant une gdev, l’entrée de storage cert.certs_by_receiver correspondant à mon identité contient 7 identités.
Et je n’avais pas vu que idty_index commençait à 1, donc pour avoir le nom de l’identité pour le debug il faut mettre identities_[*idty_index as usize-1].0. On voit alors que 77ZenAll n’a aucune certification. Soit tu as échangé certifications reçues et émises, soit ta liste d’identités contient des non-membres par manque de certifications. (le idty_index suit l’ordre alphabétique)
3 Likes
Non il n’y a que les membres actuels. Je n’ai pas inversé par inadvertance, c’est que j’étais persuadé que le genesis attendait les certs envoyés, pas reçus (et je pense pas être le seul a penser ça).
J’ai donc régénéré le json avec cette fois ci les certs reçus par identités.
Cette fois ci c’est:
Error: Input("Identity n°206 “Amaralar” has received only 0/1 certifications)")
Dans Cesium je vois pourtant Amaralar membre et ayant 5 certificateurs, mais qui date du 3 octobre (il y a 4 jours) pour la plus vieille.
Mais c’est le cas aussi pour Javilion par exemple dont la première certif date du 17 septembre dernier. Je ne trouve pas de profile vide avec des certifs plus vieille que cette date.
On voit que ça concerne 31 personnes dans ce json qui ont un bloc certs vide.
Je pense donc que ce sont des données de DataJune qui ne sont pas à jours. Je peux filtrer ces profiles sans certs, mais je voudrais m’assurer que cela proviens bien de données DataJune non à jours @HugoTrentesaux
Mais ce qui m’étonne c’est que le username Javilion apparait dans la listes de user DataJune, mais visiblement pas ses certifications (a moins que ce soit un soucis dans mon parsing, j’ai fait cette modif issuer/receiver en 10 minutes).
2 Likes
Donc si je filtre les comptes sans certs, avec genesis_certs_min_received à 1, ça passe bien, mais la blockchain finit toujours avec le même Panic:
Thread 'main' panicked at 'Empty validator set for session 0 in genesis block!', /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/frame/session/src/lib.rs:469
Par contre là je ne sais pas du tout ce qu’il manque au genesis pour set les validateurs, pour moi les déclarer et certifer dans le bloc smiths suffit.
Cette erreur n’apparait pas dans le code de Duniter, ça proviens de Substrate directement, donc nécessite de comprendre le mécanisme en jeu derrière.
Je n’ai rien renseigné comme config dans le dossier runtime par exemple, il y a probablement des configs à faire ailleurs que dans le json genesis, si quelqu’un peut m’aiguiller là dessus je veux bien.
Il te faut au moins un smith avec des session keys je pense.
Exemple :
"smiths": {
"Elois": {
"certs": ["poka", "cgeek", "vit", "tuxmain", "HugoTrentesaux", "kapis"],
"session_keys": "0x92743b12d55242276539d7256951cdfda85371caefbd325396da9331011b737d14084d2537f77e786a75b9bcbe351051fad52946ec211724b5e8c93bb8aa7a6f14084d2537f77e786a75b9bcbe351051fad52946ec211724b5e8c93bb8aa7a6f14084d2537f77e786a75b9bcbe351051fad52946ec211724b5e8c93bb8aa7a6f"
},
"Elois2": {
"certs": ["tuxmain", "Elois", "HugoTrentesaux"]
},
Tu as déjà des indications dans launch-a-live-network.md sur comment générer des session keys, même si je suis en train de compléter dans la MR !114 (ticket #91)
1 Like
Il faut définir des sessions keys pour au moins 1 smith.
Mais c’est quoi que tu essayes de lancer à partir de ce genesis ? Une blockchain locale de dev ou un live network ? Parce que dans le second cas c’est bien plus compliqué il y a plein d’étapes supplémentaires, @HugoTrentesaux est en train de documenter ça suite à notre visio.
Aussi je répète mon précédent post, mais je pense que pour la vraie migration il ne faudra surtout pas vous baser sur GVA, mais extraire directement les données de la bdd de duniter v1 avec un outil comme dex ou autre.
1 Like
Je crois que l’inquiétude de poka est :
Une blockchain local de dev bien sûr, pour commencer.
D’accords, donc pas Dex car la DB Rust sur l’indexation des transactions est peut être corrompu.
Je n’ai jamais eu besoin de créer ou ajouter de sessions keys pour mes blockchains de dev locales.
$ docker run --rm -it --entrypoint duniter duniter/duniter-v2s:debug-latest key generate-session-keys --chain dev --suri "noble stay fury mean poverty delay stadium organ evil east vague can"
grandpa: 5F7qdiJjrCu5xLETrmKJeW4FcKNiHEMWUTrBs4tGRJxWgdF2
babe: 5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3
im_online: 5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3
authority_discovery: 5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3
Session Keys: 0x87189d723e1b2826c243bc433c718ac26ba60526932216a09102a254d54462b890a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d62
"smiths": {
"poka_root": {
"certs": [
"elois",
"HugoTrentesaux",
"vit",
"poka",
"tuxmain"
],
"session_keys": "0x87189d723e1b2826c243bc433c718ac26ba60526932216a09102a254d54462b890a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d62"
},
"identities": {
"poka_root": {
"balance": 10000,
"certs": [
"roodinux",
"OrAnge",
"Skarlett",
"Hera",
"CiaoBellaCarina",
"Lol",
"Ninamaste",
"poka"
],
"pubkey": "5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3"
},
Error: Input("session_keys field forbidden")
Mais encore une fois je ne cherche pas a faire un live network ici, je vois pas pourquoi j’aurais besoin de sessions_keys.
Je ne comprends pas pourquoi tout fonctionne parfaitement avec ce json: integration_test/duniter/data/gecko_tests.json · master · clients / Ğecko · GitLab
Mais pas avec celui-ci: https://git.duniter.org/pokapow/py-g1-migration/-/raw/master/gtest.json
1 Like
dex permet d’accéder à toutes les DB, y compris à la DB leveldb de référence utilisée par le code en nodejs (à condition que le nœud duniter-v1 soit éteint le temps de l’export), c’est cette DB de référence qu’il faut utiliser.
Car pour les blockchain de dev locales, le code de génération des raw spec assume que seule la 1ère identité est dans le set des autorités au genesis, et que ses sessions keys correspondent aux clés du compte de test //Alice.
Tu as toujours besoin de session keys, c’est juste que dans le cas particulier d’une blockchain locale de dev elles sont automatiquement set avec les credentials du compte de test //Alice et affectées à l’identité n°1.
Il en résulte que l’identité avec le nom le plus haut dans l’ordre alphanumérique doit faire partie des membres forgerons, c’est peut-être ça qui coince dans ton json.
2 Likes
Mais oui c’était juste ça, merci !!
En plus on a un bol absolu, car l’identité n°1 alphabétiquement dans la Ğ1, c’est 1000i100 mdr
Donc si je résume pour @1000i100 , pour fix le bug, il suffit de te rajouter dans la toile forgerons, tu n’a pas le choix, sinon on peut pas migrer la Ğ1, c’est quasiment écrit dans le code mdr
Tu es notre Alice de la Ğ1.
Donc le fix est coté py-g1-migration:
smiths.update({'1000i100': {'certs': ['elois', 'HugoTrentesaux', 'vit', 'poka']}})
→
"1000i100": {
"certs": [
"elois",
"HugoTrentesaux",
"vit",
"poka"
]
}
→
$ rm -rf data/chains/ && docker compose up
[+] Running 1/0
⠿ Container duniter-v2s Created 0.0s
Attaching to duniter-v2s
duniter-v2s | Starting duniter with parameters: --name duniter_local --dev -d /var/lib/duniter --unsafe-rpc-external --unsafe-ws-external
duniter-v2s | 2022-10-07 22:20:22 Duniter
duniter-v2s | 2022-10-07 22:20:22 ✌️ version 0.3.0-386e4d846c7
duniter-v2s | 2022-10-07 22:20:22 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2022
duniter-v2s | 2022-10-07 22:20:22 📋 Chain specification: Development
duniter-v2s | 2022-10-07 22:20:22 🏷 Node name: duniter_local
duniter-v2s | 2022-10-07 22:20:22 👤 Role: AUTHORITY
duniter-v2s | 2022-10-07 22:20:22 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full
duniter-v2s | 2022-10-07 22:20:22 ⛓ Native runtime: gdev-300 (duniter-gdev-1.tx1.au1)
duniter-v2s | 2022-10-07 22:20:27 🔨 Initializing Genesis block/state (state: 0xc9f0…2757, header-hash: 0x3774…66ab)
duniter-v2s | 2022-10-07 22:20:28 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
duniter-v2s | 2022-10-07 22:20:29 👶 Creating empty BABE epoch changes on what appears to be first startup.
duniter-v2s | 2022-10-07 22:20:29 Using default protocol ID "sup" because none is configured in the chain specs
duniter-v2s | 2022-10-07 22:20:29 🏷 Local node identity is: 12D3KooWDGfNB6Cit5YHx1ExWMYWvBdYdbfQXdSKzvyfEz9yJ2bj
duniter-v2s | 2022-10-07 22:20:29 👶 Starting BABE Authorship worker
duniter-v2s | 2022-10-07 22:20:30 💻 Operating system: linux
duniter-v2s | 2022-10-07 22:20:30 💻 CPU architecture: x86_64
duniter-v2s | 2022-10-07 22:20:30 💻 Target environment: gnu
duniter-v2s | 2022-10-07 22:20:30 💻 CPU: AMD Ryzen 7 3700X 8-Core Processor
duniter-v2s | 2022-10-07 22:20:30 💻 CPU cores: 8
duniter-v2s | 2022-10-07 22:20:30 💻 Memory: 32044MB
duniter-v2s | 2022-10-07 22:20:30 💻 Kernel: 5.15.0-43-generic
duniter-v2s | 2022-10-07 22:20:30 💻 Linux distribution: Debian GNU/Linux 10 (buster)
duniter-v2s | 2022-10-07 22:20:30 💻 Virtual machine: no
duniter-v2s | 2022-10-07 22:20:30 📦 Highest known block at #0
duniter-v2s | 2022-10-07 22:20:30 〽️ Prometheus exporter started at 127.0.0.1:9615
duniter-v2s | 2022-10-07 22:20:30 Running JSON-RPC HTTP server: addr=0.0.0.0:9933, allowed origins=None
duniter-v2s | 2022-10-07 22:20:30 Running JSON-RPC WS server: addr=0.0.0.0:9944, allowed origins=None
duniter-v2s | 2022-10-07 22:20:30 ***** Duniter has fully started *****
duniter-v2s | 2022-10-07 22:20:30 🙌 Starting consensus session on top of parent 0x3774b04331fd44538c8e0574622bc68afe69b7ed91ca0b8c81225a77315a66ab
duniter-v2s | 2022-10-07 22:20:30 🎁 Prepared block for proposing at 1 (8 ms) [hash: 0x0b940f27ea4f9d98448b5ffacecef9e5df4c9468fd42814e353635bc7ae8690e; parent_hash: 0x3774…66ab; extrinsics (1): [0xaaba…1240]]
duniter-v2s | 2022-10-07 22:20:30 🔖 Pre-sealed block for proposal at 1. Hash now 0x0beb699f048426a4f3b690aed73e8f309c0079c45b2e0949b8c64e2f803f809c, previously 0x0b940f27ea4f9d98448b5ffacecef9e5df4c9468fd42814e353635bc7ae8690e.
duniter-v2s | 2022-10-07 22:20:30 👶 New epoch 0 launching at block 0x0beb…809c (block slot 277530205 >= start slot 277530205).
duniter-v2s | 2022-10-07 22:20:30 👶 Next epoch starts at slot 277530805
duniter-v2s | 2022-10-07 22:20:30 ✨ Imported #1 (0x0beb…809c)
duniter-v2s | 2022-10-07 22:20:35 💤 Idle (0 peers), best: #1 (0x0beb…809c), finalized #0 (0x3774…66ab), ⬇ 0 ⬆ 0
duniter-v2s | 2022-10-07 22:20:36 🙌 Starting consensus session on top of parent 0x0beb699f048426a4f3b690aed73e8f309c0079c45b2e0949b8c64e2f803f809c
duniter-v2s | 2022-10-07 22:20:36 🎁 Prepared block for proposing at 2 (3 ms) [hash: 0x9fd10c63d3a2ac37a71b42a2206989cad7883ec3bb695d337e595a7030da6994; parent_hash: 0x0beb…809c; extrinsics (1): [0x7273…de88]]
duniter-v2s | 2022-10-07 22:20:36 🔖 Pre-sealed block for proposal at 2. Hash now 0xf18b30a8b82e3f70013268293b6b4fb1bd6e2881f04bc01086bb038901eabdca, previously 0x9fd10c63d3a2ac37a71b42a2206989cad7883ec3bb695d337e595a7030da6994.
duniter-v2s | 2022-10-07 22:20:36 ✨ Imported #2 (0xf18b…bdca)
duniter-v2s | 2022-10-07 22:20:40 💤 Idle (0 peers), best: #2 (0xf18b…bdca), finalized #0 (0x3774…66ab), ⬇ 0 ⬆ 0
duniter-v2s | 2022-10-07 22:20:42 🙌 Starting consensus session on top of parent 0xf18b30a8b82e3f70013268293b6b4fb1bd6e2881f04bc01086bb038901eabdca
duniter-v2s | 2022-10-07 22:20:42 🎁 Prepared block for proposing at 3 (4 ms) [hash: 0x2d479de798b1b2ef8323da3643b06287e5352c3fde17df9de276897a59e3faf5; parent_hash: 0xf18b…bdca; extrinsics (1): [0x747f…b930]]
duniter-v2s | 2022-10-07 22:20:42 🔖 Pre-sealed block for proposal at 3. Hash now 0xa50dd48cd420139e25841a4cf9ebfc0eae63d30e63882dd3c0592b7488ce7572, previously 0x2d479de798b1b2ef8323da3643b06287e5352c3fde17df9de276897a59e3faf5.
duniter-v2s | 2022-10-07 22:20:42 ✨ Imported #3 (0xa50d…7572)
duniter-v2s | 2022-10-07 22:20:45 💤 Idle (0 peers), best: #3 (0xa50d…7572), finalized #0 (0x3774…66ab), ⬇ 0 ⬆ 0
duniter-v2s | 2022-10-07 22:20:48 🙌 Starting consensus session on top of parent 0xa50dd48cd420139e25841a4cf9ebfc0eae63d30e63882dd3c0592b7488ce7572
duniter-v2s | 2022-10-07 22:20:48 🎁 Prepared block for proposing at 4 (4 ms) [hash: 0x115496e52c130875bdcf7e2df5c56c31c585ebad2bddedcbe8b626a3844b8638; parent_hash: 0xa50d…7572; extrinsics (1): [0x205f…af66]]
duniter-v2s | 2022-10-07 22:20:48 🔖 Pre-sealed block for proposal at 4. Hash now 0xf95a391ed460ab53383b10abfb67ab33803175a5c7b11357a343bb2a67deadf6, previously 0x115496e52c130875bdcf7e2df5c56c31c585ebad2bddedcbe8b626a3844b8638.
J’ai une (quasi) ĞTest v2s en local ! 
Vous pouvez essayer: https://git.duniter.org/pokapow/py-g1-migration/-/raw/master/gtest.json
Je rappel que:
- Toutes les certifications sont présentes, même les périmés, dû à l’indexation incrémental de DataJune
- Il y a 31 comptes en moins car trop récents, dû à DataJune pas à jours
- Les compteurs de dates de certifications sont tous à 0
- Il n’y a que les membres actuels (moins 31…), pas les simples portefeuilles
- Les nom d’identité révoqués ne sont pas pris en comptes, donc vous pourrez recréer une identité précédemment révoqué.
Pour le moment je ne vois pas d’autres points.
Pour la suite, comme le dis @elois maintenant il faudrait sortir les données complètes de Dex directement, avec les dates de certifications, dans un json simple que je peux reparser derrière pour formater le final.
1 Like
Ce n’est pas un bug, c’est un comportement que j’ai codé volontairement, et qui ne s’applique que pour une blockchain locale, donc une blockchain qui ne doit jamais être exposée publiquement sur internet.
Ce comportement n’existe pas pour le lancement d’un live network, en contre-partie les sessions keys doivent être renseignées à la main dans la genesis conf.
Ce qu’on appelle un live network (c’est du vocabulaire substrate), c’est un réseau qui peut être exposé publiquement, entre autres, car il utilise des vraies clés privées générées par celui qui bootstrap le réseau au lieu des clés de comptes de tests, mais il y a également d’autres différences.
Tu peut les rajouter en ajoutant le champ “wallets” au 1er niveau de profondeur, selon ce format:
{
..
"wallets": {
"5C4puptPcKQKxJjzwjxGo2kZoUvPGEivShnbAYBr7mbnNGcR": 31987,
"5C5ANywaswtfr4bQvoMTbLjmQBLpBZAqUeD4eN2Ag46URgkc": 45300
}
}}
Les montants sont exprimés en centimes de Ğ1.
Mais surtout pour lancer une ĞTestv2 il faudrait finir le développement du runtime gtest, qui est une copie du runtime gdev mais avec des constantes pour les paramètres (qui ne sont donc pas déclarés dans le genesis) pour des raisons d’optimisation.
Cette copie duplique une partie du code, ce qui permettra à l’avenir de n’activer certaines fonctionnalités d’abord que coté gdev, puis plus tard coté gtest.
1 Like
Oui j’avais compris, mais je trouve ça drôle quand même ^^
ok je me rends pas compte de ce qu’il reste à faire à ce niveau, si tu pouvais faire un point avec hugo ou tuxmain à l’occasion ce serait sympa, qu’on puisse booter une ĞTest live dans les mois qui viennent.
Le plus pratique serait peut-être de créer une identité !god (qui est alphabétiquement avant toutes les identités Duniter v1) avec la clé //alice.
Non vue que c’est que pour les tests locaux c’est bon, on a 1000i100 !
Voilà je viens de stabiliser le repo et ajouter le README: pokapow / py-g1-migration · GitLab
Tout y est détaillé pour extraire et exporter les données en moins de 5 minutes.
Si vous voulez utiliser le genesis final directement, c’est ici: https://git.duniter.org/pokapow/py-g1-migration/-/raw/master/output/gtest.json
Toutes les identités (membres et non membres) sont présentes, toutes leurs certifications avec numéro de bloc d’expiration, ainsi que tous les wallets, avec les soldes correctes. Tout provient de Dex.
Le binaire dex est directement dans le repo, il est utilisé par le premier script d’export des données primaires.
J’ai configuré les paramètres de la wot selon ce qui me semble refléter au mieux les paramètres Ğ1 actuels, tous est paramétrable dans currency_parameters.py
La valeur du premier DU est récupéré depuis Dex directement (dernière valeur de DU en date).
Selon moi, il ne manque que la liste des identités révoqués, mais cela nécessite un apport côté parsing genesis v2s.
Dites moi si vous voyez d’autres manques ou de mauvaises données.
Maintenant il va falloir analyser en détails l’état du storage v2s, voir si les données sont cohérentes.
Je vois par exemple que des identités n’ayant qu’une certification sont membres dans le storage, ce qui n’est pas normal.
Probablement un bug a régler côté Duniter, ou bien la déclaration des identités genesis non membres n’est pas encore pris en charge côté v2s.
Est-ce qu’un admin du gitlab pourrait déplacer ce dépôt au bon endroit svp ? (je ne sais pas où…)
enjoy
4 Likes
Les certifications renouvelées apparaissent 2 fois, est-ce normal ?
Et je ne vois pas les wallets avec leurs soldes.