Tezt/EVM: initialise base_fee to zero by default

The Fee Stack

• Depends on !11509 (merged)
• Required for !11537 (merged)

Context

This MR initialises the work to implement a fee model for etherlink. For a more detailed breakdown, see the spec.

Fees

There are now several fees to worry about, that the user will have to pay: base fee, data availability fee, gas fee.

Base Fee

The base fee is a flat fee charged to every transaction - the aim of which is to discourage spam. This fee will be burned.

Data Availability Fee

This fee (da_fee(tx)) compensates the injector of the operation on Layer1 (if not injected through the delayed inbox) the fee that would have been paid to inject that data. It is proportional to the encoded size of the tx.

NB initially, data is injected through L1. It is anticipated that this fee will drop when injecting through DAL.

Gas Fee

The fee we all know and love, and where gas price matters (which will adjust up/down depending on usage). This is again paid to the sequencer.

Paying for Fees

We need a mechanism for the users to pay for the additional fees - but without breaking the DX w.r.t. the interface wallets expect. How do we do this?

We will do the same as what Arbitrum does - that is, we rely on the fact that wallets use the eth_estimateGas RPC.

Aka this RPC will return the gas limit required, to cover both execution gas and base_fee + da_fee(tx), at the given gas_price. If no gas_price is given, we assume the current value of block_base_fee_per_gas for the calculation.

We convert the base fee + da fee into an additional amount of gas, such that gas_price * additional_gas >= base_fee + da_fee(tx). This is added onto the estimated gas for execution, such that the returned eth_estimateGas => GAS_LIMIT >= additional_gas_for_fee + gas_for_execution.

Receipts

Note that receipts will now contain higher values for gas used, and the total gas used in a block may be higher than our max gas per block.

Wip/Questions

There remains a question of how we do the calculation to adjust gas price in the face of variable block times w.r.t. a sequencer - but any change here is likely to be small and relatively contained to just the adjustment calculation.

Manually testing the MR

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR