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_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.
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