Updates for ver 0.2: Fixed Grammatical errors & Beige paper broken links

This series will follow my journey into exploring Ethereum from the ground up. I am assuming that you have some knowledge of coding to understand some but not all of the concepts. Note, I will be updating this post will multiple versions with additional information as I see fit.

World Computer AKA The Ethereum Blockchain

Ethereum is a complex piece of software mixed in with game theory/economics. If you are trying to understand what’s going on underneath, it’s mind-boggling and sometimes tiresome. I still find it challenging to find resources to understand the specifications. Instead of finding one, I thought of writing one. This tweet from Mark Beylin summarizes my point at best

The best way to understand Ethereum is to understand the definition as mentioned in the white, beige, yellow papers. All of these papers point to the same specifications with varying details, white being at a higher level and Yellow being more detail specification. Throughout this series, we will be referring mainly from Beige Paper(BP) and some elements from the Yellow Paper(YP). So let us stick with BP definition for now and begin our journey.

Tip: I would recommend you to have the BP and YP open as a PDF in two windows and referring to the specifications as an when needed.

What is Ethereum?

Ethereum imho is a combination of a Global State and a Virtual Machine. Ethereum = World State+Virtual Machine.

What is the World State?

World State refers to as The Universal truth at a given snapshot for this system. Let’s look at it from a different angle, say this State Data is available, who will be using it, and what can they do? Hold that thought for now. Let’s look at a skeleton code for the some of the API’s available for the World State Database. Let’s assume there are two essential function(s) are available getGlobalState() and isValidGlobalState() , the skeleton code for the APIs might look like the code snippet below.

function getWorldState(){

return stateInfo ;

} function isValidWorldState(obj stateInfo){

return true/false ;

}

The first function returns the Truth then. Meaning you can trust what you are getting, and nothing has tampered. Does the next service verify if the state it has received is accurate ?. Let’s say some unknown player passes say a Current State XYZ and you want to ensure Current State XYZ is reliable to use isValidWorldState(XYZ) and you should get true if not yikes! Alert Alert.

Now next comes the question? State XYZ must be stored in a hard drive and should be in a format recognized by another set of functions which will read and add a new state. Notice that I said read and add and not update, We don’t have an update function as almost all Blockchains are append-only and cannot modify the current state.

Let’s explore some possible functions for our VM. According to Yellow Paper, a VM is a subset of a State Transition Function. Have a look at the handy reference.

Formally: σt+1 ≡ Υ(σt, T) from the yellow paper. More details provided below

function addNewState(obj nextState){

verify currentState;

newState = currentState+nextState;

return newState;

}

reading of the state function can look like this:

function readState(obj currentState){

verify currentState;

return nextState;

}

Mining is also a part of the State Transition Function and the YP, here is a handy table I am creating to explain away the proofs.

Tip: a handy reference to the symbols used in YP and Appendix -A below

Yellow Paper Formal Spec

We can have another function called verifyState() among other things, my point is to keep it simple, by using these state transition functions the single computer aka Virtual Machine(VM) executes these instruction in those functions and ensures that everything is in order. Let me stop here and quote the Abstract from the Beige-paper (BP)

“The Ethereum Protocol is a deterministic but practically unbounded state-machine with two basic functions; the first being a globally accessible singleton state, and the second being a virtual machine that applies changes to that state.” does it makes sense?

Before we move on, remember we talked about “Virtual Machine” (from the previous section ) aka “VM.” VM function verifies the World State and changes the state by adding a new block. So imagine you are renting out our computer to perform some computations.

Nothing comes for free, the virtual machine cannot run some arbitrary code, the code needs to be vetted, data has to be verified, and the system needs to exit carefully, etc. So every code provides a specific fee for execution time. The price is Ether. Let us pause here and think about it for a while.

What is Ether?

So let us look back at what Ethereum is. Ethereum is a functional global computer, so to run this universal computer we need to pay some network cost, and that network cost unit is Ether: Ξ

Ξ further grouped into the following units. Wei (Ξ 10^-18) is the smallest unit as you can see a Finney can be denoted as Wei (Ξ 10^-03) or 0.0010000000000000000 Ether

What if there is no pay to play concept in Ethereum? If I was a bad actor, I can quickly bring down the system with one infinite loop and consume all the resources, and the VM cannot execute the next instruction set. Ethereum prevents this by making people pay for it; the idea is once you pay for something you are careful and will not harm the system. I am oversimplifying the concept, but you get the drift. In the next section we will talk about what is the “Truth” aka Global State and how can you verify the Global State and what is data in the Global State

What is this data in the World State?

Put the World State is divided by blocks; each new block is a new Global State. Blocks contain a mapping of Addresses and Account States using a serialization /deserialization algorithm called the Recursive Link Prefix(RLP) and stored as a Patricia-Merkle Trie in a Database Backend which maintains the mapping of a Byte-array to Byte-array. We will delve into what is an RLP in the next episode.

So the World state = Total Hash of the hashes of database relationship in the State Database. I am going to stop here and stretch; I suggest you do the same.

Let us say we have a key, value pair array, LHS is the mapping of the state, i.e., Bytearray ->Bytearray. RHS is the actual mapping itself

state 1 = [key1, val1]

state 2 = [key2, val2]

state 3 = [key3, val3] Global State = hash( [ [state1], [state2], [state3]...] )

Quoting from the yellow paper “The state can include such information as account balances, reputations, trust arrangements, data about the information of the physical world; in short, anything that can currently be represented by a computer is admissible.”.

Remember the functions which we talked about and one of the parameters in those functions(s) referred to as “obj”, now let us expand “obj” a little bit, “obj” is an acronym for “Object”. An object in the Ethereum world is a byte array. E.g., ’s of an object which is essentially a byte array.

“Dog” [“D”,”o”, “g”], [[], “Dog”, [“Cat”]]

According to BP the Bytearrays are stored in Special Format called the Recursive Link Prefix(RLP). We touched on it briefly before. Let us dig a little deeper into what this RLP fuss is all about in the next post.

Let’s recap what we discovered this week.

Ethereum is a World Computer. Ethereum is a combination of A Singular World State+A Virtual Machine World State is a Collection of all States. A State is a collection of Blocks. The World State is stored as a Patricia Merkle Trie as per the RLP Prefix spec in a mini Database. Only a Virtual Machine can add a new State. The Virtual Machine needs fuel to execute instructions, and the fuel is ‘Ether’ to prevent rogue actions.

In the next section, we will delve into what is RLP, and we will be using some code examples.

APPENDIX- A: YP Symbols

Yellow Paper Symbols