Breaking down blocks

As mentioned previously, a block is a permanent store of the transaction recorded and validated during a given time period. Technically, the transaction data is written to a read-only file called a block. When we look into the details of a block, it represents the present and contains transactions that have been recorded recently, as well as a reference to the past. Each time a block is finalized, it becomes part of the past and cannot be altered or removed. The blockchain works in a cycle where new transactions are stored in the next block with a reference to the preceding block. The structure of a block depends on the blockchain.

The following table shows the structure of a block used in the bitcoin core code:

    
        
Bytes           Field Name           Description
      
        
4           Magic number           Value is always 0xD9B4BEF9.
4           Block size           Number of bytes following up to the end of the block.
80           Block header           Consists of six items used to give the block context.
1-9           Transaction counter           Positive integer indicating the number of transactions.
Vb           Transactions           Non-empty list of transactions.
      
  

When comparing this with the structure of an Ethereum block, we see in the following table that the block header field can be much larger:

    
        
Bytes           Field Name           Description
      
        
>508           Block header           Consists of 15 items used to give the block context.
Vb           Transaction list           Non-empty list of transactions.
Vb           Ommer list           List of ommer blocks that helped with the proof-of-work.
      
  

In blockchains, every block also contains a header, which, like an HTTP request, gives context to the block. The structure of the header depends on the implementation of the blockchain; for example, bitcoin implements a serialized 80-byte format string, whereas Ethereum has a format with a variable length of at least 508 bytes. The header is constructed when finalized and used to create the proof-of-work, or POW, which I will discuss in more detail later on in this chapter.

The format used for the block header by a blockchain based on the Bitcoin core code is described in the following table:

    
        
Bytes           Field Name           Description
      
        
4           Version           The block version number indicates which set of block validation rules to follow.
32           Previous block hash           A hash of the previous block's header. This hash ensures that no previous block can be changed.
32           Merkle root hash           A hash of the root of the Merkle tree (https://en.bitcoin.it/wiki/Protocol_documentation#Merkle_Trees) derived from the transactions included in the block. This hash ensures that none of those transactions can be modified without modifying the header.
4           Timestamp           The timestamp of the block in UNIX epoch time. This timestamp is determined by the verifier when starting to hash the header. Blocks with a timestamp of more than two hours in the future will not be accepted.
4           Difficulty target           The difficulty target threshold of which the block hash must be less than or equal to.
4           Nonce           An arbitrary number used by verifiers to generate a correct hash less than or equal to the target threshold. If all 32-bit values are tested without a correct nonce, the time can be updated or the Coinbase transaction can be changed and the Merkle root updated.
      
  

When comparing the format used by a blockchain based on Ethereum, the structure looks a little bit different:

    
        
Bytes           Field Name           Description
      
        
32           Parent hash           A KECCAK-256 hash of the parent (or previous) block header. This hash ensures that no previous block can be changed. 
32           Ommer hash           A KECCAK-256 hash of a list of ommer (or uncles) of the block. Uncles are orphaned blocks that contribute to the security of the main chain. They are not considered the canonical "truth" for that particular chain height.
20           Beneficiary           The address for the fees collected from successful mining.
32           State root           A KECCAK-256 hash of the root of the state tree derived from the transactions executed and finalized in the block. This hash ensures that none of those transactions can be modified.
32           Transaction root           A KECCAK-256 hash of the root node of the transaction tree.
32           Receipt root           A KECCAK-256 hash of the root node of the transaction receipt tree.
32           Logs bloom           Bloom filter from indexable (logger address and log topics) information in each log entry from the receipts.
Vb           Difficulty           Big int scalar value corresponding to the difficulty level of the block.
Vb           Number           Big int scalar value equal to the number of ancestor blocks.
Vb           Gas limit           Big int scalar value equal to the current limit of gas expenditure per block.
Vb           Gas used           Big int scalar value equal to the total gas used in transactions in the block.
Vb           Timestamp           Big int scalar value equal to the timestamp of the block at inception in UNIX epoch time.
32           Extra data           Arbitrary byte array containing data relevant to the block.
32           Mix hash           A KECCAK-256 hash which, combined with the nonce, proves that enough computations are executed on the block.
8           Nonce           
          
A 64-bit hash used by verifiers to prove that enough computations are executed on the block.