Conversation
| ); | ||
| Self::apply_validated_transaction(source, transaction); | ||
| let r = Self::apply_validated_transaction(source, transaction); | ||
| weight = weight.saturating_add(r.actual_weight.unwrap_or(0 as Weight)); |
There was a problem hiding this comment.
I wonder if this would cause us to double-account for weight and have the effect of lowering throughput. The base Ethereum txn fee is a sort of fudge for handling transaction inclusion, which could be considered to cover this.
What is complex about this is that it happens in different blocks... it makes sense to account for the weight of work done in the block it occurs in. But again, I think this might have the net effect of us lowering txn throughput.
One idea we could explore to deal with this is reducing the weight (but not the gas) charged for txns in a block with the expectation that that weight is charged in on_initialize() in the following block.
There was a problem hiding this comment.
This is for wrapped blocks and you are not using this code path at all on a Substrate chain (Moonbeam, Moonriver)!
Regarding tx throughput in general -- adding weight will not reduce it. It just provides information and avoids spams. You can arbitrarily increase overall block weight to a really large value if the chain can handle it.
There was a problem hiding this comment.
Thanks for clarifying. wrapped block is new to me, are you referring to this or something Frontier-specific?
There was a problem hiding this comment.
Yeah! This part of the code is to allow the runtime eventually handle processing an existing Ethereum-like blockchain (so that we can support migrating an Ethereum-like network over to Substrate, and add Substrate specific functionalities).
* Account for `pallet_ethereum::on_initialize` weight * Account for `pallet_ethereum::on_finalize` weight * Account for `pallet_ethereum::on_runtime_upgrade` weight
3 participants
No description provided.