Comparative Analysis: debug_executionWitness Latency

This document presents the results of measurements conducted to analyze the latency improvements of the debug_executionWitness RPC method across different configurations.

Configurations

• Pre-Serialized (added in PR #5956): Execution witnesses are generated during payload execution, converted to RpcExecutionWitness, and stored as pre-serialized JSON bytes in the database. On read, the bytes are parsed directly to serde_json::Value without any additional traversal or serialization.
• Pre-Generated: Execution witnesses are generated during payload execution and stored in the database (but require encode_subtrie() traversal and serialization on each read).
• On-Demand: Execution witnesses are generated when calling debug_executionWitness.

Measurements

Conclusions

Pre-Serialized vs On-Demand

The average latency drops from 242 ms (on-demand) to 94 ms (pre-serialized), representing an improvement of approximately 61%. Median latency shows a similar improvement, decreasing from 224 ms to 91 ms.

Pre-Serialized vs Pre-Generated

The average latency drops from 131 ms (pre-generated) to 94 ms (pre-serialized), representing an additional improvement of approximately 28%. This improvement comes from eliminating the encode_subtrie() depth-first traversal that was previously performed on every read to convert ExecutionWitness to RpcExecutionWitness.

Pre-Generated vs On-Demand

The average latency drops from 242 ms (on-demand) to 131 ms (pre-generated), representing an improvement of approximately 46%. Median latency shows a similar improvement, decreasing from 224 ms to 130 ms.

Overall

Pre-serialized execution witnesses exhibit the tightest latency distribution. On-demand requests frequently experience high-latency spikes due to witness generation at request time. Pre-generating and pre-serializing execution witnesses during payload execution effectively eliminates most of these spikes and results in more predictable response times.

How These Measurements Were Done

These metrics were obtained from an ethrex node synced to the Ethereum mainnet.

Each configuration was measured over a contiguous range of blocks, and latency was recorded for each request.

How to Get Metrics

1. Ensure the node is synced.
   Use the --precompute-witnesses flag to generate and store execution witnesses upon receiving a newPayload message.

2. Enable debug logging for ethrex-replay by editing src/main.rs:21:

   add_directive(Directive::from(tracing::Level::DEBUG))
   

3. Run ethrex-replay using the --endless flag:

   cargo run -r -- blocks --endless --rpc-url [RPC_URL]
   

4. Filter logs to capture execution witness latency:

   cargo run -r -- blocks --endless --rpc-url [RPC_URL] 2>&1 | grep --line-buffered 'Got execution witness for block' | tee execution_witness_times.txt
   

5. Post-process the captured measurements to compute min, max, average, and median latencies.

Appendix

Full Measurement Data

Pre-Serialized

Total blocks analyzed: 199

Pre-Generated

Total blocks analyzed: 176

On-Demand

Total blocks analyzed: 176