Parallel Execution — Sealevel

The book asks one question over and over: how do you build a single global state machine that runs at hardware speed without falling apart? The account model did the hard preparatory work — it pulled state out of programs and into named, external accounts, so a transaction’s footprint is knowable before it runs. That was a promise. This part cashes it in.

Because here is the uncomfortable truth every blockchain runs into: a single global state machine can only go as fast as it can execute transactions, and the obvious way to execute them — one at a time, in order — leaves every core but one idle. That is the ceiling. This part is about the one idea that lifts it: Sealevel, Solana’s parallel execution engine. Where the account model made the footprint knowable, Sealevel is what uses that knowledge to run non-conflicting transactions side by side across cores.

The core question: why serial is the ceiling

A state machine advances by applying transactions to state. If you apply them one at a time, your throughput is bounded by a single quantity: how many transactions one CPU core can run per second. Buy a 64-core machine and 63 cores watch the one that’s working. That is not a tuning problem you can fix with a faster loop — it is the fundamental shape of serial execution, and it is the same ceiling every account-model chain hits by default.

The EVM sits squarely under this ceiling, and not by accident. On Ethereum a contract is its code and holds its own storage inside itself, so the runtime cannot know which storage slots a call will touch until it actually runs the call. When you can’t tell in advance whether two calls collide, you have no choice but to assume they might — and run them serially. The serial baseline is not a lazy implementation; it is what hidden state forces.

   Serial execution — the ceiling
   ──────────────────────────────
   core 0:  [ tx0 ][ tx1 ][ tx2 ][ tx3 ][ tx4 ] ...
   core 1:  ······································ idle
   core 2:  ······································ idle
   core 3:  ······································ idle

   throughput = 1 core's transactions/second, no matter how many cores you own

The one-line thesis of this part

Here is the whole idea, stated once and then proven page by page:

If every transaction declares the accounts it will read and write, the runtime can run any set of non-conflicting transactions in parallel — across cores, and in principle across a GPU.

That is Sealevel. The name is a pun worth keeping: like the SIMD hardware it targets, it wants to apply the same program to many independent pieces of state at once, the way a GPU shades a million pixels in parallel. The precondition is the declaration. Two transactions that touch disjoint accounts can never interfere, so they can run at the same time. Two that write the same account must be ordered. The account model handed us exactly the information needed to tell those two cases apart before execution — and that is the difference between serial and parallel.

   Sealevel — declared footprints unlock parallelism
   ─────────────────────────────────────────────────
   tx0 writes {A}      tx1 writes {B}      tx2 writes {A}

   core 0:  [ tx0(A) ]  [ tx2(A) ]     ← tx2 waits for tx0 (same account)
   core 1:  [ tx1(B) ]                 ← independent, runs alongside tx0

   the footprint is DECLARED, so the runtime sees the collision before running

The teaching order

Read the pages in order. Each one forces a single idea, and each grounds in the book’s companion runtime, solmini — the same three-field Account, the same Transaction that carries a declared Vec<AccountMeta>. We start at the EVM’s serial baseline, earn the conflict rule, use it to schedule, run a batch in parallel, and end at the honest ceiling the model cannot escape.

#	Page	The idea it forces	Grounded in
2	Why the EVM Runs Serially	hidden contract storage makes a footprint unknowable, so calls must run one at a time	the Ethereum contrast; contract = code + its own storage
3	Declared Footprints: The Account-Locks Design	a transaction names its accounts and their access mode up front	AccountMeta { key, is_writable }, Transaction.accounts
4	The Conflict Rule: Shared XOR Mutable	two transactions conflict iff they share an account and one writes it	conflicts(a, b) — the borrow checker’s rule, lifted to accounts
5	Scheduling Into Conflict-Free Batches	dependency layering groups the independent, orders the contended	schedule(txs) — batch(i) = 1 + max{batch(j) : conflicts}
6	Executing a Batch in Parallel	disjoint owned working sets + commit-on-success = safe, atomic parallelism	run_parallel with rayon’s par_iter_mut
7	The Hot-Account Ceiling	one hot writable account forces serial execution — Amdahl’s floor	50 increments → 50 batches; local fee markets
900	Revision — Sealevel	the part compressed to what you must retain	the whole thread in one page

