Dans le cadre de “ Industrialiser le démarrage d'une nouvelle Ğx ”, j’ai dû faire le point sur les différentes chaînes à notre disposition dans le CLI Duniter V2S. Je vous propose un état des lieux (AVANT) puis ce que j’imagine comme fonctionnement (APRES). Dans la partie APRES, j’introduis une sépa…

[image] cgeek: je pensais qu’on les fournissais à l’exécution On peut les fournir à l’exécution, avec l’option --raw-spec, cf notre discussion Quel genesis une nouvelle version du client doit-il incorporer? . Ça permet de remplacer les raw specs incorporées par une version externe sans changer…

[image] HugoTrentesaux: Ce n’est pas immédiat d’établir si une version du client est compatible avec un runtime différent. Ce n’est pas ça que je voulais dire, je reprends un de mes exemples : [image] cgeek: duniter-gdev-601, basé sur le Genesis GDev-600 et supportant le Runtime ĞDev 601…

Ok, ce que je n’avais pas compris, c’est la différence entre l’exécution native et wasm du runtime. Je n’ai pas exploré la différence entre les deux, est-ce qu’il y a une histoire de performances par exemple ? Dans ma tête on embarquait toujours le runtime du genesis par simplicité d’utilisation, ma…

Oui c’est juste une histoire de performances. Et dans tous les cas on est obligés d’avoir un Genesis pour démarrer sur une blockchain Substrate et il y a forcément le Runtime initial dedans (c’est imposé par SystemConfig) pour interpréter le bloc#0 et les suivants jusqu’à un éventuel Runtime Upgrad…

[image] cgeek: ce n’est pas évident non plus ce block#0, apparemment celui-ci n’est pas importé mais – je pense – est déduit du Genesis. C’est bien ça. D’ailleurs les logs au démarrage du client le disent : 🔨 Initializing Genesis block/state (state: 0x0a78…3600, header-hash: 0xc155…d186) ..…

@HugoTrentesaux : dans les devs V2S que tu as réalisés pour lancer la ĞTest, tu fais des appels à la crate log, par exemple log::warn!. Je n’arrive pas à faire fonctionner ces instructions sans moi-même ajouter une crate comme env_logger et rajouter une instruction de branchement du logger : env_l…

Voici une ligne de commande que je lançais avec un vieux binaire sur ma machine : # vieux genesis que je gardais sur ma machine DUNITER_GTEST_GENESIS=/home/hugo/duniter/specs/gtest_genesis.json \ DUNITER_GTEST_CLIENT_SPEC=/home/hugo/duniter/specs/gtest_client-specs.json \ # vieux binaire que je gar…

[image] HugoTrentesaux: Donc il doit y avoir un problème de configuration de logs. Oui : c’est parce que toi tu lances une chaîne alors que de mon côté je teste la commande build-spec. Si tu l’essaies, à mon avis tu n’auras qu’une seule ligne de logs : target/debug/duniter build-spec --chai…

Attention, mon code ne s’exécute que sur le runtime gtest : ./target/debug/duniter build-spec --chain gtest_live > tmp 2023-10-02 20:03:38 Building chain spec 2023-10-02 20:03:38 prepared genesis with: - 31561 accounts (13050 identities, 18511 simple wallets) - 13050 total ident…

Je vois pourquoi : c’est parce que ces lignes de log sont produites dans build_genesis() qui elle-même est appelée au sein d’une closure de ChainSpec::from_genesis(). La closure est appelée une fois le logger initialisé, ce qui n’est pas vrai sur ma branche. Il faut que je déplace mon appel à la g…

Duniter Forum

État des lieux des différentes chaînes

Nodes Duniter-v2s

gtest, g1, gdev, runtime

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled