Overview — Project 6: Ethereum Mini-Chain

In Project 5 · the Bitcoin mini-chain you built money that moves: a ledger of unspent coins (UTXOs) that transactions consume and recreate, secured by proof-of-work. Bitcoin is deliberately a calculator — it does one thing, transfer value, and refuses to do more. ethmini is the other branch of the family tree. Ethereum asked a bigger question: what if the shared ledger could run arbitrary programs? Not “who owns which coin” but “what is the current state of this world computer, and what code is allowed to change it.” That single ambition — programmable money, a shared state machine anyone can deploy logic to — pulls in a completely different design: accounts instead of coins, a mutable world state instead of a coin set, and a virtual machine instead of a fixed script. You’ll build each piece exactly when the idea demands it.

What you’re building

A small account-model blockchain with its own tiny virtual machine — a mini-Ethereum. By the end the demo binary deploys a real (if tiny) smart contract and calls it, and you can watch the world’s fingerprint change:

   $ cargo run
   == deploy counter ==
     contract at 0xc2a0edf153956a167cfab4f19912eaf4502e6892
     code is 31 bytes
   == call counter x3 ==
     status Success, gas used 312, count now 1
     status Success, gas used 312, count now 2
     status Success, gas used 312, count now 3
   == call counter with too little gas ==
     status Reverted (gas used 50)
     count unchanged: 3 | nonce advanced: 5 -> 6

Under that demo sits a layered design, and each layer is one day’s lesson:

   Transaction        a value transfer, a contract deploy, or a contract call
       │
   WorldState::apply  the state-transition function: validate → mutate → maybe revert
      ╱      ╲
  account.rs   vm.rs   accounts (nonce/balance/storage/code)  /  the gas-metered stack VM
       │
   state_root         one SHA-256 fingerprint of the entire world

The five days

Day	Page	You build	The idea it forces
21	Accounts vs UTXO	the Account record + nonces	mutable shared state; replay protection
22	World state & roots	the state map + state root	state-transition function; deterministic commitment
23	A tiny VM	the mini-EVM interpreter	opcodes as an enum; gas; out-of-gas → revert
24	Smart contracts	deploy + call a counter	bytecode in an account; SSTORE/SLOAD
25	Gas & proof-of-stake	the gas schedule, conceptually	gas as the halting-problem answer; PoS

Each day teaches its concept, then has you build that slice into the companion crate at rust/ethmini/. Type the code, run it, and break it on purpose — a reverted transaction is as instructive as a successful one.

Self-contained on purpose

ethmini depends only on sha2 (hashing), serde/serde_json (serialising state to hash it), and thiserror (the error type). No real EVM crate, no networking, no consensus engine. We model the part that makes Ethereum Ethereum — the account-based state machine and its VM — and we are honest, on every page, about what we simplify (64-bit words instead of 256-bit, SHA-256 instead of Keccak, a sorted-hash state root instead of a Merkle-Patricia trie).

Why an account chain is the right teacher

A UTXO chain is stateless in a precise sense: each coin is created once, spent once, and gone. There is nothing to mutate. The moment you want a contract that remembers — a counter, a token balance, an auction — you need a cell of storage that one transaction writes and a later transaction reads. That is mutable shared state, and holding it correctly is the whole game:

• Mutable + shared → every transaction reads and writes the same world. The state-transition function must be deterministic (every node computes the identical next state) and atomic (a failed contract call must leave no partial writes behind). You’ll feel both as WorldState::apply and its revert path.
• Programmable → contracts are arbitrary code, which means they might loop forever. A public computer can’t run untrusted, possibly-non-terminating programs for free — so every instruction costs gas, and running out halts and reverts. Gas is the price of Turing-completeness.
• Committed → nodes must agree byte-for-byte on the state, so the whole world collapses to a single 32-byte state root. Change one storage slot and the root changes; change nothing and it’s identical.

The thread

This project runs two questions in parallel. The playbook’s recurring one — what does building this force you to understand, and what is Rust’s compiler protecting you from? — sharpens here to atomicity and ownership of mutable state: a contract call mutates a clone, and Rust’s move semantics make “commit the new state or drop it entirely” the natural, hard-to-get-wrong shape, so a reverted call cannot leak a half-written storage slot. And the project’s own question — what problem did Ethereum solve? — is the leap from Bitcoin’s calculator to a programmable world computer: a single shared machine whose state anyone can extend with code, paying gas for every step. Hold both, and by Day 25 a “smart contract” stops being a buzzword and becomes what it actually is: a few bytes of bytecode living in an account, run by a gas-metered loop against a storage map you built yourself.

Begin with Day 21 · Accounts vs UTXO →