## Week 20
Although we got some benchmarks numbers for alternative clients and made some progress on the `debug_executionWitness`, I feel a lot of time this week got lost to silly infrastructure things (issues with SP1 etc + follow from last week). Around two weeks left, need to lockin to get the last few things over the finish line.

## Benchmark of alternative clients
Finally, we got some numbers for the alternative clients. This is on mainnet for block 23174550 (as that is what I currently have a execution witness for).

| Metric | ethrex (SP1) | zeth (RISC Zero) | rsp (SP1) |
|--------|--------------|------------------|-----------|
| **Backend** | SP1 | RISC Zero | SP1 |
| **Proof Time** | 13.0 hrs | 17.7 hrs | 4.8 hrs |

One thing that surprised me was that even ethrex and rsp with the same backend had such a big difference.

Some notes on the way of getting here
- Initially as mentioned in last update, I tried to run it on GPUs. I went to https://vast.ai/ as I have used that before for GPUs. Sadly, SP1 runs certain steps through docker which conflict with Vast as it already provides server accesses through Docker ... Part of it I [could turn off](https://github.com/lambdaclass/ethrex/blob/2f3a86fe5c7da388d4b56e8dd667d657b5c1443f/crates/l2/prover/src/guest_program/build.rs#L65), but there was some things I couldn't (it was the Groth16 circuit if I recall correctly).
- After this, I thought, maybe I'll just try to run it on my desktop with GPUs. Then I ran into issues with the driver version on Linux. Fun stuff.
- I needed a beefed up machine for CPU proving. 48 CPUs and 524GB RAM.
- ```bash
> lscpu | grep -E '^Thread|^Core|^Socket|^CPU\('
CPU(s): 48
Thread(s) per core: 2
Core(s) per socket: 24
Socket(s): 1
CPU(s) scaling MHz: 64%

> free -h
total used free shared buff/cache available
Mem: 503Gi 4.0Gi 452Gi 4.5Mi 49Gi 499Gi
Swap: 4.0Gi 0B 4.0Gi

   - This specs was selected based on [this SP1 blogpost](https://www.succinct.xyz/blog-articles/introducing-sp1-reth-a-performant-type-1-zkevm-built-with-sp1). Where they mentioned they ran benchmarks on a `AWS i4g.16xlarge ` (I just ended up renting a machine from Hertzner auctions).

## Erigon `debug_executionWitness`
Reference PRs for other clients
- https://github.com/ethereum/go-ethereum/pull/32216
- https://github.com/paradigmxyz/reth/pull/9249
- https://gist.github.com/karalabe/47c906f0ab4fdc5b8b791b74f084e5f9

There has been some annoyances as Erigon has the separate database structure (snapshots + commitment). This is something I ran into earlier. Earlier in the fellowship I was fighting the same issue and my node ended up not being fully synced as it relies on the snapshots (**yeah ... that was a bad of me not letting the node sync back then.**).

The diff itself to support the endpoint should be quite small once my node is synced.
- There is already a [stateless state writer](https://github.com/erigontech/erigon/blob/fd4e3bd33b32c2cd245a3779216f2833437214cc/execution/state/stateless.go#L33) which allows constructing the trie during the block execution
- There is also a [witness implementation]( https://github.com/erigontech/erigon/blob/fd4e3bd33b32c2cd245a3779216f2833437214cc/rpc/jsonrpc/eth_call.go#L552) which does some of what we need.

Still would need to create the new endpoint and have it correctly match of the other reference clients.

## Other activities
There was a few stretch goals [from last week](https://hackmd.io/@2xic/Byy1DVtReg#Next-week). None of which made big progress this week.
- found a way to run `debug_executionWitness`
    - https://docs.zan.top/reference/debug_executionwitness
    - although it's pruned ... But works! and allows me to test against the Erigon implementation :D
- apples to apples comparison
    - I have not done anything concrete here, although it has somewhat been in the back of my mind. I think what would be interesting, but I think would be hard to get out is how many extra instructions these provers run.
    - I'm also unsure if OpenVM (our prover backend) even uses the same proving strategy as SP1. Although both are ZK, there might be tradeoffs here which I'm not aware of yet. Need more time.
- I started a bit on the final report and presentation, but will need to do more work on that the coming week
    - That said, most of the focus should still be working on completing the benchmarking and getting all the results in a better shape.

## Next week
It's basically same theme as this week, we need to push a bit more to get things over the finish line. 

**Must:**
- Get some (at least draft) PR up for `debug_executionWitness`
- Get more numbers on the alternative clients + our implementation. Better apples to apples be able to better discuss the tradeoffs. 

**Should:**
- Look at the time spent at transpilation step (see last week)
- Presentation + Final report