Deposit Fee design

[maurelian]

Originally written by @ben-chain here, moved here for easier discussion.

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).

[norswap]

There is a third alternative, one that we were actually considering even more strongly (sorry if that wasn't clear from the previous thread) which is to not do a congestion control system on L1 at all. This remove the SSTORE cost.

(We would still burn L1 gas or charge an ETH fee on L1, but the price of this would be dependent on the price of L1 gas, and not on the number of deposits, or L2 congestion in general.)

The idea is that DoSing the chain from L1 is not really possible if we burn L1 gas, because the largest amount of L2 gas that could be consumed by the deposits of an L1 block is L2_gas_stipend * L1_gas_limit / L1_gas_cost_of_deposit. If we pessimistically assume the stipend is 4x the gas cost of a deposit, then a deposit block can only be 4x as large as a normal L1 block, which we should be able to handle with ease.

(Such a "DoS" is still possible if paying ETH for L2 gas instead of burning L1 gas, something I hadn't considered!)

The only problem with this is that it is possible (it would take some extreme level of L2 congestion though) for it to become temporarily cheaper to transact via deposits than via L2. I think people agree that this is less important than minimizing deposit gas cost.

In both cases, users can overpay (and get the ETH refunded on L2) to decrease the likelihood of a failure.

The current plan is not to ever refund ETH for deposits. Such refunds do introduce extra complexity (esp. given the stipend), are not particularly intuitive, and we expect 95%+ of deposits to be effectively free because of the stipend. There are further mitigations for people who would like to do "dynamic calls" (calls that might consume little or much ETH), search "dynamic calls" in the previous thread.

[ben-chain]

Ugh, yeah, the math on the max values really cuts it quite close. This feels like a binary thing where it either invalidates the option or is totally fine. I don't think block frequency is relevant, since the 25-33x is independent, but still very real. We may just need to measure performance to really know here.

One "cheat" we can also consider: count other trusted sources of gas usage towards the stipend. This would look something like: if msg.sender == OVM_L1StandardBridge, then award an additional stipend (based on the cost of the ERC20 transfer which must have preceded it). ERC20 transfers are common and will consume a lot more than 4k gas (20k?), which helps naturally decrease the multiplier. There is a natural synergy where ERC20 deposits require more gas than pure ETH on the other side anyway. The downside is only trusted contracts can be given this access, but maybe the ERC20s, especially with a depositAndCall, would be enough.

[ben-chain]

The additional gas burn is definitely the least ideal part to me, assuming the above math checks out. Especially as L1 gas becomes more expensive, it's frustrating to just burn extra L1 gas, even if L2 is totally empty.

What if only gas beyond the stipend was made refundable? Something like: if deposit_fee < requested_extra_gas * l2_BASEFEE, then the transaction call frame is only supplied the L2 gas stipend, and the ETH (which failed to cover the additional gas cost) is refunded. Maybe dynamic callers could work with this, since they are dealing with failure/conditionals anyway.

[norswap]

This feels like a binary thing where it either invalidates the option or is totally fine. We may just need to measure performance to really know here.

We definitely should measure, if we're sure we can take the load, we're fine.

It being binary, I'm not sure. Cost must be weighed against consequences. The consequences of a huge deposit block is that the block will take time to be created, which will cause timeslots to be skipped.

Purchasing a whole L1 block is bound to be HUGELY expensive, and really not worth the cost if the consequence is merely L2 skipping a few timeslots.

If you think about it, L1 has the same ""vulnerability"" - you can purchase out a L1 block to "DoS" the chain by preventing other people to transact. But who would pay through the nose to deny one block?

Therefore, even if — for instance — the max theoretically possible lever is 33x, I'd be quite okay if we can manage 20x, because if someone manages to reach the theoretical max, they're just paying a whole lot for a very mild disruption.

ERC20 transfers are common and will consume a lot more than 4k gas (20k?)

Etherscan estimates an ERC20 transfer at 65k, so if you remove the say 25k for the base 21k + calldata, that's 40k.

One "cheat" we can also consider

I'm not sure why this cheat is needed, ERC20 transfer should be fully covered by our stipend right? So no L2 fee is paid for them.

The additional gas burn is definitely the least ideal part to me, assuming the above math checks out. Especially as L1 gas becomes more expensive, it's frustrating to just burn extra L1 gas, even if L2 is totally empty.

I'll ask people from the integration team about this explicitly.

I felt like it wouldn't be that much of an issue based on the following reasoning:

• Most deposits will be covered by the stipend, no additional gas. Bit of an "ass number", but probably 95%+ of deposits will be transfers.
• We could also lower the amount of L1 gas burned by dividing by a (updatable) constant. This increases the max theoretical attack lever, but as L1 gas prices increase, so does the cost of the attack.
• If your deposit uses a "dynamic" amount of gas, there are mitigating patterns you can use (see link in my previous comment on "dynamic calls").

What if only gas beyond the stipend was made refundable?

That's doable, but with the consequence that the stipend amount becomes encoded in the rollup node, and hence in the fault proof, so it's harder to update.

I'm not sure of your thinking here. You write this after talking of the additional L1 gas burn as if this solves the issue - but this only solves the related issue of burning more gas than you need. You still have to burn (potentially expensive) L1 gas for the extra gas that you actually use.

My impression is that refunds are not worth bothering with. It will only affect a small fraction of use cases (complex calls, so not deposits, who use a dynamic amount of gas). There are quite a few possible mitigations also:

• the "push-pull" pattern where your deposit puts inputs on L2, then you run some more processing via a L2 call
• split your complex L2 call into multiple simpler L2 calls and make multiple deposits (each benefitting from the stipend) — this works for our purpose because we're concerned about the max size of deposit blocks and this does not increase it

But I will ask integration people about this!

[norswap]

Adding in a good remark @ben-chain : we need to take the DoS case seriously, because the stake is a rogue sequencer posting un-disprovable state roots (because nobody can catch up with processing the volume coming in from the deposits), hence potentially allowing him to make off with the whole rollup's TVL.

This does mean that the deposit spam has to be sustained for a looong time so that validators can't catch up within the 7 day window though. That's a pretty insane (and one that should be mitigatable if the upgrade delay is << 7 days). It is however a good point that there is much more of a stake than my comment seems to imply, and that more caution is warranted.

[maurelian]

This does mean that the deposit spam has to be sustained for a looong time so that validators can't catch up within the 7 day window though.

Nit: if you could make it so that they can't catch up for 3.5 days, then you only need to censor the fault proof for 3.5 days. Point just being that it reduces the safety factor, and we should keep in mind multifaceted attacks during the design process. :)

[smartcontracts]

Some stream-of-consciousness notes on my end:

1. If we're going to charge users on the L1 side, I think a gas burn is still the best UX. Without a gas burn we need to charge users in some token which would almost certainly be ETH (unless there's another way to rate limit on the L1 side that I'm not thinking about). If we have to charge users ETH, then everyone needs to start adding payable keywords to every contract that sends messages to L2 which would be a complete devex headache. So if we're going to charge on the L1 side, we should stick with a gas burn.

2. With respect to the matrix defined here by @ben-chain, I would prefer (1, 1) but could possibly be convinced of (2, 1). However, (2, 1) would have to come with a mechanism for any account to pay for the gas to replay a transaction. This seems like a major headache for devex and ux, I'd prefer not to have this.

3. If we charge on the L2 side, doesn't that mean users need ETH on L2? I assume this means we need some special deposit logic that allows users to deposit ETH so they can pay for further actions on L2. Could introduce some UX headaches for users who just want to deposit some tokens and don't also want to deposit ETH.

4. I see some potential complexity around smart contracts. Smart contracts can have the same address on both L1 and L2 but might have different code. How do smart contracts (and smart contract wallets in particular) define the address who's going to pay for the deposit cost on L2? Edit: Arbitrum handles this by having users fund the account of the aliased L2 address for smart contracts. Seems like a potential headache for smart contract wallets and I don't love it. Actually, I feel very strongly that charging users on L2 is a bad design and creates too many potential headaches. At most, charge users on L1 and allow users to replay on L2.

Generally speaking, after thinking about this more, I feel that we should treat accounts on L1 and L2 as fundamentally different and that we should have the L1 account pay for the action on L1. In particular, I think this should be done as a gas burn on L1 like we currently do.

I think the main question to be answered then is how we determine the burn ratio, effectively "how much is L2 gas worth right now relative to L1 gas?". I feel that we will ultimately have to come up with an automated mechanism to handle this some time in the future. Any fixed value that we choose will either have to be extremely expensive or will eventually be so cheap that it's more efficient to send all transactions on L1 instead of going through the Sequencer.

Using a dynamic fee means getting information from L2 that tells us how congested L2 is. Congestion can spike up or down in the short term and it takes 7 days for information to flow from L2 to L1. However, it might be the case that this doesn't matter on short time windows and we can get away with using the BASEFEE from L2 to constantly update the ratio on L1, even if we're a week behind. Deposit gas costs would increase in response to macro trends but would not be impacted significantly by short-term trends. This is the sort of thing where we would have to do the math on the potential impact that someone spamming deposits could actually have on the network.

[ben-chain]

Generally speaking, after thinking about this more, I feel that we should treat accounts on L1 and L2 as fundamentally different and that we should have the L1 account pay for the action on L1.

Can you speak more as to why you feel this? To me, if something can authenticate a message from an address it should be able to pay for it. Why not let an EOA pay on either chain, or a contract to pay for/as its alias?

[ben-chain]

Thinking about the aliasing thing; I get now why Arbitrum requires giving money to the alias. I think this is probably what you meant about the contract wallets but a different example clicked for me. Imagine you were to send a deposit message from a flashloan contract which exists on the other chain--then you could get it to pay for your gas on L2.

[maurelian]

If we charge on the L2 side, doesn't that mean users need ETH on L2? I assume this means we need some special deposit logic that allows users to deposit ETH so they can pay for further actions on L2. Could introduce some UX headaches for users who just want to deposit some tokens and don't also want to deposit ETH.

To this point, I believe we also have quite a few users who deposit a token and are frustrated to realize they now need ETH on L2 to do anything with it.
IMO we should aim to enable simultaneous ETH and token deposits anyways.

Arbitrum handles this by having users fund the account of the aliased L2 address for smart contracts.

A slightly different wording, but FWIW it helped me to think of this as "the tx fee payment on a deposit transaction always comes from the L1 address".

[norswap]

To this point, I believe we also have quite a few users who deposit a token and are frustrated to realize they now need ETH on L2 to do anything with it.
IMO we should aim to enable simultaneous ETH and token deposits anyways.

That's our current plan with mint deposit parameter, right?

[maurelian]

yep!

[ben-chain]

@smartcontracts I agree with a lot of what you've written and am coming around to L1 metering more and more. I think the remaining concern I have is still what we discussed here in the second half--in the world where L2 is completely uncongested, and you want a larger L2 gaslimit than already burned by calling the L1 deposit function, then you have to burn additional L1 gas, which is ultimately overpaying given the resource price on L2.

I would propose the following modification to the scheme to solve for this without introducing too much complexity. I think this might basically be what we meant with "combining proto and norswap's approaches" in the last thread, but I didn't have my head wrapped around it yet.

• An L1 deposit can choose to burn as much gas as it likes for some guaranteed execution on L2. At minimum, we count the gas burned on L1 by sending the ETH or ERC20, CALLing the deposit contract, emitting the deposit event, ... as "burned".
• The gas burn ratio is correspondingly max_l1_gas_per_sec : max_l2_gas_per_sec so if L1 is totally full, L2 is at (but not above) max capacity.
• Optionally, the depositor can specify an additional_gas parameter, and a fee_payment value in ETH. The execution engine interprets this as follows:
  • If l2_BASEFEE * additional_gas > fee_payment, then the call frame is given only the guaranteed minimum caused by the burn which occurred on L1. The ETH is returned to some address defined in the TX type, which we would set to the NON-aliased address by default or maybe have as a parameter.
  • Else, the call frame on L2 is given additional_gas extra to work with. Refund of fee_payment - l2_BASEFEE * additional_gas worth of ETH is sent in the same way as above.

So basically, you can try to pay for additional gas, that can then be refunded--but no guarantees.

• Backwards compatible/strictly additive
• Allows this optimal usage without burning extra L1 gas
• No complex replayable ticketing system (stipend should be sufficient to implement replayable ticketing at the application layer in the worst case)

[maurelian]

At minimum, we count the gas burned on L1 by sending the ETH or ERC20

One nit is that ERC20 token transfers can very quite a bit in cost. I guess we can just index on the 'theoretical minimum' assuming a pure assembly impl (ex: lightclient/erc20. It will also be a bit of an ongoing headache whenever some opcode is repriced.

Optionally, the depositor can specify an additional_gas parameter, and a fee_payment value in ETH

I assume this is what you mean, but to be explicit, fee_payment would require a corresponding deposit of ETH right?

[maurelian]

The gas burn ratio is correspondingly max_l1_gas_per_sec : max_l2_gas_per_sec. if L1 is totally full, L2 is at (but not above) max capacity.

Can you explain the rationale for this? It seems to assume that the value of gas is determined solely by supply, without regards to demand. The last two paragraphs of @smartcontracts post are relevant as well, but I haven't seen a response to them anywhere.

[protolambda]

@ben-chain sounds good to me.

Previously I would go for the other variant: remove the additional_gas param, and divide fee_payment by L2_BASEFEE to determine the L2-part of the available gas. The L2 part of the gas would be dynamic, but refundable. If there's not enough gas, the execution can exit early or run out of gas. To guarantee execution, the user can always pay for gas on L1 (the stipend part that is backed by burning / intrinsic cost on L1). Being able to choose between L1-gas guarantees and L2-gas congestion control is a nice combination.

"Checking if the gas is sufficient and diverting execution to a fallback" can technically be moved to the application layer with above variant, but it's probably a good idea to build it into the deposit system to avoid surprises for users and enforce it as a practice.

[ben-chain]

The reason I described the conditional around l2_BASEFEE * additional_gas > fee_payment is that it seemed compelling to be able only buy the gas if it was as cheap as some value. It just seemed like you'd want to avoid the world in which you send in a 1 ETH fee payment, but the l2_BASEFEE is very high and causes you to spend it all on only 100 L2 gas. "I want to buy additional gas on L2 so long as this fee covers Y additional gas".

[norswap]

@ben-chain

The main issue I see with this proposal is that it enables DoS. There are no intrinsic limits on how big your additional_gas and fee_payment can be. This means a malicious depositor can pay a lot to make deposit blocks balloon, which is the very thing we were worried about a minute ago.

Even if we do impose a L1-side limit on additional_gas, every additional gas that does not burn L1 gas increases the potential DoS lever (that 25-33x figure we came up with before).

If we impose a gas limit on the deposit block, we either have to enforce it on L1 (incurring SSTORE cost - at which point we might just as well do EIP-1559 on L1), or on L2 (in which case you can have successful L1 deposits that do not make it on the L2 chain).

[ben-chain]

Hmm, I think a fixed upper bound on additional_gas would be good to enforce (could be either on L1 or L2), but I'm not sure what DoS attack you have in mind otherwise. The intent at least is that the l2_BASEFEE * additional_gas > fee_payment check ensures that the additional gas is only purchasable at the same price as the L2 EIP1559 charges for normal L2 transactions. So long as the L2 gas consumed by deposits is included in the gasUsed calculation of the l2_BASEFEE, wouldn't this prevent any DoS? The more addional_gas that is bought via L1, the more expensive it becomes, and the more likely that the conditional fails and additional_gas is not awarded.

[norswap]

(reproducing my slack comment for posterity)

Okay, I get it! You get charged EIP-1559 price for additional gas on L2, so you get the exponential price increase block to block. Because there is not per-block gas limit for deposit blocks, you can still cause a massive surge in size in a single deposit block, but you won't be able to keep it up for many blocks, which is the dangerous attack.

Yes, that can work. It will require (significant?) tweaking of EIP-1559 to work with deposit blocks (unless we run a separate EIP-1559 for deposit blocks only?). I do feel in my heart of hearts that the benefits are not worth the complexity, but I think it's an acceptable solution nonetheless, with a good rationale behind it 👍

[ben-chain]

It will require (significant?) tweaking of EIP-1559 to work with deposit blocks

This isn't obvious to me FWIW, what modification do you have in mind? If all gas used (including L1-burned stipend) affects the BASEFEE in the same way, it seems like block processing would just naturally handle the EIP1559 with no modification at all. I'm not an expert though, thoughts @protolambda ?

[norswap]

You are very right and I wrote that too hastily. I was thinking we need to exclude the stipend but still somehow account for it, but I think we can just count everything.

[norswap]

Had a great discussion with @K-Ho, here's a summary:

• concerned about the security of the gas burn scheme
  • is 25-33x something we can really handle?
  • BSC is reportedly struggling with 10x
    • need to check numbers here
  • we could play with the numbers (cost of additional gas / stipend) to balance cost of deposit vs DoS leverage
    • if the cost gets past a certain point, it might be better to go with L1 EIP-1559 (or another scheme that can be optimized to require a single SSTORE)
  • even if the attack is unlikely, concerned that people would compute the cost of the attack and use it for some bad PR
    • it's actually really hard to compute because it depends on extraneous demand and EIP-1559 — it probably requires a simulation using a model of tx demand
• BUT Kev really likes the idea of going with such a L1 gas burn scheme (or even lower) in order to minimize the gas cost of deposit, given that we can dynamically increase the cost of deposit (by changing the cost for additional gas and lowering the stipend) in case of an attack
  • this dynamic adjustement can be done by us initially, since we have contract upgrade rights, and in the longer term by some kind of governance
  • lots of emphasis on this being a good way pragmatic way forward & guaranteeing low deposit fees + safety
• regarding Ben's idea of sending ETH to pay for additional gas, Kev thinks it sounds a bit complicated
  • but since it's purely an add-on, we can always explain the gas burn-only method first, and then mention the additional method as an extension for advanced users that need to spend a lot of gas, so I do think it's not necessarily that much of an issue — users only need to know about it if they need it

[norswap]

Found it hard to find TPS numbers, but this puts BSC at 160 TPS so indeed approx 10x Ethereum L1.

[maurelian]

TPS is a poor measurement on smart contract chains, gas per second is better.

Just looking at gas per day charts (and zooming in on recent periods) gives:

• BSC ranging from 1 to 2 x 10^12 gas/day
• Ethereum at 1 x 10^11 gas/day

So, ultimately a similar conclusion, 10 to 20x. :)

[norswap]

Writing down a remark by @ben-chain: if we at some point we want to have a "rollup-on-a-rollup" (i.e. L3), then we will need some form of explicit limit, because L3 won't be able to take 25x the L2 block size (which, in the worst case is itself as big as 25x the L1 block size).

Own note: given the lower gas costs of L2, it's probably more feasible to implement EIP-1559 on L2 for L3.

[maurelian]

Thinking about this, I think it should be possible to detect when a transaction is occurring in a deposit block (or else we can make it so).

Of course we just want to prevent this attack, but I think it's ideal if L1 -> L3 deposits are possible. We could address this by:

1. Detecting L2 -> L3 deposits occuring during an L2 deposit block
2. Removing or modifying the stipend of L3 gas which is granted based on L2 gas costs.

[ben-chain]

Updated Proposal

Here's where we have come to with these discussions, and the path ahead to finalization/open decisions. It is a combination of @norswap 's original proposal and @protolambda 's idea for a simplified, optional way to pay for gas at L2 prices. This is basically me expanding on this comment here and discussing next steps.

Summary

• Gas for deposits is always paid on L1. We have reached agreement that the complexity introduced by paying directly from an L2 balance is too much.
• L2 deposit gas can be purchased in two forms:
  • A "guaranteed" stipend, which the L2 transaction is always allotted on L2. This form of gas may be more expensive, but a developer is guaranteed atomicity/execution on L2 within this gas limit. Payment for this form of gas is authenticated (rate limited) directly on L1 to prevent excess throughput.
  • Gas can be requested which is not guaranteed to be given out on L2. However, it is priced by the L2 BASEFEE, meaning that if extra ETH was sent in on L1 than needed, that ETH will be refunded on L2.
• These gas parameters are a part of a single TX type on L2; we will not mess with multiple types.
• Replay-ability of failed deposits will NOT be baked into the protocol, but stipends will be enough to re-implement at the application layer (which COULD include our standard messenger contracts, i.e., this can still be a library we provide).
• Because all deposits cost some amount of ETH on naturally due to L1 gas costs, we will count this expenditure, for all deposits, towards a stipend of guaranteed gas.

Pending Decisions

Finalize deposit TX type & check implementation overhead

We need to make sure that implementing this form of deposits is not too much implementation complexity in the engine, and precisely what the tx type would be. I will include a proposal based on @protolambda 's post in the older thread separately to this post. This decision is independent of the others below; we can finalize the engine before making any of the below decisions, which are both at the L1 contract/block derivation level.

Acceptable Gas Stipends

As stated above, L1 gas expenditures will be credited towards a stipend. We need to know what the minimum meaningful stipend to provide is. This is fundamentally a developer experience question. Note that we can count trusted L1 codepaths' expenditures towards the stipend. For example, and ERC20 deposit costs more on L1 due to transferFrom and we can guarantee more L2 gas accordingly. So the questions we need to basically answer are:

• What is the minimum acceptable L2 gas stipend for a value-less deposit (pure call)?
• What is the minimum acceptable L2 gas stipend for a nonzero-value deposit? (call with value, costs more gas on L1)?
• What is the minimum acceptable L2 gas stipend for an ERC20 deposit?

Note that we can allow more than this minimum to be purchasable, so devs can buy as much guaranteed gas as they want on L1, but ideally we'd like no additional cost in the standard code paths for deposits (minting on L2). This decision will inform what we go with in the next decision:

How to rate limit stipends on L1

Our solution needs to guarantee that the total gas guaranteed by L1 does not exceed our maximum L2 gas/second.

• If min_l2_gas_stipend / min_l1_deposit_gas_cost < max_l2_gas_per_second / max_l1_gas_per_second then this rate limit is naturally enforced by the L1 EIP1559 itself. We are currently investigating whether this holds, big thanks to @mslipper for coordinating.
• If not, we need to enforce an EIP1559-like rate limit from within the deposit contract. This would effectively implement the time-aware basefee EIP in solidity.

---

edit: see below for clarification

I would recommend that we denominate this rate limit in ETH, not L1 gas. This would work as follows: the deposit contract would track an L2_STIPEND_BASEFEE value which reacts on L1 to the requested stipend_gas parameter of deposits. When a stipend_gas amount is requested on L1, the L1_BASEFEE * L1_deposit_gas_cost can be used to calculate how much ETH has been "naturally" payed on L1

• If L1_BASEFEE * L1_deposit_gas_cost >= L2_STIPEND_BASEFEE * stipend_gas, then enough has already been paid and we charge no more.
• Otherwise, the user must pay an additional (discounted) extra_payment = L2_STIPEND_BASEFEE * stipend_gas - L1_BASEFEE * L1_deposit_gas_cost ETH to make up the difference. I like @norswap 's proposal of allowing this to be paid by either burning extra_payment / L1_BASEFEE L1 gas on the spot, or just by directly paying extra_payment ETH at some small discount.
• The effect of this is that when L1 gas prices increase, we actually can afford more of a stipend naturally, which I think is pretty intuitive. This can create situations where high L2 congestion causes gas to become cheaper if sent via deposit, as @smartcontracts has previously mentioned, but this will be transient since the L2_STIPEND_BASEFEE will also increase. At some ideal equilibrium we should expect them to track similarly. We will want a minimum value for this, though.

[norswap]

As promised, a few more comments

Gas can be requested which is not guaranteed to be given out on L2.

Probably need to expanded to say under which conditions it is not purchased (i.e. if the supplied payment is not enough to purchase the requested gas — in which case a refund occurs).

For example, and ERC20 deposit costs more on L1 due to transferFrom and we can guarantee more L2 gas accordingly.

This is not feasible in general, and can only be achieved through whitelisting select contracts, so I think an explanation should reflect that fact.

L2_STIPEND_BASEFEE

We probably want to be able to update this value, right? We should say so, and how (although probably "for now, by Optimism PBC, and by some kind of governance in the future" is enough).

Artificially cheap deposits

Wouldn't it be a good idea to contrast the merit of the proposed approach with Kevin's proposal of having a artifically cheap fees (e.g. through a low L2_STIPEND_BASEFEE to use the proposal's own terms) and to simply increase it if it proves problematic in practice? It's not the most elegant approach, but it's pragmatic advantages cannot be denied (especially if we determine that we can't handle a stipend that covers common use cases).

[ben-chain]

(edit: this was sent before comment above was seen)

I think there's a name collision on what we mean by stipend here. Sorry, I should have clarified that; I think I used a different definition above. In the most recent proposal, what I am referring to as "stipend" here is the gas value guaranteed on L2. This is in line with proto's earlier tx spec but is different from a "payment stipend" which was probably used further above. Maybe that helps with 1.

[norswap]

Okay, that explains a lot! I do think the prev definition is more intuitive etimologically and also to distinguish it from the "extra gas" (which is also "a stipend" in the same same sense as the payment for guaranteed gas is).

Anyhow, given this clarification, my points still hold, and if I had to rephrase them in a way that is clearer:

1. L2_STIPEND_BASEFEE must be set in such a way that the max size of a deposit block is something we can handle. This probably implies we need to be able to change it (esp. if it's denominated in ETH).
2. We can't pay for guaranteed gas in ETH, because this would essentially remove any kind of limit on the deposit block size: a single deposit could consume as much guaranteed L2 gas as it wants, as long as it pays for it in ETH.

[ben-chain]

Tried to add some color below to help explain below, but responses here are:

1. This is already a dynamic storage variable set in such a way that congesting L2 becomes prohibitively expensive, like L1. I've renamed it to base_fee_per_guaranteed_gas for naming clarity.
2. We should add an upper bound on the single-deposit limit, similar to EIP1559's 2x target block gas limit, but the protocol is otherwise resistant to congestion attacks. While deposits may temporarily exceed the target gas/sec, the EIP1559-like contract makes this exponentially expensive if sustained for a long period of time.

[norswap]

Ah! It wasn't clear to me that the proposal above was include a EIP1559-like construct. Contention point here is the SSTORE cost, but it does make the proposal consistent & logical 👌

[ben-chain]

Adding more color:

Deposit Contract

Implements EIP4396 basefee calculations in solidity.

Storage

• prev_deposit_timestamp:
  • value will update for every non-empty deposit block
  • used like self.parent(self.parent(block)).timestamp for L1 EIP
• base_fee_per_guaranteed_gas
  • used like self.parent(block).base_fee_per_gas in L1 EIP
  • units of ETH/wei
  • is what's currently being charged for deposits
• guaranteed_gas_allotted_in_block:
  • tracks guaranteed gas given out so far in the block
  • used like self.parent(block).gas_used in L1 EIP

Ideally, these values could be compressed into one slot.

Interface/functionality

• deposit(guaranteedGasLimit, target, data) payable: charges guaranteedGasLimit * base_fee_per_guaranteed_gas ETH in one of two ways:
  • payable in ETH/msg.value
  • By burning base_fee_per_guaranteed_gas * guaranteedGasLimit / block.basefee gas (L1 gas using L1 basefee)
• if sufficient funds, emits the event and guarantees the L2 gas, else revert

Optional gas

If we want L2-purchasable, optional gas, we would do:

• a modification to deposit(...) function
  • would add two additional fields:
    • requestedGasLimit: a request for extra, non-guaranteed L2 gas
    • maxFeePerGas: max L2 gas cost (else ETH is refunded)
  • cannot be paid in gas burn, must send ETH to potentially be refunded on L2
• a modification to the Engine's deposit TX type
  • guaranteed gas, gaslimit, redirect addresss

[maurelian]

Marking this as the answer.
There is also relevant detail in this comment.

[ben-chain]

Crunched the numbers comparing gas costs on current OP network to what we'll have with/without the on-chain EIP1559:

• _sendCrossDomainMessage takes 100k gas; this is effectively what we are talking decreasing most directly with the new block derivation/deposit contract. some of that breakdown:
  • looking up the messenger from the resolver takes 6k gas
  • having the messenger on a proxy takes 6k gas between the CALL itself and resolve
  • sendMessage once the implementation is delegate called takes 88k gas
    • enqueue costs 60k gas
• having the gateway on a proxy takes about 18k gas
• The only significant source of additional gas I see in the deposit flow which isn't protocol/rollup-related is that the deposits variable we keep in the standard bridge. Because we track multiple l2tokens for each l1token we have to track those balances (instead of having a contract for each l1/l2 pair and using l1token.balanceOf(address(this))), this is an additional 5k gas per deposit. Feels out of scope/too complex/too backwards incompatible to modify this one.

Conclusion:

• concretely, keeping proxies as-is and without modifying the bridge implementation, the theoretical min ETH deposit would be something like 45k + (sendMessage cost) gas:
  • 21k intrinsic
  • 18k for bridge proxy
  • 6k for the bridge events, encoding, etc. which are not a part of _sendXDomainMessage
  • • whatever the message sending cost is.
• and for ERC20 it would be something like 88k + (sendMessage cost) gas
  • 21k intrinsic
  • 18k for bridge proxy
  • 37k for transferFrom (obviously depends on token)
  • 12k for the bridge events, encoding, storage etc. which are not a part of _sendXDomainMessage
    • note this is higher than ETH due to storage slot point above
  • • whatever the message sending cost is.
• So, assuming messaging takes <15k, we can expect deposit costs in the next release to reduce to something like 60k for ETH, 100k for ERC20s.
• The % of cost for the EIP1559 storage slot overwrite (~5k) in a world where messaging would otherwise be free, other than routing through the messenger proxy is ~10% for ETH deposits and ~5% for ERC20 deposits.
  we could get more than this amount of gas back by not using the messenger proxy.
  messaging will not otherwise be free which lowers the % a little. @maurelian any guess on the cost of this function?

I'm leaning strongly towards the EIP1559 with this context.

• deposits are already going to be reduced like 60%.
• It would be 5% additional savings for ETH and 2.5% for ERC20 if we chose not to do the EIP1559 slot. For that we get:
  • no governance/trust dependency
  • no monitoring the infra for DoS to make sure we manually intervene
  • Long-term incentive compatible/sustainable/ossifiable

[maurelian]

@maurelian any guess on the cost of this function?

The depositTransaction function cost 28293 with no data being sent. With 160 bytes of data (the minimum size of abi encoded xDomainCalldata in the L1 Messenger), the cost is 30651.
The intrinsic cost of a transaction is 21000 gas, so the cost of execution and calldata are 7293 and 9651 respectively.

[maurelian]

@ben-chain having looked more closely, I now suspect the theoretical minimum for that function is between 5500 and 6000 gas. If we're very aggressive we might be able to get it down to 5000.

[norswap]

Reposting for visibility/transparency an internal document that summarizes the design we arrived at from this discussion, as well as following points of discussion:

---

Deposit Fees Design Summary

Design Goals

• We want deposits to be as cheap as possible.
• We want to minimize the probably that a deposited transaction will fail on L2.
  • But also would like to avoid the inherit complexity of replaying deposited transactions, if possible.
• We want to protect the L2 chain from DoS attacks via deposits, where it becomes possible to circumvent the congestion-control mechanism (EIP-1559) in place on L2 by sending deposited transactions via L1.
• Make it possible to pay for deposited transactions entirely from L1. Requiring users to provision L2 accounts beforehand is too much of a hurdle. It's okay if there is an option to do so however, as long as it doesn't conflict with the other design goals.

Orthogonal to this proposal but complementary:

• The ability to send ETH along with the deposited transaction (not only to pay fee, but also to make it easy for users to e.g. perform further transactions using their non-ETH bridged assets. (This is definitely going to be the case.)

Context: L2 Gas Price

On L2, the current proposal is to price gas using EIP-4396, a variant of EIP-1559 that targets a stable transacton throughput by time instead of by block.

Proposed Mechanisms

Each L1 deposit would include the following parameters, specified by the user and relayed in the L1 event that will be read by the rollup node:

• guaranteedGas
• gasPrice
• additionalGas
• refundAddress

Guaranteed Gas

The guaranteed gas is gas paid for on L1. It itself comprises:

• A gasStipend that gives users L2 gas to account for the L1 gas costs they incurred to make the deposit on L1. If possible, we'd like the gas stipend to cover the most common deposit use cases (and particularly ERC-20 transfers).
• Additional gas (guaranteedGas - gasStipend, if guaranteedGas > gasStipend) to be paid for by burning L1 gas.

We need guaranteed gas because we want a mechanism for guaranteed execution
on L2.

If guaranteedGas is enough to cover the transaction costs, then it won't revert due to out-of-gas issue. Crucially, the transaction will never fail because a change of L2 gas price.

This advantage is also the major inconvenient: guaranteedGas can be used to evade the L2-native congestion control mechanism.

See the "Pricing Guaranteed Gas" section below for a further discussion of the gas stipend on how to price guaranteed gas.

Note that the user cannot opt out of the gasStipend (it's free money!) so should he specify guaranteedGas < gasStipend, guaranteedGas will automatically be bumped to gasStipend.

Finally note that due to its "gas-burn" nature, unused guaranteed gas is never refunded.

Additional Gas

Besides guaranteed gas, the user can also request additional gas which will be paid on L2, and thus be subjected to the L2 fee pricing mechanism.

The user specified how much additional gas he wants to purchase with additionalGas and the maximum price he is willing to pay for this gas with gasPrice. He is require to send additionalGas * gasPrice in ETH along with his deposit.

On L2, if the deposit can purchase gas for <= gasPrice then additionalGas is added to the gas limit of the L2 transaction. Otherwise, the transaction will be executed using the guaranteedGas, and the gas sent to pay for the additional gas is sent to the refundAddress on L2.

Multiple remarks:

• We require users to fund the additional gas from L1, and thus prevent them to fund these deposits using their L2 balances. We do this to minimize the chance that the transaction will run without the additionalGas.
• Nevertheless, a transaction could still run without additionalGas if the price is too low.
  • A possible mitigation is to implement a retry system at the application-level, on L2, using the guaranteedGas. We should supply this as a Solidity library.
  • The risks of additionalGas should be emphasized in the documentation, and user should be directed to use guaranteedGas in most (simple) cases.

The advantage of additionalGas is that most of the time we expect this gas to be cheaper.

COMMENT:

I'm sure someone will suggest it, so let me go there first.

It seems weird to me to be cool with running without additionalGas if a low gasPrice is provided, but not to let users use their L2 balances to pay for it. We could implement a L2 balance check in the SDK if the user sends less ETH than gasPrice * additionalGas.

Any ETH leftover after paying for the actual transaction gas is sent to the
refundAddress.

Pricing Guaranteed Gas

Naive Guaranteed Gas Pricing

The whole problem in pricing guaranteed gas is that it allows to bypass the L2 congestion control mechanim.

That being said, guaranteed gas is not infinite, as L1 has its own congestion control mechanism (EIP-1559). There is therefor a lever which is how much L2 gas an attacker can cause to be used by unit of L1 gas spent. The absolute worst-case scenario being: how much L2 gas most we be able to process if a whole L1 block worth of L1 gas is dedicated to attacking L2?

A simple approach is simply to set the "L2 gas purchasing power" of one unit of L1 gas (i.e. the lever) to maxL2GasPerBlock / maxL1GasPerBlock. This ensures that we never have more than one L2 block worth of L2 gas to process for each L1 block.

Note that one L2 block can also contain additional transactions besides deposits but:

• We should comfortably be able to stretch beyond the max L2 gas parameter.
• Guaranteed gas should be counted in the L2 congestion control mechanism, in such a way that a surge in deposits would make non-deposit L2 transactions more expensive.

Gas Stipend Lever

The problem is with the gasStipend. It is awarded as a recognition that the user incurred some costs by transacting on L1. However, for an attacker this cost could be very low: he could make a huge transaction that repeatedly makes deposits at the minimum possible price (could be as low as 5-6k gas).

We would like the gas stipend to cover the most common use case, which is an ERC-20 token transfer, as that would make most deposits as cheap as possible.

Etherscan estimates an ERC-20 transfer to 65k gas (though that can vary a lot
between different ERC-20s). A 75k stipend would entail a 75k/5k = 15x lever.

For comparison, the BSC chain handles between 10 and 20 times the throughput of Ethereum, and sometimes struggles towards the high end of that range.

So we can probably handle a 75k stipend with some engineering (especially since an attack that purchases 100% of the Ethereum block space, let along for a long duration, is not really practical).

L1 Congestion Control ("EIP-1559")

Say that the L2 chain has 10x the throughput of Ethereum. This make our naive lever maxL2GasPerBlock / maxL1GasPerBlock == 10. So L2 gas at 1/10th the price of L1 gas. Currently this is not so bad, but after blob transaction land, this could be an order of magnitude more expensive than actually buying the gas on L2. But on the other hand, we need to limit the lever.

One solution is to implement a congestion control mechanism on L1 (like EIP-1559), where there is a depositBasefee that increases as more and more deposits come in.

This would enable us to have a low cost for guaranteed gas in general, but to increase the cost rapidly as a larger portion of L1 gas gets used to send deposits.

Note that the mechanism can also apply to the gasStipend: instead of denominating it in L2 gas, we denominate it in ETH as L1GasCostOfDeposit * L1Basefee (the L1 gas cost of deposit could be in the 5-6k gas range), and then use the mechanism to determine how much L2 gas this amount of ETH purchases.

Avoiding Gas Burn

While there is a need for guaranteed gas (to avoid reverts), gas burning is very wasteful. Without a L1 congestion control mechanism, we need it to avoid an infinite lever however. With the congestion control mechanism however, we're free to pay for guaranteed gas in ETH.

The idea would be to provide the ability to pay in ETH as an alternative to the gas burn.

We would keep the gas burn — which has maximally simple UX: there is no need to attach ETH and no need to compute the ETH needed to pay for a given amount of guaranteed gas: the computation is taken care of by the node's gas estimation logic.

However, we'd also allow paying for guaranteed gas in ETH, and would incentivize for this by giving a small discount (5%?) when using ETH for payment.

Note that enabling guaranteed gas payment in ETH means we most definitely can't reuse EIP-1559 as-is, because it only updates every block. Using EIP-1559 would allow someone to use a stupendous amount of ETH to purchase a ton of cheap L2 gas all-at-once in order to DOS the chain. Not to mention the technical challenges of handling blocks with unbounded amount of ETH (and potentially unbounded amounts of transactions).

(Unless that is, if we put a hard cap on the L2 gas usable by deposit every L1 block, meaning deposits that would cause gas the L2 gas consumption to go beyond this limit would revert. That's a pretty unexpected UX imho, better to let the user go to the frontend, try, see the huge fee, and figure out they should retry later. Though we should also make it abundantly clear that the fees do vary and are not fixed!)

---

Discussion

Above is the consensus we came to last time.

Feedback from Kevin is that it's pretty complex. I do agree, although everything has a justification.

If I were to convey to developers what to use, here's what I would say:

• Default mode is the guaranteed gas with gas burn. Use this if:
  1. You L2 transactions costs covered by the stipend.
  2. Your L2 transactions costs slightly above the stipend.
  3. You absolutely need to avoid failed L2 transaction & you're not willing to write your own application-level retry system.
• ETH discount as a small optimization.
  • 2 & 3 above, but you want to save monies at the cost of some complexity / hassle to you.
  • USE OUR SDK!
• Additional gas:
  • If you need to consume significantly more gas than the stipend.
  • If you're willing to implement an application-level retry system.
  • ... or if failed L2 transactions are benign for your application.
  • USE OUR SDK!

Things should be introduced in that order, with a strong recommendation on the first mode because it's the simplest.

One thing that's not quite clear to me though: that purchasing additional gas will necessary be cheaper than purchasing guaranteed gas with an L1 congestion mechanism. If we add to make one simplification to the design, I would make it that we simply drop additional gas altogether.

Although we could also go in the other direction, keep additional gas, but also allow the additional gas to be paid by L2 balances.

I think there's also something to be said about making the protocol more complex to accomodate UX: we could introduce a "retry tx" type which retries a previous deposit transaction that reverted because it ran out of gas. This would assuage most of my concern with additional gas and even letting users pay for deposits with L2 balances.

---

Protocol Office Hours Discussion from 25/03

• replayability problem solution

  • route, optionally but by default, all transactions through a “messenger” on L2 that saves the transaction so that it can be replayed later
  • we could have multiple different standard messengers implementing different kind of replayability guarantees (e.g. replayable only by the original submitter, or replayable by everyone), or users could roll their own
  • the cost of registering for replay should be covered by the stipend!!
  • one downside of this: things that are routed through a messenger can’t use msg.sender

• regarding this

  One thing that's not quite clear to me though: that purchasing additional gas will necessary be cheaper than purchasing guaranteed gas with an L1 congestion mechanism. If we add to make one simplification to the design, I would make it that we simply drop additional gas altogether.

  → The advantage of additional gas is that it can be refunded

• use cases

  • most use cases (i.e. ERC-20 transfers) should be covered by the stipend, no need to worry
  • but even for the bridge we still need to thing about when the stipend is not enough, because some ERC-20 transfers might go over the stipend amount
    • but we should just use the default “gas burn” path in this cas
  • in the majority of other cases (multisig, governance), gas burn should be recommended
    • it’s safe and easy, no need to mess with replays
    • might not even be expensive because of the L1 congestion control
  • if expenditure is a concern, esp. if calls could be very dynamic in nature or have a high revert chance, use additional gas
    • specialized fancy use-cases

• design simplification

  • should we drop the ability to purchase guaranteed gas via ETH?
    • I (norswap) said we could/should during the call, but thinking about it, all the rationale for it are still present
    • we can encourage people to purchase additional gas instead (though there’s no baked in incentive to do so... maybe ensure burned gas is slightly pricy compared to “normal” L2 gas price?)
    • would simplify an already complex design

• open question: paying for fees with L2 balances

  • given again that we have a standard solution for replays, should we simply allow additional gas to be purchased from L2 balances?
  • users would specify an amount of additional gas to purchase and an amount of L1 ETH to contribute towards that purchase (for safety, maybe we can also include a flag that says if we expected the L1 ETH to entirely pay for the additional gas purchase)