MIP-16: Calculation of gas fees

Description: How to calculate gas fees for transactions on Movement L2.
Authors: Franck Cassez

Abstract

This MIP describes the structure of the gas fees and overall resource consumption needed to execute, and post a transaction to the DA/L1.

The transaction fees on L2s are multi-dimensional [9, 10]. They comprise of execution fees, settlement fees and data availability fees. This MIP describes what the different types of fees are, and how the transaction fees can be computed.

Scope of this MIP

This MIP applies to costs/fees related to executing Move bytecode.

[!WARNING] It does not cover the extended future framework where EVM bytecode can be executed on a Movement chain.

Althought the costs (in terms of resources consumption) are expressed in gas units when executing Move and EVM bytecode, the gas units are not comparable, e.g. the minimum gas for an EVM transaction is 21000 gas units, whereas for Move-Aptos it is 700 gas units. As a result designing a fee mechanism for Movement chains that support Move and EVM bytecodes will require some careful adjustments and analysis of the different fee structures (Move and EVM).

[!WARNING] This MIP does not cover staking (and slashing and rewards) for validators.

Fee structure

The processing costs on rollups [1 - 6] are multi-dimensional. The cost of processing a transaction on a Movement chain consists of:

execution fees: the costs that correspond to resources usage, CPU and permanent storage.
data availability fees: the costs of publishing transactions/blocks data to a data availability layer.
settlement fees: the costs of validating a transaction (e.g. zk-proof generation and verification, validators attestations.)

Overall the transaction fees are defined by the sum of three types of fees:

$E x ec F ees + D A F ees + S e tlF ees .$

The fees should be expressed in a single (crypto)-currency, e.g. USD, or a token $APT, $MOVE, $ETH.

Execution

MoveVM execution fees

To execute a transaction and store the result, the operator of the chain uses some hardware: CPU and disk storage. The execution fees represent the compensation of the operator for executing a transaction.

Movement Network uses Aptos-Move as the execution layer and the execution fees for Aptos-Move are defined in the Aptos documentation Gas and storage fees. The Aptos-Move fee mechanism splits the execution fees in two parts:

CPU and IO operations, expressed in gas units;
permanent storage, expressed in $APT.

CPU and IO operations for a transaction $t x$ result in a number of gas units $Cp u I o G a s (t x)$ , and the corresponding fees are computing using a gas price $G a s P r i ce$ expressed in the gas token ($APT for Aptos-Move). A transaction specifies the value $G a s P r i ce (t x)$ it is willing to pay.
The value $G a s P r i ce (t x)$ must not be lower than a minimum $G a s P r i ce$ , which may fluctuate depending on network contention, and may be updated frequently (e.g. after each block).

In contrast, the permanent storage fees are designed to be stable and are updated infrequently. The reasoning is that they depend on how much storage costs (hardware, disks) and with advancement in technology this should go down in the future. The storage fees for $t x$ are denoted $St ore F ees (t x)$ and expressed in $APT¹.

The fees that correspond to the permanent storage are converted to gas units using the $G a s P r i ce$ and the $APT price.

The total charge in gas units for a transaction is the defined by:

$T o t a lG a s U ni t s (t x) = Cp u I o G a s (t x) + St ore F ees (t x) / G a s P r i ce (t x)$

and the total transaction fees are approximately²:

$E x ec F ees (t x) = T o t a lG a s U ni t s (t x) \times G a s P r i ce (t x) .$

[!WARNING] We may not use the $APT token value to compute the fees on Movement. If we do so the $E x ec F ees$ will be identical to processing fees on Aptos-Move, and the total fees including $D A F ees$ and $S e tlF ees$ will be higher than the processing fees on Aptos-Move, which may not be desirable.

[!TIP] Proposal 1: use the $T o t a lG a s U ni t s (t x)$ and a $G a s P r i ce$ in $MOVE to compute the execution fees on a Movement chain. This may require an oracle to get the exchange rate for $APT/$MOVE.

Gas price adjustments

We may also want to adjust the $G a s P r i ce$ (in $MOVE) to reflect our network load. There are many ways the $G a s P r i ce$ can be updated. On Ethereum it is governed by rules in EIP-1559. zkSync, Arbitrum and OP Mainnet use different strategies [1, 4, 6] to update the gas price.

[!TIP] Proposal 2: The OP Mainet [1] strategy seems to be the simplest one so we may implement this strategy first.

Data Availability fees

On a rollup (L2), transactions are grouped in batches. Processing a batch result in a new state. Both the transactions data and the new state are published to the data availability (DA) layer. The reason is that they should be available for third-parties to retrieve and verify the correctness of the state transitions (and blocks).

We assume that the agreement with the DA provider is such that we pay a fixed amount, $D A P er B y t e P r i ce$ , in USD, per bytes we publish to the DA layer. This can be updated infrequently e.g. every 6 months or year.

[!NOTE] To reduce the costs, the data published to the DA layer can be compressed. This reduces the overall costs of publishing a batch (and a state) to the DA layer but makes it harder to identify the contribution of each transaction to the overall costs. OP Mainnet Ecotone has a formula to try and weight the contribution of each transaction to the compressed data. It is unclear how well it works in practice.

[!TIP] Proposal 3: If the cost of publishing a batch $b$ to the DA is $D A F ees (b)$ , and $n$ transactions are in the batch, the DA fees for each transaction are $D A F ees (b) / n$ . This is simple to implement and can be refined later if needed.

Settlement Fees

The settlement fees depend on a number of factors, and on the settlement mechanism used by a given Move Stack chain. There is a common feature though: some data are posted to Ethereum mainnet, and the price of a transaction on Mainnet may fluctuate.

The difficulty is that we charge our users when we process a transaction on a Move Stack chain. At that time we don’t know the price of an Ethereum transaction to post our data because it will happen in the future when the transaction is included in a block. As a result we may have to use an oracle to provide an estimate of the (gas) price on Ethereum when our transaction is processed.

Another thing that is common to all the settlement mechanisms is that we have to publish a commitment to the states/blocks we produce. This is usually done by publishing state roots (hashes of states). There are two interfaces to publish data on Ethereum:

transaction data, and
blobs.

Blobs were introduced to lower the cost of L2s and offer temporary (18 days) data storage at low cost. Blobs are limited in size to 128KB, and a maximum of 6 blobs per (Ethereum) block.

Fraud-proof settlement

For a fraud-proof settlement mechanism, we have to publish the state roots of the blocks we produce, or the change sets (they may be smaller).
The size of the state roots of change sets roots is known when we create a (l2) block, so we can determine the expected cost of publishing to Ethereum mainnet using an oracle for the Ethereum gas price.

Validity proof settlement

In a validity proof settlement we have two sources of costs:

the proving part, which is a task dedicated to provers (or a market thereof),
the verification part which is a transaction in Ethereum Mainnet.

The second part is usually predicatable as the sizes of proofs are known for each zk-proof system, and the verification step is efficient. The proving part is more complex to evaluate. The zkSync –– Fee mechanism [4] may be a useful reference to design an equivalent mechanism for Movement chains.

[!WARNING] Note that we first need a zkMoveVM to develop this approach.

Fast-finality settlement

In our network, we will offer fast-finality settlement (FFS) where validators verify state transitions (and blocks) and interact with a contract, StakingK, that may live³ on Ethereum mainnet.

The costs incurred by the validators plus the cost of posting the attestations to Ethereum mainnet have to be factored in into the $S e tlF ees$ .

[!WARNING] We have not finalised the FFS details yet so it may be premature to try and define fees for this mechanism. It also pertains to staking which is not fully fledged yet.