Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Solana's runtime, Sealevel, executes non-conflicting transactions in parallel. Two txs that touch disjoint accounts run on different cores; two txs that touch the same account serialize. This is why Solana programs must declare account access in advance — Sealevel uses that declaration to compute the schedule. Protocol design on Solana is partly a parallelism game: protocols that fan out across many accounts can scale far beyond what serial execution allows.
Example: 1000 users swapping on 1000 different Orca pools execute in parallel. 1000 users swapping on the same Phoenix order book all serialize on the order book's accounts.
Use these three in order. Each builds on the one before.
In one paragraph, explain Sealevel's parallel execution model.
Walk me through how Sealevel schedules a batch of 1000 transactions with overlapping accounts.
Design a protocol that maximally parallelises a typically-serial workload (e.g., a global counter).