Backtrack From the Hardware Ceiling
Derive the performance target from the hardware's physics, then write software up to it.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 85%
Instead of asking how fast the system runs today, this method asks what the hardware would allow if the software were perfect. At Qualcomm the routine was to look at a chip, work out what the digital signal processor could do, and conclude that it supports a specific frame rate at a specific resolution — that is the ceiling, and everything after is software work. Applied to a global network, the gating resource is bandwidth: one gigabit in and out per validator implies roughly 700,000 transactions per second in theory. The number does two jobs. It converts every performance complaint into an estimate of engineering weeks, and it lets you price future hardware trends — more cores, wider GPUs, faster buses — as throughput you have already earned.
Origin
Extracted from Acquired. Yakovenko describes the practice as standard Qualcomm method: read the chip's specification, derive what it can support, then write software until the client is satisfied, and carry the same discipline into designing Solana's validator requirements.
Core principles
- 01The physical ceiling is a fact; your current number is just an artifact of the software.
- 02A target derived from hardware tells you how much work is left, not just how you compare.
- 03Hardware trend lines are the cheapest source of future performance you will ever get.
- 04Ship at the level the customer accepts, not at the ceiling, but always know the ceiling.
- 05A gap between ceiling and reality is a work estimate, not a verdict on the design.
How to run it
- 1
Identify the single gating resource
Find the one physical resource that everything else waits on. For a globally synchronizing network it was network bandwidth per validator, not CPU or storage.
Pro tip If two resources look equally binding, you have not measured hard enough yet.
- 2
Compute the ceiling from specifications, not code
Work the arithmetic from the datasheet as if your software were free. One gigabit of ingress and egress per validator implies roughly 700,000 transactions per second on that network.
Pro tip Do the calculation before you look at your current numbers so you do not anchor low.
Watch out A ceiling only holds for a stated workload; complex or non-parallelizable work has its own, lower ceiling.
- 3
Express the gap as engineering time
Subtract reality from the ceiling and convert the difference into work. Yakovenko frames known software limits as roughly three to four weeks of work each, when somebody actually needs them solved.
Pro tip Keep a ranked list of the specific limits, so a customer request maps to a known fix.
- 4
Ship at the good-enough point
Tell the customer the ceiling, offer a lower first version, and let them confirm it is sufficient. Quoting 4K at 64 frames per second and shipping 24 frames frees the team for higher-value work.
Pro tip Publishing the ceiling alongside the shipped number buys credibility for the next release.
Watch out Optimizing to the ceiling before anyone needs it is the most respectable way to waste a quarter.
- 5
Price in the hardware trend line
Ask what the ceiling becomes when the trend moves: core counts double, GPU lanes double, bus bandwidth doubles, data-centre links climb toward twenty gigabits. That is throughput you get without writing code.
Pro tip Design the architecture so trend gains land automatically rather than requiring a rewrite.
Watch out A bet on a trend line is still a bet; name the year it has to arrive by.
- 6
Re-derive the ceiling after each change
Every time you clear a bottleneck the gating resource moves. Recompute rather than assuming the original number still describes the system.
In the wild
Rather than benchmark Solana against other chains, Yakovenko starts from the validator's network link. Each validator needs a gigabit of input and output on the global network, and that bandwidth in theory supports around 700,000 transactions per second. Live benchmarks were about 50,000 with peaks over 65,000, so the gap was software, not design. Looking further out at core counts, GPU lanes, and bus generations, he argues the base hardware layer allows tens of millions of transactions per second, with the honest caveat that extracting it is blood, sweat and tears of software work.
→ A concrete, physics-anchored roadmap that separates 'we have not built it yet' from 'the design cannot do it'.
The habit came from hardware work: look at what a given digital signal processor can do, conclude it supports 64 frames per second of post-processing at 4K, and treat that as the limit. Then write software toward it until the client is happy — perhaps shipping 24 frames in the first version, hearing that it is good enough, and redirecting the team elsewhere.
→ Performance conversations became bounded and factual instead of open-ended negotiation.
Common mistakes
Quoting the ceiling as the product number
The theoretical maximum assumes ideal, non-overlapping, easily parallelized work. Presenting it as what users will experience turns a planning tool into a marketing lie.
Optimizing before anyone needs it
Closing the gap to the ceiling is only valuable when a real workload is hitting the limit. Otherwise it is expensive engineering nobody asked for.
Betting on a trend without a date
Assuming bandwidth and core counts will double is reasonable, but a bet with no deadline cannot be falsified and quietly becomes an excuse.
Is it for you?
Best for
Technical founders and infrastructure teams making multi-year bets where hardware trends, not clever code, decide the eventual ceiling.
Not ideal for
Products whose constraint is demand, distribution, or regulation rather than any physical resource.
From the transcript
“If you start at the hardware level itself, one gigabit networks is really the bottleneck, is like the bandwidth.”
“You need one gigabit of input and output per validator on this global network, and that can in theory support 700,000 transactions per second.”
“you start like that's the limit, and then you write the software until the client is happy”
From the episode
Special: Solana (with CEO Anatoly Yakovenko)