# EPF5 Week2 Update

## This week updates

This week, I dedicated my efforts to learning about three Ethereum execution clients: OpenEthereum, Erigon, and Reth. Specifically, I delved into their processes for generating and retrieving data using the `trace_filter` JSON-RPC.

In OpenEthereum, you can activate the online tracing functionality by using the command-line parameter `--tracing on`. This feature writes the data to a separate Leveldb table. When querying the data, you can directly access the results from Leveldb without relying on the state database and transaction replaying. This boosts data retrieval speed and eliminates the need for dependence on the state database. While it performs well during querying, bear in mind that if there are any errors in the generated tracing code, you will have to delete the traced data that has already been generated; otherwise, the client will utilize incorrect data.

Erigon, much like OpenEthereum, operates in a similar manner by storing its results in a separate Mdbx table.

Reth, on the other hand, does not have a separate storage mechanism for trace data. It instead follows a similar approach to Geth's `debug_traceTransaction` by replaying transactions based on the state database.

BTW, this week two PRs on Reth were merged(related to trace RPC):

- [fix(rpc/trace): include block rewards in trace_filter rpc by jsvisa · Pull Request #8868 · paradigmxyz/reth](https://github.com/paradigmxyz/reth/pull/8868)
- [feat: calc block base reward use block number only by jsvisa · Pull Request #8876 · paradigmxyz/reth](https://github.com/paradigmxyz/reth/pull/8876)

## Next week plans

Moving forward, my focus for next week will be on the design of trace data structures in OpenEthereum/Erigon. I plan to investigate how to initiate trace data generation in Geth and devise an appropriate data storage solution to effectively handle it.