Torsten Stüber, 2025-09-10
Revised on 2025-09-17: the revised document precisely distinguishes between the weight limit $(w_r, w_p)$ (which is the weight consumed for the smart contract execution) and the actual dispatch weight $w^\mathrm{total}$ of eth_call or eth_instantiate_with_code – the difference is the overhead weight $w^\mathrm{extra}$ which comprises 1) extra weight defined in the weight function of the dispatchable functions eth_call or eth_instantiate_with_code and 2) the weight of the transaction extensions.
This document is continued in Revive Resource Management.
This document describes challenges due to information loss when mapping three dimensional metrics in pallet-revive (two dimensional weight + storage deposit) to the one dimensional concept of Ethereum gas.
It is a purely abstract description but aims to be complete and precise.
I first define and explain all notions and then describe the challenges and discuss potential solutions in the final section.
The following components are involved in the gas mapping process:
We consider one specific Ethereum transaction executed on pallet-revive. The Ethereum wallet will first dry-run this transaction in order to determine a gas estimate and then submit the transaction to the chain where it will be executed again, but this time on-chain.
We assume that both executions of this transaction have the same execution path and therefore the same sequence of EVM/PVM instructions that are executed.
This execution path uniquely determines a weight and storage deposit, which we denote as follows:
ref_time part of the weightproof_size part of the weight