This series will follow my journey into exploring Ethereum from the ground up. I am assuming that you have some knowledge of programming 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: The Ethereum Blockchain
Ethereum is a complex piece of software mixed in with game theory/economics. it can be mind-boggling If you are trying to understand what’s going on underneath and sometimes tiresome. I found it difficult to find resources to understand the specifications. Instead of finding one I thought of writing one.
A good 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 detailed specifications. 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 simply refers to as The Universal truth at a given snapshot for this system. Let’s look at it from a different angle, say a 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 basic 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 at that point in time in other words the function returns the Current State(aka Truth). The second function verifies the if the state is correct, Meaning you can trust what you are getting and nothing has tampered. Does the next function verify if the state it has received is accurate ?. Let’s say some unknown player passes say a Current State XYZ and one should verify the Current State XYZ is accurate 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 that 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 the 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: handy reference to the symbols used in YP and Appendix -A below
We can have another function called verifyState() among other things, my point is to keep it simple, by using these state transition functions the simple 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.”
Before we move on, remember we talked about “Virtual Machine” (from the previous section ) aka “VM”. VM function verifies the World State and change 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 random code, the code needs to be vetted , data has to be verified and the code needs to exit carefully etc etc. So every code which needs to be run should submit a certain fee. The fee is Ether. Lets pause here and think about it for a while.
What is Ether?
So lets look back at what Ethereum is. Ethereum is a functional global computer, so to run this global computer we need to pay some network cost and that network cost unit is Ether: Ξ
Ξ can be broken into the following units. Wei (Ξ 10^-18) is the smallest unit as you can see a Finney can be denominated 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 easily 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 really oversimplifying the idea, 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?
Simply put the data in World State is a state divided by blocks, each new block represents 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's 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 pertaining to 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's expand “obj” a little bit, “obj” is an acronym for “Object”. An object in 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. Lets 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
References:
https://github.com/benjaminion/YellowPaper_CheatSheet/blob/master/YPCheatSheet.pdf
