ef-tests: use production db setup to support heavy benchmark cases#11
Merged
Conversation
This was referenced Mar 29, 2026
Merged
670e27f to
7938012
Compare
Co-authored-by: Ignacio Hagopian <jsign.uy@gmail.com>
7938012 to
d1c52ee
Compare
Collaborator
|
added upstream helper used here |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current
ef-testscrate is used to run EEST tests and generate theExecutionWitness.In a recent PR in Reth, the database configuration for tests caps the size to 64MiB. While this makes sense for regular tests, in benchmark cases we are creating worst cases that can exceed this limit.
Concretely, I was re-filling EEST tests for even lowerish 25M gas limits and in worst-cases of bytecodes needed for non-code-chunking attacks, the witness generation failed since we need to create more than 100MiB of bytecodes which exceeds the now default 64MiB db size limit.
This PR makes a local fix for this particular need in this repo, but I think medium/long term might be better that we make this configurable in the Reth repo via params, and then simplify here.