ZKsync Fee Mechanism - ZKsync Docs

Introduction to ZKsync's Fee Structure

In Ethereum, computational and storage costs are quantified using gas, with specific gas costs for each operation, which may change during system upgrades. However, ZKsync and other Layer 2 solutions face challenges in adopting this model due to the necessity of publishing pubdata on Ethereum. As a result, the cost of L2 transactions is tied to the fluctuating gas prices on L1 and cannot be hardcoded.

Gas Per Pubdata Limit

In ZKsync, transaction costs are influenced by the volatile gas prices on L1, which are needed to publish pubdata, verify proofs, and more. This is addressed in ZKsync-specific EIP712 transactions which include a gas_per_pubdata_limit field, indicating the maximum gas price the operator can charge users per byte of pubdata. For Ethereum transactions lacking this field, the operator is restrained from exceeding a predefined constant value.

Opcode Pricing Variance

The complexity of zero-knowledge proof operations differs significantly from standard CPU operations. For example, the keccak256 operation, while optimized for CPU performance, incurs higher costs in zero-knowledge systems due to its mathematical demands, leading to distinct pricing structures in ZKsync compared to Ethereum.

Intrinsic Costs in ZKsync

Unlike Ethereum, which uses a base intrinsic transaction cost to cover updates to user balances, nonce, and signature verifications, ZKsync does not include these costs in its intrinsic transaction pricing. This stems from ZKsync's support for account abstraction, allowing different account types to potentially lower transaction costs through optimizations or more zk-friendly signature schemes. The costs in ZKsync primarily cover the intrinsic zero-knowledge proving costs, which are measured through testing and hardcoded due to their complexity.

Understanding Batch Overhead

ZKsync incurs operational costs for proving each batch, referred to as "batch overhead," which includes:

L2 Costs: These are the costs in L2 gas required for proving circuits.
L1 Costs: These cover proof verification and general batch processing on L1.

The protocol aims to maximize transaction inclusion per batch to distribute these costs effectively. Several factors determine when a batch is sealed, such as time constraints for user experience, the transaction slot capacity of the bootloader, memory usage from transaction encoding, and pubdata bytes limitations, which currently stand at 128kb per transaction due to node constraints.

In the case of ZKsync batches, here are the resources the protocol watches to decide when a batch is sealed:

Time. The same as on Ethereum, the batch should generally not take too much time to be closed in order to provide better UX. To represent the time needed we use a batch gas limit, note that it is higher than the gas limit for a single transaction.
Slots for transactions. The bootloader has a limited number of slots for transactions, i.e. it can not take more than a certain transactions per batch.
The memory of the bootloader. The bootloader needs to store the transaction’s ABI encoding in its memory & this fills it up. In practical terms, it serves as a penalty for having transactions with large calldata/signatures in case of custom accounts.
Pubdata bytes. In order to fully appreciate the gains from the storage diffs, i.e. the fact that changes in a single slot happening in the same batch need to be published only once, we need to publish all the batch’s public data only after the transaction has been processed. Right now, we publish all the data with the storage diffs as well as L2→L1 messages, etc in a single transaction at the end of the batch. Most nodes have limit of 128kb per transaction and so this is the limit that each ZKsync batch should adhere to.

Each transaction spends the batch overhead proportionally to how much of these resources it requires.

Note that before the transaction is executed, the system can not know how many of these limited system resources the transaction will actually take. Therefore, we need to charge for the worst case and provide the refund at the end of the transaction.

Base Fee and Gas Limits

To safeguard against DDoS attacks, ZKsync implements a MAX_TRANSACTION_GAS_LIMIT. The baseFee reflects the real costs of computation for the proof, and the gas_per_pubdata_limit must be set sufficiently high to cover the fees for the required L1 gas per byte of pubdata. During periods of high L1 gas demand, adjustments to these limits ensure that transactions remain feasible without exceeding resource allocations.

To make common transactions always executable, we must enforce that the users are always able to send at least GUARANTEED_PUBDATA_PER_TX bytes of pubdata in their transaction. Because of that, the needed gas_per_pubdata_limit for transactions should never grow beyond MAX_TRANSACTION_GAS_LIMIT/GUARANTEED_PUBDATA_PER_TX.

