[General] Why does L1L2 tx require >2x gas limit overhead to succeed on L2?

[sanekmelnikov]

Team or Project

Caldera

ZK chain

GenLayer

Environment

Testnet

L2 block number

20520 - 20524

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

Here are three L1L2 transactions:

• Tx with gas limit 700k: fails, shows gas usage: 700k
• Tx with gas limit 800k: succeeds, actual gas usage: 342k
• Tx with gas limit 750k: succeeds, actual gas usage: 342k

All three txs have the same calldata and are expected to use 342k gas, but unless gas limit is specified with high enough (~2.1x) buffer, tx will fail on L2.

Questions:

• Why is so much overhead required and where does this assertion logic live?
• Are there any config parameters that can affect that, so we can tweak it, say, to make 2x -> 1.5x?

@albertlai431

Repo Link (Optional)

No response

Additional Details

• RPC URL: https://genlayer-testnet.rpc.caldera.xyz/http
• Chain pubdata mode: Validium

[itegulov]

@albertlai431

Sorry for the late reply, investigating this required a fairly deep dive into ZKsync protocol.

Why is so much overhead required and where does this assertion logic live?

Several things that need to be mentioned here:

• Protocol specifies what gas per pubdata byte should be used by every L1->L2 transaction (src).
• This constant can be significantly higher than fair gas per pubdata depending on chain's pubdata type and market conditions. In case of GenLayer testnet, which is a validium, REQUIRED_L2_GAS_PRICE_PER_PUBDATA=800 is 160x higher than current fair pubdata price of 5.
• During execution bootloader checks whether enough gas was provided to publish generated pubdata assuming required gas per pubdata (src). This check uses provided pubdata (which is always 800 as per above). If transaction does not have enough, then all remaining gas gets automatically consumed and tx fails. This is what happened to your first 700k gas transaction.
• After transaction finishes execution (including pubdata check above), bootloader refunds gas based on fair gas per pubdata. So you can get a big refund if the discrepancy between fair and required price is massive.

Now, let's focus on your 700k gas transaction and use it as an example. From my experiments it generates 468 bytes of pubdata (not sure if there is an easy way to obtain this information but I can elaborate on how I figured that out if you want). Empirically (fancy word for saying I tried a bunch of numbers), I found out that to make it pass you need to provide 20k extra gas making the total 720k.

Bootloader then refunds roughly (required_gas_per_pubdata - fair_gas_per_pubdata) * pubdata_bytes = (800 - 5) * 468 which is 378k gas. As per you report, your other transactions consumed 342k gas which makes sense as 720k == 342k + 378k.

Hope this helps and I am happpy to get into details on why 800 (a seemingly magic number) was chosen but don't want to bloat this answer further than it already is.

Are there any config parameters that can affect that, so we can tweak it, say, to make 2x -> 1.5x?

The constant is hardcoded in protocol and is not currently configurable. This is especially unfortunate for validiums which have low fair gas per pubdata by design but are stuck with 800 that was chosen with rollups in mind. I relayed this to protocol developers as an area for potential improvement but don't have any specific outcome yet. I will post an update if something changes though.

Also, it is unclear from your message if you are aware of this or not but I'll mention just in case: L1->L2 transactions should be estimated through zks_estimateGasL1ToL2 (as opposed to zks_estimateFee or eth_estimateGas). That endpoint takes the flow I described above into account.