T5 · The EVM Account Model

A Real-World Problem

Your product needs a team vault: funds may leave only when two of three people agree.

At the design meeting, one person says, "Receive funds at a multisig wallet address." Another says, "Deploy a vault contract." From outside, the outputs look identical: each is 40 hexadecimal characters after 0x, can receive funds, and has a balance visible in a block explorer.

You ask three questions, but nobody answers clearly:

• Can this address initiate a transaction on its own?
• Can a transfer into this address fail?
• Who can change the rules at this address?

There is an even more basic question: **where do deployed contract code and the data it remembers actually live?**Can you read them as you would read a database?

What distinguishes two addresses that look identical?

Thought Experiment

Imagine the entire chain as one globally shared computer with one enormous table.

Each row's key is an address. Its value has four fields:

nonce         a counter
balance       balance
codeHash      hash of a piece of code
storageRoot   hash of this address's own small table

The entire distinction is whether codeHash is empty.

If it is empty, the address is the location controlled by a key. Its owner can sign and initiate transactions with a private key, and its small table is always empty.

If it is not empty, the address holds code and its own small table. It cannot initiate anything by itself. When someone calls it, the code runs and can read or write that table.

Now derive three things:

**First: this computer has no clock.**No cron, timers, or background threads. Its whole life is "someone sends a transaction → execute → state changes → wait for another." It is completely still between transactions.

Second: every computation on this computer costs money. Every node worldwide runs the same code and stores the result, so each operation has a price. Writing to the small table is especially expensive because every node must retain that data permanently.

**Third: only the first kind of address can pay to start the process.**A contract account has no private key and cannot sign. Every execution path ultimately starts with a transaction signed by a private-key holder. Complex contracts move only because that path pulls them into action.

Return to the opening problem. The two solutions are not interchangeable: the third field in that table differs, changing whether the address can act, whether code runs when funds arrive, and where its rules live.

Your Decision

Requirement: a deposit contract should pay depositors interest once a day. How do you build it?

What Happens

The four options share one rule: every state change needs a private-key holder to sign a transaction and pay for the change.

Two broader lessons follow:

**1. "Who pays?" is a product decision, not an implementation detail.**Placing the cost on a party changes the shape of the feature. If you want zero fees for users, you absorb them and inherit a hot wallet and operations work.

2. Gas constraints shape contract data structures. "Loop through all users" is one ordinary backend loop but an on-chain transaction likely to fail. Cumulative indexes, lazy settlement, and Merkle lists all arise from that constraint.

Build a Model

One table, four fields:

address → {
  nonce         EOA: transactions sent; contract: contracts created
  balance       native coin balance in wei
  codeHash      empty → EOA; nonempty → contract account
  storageRoot   root of this address's storage tree
}

Compare the two account types:

The last two rows answer the vault question. Sending native coins to a contract may fail, particularly if it has no way to receive them. The transfer then reverts while the fee is still charged, as T3 explained.

What storage looks like:

Every contract has its own address space. Slots start at 0, and each holds 32 bytes. Layout follows deterministic rules:

**There are no truly private variables on-chain.**Solidity's private prevents other contracts from accessing a variable through code, but anyone off-chain can read its slot directly. A Real-World Case below shows a costly failure from assuming otherwise.

How gas is priced:

A transaction's components, roughly from more expensive to less:

Write a storage slot from zero to nonzero    most expensive: every node stores new data forever
Modify a nonzero storage slot                 expensive, but notably less than a new slot
Read a storage slot                           moderate; repeat reads in the same transaction cost less
Compute in memory                             cheap; discarded at transaction end
Read calldata                                 cheapest; it is already in the transaction
Base transaction cost + per-byte calldata    fixed costs independent of your code

Three practical deductions:

1. The first gas-saving priority is fewer storage writes, then fewer storage reads, and only then cheaper computation. Moving one storage write out of a loop may save more than changing a loop from O(n) to O(log n).
2. **The first access to a slot and later accesses within one transaction have different costs.**T8 covers cold and warm access. Measure gas instead of guessing.
3. **Exact prices change with protocol upgrades; do not memorize them.**Remember relative costs and the habit of measuring with eth_estimateGas and actual receipts.

What It Is Called

Hands-on

curl -s -X POST <your-RPC-URL> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode",
       "params":["<an-address>","latest"]}'

curl -s -X POST <your-RPC-URL> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionCount",
       "params":["<a-contract-address>","latest"]}'

curl -s -X POST <your-RPC-URL> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getStorageAt",
       "params":["<a-token-contract-address>","0x0","latest"]}'

curl -s -X POST <your-RPC-URL> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
        "to":"<the-same-token-contract-address>",
        "data":"<four-byte-selector-for-totalSupply>"},"latest"]}'

slot = keccak256( address left-padded to 32 bytes  ++  mapping declaration slot left-padded to 32 bytes )

curl -s -X POST <your-RPC-URL> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getStorageAt",
       "params":["<token-contract-address>","<the-slot-you-calculated>","latest"]}'

AI Lab

Step one:
Break down the gas consumed by one call to this Solidity code into
base transaction cost, calldata, storage reads, storage writes, memory and computation, and logs.
Give a figure and basis for each, plus a total. State which protocol version sets the prices.

Step two:
How much gas differs between the first and second call from the same address?
Which components differ, and why?

Step three:
Suggest three rewrites. Estimate the saving and describe the trade-off for each.

curl -s -X POST <your-testnet-RPC-URL> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["<hash>"]}'

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check