Lesson 02 · Foundations

The EVM: Accounts, Transactions & Gas

A smart contract is not a microservice. This lesson recalibrates your backend instincts: where code lives, who pays to run it, and why "calling a function" sometimes costs money and sometimes is free.

Why this, now? You can't review a tokenized-fund design — or interview the engineer who built it — without a precise model of what the machine actually is. When your team says "the transfer reverted," "gas was too high," or "we made it a view function," you need to know exactly what each means. This is the vocabulary of every technical conversation you'll have.

One world computer, every node runs it

Ethereum is a single state machine replicated across thousands of nodes. The state is a giant key→value map of every account and its data. A transaction is a signed request to change that state; when a block is produced, every node re-executes every transaction in it and updates to the identical new state. The component that runs the code is the EVM (Ethereum Virtual Machine).1

Mental swap: not "my server runs my code," but "the whole network runs the same code in lockstep, and agrees on the result." That redundancy is the cost you pay for trustlessness (Lesson 1).

Two kinds of account

This distinction is foundational — many people never learn it cleanly.

EOA — Externally Owned Account

Controlled by a private key. A human/wallet. Can initiate transactions. Has a balance, no code. Your MetaMask address is an EOA.

Contract Account

Controlled by its code, not a key. Has a balance and stored code + data. Cannot initiate anything on its own — it only runs when an EOA (or another contract) calls it.

Key consequence: nothing happens on-chain without an EOA kicking it off. A contract can't wake up on a timer. Your tokenized-fund contract just sits there until someone sends a transaction to it. (Automation — "pay coupons monthly" — therefore needs an off-chain trigger or a keeper service. Another off-chain dependency to design.)

A smart contract, concretely

A smart contract is code + persistent storage living at an address. You deploy it once (a transaction that creates a contract account), and thereafter anyone can call its public functions. Here's a stripped-down one — read it as an engineer:

// Solidity — a minimal ownership ledger
contract ShareRegistry {
    // persistent on-chain storage: address → share count
    mapping(address => uint256) public balances;
    address public transferAgent;        // the accountable party

    function transfer(address to, uint256 amount) public {
        require(balances[msg.sender] >= amount, "insufficient");
        balances[msg.sender] -= amount;     // state change → costs gas
        balances[to]         += amount;
    }

    function balanceOf(address who) public view returns (uint256) {
        return balances[who];           // reads only → free to call
    }
}

Two things to notice. transfer modifies storage → it must be a transaction, mined into a block, and it costs gas. balanceOf only reads → marked view, it can be answered by any single node for free, no transaction needed. msg.sender is the authenticated caller — the chain proves who it is via their signature (no req.user to spoof).

Gas: the metering that makes it all safe

Every EVM operation has a fixed gas cost (storage writes are expensive; arithmetic is cheap). When you send a transaction you pay gas used × gas price in ETH. Three reasons this exists:

PurposeWhy it matters to you
Halting / DoS protectionAn infinite loop simply runs out of gas and reverts. The network can't be frozen by bad code.
Resource pricingStorage is scarce (every node stores it forever) so it's costly. This is why architects push data off-chain — on-chain storage is the most expensive resource you have.
Fee marketWhen the network is busy, gas price rises. Cost predictability becomes a real platform concern — and a reason institutions look at cheaper L2s or permissioned chains.

Revert: all-or-nothing

If a transaction runs out of gas or hits a failed require (like the "insufficient" check above), it reverts: every state change is rolled back as if it never happened — but the gas spent up to that point is not refunded. Transactions are atomic. There is no half-completed transfer. (This is a feature you'll lean on: compliance checks that fail simply revert the whole transfer.)

The Marketnode lens

Retrieve it (don't peek)

From memory. Interleaves one Lesson-1 idea on purpose.

1. Your team wants the fund contract to automatically pay coupons on the 1st of each month. What's the architectural catch?
2. Which operation in a contract is essentially free to call and needs no transaction?
3. A compliance check fails midway through a token transfer transaction. What happens to the state?

Primary source

Skim, then bookmark: Ethereum.org — Accounts and Gas & Fees. These two pages are the authoritative version of everything above. (Out of scope for now: gas-optimisation tricks and EIP-1559 fee mechanics — you need the model, not the dial-tuning.)

I'm your teacher — ask me. Want me to walk line-by-line through that Solidity sample, or show how a real ERC-20 differs from this toy registry? Or rehearse "what would I ask a candidate about gas?" Just ask.