Exploring Ethereum Data Structures: Blocks, Transactions & Events

Introduction

Understanding the data structures of a system is necessary to be able to retrieve and make sense of the retrieved data from such system. Further, the mechanics of how a protocol like Ethereum works under the hood are not trivial, particularly due to the added complexities that Smart Contracts bring about. While this is what makes Ethereum a ‘programmable blockchain’, it also means that knowing what the underlying data represents is crucial to making sense of the data.

In this write-up, we will explore the fundamental data-components that are defined by the Ethereum Blockchain by delving into what they are and how they relate to one another, particularly when Smart Contracts are involved.

‍Note: This write-up is aimed towards users that are not overly familiar with the Blockchain and as such takes some liberties in simplifying concepts that are beyond the intended scope.

Addresses

Addresses, I hear you say? In a post about Blocks, Transactions and Events?

Well, addresses are not a data structure in and of themselves. However, they are crucial elements as they define identities on the Blockchain and thus, the all too important ‘ownership’ of private keys that control that address.  For the purpose of this post, it is important to keep in mind that such addresses (i.e. identities) may interchangeably be referring to one of two things:

• Wallet Addresses: These represent addresses whose private keys are owned by users of the protocol;
  OR
• ‍Smart Contracts: These represent addresses whose keys are not owned by a user, but by the Smart Contract that has been deployed on the Blockchain.

Note: Addresses on Ethereum are represented in the form of alphanumeric text (technically a 160-bit value represented as a hexadecimal stringe.g.0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8).

Block

The blocks are data structures that make up the basic building blocks (no pun intended) of a Blockchain, so much so that they give this technology its name. Blocks contain a list of transactions, representing a collection of activity that has been secured, signed and registered on the protocol. Each block is linked to the previous block, creating a chain of blocks and hence, the Blockchain!

Key Properties of a Block

• Block Height / Block Number: This is the number of the block as it appears in the chain. New blocks increment by a value of 1. They provide a human-readable identifier of the Block that contains a set of     transactions. The Block Height and Block Number terms are used interchangeably.
  ‍
• Timestamp: The timestamp provides the time (in UTC) that the block was successfully secured and accepted onto the Blockchain (be it mined and/or validated).

• Block Hash: The block hash is the digital signature (output of the hash function) of     all the key data contained in the block. This key data includes the Block hash of the previous block, and a computed signature of all the transactions included in that block. Since each block’s signature is built by leveraging the previous block’s information, the chain is secured as changing just one earlier block would, change the information in that block and accordingly the hash of the block. This would result the chain to break.
  ‍

Transactions

Transactions are data structures that represent activity between two primary account holders, the sender and receiver. While this can simply be a transfer of an amount of the native cryptocurrency (such as ETH for Ethereum), it can also represent calls to Smart Contract that change the contract’s state, for example, the transfer of an ERC20 token which necessitates the contract to update its balance data. It is worth noting that retrieving information from the Smart Contract in which the Smart Contract does not change its state (such as values of data stored within it) is not recorded on the blockchain as such data retrieval is free.

Key Properties of a Transaction

• Transaction Hash: A unique identifier for every transaction that is generated on the Blockchain. You can use this hash to refer to a specific transaction, even if you do not know which Block it was included in.
  
• From: The address that created the transaction.
  ‍
• To: The address that the transaction is invoking. This may either be the address for the user-owned wallet that is receiving the blockchain’s native token (e.g. ETH for Ethereum, and MATIC for Polygon), or the address of the Smart Contract that contains the code to be executed.
  ‍
• Gas* Limit: The number of gas units to make available for the transaction. If the transaction inadvertently requires more, it will halt and not complete.
  ‍
• Gas Price: The price (in gwei) to assign to each gas unit. Note that Gas Price may not be available for newer transactions.

• Max Fees Per Gas: On newer implementations the gas fee is set by the network for every block, so this value indicates the maximum fee that the user is willing to pay.
  ‍

*Gas is the transaction cost that the individual executing the transaction will be required to pay the miner for including the transaction in a block. In order to protect the blockchain, users have to pay fees when undertaking transactions. These fees depend on the complexity of the transaction (e.g. calling a complex smart contract will carry higher gas fees). These fees are calculated in special units called gas.

Events & Logs

When a transaction represents a call to a Smart Contract that changes the contract’s state (i.e. is not merely retrieving data but making changes), the Smart Contract may emit (i.e. record) event logs. The specific use of the event data structure can vary, and its use is entirely Smart Contract dependent, but they are typically used to log key information about what a particular transaction achieved. An event may only be emitted by a Smart Contract, and it is not mandatory for Smart Contracts to emit events.

Note: for the purposes of this document, the term Events and Logs are used interchangeably.

Key Properties of Events & Logs:

• Address: The address of the Smart Contract that registered the logs (i.e. where the logs came from)
  ‍
• Log Index: The order in which the log appears amongst other emitted logs on the transaction.
  ‍
• Topics: The data emitted by the event/log. Note that generally speaking, to make sense out of this data you must have access to the Smart Contracts source code or ABI.
  ‍

Conclusion

Data in the Blockchain is typically stored in an encoded manner to ensure uniformity. As a result, it is only humanly readable to an extent, and software will be required to decode such data to make more sense out of it. Popular Block Explorers like Etherscan are able to decode a lot of this data, however you may find that there is still certain data, such as logs that cannot be decoded.

At Hash, we’re building a suite of products that ensures that data is presented in a manner that abstracts the complexities of the data structure behind the blockchain, while helping decode to the largest extent possible all data and activity from DeFi protocols in a human readable format.

Written by: Matthew Scerri