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 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.

Components

The following components are involved in the gas mapping process:

• pallet-revive
• pallet-transaction-payment (we ignore the other transaction payment pallets for non-native assets)
• block author/verifier
• Ethereum wallet

Transactions

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:

• $w_r$: the ref_time part of the weight
• $w_p$: the proof_size part of the weight
• $d$: the storage deposit (which is a native asset balance)

Since smart contracts are Turing complete, these values can only be discovered by executing the transaction (either during dry-running or when executing a block).