Fix(standalone): Do not eagerly commit transactions to the DB #825
Conversation
This file contains 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
birchmd
added
C-enhancement
RomanHodulak
approved these changes
Aug 23, 2023
birchmd
added a commit
that referenced
this pull request
Aug 23, 2023
## Description The [Borealis refiner](https://github.com/aurora-is-near/borealis-engine-lib/tree/main/refiner-lib) was experiencing a performance issue where it would become very slow at processing blocks. Profiling revealed the reason was increasing time to look up the `ENGINE_STATE` key when replaying transactions (this replay is necessary to correctly process batch transactions on Near). After some investigation, we realized the cause of this slow lookup was due to that key being constantly written and deleted by every transaction. The reason for this churn is because the Engine logic was changed to automatically migrate its state, but of course old transactions did not have that logic and therefore the replay would compute an incorrect state diff relative to what is reported in the Near block. In such cases the replay changes to the DB are deleted and the correct diff from the Near block is used instead. To avoid this DB churn, this PR changes the standalone engine so that it will not commit to the DB right away when consuming a block. Instead it is now up to clients of the standalone engine to commit the changes themselves (after performing any validation). A PR on Borealis Refiner will make that change there after this PR is merged. Note this does not address the larger issue of replay accuracy. In theory the Borealis Refiner should use the code that existed at the time when replaying an old transaction. However, this is not so easy to accomplish which is why we are proposing this solution instead. It is an immediate fix to the performance issue that can keep the Refiner running while we address the more fundamental problem. ## Performance / NEAR gas cost considerations No impact to on-chain Aurora contract; changes to standalone only. ## Testing Updates to existing tests
Merged
birchmd
added a commit
that referenced
this pull request
Aug 25, 2023
### Fixes - Updated sputnikvm dependency with bugfix in the `returndatacopy` implementation and a performance improvement in accessing EVM memory. (#826) ### Changes - BREAKING: `engine-standalone-storage` no longer automatically writes to the DB when `consume_message` is called. It is up to downstream users of the library to commit the diff (after doing any validation for correctness). (#825) ### Additions - New crate for the so-called "hashchain" implementation. It will enable verification of Aurora blocks by light clients in the future. (#816) --------- Co-authored-by: Oleksandr Anyshchenko <oleksandr.anyshchenko@aurora.dev>
aleksuss
pushed a commit
that referenced
this pull request
Aug 30, 2023
## Description The [Borealis refiner](https://github.com/aurora-is-near/borealis-engine-lib/tree/main/refiner-lib) was experiencing a performance issue where it would become very slow at processing blocks. Profiling revealed the reason was increasing time to look up the `ENGINE_STATE` key when replaying transactions (this replay is necessary to correctly process batch transactions on Near). After some investigation, we realized the cause of this slow lookup was due to that key being constantly written and deleted by every transaction. The reason for this churn is because the Engine logic was changed to automatically migrate its state, but of course old transactions did not have that logic and therefore the replay would compute an incorrect state diff relative to what is reported in the Near block. In such cases the replay changes to the DB are deleted and the correct diff from the Near block is used instead. To avoid this DB churn, this PR changes the standalone engine so that it will not commit to the DB right away when consuming a block. Instead it is now up to clients of the standalone engine to commit the changes themselves (after performing any validation). A PR on Borealis Refiner will make that change there after this PR is merged. Note this does not address the larger issue of replay accuracy. In theory the Borealis Refiner should use the code that existed at the time when replaying an old transaction. However, this is not so easy to accomplish which is why we are proposing this solution instead. It is an immediate fix to the performance issue that can keep the Refiner running while we address the more fundamental problem. ## Performance / NEAR gas cost considerations No impact to on-chain Aurora contract; changes to standalone only. ## Testing Updates to existing tests
mrLSD
approved these changes
Nov 17, 2023
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.
Description
The Borealis refiner was experiencing a performance issue where it would become very slow at processing blocks. Profiling revealed the reason was increasing time to look up the
ENGINE_STATEkey when replaying transactions (this replay is necessary to correctly process batch transactions on Near). After some investigation, we realized the cause of this slow lookup was due to that key being constantly written and deleted by every transaction. The reason for this churn is because the Engine logic was changed to automatically migrate its state, but of course old transactions did not have that logic and therefore the replay would compute an incorrect state diff relative to what is reported in the Near block. In such cases the replay changes to the DB are deleted and the correct diff from the Near block is used instead.To avoid this DB churn, this PR changes the standalone engine so that it will not commit to the DB right away when consuming a block. Instead it is now up to clients of the standalone engine to commit the changes themselves (after performing any validation). A PR on Borealis Refiner will make that change there after this PR is merged.
Note this does not address the larger issue of replay accuracy. In theory the Borealis Refiner should use the code that existed at the time when replaying an old transaction. However, this is not so easy to accomplish which is why we are proposing this solution instead. It is an immediate fix to the performance issue that can keep the Refiner running while we address the more fundamental problem.
Performance / NEAR gas cost considerations
No impact to on-chain Aurora contract; changes to standalone only.
Testing
Updates to existing tests