As a web3 developer, building decentralized applications that efficiently power hundreds of on-chain user transactions can take a lot of work. Unless you acquire more profound insights into how Ethereum transactions are processed by the EVM, developing performant smart contracts may be as difficult as walking through a dark forest.
Why Do You Need To Trace Your Transactions?
When a smart contract function is triggered, the Ethereum Virtual Machine (EVM) processes the associated bytecode serving as the single source of truth for all on-chain activities. This entire computational play can be complicated, and dApp developers risk missing important smart contract events. Consider the case of a popular DeFi developer who spent a week attempting to track down a lost smart contract event.
Why can’t he check the transaction receipt details on Etherscan, you ask? Transaction receipts can only reveal so much about data modifications or external interactions performed by your smart contract executions. What you need is a way to replay the specific transactions in a way that allows you to collect precise information on how they were executed on the EVM.
This is precisely what debug_traceCall and Trace API’s trace_call method offer. Both endpoints allow you to accurately trace and replay your DApp’s transaction lifecycles without spending extra ether on gas fees.
While both API calls provide similar transaction tracing capabilities, there are a few variations to consider before deploying one.
What is the debug_traceCall Method?
Developed by the Geth team, debug_traceCall is a non-standard RPC method that allows you to process an eth_call within the context of the given block execution using the final state of the parent block as the base.
When invoked, the defined transaction is executed precisely as it would have been in the EVM without generating an accompanying on-chain transaction.
To use Alchemy’s debug_traceCall API endpoint, you need to pass a couple of arguments:
- The transaction call object containing the necessary details needed by the EVM, such as the sender, receiving address, gas price, value, and data.
Note that only the receiving address is required here. This is powerful because it allows you to quickly determine if transactions without an apparent sender in the transaction receipt originate from a sender wallet account or a third-party smart contract.
- A string argument containing the Block hash, state, or number
- The tracer object is the final argument that can be passed to the API call.
Here’s a sample curl POST call:
curl --request POST \
--url https://eth-mainnet.g.alchemy.com/v2/demo \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{
"id": 1,
"jsonrpc": "2.0",
"method": "debug_traceCall",
"params": [
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567"
},
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567"
},
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567"
}
]
}
'This API call returns an array stack of block traces in a hexadecimal format, containing key Transaction Trace Object values like gasUsed and Output.
What is the trace_Call Method?
Developed by the OpenEthereum’s team as an alternative to the Debug APIs, trace_Call is also a non-standard RPC method that allows you to execute an eth_call in return for a full externality trace on the specified transaction.
Like debug_traceCall, you can call the trace_Call API endpoint to analyze the internals of the EVM when a successful transaction was processed or even for unsuccessful transactions that weren’t even mined.
The trace_Call also accepts three(3) parameters.
– The transaction call object which we’ve previously discussed.
– An array data type where you specify the type of trace you need
– An optional Quantity or Tag value specifying the block number or state.
The result of this call is also an array stack of block traces presented as a trace tree.
Here’s a sample curl POST call:
curl --request POST \
--url https://eth-mainnet.g.alchemy.com/v2/demo \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{
"id": 1,
"jsonrpc": "2.0",
"method": "trace_call",
"params": [
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567"
},
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567"
},
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567"
}
]
}
'However, if you prefer a Javascript (Axios) API call for both API endpoints, please see the API documentation here: https://docs.alchemy.com/reference/debug-tracecall and https://docs.alchemy.com/reference/trace-call. You can also check out Alchemy’s no-code API Composer tool for making and testing requests’ prototypes: https://composer.alchemy.com/.
debug_traceCall vs trace_Call
Alchemy’s Trace and Debug APIs provide endpoints for filtering and tracing address-specific transactions. In the case of debug_traceCall, this happens with the aid of the callTracer and prestateTracer tracers, while trace_Call employs vmTrace”, “trace”, and “stateDiff” trace methods. There are a few other differences to be aware of when using either endpoint.
1. debug_traceCall has multi-chain support on Alchemy – available on all EVM-compatible test and mainnet networks on Ethereum, Polygon, Arbitrum, and Optimism protocols. On the other hand, trace_Call is only available on the test Ethereum network – Goerli.
2. Using debug_traceCall for simple EVM transaction monitoring might be overkill because of the high raw method compute costs (330) it requires to process. This is significantly higher than trace_Call’s cost(75).
Building With Confidence
That’s all. Getting access to the trace_Call and debug_traceCall methods can help you deploy optimized smart contract executions.
You can also check out our other Alchemy’s Trace and Debug API capabilities to simplify your development experience.