Downgrade class

[AurevoirXavier]

Able to downgrade a call to normal class.

More and more chains focus on EVM now.
And we people might want to dispatch a call from the EVM.

For example, Darwinia or Moonbeam is an Ethereum-like chain. We set use Gnosis multisig instead of pallet-multisig. And I set the sudo key to that contract address. But I can't dispatch some calls from the EVM due to https://github.com/paritytech/frontier/blob/2b09a676cac8cca665c882a28bd13b2acef39395/frame/evm/precompile/dispatch/src/lib.rs#L67.

So, I think it's okay to have a utility to downgrade a call to a normal class. (it requires roots origin, and people know what they are doing)

---

Or do you think providing a with_class is better?

[bkchr]

I don't see any reason to have this. In general I don't get the reason frontier is checking the dispatch class? What is the reason behind this?

[boundless-forest]

I've submitted another pr to address this issue in the frontier repo. polkadot-evm/frontier#1042 Let's wait the opinion of @sorpaas.

[bkchr]

@boundless-forest ty!

[AurevoirXavier]

I don't see any reason to have this. In general I don't get the reason frontier is checking the dispatch class? What is the reason behind this?

I'm not sure about that. Maybe it's because they haven't done some further research and that's a tmp safeguard.

But I feel this is useful for Substrate. Just like the with_weight. It provides more flexibility to runtime.

[bkchr]

But I feel this is useful for Substrate. Just like the with_weight. It provides more flexibility to runtime.

with_weight is quite different to this. I don't get the need to change the class? The only thing you get from this is that your transaction is getting a lower priority?

[AurevoirXavier]

The only thing you get from this is that your transaction is getting a lower priority?

Yes, you are right. But is it worth having a with_class (to make the priority higher)?

[ggwpez]

But is it worth having a with_class (to make the priority higher)?

We could add Utility::with_class for root to upgrade to Operational or Mandatory.
IMO only really makes sense for Sudo chains, since normally governance goes through the scheduler, and that is already Mandatory.

[bkchr]

We could add Utility::with_class for root to upgrade to Operational or Mandatory.

But this means that some extrinsic will have a higher dispatch class and then we only find out while applying that this someone doesn't has root. I'm still not convinced.

IMO only really makes sense for Sudo chains, since normally governance goes through the scheduler, and that is already Mandatory.

I mean the dispatch class is mainly around the priority of the transaction and the weight space there is reserved. But when would you need this upgrade? Why isn't the particular tx then not directly set to the proper dispatch class?

[AurevoirXavier]

Thanks for your patience and reply.

Maybe the developers want to make some tweaks. They can call this from runtime code or from other pallets to satisfy their service logic.

Why isn't the particular tx then not directly set to the proper dispatch class?

Yes! That's the question. In the Substrate ecosystem, we could use the pallet from any team but developers' knowledge levels might be different. And just like the with_weight, why can't they set the weight correctly at the beginning?

[bkchr]

And just like the with_weight, why can't they set the weight correctly at the beginning?

It is basically a hack to prevent bricking a chain because certain things are not benchmarked properly. with_dispatch_class would only change the transaction orderind/unlock "extra block weight". However for the second thing you could already use with_weight

[xlc]

I don't think we have any real use case for this so how about wait until someone actually find a use case first? Not "I think it will be useful for X" kind, but "I need this to do X" kind.