How should we pay gas for deposits?

[karlfloersch]

One of the decisions that we haven't come to a conclusion on (or really documented) is whether we change how we pay gas for deposits. These are the two design choices:

Option 1 [status quo]: Pay gas on L1

Currently we have a fixed amount of L1 gas which is burned in exchange for L2 gas. The value is set here. This approach works, but it is conceptually a bit wonky. It creates two gas markets for L2 gas - one gas market on L2 (normal EIP1559 for L2), and one gas market on L1 (using this fixed exchange rate). This means that theoretically if L2 gas becomes extremely expensive, it can be cheaper to execute L2 transactions using deposits than sending transactions directly on L2.

While it may feel a bit funky, it has the benefit of being relatively simple. Sometimes simplicity is worth optimizing for vs theoretical cleanness. Also, probably most compellingly is this is currently what we have implemented and we have a lot of other features that might be higher leverage to build.

Option 2: Pay gas on L2

Another proposal is break deposits into two types:

1. ETH deposits - these are free.
2. Normal deposits - these must pay gas on L2 according to the current BASE_FEE

The process for depositing tokens other than ETH would be: 1) deposit ETH, and then 2) send a normal deposit transaction which uses the newly deposited ETH to pay the current BASE_FEE on L2.

The benefit of this approach is that it means that only ETH is subject to special gas rules, and all other transactions to pay the BASE_FEE and contribute to congestion on L2 (which makes sense conceptually). Of course the downside is implementation complexity which may or may not be justified based on user needs. It also could be the case that this approach introduces more room for manipulation by the sequencer! This is because the sequencer can manipulate the BASE_FEE and use that to intentionally invalidate specific deposits.

Call to action

• What proposal do you like best?
• Is there an alternative I did not lay out?

Process note: the way we handle deposits (and all other spec related decisions) should be product driven. That means that to come to a conclusion here we need to ensure pain points & user stories for each approach are throughly explored.

[karlfloersch]

My current favorite proposal is sticking with (1), the status quo

The reason why I think we should just continue with the status quo is:

1. I do not see a user pain point that we would be addressing by changing this proposal. Note this does not mean pain points do not exist.
2. I would guess that it's less implementation complexity.
3. Proposal (2) needs to be considered from the perspective of what can occur if the sequencer is manipulating the BASE_FEE - I haven't seriously considered this attack vector yet.

Until we have identified product reasons to change our gas payment mechanism (eg. user pain points) I'd suggest we stick with the status quo.

[ben-chain]

I do not see a user pain point that we would be addressing by changing this proposal

We've definitely seen people annoyed by the gas burn in various capacities, including the fact that it means L1 gasprice volatility impacts deposit gasprice volatility, even if the two aren't correlated. I think @K-Ho should really be the one here to weigh in, ideally after collecting interview data from integrators.

One complexity that I can see in number 2 is that it means there can be "invalid transactions" in a deposit block now if they don't have enough funds. However, since it is a new TX type, that may fine, and we just say that the deposit TX is auto-reverted and returns status: 0 if this happens. In this sense the block is still valid, but correct execution of the transaction is a no-op.

[norswap]

Three unrelated points:

• Would it be possible to read (on L1) a recent-ish (e.g. last L1-confirmed sequencer block) L2 gas price, and use that to set the fee?
• Instead of burning gas, we could require ETH attached to the tx. This avoids the volatility pitfall brought up by Ben.
• If we go with prop (1), we can make the conversation rate updatable in case things get weird. The problem is that is not very transparent and is potentially a way to censor all L1->L2 txs. We could at least add a check that L2 gas should not be more expensive than L1 gas to eliminate the latter concern.

[ben-chain]

Would it be possible to read (on L1) a recent-ish (e.g. last L1-confirmed sequencer block) L2 gas price, and use that to set the fee?

Interesting thought, I'd be worried about the sequencer manipulating that pre-finalized value with a malicious proposal. Since the gasprice is the throughput ratelimit, then it would be scary that the sequencer might 1) be able to DOS the chain with tons of compute, or 2) censor with super costly compute, as you say.

You could make it so that the fraud proof corrects this gasprice and skips the transactions if it ended up being a malicious proposal. But at that point, you might as well just always do it in L2.

we could require ETH attached to the tx

This is definitely an option, and an example of where we need more user research. This may actually be inconvenient for DevEx because it potentially requires passing a msg.value down a lot of steps of the tx call stack.

[norswap]

Maybe if we adopt a modified EIP-1559 for the fee (which we could validate onchain at batch submission time), that would preclude manipulations (excepted to an insignificant extent)?

You could make it so that the fraud proof corrects this gasprice and skips the transactions if it ended up being a malicious proposal. But at that point, you might as well just always do it in L2.

I'm not sure what you mean here!

[ben-chain]

Maybe if we adopt a modified EIP-1559 for the fee (which we could validate onchain at batch submission time)

This is a good idea; I think it would work, but I think minimizing L1 gas at all costs takes precedent.

I'm not sure what you mean here!

I think I was basically just saying you can do (2., 1./2.) in the options below.

[ben-chain]

I think from an ENG perspective we may actually have more than two options. It seems like we really have a combo of possibilities in two dimensions:

Where the ratelimit occurs:

1. We can ratelimit up front on L1, guaranteeing that transactions succeeding on L1 will be run on L2.
2. We can ratelimit on L2 based on the L2 BASEFEE, so that it is possible to submit a transaction succeeding on L1 but failing on L2.

How the ratelimit is paid:

1. We can require that gas is burned on L1.
2. We can require that assets are transferred on L1 (ETH, WETH, or even DAI lol)
3. We can require that assets are transferred on L2 (e.g. from the oETH balance of the L1 msg.sender)

We currently implement (1., 1.). I think any combo is possible to implement other than (1., 3.).

[norswap]

Ratelimit on L2 seems really bad for UX in a way that is hard to improve on.

[ben-chain]

I agree that "a transaction succeeding on L1 but failing on L2" is a very tricky spot to be in. It might be reasonable if there were a way to "re-run" it from within L2 by paying more gas, idk.