Ethereum accounts and state - EOAs, contracts and the world state

To understand what really happens in every transaction, you need to know what Ethereum stores. The answer: a table of accounts. Every transfer, contract call and deal creation is a change of records in this table. This article is the foundation for the sections on the EVM and storage.

Two kinds of accounts

An EOA (externally owned account) is an ordinary address controlled by a key (how a key relates to an address). Only EOAs can start a transaction. A contract cannot "wake up" by itself: it runs when an EOA or another contract calls it (what a smart contract is).

The four account fields

Every account on the network is described by four values:

1. nonce - for an EOA the number of transactions sent; for a contract the number of contracts it created. It guards against replay and sets the order of transactions (in a transaction).
2. balance - the balance in wei (the smallest unit of ETH).
3. storageRoot - the root of the data structure holding the contract's persistent memory. Empty for an EOA.
4. codeHash - the hash of the contract's bytecode. For an EOA it is the hash of the empty string.

The bytecode itself is stored separately, and only its hash is recorded in the account.

Units: wei, gwei, ether

Ethereum has no fractional numbers; everything is counted in integers.

Gas prices are measured in gwei. ERC-20 tokens also store integers and have a decimals parameter (USDC has 6, most others 18) (about tokens). So "1 USDC" in a contract is the number 1000000. More on the pitfalls of integer math: integers and rounding.

The world state

The set of all accounts is called the world state. It is a mapping "address → account". It is kept in a special tree structure - the Merkle Patricia trie (what a Merkle tree is). Its root, the state root, is recorded in the header of every block.

Why so complicated? The root is a "fingerprint" of the entire state: changing even one record changes the root. Nodes that compute their root after a block and compare it with the recorded one instantly confirm they reached the same result. That is the consensus check.

How a transaction changes the state

The state changes only through transactions. Each block is a step from the old state to the new:

1. The state of the previous block is taken.
2. The block's transactions are executed one after another (the EVM runs them).
3. The result is a new state and a new state root.

If a transaction is rejected (for example a contract error), its changes are rolled back, but the gas fee is still charged.

How a contract address is derived

A contract's address is computed deterministically, and can be known before creation.

• Ordinary creation (CREATE): the address is the last 20 bytes of keccak256(rlp(sender, nonce)).
• CREATE2: the last 20 bytes of keccak256(0xff ‖ sender ‖ salt ‖ keccak256(init code)). This allows one address on different networks (how Coin-Trust uses it).

That is exactly why the escrow contract has the address 0x6462DDDc0a3D893A7C17f94410e2d27162a390aD identically on Ethereum, Base, Polygon and BNB Chain.

Reading state: free

Reading (eth_call, eth_getBalance) does not create a transaction and costs nothing: the node simply looks into its state. You pay only for changes. That is why the interface can show you deals for free, while a signature and fee are needed only for actions.

Example: what changes when a deal is created

Anna creates an offer with 500 USDC:

1. Anna's (EOA) nonce increases by 1.
2. Anna's ETH balance decreases by the gas payment.
3. In the USDC contract Anna's balance record decreases and the escrow's balance record increases.
4. In the escrow contract a deal record is added to storage and a counter increases.

Four accounts, many records - but all within one atomic operation: either everything applies or nothing.

What to read next

Let us look into the network's "processor": the EVM under the hood. And if you wonder how a contract's data is stored, the storage layout.