Setting a hard bound on gas_per_pubdata_limit also means that with the growth of L1 gas prices, the L2 baseFee will have to grow as well. This ensures that base_fee * gas_per_pubdata_limit = L1_gas_price * l1_gas_per_pubdata.

This mainly impacts computationally intensive tasks. For these kinds of transactions, we need to conservatively charge a big upfront payment. It is compensated with a refund at the end of the transaction for any overspent gas.

Trusted Gas Limit

For operations requiring extensive pubdata, such as deploying a new contract, the MAX_TRANSACTION_GAS_LIMIT may be exceeded. This is accommodated by including the bytecode in a separate part of the pubdata, termed "factory dependencies," allowing the operator to gauge the required gas expenditure accurately.

to provide a better user experience for users, the operator may provide the trusted gas limit, i.e. the limit which exceeds MAX_TRANSACTION_GAS_LIMIT assuming that the operator is sure that the excess gas will be spent on the pubdata.

Refunds

Another distinctive feature of the fee model used on ZKsync is the availability of refunds. Refunds can be issued for unused limited system resources and overpaid computation. This is needed because of the relatively big upfront payments required in ZKsync to provide DDoS security.

Formulas and constants for calculating fees

After determining price for each opcode in gas according to the model above, the following formulas are used for calculating baseFee and gasPerPubdata for a batch.

System-wide constants

These constants are to be hardcoded and can only be changed via either system contracts/bootloader or VM upgrade.

BATCH_OVERHEAD_L1_GAS (L_1_O)— The L1 gas overhead for a batch (proof verification, etc).

L1_GAS_PER_PUBDATA_BYTE (L_1_PUB) — The number of L1 gas needed for a single pubdata byte. It is slightly higher than 16 gas needed for publishing a non-zero byte of pubdata on-chain (currently the value of 17 is used).

BATCH_OVERHEAD_L2_GAS (EO)— The constant overhead denominated in gas. This overhead is created to cover the amortized costs of proving.

BLOCK_GAS_LIMIT (B) — The maximum number of computation gas per batch. This is the maximal number of gas that can be spent within a batch. This constant is rather arbitrary and is needed to prevent transactions from taking too much time from the state keeper. It can not be larger than the hard limit of 2^32 of gas for VM.

MAX_TRANSACTION_GAS_LIMIT (TM) — The maximal transaction gas limit. For i-th single instance circuit, the price of each of its units is $S C_{i} = ⌈ \frac{T _{M}}{C C _{i}} ⌉$ to ensure that no transaction can run out of these single instance circuits.

MAX_TRANSACTIONS_IN_BATCH (TXM) — The maximum number of transactions per batch. A constant in bootloader. Can contain almost any arbitrary value depending on the capacity of batch that we want to have.

BOOTLOADER_MEMORY_FOR_TXS (BM) — The size of the bootloader memory that is used for transaction encoding (i.e. excluding the constant space, preallocated for other purposes).

GUARANTEED_PUBDATA_PER_TX (PG) — The guaranteed number of pubdata that should be possible to pay for in one ZKsync batch. This is a number that should be enough for most reasonable cases.

Derived constants

Some of the constants are derived from the system constants above:

MAX_GAS_PER_PUBDATA (EPMax) — the gas_price_per_pubdata that should always be enough to cover for publishing a pubdata byte:

E P_{M a x} = ⌊ \frac{T _{M}}{P _{G}} ⌋

Externally-Provided Batch Parameters

L1_GAS_PRICE (L_1_P) — The price for L1 gas in ETH.

FAIR_GAS_PRICE (Ef) — The “fair” gas price in ETH, that is, the price of proving one circuit (in Ether) divided by the number we chose as one circuit price in gas.

E_{f} = \frac{P r i c e _{C}}{E _{C}}

where PriceC is the price for proving a circuit in ETH. Even though this price will generally be volatile (due to the volatility of ETH price), the operator is discouraged to change it often, because it would volatile both volatile gas price and (most importantly) the required gas_price_per_pubdata for transactions.

Both of the values above are currently provided by the operator. Later on, some decentralized/deterministic way to provide these prices will be utilized.

Determining `base_fee`

When the batch opens, we can calculate the FAIR_GAS_PER_PUBDATA_BYTE (EPf) — “fair” gas per pubdata byte:

E P_{f} = ⌈ \frac{L 1 _{p} * L 1 _{P U B}}{E _{f}} ⌉

