-
Notifications
You must be signed in to change notification settings - Fork 118
fix(levm)!: fix jumpdests for large initcodes #5254
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
Conversation
Lines of code reportTotal lines added: Detailed view |
crates/storage/store_db/rocksdb.rs
Outdated
|
|
||
| for (code_hash, code) in update_batch.code_updates { | ||
| let mut buf = Vec::with_capacity(6 + code.bytecode.len() + 2 * code.jump_targets.len()); | ||
| let mut buf = Vec::with_capacity(6 + code.bytecode.len() + 4 * code.jump_targets.len()); |
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.
I think it's better to use size_of to avoid hard-coding this lenght
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.
Improved in 9d129ce
crates/storage/store_db/rocksdb.rs
Outdated
| .chunks_exact(2) | ||
| .map(|c| u16::from_le_bytes([c[0], c[1]])) | ||
| .chunks_exact(4) | ||
| .map(|c| u32::from_le_bytes([c[0], c[1], c[2], c[3]])) |
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.
Talking with @Oppen, we think that it's better to encode the jump_target in RLP, which will be smaller than 32 bits for the common case.
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.
Better is a strong word for any use of RLP. But in the tradeoff IO probably wins, and RLP is better for IO than always using all the bytes.
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 in 084c8e2
Benchmark Results ComparisonNo significant difference was registered for any benchmark run. Detailed ResultsBenchmark Results: BubbleSort
Benchmark Results: ERC20Approval
Benchmark Results: ERC20Mint
Benchmark Results: ERC20Transfer
Benchmark Results: Factorial
Benchmark Results: FactorialRecursive
Benchmark Results: Fibonacci
Benchmark Results: FibonacciRecursive
Benchmark Results: ManyHashes
Benchmark Results: MstoreBench
Benchmark Results: Push
Benchmark Results: SstoreBench_no_opt
|
| pub bytecode: Bytes, | ||
| // TODO: Consider using Arc<[u16]> (needs to enable serde rc feature) | ||
| pub jump_targets: Vec<u16>, | ||
| // TODO: Consider using Arc<[u32]> (needs to enable serde rc feature) |
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.
Can we add a comment here or anywhere you consider convenient about the reason why we use 32 bits? So nobody changes it to u16 back again
If you want you can link EIP-3860 but it's not necessary
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.
No, it would be a good idea to link to the EIP. Also to the failing EEST test.
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.
When in doubt, overcommenting is better than undercommenting. Don't let school tell you otherwise.
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.
Added comment in da77868
Caution
This changes the serialization of
Code, and thus requires re-syncing.Motivation
While executing the state tests in debug mode, a debug assert was triggered.
The calculation of valid jumpdests assumes the code will be less than 2^16 bytes in length, however this isn't true before Shanghai.
Description
This PR adds support for up to 2^32 bytes of initcode.