ĞDev runtime 500

Networks Technical committee
, ,
1

Cette fois-ci je le fais en français, si on a plus de contributeurs non francophones, je pourrai repasser à l’anglais. Il est temps de faire un runtime upgrade sur la ĞDev, pour apporter de nouvelles fonctionnalités et faciliter le développement

(cf Renommage de "smiths" en "smith" : jongler avec deux runtimes)

Voici ci-dessous certains points importants du runtime-500. Pour ce qui touche aux benchmarks, il reste à les faire tourner sur la machine de référence. Merci beaucoup à @bgallois pour son énorme travail :slight_smile: (et il nous réserve encore quelques surprises pour la suite…)

  • Storage benchmark (!167)
  • refac membership renewal (!166)
    • :information_source: possibilité de redevenir membre après la perte d’adhésion
  • fix certification period on renewal (!165)
  • Fix pallet-certification benchmark (!164)
  • Offences management (!161)
    • :information_source: enfin !! les noeuds hors ligne seront exclus automatiquement sans pénalité
  • Fix certification renewal (!159)
  • Fix/108/certification expiry (!158)
  • Substrate pallets benchmark (!156)
  • Authority-members pallet benchmark (!155)
  • Oneshot account pallet benchmark (!153)
  • style: rename smiths* to smith* almost everywhere (!148)
  • Membership pallet benchmark (!147)
  • Certification pallet benchmark (!145)
  • doc(smith): fix: no setSessionKeys before being smith (!144)
  • doc(smith): fix, clarify (!143)
  • Duniter-account pallet benchmark (!140)
  • Provide-randomness pallet benchmark (!139)
  • Identity pallet benchmark (!138)
  • add storage benchmarks & base block benchmarks (!118)

Il n’y a pas de problème de comptabilité avec le client, pas besoin de mettre à jour les nœuds forgeron.

Pour savoir comment vérifier le nouveau runtime et voter l’upgrade, cf

Voici la proposition que j’ai soumise :

Capture d’écran du 2023-06-08 10-37-42
Capture d’écran du 2023-06-08 10-37-421920×1080 258 KB

Elle peut être votée ici : https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/techcomm/proposals

@technical-committee, à vous de jouer :slight_smile:

3 Likes
2

Pour voter avec gcli (en mode dev) :

# gcli command to vote proposal
gcli --network gdev --secret 'xxx' tech vote \\
0x9cf8bf1964a54dc05ad7b6420504c3038cbe825be6e73dbed1b7e6a45781796b 7 1
#           proposal hash  ↑                        proposal index ↑ ↑ yes/no
⚠️ indexer does not have the same genesis hash as blockchain
transaction submitted to the network, waiting 6 seconds...
Error: Anyhow(Runtime error: Module(ModuleError { pallet: "TechnicalCommittee", error: "DuplicateVote", description: ["Duplicate vote ignored"], error_data: ModuleErrorData { pallet_index: 23, error: [4, 0, 0, 0] } }))
  • oui, il y a un bug de l’indexeur qui pense que le genesis hash est le hash du bloc 1 et pas du bloc 0, c’est corrigé en dev, mais pas encore en prod
  • oui, comme j’ai déjà voté, ça retourne une erreur DuplicateVote, on peut le voir dans le bloc 2507420.
3

J’ai voté oui, même si je ne comprends pas tout. Je fais confiance…

1 Like
4

Donc on assume que les poids seront sous-évalués jusqu’au prochain runtime upgrade où on aura pris le temps de benchmarker sur la machine de référence ?

5

Tu peux le voir comme ça. Ou alors on peut considérer que la machine de référence de la ĞDev est le laptop de Benjamin. Si quelqu’un a un serveur moins puissant que le laptop de Benjamin, elle pourrait ne pas tenir un stress-test.

6

Gros upgrade, je verrai bien ce qui casse ou non avec gecko côté API.
A voté.

7

Je me mets un pense-bête pour m’occuper de ça ce soir.

8

J’ai fait le build srtool à partir du tag runtime-500, et je ne retrouve pas les mêmes hash :

