Integrate srml-evm's call/create transaction with weight system

[sorpaas]

Current transaction weight for the srml-evm is fixed. This should be changed to be determined by gas price and gas limit.

#3927 (comment)

[kianenigma]

How though? do you expect to change the weight system itself, or hack around something else?

There are some concerns here:

• The current weight system is built around the idea that the weight of a dispatch is a very cheap data to calculate and is known prior to dispatch. Both of this are justifiable due to the fact that we want the weight to evaluate in a signed extensions's per-dispatch().

• This does not fit into what a smart contract module would need. Both srml-evm and srml-contracts needs to do something different. Yet, I am not sure if we ever want to give up on the assumption above. On one hand, even without srml-contracts/evm, the sudo functions are or any dispatch that has a nested call is not being treated now correctly in substrate. Bot we've discussed this internally and the outcome was the if a call's consumed weight is dynamically a function of the input or state, it must deal with it itself. On the other hand, I think the above assumption about weights being static and fixed is correct and should stay for numerous reasons, and we should not change substrate just for the sake of one module. In such cases, the module itself must do something to adopt.

If we want to take the latter approach (substrate weights will not change), I think this is the minimum, least sophisticated, but functional approach: allow modules to directly increment the weight counter of block in srml-system. We can later on make it prettier. What would happen is:

Henceforth, when I say call I mean a transaction that calls the call method of srml/evm or srml/contracts.

I assume that both evm/contracts module maintain some internal gas metering, in which you charge the gas-limit, you execute, you now know the actual consumed gas and you refund.

• a call has two chunks of weight:
  • static: price of calling the call, setting up the evm/context, all the basics that are fixed, basically calling a call that invokes a noop contract.
• put this ^^ into the #[weight]. so the weight of a contract call is minimal and simple.
• Charge a gas form the user based on the typical gas-limit approach. charge the whole thing and refund a portion or all if something extra was left.
• execute the contract code.
• I assume at this point you know how much gas was actually used. This is the only amount that is overlooked in weight. Given some function F that converts gas to weight, manually add F(gas) to the block weight.

I have a branch in which very simply I demonstrate this with sudo.
https://github.com/paritytech/substrate/compare/kiz-dynamic-branch?expand=1

note1: in the case of srml-contract, a contract itself can execute another dispatch from another srml module. This can get tricky but I guess not the case for evm + we can probably deal with it later. (@pepyakin told me srml/evm also has this)

note2: why do we even have weight? to a) prevent spamming b) charge for the portion that we accept. A module can easily charge itself, if the weight is not enough. Many srml modules do this. contract modules should also do the same via gas metering. The only concern is that a contract transaction might actually consume a big chunk of a block's weight while its weight is very small. Hence, I think, just tweaking the weight post-dispatch is sufficient.

[xlc]

Here is my proposal, that we charge the maximum weight upfront and refund / reduce it when the contract execution completes.

While we cannot calculate the actual transaction weight upfront, we can calculate the upper bound (both srml-evm and srml-contracts have gas limit) and use it as the weight of the transaction and user is initially charged against with this. Later after the dynamic part is executed, the unused gas / weight can then be refunded to user.

Pros:

• Similar behaviour to Ethereum
• It is safer. e.g. While producing a block with 1000 weight remain available, it can pick a dynamic weight transaction with upper bound of 1000 and know it will fit into the block. Otherwise it may be spend time packing a transaction and a weight increase happened which causes this transaction unfit and therefore wasting time.
• The assumption of the weight can be statically calculated largely remains the same. It changes to the upper bound of the weight can be statically calculated. We don't need to classes of weight (static vs dynamic) in the concept level (we can totally have them on the implementation level).
• User can use the fee PRC to determine the max fee. Knowing the min fee is less useful.
• No need to have separate inaccurate block gas limit check. The weight system handles it.

substrate/srml/contracts/src/lib.rs

Line 1062 in 1d5cae9

let gas_available = T::BlockGasLimit::get() - <Module<T>>::gas_spent();

Cons:

• I think it will be bit more complicated to implement reduce weigh. Previously the weight only increases, now it can decreases.
• More edge cases regards to ExistenceRequirement

[pepyakin]

@kianenigma

correction, I said that it is the current idea that evm also will have this.

@xlc Yeah, this is broadly pretty much what I and I believe @kianenigma have in mind.

Here are a few notes:

1. Yes, we refund the user, but I'd argue that a more important thing is that we also update the accurate block weight, thus allowing packing the block densilly and avoiding the case where a transaction can set the full upper bound but consume the least possible amount of gas (effectively buying the block weight in the cheapest).
2. I am not sure why would it be hard to reduce weight, although I am concerned about the breaking this weight-only-increases invariant. However, we don't necessarily have to break it: we might get away with only one call to increase the weight after it the effective consumed weight is known. This depends on the way the extra dynamic weight booking API though. Otherwise, due to the fact that srml-contracts and, and srml-evm in the future, have ability to call other modules directly, the other modules can observe this invariant broken, e.g. if called both within a contract extrinsic dispatch and somehow after (due to extrinsic call or another contract call).
3. I would argue that contract calls (and really possibly all calls) should not lower the balance lower than the existence deposit unless this is opt-in explicitly. This is already the case for srml-contracts. So I don't see a reason why would be there more edge cases for existence requirement. Am I missing something?

[xlc]

If the only way to kill an account is explicit balance transfer then we won't have any edge cases about existence requirement. Other as part of the charge transaction fee, it could kill the account and causing side effects (e.g. remove nonce) and then refund restore the account but it is too late to undo the side effects.

[kianenigma]

@sorpaas I didn't re-read the entire discussion again but at least from the title of the issue I can say this is closed?

[shawntabrizi]

@sorpaas is this done already in frontier?

[sorpaas]

Yeah I think this is already done!