Using Etherscan is much easier than it looks

Previously, we learned about the Etherscan Homepage and the Transactions Overview pages on Etherscan. If you missed it, those articles can be found here:
Part 1: Etherscan Homepage
Part 2: Transactions Overview

Today, we will be continuing to learn about the Transactions Overview page. 💸

After the Ether Price section, there is an option to “Click to see more.” If we click this, we will see even more information about the transaction. This is detailed information about gas during the time of the transaction, attributes of the transaction, and binary data that formed the input of the transaction. Today, we will be learning more about this section.

This information is not necessary for us to know to be able to check on the status of our transaction but it gives us some interesting additional information about it.

Let’s break down these different sections. In order, from top to bottom:

Gas Limit & Usage by Txn (Usage by transaction) ⛽

The first number shown is the gas limit for this specific transaction. This is the amount of gas that was provided by the sender to make the transaction happen. The second number is the amount of gas that was actually used for the transaction. The percentage shows the percentage of the gas provided that was used to make the transaction happen (Usage by Txn / Gas Limit). Both of these values are shown in individual units of gas.

While peer-to-peer (wallet-to-wallet) interactions and transfers such as sending ETH to a friend usually involve around 21,000 units of gas for the transaction to successfully take place, interacting with smart contracts can cause this number to be much higher. This is due to the computational complexity of smart contracts as they require more computational resources to be processed.

Gas Fees 💰

The base gas fee shows the base gas fee at the time of the transaction. This is the minimum amount that had to be used for gas for the transaction to be processed at the time. This fee is calculated based on the fee amount for blocks that were recently added to the blockchain before the current block.

The max fee and max priority fees were the max amounts that the sender was willing to pay for the transaction and give to the miner(pre-merge)/validator(post-merge) of the transaction. The priority fee acts as a tip to these miners/validators.

Burnt & Txn Savings Fees (transaction savings fees) 🔥

Burning is a process by which tokens are permanently removed from circulation, causing a lowering available supply of a token to buy, trade, or sell. When a transaction occurs on the Ethereum blockchain, an ETH equivalent of the base gas fee is burned.

The “burnt” section shows us how much ETH was burned in this transaction. The “Txn Savings (Transaction Savings)” section shows how much the sender saved in gas fees based on the amount of gas that was sent to have the transaction validated compared to the amount needed for the transaction to succeed. This amount is returned to the sender’s wallet.

Other Attributes 🔤

This section shows more detailed information about the specific transaction. The information in this section can vary widely from transaction to transaction.

Txn Type (transaction type) is reflective of the network during the time of the transaction. The transaction type will show as 2(EIP-1559) and 0 (Legacy).

Transaction Type 2 (EIP-1559) means that the transaction happened post EIP-1559 implementation. 0 (Legacy) transaction types happened before this implementation.

EIP-1559 (Ethereum Improvement Proposal-1559) is an upgrade that was implemented on August 5, 2021 which changed the way that Ethereum handled transaction fees. This is not to be confused with the merge which was implemented September 15, 2022 which transitioned Ethereum from a POW (proof of work) to a POS (proof of stake) consensus mechanism.

Nonce is the transaction number for the sender of the transaction. This count begins at the number 0. Therefore, just add 1 to the number seen in the “Nonce” section to get the transaction number for the sender. In the screenshot shown above, this was the 916th transaction for the sender. The position in block shows the order in which the transaction was added to the block. This transaction is the 41st transaction within its block.

Input Data ⌨️

The input data contains information that is required to interact with a smart contract or a message that is sent to the recipient of the transaction. Within the box, we can see binary data that formed the input of the transaction. This input data can range from information such as the initial call to begin the execution of a smart contract to smart contract initialization if a contract was created as a result of the transaction.

This information can be viewed in the default view, UTF-8, or as the original bytecode. The default view is the most human-readable out of the three views. It shows the primary function(s) that the sender interacted with followed by the method ID(s) and additional input data.

Default view for input data

UTF-8 is Unicode Transformation Format-8 bits. It is a type of encoding method that encodes all valid characters (including emojis!) into one to four-byte (8-bit) code units.

Bits and bytes are how computers store information. Bits are the smallest unit of storage for computers and can only store either a 0 or 1. Bytes are a collection of 8 bits.

UTF-8 view for input data

Why would Etherscan show the input information in UTF-8 format? 👾

The majority of the internet is encoded in UTF-8 format. It can support all valid characters, efficiently uses computer memory, and allows us to view long and complex information in a condensed way. Compared to the other views, the UTF-8 view typically looks much shorter.

The final view available is the original view. This view shows the input data in bytes beginning with a hex value.

Original view for input data

Bytes are a form of storage for computers. Hex values are another form of storage for computers. Hex values can store large binary numbers into sets of four digits.

While the three views look completely different, they all have the exact same information.

Etherscan also has an option to “Decode Input Data.”

The decoded input data contains the same information about the input data as all three earlier views! This view is also human-readable. In this view, we can see the names, types, and data of the input values.

As we break down this section, we will learn more about Solidity (the primary programming language used to create smart contracts on Ethereum) and its data types.

The “type” shown is reflective of the data type that the associated data represents.

Data types are sets of possible values within programming languages that tell the computer what type of information it contains and what operations can be performed on that information. Some examples of possible data types are Booleans, integers, and arrays. Solidity is a statically typed language, meaning that each variable type must be specified.

The “name” in this section is representative of the variable name used by the smart contract creator for the associated data.

In this screenshot, this decoded input data has one row. We can ignore the first column as it is just a counter for the information within this section.

The name for the data in this row is "_merkleProof" of data type "bytes32[]" with no data in the data column.

What does this mean?

The data type "bytes32" is a fixed-size byte array. This array holds a sequence of 32 bytes. It is named "_merkleProof" as it was likely used as a way to handle Ethereum addresses via the implementation of a Merkle Tree. Without looking directly at the code, this is only a best guess.

The data section shows as empty since this data was likely passed in and handled via the front end connected to the smart contract.

In this screenshot, the first row shows the values 0, to, address, and the string of characters “0xdd33E6fd03983c970aE5E647df07314435d69F6B.” Once again, we will ignore the first column as it is just a counter for the information within this section.

“To” is the name for the data in this row. It is of type “address” and the data that is contained in this section is “0xdd33E6fd03983c970aE5E647df07314435d69F6B.”

What does this mean?

Address is a data type in Solidity that holds a 20-byte value. This is the size of an Ethereum address. There are two types of the address data type: address and address payable.

Address is an Ethereum address. Address payable is also an Ethereum address.

However, the address payable type allows for the transfer of Ether via transfer and send functions. This distinction is made as some smart contracts do not accept Ether as a form of currency.

The next row is of name "id", type "uint256", and data "0." This is a variable known as "id" and it is an unsigned integer of 32 bytes/256 bits.

Integers are a data type common to many different programming languages. They are whole numbers with no fractional or decimal parts. While signed integers can contain negative values (such as -5), unsigned integers only consist of positive values.

In this transaction, we see another fixed-sized byte array with the name "merkleProof." However, this array contains multiple hexadecimal values. These hexadecimal values are representative of the input values for this transaction and can be decoded to find out the exact input values.

As seen, this section allows us to see a condensed overview of the transaction action(s) in a more detailed way than the "Transaction action" section of the transactions overview page allows.

Not only are we able to see the transaction action but also the data types and associated data that was passed. This can be especially useful when looking through Etherscan and contracts to familiarize oneself with how data is handled and passed in various transactions.

Understanding this section is also useful in finding information such as the nonce and position in block for specific transactions. While it may seem trivial to pay attention to this information, it can be interesting to see as one begins to familiarize themselves with transaction ordering in blockchains.

Next time, we will learn more about internal transactions, transaction logs, states, and comments to round out our understanding of the transaction details page on Etherscan before learning more about individual wallets, contracts, and more!

In the meantime, learn more about Etherscan by following their socials here:

Twitter: https://twitter.com/etherscan

Facebook: https://www.facebook.com/etherscan/

Reddit: https://www.reddit.com/r/etherscan/

Medium: https://medium.com/etherscan-blog

If you have any questions or just want to say hi, feel free to reach out to me on Twitter! ☕