The current frontier transaction proof_size calculation relies on the EVM hook and is calculated manually. For example, see https://github.com/polkadot-evm/frontier/blob/master/frame/evm/src/runner/stack.rs#L952-L1168. This is due to the lack of a workable solution to query the consumed proof_size of the executed Ethereum transaction. This approach makes the codebase harder to maintain and prone to errors.
Utilized the Polkadot storage_proof_size host function. By integrating it into the current Ethereum and EVM pallets, the transaction proof size can be restricted easily and accurately.
Additional Information
The only drawback that comes to mind is that the newly added host function requires a forced upgrade for the network nodes. This may pose a challenge for networks with thousands of decentralized nodes. (But I believe it's doable; we managed it when switching to async backing mode.)
Motivation
The current frontier transaction proof_size calculation relies on the EVM hook and is calculated manually. For example, see https://github.com/polkadot-evm/frontier/blob/master/frame/evm/src/runner/stack.rs#L952-L1168. This is due to the lack of a workable solution to query the consumed proof_size of the executed Ethereum transaction. This approach makes the codebase harder to maintain and prone to errors.
Suggested Solution
Utilized the Polkadot
storage_proof_sizehost function. By integrating it into the current Ethereum and EVM pallets, the transaction proof size can be restricted easily and accurately.Additional Information
The only drawback that comes to mind is that the newly added host function requires a forced upgrade for the network nodes. This may pose a challenge for networks with thousands of decentralized nodes. (But I believe it's doable; we managed it when switching to async backing mode.)