Transactions

Index

The /transactions page will display all synchronized blocks, with basic details such as age or sender and destination. No destination means it's a contract creation. Transaction hashes link to the transaction details page If a transaction is mined but the CLI is not listening, it won't appear here.

If the address is a known contract (the name has been set manually, or synchronized) it will be displayed instead of the address.

Details

Each block has its own page, with the URL following the pattern /transaction/${txHash}.

Based on what happened during the transactions different sections will be displayed:

  • Token transfers: if the transaction emitted standard ERC_20 Transfer() events, they will formatted and displayed here with contract names and formatted amounts.

  • Token balances: Also based on Transfer() events, for each emitted event, a query to get the balance will be made on the current & previous block, both values will be displayed, as well as the difference.

If the transaction is a contract call and the artifacts have been uploaded, you'll be able to see:

  • Function call signature with the parameters

  • Emitted events

  • Watched variables data

The watched variables data will be the one watched for the contract called in the transaction.

Tracing

If you are connected to a node that supports debug_traceTransaction, you'll be able to see the Trace section on every transaction page.

This feature is similar to the "Internal Txns" Etherscan page, it will show you interactions that happened with other contracts during the transaction.

By default, transaction tracing is not activated in any of your workspaces. In order to do that you need to go in the "Settings" page, scroll down to the "Advanced Options" panel, select the tracing mode in the dropdown, and click "Update".

After changing this setting, you'll need to restart the CLI (or the Hardhat node if you are using the plugin).

There are two different modes: "Tracing on a Hardhat network" and "Tracing a non-Hardhat network". This distinction is needed because transaction tracing is handled a bit differently with Hardhat.

Once tracing has been activated it will be ran for every write transaction, and the trace will be displayed, after processing, on the transaction page.

Here is what you'll see:

  • Type of action (CALL, CREATE, etc...)

  • Address of the contract called (or created)

  • Name of the contract

  • Decoded function called with parameters

For the last two, it will be available if Ethernal was able to match it with an existing contract, or able to pull info from Etherscan.

Once all the steps have been collected, we are trying to get as much info as possible from each step:

If it's a CALLx step, we try three different strategies, and use the first one that returns the info that we need:

  1. We look for the called address in your synchronized contracts, if there is a match, we'll use this info to decode the parameters and display the name along the trace

  2. We hash the called bytecode, and compare it to hashes of your other contracts. If there is match, we set the name & the ABI from it.

  3. We look for an existing address on Etherscan, and if there is a match we pull the name and ABI from there, and associate it with the trace.

For CREATEx steps, it's only trying strategy #2.

Depending on how big the trace is, and how many requests to Etherscan are made, this process can take a bit of time. However, once it's finished, your trace becomes much easier to understand!

A more in-depth article on how it works is available on the blog: https://blog.tryethernal.com/transaction-tracing-with-ethernal/

Last updated