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 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.
mrLSD
commented
8 months ago
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.