miner,eth: latest block as pending block on rollup

[protolambda]

Description

This fixes the pending-block behavior to be more compatible with pre-bedrock assumptions: requests for the "pending" block/header get served the "latest" block. This prevents transactions from the tx-pool from being revealed before they are committed to by the sequencer

Additionally this updates other lesser used API endpoints that utilize the "pending" mining state as well:

• debug-namespace methods do not serve state or receipts for the pending block, if not available like in the rollup case.
• the pending-state in graph-QL queries (as hit by StateAndHeaderByNumberOrHash) continues processing as "latest" state when the pending state is not available, like in the rollup case.

And to prevent unnecessary pending-block computations, the worker in the miner package is changed to:

• Do not update the pending-block snapshot when processing txs
• Not triggering recommits: the Engine API does its own revising of payload builds with buildPayload, and thus we can disable the pending-block work-triggering parts by draining the events that create those, rather than processing them (in newWorkLoop). Draining is important, as unsubscribing would leave the producing subscription channels filling up, causing the engine API to hang after producing blocks.

The engine API will still be initiating tasks for block-building, but does so by merely using the block-building functionality of the worker, not the whole recommit and snapshot thing that still remains from L1 PoW days / pending-block support.

I also suspect that this improves sequencing performance, or at least reduces block-building lag spikes: rebuilding the pending block continuously on the head block which changes every 2 seconds, and re-applying transactions, is expensive. Previously this was worked-around on the sequencer node by setting the pending-block gas limit to be very low (5000 gas to effectively force the pending-blocks to be empty), but now it doesn't try to build it at all anymore, which means there is less contention around the state of the chain and the tx-pool.

Tests

ethereum-optimism/optimism#5736

Replaces #81

Fix CLI-3793

[protolambda]

do not merge until we figure out test-failures in ethereum-optimism/optimism#5736

[protolambda]

Figured out the issue: the producing-side of the chain-heads subscription started blocking the forkchoice API. There needs to be at least one subscriber, which is the miner apparently. So instead I now implemented it to drain the produced triggers, without creating pending-block computation work, as well as ignoring incoming news txs, rather than unsubscribing to the tx events. Monorepo e2e tests should pass now.

[protolambda]

cleaned up the diff a little bit more. Ready for review now

[ajsutton]

LGTM.

[trianglesphere]

LGTM. Can you back port it to a new branch based off of release/v1.101105?

[ajsutton]

@trianglesphere I've created a branch with this change and #95 back ported onto release/v1.101105: https://github.com/ethereum-optimism/op-geth/compare/aj/backport-pending-block-l1overhead

We probably should have a better name for that branch but I wasn't sure what pattern we used so shoved it under aj/ until someone has a better idea.

I think we should also get both PRs merged into optimism if we're happy with them.

[trianglesphere]

The flag was not included in the list of flags. Failed to start b/c of this.

op-geth/cmd/geth/main.go

Line 160 in 6fe4241

}, utils.NetworkFlags, utils.DatabasePathFlags)

[trianglesphere]

lgtm