-
Notifications
You must be signed in to change notification settings - Fork 100
feat: move state/receipt building to new method #308
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
✅ Heimdall Review Status
|
Moves transaction processing logic of build_pending_state to a new struct. Also separates out reusing a cached execution from executing using the EVM. This also removes block_hash from receipts and transactions which matches the spec and removes the need for calculating a useless block hash for every flashblock. The next step is to move the for loop into this struct which will return an iterator of results. Using this, we'll be able to prewarm accessed addresses using FALs and eventually process transactions in parallel. Moving execution to a new struct allows us to implement a trait for building flashblocks and switch out different implementations (prewarming, parallel, sequential).
658461f to
bf20816
Compare
refcell
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.
If we're going to refactor the pending logic into a struct, could we take the extra step and move it into a new module to try to make this code a bit easier to read?
|
Yup, good idea! Made a few changes: moved the state builder it to a new |
refcell
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.
Looks great thanks @meyer9
Moves transaction processing logic of build_pending_state to a new struct. Also separates out reusing a cached execution from executing using the EVM.
This also removes block_hash from receipts and transactions which matches the spec and removes the need for calculating a useless block hash for every flashblock.
The next step is to move the for loop into this struct which will return an iterator of results.
Using this, we'll be able to prewarm accessed addresses using FALs and eventually process transactions in parallel. Moving execution to a new struct allows us to implement a trait for building flashblocks and switch out different implementations (prewarming, parallel, sequential).