Cryptographic operations not via crypto backend

[han0110]

While running some benchmark I found OpenVM's guest has much longer trace than other zkVMs, after digging I found there are some expensive cryptographic operations not covered by revm_precompile::interface::Crypto or alloy_consensus::crypto::CryptoProvider (OpenVM uses the crypto backend instead of crate patching):

1. verify_and_compute_sender in reth-stateless - Which uses k256 or secp256k1 to do ECDSA verification
   This blowup the trace of normal block because every tx has the sig to be verified.
2. Directly usage of sha256 (could be negligible)

• ethereum_hashing::Sha256 impl
• alloy_eips::eip7685::Requests::requests_hash
• stateless_validator_common::compute_requests_hash

For 1. we could probably bring back the crate patching as a short term solution, for 2. it seems there is no simple fix for now.

[jsign]

@han0110, I think 1. was fixed by @hecmas in Reth recently and will be solved here whenever a new Reth tag is done. paradigmxyz/reth#21436

[jsign]

Reg 2., I think we might need to include some CryptoProvider-ish similar abstraction to ethereum_hashing and stateless_validator_common.

For the former, we have some fork I created a while ago that I think requires some cleanup-ish maybe and we can extend to do it (I think this will depend more on ourselves medium/long term until we can upstream). Maybe as part of the bigger #8 (which IIRC requires more Lighthouse patching). After maybe we come up with a whole set of changes on Lighthouse crates, we can push to upstream them in their "final form".

For stateless_validator_common, I think we might need to create some general CryptoProvider abstraction to allow both Reth and Ethrex. For Reth would maybe just be using CrytoProvider as an impl (so mostly a proxy) and for Ethrex we could ask them to implement what we need. So kind of doing our own standarized "CryptoProvider" for the standarized-precompiles.

Thinking out loud a bit... not sure if everything here makes sense.

[han0110]

@han0110, I think 1. was fixed by @hecmas in Reth recently and will be solved here whenever a new Reth tag is done. paradigmxyz/reth#21436

Ah nice, hope I knew this earlier. (then I think #21 is not necessary, let's just wait for next reth release!)