There are now two situations that can be observed:

E P_{f} > E P_{M a x}

This means that the L1 gas price is so high that if we treated all the prices fairly, then the number of gas required to publish guaranteed pubdata is too high, i.e. allowing at least PG pubdata bytes per transaction would mean that we would to support tx.gasLimit greater that the maximum gas per transaction TM, allowing to run out of other finite resources.

If $E P_{f} > E P_{M a x}$ , then the user needs to artificially increase the provided Ef to bring the needed tx.gasPerPubdataByte to EPmax

In this case we set the EIP1559 baseFee (Base):

B a se = ma x (E_{f}, ⌈ \frac{L 1 _{P} * L 1 _{P U B}}{E P _{ma x}} ⌉)

Only transactions that have at least this high gasPrice will be allowed into the batch.

II.

Otherwise, we keep $B a se * = E_{f}$

Note, that both cases are covered with the formula in case (1), i.e.:

B a se = ma x (E_{f}, ⌈ \frac{L 1 _{P} * L 1 _{P U B}}{E P _{ma x}} ⌉)

This is the base fee that will be always returned from the API via eth_gasGasPrice.

Overhead for a Transaction

Let’s define by tx.actualGasLimit as the actual gasLimit that is to be used for processing of the transaction (including the intrinsic costs). In this case, we will use the following formulas for calculating the upfront payment for the overhead:

S_{O} = 1/ T X_{M}

M_{O} (t x) = e n c L e n (t x) / B_{M}

E_{A O} (t x) = t x . a c t u a lG a s L imi t / T_{M}

O (t x) = ma x (S_{O}, M_{O} (t x), E_{O} (t x))

where:

SO — is the overhead for taking up 1 slot for a transaction

MO(tx) — is the overhead for taking up the memory of the bootloader

encLen(tx) — the length of the ABI encoding of the transaction’s struct.

EAO(tx) — is the overhead for potentially taking up the gas for single instance circuits.

O(tx) — is the total share of the overhead that the transaction should pay for.

Then we can calculate the overhead that the transaction should pay as the following one:

L 1_{O} (t x) = ⌈ \frac{L 1 _{O}}{L 1 _{P U B}} ⌉ * O (t x)

E_{O} (t x) = E_{O} * O (t x)

Where

L_1_O(tx) — the number of L1 gas overhead (in pubdata equivalent) the transaction should compensate for gas.

EO(tx) — the number of L2 gas overhead the transaction should compensate for.

Then:

overhead_gas(tx) = EO(tx) + tx.gasPerPubdata ⋅ L_1_O(tx)

When a transaction is being estimated, the server returns the following gasLimit:

tx.gasLimit = tx.actualGasLimit + overhead_gas(tx)

Note, that when the operator receives the transaction, it knows only tx.gasLimit. The operator could derive the overhead___gas(tx) and provide the bootloader with it. The bootloader will then derive tx.actualGasLimit = tx.gasLimit − overhead__gas*(_tx*) and use the formulas above to derive the overhead that the user should’ve paid under the derived tx.actualGasLimit to ensure that the operator does not overcharge the user.

overhead(tx)

For the ease of integer calculation, we will use the following formulas to derive the overhead(tx):

$B_{O} (t x) = E_{O} + t x . g a s P er P u b d a t a B y t e \cdot ⌊ \frac{L 1 _{O}}{L 1 _{P U B}} ⌋$

$B_{O}$ denotes the overhead for batch in gas that the transaction would have to pay if it consumed the resources for entire batch.

Then, overhead_gas(tx) is the maximum of the following expressions:

$S_{O} = ⌈ \frac{B _{O}}{T X _{M}} ⌉$
$M_{O} (t x) = ⌈ \frac{B _{O} \cdot e n co d in gL e n ( t x )}{B _{M}} ⌉$
$E_{O} (t x) = ⌈ \frac{B _{O} \cdot t x . g a s B o d y L imi t}{T _{M}} ⌉$

Deriving `overhead_gas(tx)` from `tx.gasLimit`

The task that the operator needs to do is the following:

Given the tx.gasLimit, it should find the maximal overhead_gas(tx), such that the bootloader will accept such transaction, that is, if we denote by Oop the overhead proposed by the operator, the following equation should hold:

O_{o p} \leq o v er h e a d_{g} a s (t x)

