Gdev runtime 600

cgeek · 15 August 2023 17:29

Pourtant je le vois bien : https://g1-migrator.axiom-team.fr/inputs/blocs.json

Peut-être qu’il a disparu le temps de sa génération, et qu’il faut réessayer de temps en temps.

Pini · 15 August 2023 20:02

Ce n’est pas un oubli. C’était juste mipossible.

tuxmain · 15 August 2023 21:04

Il est vide et a été modifié en juillet alors que les autres datent d’aujourd’hui…

tuxmain · 16 August 2023 12:44

J’essaie de faire tourner py-g1-migrator chez moi mais il y a bien une erreur pour blocs.json :

dex find main_blocks -p medianTime -o json -f blocs.json

Error: DeserError: missing field `wrong` at line 1 column 130741: '{"version":10,"number":0,"currency":"g1", [...]'

(nœud synchro depuis des chunks téléchargés, bloqué et arrêté à 85%)

vit · 16 August 2023 16:22

Dex semble aussi être bugué sur l’export des identités. Pour avancer, soit un dev Rust se penche sur le code de dex, soit un dev Python implémente l’import direct des index leveldb dans le code Python de py-g1-migrator.

Mon script d’intégrité peut servir et je peux aider si besoin :

tuxmain · 17 August 2023 08:33

C’est bon, il suffisait d’ajouter une valeur par défaut au champ wrong du bloc, pour qu’il tolère son absence dans la bdd. Files · tuxmain/default-wrong · Pascal Engélibert / duniter-core · GitLab

Par contre rien ne dit que ça marchera encore dans un an. Dex casse facilement à la moindre erreur, il ne compile qu’avec une version de duniter-core datant de 2021, le script python est de bric et de broc… Il serait plus prudent de préparer un truc robuste et conçu pour être tolérant aux erreurs, qui lise directement dans la bdd pour minimiser les dépendances.

tuxmain · 17 August 2023 09:02

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.

Le gdev.json auquel il manque le runtime : https://txmn.tk/g1/gdev/gdev.json

cgeek · 17 August 2023 17:12

Je peux (essayer de) m’en occuper, par contre avant j’aimerais merger MR!180 à propos de Blake2_128Concat.

edit : pour info, je m’y mets seulement maintenant. Je vais prendre mon temps.

cgeek · 30 August 2023 19:24

Le runtime-600 est disponible dans les releases. (merci à @Pini pour le déblocage de la CI)

Ne reste plus qu’à générer la spec, mais j’ai quelques soucis sur :

D’abord j’ai renommé le préfixe “smiths” en “smith”, car il y avait une erreur, mais ensuite il y a plus gênant :

docker run -v $HOME/duniter-v2s/resources:/var/lib/duniter/resources -e DUNITER_GENESIS_CONFIG=/var/lib/duniter/resources/gdev.json --rm duniter/duniter-v2s:runtime-600 -- build-spec -lerror --chain=gdev_live --raw > name-raw.json
Error: Input("Identity 'Nounoursgt8946' not exist")

Un soucis avec py-g1-migrator ?

tuxmain · 30 August 2023 19:37

J’avais fait quelques changements ad hoc dans py-g1-migrator, je viens de pusher dans tuxmain/gdev.

cgeek · 31 August 2023 20:28

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 )

HugoTrentesaux · 1 September 2023 07:47

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.

cgeek · 1 September 2023 20:02

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.

tuxmain · 2 September 2023 08:19

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.

cgeek · 2 September 2023 08:36

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 :

let count_uds = T::MomentIntoBalance::convert(
    T::UdReevalPeriod::get() / T::UdCreationPeriod::get(),
);
if_std! {
    println!("ud_reeval_period = {:?}", T::UdReevalPeriod::get());
    println!("ud_creation_period = {:?}", T::UdCreationPeriod::get());
    println!("count_uds = {:?}", count_uds.clone());
}

ud_reeval_period = 15778800
ud_creation_period = 86400000
count_uds = 0

Normal

edit 3 : mais ce n’est pas cohérent avec ma genesis config :

  "parameters": {
   ...
    "ud_creation_period": 14400,
    "ud_reeval_period": 100800,

edit 4 : bon c’est ça, mon gdev.json n’est pas bon.

edit 5 : ça avance !

ud_reeval_period = 100800
ud_creation_period = 14400
count_uds = 7
2023-09-02 11:42:48 🙌 Starting consensus session on top of parent 0x65524bd06366df57cb701b2915f0f2493e0e451e4688cb366701924bcb3e1726    
2023-09-02 11:42:48 🎁 Prepared block for proposing at 1 (3 ms) [hash: 0x8d0aa44b92cc2d9759cccb5631599c21c152690f0f9b3cb01a5f33ee8fcfbf4a; parent_hash: 0x6552…1726; extrinsics (1): [0x3683…6a3b]]    
2023-09-02 11:42:48 🔖 Pre-sealed block for proposal at 1. Hash now 0x51a03e27cb7833ca1319697e9ec0a26b9f61c5dc82074f63edac997a76450b1e, previously 0x8d0aa44b92cc2d9759cccb5631599c21c152690f0f9b3cb01a5f33ee8fcfbf4a.    
2023-09-02 11:42:48 👶 New epoch 0 launching at block 0x51a0…0b1e (block slot 282274628 >= start slot 282274628).    
2023-09-02 11:42:48 👶 Next epoch starts at slot 282275228    
2023-09-02 11:42:48 ✨ Imported #1 (0x51a0…0b1e)

cgeek · 2 September 2023 17:27

A post was split to a new topic: Industrialiser le démarrage d’une nouvelle Ğx

cgeek · 19 September 2023 10:57

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.

tuxmain · 19 September 2023 11:23

oui
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 ~~bordel~~ edge 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.

cgeek · 19 September 2023 11:37

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.

tuxmain · 19 September 2023 11:46

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).