Everything You Know about the Scalability Trilemma is Probably Wrong
Is it really a Trilemma if it has already been solved?
Since the Ethereum team introduced the Scalability Trilemma, the public has latched on to it as the ultimate, and much hyped about, issue in scalability.
At a high level, the three properties it highlights — decentralization, scalability, and security — are self-evidently crucial to any DLT-based network that wishes to deploy in real-world use cases.
However, there seems to be much confusion about the scope and significance of the Trilemma as it is defined. Many have embraced it as mathematical proof that DLT cannot scale, with some recent notable examples. Others tout the Trilemma as evidence that the only scaling solution is sharding.
In fact, neither of these conclusions is true.
This article aims to clear up these misconceptions and take a deeper look at both the quantitative and qualitative merits of the Trilemma.
The Scalability Trilemma Defined
Broadly speaking, the Scalability Trilemma claims that there is a trade-off between three important DLT properties: decentralization, scalability, and security.
While catchy and seemingly plausible — otherwise, why haven’t projects been able to solve scalability? — it is critical to understand the precise, mathematical definition before the statement can be evaluated.
The Trilemma as defined by the Ethereum team is available here. For ease, I have included the relevant part:
The Trilemma claims that blockchain systems can only at most have two of the following three properties:
1. Decentralization (defined as the system being able to run in a scenario where each participant only has access to O(c) resources, i.e. a regular laptop or small VPS)
2. Scalability (defined as being able to process O(n) > O(c) transactions)
3. Security (defined as being secure against attackers with up to O(n) resources)
A quick aside: In case you are unfamiliar, the definition uses Big O Notation, which characterizes a function according to its rate of growth as a particular input variable increases. For example, finding the tallest person among a group of k people is O(k) since you need to measure each person’s height. The more people you have, the longer the process will take, and the total time is linear in the number of people. The important takeaway for this article is that Big O Notation describes complexity classes. In particular, O(n) and O(c) in the definition represent fundamentally different levels that may be arbitrarily far apart. Additionally, Big O absorbs constant factors, meaning that c * O(n) = O(n) for any constant c.
So what does this definition mean? There are two different classes of resources involved.
O(n) is both the desired level of transaction throughput and the resources of a potential attacker. These two values can be off by a constant factor — even a large factor — but they grow at the same rate. This is a good assumption to make to be safe.
There are two components of a DLT: state (i.e. the data describing accounts and transactions) and transaction processing (i.e. consensus and everything else involved in validating requests). Both state and transaction processing are O(n) under this model, which is also reasonable.
O(c) is the level of resources per network user (hardware, money, etc.). Users may have different levels of resources, but they are within a constant factor of one another. Most importantly, user resources are strictly less than the resources available to an attacker, that is, O(c) < O(n).
What the mathematical definition of the Trilemma claims is that recognizing certain resource limitations, such as hardware, it is impossible to scale capacity past those resource limitations.
Intuitively, this claim rings true. There are only so many transactions per second that hardware can process, regardless of how powerful that hardware is. At some point, you run into a bottleneck.
Is it possible to surpass these limits? At its heart, the mathematical definition says No.
Logos “solves” the Trilemma as defined
Despite the claims of the Trilemma to the contrary, Logos does satisfy all three desired properties via its sharding mechanism.
At a high level, sharding involves splitting the network into subgroups and only requiring a single subgroup to process a particular transaction. It is non-trivial to show that a sharding scheme is secure and functional, but it can massively increase capacity provided it is designed correctly.
In Logos, sharding involves splitting the validator set into disjoint groups (the shards) via a verifiable random function. Each account is similarly assigned to a particular shard. The chain mesh DAG data structure is natively divisible at the account level (each account has its own set of transaction chains), which makes this process substantially easier than sharding a blockchain.
The validators in each shard process the transactions for its accounts and maintains the associated distributed database. Since the shard can uniquely lock its accounts while a transaction is being processed, double spends are impossible.¹
Notably, Logos’ sharding model enables the network to dynamically scale with the number of participants in the network while not increasing the per-node computational requirement.
Both state and transaction processing are sharded, meaning the entirety of the network resources are spread out across nodes rather than shared globally.² So sharding captures the heart of what the Trilemma claims to be impossible.
Specifically, Logos with sharding satisfies all three previously defined properties:
- The network processes O(n) transactions (by definition)
- Each validator has only O(c) < O(n) resources, meaning that the network is processing a different level of transactions than any single validator can handle. Additional shards and validators can be added to accommodate additional transactions.
- The network is robust to an O(n) attacker. Using the VRF, the attacker would be distributed across shards in a way that it cannot economically control. As those resources increase, so do the number of shards. Since O(n)/O(n) = O(1), the ability of an attacker to overwhelm a single shard does not scale. Slashing and the Logos economic incentive system are also relevant for this property.
Since all three conditions are met, we have a solution!
The Trilemma is not binding or mathematical
Before getting too excited, how is Logos able to solve an allegedly (at least according to the popular belief) binding and mathematical Trilemma?
Obviously, since Logos solves the Trilemma, the assumption that it cannot be solved is incorrect, and it is clearly not a true Trilemma.
Incidentally, the proponents of the Trilemma never claimed that it was binding! The Ethereum team explicitly stated that it is not, as have earlier proponents. The very FAQ in which it was defined (linked above) presents a solution!
I think that much of the confusion surrounding the Trilemma stems from the relatively technical context in which it is presented. The general public seems to have grabbed on to the high level statement of the Trilemma and accepted it as fact without understanding the deeper mathematical implications.
In reality, the Trilemma is a thought exercise rather than a mathematical fact. It was stated as a way to contextualize the specific problem that the Ethereum team is trying to solve as well as the specific axes they were optimizing over. Fundamentally, it is a means of highlighting Ethereum’s particular scaling solution. And it does this well — sharding is one of the most exciting scalability solutions, and the Trilemma identifies some of the specific tradeoffs it overcomes.³
But that does not mean that it holds any particular broad mathematical insights or that its definition perfectly captures these higher-level concepts. More importantly, it does not mean that the only means of scaling a network is sharding or something else that “solves” the Trilemma, as prevailing wisdom suggests. So the mathematical usefulness of the Trilemma when designing a DLT is questionable and ultimately limited.
Decentralization in the Trilemma
Perhaps a more interesting question is whether the spirit of the question is useful. In particular, many people have grabbed on to its non-mathematical definition of decentralization, which can be paraphrased as: “Participants must be able to run a full validator node on a regular laptop.” In Big O space, running a validator on a Raspberry Pi and a high-performance server (or even a supercomputer) are equivalent,⁴ so the informal definition does not truly reflect decentralization as defined mathematically in the Trilemma.
Nevertheless, the informal definition is cited in the mathematical definition as well as several times subsequently, and the clear qualitative intention is that the critical part of decentralization is that you can run a full node on average consumer hardware.
Does this condition meaningfully capture the concept of decentralization? No, at least not in a way that has any significant impact in any reasonable real-world setting. Put another way, while there may be some theoretical significance of being able to run a full node on your laptop, there is no plausible practical significance.
Practical vs theoretical significance
There is an important difference between practical and theoretical significance that is often lost in popular blockchain discourse. Theoretical significance is whether there is a technical or mathematical implication of a particular event or choice, no matter how small. Practical significance is whether that event or choice has a meaningful impact in the real world.
A parallel field in which this distinction is important is statistics. If you are estimating the difference in average height in Boston and New York, given a large enough sample size, you will almost certainly arrive at a statistically significant (i.e. theoretically significant) but small difference with a very small p-value. However, there is essentially no practical significance of this result.
On the flip side, if you are testing patients for cancer, a p-value near or even slightly above an arbitrary cutoff like 0.05 has relatively lower theoretical significance but immensely higher practical significance.
Practical limitations of the Trilemma
This same lens can be applied to DLT and the Trilemma. There may be some theoretical benefit for enabling every Average Joe to participate as a full validator in a network, but it has basically no practical value. Any network satisfying the security condition (both as specified by the Trilemma and more generally) must have some mechanism of assigning votes that reflects an economic investment, such as computers in proof-of-work or tokens in proof-of-stake.⁵ Regardless of mechanism, there is inevitably an economies of scale effect plus a natural Pareto distribution that results in a few major validators and many smaller validators. Relative to the major validators, an Average Joe validator has no meaningful impact on the system while still imposing additional overhead. Somewhat perversely, fixating on this contrived definition of “inclusiveness” fails to improve actual decentralization while negatively impacting network performance.
What is important, both theoretically and practically, is that anyone can ensure that the validators are not abusing their power, and, if they are, punish them accordingly. Luckily, since consensus is substantially easier to verify than achieve, this can be done without throttling the network to allow anyone to act as a validator. A key result of the math behind Logos is that no validator can jeopardize the security of the network without acting in a provably malicious way that is easy for anyone to check and, when seen, initiate slashing penalties.
Ultimately, decentralization is not an absolute property as the Trilemma suggests (both mathematically and qualitatively) but rather a spectrum. Any network that sufficiently guarantees that no single user or cartel of users can control the network can be said to be decentralized, while an architecture that fails to provide this distribution of power is centralized.
In practice, this has little to do with whether a validator can be run on a laptop. Anyone can participate in proof-of-work consensus by mining,⁶ but proof-of-work networks are highly centralized. In both Bitcoin and Ethereum, for example, fewer than four mining pools control over 50% of the hash rate. Alternative schemes that many characterize as centralizing, such as delegation in proof-of-stake, in fact, can be substantially more decentralized than proof-of-work or vanilla proof-of-stake consensus.
Similarly, the quantitative definition of the Trilemma is also not practically significant for analyzing scalability.
A network that mathematically solves the Trilemma is probably scalable (but not necessarily!), but a network that does not satisfy the Trilemma may very well be scalable as well!
How can this be? While Big O Notation is useful for analyzing limiting behavior of functions, it abstracts away critical practical differences of various functions by absorbing constants. But constants matter practically. For example, the functions f(x) = x² and g(x) = 745,912 * x² are both O(x²), but f(x) is 6 orders of magnitude less complex than the g(x) if used in the real world — a massive difference! In the same way, a scalability solution where user resources, attacker resources, and network capacity are all O(n) could provide many times more capacity than required user resources and be more than adequate for real-world use cases.
On the other hand, a network that satisfies the mathematical criteria of the Trilemma may not operate at practical scale. In the example below, transaction processing and attacker resources are both O(x²), which is strictly greater than the user resource scale of O(x) in Big O space. But transaction processing is strictly less than per user resources for all reasonable, real-world ranges of resources!
Of course, there is a theoretical crossing over point where the O(x²) function will dominate O(x), but what use is that if that level is not seen in the real world? In this case, the relying on the Trilemma as the litmus test for scalability fails to show the full picture.
By relying on Big O Notation, the Trilemma overlooks a whole class of perfectly valid and important scalability solutions and conceals some critical practical considerations.
In all cases, it is not one single, pithy property that defines decentralization or scalability, but a broad and complex set of interacting components that span computer science and game theory. While a simple statement like the Scalability Trilemma may be attractive, it belies this nuance, both practically and theoretically. The scalability solution it was designed to highlight — sharding — is not the only path to scale, and Logos' advances in data structure, consensus, and token structure are equally important in building a network for global adoption.
Ultimately, the right question is not “How does this network solve the scalability Trilemma?” but rather “How does this network scale practically?”
[1] More in-depth overviews of Logos’ sharding system can be found in the white paper and primer.
[2] Many sharding schemes shard only one of state or transaction processing, meaning they don’t satisfy the Trilemma.
[3] Note that sharding, even as defined in Ethereum and Logos, is not a silver bullet as there is non-trivial overhead in coordinating and communicating across shards. Sharding is a good start, but the validation within each shard is also a bottleneck. For this reason, it is critical to dramatically improve the base consensus layer.
[4] Since k*O(c) is equivalent to O(c) for any k.
[5] This assignment of votes proportional to some provable economic investment is one of the key breakthroughs of Bitcoin.
[6] Regardless of whether mining is profitable for those users, mining is open to anyone.
If you’d like to keep up with what we are doing:
Follow us: Twitter | Discord | Telegram | Reddit
Read: White paper | Logos website
