🚨 Runtime Upgrade Proposal: gtest v1110

[poka]

Objectif: Fix bug de réévaluation quotidienne du DU

@technical-committee

Problème actuel:

• Le DU est réévalué TOUS LES JOURS au lieu de tous les 6 mois
• Cause: first_ud_reeval en secondes (1766232000) au lieu de millisecondes

Solution:

• Migration automatique (idempotente): NextReeval passera de 1766232000 à 1766232000000 ms
• Date correcte: 20 décembre 2025 à 13:00:00 UTC

MR:

• Network GTest runtime 1110 (!349) · Merge requests · nodes / rust / Duniter v2S · GitLab

Proposition:

• Release: runtime-1110 · nodes / rust / Duniter v2S · GitLab
• Branch: network/gtest-1110
• Blake2_256: 0x514cf1f1bcb6f498436b1e441b8155401367518d080e57c0498e3e3d91dc7b1a

Vote: https://duniter-portal.axiom-team.fr/?rpc=wss%3A%2F%2Fgt.p2p.legal%2Fws#/techcomm/proposals

Votez pour la proposition 1, la proposition 0 étant obsolète. Vous pouvez voter “Non” à la proposition 0 pour l’annuler avant sont expriration.

Seuil: 6
Fin du vote: Jeudi 30 Octobre à 16h30

Merci de vérifier le hash en compilant localement avec:

cargo xtask release runtime build gtest
cat release/srtool_output_gtest.json | grep blake2_256 | jq -r '.runtimes.compressed.blake2_256'

Voir ce tuto: Technical committee: Check runtime upgrade hash compliance

Vous pouvez également lire et vérifier que les tests de la migration passent bien:

% cargo test -p gtest-runtime --lib migrations::tests -- --nocapture

running 4 tests
Initial NextReeval (future value): 1782010800000 (June 20, 2026)
Initial NextReeval: 1766232000
Migration weight: Weight { ref_time: 16770000, proof_size: 0 }
Updated NextReeval: 1782010800000
test migrations::tests::test_migration_v1110_with_already_correct_value ... ok
Migration weight: Weight { ref_time: 22976000, proof_size: 0 }
Updated NextReeval: 1766232000000
test migrations::tests::test_migration_v1110_preserves_future_value ... ok
test migrations::tests::test_migration_v1110_is_idempotent ... ok
test migrations::tests::test_migration_v1110_fixes_incorrect_next_reeval ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 5 filtered out; finished in 0.00s```

[poka]

Je viens de réaliser que ma condition d’execution de la migration n’est pas bonne. Il se base sur la valeur de nextReeval alors qu’il faudrait plutôt se baser sur le numéro du runtime. Je dois refaire une proposition.

---

Et en fait je me rend compte qu’ici il y a beaucoup plus simple, pas besoin de runtime upgrade, juste un setStorage directement, proposition 5.

Comment j’ai déterminé les bonnes valeurs ?

et

python3 -c "import struct; print('0x' + struct.pack('<Q', 1766232000000).hex())"

[poka]

La proposition 6 remet la bonne valeur du DU.

duniter-v2s % python3 -c "import struct; print('0x' + struct.pack('<Q', 1148).hex())"

---

Pour vous y retrouver dans les différentes propositions ouvertes, vous pouvez vous référer à celle auquels j’ai vôté oui.
Actuellement les 3 dernières.

---

Si ça vous convient je peux supprimer la MR runtime 1110 ainsi que la release 1110.
Soyez indulgent je m’entraine, le réseau gtest est fait pour ça, on se fait la main

[cgeek]

Juste pour clarifier : quand tu dis proposition “5” c’est en référence aux propositions visibles dans l’onglet “Comité tech > Proposals” de Duniter Portal, donc index 5.

Proposition d’index 5

• fonctionnellement : universalDividend.nextReeval = 1766232000000
• hash de la clé du storage : 0x235cdca73b1fc4b26dd60639fe5bf213510012cc03aa2d41b711cd71b8a63e85
• hash de la valeur : 0x0086a13b9b010000

J’ai testé le call en local sur un nœud de dev pour bien tout vérifier par moi-même, le storage est correctement mis à jour.

J’ai donc voté la proposition.

Procédure de vérification détaillée

Obtention de la clé

On veut connaître la clé du storage associée à universalDividend.nextReeval :

Copier la valeur 0x235cdca73b1fc4b26dd60639fe5bf213510012cc03aa2d41b711cd71b8a63e85.

Obtention de la valeur

Comme Substrate attend une valeur hexadécimale, il faut convertir 1766232000000 en hexadécimal.

En python, Poka propose :

python3 -c "import struct; print('0x' + struct.pack('<Q', 1766232000000).hex())"                                                                                                    

En JS :

const num = 1766232000000;

// Créer un buffer de 8 octets
const buffer = new ArrayBuffer(8);
const view = new DataView(buffer);

// Écrire en little-endian (true = little-endian)
view.setBigUint64(0, BigInt(num), true);

// Convertir en hex
const hex = '0x' + Array.from(new Uint8Array(buffer))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');

console.log(hex);

Dans les 2 cas, on obtient 0x0086a13b9b010000.

Proposition finale

On vérifie dans la proposition que les 2 valeurs calculées correspondent bien.

• clé 0x235cdca73b1fc4b26dd60639fe5bf213510012cc03aa2d41b711cd71b8a63e85
• valeur 0x0086a13b9b010000

C’est OK.

Proposition d’index 6

• fonctionnellement : universalDividend.currentUd = 1148 au lieu de 1505 actuellement, mais il vaudrait mieux que la proposition 5 passe avant sinon il va falloir recommencer la proposition 6 plus tard.
• hash de la clé du storage : 0x235cdca73b1fc4b26dd60639fe5bf213e693e94477a5a91aed0757f3de0b8168
• hash de la valeur : 0x7c04000000000000

Mêmes vérifications que pour la proposition précédente.

C’est OK.

J’ai n’ai PAS voté la proposition pour la bloquer temporairement tant que la proposition 5 n’est pas passée.

[poka]

Oui je parle en index, proposition 5, la 6ème .

[vit]

J’ai voté oui, non, oui, non, puis finalement oui avec Tikka. Pour la proposition du set storage.

C’est pas que j’hésitais, c’est que je testais mon code de Tikka…
Les propositions y sont affichées par ordre d’index croissant.

[poka]

@technical-committee pour rappel il reste 4 jours pour voter les propositions, à commencer par l’index 4 et 5. Il manque 2 votes pour la 5ème.

[1000i100]

De ce que je comprends, la date de prochaine réévaluation du DU serait au 20 décembre avec la proposition d’index 5.

Quitte à ce que ce soit pas à l’équinox, pourquoi ne pas la mettre plus tôt pour se rendre compte plus rapidement si le problème est réglé et que la réévaluation ce fait correctement ?

En ce sens, j’ai tenté de faire un proposal aussi, mais je n’arrive pas à le passer (wrong length me dit-il) qu’est-ce qui cloche ?

Avec la valeur que j’indique, si j’ai bien compris ça donnerais le 1er novembre 2025 à 13h c’est bien ça ?

PS : si on change quand a lieu la prochaine rééval et le montant, ça ne change pas la fréquence, il y a donc une chose de plus à changer non ?

Enfin, j’ai essayer de recompiler duniter-v2s à plusieurs reprise, y compris en créant le dossier qu’il réclame avec un chmod o+w mais pas moyen de finir la compile avez vous eu ce problème et comment l’avez vous résolu :

$ cargo xtask release runtime build gtest
Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.29s
Running `target/debug/xtask release runtime build gtest`
rustc 1.91.0-nightly (7d82b83ed 2025-08-06)
cargo 1.91.0-nightly (840b83a10 2025-07-30)
🚀 Construction du runtime avec srtool: gtest
Docker version 28.5.1, build e180ab8
📄 SRTOOL_OUTPUT = release/srtool_output_gtest.json
🐳 Lancement du conteneur srtool...
🚀 Démarrage de srtool...
📁 Répertoire de travail: /build
🔧 Runtime: gtest
📄 Sortie: release/srtool_output_gtest.json
🔨 Construction du runtime avec srtool...
tee: release/srtool_output_gtest.json: Permission denied
🧰 Substrate Runtime Toolbox - srtool v0.18.3 🧰
              - by Chevdor -
info: override toolchain for '/build' set to '1.88.0-x86_64-unknown-linux-gnu'
info: component 'rust-std' for target 'wasm32-unknown-unknown' is up to date
info: component 'rust-src' is up to date
🏗  Building gtest-runtime as release using rustc 1.88.0 (6b00bc388 2025-06-23)
⏳ That can take a little while, be patient... subsequent builds may be faster.
   Since you have to wait a little, you may want to learn more about Substrate runtimes:
   https://docs.substrate.io/learn/architecture/
    Updating git repository `https://github.com/duniter/duniter-polkadot-sdk`
    Updating crates.io index
    Updating git repository `https://github.com/paritytech/subxt`
 Downloading crates ...
