Clarify approach to charging gas fees on deposits

[maurelian]

Transferred from ENG-1785

[protolambda]

Been thinking about the deposits discussion more, and instead of tight contract/tx coupling, I think we should take a different route:

As @snario suggested: we can do all the different variants, to be agnostic.

But instead of many different types, I suggest we combine them.

It looks like:

• stipend_gas: paid for gas, free in L2, not refunded
• refundable_gas: paid for gas, refund back refundable_amount * unused_gas / refundable_gas
• refundable_amount: paid for gas, refund back
• fee_remaining: can buy fee_remaining / l2_base_fee_per_gas extra gas, unused gas is refunded
• redirect_addr: send the ETH to this address if tx fails, and any refundable gas

In addition to the regular fields:

• from: sender (authorized by system that inserts the deposit)
• to: receiver
• mint: ETH to mint in from before any EVM execution, redirected to redirect_addr on fail. Can be nil/zero.
• value: ETH to transfer from from to to (may be higher/lower than mint, depending on existing balance)
• data: EVM input
• block_number: make the deposit tx hash unique across all blocks
• tx_index: make the deposit tx hash unique across transactions within the block

Edit: removed amount: mint and value fields are different

This content is RLP encoded: zero integers don't have to cost much space.

Why?

• this enables the contracts on L1, and the derivation code in rollup, to determine the fee strategy without having to change geth again
  • We can craft more variants later on
  • Upgrade without having to hardfork the execution-layer
  • Upgrade with driver logic change AND/OR L1 deposit contract change
• Too many UX options, maybe we want multiple at the same time
• Token deposits must never fail, or tokens get locked in L1 without unlock on L2: paying for gas on L1 is necessary
• Some deposits need to be cheap: pay for gas at base-fee rate of L2 (and stipend can compensate fees already used on L1 deposit call itself)
• This is great for the L1-info deposits to the pre-deploy: these need to be paid by the system: stipend necessary
• To keep more dynamic deposits reasonable (e.g. those that go through routers, or check arbitrage options), will need refunds
• Redirecting ETH/gas is a nice constant-cost backup if things fail: not all contracts are entry-point friendly, the user should be able to get their ETH back if things fail.
• Full compatibility with existing deposit contract (driver can read logs from old and new contract, and translate legacy to this deposit field, with stipends/refunds/base-fee derived as necessary)
• Flexibility maximizes chances of this transaction type becoming a "system transaction" EIP

---

Also note we have two options for gas accounting:

1. Deposits consume gas from block gas-pool: only a limited amount of gas per block, multiple deposit-blocks per L1
2. Deposits consume gas that is processed/refunded/etc., but do not affect gas-pool: unlimited amount of deposits per L2 block (still limited by L1 costs however)

Packing deposits into multiple blocks only introduces more overhead (header data of additional blocks, but also complex packing in driver function, since gas usage is dynamic), so I like option 2 better.

[norswap]

Here's a proposal I wrote that we discussed today.

Feedback was L1 congestion control might be too expensive, and we should consider the simplest possible thing that achieves the same goal, which might be basing the deposit gas price on the L1 basefee (which is similar to what is done currently). Needs further reflection from me, but I think it can work.

---

Deposit Fee Handling Proposal

Context

Deposits are L2 transactions submitted on L1 to the deposit contract, then picked up by the rollup node for inclusion in the L2 chain.

Depositors pay for the L1 gas fee of the L1 transaction submitting the deposit. This document proposes a mechanism for the "L2 fee" (henceforth: the deposit fee) that they should pay on top of that, to pay for the L2 transaction itself.

TL;DR

A depositor only pays fees on L1. This fee is equal to the gas limit set in the deposit, multiplied by the deposit gas price.

The deposit gas price is determined by a deposit-specific congestion-control fee scheme (probably based on EIP-1559) that is maintained by the deposit contract. From this fee, we subtract a stipend that should make many transactions (at least token and NFT deposits) free under normal congestion conditions.

There would be two modes of payment for the deposit fee: either as burned L1 gas (easy to estimate/integrate) or as an ETH transfer (lets the system keep the money). We incentivize the second solution by offering a discount on the fee to its users.

In contrast, users submitting L2 transactions to the sequencer pay a L2 fee, and a L1 fee to pay for L1 calldata. The L2 fee is based on the gas actually consumed (not the gas limit) and a gas price set by EIP-1559 (working just like on L1 but adapted to the faster block schedule). Sequencer fees are not the topic of this document and we won't talk about them further.