{
  "gen": "srtool v0.9.25",
  "src": "git",
  "version": "3.0.0",
  "commit": "dabb2c0905cf0212470968261720d66da9eb3312",
  "tag": "v0.4.0",
  "branch": "heads/runtime-500",
  "rustc": "rustc 1.66.1 (90743e729 2023-01-10)",
  "pkg": "gdev-runtime",
  "tmsp": "2023-06-08T18:02:50Z",
  "size": "463086",
  "prop": "0xc7f75cf824145f3e3fe62d726949bfc9b4aaee8ec4feee223c1ff25e0aeb0f9d",
  "authorize_upgrade_prop": "0x5a8821a419f4a2c168bcb3f62946941c741d179bd26c6dfea572713df5a1995b",
  "ipfs": "QmRhFnZ41mN5izeQYgNKb5WWGQK6do91Q1p2XUuAi9u5LV",
  "sha256": "0xafbec69ff8eab7d030e79d5eb03799a4d6dc3a245a8e0669a23c23c8ddbd5cdb",
  "wasm": "runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm",
...
    "compressed": {
      "tmsp": "2023-06-08T18:01:37Z",
      "size": "463086",
      "prop": "0xc7f75cf824145f3e3fe62d726949bfc9b4aaee8ec4feee223c1ff25e0aeb0f9d",
      "authorize_upgrade_prop": "0x5a8821a419f4a2c168bcb3f62946941c741d179bd26c6dfea572713df5a1995b",
      "blake2_256": "0x4f05f3874134b5992a6c6b1201231c6e7a16c21eddecfd9f07283c5c4c1adbf4",
      "ipfs": "QmRhFnZ41mN5izeQYgNKb5WWGQK6do91Q1p2XUuAi9u5LV",
      "sha256": "0xafbec69ff8eab7d030e79d5eb03799a4d6dc3a245a8e0669a23c23c8ddbd5cdb",
      "wasm": "runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm",
...
        "proposal_hash": "0xc7f75cf824145f3e3fe62d726949bfc9b4aaee8ec4feee223c1ff25e0aeb0f9d",
        "parachain_authorize_upgrade_hash": "0x5a8821a419f4a2c168bcb3f62946941c741d179bd26c6dfea572713df5a1995b",
        "ipfs_hash": "QmRhFnZ41mN5izeQYgNKb5WWGQK6do91Q1p2XUuAi9u5LV",
        "blake2_256": "0x4f05f3874134b5992a6c6b1201231c6e7a16c21eddecfd9f07283c5c4c1adbf4"
      }
    }
  }
}

Je lance srtool avec ce script :

#!/bin/bash

docker run --rm -i -e PACKAGE=gdev-runtime -e RUNTIME_DIR=runtime/gdev -v $PWD:/build -v $PWD/srtool-out:/out -v srtool-cache:/home/builder/cargo -u root paritytech/srtool:1.66.1 sh -c "
  sed -i '/builder:/s/1001/'$UID'/' /etc/passwd
  chown builder /home/builder
  chown builder /out
  exec su builder -c '
    PATH=.:\$PATH
    build --app --json -cM
  '
"

Qu’est-ce que j’ai raté ?

9

Ça c’est master, pas runtime-500.

(le commit de runtime-500 c’est 2d6e8b2be7917c75504bb0353f3d9681a5461f55)

10

Ah ça y est, je comprends mon ânerie :man_facepalming:
J’ai fait git checkout -b runtime-500 au lieu de git checkout runtime-500.
(à ma décharge j’ai eu une dure journée…)

Merci @HugoTrentesaux !

1 Like
11

Plus qu’un vote de @1000i100 @cgeek @Moul ou @vit pour que la proposition puisse être validée ! (et il faudra mettre en ligne l’image sous 600 blocs = 1h après cloture.

12

J’arrive trop tard, @vit a voté :slight_smile:

1 Like
13

Toujours possible de voter, mais en soumettant l’extrinsic à la main, c’est juste pas proposé dans polkadotjsapp. Gcli fonctionne bien pour ça :slight_smile:

1 Like
14

Proposition fermée au bloc 2543359
Préimage fournie au bloc 2543380

1 Like
15

SetCode a échoué au bloc 2,543,960

image
image910×600 34.8 KB

Le poids donné initial “lenghtBound” était de 1000000 (un million) et le poids du runtime duniter-v2s/runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm était de 463080 octets.

(en cours d’investigation)

2 Likes
16

J’ai finalement fait le call en sudo en utilisant sudoUncheckedWeight

image
image1766×880 198 KB

Il est passé au bloc 2785277 (ça n’a pris que 0.05% du poids disponible), nous sommes maintenant au runtime 500.

Si on avait voulu faire avec le technical committee, il aurait fallu faire upgradeOrigin.dispatchAsRootUncheckedWeight(), mais le fonctionnement est le même.

Je n’ai pas bien compris comment était faite l’estimation de poids. Dans frame/system/src/lib.rs, on voit ceci :

#[pallet::weight((T::BlockWeights::get().max_block, DispatchClass::Operational))]
pub fn set_code(origin: OriginFor<T>, code: Vec<u8>) -> DispatchResultWithPostInf

Donc je m’attendais à ce que le poids de setcode soit toujours le maximum d’un bloc, mais apparemment je passe à côté de la raison… :thinking:

@bgallois qui a bien bossé la question des poids aura sûrement une meilleure idée ><

3 Likes
17

Je viens de voir que la branche release/runtime-500 n’avait pas été mergée dans master, donc que la version du Runtime ou de Srtool n’était pas à jour. Je viens donc de le faire.

1 Like