feat(l1): cache block hash lookup for BLOCKHASH opcode

[fmoletta]

Motivation
Addressing #5344 by using the existing block_hash_cache to store block hashes looked up during BLOCKHASH opcode execution to speed up subsequent lookups

Description

• Add interior mutability to block_hash_cache (HashMap -> Arc<Mutex>)
• Insert block hashes obtained during lookup to block_hash_cache (BLOCKHASH opcode)
• Use oldest cached block successor to shortcut ancestor lookup (BLOCKHASH opcode)

Benchmark Results: x33,6 improvement on BlockHash EEST gas benchmark: 1080.92 Mgas/s vs 32.18 Gas/s on main (7b4a0ba)

Closes #5344

[github-actions]

Lines of code report

Total lines added: 14
Total lines removed: 0
Total lines changed: 14

Detailed view

+--------------------------------+-------+------+
| File                           | Lines | Diff |
+--------------------------------+-------+------+
| ethrex/crates/blockchain/vm.rs | 138   | +14  |
+--------------------------------+-------+------+

[mpaulucci]

this grows infinitely?

[fmoletta]

This is only used for the BLOCKHASH opcode implementation, which checks that the requested block number is less than 256 blocks away from the current block, so it should only grow up to 256

[JereSalo]

I know the PR is not open yet but we should update this comment, right?

[fmoletta]

nice catch!

[Oppen]

I suggest we try preloading the 256 hashes in an array/vector first. For the most part they could live in memory (they take 8kiB for the canonical chain, with some extra for reorgs and forks) already, and even when they don't, the common case is blocks in the canonical chain, meaning they can be resolved with a single query to the canonical hashes table, and the rest require a bounded (65, I think, for forks starting at a non-finalized block that should be at most 64 blocks long, plus one for the intersection with the canonical chain).
That would avoid the internal management of block hashes, including the mutex, and I think would lead to overall simpler code. Iff it shows to perform poorly, I would consider something more complex than that.

[fmoletta]

I suggest we try preloading the 256 hashes in an array/vector first. For the most part they could live in memory (they take 8kiB for the canonical chain, with some extra for reorgs and forks) already, and even when they don't, the common case is blocks in the canonical chain, meaning they can be resolved with a single query to the canonical hashes table, and the rest require a bounded (65, I think, for forks starting at a non-finalized block that should be at most 64 blocks long, plus one for the intersection with the canonical chain). That would avoid the internal management of block hashes, including the mutex, and I think would lead to overall simpler code. Iff it shows to perform poorly, I would consider something more complex than that.

I implemented this on #5443 but the benchmark results are worse than this solution.
The benchmark only requests a single block hash multiple times so it makes sense that preloading all 256 won't be an improvement, but I also don't think it is very common for a contract to request so many different block hashes

[Oppen]

I suggest we try preloading the 256 hashes in an array/vector first. For the most part they could live in memory (they take 8kiB for the canonical chain, with some extra for reorgs and forks) already, and even when they don't, the common case is blocks in the canonical chain, meaning they can be resolved with a single query to the canonical hashes table, and the rest require a bounded (65, I think, for forks starting at a non-finalized block that should be at most 64 blocks long, plus one for the intersection with the canonical chain). That would avoid the internal management of block hashes, including the mutex, and I think would lead to overall simpler code. Iff it shows to perform poorly, I would consider something more complex than that.

I implemented this on #5443 but the benchmark results are worse than this solution. The benchmark only requests a single block hash multiple times so it makes sense that preloading all 256 won't be an improvement, but I also don't think it is very common for a contract to request so many different block hashes

I'd argue it doesn't really implement what I said, as it's making a get to the DB for each block, which I'm saying we should avoid. It's also using a hashmap rather than a vector, and hashing is not free either.