search

paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.network/
1.63k stars 573 forks source link

Vision: Allow users to limit weight spent in categories of calls #196

Open rphmeier opened 1 year ago

rphmeier commented 1 year ago

FRAME is mostly centered around purpose-built chains, where all pallets or calls a runtime exposes have equal priority, in the sense that a chain's blockspace is allocated to all its pallets with equal priority.

As chains evolve, they may choose to allocate more or less weight to specific pallets or bundles of Calls. The easiest example of this would be chains that expose some specialized functionality, but wish to enable smart contracts as well. Such a chain might want to allow smart contract calls for both pallet-contract or some pallet-evm, but only cumulatively up to e.g. 20% of the block's Weight.

The node-side code looks to already accommodate this use-case with TransactionValidityError::Future, but we need an easy way to plug into pallet-transaction-payment or some other entry point to return this.

xlc commented 1 year ago

Sounds like this https://github.com/paritytech/polkadot-sdk/issues/1140

DispatchClass already allow reserve x% of block space for operational transaction.

rphmeier commented 1 year ago

@xlc Nice, I missed paritytech/polkadot-sdk#1140 - looks like it was closed, but wondering if you think this is worth keeping open to make it simpler

rphmeier commented 1 year ago

AFAIK paritytech/polkadot-sdk#1140 doesn't fully cover this use-case, as I understand that DispatchClass is set by the pallet author, whereas I would want transactions to be categorizable by the runtime builder.

xlc commented 1 year ago

We can do something similar to EnsureOrigin to allow pallet developers to make the dispatch class of pallet calls to be configurable by runtimes.

kianenigma commented 1 year ago

A meta comment that comes to mind about this is that we have possibly mis-worded the term DispatchClass. It makes little sense that something like on_initialize registers some weight with dispatch class mandatory.

While doing this, we should consider:

  1. renaming this whole thing to WeightClass
  2. make WeightClass extensible, such that arbitrary classes can be defined and used.

This might actually make the migration easier. We can leave the existing DispatchClass as-is and mark it as deprecated.