Question: Why does `alith` act as a signer during upgrade even when not set as sudo?

[magecnion]

I noticed that when testing an upgrade by running moonwall test using Chopsticks as the environment, alith acts as the signer. However, on the forked chain, alith is not set as sudo. I couldn't find any code where alith is designated as sudo.

I initially thought that the mock-signature-host: true setting might be enabling this behavior, but even when I change its value to false, alith is still able to perform the upgrade.

[timbrinded]

The immediate answer to your question is that enacting an authorized runtime upgrade is permissionless, any signer can do it if the bundled wasm blob hashes to the same amount as <parachainSystem/system>.authorizedUpgrade storage.

---

More Context

For polkadot parachains, a runtime upgrade is composed of two steps:

1. Hash a runtime upgrade wasm blob and register it as authorized
2. Submit the wasm blob to the chain so that it replaces the active runtime

Step 1 is actually just a simple storage write, so with chopsticks we can just override the storage value to whatever we calculate the hash to be. i.e. we use the setStorage endpoint:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "dev_setStorage",
  "params": [
    {
      "parachainSystem": {
        "authorizedUpgrade": "0xbb6051f13dd1cf55d3549fb6f46a5e8febfb1a63b25fa86617f5cbd9b5fa88e201"
      }
    }
  ]
}

However like you mentioned, you can use sudo on dev chains to set this value to whatever. In production, you would use governance to set this value. Other alternatives would be to even change the genesis block (via the chainspec) to have a "pre-authorized" blob hash, which is useful for zombienet testing production runtimes.

What all these methods have in commmon is that once the storage is loaded with the correct hash, anyone can call system.applyAuthorizedUpgrade() if the bundled wasm hashes to the same value.

---

Hope that helps!

[magecnion]

Now it all makes sense. Thanks for the detailed answer.