By the end you will be able to look at any Solana transaction’s account list, split it from its neighbours into “can run together” versus “must wait,” and explain — with real Rust in front of you — exactly why the parallel result is byte-for-byte identical to the serial one.

What this part does not cover

Keeping scope honest matters, because Sealevel is only one leg of the throughput story. This part is about execution — turning a known set of transactions into new state as fast as the hardware allows. It says nothing about:

• Ordering. In what sequence do transactions arrive at execution? That is Proof of History’s job — the verifiable clock that lets validators agree on order without a round of messages. PoH orders; Sealevel executes. They are companions: an ordering with no fast execution is a slow chain, and fast execution over an unagreed order is not a chain at all.
• Consensus. How the network agrees which produced state is canonical (Tower BFT, forks, finality) belongs to Consensus.
• Networking. How transactions physically reach a leader and how blocks propagate (Gulf Stream, Turbine, the validator pipeline) is a separate part.

Sealevel assumes it has been handed an ordered batch of transactions and asks one thing only: how fast can I turn these into new state? That deliberate narrowness is what lets us answer it cleanly.

The thread

What does building Sealevel force you to understand? That parallelism is not something you add to a runtime — it is something you reveal. The independent transactions were always independent; serial execution simply never looked. Declaring each transaction’s account footprint up front is what lets the runtime see the independence before running anything, and once it can see it, running non-conflicting work across cores is almost mechanical. This is the direct payoff of the account model’s promise, and the direct enabler of hardware-speed execution — the throughline of the whole book. The declaration is the hinge everything turns on.

The first job is to feel the ceiling for ourselves — to understand exactly why hidden state condemns the EVM to one core at a time: Why the EVM Runs Serially.

Check your understanding

1. A single global state machine “can only go as fast as it can execute transactions.” Explain why running transactions one-at-a-time is a ceiling and not just a slow implementation you could optimize away.
2. State the one-line thesis of this part. What single piece of information must each transaction provide for the thesis to hold, and where did the account model already arrange to provide it?
3. Why is the EVM’s serial execution a consequence of how it stores state, rather than a design mistake? Contrast it with what Solana’s account model exposes.
4. Proof of History and Sealevel are called “companions.” What distinct job does each do, and why is neither one sufficient on its own?
5. Name two things this part deliberately does not cover, and say which other part of the book owns each.

Show answers

1. Serial execution bounds throughput by a single quantity — how many transactions one CPU core can run per second — so every other core sits idle. That is the fundamental shape of running transactions in sequence, not an inefficiency in the loop: no amount of tuning a one-at-a-time executor gives you more than one core’s worth of work. Escaping it requires running different transactions on different cores at once, which is a different design, not a faster version of the same one.
2. If every transaction declares the accounts it will read and write, the runtime can run any set of non-conflicting transactions in parallel. The required information is each transaction’s account footprint (which accounts, and whether each is written). The account model already arranged this by moving state out of programs into named, external accounts, making the footprint knowable up front.
3. On Ethereum a contract holds its own storage inside itself, so the runtime cannot know which storage a call touches until it executes the call. When you can’t tell whether two calls collide, you must assume they might and run them serially — hidden state forces it. Solana instead exposes state as named external accounts a transaction lists in advance, so the runtime can see collisions before executing and run the independent ones in parallel.
4. Proof of History produces a verifiable ordering of transactions that validators agree on without extra messaging; Sealevel executes an already-ordered batch as fast as the hardware allows. Neither suffices alone: an agreed order with slow execution is a slow chain, and fast execution over an unagreed order is not a chain at all. Ordering + fast execution together are what a hardware-speed state machine needs.
5. Any two of: consensus (how the network agrees which state is canonical — owned by Consensus); ordering (the sequence transactions arrive in — owned by Proof of History); networking (how transactions reach a leader and blocks propagate — owned by the validator pipeline). This part covers execution only.