This part of the series will cover section 2 of the Yellow Paper, which explains world state.
I assume you've already gone through conventions defined in Part 0. If you haven't yet, I highly recommend you to go check it out first.
World State
Ethereum can be considered as a transaction based state machine. It begins with a genesis state and by executing transactions, it goes to a new state - a valid one enforced by a set of rules.
The state of this state machine is termed - "world state" and denoted by
| WORLD STATE |
Address AccountState
----------------------------------------------------------------
address1 -> accountState1(nonce, balance, storageRoot, codeHash)
address2 -> accountState2(nonce, balance, storageRoot, codeHash)
address3 -> accountState3(nonce, balance, storageRoot, codeHash)
.
.
That brings us to the first equivalence from paper -
where,
is the world state at some time is a single transaction tuple with multiple constituents is the state transition function
When given the current state
Keep in mind that
Now, comes the block. Isn't it that Ethereum jumps to a new state, when a block is mined? Where does the block fit in the equation?
Well, yes a new state is indeed generated when a block in finalized by mining. In fact, the individual state transitions corresponding to each transaction in the block (
and so on...
Above three can be combined to be written as:
Now, we introduce another state-transition function
where,
is the world state at time is a single block, represented as a tuple is the state transition function at block level
The block is a tuple with multiple components, one of which is a list of transactions (precisely, a list of transaction tuples),
which is same as-
(Note: ellipsis before and after the list of transactions,
In other words
This might seem a bit confusing, but remember that all of the above are equivalences (
Account State
As said before, the world state,
An account state
-
( ): Nonce is number of transactions sent by this address, if it is an EOA, or it is number of contract-creations made by this address if it is a contract. -
( ): Number of Wei owned by this address. -
( ): A 256-bit hash of root node of a Merkle Patricia Trie data-structure. This MPT structure holds contents of this account. The contents in the MPT are encoded mapping of 256-bit hash of 256-bit keys (aka storage slot) to RLP-encoded 256-bit integers as values (representing the account content). In simple terms, you might know this "content" as contract storage. As expected, only contract accounts can have non-empty storage. EOAs always have empty storage. -
( ): The hash of the EVM code (aka bytecode) of this account. Remember that only contracts have bytecode, EOAs have empty bytecode. Thus, if is the bytecode then, . And , always for an EOA account - meaning for an EOA is always hash of an empty string.
Paper defines a serialization function
where
According to convention then,
Finally, using all the above the paper defines a convenient equivalence:
Note that in the equivalence above, the subscript
We already know that
The equivalence
A non-existent account is defined as:
Whereas an empty account i.e. it has no code (bytecode), zero nonce and zero balance, given as:
An account is dead if it is either non-existent or empty. Mathematically it is same as,
Now, paper defines the world-state collapse function
where,
Remember, that the world-state is a mapping from account address to account states.
This set of items yielded by
It is assumed that account state can either be non-existent or valid if existent. Mathematically,
where,
And that concludes this part of the series! Next part will be all about transactions. Stay tuned!