Wrestling with the Scalability Trilemma
I’ve been thinking a lot about the scalability trilemma lately, and wanted to write this blog post because after grappling with it for several days it seems pretty clear to me that the idea is at least a little bit wrong. But how wrong?
I’m still not entirely sure, but in this post I’ll try to explain where the concept has definite problems. For anyone who hasn’t run into the concept, the idea behind the “scalability trilemma” is that there is an inherent trade-off that requires blockchains to sacrifice either security or decentralization when increasing network capacity.
If we dig into the idea, the issue boils down to a resource allocation problem. Given a limited amount of money to spend running a blockchain, allocating funds to increase the throughput of all nodes (increasing scalability) would seem to require either shutting down a few nodes to balance the budget (decreasing decentralization) or spending less on our network security function (mining or staking). Increased transaction volume could hypothetically offset some of our costs, but let’s assume for argument’s stake that this is impractical.
So what is wrong with this argument? Nailing down the exact problem is difficult, because it requires teasing out what people mean when they talk about “security” in a blockchain. It also doesn’t help that the various types of vulnerabilities are often conflated in proof-of-work and proof-of-stake networks, but once we look at blockchain with a reasonably comprehensive security model, my own sense is that the scalability trilemma affects proof-of-work and proof-of-stake networks, but is not a universal law that limits blockchain as an overarching class.
The best way to approach this argument is reviewing the three basic attack vectors that exist against all classes of blockchain:
What you see above is the internal taxonomy we use to categorize network attacks at Saito. In this model, the first attack — the chain-reorganization attack — is the one that everyone associates with blockchains. Chain-reorganization attacks occur when an attacker attempts to dominate block production. These are the sexiest attacks in blockchain, which may explain why most of the academic work in the field focuses on these vulnerabilities. Examples of attacks on the chain-reorganization mechanism include the “selfish mining” and “gap mining” strategies — methods that miners can hypothetically use to increase their chance of successful chain reorganization.
The second attack vector — the fee-recycling attack — is much less understood yet far more common: it occurs when an attacker finds a way to earn more money than his peers for doing the same piece of work. Some people don’t consider fee-recycling attacks vulnerabilities because they are market-driven activities (and shouldn’t miners be profit-oriented?), but they are absolutely an attack vector and the reason they matter is that small differences in profitability can compound over time and put attackers in a position to pull off chain-reorganization and governance attacks. The fact that fee-recycling attacks are often gateway attacks is another reason they are not often recognized as a distinct attack vector, but you can always spot them as they attack the the fee-distribution mechanism instead of the block-production mechanism.
The third type of attack — the governance attack — occurs when an attacker manipulates the rules of a blockchain in a way that makes it easier to pull off chain-reorganization or fee-recycling attacks. Most people don’t worry about governance attacks very much because bitcoin is reasonably secure against them (you have to fork to change the rules of the system!), but many proof-of-stake networks have serious governance vulnerabilities. The voting systems that EOS and other dPOS blockchains use to distribute funds are riddled with these sorts of vulnerabilities.
It can be difficult to cognitively separate these attack types because existing blockchain designs often muddle them together. But they are different: the focus of chain-reorganization attacks is on the block-issuing mechanism. The focus of fee-recycling attacks is on the token-distribution mechanism. And the focus of governance attacks is on how the network comes to consensus on who is permitted to produce blocks and who is permitted to get paid.
Once attacks are viewed in this light it is easy to categorize them. In the case of bitcoin, selfish-mining attacks fall into the chain-reorganization category. The use of private relay networks like FIBRE constitute fee-recycling attacks. And all proposals that involve on-chain voting introduce the possibility of governance attacks.
Distinguishing between these three attack vectors is important because a blockchain is only as secure as its weakest attack vector. If this seems an abstract point, consider an extreme example. Imagine that it is the year 2200 and hashpower has become an industrial commodity: available for rent on spot markets at whatever volume buyers want. In this hypothetical future, it won’t matter how hard it is to produce blocks because fee-recycling attacks are far easier than chain-reorganization attacks: any attacker able to rent 51% of network hashpower can capture up to 100% of network revenue just by orphaning competitor blocks and recycle those funds into a perpetual attack on the network. In this environment, the difficulty of the mining algorithm is irrelevant. How much miners are paid is irrelevant: the vulnerability is imposed by the shape of the supply curve for hashpower.
This thought experiment, and several more that are too involved for this post, lead to an important realization for thinking about the “scalability trilemma”: of all three attack vectors, only chain-reorganization attacks get more difficult when we have an explicit security function like mining or staking. Fee-recycling attacks work the same regardless of how much it costs to produce a block. And governance attacks depend mostly on the ease of collusion in the network (something that correlates with but is not the same as network centralization).
So let’s go back to the concept of the “scalability trilemma”. The first really interesting insight that having this framework for thinking about attack vectors gives us is that even in proof-of-work and proof-of-stake networks security is not something that we can just purchase. Securing a blockchain involves balancing attack vectors, and while paying block producers more can thwart chain-reorganization attacks, that doesn’t make our blockchain more secure. In some situations, paying miners more can even make fee-recycling and governance attacks more vicious.
The second insight comes from considering networks like Saito, which don’t use miners or stakers to protect against chain-reorganization attacks. For those unfamiliar with Saito, the cost of a chain-reorganization attack in our network scales with transaction volume. It is true that Saito has a mining component that defends against fee-recycling attacks, but adjusting the payout to miners only has indirectly and incidental consequences for attacks on the block-issuing mechanism. So does the scalability trilemma affect Saito or does it not?
As the designer of the Saito network I’m frankly not even sure myself — the main point of giving money to miners is to avoid fee-recycling attacks and governance attacks. On a more subtle note, it is also to make the risks of those attacks quantifiable. It is possible that the scalability trilemma still applies in certain network configurations. And it is possible that the network will optimize to avoid those situations. We do not know.
What I think we can say with confidence is this — the scalability trilemma is not a universal property of blockchain. In the cases where it seems to be a bigger threat, what is really happening is that the network defense mechanism is overly focused on preventing a single attack vector: the chain-reorganization attack. And the mechanism that it uses to protect against that attack involves paying money to a single group of nodes that do not contribute to running underlying network infrastructure.
In short, it is a problem that is specific to proof-of-work and proof-of-stake approaches. Solving these weaknesses means moving to a network structure where chain-reorganization, fee-recycling and governance attacks are decoupled and the risk of each type of attack can be quantified, compared and compensated for separately. Saito offers one solution that accomplishes this using economic rather than technical security mechanism. It is likely there are other approaches under development that tackle the same problem from a different angle.
In any event, thanks for taking the time to read such a lengthy post. If you agree or disagree, please feel very welcome to let me know why. And if you’re in Beijing and find these sorts of discussions interesting, please look us up.
– — — — — — — — — — — — — — — — –
 Vitalik Buterin seems to have been the first person to publicly suggest that a scalability trilemma might exist, although his tweet posed the thought as an idea for consideration instead of a blanket statement.
 Some of the best work seems to be coming out of Cornell and Berkeley. I’m thinking in particular of Emin Gun Sirer on selfish mining, Ittay Eyal on other profit-maximizing mining strategies and Max Fang and Philip Hayes on other game theoretic attacks like address blacklisting and punitive forking.
 The tendency of people to confuse these two attacks is worsened by the way proof-of-work and proof-of-stake just hand over the entire block reward to block producers. Although this is a topic for a separate blog post, separating these two classes of attacks and securing against each separately requires separating block production from token issuance: the challenge is dividing up the payment securely.
 What I mean here is that it is easier to acknowledge that fee-recycling attacks exist as a class of attacks when there is a payment mechanism attackers can game that isn’t connected to block production, such as a subsidy for routing nodes. The fact that all of the money is given to block producers in POW and POS is one reason people mix these attacks up with chain-reorganization attacks, because they get easily more conflated with chain-reorganization attacks.