# Week 19

This week, progress was made on adding more alternative clients to compare against. We added some more metrics and tried to get Reth up and running, ran into issues and are now thinking about just implementing the missing method into Erigon.

## More clients to compare against
We now have support for [RSP](https://github.com/succinctlabs/rsp) and [ZETH](https://github.com/boundless-xyz/zeth/) backends. Both use Reth as the execution VM, but they use different proof backends. One is SP1 and the other is RISC0.

We still have some problems getting the benchmarking clients to generate proof. There are a few ways of attacking this, I think
- We can move the proof generation to happen on GPUs.
- We can find a smaller block and generate proofs from that.

### Erigon `debug_executionWitness`
I was last week trying to get a Reth client up and running, but then ran into [this issue](https://github.com/paradigmxyz/reth/issues/19244). Since the issue has not had any activity, I'm thinking that I will just implement it into Erigon myself.

For context the change to geth [was quite small](https://github.com/ethereum/go-ethereum/pull/32216) and as far as I have seen Erigon has a similar interface which I can reuse. This would allow me to both get the `debug_executionWitness` for my benchmarking and potentially get a upstream change merged as Erigon doesn't currently have this rpc method.

## Improved metrics
We added some more metrics to our transpilation to get more information about the RPC time and the proof generation.

| Block | Transaction Count | Total Instructions | Transpile Time (ms) | Assembly Time (ms) | Proof Build Time (ms) | Proof Time (ms) | Total Time (ms) |
| :------- | ----------------: | -----------------: | ------------------: | -----------------: | --------------------: | --------------: | --------------: |
| 22920995 | 99 | 364627 | 144755 | 996 | 33929 | 160266 | 330689 |
| 22940999 | 281 | 981816 | 944865 | 2219 | 70788 | 445858 | 1394061 |
| 22940995 | 211 | 838804 | 592874 | 2201 | 62879 | 291285 | 887018 |

Most of the overhead is on the proof time, but we can also see a big overhead is on the transpilation itself. Probably larger than it should be ... Need to investigate that.

## Other things I looked into this week
Some resources I looked at this week
- https://zkevm.ethereum.foundation/
- Has some good content, but what I found most interesting was the `Ethereum Client Readiness for zkVM Integration` part.
- https://blog.openvm.dev/openvm-gpu
- In case we might need to add GPU mode for comparing against the various implementations.

## Next week
**Must:**
- Need to get the proof generation working for the other benchmark clients
- Either by having proofs be generated from the GPU, running on smaller blocks or something I haven't yet considered.
- Implement a version of `debug_executionWitness` in Erigon.

**Should:**
- Get a sense of how much apples to apples we are comparing
- Probably should complete the [proof comparison](https://hackmd.io/@2xic/SJstINCKxx) writeup I started on. Our approach and the stateless one has completely different tradeoffs and assumptions.
- What would be the overhead for us to do more realistic transpilation? Some of our opcodes are currently being "dummy" transpiled and just peeking at the execution results.
- Look at why we spend so much time on the transpilation step.
- Start thinking about the EPF day presentation and the [final report](https://notes.ethereum.org/@MarioHavel/cohort6finale)