Smart Contract Traceability
Last updated
Was this helpful?
Last updated
Was this helpful?
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 and includes:
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:
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.
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 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.
/api/v1/contracts/{id}/results/{timestamp}
/api/v1/contracts/results/{transactionIdOrHash}
Example:
State trace can be viewed on a supported Hedera Network Explorer.
ℹ️ Detailed information on state trace can be found in the and includes:
The Hedera supports two rest APIs that return information about the smart contract’s state changes. This includes:
