Fix(standalone): properly compute runtime random value #863
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-bug
mrLSD
approved these changes
Nov 7, 2023
|
LGTM! |
aleksuss
pushed a commit
that referenced
this pull request
Nov 28, 2023
## Description The Near runtime has a random value available to smart contracts via a cost function. Aurora exposes that random value to EVM smart contracts in two ways: (1) via a custom precompile, and (2) via [EVM opcode 0x44](https://www.evm.codes/#44?fork=shanghai) since it was changed from `DIFFICULTY` to `PREVRANDAO` after the merge. Therefore it is important for the standalone engine to be able to correctly provide the same random value as would be present on-chain. In this PR I fix the standalone engine to be able to correctly reproduce the Near runtime random value based on the implementation present in nearcore. There will also be a follow-up PR to `borealis-engine-lib` to make use of this change in the Borealis Engine there. The random value is computed as `sha256(block_random_value || action_hash)` where the `block_random_value` comes from the protocol-level VRF (this was the value which previously we were using directly) and the `action_hash` is derived from the (`FunctionCall`) `Action` that is being executed in the Near runtime. To have the `action_hash` available to the standalone engine I am adding a new field to `TransactionMessage` which stores this value. In the tests the `action_hash` field is populated in a reasonable way, but not exactly as it would be in nearcore because there is no actual `Action` (we skip straight to the Wasm execution). However, in the follow-up PR in `borealis-engine-lib` the field will be populated from the Near data. Once this change is made, it will fix a bug in Borealis Engine where it was not correctly reproducing the execution of contracts involving randomness. ## Performance / NEAR gas cost considerations N/A : change is to standalone engine only. ## Testing The test for the random precompile has been updated to reflect this change. A test related to tracing is also changed to no longer depend on the randomness precompile because the test did not rely on the specifics of which precompile was used and now using randomness in the tests has extra setup steps.
Merged
aleksuss
added a commit
that referenced
this pull request
Nov 28, 2023
## [3.4.0] 2023-11-28 ### Additions - Added a possibility to pass initialize arguments in json format to the `new` transaction by [@aleksuss]. ([#871]) - The `SubmitResult` was made available for `ft_on_transfer` transactions in the standalone engine by [@birchmd]. ([#869]) - The order of producing the exit precompile and XCC promises has been changed to sequential by [@birchmd]. ([#868]) ### Changes - Removed the code hidden behind the feature that isn't used anymore by [@joshuajbouw]. ([#870]) - The logic of unwrapping wNEAR has been changed to the Bridge's native by [@birchmd]. ([#867]) - Bumped the `near-workspaces` to 0.9 by [@aleksuss]. ([#862]) ### Fixes - Add a method for upgrading XCC router contract by [@birchmd]. ([#866]) - Fixed a potential panic in the `ExitToNear` precompile by [@guidovranken]. ([#865]) - Fixed a behaviour when the `ft_transfer` could occur before the `near_withdraw` by [@birchmd]. ([#864]) - Fixed correctness of reproducing the NEAR runtime random value in the standalone engine by [@birchmd]. ([#863]) [#862]: #862 [#863]: #863 [#864]: #864 [#865]: #865 [#866]: #866 [#867]: #867 [#868]: #868 [#869]: #869 [#870]: #870 [#871]: #871 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Michael Birch <michael.birch@aurora.dev> Co-authored-by: Guido Vranken <guidovranken@users.noreply.github.com> Co-authored-by: Joshua J. Bouw <joshua@aurora.dev>
aleksuss
added a commit
that referenced
this pull request
Nov 28, 2023
## [3.4.0] 2023-11-28 ### Additions - Added a possibility to pass initialize arguments in json format to the `new` transaction by [@aleksuss]. ([#871]) - The `SubmitResult` was made available for `ft_on_transfer` transactions in the standalone engine by [@birchmd]. ([#869]) - The order of producing the exit precompile and XCC promises has been changed to sequential by [@birchmd]. ([#868]) ### Changes - Removed the code hidden behind the feature that isn't used anymore by [@joshuajbouw]. ([#870]) - The logic of unwrapping wNEAR has been changed to the Bridge's native by [@birchmd]. ([#867]) - Bumped the `near-workspaces` to 0.9 by [@aleksuss]. ([#862]) ### Fixes - Add a method for upgrading XCC router contract by [@birchmd]. ([#866]) - Fixed a potential panic in the `ExitToNear` precompile by [@guidovranken]. ([#865]) - Fixed a behaviour when the `ft_transfer` could occur before the `near_withdraw` by [@birchmd]. ([#864]) - Fixed correctness of reproducing the NEAR runtime random value in the standalone engine by [@birchmd]. ([#863]) [#862]: #862 [#863]: #863 [#864]: #864 [#865]: #865 [#866]: #866 [#867]: #867 [#868]: #868 [#869]: #869 [#870]: #870 [#871]: #871 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Michael Birch <michael.birch@aurora.dev> Co-authored-by: Guido Vranken <guidovranken@users.noreply.github.com> Co-authored-by: Joshua J. Bouw <joshua@aurora.dev>
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 Near runtime has a random value available to smart contracts via a cost function. Aurora exposes that random value to EVM smart contracts in two ways: (1) via a custom precompile, and (2) via EVM opcode 0x44 since it was changed from
DIFFICULTYtoPREVRANDAOafter the merge. Therefore it is important for the standalone engine to be able to correctly provide the same random value as would be present on-chain.In this PR I fix the standalone engine to be able to correctly reproduce the Near runtime random value based on the implementation present in nearcore. There will also be a follow-up PR to
borealis-engine-libto make use of this change in the Borealis Engine there.The random value is computed as
sha256(block_random_value || action_hash)where theblock_random_valuecomes from the protocol-level VRF (this was the value which previously we were using directly) and theaction_hashis derived from the (FunctionCall)Actionthat is being executed in the Near runtime. To have theaction_hashavailable to the standalone engine I am adding a new field toTransactionMessagewhich stores this value.In the tests the
action_hashfield is populated in a reasonable way, but not exactly as it would be in nearcore because there is no actualAction(we skip straight to the Wasm execution). However, in the follow-up PR inborealis-engine-libthe field will be populated from the Near data. Once this change is made, it will fix a bug in Borealis Engine where it was not correctly reproducing the execution of contracts involving randomness.Performance / NEAR gas cost considerations
N/A : change is to standalone engine only.
Testing
The test for the random precompile has been updated to reflect this change. A test related to tracing is also changed to no longer depend on the randomness precompile because the test did not rely on the specifics of which precompile was used and now using randomness in the tests has extra setup steps.