feat(openvm): add precompile patches

[jonathanpwang]

This PR adds the necessary guest setup and patches to trigger all OpenVM custom instructions and patches for ETH block validation. Updates to openvm v1.4.0.

We currently patch revm to handle pre-compiles, but in a subsequent PR we will switch to using the new CryptoProvider trait to be able to directly use upstream revm.

I was not able to include the openvm ruint patch because it requires version to be fixed to v1.14.0 but some other risc0 packages seem to require v1.15^. From previous profiling, the ruint patch is not one of the most significant patches, so it's okay to skip it for now (although performance is still best with it).

We note that currently the stateless_validation function has a significant performance degradation because the conversion from execution witness to MPT in the guest program is very unoptimized, compared to our current deserialization approach:
Flamegraphs to be updated but we believe the performance degradation remains

• deserialization approach (faster) benchmark:
  
  The flamegraph is weighted by number of AIR trace cells, not instructions, per call stack. source

• stateless_validation approach (slower) benchmark run from this branch:
  
  Observe the large portion spent on StatelessTrie::new(). source

[jsign]

Will move out of draft after openvm v1.2.1 is released (it includes the k256 patch and other devex features to make patching easier).

@jonathanpwang, I see you released v1.3.0 a while ago -- could you rebase so we can consider merging this? I'm quite interested in giving it a spin for benchmarks.

Also, we changed to a new MPT from Risc0 and more optimized inputs (here and later here), so I'm curious how this now looks in your flamegraphs if you can re-run them 🙏

[jonathanpwang]

@jonathanpwang, I see you released v1.3.0 a while ago -- could you rebase so we can consider merging this? I'm quite interested in giving it a spin for benchmarks.

Also, we changed to a new MPT from Risc0 and more optimized inputs (here and later here), so I'm curious how this now looks in your flamegraphs if you can re-run them 🙏

Will do. Yes I saw the MPT and was interested to try.

[jonathanpwang]

@jsign I've updated to OpenVM v1.4.0.

I wasn't able to test it directly in the repo yet because the readme instructions:

cd crates/witness-generator-cli
cargo run --release -- tests --include Prague --include cold

gave me error

Error: Failed to build EEST generator

Caused by:
    0: Failed to execute download script
    1: No such file or directory (os error 2)

By the way, with OpenVM v1.4.0, the CLI and SDK both come with GPU support if feature cuda is enabled: https://docs.openvm.dev/book/getting-started/install#installation-with-nvidia-gpu-support
I haven't looked into how this is handled in ere-host yet, so just mentioning it's an option. cc @han0110

[jsign]

@jonathanpwang, thanks very much!

Ah, regarding witness-generator-cli we should fix the docs -- should be ran at the workspace level, not crate level. Standing in root of the repo, running RAYON_NUM_THREADS=10 RUST_LOG=info cargo run --release -p witness-generator-cli -- tests --include 10M- --include Prague will generate all 10M gas tests (as an example).

Reg OpenVM v1.4.0, we just merged the support for ere today in eth-act/ere#113 :) We have to update the ere dep in this repo, and should be good to go.

I'm OOO until Monday, so I can do this as soon as I come back.

[han0110]

@jonathanpwang Thanks for upgrading the patching, just ran locally and the performance looks nice!

But I found that the ruint patch is not used, because the alloy-trie@0.9.0 requires nybbles@0.4.0 that requires ruint@1.15.0, and in OpenVM's guest lib the ruint is 1.14.0, so the patching is ignored.

Not sure how much it affects the performance, but I think we could integrate the current patching first, and upgrade in future PR to get the fully patched performance.

[jonathanpwang]

@han0110 yes I noted it in the PR description. I tried to patch to 1.16 but there was some change that requires const fn and it was not the most straightforward. I believe it doesn't affect performance too much because it's all in revm_interpreter::arithmetic and even there most of the instructions are associated with handling the stack

[han0110]

Sorry I missed that part about ruint patching in the PR description 🙏

I believe it doesn't affect performance too much because it's all in revm_interpreter::arithmetic and even there most of the instructions are associated with handling the stack

Got it, sounds good!

[jsign]

The CI job failing is expected since this is an external branch PR, so the GH repo secrets are guarded. Thanks very much again @jonathanpwang.

[kevaundray]

We note that currently the stateless_validation function has a significant performance degradation because the conversion from execution witness to MPT in the guest program is very unoptimized, compared to our current deserialization approach:

@jonathanpwang do you have a link to where this is done in an optimized way?

[jonathanpwang]

@jonathanpwang do you have a link to where this is done in an optimized way?

The latest is https://github.com/axiom-crypto/openvm-reth-benchmark/tree/main/crates/executor/client which uses a new MPT.

Let me update everything to reth 1.7.0 to do a fair comparison.

BTW (not really the right place to mention) - if this repo could update reth to 1.7.0, then I will prepare another PR to switch to CryptoProvider.

[jsign]

@jonathanpwang, I'm updating our fork to latest Reth in #182 -- but found a problem with OpenVM compiler, more see comment https://github.com/eth-act/zkevm-benchmark-workload/pull/182/files#r2337888495.