Co-authored by Surya Viswanathan and Aakash Shah.
The Scalability Trilemma, a term coined by Vitalik Buterin (founder of Ethereum), refers to the tradeoffs that crypto projects must make when deciding how to optimize the underlying architecture of their own blockchain. In layman’s terms, it’s akin to the phrase “you can’t have everything”. The trilemma Vitalik is referring to involves three components: decentralization, security, and scalability. In this post, we’ll provide an overview of these three components and evaluate the pros & cons of each. This is a useful comparative framework to measure blockchains against each other. Rarely is it the case that the actual underlying infrastructure is poor (though this also does occur). The better question to ask is, which aspects of the blockchain does the project intend to optimize, and are these in line with its value proposition and use-case. While educational, we hope this content also enables you to better evaluate cryptos on your own.
Decentralization, as the word suggests, refers to the degree of diversification in ownership, influence and value in the blockchain. The important concept here is that it is the “degree of decentralization” — it is not a binary attribute. Ethereum is very decentralized; Eos is partially decentralized; Twitter is not at all decentralized. A common misconception is that networks can simply be labeled decentralized or not. Another one is that all blockchains are decentralized to the same degree.
Let’s start with the most centralized types of organizations. Typically, these organizations don’t run on a blockchain. The organization is controlled by a small group of individuals at the top — the management team. They typically control the majority of ownership in the company, and are the decision-makers alongside a board of advisors. This is the nature of most companies today, be it a partnership, C-Corp or 501(c)3 structure.
Decentralized networks are controlled, for the most part, by the users. Users collectively have the ability to use their stakes to vote, to use services on the platform, and to benefit financially. Obviously, while in all blockchains users can stake their tokens to vote, the influence they have is different. In proof-of-stake protocols, an individual’s vote is as influential as the number of tokens they hold. In delegated proof-of-stake protocols, an individual’s stake is only used to elect a third-party, who will then vote on a user’s behalf. However, given that the majority of governance structure is written directly into the code itself, these “decisions” primarily revolve around settling disputes. This is in contrast to the decisions a management team would typically make, around strategy, operations and shareholder rights.
Another important element of decentralization is that the majority of value accrues to the community. There is no “management team”, and therefore no one centralized party taking a cut before shareholders are compensated. Effectively, most crypto projects are wholly owned by their shareholders, or users, rather than the founders. This is obviously a more appealing proposition for those that are not the founders. Take a look at the music industry today. Apple (iTunes) takes a 30% cut of sales fees for hosting and distribution, with the remaining 70% going to content creators. If music streaming were run on a blockchain, 90%+ of the value would likely accrue to the content creators. A small portion would go to the entities involved in running the network, but the majority of value accrues back to the producer of value, rather than an intermediary.
Here are the pros and cons of decentralized protocols:
- Decentralization, at a philosophical level, aims to bring power back to the community. By using a blockchain, where the rules of governance are literally codified and cannot be edited, one can maximize distribution of influence, wealth and ownership across the community.
- The more decentralized a system, the more secure (typically). There is no central point of failure or hack. There are, however, certain ways to hack even the most decentralized systems.
- Decentralized protocols like Bitcoin or Ethereum often use PoW mining to produce new blocks. This form of mining requires validators to solve difficult hash puzzles. As a result, this not only uses vast amounts of energy, but also compromises on performance and speed. This can be problematic for use-cases that require high throughput.
- The downside to leaving disputes up to the community, is that there is no central moderator. For certain use-cases, like Social Media, this would enable the publication of hate speech or fake news, for example.
- It is hard to shut down a decentralized blockchain, as there is no centralized server or party. While also stated as one of the core benefits, in a scenario where a destructive use-case were to arise, this would cause a problem that would be hard to resolve, apart from by the community itself.
Security refers to the level of defensibility a blockchain has against attacks from external sources. Internally, or within the blockchain itself, it’s a measure of how immutable the system is to change. For most blockchains, there are many, many potential security risks. In a future blog post, we’ll discuss some of the common attack vectors and plausible defenses in more detail. In our opinion, decentralization and security go hand in hand. In many cases, the more nodes there are, the less reliant the network is on a centralized party, and therefore the less risk of having a central point of failure. There are, however, a host of other attack vectors that pose risks to decentralized networks, including:
- >50% Attack — an entity (or set of entities) that owns more than 50% of the total tokens outstanding, effectively owns the network
- Sybil Attack — an entity (or set of entities) could forge multiple (hundreds, thousands or more) identities on a system in order to effectively control a significant stake in ownership and/or decision making of the network
- Penny spend Attack — an entity (or set of entities) that flood the network with low-value transactions in order to stop the network from running
- Distributed Denial of Service Attack (DDoS) — occurs when there is intent to disrupt traffic in a network by flooding the network with malicious transactions
- Collusion Attack — one or more entities (or nodes) decide to collude together to perform some malicious operation(s) on the network
- The primary benefit of robust security is that the blockchain is less vulnerable to attack. This is ideal for applications that require sovereign grade security and deal with confidential data. Anything in the realm of financial services would likely require the highest degree of security. Even crypto exchanges — one of the biggest targets of hackers — would be far better suited to deal with such attacks if built on a blockchain. (Indeed, we discuss the prospect of a new set of dApps — decentralized crypto exchanges — as one of the more promising ideas for future dApps on Eos).
- There are no downsides to maintaining robust security, but in order to do so there are a few second-order effects that are concerning. Many secure blockchain networks utilize PoW protocols — these require complex hash puzzles to be solved prior to block production — but more importantly, these protocols use up an immense amount of computing power and energy. Consequently, this reduces throughput and increases network latency, a strong deterrent for many potential users, that are used to near-instantaneous transaction times on centralized networks. This is still a worthwhile tradeoff for platforms that put a premium on security, but for ones that attempt to optimize user experience, this is certainly a strong consideration.
The degree of scalability is important because it dictates the eventual capacity of any network. Put another way, it determines the upper limit on how large a network can grow. It is perhaps the most important question to think about when evaluating a network — how many users can this network sustain? Bitcoin currently has between 2.9 to 5.8 million wallet holders; Facebook has 4bn users; Eos has a few thousand. Nano is perhaps one of the most scalable platforms out there, for a few reasons: 1) It condenses transactions into micro UDP packets (akin to a zip file), so that even the most basic computer hardware can process transactions; 2) Every user provides the power for their own transactions, on their own blockchain ie. There is no massive blockchain which other users have to support; and 3) Individual blockchains only store the last balance on each user account, not the user’s entire transaction history (this is backed up separately on the network, available to those that ask).
Yet, there are tradeoffs to achieving infinite scalability. Scalability and decentralization can co-exist, but security risks become greater. Developers will choose the platform that best suits their needs, and users will choose the platforms that function best, according to them. Some users may be willing to sacrifice security for scalability; others, scalability for security. We evaluate the core features based on the overall mandate of the system.
- Scalability ensures that the application runs quickly and that it can support a high volume of transactions. As we mentioned, this is especially useful for audio/video streaming sites, gaming, and social media.
- The application is less likely to break down if user demand is greater than originally planned (Cryptokitties, for example, which was run on Ethereum, was not very scalable and ran into major issues because of this:
- The costs to achieving infinite scalability primarily regard security. Almost all of the above security risks become greater with a network of massive scale. In addition, quickly growing networks will require a fast consensus mechanism, in order to validate more transactions while delivering the same speed to individual users. This can only occur in Proof of Stake or Delegated Proof of Stake. This compromises decentralization. If the protocol is Proof of Work, the hash puzzles or mining algorithms would need to be easier in order to have a commensurately fast validation process. This compromises security, and also decentralization to an extent (mining pools would thrive if hash puzzles were made easier).
Buterin was right, in that even envisioning a blockchain platform that optimizes all three factors is challenging. In our mind, the closest to come to this is Nano. However, the main lesson is that any user and developer will have preferences over which aspects they want to optimize, and there are several options that optimize any two of the three. Depending on the use-case, and individual preferences, one can determine which is best suited for themselves.