[ĞDev proposal] runtime-200

Networks ĞDev
,
1

Le runtime-200 est publié, consultez les release notes:

Pourquoi un nouveau runtime

Il faut éviter d’avoir trop de changements dans un runtime, sinon c’est difficile à vérifier et le risque que l’upgrade se passe mal est plus élevé.

La ĞDev étant la monnaie destinée à recevoir en premier les nouveaux développements, les runtime upgrade y seront toujours fréquents. Ils seront beaucoup moins fréquents sur la ĞTest, et encore moins sur la Ğ1.

Les développements avancent, et il y a déjà suffisamment de changements pour faire un runtime upgrade.

Les changements

Les 4 principaux changements sont les suivants:

  • feat(identity): stricter idty name validation (!55) @tuxmain
  • feat(wot): remove received certs on unvalidated idty removal (!74) @tuxmain
  • feat(identity): remove useless error OwnerAccountNotExist (!78) @elois
  • fix(smith-wot): smith certs expiration should revoke smith membership (!79) @elois

Pour une liste exhaustive, merci de consulter les release notes: runtime-200 · nodes / rust / Duniter v2S · GitLab

Le proposal

Hashs du proposal: 0xa325a37c0e343405e94d69ab8925872c7aec089887dae795f81b91e40178f9ff

Maintenant que nous avons la pallet preimage, nous pouvons enfin créer un proposal qui ne contient pas tout le bytecode wasm, mais à la place une proposition de schedule un call en fournissant uniquement son hash, voyez plutot le détail du proposal:

    {
      args: {
        call: {
          args: {
            id: runtime-200
            after: 100
            maybe_periodic: null
            priority: 0
            call: {
              Hash: 0x5ff7ccaeb332525d207d67df62ca9c725c0ffb5ad855373c1f7e2ebec1a92ca6
            }
          }
          method: scheduleNamedAfter
          section: scheduler
        }
        weight: 1,000,000,000
      }
      method: dispatchAsRoot
      section: upgradeOrigin
    }

On voit que le call proposé est: upgradeOrigin.dispatchAsRoot(scheduler.scheduleNamedAfter("runtime-200", 100, null, 0, Hash(0x5ff7ccaeb332525d207d67df62ca9c725c0ffb5ad855373c1f7e2ebec1a92ca6)), 1,000000000)

Dis plus simplement, on propose de planifier l’exécution d’un call dans 100 blocs, se call devant avoir pour hash 0x5ff7ccaeb332525d207d67df62ca9c725c0ffb5ad855373c1f7e2ebec1a92ca6. Ça correspond au hash de system.setCode(bytecode).

Les 100 blocs, c’est le temps dont on dispose après l’acceptation de la proposition pour publier le bytecode wasm du nouveau runtime. S’il n’est pas publié à temps, il faut revoter :stuck_out_tongue:

Et voici la screen de la création de la proposition:

image
image1729×983 114 KB

Comment vérifier le runtime

  1. Checkout le tag git runtime-200.
  2. Build le runtime avec srtool:
docker run \
  -i \
  --rm \
  -e PACKAGE=gdev-runtime \
  -e RUNTIME_DIR=runtime/gdev \
  -v $PWD:/build \
  paritytech/srtool:1.66.1 build --app --json -cM
  1. Vérifier le champ proposal_hash dans le json fourni par srtool. Srtool utilise subwasm pour calculer le proposal hash, le calcul est fait par ici : subwasm/libs/substrate-runtime-proposal-hash/src/lib.rs at master · chevdor/subwasm · GitHub
    Il s’agit en réalité du hash blake2_256(0x00 ++ 0x03 ++ runtime_bytecode).

Voter

Pour voter il suffit d’exécuter le call smithCollective.vote avec votre compte membre forgeron.

Sont appelés à voter: @cgeek @1000i100 @poka @HugoTrentesaux @vit @kapis @tuxmain

5 Likes
2

Pour l’instant on dirait que seulement @tuxmain a voté pour

1 Like
3

Je suis en soirée, je regarderai demain

2 Likes
4

Vérification du build du runtime-200 faite (mais pas du code source) :
dans compressed.proposal_hash je retrouve le hash : 0x5ff7ccaeb332525d207d67df62ca9c725c0ffb5ad855373c1f7e2ebec1a92ca6

1 Like
5

C’est bien le hash du call qui sera fourni via la préimage. Cela évite de spammer la blockchain avec un nouveau runtime si la proposition n’est pas acceptée.

1 Like
6

J’ai dû voter à l’aveugle, lors de la compilation j’ai une erreur :

error: failed to open: /build/runtime/gdev/target/srtool/release/.cargo-lock
7

c’est juste un problème de droits, lié au fait que docker créer les fichiers en tant que root, entre 2 builds il faut nettoyer:

sudo rm -rf runtime/gdev/target/srtool/
1 Like
8

OK merci, d’ailleurs mon build était super lent jusqu’à ce que je supprime ce dossier. J’ai même dû supprimer un cran plus haut :

sudo rm -rf runtime/gdev/target/

Et je retrouve bien le bon hash 0x5ff7ccaeb332525d207d67df62ca9c725c0ffb5ad855373c1f7e2ebec1a92ca6 pour le binaire compressé. Cool :+1:

2 Likes
9

Je n’ai pas pu publier la preimage du runtime, car le dépôt à effectuer est trop élevé.
Le coup par octet est pourtant fixé au minimum, mais comme on n’a que 2 décimales ça fait 0.01 ĞD par octet, il faut donc 4500 ĞD pour déposer une pre-image de 450 Ko (taille approximative du runtime).

Je vais donc upgrade le runtime avec sudo. On réglera ce problème dans le runtime suivant (300), je pense que le mieux c’est de passer à 3 ou 4 décimales, ce sera également l’occasion de faire une première migration :slight_smile:

3 Likes
10

Et est-ce qu’il ne faudrait pas faire un ticket sur la pallet pre-image pour pouvoir fournir une fraction comme coût par octet ? (du style 1 unité pour 1ko)

1 Like
11

Non ça ne sera jamais accepté de faire une division supplémentaire pour rien, il faut juste qu’on ait plus de décimales comme toutes les cryptos…

1 Like