Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
N
nebula
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
exchain
nebula
Commits
aec36974
Unverified
Commit
aec36974
authored
Nov 19, 2024
by
Roberto Bayardo
Committed by
GitHub
Nov 19, 2024
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
document batcher throttling in op-batcher readme (#12957)
parent
b3ec4d69
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
19 additions
and
0 deletions
+19
-0
readme.md
op-batcher/readme.md
+19
-0
No files found.
op-batcher/readme.md
View file @
aec36974
...
...
@@ -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
)
.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment