Ethereum from the Ground Up – State Transition Functions and Code Execution

Ethereum Code Execution

Welcome to our series Ethereum from the Ground Up.  Throughout the course of this series, our desire is to explore the underpinnings of the 2nd largest cryptocurrency on the market.  Ethereum learned a few important lessons from Bitcoin and was the first revolutionary cryptocurrency to feature a Turing-complete blockchain.  We’ll get into more the application-level details in later weeks, but for now we first need to establish a solid foundation in the basic elements of Ethereum.  After discussing the atomic elements, we will be able to build our understanding and fully appreciate the system as a whole, including the facets Ethereum users encounter on a daily basis.

            Last week, we took the time to focus on what Ethereum is.  This included accounts, transactions, and messages among a few smaller items.  This week, we will take a look at how the elements interact.  There are three major areas to tackle in this sphere – Ethereum state transition functions, actual execution of code in contracts, and the blockchain coupled with how mining works.  We’ll take a look at the first two this week and discuss the blockchain / mining topic next week.

State Transition Function

            Alright, what is an Ethereum state transition function?  Let’s take each word individually and then try to understand what they mean together:

  • State – this represents the current condition or status of the network.  Ethereum has two major states, including world states and account states (which we’ll discuss below).
  • Transition – the easiest way to think about this is the state x converting or changing state to x’ such that .  The element x stays the same, but its current condition has been altered.
  • Function – a function performs the operation of altering the state’s current condition.

So, putting these all together, a state transition function is an operation that transforms the current condition of an entity in Ethereum (in our case either an account state and/or the world state).

            No problem, that makes sense.  But what about the two different states that were mentioned above?  Let’s start with the world state.  The world state of Ethereum is the current mapping between accounts and their account states.  Note that this is not stored on the blockchain but rather is stored in a state tree.  There’s an endless rabbit hole to enter here, but suffice it so say, 1) the world state of Ethereum is always changing when accounts perform transactions, and 2) this ever-changing state is always accounted for in the state tree.  It’s also interesting to realize that anyone can discover the current balance of an account or state of a smart contract by querying the world state tree.  If you really want to know more about this, the Ethereum Yellow Paper has all the details (in excruciating detail, no less 😊). 

Account State

            Now for the account state.  There’s not too much more to say about this than what we previously discussed in the last article.  We mentioned the two types of accounts, externally owned accounts and contract accounts, and essentially their state is just the current data held within the account.  In summary, the world state is based on accounts and their transitions while an account state is only concerned with its own data in flux via some modification.

            We are now ready to discuss the state transition function since we understand both of the aforementioned states.  See Figure 1 below for a depiction of such a function (taken from the Ethereum White Paper):

Figure 1:  Ethereum State Transition Function

Below is a condensed version of the state transition function.  Nerd alert:  the technical depiction of this function is  (similar to our example with x and x’ from earlier).

Function Layout

  1. Check the transaction…
    1. Is it well-formed (i.e., does it have all the values it should)?
    1. Is the signature valid?
    1. Does the nonce match the nonce in the sender’s account?
    1. If these are true, continue.  If not, throw an error.
  2. Calculate the transaction fee (STARTGAS * GASPRICE).  Deduct this amount from the sender’s account while incrementing the sender’s nonce. 
    1. If the sender doesn’t have enough gas, stop and throw an error.
  3. For all of the bytes in the transaction, deduct a certain amount of gas to pay for the transaction.
  4. Transfer the value to the receiver’s account.  There’s a little logic that goes on here:
    1. If the receiving account exists, everything is good to go.
    1. If the receiving account does not exist, create the account (remember, this would be an externally owned account type).
    1. If the receiving account type is a contract, run the contract’s code until it finishes or the transaction runs out of gas.
  5. If something went wrong trying to run this, put everything back the way it was originally (except the miner still gets mining fees). 
  6. And finally, if everything was okay, return unused gas to the sender and send the miner any mining fees accrued. 

That’s basically it.  It’s pretty simple if you look at it in total:  send an amount or run some code, deduct gas as needed, and pay the miner.  Of course, there are always slight nuances to everything, but this sums it up from a high-level point of view.

            But wait, it makes sense to transfer Ether from one account to another, but what does it mean to run code in a contract?  Great question and great timing!  You must have known that our next section is going to discuss code execution!

Virtual Machine Code

            “Ethereum virtual machine code” or “EVM code” is the language that powers contracts on Ethereum’s blockchain.  (For those of you computer scientists reading, EVM code is a low-level, stack-based bytecode language similar to machine code used in standard operating systems).  This code essentially runs a while loop (in software parlance) that continues executing the same operations over and over until commanded to stop or return to some calling parent function.  During the performance of operations, the code has access to three locations for storage:

  1. Ethereum incorporates a stack for calling functions just like most programming languages; the stack operates as a LIFO (last-in-first-out) buffer with push and pop functionality.
  2. An infinitely expandable memory base storing data in a byte array.
  3. The contract’s long-term storage (similar to a computer’s hard drive).  These key/value pairs retain information in the contract while the stack and memory are reset after all computations have been performed.

EVM Code Operations

EVM code operations are capable of achieving highly complex functionality but are themselves actually quite simple (if you are at all familiar with standard machine code, you’ll recognize many of the same operations in EVM code as you might writing low-level code for Windows or Linux).  Let’s break this down a little:  a tuple of information (or cluster or structure depending on your programming background) exists in the Ethereum virtual machine.  As each computation progresses, a new index is passed to the virtual machine stating which command must be executed. 

For example, if an ADD is performed, two items are popped off the stack, summed together, and pushed back onto the stack.  For each byte of information processed, the total amount of gas in the transaction is reduced by 1.  As we discussed in the last post, this is a key component in mitigating denial-of-service attacks.  If anyone desired to launch such an attack, it would be extremely expensive from a monetary standpoint and would greatly deplete the resources of the attacker.

What Can EVM Code Do?

Due to its Turing-completeness, the EVM code on Ethereum’s blockchain can basically perform any computation that you could imagine (again, just like the parallels with machine code that we have mentioned).   This means that we can add, subtract, multiply, divide, process complex functions, and even loop over code using jump instructions or references to other contracts.  Luckily, Ethereum’s creators have already answered the question about infinite loops – senders have to set a maximum number of transactions to be performed before a miner ever gets the transaction.  This allows for miners to understand that a process may be excessively long and take steps to fend off what might become an attack on the network.

Learn More About Ethereum’s Functions

            Alright, well there you have it – Ethereum’s state transition functions and code execution, while complex, make sense and enable a very powerful blockchain to perform a host of tasks.  Want to learn more about the topics we’ve discussed?  Take a look at a few of these posts:

In the next article, we’re going to take a look at Ethereum’s blockchain and how mining operations actually take place.  These entities may look similar to Bitcoin’s but have incorporated some changes that make for enormous efficiency gains.  We’ll see you in the next article!

1 reply

Trackbacks & Pingbacks

  1. […] Last week, we took the time to focus on two important facets dealing with how elements interact in Ethereum.  We began with state transition functions, which deal with how both world and account states […]

Comments are closed.