ĞDev runtime 802 -- release

Networks Technical committee
1

Il était temps de proposer la mise à jour vers le runtime 802 !! (cf ĞDev Runtime 802 -- suivi). Voici la page de release :

🔨 Srtool version: srtool v0.15.0
🦀 Rustc version: rustc 1.77.0 (aedd173a2 2024-03-17)
🏋️ Runtime Size: 655 KB (671530 bytes)
🔥 Core Version: gdev-802
🗜 Compressed: Yes: 78.10 %
🎁 Metadata version: 14
🗳️ system.setCode hash: 0xa1f1d6cd467574050db78203ee439b3d194952bfba575dca4b6f6983d15c3f7b
#️⃣ Blake2-256 hash:  0x70b82abc8af0b5b90372d5d844a5b4bba809ba0287e357d976eabc1b7c175ebc

Merci à @Moul d’avoir réparé les images docker utilisées dans la CI. Merci à @cgeek pour cette CI. Merci à @bgallois pour de nombreuses MR. Curieusement, il y a eu un problème avec les release notes sur Gitlab, donc les voici :

Merge requests

  • Fix 245 (!277)
  • Fix distance end2end tests (!276)
  • Upgrade polkadot v1.14.0 (!274)
  • Resolve “Dissociate release of Runtime and release of Client” (!273)
  • Separate weight by chains (!272)
  • Fix #232 (!268)
  • Fix #200 (!267)
  • adapt ci to export new py-g1-migrator history files (!266)
  • Fix #218 and #158 (!265)
  • update doc for rpc port (!264)
  • Upgrade to polkadot-v1.11.0 (!263)
  • Fix #179 (!262)
  • update srtool build instructions (!261)
  • Fix #221 (!259)
  • Upgrade to polkadot-v1.9.0 (!258)
  • Fix #219 and #220 (!257)
  • Refactor node implementation (!256)
  • Resolve “Allow native Runtime execution” (!255)
  • Refac generated documentation (!254)
  • Fix #196 forbid empty linked account (!253)
  • Change distance evaluation period from Sessions to Blocks (!252)
  • Fix misleading error message when Babe owner keys != 1 (!251)
  • allow oracle connexion through “insecure url” (!250)
  • Fix srtool (!249)
  • Fix live tests (!248)

