Comme il faut utiliser docker pour compiler le runtime je veux bien que quelqu’un termine la release. J’ai créé la branche release/runtime-600. Les instructions sont dans docs/dev/launch-a-live-network.md.
Je pense avoir réussi à générer les raw-spec, voici deux fichiers :
le genesis configuration file : gdev.json.zip (2,1 Mo)
les raw-spec dérivées du fichier précédent et qui intègrent le runtime-600 : gdev-raw.json
Si j’en crois la documentation, je devais vous partager ce gdev-raw.json, je n’ai pas encore bien compris pourquoi, je verrai ça demain (à vous lire, ou à continuer de lire la doc )
Je sors d’une pause complète sur Duniter et je me relance à plein temps. J’ai quelques trucs à faire avant de travailler avec vous sur une nouvelle ĞDev (ou ĞTest, à définir).
Je note ce point pour la prochaine visio, je pense que ce serait bien d’en parler ensemble.
Je pense avoir déroulé correctement le tuto, j’ai une GDev en local basée sur le gdev-raw.json joint ci-avant mais qui plante sur la génération du block#0. C’est peut-être mon environnement qui n’est pas correct, mais bon, à toutes fins utiles je vous poste les logs ici :
Résumé
2023-09-01 21:46:18 Generating node key file '/var/lib/duniter/node.key'...
2023-09-01 21:46:18 Node peer ID is '12D3KooWSGzoaTu3WubUaU3syGTG5xMbX3ZAZwFVxNsXZZawoPoW'.
2023-09-01 21:46:18 Starting duniter with parameters: --bootnodes /dns/duniter-rpc/tcp/30333/p2p/12D3KooWKiyqmbKVJMsgDWiq4ni56czNQEkPY9LxyGrc74TJURwu --node-key-file /var/lib/duniter/node.key --rpc-cors all --rpc-methods Unsafe --validator --chain /var/lib/duniter/gdev-raw.json -d /var/lib/duniter --unsafe-rpc-external --unsafe-ws-external
2023-09-01 21:46:18 12D3KooWSGzoaTu3WubUaU3syGTG5xMbX3ZAZwFVxNsXZZawoPoW
2023-09-01 21:46:19 2023-09-01 19:46:19 Duniter
2023-09-01 21:46:19 2023-09-01 19:46:19 ✌️ version 0.3.0-unknown
2023-09-01 21:46:19 2023-09-01 19:46:19 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023
2023-09-01 21:46:19 2023-09-01 19:46:19 📋 Chain specification: Ğdev
2023-09-01 21:46:19 2023-09-01 19:46:19 🏷 Node name: elderly-tree-8901
2023-09-01 21:46:19 2023-09-01 19:46:19 👤 Role: AUTHORITY
2023-09-01 21:46:19 2023-09-01 19:46:19 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full
2023-09-01 21:46:19 2023-09-01 19:46:19 ⛓ Native runtime: gdev-600 (duniter-gdev-1.tx1.au1)
2023-09-01 21:46:21 2023-09-01 19:46:21 🔨 Initializing Genesis block/state (state: 0x2b3a…9feb, header-hash: 0xe22f…5586)
2023-09-01 21:46:21 2023-09-01 19:46:21 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2023-09-01 21:46:22 2023-09-01 19:46:22 👶 Creating empty BABE epoch changes on what appears to be first startup.
2023-09-01 21:46:22 2023-09-01 19:46:22 🏷 Local node identity is: 12D3KooWSGzoaTu3WubUaU3syGTG5xMbX3ZAZwFVxNsXZZawoPoW
2023-09-01 21:46:22 2023-09-01 19:46:22 👶 Starting BABE Authorship worker
2023-09-01 21:46:22 2023-09-01 19:46:22 💻 Operating system: linux
2023-09-01 21:46:22 2023-09-01 19:46:22 💻 CPU architecture: aarch64
2023-09-01 21:46:22 2023-09-01 19:46:22 💻 Target environment: gnu
2023-09-01 21:46:22 2023-09-01 19:46:22 💻 Memory: 15987MB
2023-09-01 21:46:22 2023-09-01 19:46:22 💻 Kernel: 5.15.49-linuxkit
2023-09-01 21:46:22 2023-09-01 19:46:22 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)
2023-09-01 21:46:22 2023-09-01 19:46:22 💻 Virtual machine: no
2023-09-01 21:46:22 2023-09-01 19:46:22 📦 Highest known block at #0
2023-09-01 21:46:22 2023-09-01 19:46:22 Running JSON-RPC HTTP server: addr=0.0.0.0:9933, allowed origins=None
2023-09-01 21:46:22 2023-09-01 19:46:22 Running JSON-RPC WS server: addr=0.0.0.0:9944, allowed origins=None
2023-09-01 21:46:22 2023-09-01 19:46:22 〽️ Prometheus exporter started at 127.0.0.1:9615
2023-09-01 21:46:22 2023-09-01 19:46:22 ***** Duniter has fully started *****
2023-09-01 21:46:22 2023-09-01 19:46:22 💔 The bootnode you want to connect to at `/ip4/127.0.0.1/tcp/30333/p2p/12D3KooWG9QffS4Atii6zD1AwRcs1MurFa2CfacJJmvmuT6scxKN` provided a different peer ID `12D3KooWSGzoaTu3WubUaU3syGTG5xMbX3ZAZwFVxNsXZZawoPoW` than the one you expect `12D3KooWG9QffS4Atii6zD1AwRcs1MurFa2CfacJJmvmuT6scxKN`.
2023-09-01 21:46:22 2023-09-01 19:46:22 💔 The bootnode you want to connect to at `/ip4/127.0.0.1/tcp/30333/p2p/12D3KooWG9QffS4Atii6zD1AwRcs1MurFa2CfacJJmvmuT6scxKN` provided a different peer ID `12D3KooWSGzoaTu3WubUaU3syGTG5xMbX3ZAZwFVxNsXZZawoPoW` than the one you expect `12D3KooWG9QffS4Atii6zD1AwRcs1MurFa2CfacJJmvmuT6scxKN`.
2023-09-01 21:46:22 2023-09-01 19:46:22 discovered: 12D3KooWHn9jUkD8w1v8QQHWrFkNcURCWznaE4cawqvGkzp8o1Rj /ip4/172.31.0.3/tcp/30333/ws
2023-09-01 21:46:24 2023-09-01 19:46:24 🙌 Starting consensus session on top of parent 0xe22ff1acaee778d304f6c40a103c34e1035d7b0a4a9bbd82f2d8a45adaa25586
2023-09-01 21:46:24 2023-09-01 19:46:24 panicked at 'attempt to divide by zero', /rustc/8796e7a9cfd4c5c4f1de15ec1c53994ddf288665/library/core/src/ops/arith.rs:488:1
2023-09-01 21:46:24 2023-09-01 19:46:24 1 storage transactions are left open by the runtime. Those will be rolled back.
2023-09-01 21:46:24 2023-09-01 19:46:24 1 storage transactions are left open by the runtime. Those will be rolled back.
2023-09-01 21:46:24 2023-09-01 19:46:24 ❗️ Inherent extrinsic returned unexpected error: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
2023-09-01 21:46:24 WASM backtrace:
2023-09-01 21:46:24
2023-09-01 21:46:24 0: 0x183875 - <unknown>!rust_begin_unwind
2023-09-01 21:46:24 1: 0x3ec0 - <unknown>!core::panicking::panic_fmt::h57b56b1dc717ba48
2023-09-01 21:46:24 2: 0x3e81 - <unknown>!core::panicking::panic::h152edf3fad35a2e6
2023-09-01 21:46:24 3: 0x4d389 - <unknown>!pallet_universal_dividend::<impl frame_support::traits::hooks::OnTimestampSet<<T as pallet_timestamp::pallet::Config>::Moment> for pallet_universal_dividend::pallet::Pallet<T>>::on_timestamp_set::h2e09a490fdd6972a
2023-09-01 21:46:24 4: 0x90d0f - <unknown>!frame_support::storage::transactional::with_storage_layer::h4adf8ad53c5109ae
2023-09-01 21:46:24 5: 0x170b0 - <unknown>!<gdev_runtime::RuntimeCall as frame_support::traits::dispatch::UnfilteredDispatchable>::dispatch_bypass_filter::hb9eaa75132fb4db0
2023-09-01 21:46:24 6: 0x16d34 - <unknown>!<gdev_runtime::RuntimeCall as sp_runtime::traits::Dispatchable>::dispatch::hf53c3c69d77eb11d
2023-09-01 21:46:24 7: 0x10be9d - <unknown>!<sp_runtime::generic::checked_extrinsic::CheckedExtrinsic<AccountId,Call,Extra> as sp_runtime::traits::Applyable>::apply::hbb50cd1564d3614b
2023-09-01 21:46:24 8: 0xc3833 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::apply_extrinsic::h218aa786580ca1c3
2023-09-01 21:46:24 9: 0xd49b1 - <unknown>!BlockBuilder_apply_extrinsic
2023-09-01 21:46:24 . Dropping.
2023-09-01 21:46:24 2023-09-01 19:46:24 panicked at 'Timestamp must be updated once in the block', /usr/local/cargo/git/checkouts/substrate-7b26ec960e31aff5/7f8b8db/frame/timestamp/src/lib.rs:179:13
2023-09-01 21:46:24 2023-09-01 19:46:24 Proposing failed: Import failed: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
2023-09-01 21:46:24 WASM backtrace:
2023-09-01 21:46:24
2023-09-01 21:46:24 0: 0x183875 - <unknown>!rust_begin_unwind
2023-09-01 21:46:24 1: 0x3ec0 - <unknown>!core::panicking::panic_fmt::h57b56b1dc717ba48
2023-09-01 21:46:24 2: 0x5bc67 - <unknown>!<pallet_timestamp::pallet::Pallet<T> as frame_support::traits::hooks::OnFinalize<<T as frame_system::pallet::Config>::BlockNumber>>::on_finalize::hb1347f4ecbebc228
2023-09-01 21:46:24 3: 0xc4bc5 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::idle_and_finalize_hook::h467a73fab6393a5b
2023-09-01 21:46:24 4: 0xc4cb4 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::finalize_block::ha93eb503968fad45
2023-09-01 21:46:24 5: 0xd4a63 - <unknown>!BlockBuilder_finalize_block
2023-09-01 21:46:24
edit : je ne comprends pas encore très bien, mais j’arrive à lancer en mode debug donc je devrais finir par trouver.
edit 2 : je fais une pause, je pense que c’est dans service.rs où il manque la création de l’inherent.
Quelle commande as-tu utilisé pour le lancer ? En fonction du sealing qu’on choisit il branche différemment dans service.rs et peut ne pas créer les inhérents. Je ne pense pas que service.rs soit le problème.
Sans préciser le sealing, donc je suis en mode “automatique”. Mais effectivement je passe bien dans la création de l’inherent, le problème est ailleurs.
edit : l’erreur “Timestamp must be updated once in the block” n’est qu’un symptôme, l’erreur se produit en fait dans reeval_ud parce que count_uds_beetween_two_reevals vaut zéro.
edit 2 : si je trace les valeurs dans la pallet UD :
Dans le refactoring que j’effectue pour Industrialiser le démarrage d’une nouvelle Ğx, se pose la question de ce que l’on souhaite comme données pour la ĞDev, ĞTest et Ğ1. J’ai deux questions :
A priori, pour ĞTest et Ğ1 nous serions dans une configuration très proche avec reprise des données de la Ğ1 mais avec des paramètres de délais plus courts pour la ĞTest (production du DU, délais de renouvellement, etc.) et un DU élevé (pour éviter que la monnaie ne prenne en valeur). Est-ton bien d’accord là-dessus ?
Pour la ĞDev, jusqu’à maintenant nous faisions un peu comme la ĞTest : donnée de la Ğ1 + paramètres plus fréquents. Continue-t-on sur la même voie ? Nous pourrions avoir une WoT restreinte aux contributeurs techniques par exemple. Ou bien continuer à utiliser la WoT Ğ1 tant que la ĞTest n’est pas lancée.
La GT peut servir à tester à la fois Duniter et l’écosystème avec des données ressemblant à la G1, donc on pourrait la lancer avec un instantané de la G1 et laisser les gens volontairement la tester. Je ne vois pas l’intérêt de restreindre, au contraire elle devrait pouvoir accueillir autant de bordeledge cases que possible. Quitte à utiliser des bots pour entretenir sa TdC et qu’elle reste au moins au niveau de la G1 en terme de bande passante, occupation des blocs, nombre de membres et de certifs.
J’en profite avec une troisième question : dans le Genesis, selon moi, tous les Smiths devraient être automatiquement co-certifiés, possiblement au hasard, à hauteur de [SmithWotMinCertForMembership ; SmithMaxByIssuer] certifications. Je ne vois pas l’intérêt qu’il en soit autrement. Êtes-vous d’accord avec ça ?
Si oui, je modifierai la structure du fichier de genesis config pour que l’on n’ai plus besoin de préciser les certifications statiquement, mais juste le pseudo des smiths + leur session_keys.
Je suis d’accord pour que les forgerons soient une clique en gdev et gtest pour des raisons pratiques (besoin de recueillir les listes de certifs et de mettre à jour le json), mais pas pour la G1.
Ces certifications ont quand même un sens et des implications sur la sécurité de la chaîne. Un forgeron avec le minimum de certifications forgeron est probablement moins reconnu comme fiable qu’un forgeron en ayant 15, donc on n’a pas intérêt à effacer cette information en leur donnant le même nombre de certifs (et donc en pérennisant davantage la position du premier, qui était peut-être un attaquant ou qui gérait mal son serveur).
Effectivement pour gdev et gtest on peut partir sur une clique. Et pas forcément besoin de mettre les session keys d’autres personnes que celle qui démarre le réseau. D’ailleurs, je me sers justement de la présence de session keys pour savoir quelle autorité sera online au début.
// Initial authorities and session keys
let session_keys_bytes = if let Some(declared_session_keys) = &smith_data.session_keys {
counter_online_authorities += 1;
// insert authority as online
initial_authorities.insert(identity.index, (identity.owner_key.clone(), true));
// decode session keys or force to given value
match maybe_force_authority {
Some(ref bytes) => bytes.clone(),
None => hex::decode(&declared_session_keys[2..])
.map_err(|_| format!("invalid session keys for idty {}", &name))?,
}
} else {
// still authority but offline
initial_authorities.insert(identity.index, (identity.owner_key.clone(), false));
// fake session keys
let mut fake_bytes = Vec::with_capacity(128);
for _ in 0..4 {
fake_bytes.extend_from_slice(identity.owner_key.as_ref())
}
fake_bytes
};
Je ne sais pas si vous avez vu mais il y a un bouton “Bulk Edit” dans la page listant les issues d’une milestone sur GitLab.
Je dis ça parce qu’en voyant mes notifications mail j’ai l’impression que certaines éditions automatisables (migration des issues d’une milestone vers une autre) sont faites à la main.