Ethereum Client Trace Comparisons

trace debug evm clients geth besu reth nethermind erigon

Author

Andrew Davis

Published January 21, 2026 at 07:48 AM UTC

This report compares debug_traceTransaction outputs across Ethereum execution clients to identify behavioral differences and formatting quirks.

Source: This analysis was generated using ethereum-trace-compare

Overview

• Total transactions: 501
• Skipped (client errors): 1
• Analyzed: 500
• Clients: besu, erigon, geth, nethermind, reth

Difference Types Found

These are semantic differences detected in trace outputs. High counts indicate systematic differences in how clients report EVM execution.

Client Quirk Summary

This table shows where each client differs from the majority behavior. Lower numbers indicate better conformance.

Per-Client Reports

Detailed reports for each client:

• BESU
• ERIGON
• GETH
• NETHERMIND
• RETH

Format Quirks (Not Bugs)

These are formatting differences that don't affect trace correctness. The comparison tool normalizes these before semantic comparison.

Return Value Encoding

How empty return values are represented. These are semantically equivalent.

Example (block 24281427, tx 0xbe3839523703cc914573c2a304367bff26fd6d08738389fc8d2bf857cdf3391c):

Memory Format

How memory words are formatted in structLogs.

Example (block 24281427, tx 0x584b891391ad58c565ea1bc9933b2f9b098e34d693ac8d77c465ba951ac2373a):

Storage Format

How storage keys and values are formatted. Clients differ in zero-padding.

Example (block 24281427, tx 0x584b891391ad58c565ea1bc9933b2f9b098e34d693ac8d77c465ba951ac2373a):

Optional Fields

Fields some clients include that others may omit.

error example:

Example (block 24281427, tx 0x584b891391ad58c565ea1bc9933b2f9b098e34d693ac8d77c465ba951ac2373a):

returnData example:

Example (block 24281427, tx 0x584b891391ad58c565ea1bc9933b2f9b098e34d693ac8d77c465ba951ac2373a):

storage example:

Example (block 24281427, tx 0x584b891391ad58c565ea1bc9933b2f9b098e34d693ac8d77c465ba951ac2373a):

structLog_for_simple_transfer example:

Example (block 24281427, tx 0xbe3839523703cc914573c2a304367bff26fd6d08738389fc8d2bf857cdf3391c):

AI Analysis of Client Differences

Ethereum Client debug_traceTransaction Analysis

Executive Summary

Across 501 transactions, there are 2.4M+ differences detected, but the vast majority are formatting variations rather than semantic bugs. The data reveals three distinct categories:

1. Format-only differences (cosmetic, no semantic impact)
2. Field presence differences (when/whether optional fields appear)
3. Potential semantic differences (actual behavioral divergence)

1. Key Behavioral Differences by Client

Besu

Geth

Erigon

Nethermind

Reth

2. Separating Semantic Differences from Format Noise

Format-Only (Safe to Normalize)

Actual Semantic Differences

3. Patterns Suggesting Bugs or Spec Violations

[BUG] Besu: Return Data Loss

Impact: Debugging tools lose revert reasons, making troubleshooting significantly harder.

[BUG] Besu: Inconsistent Type Serialization

• stack: bytes_array instead of list - breaks standard JSON array iteration
• op: string instead of hex_string - inconsistent with other hex fields
• error: list instead of string - unexpected structure for error messages

[BUG] Besu: Phantom structLog for Transfers

Simple ETH transfers (no contract code) produce 1 structLog entry in Besu, 0 in all others. This could indicate:

• Besu traces the implicit "stop" at empty code
• Others skip tracing entirely for EOA-to-EOA transfers

[WARNING] Storage Reporting Point Divergence

The storage field shows massive differences in which opcode reports storage changes:

• Geth/Erigon: Report storage on SLOAD/SSTORE only
• Besu: Missing storage on SLOAD/SSTORE, but reports on unrelated opcodes (PUSH, DUP, etc.)
• Nethermind/Reth: Report storage on many non-storage opcodes

This suggests different interpretations of "when to snapshot storage state."

[WARNING] Refund Counter Reporting

• Geth/Erigon/Reth: Include refund field throughout execution
• Besu/Nethermind: Missing refund on most opcodes

4. What Each Client Does (Without Assuming Reference)

Storage Field Timing

Memory Initialization Reporting

Refund Counter Availability

5. Notable Quirks by Client

Besu

• Most divergent client with 782K+ value mismatches
• Uses compact encoding (no zero-padding) - saves bytes but breaks simple string comparison
• Missing 0x prefix on hex values in several places
• Returns empty revert data (data loss bug)
• Adds trace entries for EOA transfers
• Different type representations break API compatibility

Geth

• Cleanest output - zero semantic mismatches in this dataset
• De facto reference for field presence patterns
• Consistent 64-char zero-padded hex encoding

Erigon

• Closest to Geth in behavior
• Identical field presence/absence patterns
• Same encoding conventions

Nethermind

• Verbose output - includes storage: {} and error: null even when empty
• 1,673 storage value differences suggest different snapshot timing
• 3 gas calculation differences worth investigating

Reth

• Extra returnData field on every step (1.1M occurrences)
• Different refund counter behavior vs majority
• 1,993 value differences in storage/memory/gasCost
• Storage changes reported at slightly different execution points

Recommendations

1. For Besu team: Investigate return data loss (high severity); consider aligning type serialization with majority

2. For tooling developers: Normalize these formats before comparison:

   • Strip/add 0x prefix
   • Zero-pad hex values to expected length
   • Treat "" and "0x" as equivalent for empty data

3. For spec authors: Clarify:

   • When storage field should be populated
   • Whether refund is required/optional
   • Expected behavior for EOA-to-EOA transfer traces
   • Canonical encoding for empty values