# Week 21 Week spent debugging implementation of `debug_executionWitness` and adding benchmarking metrics. Next week I'll write the final report and work on presentation. ## `debug_executionWitness` Got a new (faster) machine to sync Erigon. Synced in one day, great. Started to test out the code changes for execution witness. Was able to test the code written last week for the `debug_executionWitness` response, it worked for all fields except the `state` (so it worked for generating the data for `codes`, `headers` and `keys`) ... `State` contains the trie nodes needed for block execution. The current codepath for the stateless execution of blocks is not compatible with RPC as it's currently implemented. I ended up [opening an issue (with some of my analysis)](https://github.com/erigontech/erigon/issues/17824#issuecomment-3508308670) for this as it's also exposed through the existing `eth_getWitness` rpc method that is implemented (**this is not the same as `debug_executionWitness` btw**). I spent multiple days trying to debug the issue, trying various versions to try to bisect where the error happened. The PR that added it was [before version 3.0](https://github.com/erigontech/erigon/pull/12847) so couldn't go that far as it would be a hard diff and snapshots would not work, but tried when they [added p2p support]( https://github.com/erigontech/erigon/pull/16570) and other recent changes that fixed code in [similar codepaths](https://github.com/erigontech/erigon/pull/17687). So this was a bit sad, I was hoping to be able to finish to also get a PR out as part of this fellowship and not purely do "research". Still one week left, so I'll be responsive if they give me pointers on the issue. ### Benchmarking Time was spend getting some more metrics for the benchmarking. Sadly there is no good standard for the instructions counts so it's mostly an indicator and not the full on truth. - OpenVM (what we use) - Does not expose the [cycle count](https://docs.openvm.dev/specs/reference/rust-frontend#std-support) atm, but in [this PR](https://github.com/2xic/erigon-risc-v-executable-proof-sourcing/pull/11) we just do an estimate based on the number of instructions in the binary (and since we don't do functions calls etc, that is likely good enough) - I also realized we didn't benchmark with STARK proofs, just app proofs, it didn't change the results much, but thought I would mention it. - SP1 - Does expose the [instructions count + syscall count](https://github.com/succinctlabs/sp1/blob/82f63ebadd12ca4e6ae3b333996016b5ad6b8804/crates/core/executor/src/report.rs#L28-L40) (instructions = RISC-V to be clear). - RISC0 - Only exposes the number of [cycles](https://github.com/risc0/risc0/blob/main/risc0/zkvm/src/host/client/prove/mod.rs#L46-L48) which should [somewhat map to an instruction](https://github.com/risc0/risc0/blob/277d3a61/website/api/zkvm/optimization.md#most-risc-v-operations-take-exactly-one-cycle). These will be published part of the presentation and report next week. [See Github](https://github.com/eth-protocol-fellows/cohort-six/blob/master/development-updates.md#cohort-end). ## Next week For the final week of the cohort we need to prepare our presentation and the final report. I'll also follow up on the issue I opened against Erigon.