Neon EVM connects Ethereum’s developer experience with Solana’s performance, but tracing Solidity execution on Solana is challenging due to fundamental differences in the two ecosystems’ architectures and tooling.

This challenge becomes especially clear when it’s time to debug.

Debugging on Solana using logs can be a frustrating experience. We've all been there - adding a feature to a Solana program and hitting a failure with no clear explanation why. Without proper tooling, identifying the root cause can feel like searching for a needle in a haystack.

‍

‍

In this article, we’ll unpack how Neon EVM enables precise, reproducible tracing of Neon EVM transactions on Solana, and what went into building this unique capability.

Ethereum vs. Solana: Architecture Overview

Neon EVM consists of two core components:

• Neon Proxy - an Ethereum-compatible JSON-RPC node.
• Neon EVM Program - a BPF-based program deployed on Solana that executes EVM bytecode.

To simulate and debug transaction execution, a third component - Neon API - compiles the same BPF program but targets native x86_64 for local emulation and tracing.

The code for the on-chain program and Neon API is shared through a common crate (evm-loader), enabling tight alignment between emulated and on-chain execution.

‍

‍

Code Sharing and the Ethnum Alignment Problem

Sharing code between Neon API and the BPF program required consistent Rust versions and crate compatibility. But a subtle issue arose with the ethnum crate.

The core of the problem: starting from Rust 1.77, the alignment of u128 was changed from 8 to 16 bytes to match C compilers like GCC and Clang. This broke struct layouts and offset expectations used in serialized U256 values, which were based on the older alignment.

‍

‍

To fix this, the team forked ethnum, redefining U256 as four u64 parts. This restored 8-byte alignment for tracing purposes while maintaining backward compatibility with data already serialized on mainnet. The BPF program continues using standard Solana build tools, while the API uses the forked crate.

Emulation vs Tracing: What's the Difference?

Neon provides two major modes of execution outside Solana:

Emulation

• Reproduces transaction logic in a single, uninterrupted run.
• Fetches account data from the current state.
• Useful for quick simulations but does not capture historical context.

Tracing

• Faithfully replays the original on-chain execution.
• Fetches exact account data at each block and slot.
• Handles resets and cancellations during Solana execution.

Each Ethereum transaction on Neon can span multiple Solana transactions. That’s why tracing must reconstruct the full sequence using execution maps, ensuring every step matches the original on-chain behavior.

‍

‍

Execution Map and State Handling

The execution map captures how the transaction evolved on Solana:

• Reset: Reinitialize Machine & storage
• Cancel: Abort execution & return Cancelled status

Tracing uses this map to simulate each step exactly as it happened, reconstructing the transaction state at each reset, and cleanly terminating on cancel events.

‍

‍

Tracing Macros and Backends

To minimize overhead and improve modularity, Neon uses Rust macros like:

• begin_vm
• end_vm
• begin_step

These macros instrument the transaction at key execution points and plug into multiple backends depending on context:

• ExecutorState - used during on-chain BPF execution.
• SyncedExecutorState - used for emulation/tracing on x86_64.
• AccountStorage trait - abstracts data fetching across modes:
  • On-chain: reads accounts passed to the Solana program.
  • Emulation: fetches live data from a Solana node.
  • Tracing: reads from a dedicated database of historical Solana account states.

‍

‍

Verifying Tracing Accuracy

‍

‍

Tracing doesn’t stop at reproducing execution. It also performs deep verification:

• Number of changed accounts
• Ethereum account balances
• Smart contract storage state
• All PDA contents involved

This ensures that the trace output isn’t just plausible - it’s provably identical to on-chain outcomes.

Results: 10,000 Transactions and Counting

Neon’s tracing has been tested on over 10,000 transactions with zero errors during reproduction and verification. The team is now preparing to release public RPC endpoints that allow developers to use methods like:

• debug_traceTransaction
• debug_traceCall
• trace_call

A standalone Tracer service manages these debugging endpoints, handles validation, and interacts with the Neon API for execution.

Final Thoughts

Debugging smart contracts on Solana has long been a pain point. With Neon EVM’s tracing system, developers get the best of both worlds: Ethereum-style tooling with Solana-level performance. This tracing infrastructure reflects deep design choices in Rust, Solana internals, and Ethereum compatibility - and is now becoming publicly available for developers.

If you’ve struggled with understanding failed transactions on Solana or building complex dApps that rely on precise behavior, Neon’s tracing may just be the missing piece.

Reach out to us on Discord for help with all your debugging needs.

‍