Design Backwards From the Adversary
Pick the one number an attacker must beat and let it set every requirement.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 82%
Start from the failure you refuse to permit and express it as a count: the minimum set of independent participants who, if they all colluded, could break the network — the Nakamoto coefficient. Everything else follows mechanically. Wanting that minimum set to reach twenty or thirty thousand means the system must move far more messages per second, perform far more cryptography per second, consume far more bandwidth, and demand better hardware from every operator. Those are no longer debatable preferences; they are consequences. The metric also does organizational work: once the community's stated religion is maximizing censorship resistance, contributors filter their own proposals, and features that would shrink the number get rejected without a meeting. The general form is to convert a security aspiration into a single number an adversary must beat.
Origin
Extracted from Acquired. Yakovenko reaches the metric via a deliberately morbid analogy — a sensor array detecting a nuclear strike needs enough independent verifiable sensors that corrupting the result is infeasible — and credits the Nakamoto coefficient framing to Balaji.
Core principles
- 01One adversarial metric beats five virtues nobody can trade off against each other.
- 02Define failure as the minimum collusion that breaks you, then maximize that minimum.
- 03Requirements should be consequences of the metric, not preferences.
- 04A metric the whole community can chant becomes a filter for every decision.
- 05If a decision does not move the number, it is not a priority.
How to run it
- 1
State the failure you refuse to allow
Describe the catastrophic outcome concretely and from the adversary's side. For a censorship-resistant network it is a coordinated group deciding whose messages get through.
Pro tip A vivid, uncomfortable analogy makes the requirement stick where an abstraction will not.
- 2
Reduce it to a countable minimum
Turn the failure into the smallest number of independent participants who would have to collude to cause it. That count is now your objective function.
Pro tip Independence is the load-bearing word — participants sharing an operator or a data centre count once.
Watch out Counting nodes rather than independent controllers inflates the number and hides the real risk.
- 3
Set a target, not a direction
Commit to a specific scale — tens of thousands of independent participants — so the architecture has something to be sized against.
Pro tip Targets in the tens of thousands change the design; 'more decentralized' changes nothing.
- 4
Derive the mandatory costs
Work out what the target forces: more messages per second, more signature verification, more bandwidth per operator, higher hardware requirements. Accept them as requirements.
Pro tip Publish the operator specification early so the supply side can plan capital expenditure.
Watch out Hardware requirements that outrun what operators can buy shrink the very set you are maximizing.
- 5
Use the number as the veto
Evaluate proposals by whether they raise or lower the minimum collusion set. Anything that lowers it loses, regardless of how much throughput or convenience it buys.
Pro tip Say no with the number attached; it depersonalizes the rejection.
- 6
Hand the metric to the community
Make it the stated priority so contributors optimize for it independently. When maximizing censorship resistance is the community's religion, alignment stops being a management task.
In the wild
The hardware requirements that critics read as centralizing are, in Yakovenko's account, downstream of the opposite goal. Maximizing the minimum colluding set toward twenty or thirty thousand independent participants requires a system that handles far more messages, cryptography, and bandwidth per second — which requires better hardware. The token exists for the same reason: to make the right to participate freely transferable and reassignable, so no central authority issues the set of guardians and becomes the single point of failure.
→ Contentious engineering costs became explicable as consequences of one published objective.
The analogy Yakovenko designs from: an array of sensors detecting a strike is only trustworthy if a large number of independent, verifiable sensors would have to be corrupted for the system to report wrongly. Asking 'how do I know it is working' becomes 'how large is the minimum set that could collude against me', which is a number you can build toward.
→ A security aspiration became a measurable target that dictated the rest of the architecture.
Common mistakes
Counting nodes instead of controllers
A thousand machines under a handful of operators has the collusion profile of a handful. Measuring the wrong unit produces a comforting number and no actual resistance.
Letting convenience quietly lower the number
Features that centralize participation for speed or simplicity shrink the minimum colluding set. Without the metric as an explicit veto, this erosion happens one reasonable decision at a time.
Keeping the ability to issue participants
If the founding team can mint new guardians at will, it is the root of trust and therefore the point of failure — which defeats the metric no matter how large the count looks.
Is it for you?
Best for
Teams building trust-critical infrastructure who need one shared objective that settles architecture arguments.
Not ideal for
Products where the binding constraint is user experience or growth rather than resistance to a coordinated adversary.
From the transcript
“So it's the minimum set of independent participants that if they all colluded would break the network.”
“And to do that, to really scale that to a very large number, 20,000, 30,000, you need to make a system that just handles a…”
“the religion in like our little community is maximize censorship resistance”
From the episode
Special: Solana (with CEO Anatoly Yakovenko)