Why Deposit Fees Are Needed

A depositor already pays L1 fee for his deposit. Given current L1 gas costs, this is quite pricy. However, we can't waive the deposit fees in all cases. Without a congestion-based deposit fee, depositors are able to bypass congestion control on L2 and essentially DoS L2.

This may sound strange. L1 has its own congestion-control fee mechanism (EIP-1559) and the rollup should support much higher throughput than all of L1. How can deposits cause a DoS on L2?

The key issue is that L1 does not charge for L2 gas, but only for the L1 gas consumed by the L1 transaction that submits the deposit. Despite L1's high gas price, it is possible to submit a small deposit that will cause a massive amount of L2 gas to be consumed. Assuming that we impose a bound on the L2 transaction gas limit, the amplification factor of such a DoS attack is max_L2_gas_limit_in_ETH / deposit_L1_gas_cost_in_ETH.

Normal Usage & Stipend

Despite the DoS concerns, during normal utilization, the L1 gas cost for deposit submission greatly exceeds what the user would pay to submit a similar transaction on L2 directly.

For this reason, we offer users a stipend that should make the most common use cases (token and NFT deposits) free under normal congestion conditions.

This makes deposits free of additional costs in most cases, while still charging normal users in case of congestion, and always charging users that submit transactions with massive gas limits.

Paying for Deposit Fees

We propose to have two co-existent modes of payment for deposit fees:

1. Deposit fees burned as L1 gas.
2. Deposit fees paid as ETH transfer, with a discount serving as an incentive.

The UX of (1) is slightly nicer since the fees for the L1 transaction submitting the deposit can be easily estimated via the usual eth_estimateGas JSON-RPC call. This is easy to integrate for bridges and other projects.

However, burning gas means essentially donating the deposit fee to L1 validators, who don't really need the extra incentive.

Therefore, we add solution (2) where the fee is paid as an ETH transfer instead. The fee can be easily estimated by querying the deposit contract for the current gas price, to be multiplied by the gas limit specified in the deposit. The stipend should also be deducted.

In order to incentivize the use of solution (2), we'd give a small (5%? 10%?) discount on the fee when using solution (2).

We note that in both cases, there is a risk for deposits to revert if they land on a later L1 block where the deposit gas price would be higher, so wallets may want to add a safety margin on top of the estimated deposit fee. In most cases the stipend should cover the costs, so these problems should be rare in practice.

Downsides & Mitigations

The proposed scheme has two mild downsides:

1. "Dynamic calls" that can either consume a little or a lot of gas depending on on-chain conditions will always need to pay for the worst case (since the fee is based on the gas limit, and there is no refund for unused gas).
   • Mitigation: only post the dynamic call inputs via the deposit, then do a sequencer transaction to actually perform the computation. Projects can do this with their own infrastructure or using existing solutions (Gelato Network, Keep3r, ...). This is more work, but ensures these kinds of call are still doable for a reasonable cost.
2. The congestion schemes for deposit and sequencer transactions are not directly connected. This means that if the L2 chain is congested with sequencer transactions, there may exist small periods of arbitrage where it is cheaper to submit a transaction via a deposit rather than via the sequencer.
   • We consider this acceptable. Since deposit transactions have their own congestion control system, such periods are necessarily transitory. Crucially, it is not possible to exploit the "cheap" deposit transactions to perpetuate the sequencer transaction congestion.

Open & Related Questions

Note: these concerns should not weigh on evaluating the current proposal, but are somewhat related.

We need to pick a specific congestion-management fee scheme. The current idea is to go with something derived from EIP-1559.

Another question is whether to impose a gas limit on deposit blocks (i.e. on the total gas consumed by deposit transactions that land in the same L1 block). If we do, we risk reverting the deposit submissions of unsuspecting users, but if we don't, we risk causing huge instantaneous peaks in the deposit gas cost. I'm afraid the latter would be too much of a DoS factor. Picking a high but realistic limit could be a good middle ground.

Appendix: Alternative Designs Considered

In this section I briefly explain why alternative designs were discarded. Feel free to skip this part if you're only interested about how we are planning for things to work.

Why not pay deposit fees on L2?

This actually encompasses two sub-designs:

1. Make the deposit fee equal to the regular L2 fee paid for sequencer
   transactions, and deduct it from the L2 balance.
2. Adopt a different fee scheme for deposit fees, but deduct it from the L2
   balance.

