WTF is Parallelization?
Ethereum has been our technical concept model the last few articles, so this week we step in to the realm of Solana.
Let's talk about parallelization (w/ pictures).
SHORT VERSION
Given that "parallel" is a pretty common term I won't waste a ton of time on analogies, which are oft drawn from things like "lanes on a highway" or "checkout lines at the grocery store."
If neither of those resonate with you, here is a @jackbutcher-esque visual of what it means in practice:
TLDR:
Things are done at the same time, distributed across resources rather than seeing each one completed fully before starting work on the next one.
For Solana, this design principle is applied at both the transaction-processing and block-propagation levels in order to increase throughput and enhance end-user experience.
If that is good enough to know a major reason why the chain is more performant; later dood(ette)!
If you want to learn how that is achieved, with a detour into how it's being implemented in the EVM world, read on.
LONG VERSION
Hell yea, lets draw pictures about niche technical topics. Here's how we'll structure this:
Glossary
Why aren't all chains parallel?
How does Solana do it?
How are others (Ethereum, Monad) tackling the same problem?
Wrap-up
We'll start simple with determining why this isn't "standard" for the majority of blockchains, discuss how Solana achieves it and then do a brief look into how the EVM is working to implement their own version of it.
Let's dig in.
1. GLOSSARY
State: The current "snapshot" of everything stored on the blockchain - like a giant spreadsheet showing who owns what and all the current values of things. It's like taking a photo of everyone's bank accounts, NFTs, and smart contract data at a specific moment.
Sealevel: The runtime engine of the Solana stack responsible for managing the transaction parallelization rules. Within this, the SVM is evoked concurrently to process transactions separately.
Solana Virtual Machine (SVM): The "rulebook" that defines what's allowed and what's not allowed when running programs on Solana. Like a strict referee that makes sure everyone plays by the same rules when executing smart contracts and transactions.
Ethereum Virtual Machine (EVM): Ethereum's same "rulebook" - but instead of governing "programs" it governs "smartcontracts" and the like.
2. Why aren't all chains parallel?
In short; blockchain was pretty fucking new when Ethereum came to market (2015).
Smartcontracts weren't a thing, existing chains (Bitcoin) used an entirely different transaction model (UTXO vs Account) and, strictly speaking, executing more than one transaction at the same time introduces new problems that were probably easier to just avoid outright.
The priority was to make the thing (the EVM) work. Optimizations could come later. So, they built the plane and kept things simple for troubleshooting.
By the time Solana came around (2017) things were better understood (but still nascent) and no chain had been expressly designed with parallelism in mind. Toly designed Solana that way because, being from the telecom industry, that was just how he understood performant system design - so he built the chain with those principles in mind knowing that's what he wanted to prioritize.
Okay, cool, but...
3. How does Solana do it?
Let's talk about it.
THE PROBLEM
First, we should address why parallel transaction execution can be tough in a blockchain setting: order always* matters.
*when the transactions involve the same blockchain data.
Here's what I mean by that.
Suppose a (crude) analogous situation:
3 people are queued for a single bathroom with 2 resources (sink, toilet).
You, as the doorman, are responsible for controlling who can use this bathroom at any given time.
To keep things simple you just let everyone use it one after another.
Visualized
How the queue is processed:
You let in Mr. Purple, who decides to use the toilet. Unfortunately for us he ate some questionable eggs this morning and clogs the toilet. It no longer works. He exits after 10min.
Next, you let in Mr. Green and, luckily, he only needs to wash his hands. Great - he can proceed unimpeded because he's using a totally separate resource. He finishes up and exits after 10min.
Lastly, you let in Sir Yellowton. He needs the toilet. Unfortunately, because he is accessing the resource after Mr. Purple, his experience is vastly different than if he accessed it before him. Sequence mattered. Regardless, he does what he can and exits after 10min.
Total time for all 3 people to process: 30min.
HOW DOES SOLANA DO IT DIFFERENTLY?
In Solana-land all transactions explicitly call out what part of the blockchain state, or resources, they plan to access (read or write to).
This additional information allows for the sorting and grouping of transactions/people in to non-conflicting groups which ultimately allows the whole group to access the bathroom at the same time.
Again; this is only possible because we know ahead of time everyone entering the bathroom won't interfere with others in their own group.
Visualized:
Assuming these guys are besties, here is how the flow could look:
Mr. Purple (toilet) and Mr. Green (sink) are grouped because we know each is using a separate resource. Mr. Purple still breaks the toilet and Mr. Green just washes his hands like last time. Both finish, exit after 10min.
Sir Yellowton is allowed to enter thereafter and, again, has a different experience for the same reasons simply due to sequence. He does his business and exits after 10min.
Total processing time for the same 3 man queue: 20min (33% improvement)
Efficiency.
That one characteristic is the differentiator at the highest level for transaction parallelization within the Solana stack. It also parallelizes block propagation through block shredding [i], but that's a tale for another article.
So, that's how Solana achieves greater throughput, but...
4. How are others (Ethereum*, Monad) tackling the same problem?
Glad you asked, because what they do is slightly different: Optimistic Parallelization
Okay, WTF is optimistic parallelization? Don't L2s do that? - You
First:no they do not and you should feel bad for asking. Second: I apologize for saying you should feel bad because there are no bad questions here. Third: Some L2s are defined as optimistic due to how they post their proofs to Ethereum, and the word actually applies here so you weren't far off.
CAN YOU PLEASE JUST TELL ME WHAT OPTIMISTIC MEANS?
Okay - chill.
In general, it just means that the thing you're doing assumes everything is correct and that, should that not be true, you have measures for correcting.
For L2s it's fraud dispute mechanisms and for parallelization here it's simply replaying messages that had conflicts. This allows system resources to be focused on processing rather than verifying + processing.
Applying it to our analogy:
TLDR: You just process everything in parallel and hope for the best. If there are conflicts you just re-run the ones with issues until it works.
NOTE: I say "Ethereum" above but it should be pointed out that it only applies to the Besu [iii] and Nethermind clients, meaning it's not in-protocol / standardized to the EVM.
5. Wrap-up
In closing, this is a high-level overview of how blockchains aim to increase efficiencies through parallelizing transaction processing. I'll provide a synopsis below to put a bow on things. Hope you found it helpful.
SUMMARY
It's hard to parallelize blockchains because sequence can matter
If you can determine which transactions actual impact one another you can run those in sequence while everything else is parallel
Solana achieves this by forcing transactions to say what they're going to read/write from
Monad / Ethereum clients do this by simply running everything in parallel anyways and re-running what broke the first time
It should be noted that, going forward, you're likely going to see this become standard practice for high-throughput chains.
Notable examples not mentioned above are SUI, SEI, MegaETH, and any EVM chain that plans to use the reth client to achieve 1 GGas/s.
[i] https://www.helius.dev/blog/solana-executive-overview#turbine
[ii] https://docs.monad.xyz/technical-discussion/execution/parallel-execution