for the $t x . b o d y G a s L imi t$ we use the $t x . b o d y G a s L imi t$ = $t x . g a s L imi t - O_{o p}$ .

There are a few approaches that could be taken here:

Binary search. However, we need to be able to use this formula for the L1 transactions too, which would mean that binary search is too costly.
The analytical way. This is the way that we will use and it will allow us to find such an overhead in O(1), which is acceptable for L1->L2 transactions.

Let’s rewrite the formula above the following way:

O_{o p} \leq ma x (SO, MO (t x), EO (t x))

So we need to find the maximal $O_{o p}$ , such that $O_{o p} \leq ma x (S_{O}, M_{O} (t x), E_{O} (t x))$ . Note, that it means ensuring that at least one of the following is true:

$O_{o p} \leq S_{O}$
$O_{o p} \leq M_{O} (t x)$
$O_{o p} \leq E_{O} (t x)$

So let’s find the largest Oop for each of these and select the maximum one.

Solving for (1)

O_{o p} = ⌈ \frac{B _{O}}{T X _{M}} ⌉

Solving for (2)

O_{o p} = ⌈ \frac{e n c L e n ( t x ) \cdot B _{O}}{B _{M}} ⌉

Solving for (3)

This one is somewhat harder than the previous ones. We need to find the largest O_{op}, such that:

O_{o p} \leq ⌈ \frac{t x . a c t u a lE r g s L imi t \cdot B _{O}}{T _{M}} ⌉

O_{o p} \leq ⌈ \frac{( t x . er g s L imi t - O _{o p} ) \cdot B _{O}}{T _{M}} ⌉

O_{o p} \leq ⌈ \frac{B _{O} \cdot ( t x . er g s L imi t - O _{o p} )}{T _{M}} ⌉

Note, that all numbers here are integers, so we can use the following substitution:

O_{o p} - 1 < \frac{( t x . er g s L imi t - O _{o p} ) \cdot B _{O}}{T _{M}}

(O_{o p} - 1) T_{M} < (t x . er g s L imi t - O_{o p}) \cdot B_{O}

O_{o p} T_{M} + O_{o p} B_{O} < t x . er g s L imi t \cdot B_{O} + T_{M}

O_{o p} < \frac{t x . er g s L imi t \cdot B _{O} + T _{M}}{B _{O} + T _{M}}

Meaning, in other words:

O_{o p} = ⌊ \frac{t x . er g s L imi t \cdot B _{O} + T _{M} - 1}{B _{O} + T _{M}} ⌋

Then, the operator can safely choose the largest one.

Discounts by the operator

It is important to note that the formulas provided above are to withstand the worst-case scenario and these are the formulas used for L1->L2 transactions (since these are forced to be processed by the operator). However, in reality, the operator typically would want to reduce the overhead for users whenever it is possible. For instance, in the server, we underestimate the maximal potential MAX_GAS_PER_TRANSACTION, since usually the batches are closed because of either the pubdata limit or the transactions’ slots limit. For this reason, the operator also provides the operator’s proposed overhead. The only thing that the bootloader checks is that this overhead is not larger than the maximal required one. But the operator is allowed to provide a lower overhead.

Refunds

As you could see above, this fee model introduces quite some places where users may overpay for transactions:

For the pubdata when L1 gas price is too low
For the computation when L1 gas price is too high
The overhead, since the transaction may not use the entire batch resources they could.

To compensate users for this, we will provide refunds for users. For all of the refunds to be provable, the counter counts the number of gas that was spent on pubdata (or the number of pubdata bytes published). We will denote this number by pubdataused. For now, this value can be provided by the operator.

The fair price for a transaction is

F ai r F ee = E_{f} \cdot t x . co m p u t a t i o na lG a s + E P_{f} \cdot p u b d a t a u se d

We can derive $t x . co m p u t a t i o na lG a s = g a ss p e n t - p u b d a t a u se d \cdot t x . g a s P r i ce P er P u b d a t a$ , where gasspent is the number of gas spent for the transaction (can be trivially fetched in Solidity).

Also, the FairFee will include the actual overhead for batch that the users should pay for.

The fee that the user has actually spent is:

A c t u a lF ee = g a ss p e n t \cdot g a s P r i ce

So we can derive the overpay as

A c t u a lF ee - F ai r F ee