In both cases, the concern is that it becomes possible to submit a deposit on L1 that won't be executable on L2 because of a lack of L2 funds. It's in fact not possible to verify L2 balances on L1 at the time of the deposit.

This is a UX nightmare, and deemed unacceptable by multiple people. Mitigations include the possibility of "replaying" a previous deposit by adding to the L2 fee. However, given the L1 cost of submitting a transaction dominates, this is still a very unhappy & costly path. And the UX isn't improved compared to just resubmitting the transaction.

Why no unified congestion management?

Another approach we considered was to treat deposit & sequencer transactions for the sake of the congestion-control fee scheme.

The fee scheme (e.g. EIP-1559) is ran by the rollup node, because it's not possible to accurately compute the gas usage of L2 transaction on L1 (it would require running the transactions!).

In order to pay deposit fees on L1, the deposit contract must be supplied with a recent-ish measure of congestion on L1 (probably the basefee as set by EIP-1559).

The problem is that if the sequencer is empowered to send this basefee to the deposit contract, he can manipulate it by setting it very high to censor all deposits, or very low to enable DoS via deposits.

A mitigation that was considered was to associate the basefee with state roots posted by the sequencer, however this doesn't solve the issue for two reasons:

• At any given time, there may be multiple state roots for the same batch, e.g. in case of a fault proof. It's then not clear which basefee to use.
• If using a simple first-come-first-served policy to pick the basefee, this still allows a rogue sequencer to censor or DoS the L2 chain for the whole fault proof period of 7 days, which is not acceptable.

[norswap]

I consider the clarification complete. Upon further reflection, I don't see any issue with charging for L2 gas on L1, based on the cost of L1 gas divided by a constant (which it should be said, is how things currently work!). The constant should be updateable.

We should discuss whether we want deposit fees to be part of the deposit rollup milestone, or to be tackled later.

[norswap]

There is however, an additional concern that needs to be raised: do we implement a gas limit for deposit blocks? I'd be in favour of not doing it — the intrinsic L1 costs + L2 gas fee will make sure we can never end with absurdly sized deposit blocks. Even a whole L1 block filled with deposits will only yield at best a deposit block that is at worst 4x bigger than a normal Ethereum block, which we should be able to handle easily. (The lever comes from the stipend, assuming the L2 gas stipend is < 4x L1 gas cost of deposit.)

[ben-chain]

Sorry that I'm just getting to this after sickness & the holidays; I do have some thoughts.

We should discuss whether we want deposit fees to be part of the deposit rollup milestone, or to be tackled later.

I definitely don't think we should let this be a blocker for this milestone. Most importantly, I still think we need a lot more input from our integrations team and and people with experience using the dev-ex, and I don't want that discussion to block deposit rollup work. This one is high-impact for sure--we need to hear from more people on this.

@norswap , I think your proposal is a solid option, and easier to implement, but I would still like to discuss the "paying on L2" option just a bit more. After thinking about it, my guess is that this depends on how optimal we want deposit gas costs, and how we need to parameterize the EIP1559 impacting deposits, wherever it lives.

In both cases, the concern is that it becomes possible to submit a deposit on L1 that won't be executable on L2 because of a lack of L2 funds. [This is not good UX.] Mitigations include the possibility of "replaying" a previous deposit by adding to the L2 fee. However, given the L1 cost of submitting a transaction dominates, this is still a very unhappy & costly path. And the UX isn't improved compared to just resubmitting the transaction.

Both proposals require deposit replays in some cases, so the UX choice is actually not immediately obvious to me. I can think of two UX questions:

1. What is the UX of submitting the replay in either case?
2. What is the chance of having to replay in either case?

Answering 1., it could arguably be better if transaction replaying was implemented on L2--since replays would be cheaper & instant. It may also make the deposits themselves much cheaper, being just an event vs. an L1 storage write for updating the basefee in the deposit contract.

Answering 2., I think it entirely depends on the EIP1559 implementation. For Deposit Rollup, I would imagine the probabilities are equal for a basic implementation. With the introduction of a sequencing window, I think it's more complex. If the L2 BASEFEE moves sufficiently slowly/quickly, I think it could go either way. You can also have "two" basefees for each tx type, but that feels pretty ugly. I think @karlfloersch / @protolambda have discussed a fast EIP1559 for the sequencer, so that could be an issue.

