Understanding the EVM state

The EVM state

A challenging task for the Ethereum VM newcomer is to understand what exactly is the EVM state and what it contains. The main material that needs to be well understood is the Yello Paper.

The Yello Paper essentially says that the world state is a map from addresses to accounts states.

Accounts

In Ethereum, accounts states contain the following fields:

• nonce
• balance
• storageRoot
• codeHash

Side notes and questions:

• The codeHash is not a reference to the code. Is the code accessible from an account or not?
• The storageRoot is just a hash of the account's storage root (which probably contains the code too). It does not seem to be possible to extract any information from the storage using only the storageRoot.
• From the semantics point of view, it looks like the storage and the code need to be somehow accessible from an account state. Probably this is why the KEVM configuration stores these extra-fields explicitly.
• Also, for executable semantics, the state needs to know things about existing accounts; thus, it should hold some kind of list of accounts.

Transactions

In Ethereum, transactions come in two flavors: message calls or contract creation transactions. There are a number of common fields:

• nonce
• gasPrice
• gasLimit
• to
• value
• v
• r
• s

Now, contract creation transactions contain a special field:

• init which is a code fragment which returns body -- the code that will be executed every time when an account receives a message call.

If the transaction is not a contract creation, then it is a message call and instead of init it contains the field:

• data - holding the message call input data.

Side notes and questions:

• It seems that the distinction between the two types of transactions is clear. What is not clear is the link between the EVM state and the transactions. Probably, the EVM state contains a pool o transactions which is enriched with new transactions whenever they arrive from the other nodes.

Transaction execution

An execution of a transaction changes the current state and produces another state. During the execution, a substate which contains some meta-information: the set of the accounts to be discarded following he transaction's completion, a series of logs, the list of touched accounts, and the refund balance. The following steps are performed during the transaction execution:

1. Compute the intrinsic gas
2. Check the validity of the transaction
3. Change the nonce of the account of the sender (this change is done anyway, no matter if the transaction failed or not)
4. Change the balance of the account by subtracting the up-front cost
5. Depending on the message type, perform the specific actions.
6. Determine the amount of gas to be refunded
7. Determine the mining fee
8. Create the new state

Side notes and questions:

• From this section (Section 6 in the Yellow Paper) it seems that blocks also need to be part of the state. However, this is not present in the KEVM approach...

Contract creation

This stage happens in the context of transaction execution discussed above. Thus, the entire list of transaction parameters are visible here.

Steps:

1. Create a new account (plenty of details to be filled in here)
2. Run the init code (this may affect the state)

• handle the gas costs, exceptions

Message call

As contract creation, message call is done in the context of the transaction execution. Thus, the entire list of transaction parameters are visible here, too.

Steps:

1. Compute the first transition state - where the value is transferred from the sender to the recipient
2. Execute the associated code and update gas consumption

• Execution might throw exceptions (8 exceptions that are contracts as well)

Execution model

This is probably the most important section (sec. 9) in the Yellow Paper, since it defines in detail how the system state is altered in the presence of bytecode instructions and an environmental data.

Basics

• The machine word size: 256-bit
• Memory model: word-addressed byte array
• Stack:
  • item size: 256-bit
  • max size: 1024
• Independent storage model: word-addressable word array, non-volatile, part of the system state
• Initially, both storage and memory are filled with zeroes.
• Code is stored in a virtual ROM
• Exceptional execution: stack overflow, invalid instructions

Fees overview

Three circumstances to deduct fees:

• The intrinsic fee (Appendix G)
• The deducted gas for a message call or contract creation
• Fee paid for an increased usage of memory Details are all given in Appendix H.

Execution Environment

It consists in the following components:

• the system state
• the gas for computation
• the address of the account which owns the code that is executing.
• Ia: the address of the account which owns the code that is executing.
• Io: the sender address of the transaction that originated this execution.
• Ip: the price of gas in the transaction that originated this execution.
• Id: the byte array that is the input data to this execution; if the execution agent is a transaction, this would be the transaction data.
• Is: the address of the account which caused the code to be executing; if the execution agent is a transaction, this would be the transaction sender.
• Iv: the value, in Wei, passed to this account as part of the same procedure as execution; if the execution agent is a transaction, this would be the transaction value.
• Ib: the byte array that is the machine code to be executed.
• IH: the block header of the present block.
• Ie: the depth of the present message-call or contract-creation (i.e. the number of CALLs or CREATEs being executed at present).
• Iw: the permission to make modifications to the state.

The execution model computes the resulting state, the resulting gas, the substate, and the resultant output.

Execution overview

TBA!