Overview — Project 7: Solana Mini-Chain

In Project 6 · the Ethereum mini-chain you built a world computer: one shared, mutable state machine that runs arbitrary contracts, paying gas for every step. It is enormously more capable than Bitcoin’s calculator — but it bought that power with a hard constraint you may not have noticed while building it. ethmini’s WorldState::apply runs transactions one at a time, in order, and it has to: a contract holds its own hidden storage, so you can’t know which state a call will touch until you run it. Two transactions might both poke the same storage slot, so the only safe move is to process them sequentially. That single fact — transactions are serialized because their footprint is unknown — is the throughput ceiling the third branch of the family tree set out to smash.

solmini is a Solana-style mini-runtime, and Solana asked a ruthlessly narrow question: what if we optimized almost everything for raw throughput and low cost per transaction? Not “the most decentralized money” (Bitcoin) and not “the most expressive shared computer” (Ethereum), but the most transactions per second per dollar. Getting there took two ideas you’ll build here — a clock that lets the network agree on order without talking (Proof of History), and a transaction format that declares its footprint up front so the runtime can run thousands of them in parallel (Sealevel) — plus a deliberately aggressive bet on hardware. By Day 30 you’ll connect all of it to the real Anchor programs you’ve already written.

What you’re building

A small Proof-of-History clock + parallel-execution runtime — a mini-Solana. The demo binary builds a verifiable clock, runs a mixed batch of transactions, and then races a big independent batch sequentially against the scheduled-parallel path:

   $ cargo run
   == Proof of History — a verifiable clock ==
     produced 5 entries over 190 sequential hashes
     verify(genesis, entries) = true  (recomputes every hash)
     verify after flipping one byte = false  (the chain is tamper-evident)

   == Accounts + stateless programs ==
     before: alice=100, bob=0
     after:  alice=50, bob=50
     counter state.count = 6

   == Parallel execution — sequential vs scheduled-parallel ==
     1200 independent transfers scheduled into 1 batch(es)
     sequential: 7.1s
     parallel:   1.2s
     speedup:    ~6x  (varies with core count; not a benchmark)

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

   Transaction { program, accounts: [meta…], data }   the declared footprint
       │
   schedule()        conflict-free batches by dependency layering
       │
   run_parallel()    each batch runs across threads (rayon); commit on success
      ╱        ╲
   poh.rs    account.rs + program.rs   the verifiable clock  /  typed accounts + stateless programs

The five days

Day	Page	You build	The idea it forces
26	The throughput problem	the mental model + crate skeleton	what Solana optimizes for; the trilemma trade-off
27	Proof of History	a mini-PoH you can build + verify	a sequential hash chain as a verifiable clock
28	The account model	typed accounts + stateless programs	state lives outside code; declarable footprints
29	Parallel execution	the Sealevel-style scheduler	declare-accounts-up-front → fearless parallelism
30	Capstone & the Anchor bridge	the synthesis + the map to Anchor	why BTC/ETH/SOL all exist, in code you built

Each day teaches its concept, then has you build that slice into the companion crate at rust/solmini/. Type the code, run it, and break it on purpose — a transaction the scheduler refuses to parallelize is as instructive as one it does.

Self-contained on purpose

solmini depends only on sha2 (the PoH hash and account keys), serde/serde_json (typed account data), thiserror (the error type), and rayon (the worker thread pool). No real validator, no networking, no ed25519 signatures, no Tower BFT consensus. We model the two ideas that make Solana fast — the verifiable clock and the parallel scheduler — and we are honest, on every page, about what we simplify (SHA-256 keys instead of ed25519, a hash-derived clock instead of a true VDF, an O(n^2) conflict scan instead of Solana’s account-lock machinery).

Why a parallel runtime is the right teacher

Every earlier project in this playbook touched concurrency from a different angle. kvlite made one data structure safe to share across threads with Arc<RwLock<T>>. solmini asks the follow-up question that real systems live or die on: how do you run thousands of independent units of work in parallel without a lock becoming the bottleneck? The answer Solana found — and the one you’ll build — is to make conflicts visible before execution so the runtime only ever hands disjoint data to each thread:

• Independent by declaration → a transaction lists the accounts it reads and writes. The scheduler can then see, without running anything, which transactions can’t possibly interfere — and run those on different cores. This is “shared XOR mutable” lifted from variables to accounts.
• Stateless programs → because program code holds no state (all state is in external accounts), a transaction’s footprint is knowable up front. This is the design choice Ethereum’s contract-holds-its-storage model forecloses, and it’s why Solana can parallelize where Ethereum can’t.
• A clock instead of a conversation → ordering thousands of transactions per second is itself a bottleneck if validators must message each other about when things happened. Proof of History replaces that conversation with a hash chain every validator can verify independently.

The thread

This project runs two questions at once. 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 fearless parallelism at scale: rayon’s par_iter_mut hands each worker thread a disjoint &mut to its own transaction’s accounts, and because the scheduler only groups conflict-free transactions, the compiler’s “shared XOR mutable” rule and your scheduler enforce the same guarantee at two levels — so the data race that “just run these on threads” invites in C is, once again, unrepresentable. And the project’s own question — what problem did Solana solve? — is throughput and cost: a single global state machine engineered to settle tens of thousands of transactions a second for a fraction of a cent, and the trade-offs (hardware, centralization pressure, liveness) it accepted to get there.

By Day 30 you’ll set all three mini-chains side by side and answer, in code you wrote yourself, why Bitcoin, Ethereum, and Solana all exist — and then map solmini onto the real Anchor programs in your solana-contracts/.

Begin with Day 26 · The Throughput Problem →