I also think that implementing the replays on L2 is much harder; it's definitely a heavier lift as I see it. You have to validate the failed deposit and check that it a) really happened and b) wasn't already applied. Would be curious for @protolambda 's take on what implementing this look like. Possibilities:

1. The replay tx can specify an index for the failed deposit, and the engine looks it up in the old block.
2. If a deposit can't pay up on L2, we divert a call frame to some system contract/predeploy, or otherwise record the failure in the state, and give a way to replay that.

Overall, still on the fence, and I still wanna hear from others.

[protolambda]

Regarding deposit congestion control:

• There should definitely be a way to guarantee a transaction from L1 without repeating it, even at a higher price. Not having this option affects potential integrations, cc @K-Ho
• Assuming we want to both minimize fees and enable above always-through, refunding the difference (if any) seems nice to have (i.e. fee is locked on L1, part of the total L2 balance, and refunded to sender on L2)
• Failing deposits is natural for some use-cases like cross-chain arbitrage. Stopping execution if arbitrage turns out to be gone, and get refunded as much gas as possible.

---

@ben-chain

Would be curious for @protolambda 's take on what implementing this look like

I don't like the replay-on-fail approach, it introduces per-user state on L2. And we have to either fail all later transactions of the same user, or store every failed tx per user. And a failed deposit of one user shouldn't halt other users from depositing, yet synchronous deposits may be important to guarantee in some cases.

Option 1: Storing the block-height and transaction index of failed deposits sounds reasonable to me. It's like storing all failed txs per user, but is easy to prune history of if size ever becomes a problem. It could look like a single storage write to some predeployed read-only contract. And then you could read if it was a failure (i.e. if it can be replayed) only for deposits that specify themselves as a replay (to avoid overhead on other deposits), and then essentially substitute the data/value/mint fields with the previously failed deposit, and keep the new fee payment.

Maybe there is a better option with a little bit more thought, but I would still prefer an option that at least enables guaranteed processing on L2 for UX reasons. Not introducing too much changes to the L2 state updates would also help keep the diff small.

[ben-chain]

In the interest of soliciting external feedback, I'm going to try to write each tradeoff as succinctly as possible for readers. Here's how I would put it:

Problem Statement

We would like to make deposits as cheap as possible in the happy case. In 1.0, we can get the L1 gas down to <5k, which would open up a DoS if unchecked. We need a way to block/increase the cost of deposits if they start getting spammed. We've identified two main approaches, corresponding to 1 and 2 in the first section here.

A) L1 EIP1559 mechanism: the deposit contract on L1 limits deposit frequency by increasing cost under congestion.
B) L2 EIP1559 mechanism: the L2 VM limits deposit frequency by increasing cost under congestion.

Tradeoffs

Here's what the effects of these options are.

Failure Mode UX

• In option A), there is a chance for your L1 deposit TX reverting up front.
• In option B) there is a chance for your L1 deposit TX succeeding, but the L2 TX being rejected. We can implement the ability to replay the second half from L2.

Both failure modes require that users replay the deposit TX (from L1 in A, from L2 in B), but option B) is worse. This is because the L1 half of the transaction still succeeds, causing devex issues.

Cost

• In option A), we must perform an L1 SSTORE overwrite to track the deposit frequency.
• In option B), we track it in L2, so no L1 SSTORE.

It is possible to implement option B without any SSTOREs at all, so the cost could more than double for small payloads in option A.

Failure Mode Likelihood

• In both cases, users can overpay (and get the ETH refunded on L2) to decrease the likelihood of a failure.
• In both cases, the cost of a spam attack to force failures should be pretty similar. (can someone check me on this? see below, option A may be worse)
• L2 congestion may be more volatile, which would cause failures in B) to be more likely. (In other words, option A requires that deposits get congested to trigger the fail, option B could arise from L2 congestion itself.)

Difference in Ratelimit Trigger

• In option A), the ratelimit would kick in based on the sum of L2 gasLimit values.
• In option B), the ratelimit could kick in based on the sum of L2 gasUsed values.

This is minor, but it does mean that option A) will trigger more easily/at lower throughput. If we refund the extra ETH paid in option A), we will have to deal with an attacker's deposit consuming very little gas on L2, or else the cost of a spam attack would be significantly lower for option A). The mitigation I see is probably to reinforce a minimum gas usage or only refund above a certain amount or % of gas, but it may make the cost of attack proportionally cheaper in A).

[maurelian]

Please move response to the previous comment here: #112.

Locking this thread to make that clear.