Introduction

Transaction tracing is the process of extracting detailed information about each step of the transaction. This article explains how transaction tracing works and the difference between two transaction tracing methods: **trace_call** and **debug_traceCall.**

Prerequisites

Before reading about how transaction tracing works and the difference between tracing methods you should have a clear understanding of EVM, Execution Clients, Smart Contracts and Nodes. You can read about these topics in the official Ethereum documentation. However, if you just need a refresher, you can find the one-line definitions for these topics below.

• Smart Contracts: Smart contracts are self-executing contracts with the terms of the agreement written into lines of code. The code and the agreements contained therein exist across a decentralized, distributed blockchain network.
• Execution Client: An Execution/Ethereum Client is a software program that connects to the Ethereum network to enable users to interact with the Ethereum blockchain. Some popular Ethereum clients include Geth, Parity, and Erigon.
• EVM: The Ethereum Virtual Machine (EVM) is a turing-complete virtual machine that allows for the execution of smart contracts on the Ethereum blockchain. The EVM is responsible for processing and executing all of the transactions that occur on the Ethereum network.
• Node: An Ethereum node is a computer that runs an Ethereum Client and maintains the Ethereum blockchain.

<aside> 💡 These definitions are not meant to be complete explanations. Instead, they are just refreshers for the people who already know about these concepts. For a detailed explanation please refer to the official Ethereum documentation.

</aside>

The Problem

There are two types of transactions in EVM-compatible protocols:

1. Value Transfers: A value transfer just moves the native blockchain currency (Ether in the case of Ethereum) from one account to another.
2. Contract Executions: A contract execution involves calling a function of the smart contract that can change the state of the contract and even call functions of other smart contracts.

The downside of the contract execution is that it is very hard to tell what the transaction actually did. When a transaction` is executed, you can get a transaction receipt that contains a status code to check whether the execution succeeded or not, but there is no way to see what data was modified, or what external contracts were invoked.

Look at the transaction flow below:

This is a transaction in which a user (externally owned account) invokes a contract which in turn invokes another contract and this is how the transaction receipt for this transaction looks like: