Working with Raw Blockchain Data
Understanding how transactions, traces, and logs data work is the foundation to mastering blockchain data.
At the heart of blockchain data are three fundamental data tables: transactions, traces, and logs. These tables capture the lifecycle of a transaction, from its inception to its final state. By understanding these core components, you will find it easier to query onchain data, build more intuitive dashboards, and create insightful reports.
Lifecycle of a Blockchain Transaction
Let’s take the example of you transferring USDT to a friend on the Ethereum chain. You sign the transaction to transfer the ERC-20 token from your wallet, triggering the transfer function that specifies the recipient and amount.
Behind the scenes, the blockchain creates two key tables: transactions and traces. These tables record details like transaction hash, sender, recipient, transaction status, gas fees, block number, and timestamp.
The transaction's final stage is marked by the emitTransfer function, which generates the logs table. This table includes contract address, event topics, call data, and block information.
Most tables on Blockchain Analytics platforms like Dune & Flipslide are built upon these three foundational tables. Understanding them is essential for delving into more complex blockchain data exploration.
Part 1- Exploring Transaction Data on Ethereum
Every transaction happening in the cryptoeconomy is, by design, visible to anyone via explorers. The challenge is that the average person usually finds it difficult to read and interpret these transactions due to the jargon and technicalities involved in navigating blockchain explorers like Etherscan.
This section of the guide will be an overview of important terminologies and details you need to understand when looking up any transaction on blockchain explorers.
Let's say you swap USDT for Highstreet (HIGH) tokens on Binance. Since these are ERC-20 tokens, you can find transaction details on Etherscan. After each swap, a transaction hash is generated. Entering the hash into etherscan's search bar will bring you to a page like this:
Transaction Hash: A unique identifier for each transaction, similar to a receipt number.
Status: Indicates the current state of the transaction- e.g. success, failed, canceled, or is still pending.
Block: The block number where the transaction is included. Blocks contain groups of transactions added to the blockchain at specific times.
Block confirmation means how many blocks have passed since the transaction was included.
Timestamp: Date and time the transaction was included in a block.
Transaction Action: The type of action the transaction performs, such as sending tokens, deploying a smart contract, or providing liquidity in a pool.
From: Address of the sender initiating the transaction.
Interacted With (To): Address receiving the transaction (this can be an EOA (externally owned address) for token transfers, or contract address for smart contract interactions.
Tokens Transferred: Specific tokens involved in the transaction.
Value: Amount of Ether (ETH) sent in the transaction.
Transaction Fee: Total fee paid for the transaction in ETH.
Gas Price: Price per unit of gas used by the transaction.
Gas Limit & Usage by Txn:
Gas Limit: Maximum amount of gas the sender is willing to spend on the transaction.
Gas Usage: Actual amount of gas used by the transaction.
Gas Fees: Calculated cost of gas used (Gas Used * Gas Price).
Base Fee: the minimum fee to be paid in the block.
Max: the maximum fee the user is willing to pay.
Max Priority: tip paid to incentivize miner to include transaction.
Burnt & Savings Fees:
Burnt Fees: The base fee is burned (sent to 0x address) to secure the network (burned/destroyed).
Savings Fees: A portion of the gas fee that goes to the miner who included the transaction in a block.
Where Savings = max- base- priority * gas used.
Other Attributes: May include additional details specific to the transaction like type, nonce, and position in block.
Input Data: Data associated with the transaction, often used for smart contract interactions. You can find a decode button if the ABI of the contract is provided.
As you navigate Explorers, it is important to understand if the address being interacted with is a contract address or an EOA-externally owned address (user address). A contract address will usually have an input call data column, which contains additional details about the transaction.
Let’s talk about Input Data
Input data in an Ethereum transaction specifies the function being called and the arguments passed to that function. It's essentially the message telling the smart contract what to do.
Breakdown of Input Data Elements:
The input data for an Ethereum transaction typically includes the following elements:
Function: The name of the function being called on the smart contract (e.g.,
swap).Address executor: The address of the contract involved in the transaction.
Tuple desc (tuple description): This defines the data types of the arguments passed to the function. Tuples are collections of data that group related values together. In this context, they specify the expected data types (e.g., address, uint256) for the function's arguments. Tuples are immutable, meaning their values cannot be changed after creation.
Bytes data: This section contains additional information specific to the function being called. It's encoded in bytes format for the smart contract to interpret.
Decoding Bytes Data:
The decoding process involves understanding how the data is structured within the bytes. Here's a breakdown:
Function Signature (Method ID): The first 8 hexadecimal characters (4 bytes) of the input data represent the function signature, also known as the method ID. This value is derived by:
Combining the function name and its input data types.
Taking the Keccak-256 hash of the combined string.
Extracting the first 4 bytes of the hash.
Displaying the extracted bytes in hexadecimal format.
Decoding Individual Parameters: After identifying the function signature, each remaining byte is decoded based on its position within the
tuple desc. This involves interpreting each byte according to its corresponding data type (e.g., address, uint256) and assigned value.
In this Transaction, the methodID is decoded as 07ed2379, while its parameters are specified thus:
Understanding how to decode input data is crucial for extracting deeper insights beyond what blockchain explorers provide. I plan to delve deeper into input data and share more details as I learn along the way.
My next guide will focus on understanding Event Logs. Be sure to follow along as we learn blockchain data together.