Thread by @technocrypto

A short Twitter thread on the difference between first-run and second-run gas pricing constraints, which are becoming increasingly relevant for things like optimistic rollups.

1of10

Background: gas pricing tackles 3 rough categories of resource bound simultaneously.
1. DoS risks (especially relative worst case risks)
2. Sync times
3. Long term chain size costs

(some of these will change with architecture, I'm just glossing that for now).

2of10

The first two of these especially can behave very differently on the "first run" of a brand new tx on a given state, like a block producer (either L1 or L2) does blindly with user TXs, vs a "second-run" such as someone else later syncing the block or running fraud proofs.

3of10

"But Jeff!" the more security minded of you are shouting, "block producers can also launch DoS attacks, so there's no real difference!"

But there is. And it's the fact that BOTH the operations and the before/after state are known, fixed, and committed to on "second runs".

4of10

This is exactly what access lists are about: constraining both the before and after state of a TX to better bound DoS risk. A block is the extreme version of this, with both before and after state fully fixed. (sidenote: this is partly what Turbo-geth-now-Erigon is about)

5of10

To give just one concrete example, for some types of TX the user submitting it *can't* fully know which addresses/storage slots they will hit on inclusion, so even with perfect strategy their access list will include some places they don't use.

6of10

First-run gas prices *have* to reflect the worst-case uncertainty within this range, or an attacker can exploit the gap. But once a given block is compiled, the producer of that block knows *exactly* which addresses and storage slots were accessed and which changed.

7of10

Technically this difference could be reflected in adjustments to block gas limits and block rewards when appropriate metadata is attached, but that's not what this thread is about. It's about L2 design, because L2s experience this same first/second-run differential.

8of10

This means that, e.g. fraud proofs submitted on L1 from an L2 can have better access list detail (and therefore gas pricing) than the actual user TX they contain. Second runs also have no need to maintain backwards compatibility for non-access-list applications, so...

9of10

...instead of just a price differential between declared and undeclared access full safelisting would work great. This doesn't require static analysis, because it's efficient to just log these values from the first run. So do that!

10of10