# \[ĞDev proposal\] runtime-200

**URL:** https://forum.duniter.org/t/gdev-proposal-runtime-200/9495
**Category:** ĞDev
**Tags:** gdev, runtime
**Created:** [18 June 2022 17:35 UTC](https://forum.duniter.org/t/gdev-proposal-runtime-200/9495 "2022-06-18T17:35:40Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [18 June 2022 17:35 UTC](https://forum.duniter.org/t/gdev-proposal-runtime-200/9495/1 "2022-06-18T17:35:40Z")

</div>

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

> **[runtime-200 · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/runtime-200)**
>
> Runtimes The runtimes have been built using srtool v0.9.20 and rustc 1.60.0 (7737e0b5c 2022-04-04)....

## 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](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/55)) @tuxmain
- feat(wot): remove received certs on unvalidated idty removal ([!74](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/74)) @tuxmain
- feat(identity): remove useless error `OwnerAccountNotExist` ([!78](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/78)) @elois
- fix(smith-wot): smith certs expiration should revoke smith membership ([!79](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/79)) @elois

Pour une liste exhaustive, merci de consulter les release notes: [runtime-200 · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/runtime-200)

## 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:

```json
    {
      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 😛

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

 ![image](https://forum.duniter.org/uploads/default/original/2X/2/2762399bbec4007bc5743c0cbdcf47cfa6411b88.png)

# Comment vérifier le runtime

1. Checkout le tag git `runtime-200`.
2. Build le runtime avec srtool:

```docker
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**](https://github.com/chevdor/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](https://github.com/chevdor/subwasm/blob/master/libs/substrate-runtime-proposal-hash/src/lib.rs#L58)  
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

---

_[View the full topic](https://forum.duniter.org/t/gdev-proposal-runtime-200/9495)._