After contracts have been deployed, you may want to further investigate the execution of a smart contract function call. Traces provide a comprehensive view of the sequence of operations and their effects, allowing for analysis, debugging, and auditing of smart contract behavior. The two types of useful traces:
Contract call trace information captures the input, output, and gas details of all the nested smart contracts functions executed in a transaction. On Ethereum, these are occasionally called inner transactions but they simply capture snapshots of the message frame consideration the EVM encounters when processing a smart contract execution at each depth for all involved functions.
| Input Data | It records the input data or parameters provided when calling a particular function within a smart contract. This input data is essentially the encoded form of the function signature and its arguments. |
| Output Data | After executing the function, the trace information includes the output data returned by that function. This can be the result of the function's computation or any data it generates as part of its execution. |
| Gas Details | Logs information about the gas consumed by each function call. Each operation within a function consumes a certain amount of gas, and this information is tracked to calculate the overall transaction cost. |
This information can be queried using the transaction ID or Ethereum transaction hash.
ℹ️ Detailed information for call trace can be found in the Hedera protobuf and includes:
| Call Trace Data | Description |
|---|---|
| Call Operation Type | Specific type of operation performed during the execution of a smart contract or a transaction in the EVM. Example: “CALL” is an operation type use when a transaction invokes a function within a smart contract. It executes the function and can potentially modify the state of the contract. |
| Result Data | The result data is the output or return values generated by the execution of a smart contract function or action. When a function call is executed, it may produce data as a result, such as computed values, status indicators, contract revert reason if any and the error if the transaction itself failed without an explicit REVERT |
| Result Data Type | The "result data type" refers to the data type of the value returned by the function or method. For example, if you have a function add(a, b) that adds two numbers and returns the result, the result data type might be an integer if it returns the sum of the numbers. |
| Call Depth | The level or depth of the current function call within the call stack. It provides information about the nested nature of function calls and helps track the sequence and hierarchy of function invocations during the execution of a smart contract. The caller depth indicates how many functions have been called before the current function in the call stack. It starts at 0 for the initial function invocation and increments by 1 for each subsequent function call. For example, the parent transaction would be represented as call depth 1 and first child would be at call depth 1.1 and child transaction 2 would be at call depth 1.2. Child transaction at depth 1.2 has two parents. |
| Caller | The caller can be the ID of the account calling the contract or the ID of another smart contract calling the contract. The first action in the tree can only come from an account. The rest of the actions in the call tree come from the contract. When a smart contract function is invoked, either by an external account or by another contract, the caller address is recorded in the trace to identify the source of the function call. The caller address can be useful in understanding the context of the execution and determining the origin of the transaction or message that triggered the function call. |
| Recipient | The address of the smart contract or account that receives a specific call or transaction. It represents the destination or target of the interaction within the EVM. The contract action can be directed to one of the following: • Account: The account ID of the recipient if the recipient is an account. Only HBARs will be transferred. • Contract: The contract ID if the recipient is a smart contract • EVM address : If the contract action was directed to an invalid solidity address, what that address was |
| From | The from Hedera contract calling the next contract. |
| To | The contract receiving the call or being created. |
| Value/Amount | The amount of hbars transferred within this call. |
| Gas Limit | The gas is defined as the upper limit gas this contract call can spend. |
| Gas Used | The amount of gas that was used for the contract call. |
| Input | Bytes passed as an input data to this contract call |
Example:
Call trace example on HashScan
Smart Contract state changes will now be tracked whenever a smart contract transaction modifies the state of the contract. This will enable developers to have a paper trail of the state changes that occurred for a contract from the time the contract was created. The state changes that will be tracked include each time a value is read or written to the smart contract. The storage slot represents the order in which the smart contract state is read or written.
The value read reflects the storage value prior to the execution of the smart contract transaction. The value written, if present, represents the final updated value of the storage slot after the completion of the smart contract call. Transient states between the start and finish of the contract are not stored in the transaction record.
ℹ️ Detailed information on state trace can be found in the protobuf and includes:
| State Trace Data | Description |
|---|---|
| Address | The smart contract EVM address. Ex: |
| Contract ID | The smart contract ID. Ex: |
| Slot | Refers to a storage location where data is stored within the contract's state. It can also be thought of as a variable or a storage unit that holds a specific value. |
| Value Read | The current values of variables or data structures before making modifications. These values can be used to validate conditions, perform calculations, or trigger specific actions within the contract's code. |
| Value Written | The written or changed variables or data structures after the modification. |
Consensus nodes store sidecar records called ContractStateChanges. Each time a smart contract state changes, a new record will be produced that commemorates the state changes for the contract that took place.
The Hedera mirror node supports two rest APIs that return information about the smart contract’s state changes. This includes:
/api/v1/contracts/{id}/results/{timestamp}/api/v1/contracts/results/{transactionIdOrHash}
Example:
"state_changes": [
{
"address": "0000000000000000000000000000000000001f41",
"contract_id": "0.1.2",
"slot": "0x00000000000000000000000000000000000000000000000000000000000000fa",
"value_read": "0x97c1fc0a6ed5551bc831571325e9bdb365d06803100dc20648640ba24ce69750",
"value_written": "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925"
}
]
State trace can be viewed on a supported Hedera Network Explorer.
State trace example on HashScan