In order to keep the invariant of $g a s U se d \cdot g a s P r i ce = f ee$ , we will formally refund $\frac{A c t u a lF ee - F ai r F ee}{B a se}$ gas.

At the moment, this counter is not accessible within the VM and so the operator is free to provide any refund it wishes (as long as it is greater than or equal to the actual amount of gasLeft after the transaction execution).

Refunds for repeated writes

zkEVM is a state diff-based rollup, i.e. the pubdata is published not for transactions, but for storage changes. This means that whenever a user writes into a storage slot, the user incurs certain amount of pubdata. However, not all writes are equal:

If a slot has been already written to in one of the previous batches, the slot has received a short id, which allows it to require less pubdata in the state diff.
Depending on the value written into a slot, various compression optimizations could be used and so we should reflect that too.
Maybe the slot has been already written to in this batch and so we don’t to charge anything for it.

You can read more about how we treat the pubdata on Handling pubdata.

The important part here is that while such refunds are inlined (i.e. unlike the refunds for overhead they happen in-place during execution and not after the whole transaction has been processed), they are enforced by the operator. Right now, the operator is the one that decides what refund to provide.

Improvements in the upcoming releases

The fee model explained above, while fully functional, has some known issues. These will be tackled with the following upgrades.

The quadratic overhead for pubdata

Note, that the computational overhead is proportional to the tx.gasLimit and the amount of funds the user will have to pay is proportional to the L1 gas price (recall the formula of B_O). We can roughly express the transaction overhead from computation as tx.gasLimit * L1_GAS_PRICE * C where C is just some constant. Note, that since a transaction typically contains some storage writes, and its tx.gasLimit = gasSpentOnCompute + pubdataPublished * gasPricePerPubdata, tx.gasLimit is roughly proportional to gasPricePerPubdata and so it is also proportional to L1_GAS_PRICE.

This means that formula tx.gasLimit * L1_GAS_PRICE * C becomes quadratic to the L1_GAS_PRICE.

`gasUsed` depends to `gasLimit`

While in general it shouldn’t be the case assuming the correct implementation of refunds, in practice it turned out that the formulas above, while robust, estimate for the worst case which can be very difference from the average one. In order to improve the UX and reduce the overhead, the operator charges less for the execution overhead. However, as a compensation for the risk, it does not fully refund for it.

L1->L2 transactions do not pay for their execution on L1

The executeBatches operation on L1 is executed in O(N) where N is the number of priority ops that we have in the batch. Each executed priority operation will be popped and so it incurs cost for storage modifications. As of now, we do not charge for it.

zkEVM Fee Components (Revenue & Costs)

On-Chain L1 Costs
- L1 Commit Batches
  - The commit batches transaction submits pubdata (which is the list of updated storage slots) to L1. The cost of a commit transaction is calculated as constant overhead + price of pubdata. The constant overhead cost is evenly distributed among L2 transactions in the L1 commit transaction, but only at higher transaction loads. As for the price of pubdata, it is known how much pubdata each L2 transaction consumed, therefore, they are charged directly for that. Multiple L1 batches can be included in a single commit transaction.
- L1 Prove Batches
  - Once the off-chain proof is generated, it is submitted to L1 to make the rollup batch final. Currently, each proof contains only one L1 batch.
- L1 Execute Batches
  - The execute batches transaction processes L2 -> L1 messages and marks executed priority operations as such. Multiple L1 batches can be included in a single execute transaction.
- L1 Finalize Withdrawals
  - While not strictly part of the L1 fees, the cost to finalize L2 → L1 withdrawals are covered by Matter Labs. The finalize withdrawals transaction processes user token withdrawals from zkEVM to Ethereum. Multiple L2 withdrawal transactions are included in each finalize withdrawal transaction.
On-Chain L2 Revenue
- L2 Transaction Fee
  - This fee is what the user pays to complete a transaction on zkEVM. It is calculated as gasLimit x baseFeePerGas - refundedGas x baseFeePerGas, or more simply, gasUsed x baseFeePerGas.
Profit = L2 Revenue - L1 Costs - Off Chain Infrastructure Costs

Blocks and Batches

Explore how ZKsync Era processes transactions by grouping them into blocks and batches, the role of sealing blocks, and the importance of rollbacks in the virtual machine.

Finality

Explore the concept of finality in blockchain systems and learn about the steps involved in achieving transaction settlement.