Skip to content

op-batcher: document batcher throttling in the readme #12957

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
geoknee merged 1 commit into from
Nov 19, 2024
Merged

op-batcher: document batcher throttling in the readme #12957

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions op-batcher/readme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,25 @@ The batcher can almost always recover from unforeseen situations by being restar

Some complexity is permitted, however, for handling data availability switching, so that the batcher is not wasting money for longer periods of time.

### Data Availability Backlog

A chain can potentially experience an influx of large transactions whose data availability requirements exceed the total
throughput of the data availability layer. While this situation might resolve on its own in the long term through the
data availability pricing mechanism, in practice this feedback loop is too slow to prevent a very large backlog of data
from being produced, even at a relatively low cost to whomever is submitting the large transactions. In such
circumstances, the safe head can fall significantly behind the unsafe head, and the time between seeing a transaction
(and charging it a given L1 data fee) and actually posting the transaction to the data availability layer grows larger
and larger. Because DA costs can rise quickly during such an event, the batcher can end up paying far more to post the
transaction to the DA layer than what can be recovered from the transaction's data fee.

To prevent a significant DA backlog, the batcher can instruct the block builder (via op-geth's miner RPC API) to impose
thresholds on the total DA requirements of a single block, and/or the maximum DA requirement of any single
transaction. In the happy case, the batcher instructs the block builder to impose a block-level DA limit of
OP_BATCHER_THROTTLE_ALWAYS_BLOCK_SIZE, and imposes no additional limit on the DA requirements of a single
transaction. But in the case of a DA backlog (as defined by OP_BATCHER_THROTTLE_THRESHOLD), the batcher instructs the
block builder to instead impose a (tighter) block level limit of OP_BATCHER_THROTTLE_BLOCK_SIZE, and a single
transaction limit of OP_BATCHER_THROTTLE_TRANSACTION_SIZE.

## Known issues and future work

Link to [open issues with the `op-batcher` tag](https://github.com/ethereum-optimism/optimism/issues?q=is%3Aopen+is%3Aissue+label%3AA-op-batcher).
Expand Down