Smart Contract Traceability

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:

➡ Call Trace

➡ State Trace

Call Trace

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 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. `OP_UNKNOWN = 0; OP_CALL = 1; OP_CALLCODE = 2; OP_DELEGATECALL = 3; OP_STATICCALL = 4; OP_CREATE = 5; OP_CREATE2 = 6;`
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

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.

OP_UNKNOWN = 0;
OP_CALL = 1;
OP_CALLCODE = 2;
OP_DELEGATECALL = 3;
OP_STATICCALL = 4;
OP_CREATE = 5;
OP_CREATE2 = 6;

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.

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:

State Trace

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

State Trace Data	Description
Address	The smart contract EVM address. Ex: `0000000000000000000000000000000000001f41`
Contract ID	The smart contract ID. Ex: `0.0.1234`
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.

Address

The smart contract EVM address.

Ex: 0000000000000000000000000000000000001f41

Contract ID

The smart contract ID.

Ex: 0.0.1234

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 Node

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.

Mirror Node

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"
      }
    ]

Hedera Mirror Node Explorer

State trace can be viewed on a supported Hedera Network Explorer.

PreviousVerifying Smart Contracts NextTokens Managed by Smart Contracts

Last updated 6 months ago