Impl block prevrandao

[zjb0807]

Closes: #2693

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 64.89%. Comparing base (1bead11) to head (2967694). Report is 1 commits behind head on master.

Files	Patch %	Lines
modules/evm/src/lib.rs	0.00%	3 Missing :warning:
modules/support/src/mocks.rs	0.00%	3 Missing :warning:
modules/evm/src/runner/stack.rs	0.00%	2 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #2736 +/- ## ========================================== - Coverage 65.35% 64.89% -0.47% ========================================== Files 69 66 -3 Lines 9797 8563 -1234 ========================================== - Hits 6403 5557 -846 + Misses 3394 3006 -388 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ermalkaleci]

I have 2 concerns with this:

1. Is this going to work for tx executive on_initialize?
2. This is a read and doing hashing every time is called. Any risk this can be abused?

[xlc]

1. Is this going to work for tx executive on_initialize?

An insecure random value that's based on parent block hash will be provided. But there are only few limited ways to trigger EVM call in on_initialize including scheduler and XCM. XCM processing will be moved out from on_initialize in future and scheduler usage is governance protected so it should be fine.

2. This is a read and doing hashing every time is called. Any risk this can be abused?

I guess we can cache the value? Otherwise we need to ensure we charge enough gas.

[ermalkaleci]

1. Is this going to work for tx executive on_initialize?

An insecure random value that's based on parent block hash will be provided. But there are only few limited ways to trigger EVM call in on_initialize including scheduler and XCM. XCM processing will be moved out from on_initialize in future and scheduler usage is governance protected so it should be fine.

2. This is a read and doing hashing every time is called. Any risk this can be abused?

I guess we can cache the value? Otherwise we need to ensure we charge enough gas.

I think we need to be careful with this, at least enable only on mandala & karura first

[xlc]

It is known prevrandao have its limitation and cannot be used solely for cases requires strong random number, extra randomness source are required so I am not too worried about abuse.