-
Notifications
You must be signed in to change notification settings - Fork 55
refactor(levm): use ethrex account types in LEVM #2629
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
Merged
Merged
Conversation
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
Lines of code reportTotal lines added: Detailed view
|
Benchmark Results ComparisonPR ResultsBenchmark Results: Factorial
Benchmark Results: Factorial - Recursive
Benchmark Results: Fibonacci
Benchmark Results: ManyHashes
Benchmark Results: BubbleSort
Benchmark Results: ERC20 - Transfer
Benchmark Results: ERC20 - Mint
Benchmark Results: ERC20 - Approval
Main ResultsBenchmark Results: Factorial
Benchmark Results: Factorial - Recursive
Benchmark Results: Fibonacci
Benchmark Results: ManyHashes
Benchmark Results: BubbleSort
Benchmark Results: ERC20 - Transfer
Benchmark Results: ERC20 - Mint
Benchmark Results: ERC20 - Approval
|
EF Tests Comparison
|
tomip01
reviewed
Apr 29, 2025
tomip01
approved these changes
Apr 29, 2025
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.
Very good! Just one suggestion
JulianVentura
suggested changes
Apr 29, 2025
crates/vm/levm/src/opcode_handlers/stack_memory_storage_flow.rs
Outdated
Show resolved
Hide resolved
JulianVentura
approved these changes
Apr 29, 2025
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.
Motivation
Description
get_account_info
is nowget_account
because we also need the code of the account andAccountInfo
has thecode_hash
only. This makes changes on every structure that implementsLevmDatabase
trait.StorageSlot
that had thecurrent_value
andoriginal_value
of a storage slot (original_value
being the value pre-tx) I had to make some changes to logic and store those original values into an auxiliaryHashMap
onVM
.get_original_storage()
for getting the original storage value.Storage changes deep description:
original_value
we will look up in the original values stored in the VM struct. These intends to store the storage values previous to starting the execution of a particular transaction. For efficiency and performance, we only update this new field when actually getting the original value.CacheDB
could have a lot of accounts with their storage but theVM.storage_original_values
will start empty on every transaction. WhenSSTORE
opcode is executed and we actually care for the original value of a storage slot we will look atstorage_original_values
and it won’t find it (the first time), so then it will see what the value in theCacheDB
is, and if it’s not there it will finally check on the actualDatabase
. After retrieving the value, it will be added tostorage_original_values
, but ONLY the FIRST time. That means that if the value keeps on changing theoriginal_value
won’t change because once it’s added it’s not modified.Closes #issue_number