Ethereum Primitives #1.2
Tags: Ethereum, Eth, Ethereum Blockchain

In fact, a lot of things are Turing complete by accident, for example, Minecraft. See here

Consensus algorithm. Ethereum uses Nakamoto Consensus. From yellow paper this is

sequential single-signature blocks, weighted in importance by PoW to determine the longest chain and therefore the current state

since Ethereum will be moving to PoS Casper algorithm, we will not dwell into this area too much

Economic Security. Achieved with the PoW Ethash algorithm, to determine the difficulty of finding the block and thus obtaining ether. This will be replaced by PoS, so we will skip this part too

Achieved with the PoW Ethash algorithm, to determine the difficulty of finding the block and thus obtaining ether. This will be replaced by PoS, so we will skip this part too Clients. This is the software that is run by nodes (computers /servers). Clients are open-source software implementations of all of the above. When writing this (26/08/2020) the most popular client is geth (go-ethereum)

used from ethernodes.org

it is important to note that

(i) the higher the number of distinct clients (e.g. geth, besu, nethermind, and so on) = the more fault-tolerant the network is. Imagine there is a serious bug somewhere in geth and 80% of all nodes use this client!

(ii) ideally uniform distribution of the client users. In other words, if there are 10k nodes and there are 10 distinct clients, then we want 1000 nodes running client #1, 1000 nodes running client #2 and so on

This is not the case in practice, as can be seen from that piechart

Data structures. Finally, the precious of this article: Modified Merkle Patricia Trie

precious Modified Merkle Patricia Trie

There is so much confusion about this data structure, that it was my duty as the disseminator of the Ethereum deep knowledge to dwell into the depths of the Fangorn Forest

The best resource for this is the Learn tab here

I will outline the main points here. First, some definitions

Trie — a special form of N-ary trie. This means that each node can have up to N children. See the learn tab here for more

Radix Trie — Trie with a better space complexity. It can “skip ahead”. See the learn tab here for more

Merkle Trie — Patented in 1979 by Ralph Merkle. This data structure was created to cryptographically verify the integrity of the stored data. Here is a screenshot from Vitalik’s Ethereum whitepaper

merkle trie

As you can see from the above, if someone tries to tamper with the data and tries to obtain the ring to rule them all that they don’t have out of the ether, then anyone can verify that the node containing the ring is not valid, and so no, let Sauron have it… Once again, for more info go to… You already know the drill

Modified Merkle Trie — this data structure builds on the above, to better serve Ethereum’s stack. The modification is that we now have three types of nodes. This iteration helps us save on space without sacrificing the time complexity too much

Note the synonyms

Trie, prefix trie, digital trie

Radix Trie (sometimes branching factor is specified, for example, Radix 2 Trie. Meaning each node has up to 2 child nodes)

Merkle Trie, Patricia Trie, Hash Trie

Modified Merkle Trie, Merkle Patricia Trie, Modified Merkle Patricia Trie

Use cases

Trie — spell checkers, auto-complete, longest prefix matching, automatic command completion, network browser history

Radix Trie — associative arrays, IP routing

Merkle Trie — in distributed systems for efficient data verification, torrenting, version control

Modified Merkle Trie — Ethereum ;)

This is how a Modified Merkle Patricia Trie looks like

modified merkle patricia trie. Figure G. Source: Lee Thomas, https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture

Please, study the above carefully before moving on

It is an optimized (to better suit Ethereum’s stack) Merkle Trie

We have three distinct node types

(i) extension node

used to “skip ahead” if there is a shared nibble path

(ii) branch node

(key, value) bindings in Ethereum are rlp encoded and stored in bytes32 data type, represented with hex characters, also known as nibbles. The reason why we have 0,1,2,…,f is precisely to represent each nibble (each hex character)

(iii) leaf node

has no children, and will contain the value of the path leading up to it. In principle, the hashes for verification must be computed using these nodes (I have not checked this)

The above node types are required to improve on the space and time complexity of Ethereum’s data storage layer. We are saving on the space complexity by not needing to have a node per each nibble, instead, we store “common prefixes”. This introduces a bunch of problems, but these are easily solvable. Learn tab here :) Time complexity is improved because we don’t have to traverse every single nibble in the path, we can skip the common prefixes. The question of whether the Modified Merkle Patricia Trie is the most optimal data structure is something worth thinking about too. But not in this article, it is getting too long already. The linked article proposed a Distributed Merkle Patricia Trie, authors of the paper claim to have achieved 20000 transactions per second using a modified Ethereum implementation that incorporates this data structure

It is also worth noting that MPT (Merkle Patricia Trie) is used in all of the trees in Ethereum: Receipt Tree, State Tree, Storage Tree, and Transaction Tree. This once again, if needed will be extended upon later on. If interested, you can learn more about these here