ĞDev runtime 401

[HugoTrentesaux]

It has been a while since we did not released and upgraded to a new runtime, and it was never done on ĞDev5. With the new subsquid indexer I think we have the tools to understand a bug if there is any.

runtime-401 · nodes / rust / Duniter v2S · GitLab

Here are the main updates of runtime-401:

• MR !112 more detailed error messages when identity creation fails
• MR !121 upgrade to substrate v0.9.32 by tuxmain
• MR !119 restrict identity name according to discussion Format du UserID
• MR !133 improve documentation of runtime calls (will be visible in polkadotjs app)

It is compatible with client v0.4.1 which is available on latest docker image (duniter/duniter-v2s:latest) and which comes with a lot of docker improvement and substrate v0.9.32 features. Most of the nodes are running a version very close even it is labeled v0.3.0.

---

@technical-committee you can rebuild this runtime to check the hash with srtool and if you agree, vote for the proposal number 6: https://polkadot.js.org/apps/?rpc=wss://gdev.coinduf.eu/ws#/techcomm/proposals

[ĞDev proposal] runtime-200

[HugoTrentesaux]

The proposal has 4 votes over 7 needed (Polkadot/Substrate Portal). @1000i100 @cgeek @Maaltir @Moul @vit, do you need additional information to take part in the vote?

[cgeek]

No thanks, I’m currently checking the runtime hash, give me one day.

[vit]

I got two proposal_hash in the srtools json. The second one match the H256 (Hash) of the proposal number 6.

But when I am voting, I give the hash H256 (Hash) of the proposal number 6, keep the index at 0 (do not know what it is), then select “Yes”.
The response is an error TechnicalCommitee.ProposalMissing

I am quite stuck here…

[tuxmain]

The index must be 6. (proposals are uniquely indexed)

I don’t know how to get the index in a proper way in the storage, I guess the only way is to rely on proposals ordering and the total proposals count.

The “Tech Comm” tab in PolkadotJS handles all this automatically.

[Maaltir]

En fait je ne sais pas du tout comment faire…

[vit]

When I put 6 as the index, same error. May be the hash is not good after all…

The procedure really needs a clear documentation on a wiki.
It was a pain to find info spread on the forum messages here (I blame no one here, and may be I will do it and publish a personal doc soon, if my attempt is a success ).

EDIT:
The hash to provide is this ?
0xe377706f91aea6f20911f2bb750de9c267fd1019227424dbd64465e732c85efb

[cgeek]

I’ve just voted, it’s very simple: go to Governance > Tech. comm. > Proposals and then you have a “Vote” button on the right:

[tuxmain]

@vit

The hash to provide is this ?
0xe377706f91aea6f20911f2bb750de9c267fd1019227424dbd64465e732c85efb

No, this is the runtime’s hash, that is included in the call contained in the proposal. You must approve the proposal’s hash, which can be found by 2 ways:

• storage: proposalOf (it’s the key)
• storage: proposals

And at high level by 2 ways:

• high level polkadot JS tab
• Gcli

In this case it’s 0x946a95ab1c79a5c97e143ceb2d6ee98f181d0bca28c09770f46abe3d57cb140c.

Using the RPC API you may find 512b hashes, then the proposal’s hash is the second half.

[HugoTrentesaux]

@Maaltir

En fait je ne sais pas du tout comment faire…

Je propose que tu votes par confiance en attendant qu’on rende la vérification plus facile. Pour voter, voici comment faire (à l’envers) :

Comme l’a montré cgeek, tu peux aller dans https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/techcomm/proposals (Governance > Technical Committee > Proposals) et cliquer sur “vote”.

Cela nécessite d’avoir installé au préalable l’extension navigateur polkadot{.js} et d’y avoir ajouté ton mnemonic Ğecko (avec le bon chemin de dérivation si nécessaire, je ne sais plus où on en est de ce point de vue).

---

@Moul

I am having an issue with the permissions:

You have to read messages 5 and 6, this issue remains to be fixed. A chmod is necessary.

