-
Notifications
You must be signed in to change notification settings - Fork 708
[NIT-3121] Make uncompressed batch size limit configurable #3947
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.
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
[NIT-3121] Make uncompressed batch size limit configurable #3947
Conversation
❌ 5 Tests Failed:
View the top 3 failed tests by shortest run time
📣 Thoughts on this report? Let Codecov know! | Powered by Codecov |
Tristan-Wilson
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR looks good but I had a comment on the geth PR which will probably change this one due to how to access the new decompression limit setting, so marking request changes.
…-uncompressed-batch-size-limit
tsahee
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for the long delay. generally seems great
…-uncompressed-batch-size-limit # Conflicts: # cmd/replay/main.go
|
|
||
| tx, err := seqInbox.AddSequencerL2BatchFromOrigin8f111f3c(&sequencer, seqNum, batch, big.NewInt(1), common.Address{}, big.NewInt(0), big.NewInt(0)) | ||
| Require(t, err) | ||
| _, err = EnsureTxSucceeded(ctx, builder.L1.Client, tx) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here, you can look at the receipt, search for the event SequencerBatchDelivered and extract from it seqMessageIndex. Then you can wait for this specific batch to be received instead of waiting for a new batch to be received
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done ✅
…-uncompressed-batch-size-limit # Conflicts: # arbnode/mel/extraction/message_extraction_function.go # arbnode/mel/extraction/message_extraction_function_test.go # arbnode/mel/runner/mel.go # cmd/pruning/pruning.go
…-uncompressed-batch-size-limit # Conflicts: # cmd/replay/main.go
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #3947 +/- ##
==========================================
+ Coverage 33.35% 33.47% +0.11%
==========================================
Files 453 453
Lines 55536 55556 +20
==========================================
+ Hits 18524 18596 +72
+ Misses 33774 33729 -45
+ Partials 3238 3231 -7 |
…-uncompressed-batch-size-limit
Offline, Tsahi wrote:
I added a comment about testing. It's small but I think it's exactly the sort of thing we should start to do more to make our tests less flaky. I left the design-approved comment. After it's solved, you can let anyone approve it, dismiss my review and merge.
The issue has been solved, thus dismissing.
We extend (Arbitrum) chain config with a new field describing limit on the uncompressed batch size (previously hardcoded to 16MB).
Note
Design decision: Instead of propagating individual limit values as bare integers between components, we pass the entire
params.ChainConfigstruct. This architectural decision is crucial for maintaining chain configuration integrity. By requiring access to the specific limit field only via the full parameters object, we explicitly guarantee that the value used is always sourced directly from the authoritative chain configuration. This mitigates the risk of developers accidentally (or intentionally) passing arbitrary values that are incompatible with the chain's agreed-upon settings.This limit value is used in two places:
BatchPosterOptsandBatchPosterstructs.ParseSequencerMessage.Related changes:
ArbitrumDevTestChainConfigin inbox fuzzing testsMessageExtractorwith chain params (I preferred to do this instead of extending MEL state as suggested in the Linear ticket)pulls in OffchainLabs/go-ethereum#571
closes NIT-3121