[...]
error: failed to create directory `/build/runtime/gtest/target`

Caused by:
  Permission denied (os error 13)
Error: Échec de la construction du runtime avec srtool

[poka]

@1000i100

PS : si on change quand a lieu la prochaine rééval et le montant, ça ne change pas la fréquence, il y a donc une chose de plus à changer non ?

Non, voir: Duniter v2s et l’indexeur ne démarrent pas avec la valeur du DU de la Ğ1 - #16 by poka

@1000i100

En ce sens, j’ai tenté de faire un proposal aussi, mais je n’arrive pas à le passer (wrong length me dit-il) qu’est-ce qui cloche ?

Je crois qu’il y a peut être un bug de l’interface polkadotjs car parfois j’ai l’impression que lengthBound est prérempli. Mais parfois j’ai dû la calculer à la main.
Pour se faire il suffit de prendre le encoded call data, retirer le 0x au début, compter son nombre de caractère et le diviser par 2 (nombre de bytes). Par exemple:

echo 1702101500000a2acefe9868b7798a1f61489a1a0d45b330accf87e1e88326ee97430ecbd4815700 | wc -c → 81
Ca fait 40.5, on peut mettre 50 pour avoir de la marge.

---

@1000i100

un chmod o+w

Regarde surtout le owner du dossier en question et dossier parent. Dans le doute pour tester fait un petit chmod 777 -R du dossier parent, pour voir si c’est vraiment un pbm de droits.

[Moul]

J’ai approuvé les propositions aux index 4, 5 et 6. La 5 est à valider.
Curieux cette nouvelle manière de vérifier uniquement le changement d’une valeur.
Je cherchais ou se trouve le code (la branche) de la proposition 6.
Pour la proposition 5, j’ai construit le runtime et ait obtenu le même hash blake256.

[poka]

@Moul

Pour la proposition 5, j’ai construit le runtime et ait obtenu le même hash blake256.

Aucune de ces 3 propositions n’est un runtime upgrade, juste un setStorage. Donc il n’y a pas de code associé (pas de preimage).

Du coup je ne sais pas quel runtime tu as compilé et quel hash tu as vérifié ?
Pour ces propositions le contenu des changements est directement présenté dans la proposual, il suffit donc de vérifier que le contenu est celui attendu (@cgeek a expliqué la procédure un peu mieux que moi juste au dessus).

[Moul]

Ah ok. J’avais vérifié la proposition 5 en vérifiant cette branche et en obtenant ce hash, mais ça correspond aux premières propositions.

@poka

