isthmus: Add upgrade gas specs #616
Conversation
There was a problem hiding this comment.
I'm in favour of always adding the upgrade gas - it's so easy to forget otherwise. As long as L2 user transactions are not included, the increased gas limit is safe unless the upgrade transactions themselves are insanely expensive to execute in fault proofs which is extremely unlikely.
| ## Omission of user transactions | ||
|
|
||
| Starting with Isthmus, network upgrade blocks must not contain any non-deposit transactions, to | ||
| avoid any unintended interplay of user transactions with upgrade transactions. | ||
|
|
||
| This is checked at the batch stage. So if a batch of an upgrade block is not empty, it is considered | ||
| invalid and the rules for dropped batches apply. |
There was a problem hiding this comment.
Why only omit non-deposit transactions? And why do we need both "upgrade gas" and "omission of user transactions"? It sounds like either of them alone would mitigate the issue
There was a problem hiding this comment.
You can't omit deposit transactions - they must be included as part of the censorship resistance. Skipping user transactions removes the risk that the upgrade transactions don't use their full gas limit, leaving a higher than usual remaining block gas limit which could then be filled by particularly expensive L2 user transactions (ie calling precompiles that are expensive to execute in cannon). This way we know that the L1 deposit transactions have a fixed gas limit as usual (enforced on L1) and the potentially increased total gas limit is only usable by the upgrade transactions which we control so know they are fault provable.
There was a problem hiding this comment.
"Omission of user tx" only buys you the remainder of the block gas limit, which can be zero because the only guarantee is that maxResourceLimit + systemTxMaxGas <= gasLimit so it can be equal to the left side, which could in theory be fully exhausted.
And actually, user tx omission doesn't help at all really, because user txs are executed after all deposit txs are executed. So user txs don't pose a risk to the execution of upgrade deposit txs.
sebastianst
requested review from
protolambda,
tynes and
mslipper
as code owners
|
Moving out of draft as I got a 👍🏻 from @ajsutton on the specified design variant to always add the upgrade gas. |
|
Moving back into draft as we'll probably not include this in Isthmus. |
tynes
added
the
S-wontfix
|
Closing this as we are not shipping this |
Description
Adds specs for the upgrade gas feature of Isthmus, plus a new rule for omission of user transactions in upgrade blocks, which is so far only implemented in the op-node sequencer as a policy, not a consensus rule.
Additional context
See ethereum-optimism/optimism#14649
Note that upgrade gas is necessary because the
system transaction max gasis only 1 Mio and upgrade transactions in total now tend to consume more, like 3.x Mio gas for Isthmus (plus there's the L1 info deposit, which only consumes 44k currently though). The only constraint by the protocol on the gas limit is:maxResourceLimit(user deposit gas, usually 2e7) +systemTxMaxGas(L1 info deposit and upgrade txs (so far), usually 1e6) <=gasLimitThis version of the specs always adds the upgrade gas, which is the total sum of all upgrade transactions' gas limits, to the block gas limit. We could implement an alternative rule where we only update the gas limit of the block if it is smaller than
system transaction max gas + max resource limit + upgrade gas. This would have the property that this rule would effectively not alter the block gas limit of chains with typical gas limits (e.g. 60 Mio for OP mainnet) for Isthmus, which needs < 4 Mio upgrade gas (+20 Mio max resource +1 Mio system tx max gas).To clarify, this change is only necessary because we allow small gas limits. Chains with typical gas limits like OPM wouldn't need this rule.
Metadata
Closes #609