Ethereum under the hood- Part 7( Blocks )

Deepak rao

21 Mar 2022 • 5 min read

Welcome back and a happy new year. Glad you are still with me as we dig venture into the internals of Ethereum. In chapter 6, we discussed Hashing; in this section, we dive into Blocks. Block is a big topic to cover in one single medium post, so I intend to split Blocks into 2 Parts and Part-1 of Blocks short, so in Block Part 1 we cover:

Quick review
Blocks
Block Header
Summary
Onwards.

Quick Review:

We are dipping a little deeper into our journey of exploring Ethereum, but it’s good to pause and recap what we have learned so far, I have created a public gist to refresh our collective memories, for this overview, let us focus on Part 3 through 6.

https://gist.github.com/deepakraous/d35635acc6d645494dba7203f1b525b5

Blocks:

The block is the core of the concept of a BlockChain; a Block is a historical recordkeeper of the list of transactions. There is a lot of information packed into that statement. Ethereum, like its predecessor Bitcoin, has the concept of a Blockchain, and to understand a Block, we will approach a Block as a Data structure.

The Ethereum Yellow paper, defines a Block as a collection of three entities 1. Block Header 2.Transaction(s) List 3.Ommers List, formally defined as:

https://ethereum.github.io/yellowpaper/paper.pdf

A block is a data structure similar to that has a set of validated transactions.

Block Header:

Block header, as the name suggests is the header of a Block, Blockheader is composed of 15 distinct fields as per the yellow paper, I tried capturing them in a spreadsheet, similar to the one below:

Each one of those fields needs a separate chapter by itself, we will not go into the details of each one of those 15 fields but will focus on a few. I would recommend having a look at Part-4( The trie ) as a refresher. Now back to the Block Header fields

ParentHash: This field, as the name refers to the Parent’s Keccak hash of this block. The field size would be 256-bit Keccak hash function, primarily the hash value indicates the immediate parent of this block, using this technique is how Ethereum links one block to another, forming a chain of blocks.

StateRoot: This refers to the Keccak hash root of a collection of the state trie (post-execution), which has occurred since the creation of this block, a { key, value } collection. There is only one global state that is updated continuously, and each block will have the root hash of the state trie DB.

Keys ->  { Ethereum Address 160 bit }
Values -> { Nonce,Balance,StorageRoot,CodeHash }

TransactionRoot: Keccak Hash of the root node of Transaction Trie: This field refers to the Keccak hash root of a collection of all the Transaction trie, which has occurred since the creation of this block.

ReceiptsRoot: Keccak Hash of the root node of Transaction Trie: This field refers to the Keccak hash root of a collection of all the Transaction trie, which has occurred since the creation of this block. The Receipt (R) is a Tuple comprised of 4 fields. Ethereum yellow paper has, in some detail, mentioned the receipts root field. The receipts field is a collection of

          | Description      | Symbol     |   
          | :— — — — — - - -:|: — — — — -:| 
          | Total Gas Spent  | Ru         |
          | Bloom Filter Root| Rb         | 
          | Logs of the Tran | Rl         | 
          | Status Code      | Rz         |

The logs (Rl) and Bloom filter root (Rb) fields are described in detail in the yellow paper; Bloom Filters do need a separate section, and I am planning to discuss them in Part-8 but for now, let us think of Bloom filters as an algorithm that can help speed up search time results.

Relationship between Transaction Trie and Receipts Trie

Reading through the Yellow paper, I can see that each block header includes the Keccak 256 hash of the root of the trie for transactions and transaction receipts. I am struggling to understand how ...