• Branch: network/gtest-1110
• Blake2_256: 0x514cf1f1bcb6f498436b1e441b8155401367518d080e57c0498e3e3d91dc7b1a

Après relecture du message de cgeek c’est plus clair.

[poka]

@Moul

en vérifiant cette branche et en obtenant ce hash

Oui je dois supprimer cette branche, elle est obsolète, mais c’était un bon entrainement en soit.

---

La proposition 5 vient d’être exécuté avec succès

La valeur du nextReeval a donc été modifié.

Avant:

Après:

---

Il reste donc:

• Proposition 4 (manque 2 votes): Nouvelle constitution du comité technique
• Proposition 6 (manque 2 votes): Nouvelle valeur du currentUd corrigé

[Moul]

@poka

Avant:

Étrange cette valeur. C’est pas ce qui a été configuré.

---

Ça fonctionne ! Le montant arrête d’être réévalué tous les jours.

[poka]

@Moul

Étrange cette valeur. C’est pas ce qui a été configuré.

Si:

@cgeek

Proposition d’index 5

• fonctionnellement : universalDividend.nextReeval = 1766232000000
• hash de la clé du storage : 0x235cdca73b1fc4b26dd60639fe5bf213510012cc03aa2d41b711cd71b8a63e85
• hash de la valeur : 0x0086a13b9b010000

---

Ah tu veux parler de l’ancienne valeur, si en fait c’est qu’elle a été réévalué plusieurs fois donc n’est plus du tout égale au first_ud_reeval (il rajoutait 6 mois tous les jours)

@Moul

image230×417 9.58 KB

C’est un teasing de Silkaj v2 ?

[Moul]

Le montant initialement inscrit était, toujours avec la conversion de ms en s :

date -d @1766232
Wed 21 Jan 11:37:12 CET 1970

or, ta capture d’écran indique :

date -d @270005832
Sun 23 Jul 02:37:12 CET 1978

La nouvelle valeur est :

date -d @1766232000
Sat 20 Dec 13:00:00 CET 2025

@poka

Ah tu veux parler de l’ancienne valeur, si en fait c’est qu’elle a été réévalué plusieurs fois donc n’est plus du tout égale au first_ud_reeval (il rajoutait 6 mois tous les jours)

Ah oui, en effet. Intéressant.

3600 × 24 × 365.25 / 2 = 15778800
1766232 + 15778800 × 17 = 270005832 s

La date de réévaluation s’est déplacée de huit années et demie (17/2 semestres). Mais était toujours dans le passé. Donc, il y avait réévaluation tous les jours.

---

@poka

C’est un teasing de Silkaj v2 ?

Euh, comment dire, c’est un prototype. J’ai voulu tester l’affichage de tableaux et de graphiques avec deux bibliothèques graphiques.

[cgeek]

@poka

• Proposition 4 (manque 2 votes): Nouvelle constitution du comité technique

Je n’avais pas regardé, je vois que c’est un changement de clé pour Hugo, le retrait d’Eloïs et l’ajout de @aya. J’ai voté, la proposition est passée.

[poka]

Chouette, j’ai exécuté la proposition, bienvenue @aya au comité

---

@cgeek

la proposition est passée

Pour executer une proposition ayant atteint le nombre de vote requis, il faut executer l’extrinsics technicalCommittee.close, qui peut se faire simplement en cliquant sur le bouton “close” à droite de la proposition, remplaçant le bouton de vote.

Reste donc la proposition 6 pour remettre la bonne valeur du DU.

[cgeek]

@cgeek

J’ai n’ai PAS voté la proposition pour la bloquer temporairement tant que la proposition 5 n’est pas passée.

Vu que la 5 est passée, je viens de voter la 6 également.

@poka

il faut executer l’extrinsics technicalCommittee.close

Ma clé est encore dérivée du format Cesium, et je ne peux pas le faire via Ğcli, je te laisse la main.

[poka]

Proposition 6 également passé !

Avant:

Après:

Merci à tous !