Keccak pipelined calculator

[Scooletz]

This PR proposes a new way of handling Instruction.KECCAK256, when it's followed by some instructions that are not result dependent (no immediate pop of the value). It does it by moving the computation to a separate component with a separate thread to compute and placing a special marker in EvmStack, so that when the value needs to be retrieved, it's retrieved from the OffHeapStack. You can think of it as a CPU pipeline enabler, that does something behind the scenes and materialized value on the stack when ready.

The preliminary benchmarks, that compare actual execution with the offloading, show the following difference

Method	Mean	Error	StdDev	Ratio
ValueKeccak	209.94 ns	2.212 ns	2.069 ns	1.00
KeccakCalculator	22.80 ns	0.469 ns	0.439 ns	0.11

This, of course, does not take into consideration the overhead of checking in EvmStack whether or not the value is kept OffHeap and detecting what to do. This is just a rough estimation what could be done.

To reflect on a real example, WrappedEth was used: https://app.dedaub.com/ethereum/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2/disassembled Here are some of the sequences that followed SHA3

0x5fa: SHA3      
0x5fb: DUP2      
0x5fc: SWAP1     
0x5fd: SSTORE    

0x5bd: SHA3      
0x5be: PUSH1     0x0
0x5c0: DUP6      
0x5c1: PUSH20    0xffffffffffffffffffffffffffffffffffffffff
0x5d6: AND       
0x5d7: PUSH20    0xffffffffffffffffffffffffffffffffffffffff
0x5ec: AND       
0x5ed: DUP2      
0x5ee: MSTORE 

A terrible case:

0x6ce: SHA3      
0x6cf: SLOAD

  0x773: SHA3      
  0x774: PUSH1     0x0
  0x776: CALLER    
  0x777: PUSH20    0xffffffffffffffffffffffffffffffffffffffff
  0x78c: AND       
  0x78d: PUSH20    0xffffffffffffffffffffffffffffffffffffffff
  0x7a2: AND       
  0x7a3: DUP2      
  0x7a4: MSTORE

Changes

• List the changes

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Optional. Remove if not applicable.

Documentation

Requires documentation update

• Yes
• No

If yes, link the PR to the docs update or the issue with the details labeled docs. Remove if not applicable.

Requires explanation in Release Notes

• Yes
• No

If yes, fill in the details here. Remove if not applicable.

Remarks

Optional. Remove if not applicable.

[Scooletz]

Comparing time to offload 20ns with the actual computation 200ns and the cost of a regular opcode 2ns makes this PR not worthy to chase. Still, memoizing Keccaks is worth considering.