DA, op-batcher: imrovements tracker

[protolambda]

With actively changing blob fee market dynamics we need to: 1) out-of-protocol: adapt the batch-submission operational functionality to maintain fee-accuracy and optimal op-batcher operation costs. 2) in-protocol: adapt the fee-pricing to provide the lowest and most accurate fees to end-users.

Out of protocol

These changes can be implemented now, to mitigate any short-term issues.

• Runtime batcher configuration:
  • https://github.com/ethereum-optimism/optimism/pull/10897
  • https://github.com/ethereum-optimism/optimism/pull/10837
• Cancellation of in-flight batcher blob transactions, to reset the nonce such that calldata transactions can be submitted and confirmed.
  • https://github.com/ethereum-optimism/optimism/pull/10941
• Parallel processing of L2 chain consolidation (DA derivation parallel to engine processing of p2p blocks): see events processing and later parallel deriver execution:
  • https://github.com/ethereum-optimism/optimism/issues/10865
  • https://github.com/ethereum-optimism/optimism/issues/10864
• Automatically switch between blobs and calldata
  • https://github.com/bnb-chain/opbnb/pull/209

Ideas:

• Add back-pressure system, to reduce DA usage of sequencer, by lowering block throughput in terms of total L1 cost dynamically, once the batcher starts to lag behind in work. The sequencer block-building code could inspect the diff between the safe-head and unsafe-head, and the larger the diff, the less L1-cost could be included.

In protocol

These changes require a breaking change, and thus a coordinated network upgrade.

Ideas:

• Dynamically swap pricing parameters between calldata and blob configuration, depending on the optimal choice of DA. This lowers costs for users automatically, with the assumption that the batcher is operated optimally also.
• Monitor volatility in DA fees, and increase L1 fee parameters dynamically when high volatility is perceived, to derisk discontinuity between optimistic fees (time of L2 transaction) and realized fees (time of L1 transaction).
• Support multiple batch-submitter addresses to submit for the same chain and inbox, to have more flexibility as batch-submitter, to work around transaction replacement / nonce issues.
  • Warning: this conflicts with the generalized batch-authentication idea of making a L1 contract emit an event to accept/deny data in the inbox.
  • Warning: this conflicts with a new initiative to introduce strict batch-ordering, which can reduce op-node startup/reset time significantly (no need to walk back L1 chain as much) and optimize proofs (much less execution due to much shorter L1 traversal). This is being suggested as a feature on top of the steady-batch-derivation project.

[tynes]

I want to explore the possibility of using https://github.com/ethereum-optimism/specs/issues/221 rather than directly supporting multiple batcher addresses. Adding multiple batcher addresses to the protocol will add tech debt to the protocol where as using a smart contract to define logic is generic and can be extended permissionlessly to support many features. We would need to engineer around the fact that batches can be posted in both blobs and calldata, but with the right smart contract architecture this is certainly possible to handle. The general philosophy that the OP Stack should follow is creating powerful abstractions that enable permissionless innovation rather than hardcoding particular solutions to problems