---

@vit this is what happens:

1. srtool allows to build the runtime in a reproducible manner
2. it gives two hashes written on the release page:

• #️⃣ Blake2-256 hash: 0x59e84456b6e8ae8e8ddba9e4617e673e1569773d359989e689ada34206d0f8d3 which is the hash of the runtime (the output binary)
• 🗳️ system.setCode hash: 0xe377706f91aea6f20911f2bb750de9c267fd1019227424dbd64465e732c85efb which is the hash of the scale encoded call to upgrade the runtime to this version

3. in the proposal (screenshot below), you can see three hashes:

• 0xe3777... which is the hash of the “system.setcode” call we are voting for. The call is not submitted yet, but it can be published after the vote is accepted, since there is no need to upload a runtime to the blockchain if it is rejected
• 0xf7dc7... which is the hash of the “schedule.schedulenamedafter” call allowing us to schedule a call in the future
• 0x946a9... which is the hash of the proposal, the one we have to vote for

But as shown above, there is no need to perform this call manually because the pallet collective we are using for the “technical committee” has been implemented in recent version of polkadotjs app. And so there is a rather intuitive interface to cast the vote.

[Moul]

What’s wrong here?

gcli-v2s (master) [1]> cargo run -- -S seed -u ws://localhost:9945 tech-vote 0x59e84456b6e8ae8e8ddba9e4617e673e1569773d359989e689ada34206d0f8d3 6 1
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/gcli -S seed -u 'ws://localhost:9945' tech-vote 0x59e84456b6e8ae8e8ddba9e4617e673e1569773d359989e689ada34206d0f8d3 6 1`
Secret key (Seed): 
Error: Rpc error: RPC error

Caused by:
    RPC error

I can list tech-proposals:

cargo run -- -u ws://localhost:9945 tech-proposals
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/gcli -S seed -u 'ws://localhost:9945' tech-proposals`
946a95ab1c79a5c97e143ceb2d6ee98f181d0bca28c09770f46abe3d57cb140c
UpgradeOrigin(
    dispatch_as_root {
        call: Scheduler(
            schedule_named_after {
                id: [
                    114,
                    117,
                    110,
                    116,
                    105,
                    109,
                    101,
                    45,
                    52,
                    48,
                    49,
                ],
                after: 100800,
                maybe_periodic: None,
                priority: 0,
                call: Hash(
                    0xe377706f91aea6f20911f2bb750de9c267fd1019227424dbd64465e732c85efb,
                ),
            },
        ),
    },
)

5aa30a5ceee32ddf4fc2db22a6f36c93f4fbafe25ce577f5acf7d4df2bf5cdfe
[…]

[Pini]

@Maaltir Tu as voté pour la proposition n°3 qui est obsolète. C’est pour la n°6 qu’il faut voter :

[Moul]

Threshold reached 7/7. It is no longer possible to vote once the threshold is reached. Ready to be close.
I voted on proposal index 4 from py-substrate-interface!

[HugoTrentesaux]

I closed the proposal in block 1 386 843.

Then somebody had to upload the preimage corresponding to what was voted:

system.setCode(runtime401)
# hash 0xe377706f91aea6f20911f2bb750de9c267fd1019227424dbd64465e732c85efb

I checked that my local wasm bytecode has to correct hash:

$ pwd
/home/hugo/dev/duniter-v2s/runtime/gdev/target/srtool/release/wbuild/gdev-runtime
$ b2sum -l 256 gdev_runtime.compact.compressed.wasm 
59e84456b6e8ae8e8ddba9e4617e673e1569773d359989e689ada34206d0f8d3  gdev_runtime.compact.compressed.wasm

I checked that the setCode call has the correct hash and get the encoded call data in polkadotjs:

I pasted the encoded call data in a preimage.notePreimage() call:

The runtime has been successfully uploaded in block 1 387 375. It will be applied as scheduled at block 1 487 644 (next Tuesday if we do not loose smith in the meantime).

[cgeek]

Indeed, there we are: