WORLD STATE

The world state is divided by blocks; each new block representing a new world state. The structure of the world state is a mapping of two things:

  1. Addresses  
  2. Account states

by using the standard recursive length prefix (RLP). This information is stored as a Merkle Patricia tree in a database backend that maintains a mapping of byte arrays to byte arrays. As a whole, the state is the sum total of database relationships in the state database.

Merkle Patricia Trees

Merkle Patricia trees are modified merkletrees where nodes represent individual characters from hashes rather than each node representing an entire hash. This permits the state data structure itself to represent not only the intrinsically correct paths in the data yet also the requisite cryptographic proofs that go into making sure that a piece of data was valid in the first place. In other words, by combining the structure of a standard merkletree with a Radix Tree structure, it helps to keep the blockchain valid. Since all searching and sorting algorithms in Ethereum must be filtered via this stringently correct database, the accuracy of information is guaranteed. The following is a search tree beginning with hexadecimal values a and 4:

TREE TERMINOLOGY

  1. Root Node – The top (first) node in a tree. 
  2. Child NodeA node directly connected to another node when moving away from the Root. 
  3. Parent NodeThe converse notion of a child. 
  4. Sibling NodesA group of nodes with the same parent. 
  5. Descendant NodeA node reachable by repeated proceeding from parent to child. 
  6. Ancestor NodeA node reachable by repeated proceeding from child to parent. 
  7. Leaf NodeA node with no children. 
  8. Branch NodeA node with at least one child. 
  9. Degree – A node’s number of subtrees.
  10. Edge – The linkage between a node and another node.
  11. Path – A node and edge series that connects a node to a descendant.
  12. Level – A node level is described by 1 + (the number of node-root connections).
  13. Node HeightThe height of a node is the number of edges on the longest path between that node and a leaf. 
  14. Tree HeightThe height of a tree is the height of its root node. 
  15. Depth – A node’s depth is the number of edges from the root node of the tree to the node.
  16. Forest – A forest is a collection of n ≥ 0 disjoint trees.

Recursive Length Prefix Encoding

Recursive Length Prefix Encoding (RLP) imposes a structure on data that intrinsically considers a prefixed hex value to position the data in the state database tree. This hex value determines the depth of a specific piece of data. There are two types of fundamental items one can encode in RLP:

  1. Strings of bytes  
  2. Lists of other items

RLP encodes arrays of nested binary data to an arbitrary depth; it is the main serialization method for data in Ethereum. RLP encodes the structure of data only, so it doesn’t pay attention to the specific types of data being encoded. Positive RLP integers are represented with the most significant value stored at the lowest memory address (big endian) and without any leading zeros. As a result, the RLP integer value for 0 is represented by an empty byte array. If a non-empty deserialized integer starts with leading zeros, it is invalid. The global state database is encoded as RLP for fast traversal and inspection of data. RLP encoding creates a mapping between addresses and account states. Since it is stored on the node operator’s computers, the tree can be indexed and searched without network delay. RLP encodes values as byte-arrays, or as sequences of further values, which are subsequently encoded as byte-arrays.

THE BLOCK

There are 17 different elements in a block. The first 15 elements are part of what is known as the block header.

The Block Header Description

The information contained in a block beside the transactions list comprises of the following:

  1. Parent Hash – This is the Keccak-256 hash of the parent block’s header. 
  2. Ommers HashThis is the Keccak-256 hash of the ommer’s list portion of this block. 
  3. BeneficiaryThis is the 20-byte address to which all block rewards are transferred. 
  4. State RootThis is the Keccak-256 hash of the root node of the state trie, after a block and its transactions are finalized. 
  5. Transactions RootThis is the Keccak-256 hash of the root node of the trie structure populated with each transaction from a Block’s transaction list. 
  6. Receipts RootThis is the Keccak-256 hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block. 
  7. Logs BloomThis is the bloom filter composed from indexable information (log address and log topic) contained in the receipt for each transaction in the transactions list portion of a block. 
  8. DifficultyThis is the difficulty of this block – a quantity calculated from the previous block’s difficulty and its timestamp. 
  9. NumberThis is a quantity equal to the number of ancestor blocks behind the current block. 
  10. Gas LimitThis is a quantity equal to the current maximum gas expenditure per block.
  11. Gas UsedThis is a quantity equal to the total gas used in transactions in this block. 
  12. TimestampThis is a record of Unix’s time at this block’s inception. 
  13. Extra DataThis byte-array of size 32 bytes or less contains extra data relevant to this block. 
  14. Mix HashThis is a 32-byte hash that verifies a sufficient amount of computation has been done on this block. 
  15. NonceThis is an 8-byte hash that verifies a sufficient amount of computation has been done on this block. 
  16. Ommer Block HeadersThese are the same components listed above for any ommers.

Block Footer

Transaction Series – That’s the block’s only non-header content.

Block Number and Difficulty

Note that is the difficulty of the genesis block. The Homestead difficulty parameter is used to affect dynamic homeostasis of time between blocks, as the time between blocks varies, as discussed below, as implemented in EIP-2. In the Homestead release, the exponential difficulty symbol, causes the difficulty to slowly increase (every 100,000 blocks) at an exponential rate, and thus increasing the block time difference, and putting time pressure on transitioning to proof-of-stake. This effect, known as the “difficulty bomb”, or “ice age”, was explained in EIP-649 and delayed and implemented earlier in EIP-2, was also modified in EIP-100 with the use of x, the adjustment factor, and the denominator 9, in order to target the mean block time including uncle blocks. Finally, in the Byzantium release, with EIP-649, the ice age was delayed by creating a fake block number, which is obtained by subtracting three million from the actual block number, which in other words reduced the time difference between blocks, in order to allow more time to develop proof-of-stake and preventing the network from “freezing” up.

Account Creation

Account creation definitively occurs with contract creation. Is related to: init. Lastly, there is the body which is the EVM-code that executes if/when the account containing it receives a message call.

Account State

The account state consists of details of any specific account during some specified world state. The account state is made up of four variables:

  1. Nonce – The number of transactions sent from this address, or the number of contract creations made by the account associated with this address. 
  2. BalanceThe amount of Wei owned by this account. Stored within the state database as a key/value pair. 
  3. Storage_root – A 256-bit (32-byte) hash of the root node of a Merkle Patricia Tree that encodes the storage contents of the account. 
  4. Code_hashThe hash of the EVM code of this account’s contract. Code hashes are stored in the state database. Code hashes are permanent and they are executed when the address belonging to that account receives a message call.

Bloom Filter

The Bloom Filter is composed of indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list.

 

Asma on EmailAsma on FacebookAsma on GithubAsma on GoogleAsma on LinkedinAsma on Wordpress
Asma
Blockchain Research Analyst at Nvest
I am a BE graduate, specialized in Computer Science. Currently, pursuing ME in Computer Networks from UVCE. Also, I am working as a Blockchain Research Analyst at Nvest.
WhatsApp chat