Scaling Series Part 1: What is Decentralized Scaling?
Define: decentralized scaling
This post is the first in what will be a series on scaling decentralized blockchains. The topic of “scaling” is probably the single most talked-about in the blockchain space, at least when it comes to technical discussions. More specifically, decentralized scaling of decentralized blockchains is where the real meat is; where the most interesting and active research has been performed over the past 10 years in the blockchain space. An overview of the scaling problem — and associated definitions, which will be the basis of the topics of the future posts in this series — is presented here.
What is the Scaling Problem?
The root cause of the scaling problem, as it is commonly referred to, is that every node in a peer-to-peer, decentralized blockchain system must verify every transaction on the network. Aside: this does not mean that every node in the network contributes to the “security” of the network, which is an unfortunately common misconception — we’ll re-visit this point later. This mass replication of computational work and storage requirements limits the transaction throughput of the network.
The scaling problem has led to a flurry of discussion, research, and many, many empty promises — where projects have claimed to have solved the scaling problem once and for all — over the past decade.
Before going more in-depth into proposals on improving scalability (the subject of future posts), we must first define “decentralized scaling,” which is the subject of the current post.
What is “Scaling”?
Let’s get the easy half of “decentralized scaling” out of the way first — the “scaling” half. Scaling in the context of blockchains refers to increasing the throughput of the system, as measured by transactions per second.
It should be noted that scaling does not imply a decrease in the latency of transactions. Indeed, improvements to scaling may sometimes come at the cost of increased latency. A simple thought experiment to demonstrate this point: imagine a blockchain with block times lower than the time it would take for light to travel between New York and Beijing. The orphan rate (or uncle rate, if it used such a system) would be astronomically high, which would negatively impact security, throughput, latency, and a whole host of other attributes of the system, making it practically unusable.
It should also be noted that, on their own, consensus mechanisms do not affect transaction throughput in any meaningful way. A common misconception is that “Proof-of-Work (PoW) is slow” — that could not be further from the truth. In fact, PoW has one of the lowest overheads of any known consensus mechanism in terms of both size and computational load: a single forward-hash of a small list of integers and a single comparison.
Systems that achieve greater scalability with different consensus mechanisms do so almost universally by reducing the size of the set of block producers. If the root cause of the scalability problem is that every transaction must be validated by every node, one way forward is to simply reduce the number of nodes on the network. This parameter — the number of block producers — isn’t actually intrinsic in these consensus mechanisms, but is chosen carefully to mask limitations in the consensus mechanism and make it appear “decentralized,” as we shall see in the next section.
What is “Decentralized”?
The word decentralized has been used and abused in the blockchain space, often thrown around without a firm definition but instead a loose, nebulous feeling driven by emotions (especially in regards to the boogeyman of miner centralization). This post attempts to provide a concrete definition of decentralization, a definition that will form the basis of future posts in this series.
A system is decentralized if and only if it is:
- distributed and
- trustless and
- permissionless
The above three properties are necessary and sufficient for describing a system as “decentralized.”
The Pursuit of Decentralized Scaling
Over the years, many systems have claimed to improve on the scalability of Bitcoin using stake-based consensus mechanisms. One very important thing to remember when dealing with the many consensus mechanisms that claim to “solve scaling” (which, as discussed previously, is completely off-base), is that for every buyer there must be a seller. This excludes pure Proof-of-Stake (PoS) and stake-based systems from being decentralized by the definition above, as they are permissioned — it is not possible to participate in the system without permission from someone inside the system. PoW systems are permissionless, as permission from network participants is not needed; anyone can hook up their computer to the network and start mining.
A particular flavor of PoS that has been heralded as being responsible for securing the blockchains with the greatest throughput is undoubtedly Delegated Proof-of-Stake (DPoS), or, as I like to call it, Proof-of-Delegated-Stake (PoDS). In addition to not being permissionless, PoDS cannot even be in good faith described as secure, as it costs an attacker nothing to secure delegated stake and attack the system, especially when the system is not even Byzantine Fault Tolerant.
The class of proposals to properly scale decentralized blockchains currently revolve around not having each node in the network validate every transaction. This is accomplished by either sharding the base blockchain (so-called layer-1 scaling) or having separate chains running alongside the base chain that only a subset of users need to fully validate (so-called layer-2 scaling). Both of these flavors of scaling are under active research, but there is still a significant amount of work that must be done in order to ensure both security and decentralization of the resultant system.
Closing Thoughts
This post presents an overview of the scaling problem, and introduces a concrete definition of decentralized scaling. This definition will be used in subsequent posts of evaluate, compare, and contrast various blockchain scaling proposals, including using zk-SNARKs, off-chain systems (child chains, state channel networks, etc.), and improvements to on-chain scaling performance.
Edit 2019–04–29: The post refers to PoW and PoS as consensus protocols, which is technically incorrect. They are actually methods for Sybil resistance, upon which consensus protocols can be built (such as a longest-chain fork choice rule). For the purposes of this post, however, the distinction is not important.
Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. ConsenSys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about ConsenSys and Ethereum, please visit our website.