Issues

  • Distance oracle must have state to download WoT (#249)
  • Add PUBLIC_ADDR to docker env var (#246)
  • document UnitsPerUd (#240)
  • Yunohost package (#237)
  • Maximal proof_size (#236)
  • Exonerate all transaction fees when blockchain use is low (#232)
  • Complete migrator CI (#229)
  • Currency trait deprecation (#226)
  • Benchmarks error (#225)
  • Oracle : ne pas se bloquer à cause des clés (#221)
  • Smith-members: invert issuer and receiver in events (#220)
  • Distance : rajouter le résultat dans l’évènement (#219)
  • Protocole : ne pas autoriser la création d’une identité où le compte n’existe pas (#218)
  • Polkadotjs UI : perte de la description dans les calls (#217)
  • Allow native Runtime execution (#214)
  • Distance oracle tries to publish inherent even if already published result, leading to ExtrinsicFailed result of the inherent (#207)
  • align distance oracle on modulo instead of session (#202)
  • distance oracle refuses “insecure url” (#201)
  • debian package (#200)
  • Use IdtyIndex as Session ValidatorId (#197)
  • Check that transfer_all on a linked account does not lead to empty linked account (#196)
  • Dissociate release of Runtime and release of Client (#195)
  • Misleading error message in logs for distance oracle (#191)
  • Refac generated documentation (#183)
  • Merge identity/pubkey “conversion” trait into one (#179)
  • Calibrate distance MAX_EVALUATIONS_PER_SESSION (#174)
  • Membership handler weight accounting (#167)
  • Split OnEvent(membership_event) (#163)
  • Add live tests for membership status coherence (#161)
  • Identity creation should only be possible for an account that already “exists” (#158)
  • Contribute to Cesium² (#142)
  • Could not find protoc (#112)

Runtime upgrade

Dans la nouvelle version de substrate (cf frame_system - Rust), il y a un nouveau mécanisme pour les runtime upgrade que je propose d’essayer cette fois ci. Voici comment je soumets la proposition :

image
image1923×584 97.9 KB

Le comité technique (@technical-committee) peut s’exprimer et voter depuis l’appli polkadotjs :

image
image1923×371 41.5 KB

https://duniter-portal.axiom-team.fr/#/techcomm/proposals

Je n’ai pas fait de tests approfondis (try_runtime, tests en local, live tests…) mais a priori ça devrait pas casser :face_with_peeking_eye:

5 Likes
3

Je ne peux pas voter, c’est parce que le seuil est atteint ?

4

image
image1923×371 48.3 KB

Je suppose que c’est parce que tu essayes de voter avec ta nouvelle adresse alors que c’est toujours 5EVRzJDpDxFNU9cbrGPdQD5sRsV2uiKMPNgr1sbRDX4X6Ex8 qui est dans le comité technique.

1 Like
5

Pour les test Ğecko, la plupart des compte Ğ1 sont désormais en identité expiré, ce qui complique les tests après migration d’identité.
Un reboot faciliterai la chose, avec allongement des durées d’expiration genre à 10 000 ans.

1 Like
6

Plutôt rallonger de 1 ou 2 ans que 10000, sinon ce seront les fonctionnalités en rapport avec les temps d’expiration qui seront dures à tester :stuck_out_tongue_winking_eye:

3 Likes
7

Un reboot oui, changer la durée d’expiration non, ça permet de tester le retour dans la toile de confiance après l’avoir quitté !

Oui c’est ça, j’ai voté ! :wink:

3 Likes
8

A voté !

2 Likes
9

Je peux te partager les clés sudo si tu veux renouveler en masse des identités. Ou je peux le faire, ça peut être marrant ><

Contre :stuck_out_tongue:

2 Likes
10

Oui parce que je suis plus pour un reboot qu’un upgrade.

Mais si on peut renouveler en masse alors je vais peut-être changer mon vote :slight_smile:

1 Like
11

Les deux ne sont pas exclusifs. On peut faire un upgrade pour s’entraîner à en faire (preuve que c’est utile, j’ai découvert le nouveau fonctionnement), et en parallèle lancer un nouveau réseau. En plus maintenant c’est entièrement automatisé (Industrialiser le démarrage d'une nouvelle Ğx), il suffit de faire une branche network/gdev-900 et de cliquer sur le bouton trigger_network_release de la CI. Ensuite il ne reste plus qu’à lancer un nœud qui utilise les nouveau gdev_raw.json et dire aux autres de se connecter en ajoutant son nœud aux bootnodes. Ça demande un peu de boulot pour les forgerons, mais ça ne fait qu’une dizaine de personnes à contacter pour l’instant. Pour que ce soit utilisable dans les apps, il faut aussi lancer un indexeur, puis demander à tous les endpoints hardcodés dans les apps de passer sur le nouveau réseau sinon on risque d’avoir des comportements bizarres si les apps se connectent aléatoirement à l’un ou l’autre des réseaux. En tout cas c’est le bon moment pour implémenter le scan réseau !

2 Likes
12

Rah! la nomenclature de branche des runtimes a changé de runtime-XXX à network/gdev-XXX. Je m’en suis rongé les ongles :beaver: Déjà que ce foutu d’outil de srtool est une méchante bête à maitriser. Il m’a fallu retrouver mes notes de galères pour la fouter correctement.

Ma recette :

podman run -it --rm -e PACKAGE=gdev-runtime -e RUNTIME_DIR=runtime/gdev paritytech/srtool:1.77.0 bash
cd /build
git clone https://git.duniter.org/nodes/rust/duniter-v2s -b network/gdev-XXX .
./srtool/build
Summary 
Summary generated with srtool v0.15.0 using the docker image paritytech/srtool:1.77.0:
 Package     : gdev-runtime v1.0.0
 GIT commit  : 313f6da1be68af716589b37509fbeba3468c733e
 GIT tag     : gdev-802
 GIT branch  : network/gdev-802
 Rustc       : rustc 1.77.0 (aedd173a2 2024-03-17)
 Time        : 2024-09-26T13:12:25Z

== Compact
 Version          : gdev-802 (duniter-gdev-1.tx1.au1)
 Metadata         : V14
 Size             : 2.92 MB (3066320 bytes)
 setCode          : 0x52439e4b2991f1bf104b127d23e9aed5bb06c576d3cd4b1bb616db20d3e569e9
 authorizeUpgrade : 0x07a9e150364f6db4844d320d4f6e6dc8114d59cc2e3b582dd6cdd0332d8e7465
 IPFS             : QmNNLpnhjdKxLnR7Hpd46LxYFkHXEbsCQyzaCBjxqsffKA
 BLAKE2_256       : 0x0df38ccfd7162db2923d4d259c4d14c4c1254bcc96d7ef87533b708b6ea62088
 Wasm             : runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.wasm

== Compressed
 Version          : gdev-802 (duniter-gdev-1.tx1.au1)
 Metadata         : V14
 Size             : 655.79 kB (671530 bytes)
 Compression      : 78.1%
 setCode          : 0xa1f1d6cd467574050db78203ee439b3d194952bfba575dca4b6f6983d15c3f7b
 authorizeUpgrade : 0x446434189063e1becada5e42963f5b527cb54e5825a8ad62041bd40eddf82499
 IPFS             : QmTp4zLAUeWFCwU6BLBqVv4XbjV9MdDAHb4h61LsSZgVbs
 BLAKE2_256       : 0x70b82abc8af0b5b90372d5d844a5b4bba809ba0287e357d976eabc1b7c175ebc
 Wasm             : runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm

Vérification sous bash :

diff <(printf "%s\n" "0x70b82abc8af0b5b90372d5d844a5b4bba809ba0287e357d976eabc1b7c175ebc") <(printf "%s\n" "0x70b82abc8af0b5b90372d5d844a5b4bba809ba0287e357d976eabc1b7c175ebc")

Je valide le runtime généré. A approuvé cette évolution de runtime !

Il faut voter avec son compte ed25519 (v1) (oldAddress) qui fait partie du comité technique :

gcli -S cesium tech vote 26562676f3882053f290f2ec184bb2b84b3b0eaa53941d2c530eeb7c333cc36b 0 1

Cesium id: 
Cesium password: 
transaction submitted to the network, waiting 6 seconds...
voted Voted { account: AccountId32([232, 175, 253, 40, 186, 3, 78, 77, 188, 109, 8, 232, 45, 162, 46, 98, 252, 51, 108, 137, 239, 69, 220, 93, 75, 28, 250, 91, 62, 63, 237, 32]), proposal_hash: 0x26562676f3882053f290f2ec184bb2b84b3b0eaa53941d2c530eeb7c333cc36b, voted: true, yes: 4, no: 1 }
2 Likes
13

État actuel du vote :

image
image1631×186 18.5 KB

Encore trois jours. 5 votes sur 6.

14

J’ai l’impression que j’ai été sorti du comité technique, tant mieux car je ne peux pas suivre :confused:

edit : d’ailleurs vous pourriez également me sortir des Smith initiaux en cas de reboot.

15

T’en fait parti avec ton compte ed25519 (v1) :

image
image1642×315 21 KB

16

Il manque un vote positif de l’un de vous trois : @vit, @cgeek, @poka.

17

Ah yes ! C’est fait, du coup. Mais ma remarque vaut toujours, vous pouvez me sortir si je gêne.

2 Likes
18

TL;DR: runtime upgrade au bloc 3270553 :tada:

Voici la version longue :

image
image1737×342 39.6 KB

J’ai cliqué sur “fermer”, ce qui a eu lieu au bloc 3270447. Mais ça a abouti à une erreur BadOrigin.

image
image1737×696 146 KB

Une fois de plus, j’ai oublié que le comité technique n’était pas une origine acceptée pour les call systèmes, raison pour laquelle elois avait fait la pallet “upgrade origin”. Il aurait fallu faire upgradeOrigin.dispatchAsRoot(...) pour que ça fonctionne.

Ce n’est pas le cas si on utilise directement sudo (cf bloc 3270522), je vais donc continuer cette fois comme si je ne m’étais pas trompé dans la proposition, mais on pourra se ré-entraîner prochainement pour changer le comité technique.

Une fois le authorize upgrade exécuté, n’importe quel compte peut demander le runtime upgrade avec system.applyAuthorizedUpgrade :

image
image1737×626 181 KB

C’est donc fait au bloc 3270553 :tada: (notez que je l’ai fait avec un compte quelconque).

Maintenant, il reste à observer le comportement pour voir si on n’a rien d’anormal.

5 Likes