Blockchain technology is facing a serious scalability issue, and solving it might not be as easy as some think.
In the history of blockchain to be written in textbooks, 2018 will probably be known as the year of failing at scaling. An outcry for scalable blockchain systems in 2017 led to a number of companies making attempts at solving the problem of scaling and gradually realising that it’s not that simple.
As the year has concluded, ModernToken’s Blockchain Science department presents an overview of known approaches to improving scalability.
The great race to reliable scalability started with the outburst of startups and funding campaigns trying to bring distributed ledger technology (DLT) into business and to real-world applications. The first wave of projects triumphantly entering the market with a promise to solve specifically this issue have been, as predicted by experts, spectacularly missing their marks.
The most notorious examples of this are EOS — not fast, not a blockchain, not Byzantine fault-tolerant, according to a report by research firm Whiteblock — and IOTA, which has publicly acknowledged its own centralization and affirmed that it has never had a solid vision of a decentralized protocol.
A number of projects that weren’t hard pressed by their marketing to ship their products are still at work, and we’re expecting to see their progress — whether positive or negative — in the year to come. Meanwhile, it is worth to explore the problem itself and the ways it is being tackled by the industry.
Problem overview
In broad strokes, the challenge for DLT can be illustrated by the so-called scalability trilemma, coined by Vitalik Buterin: of the three fundamental properties of distributed networks — decentralization, scalability, and security — it is hard to have any two without compromising the third one, knowingly or not.
For distributed databases with shared state, there is also the CAP theorem, which regards availability (always getting a timely response to a query), consistency (always getting the most recent update or an error message) and partition tolerance (does the system lose liveliness if the network gets split). It is seemingly only possible to hold at most two of these properties.
To illustrate, if the network splits in half but remains operational, one has to choose between consistency and availability, as the unreachable part of the network may make updates to state that will not propagate to the reachable part. The theorem has varying effects on DLT architectures as well.
The trick is breaking up the state (the data that constitutes a ledger, i.e. the list of all current balances, the collection of current states of every smart contract, etc.) into parts while keeping the high security expectations and preserving the homogeneity of interactions. Namely, any entity (user account, smart contract) needs the ability to transact with any other entity, regardless of the relative places they end up after the state space is compartmentalized.
Lines of inquiry
With industry experience and theorycrafting accumulated so far, there are several possible approaches to attempt building scalable blockchain systems. Some of them are only vague sketches of ideas, while for others numerous projects and research teams are working on prototype architectures and proof-of-concept implementations.
Each approach has its own way of splitting the state, and each one entails its own set of constraints and bottlenecks.
To keep focus on the concepts, we refrain from mentioning particular companies and projects, so any resemblance to actual products — living or dead — or real events, is coincidental.
Sharding with proof-of-stake
Sharding attacks the problem head-on: instead of having every node replicate the entire state, let’s break it into segments (shards) and spread them between groups of nodes. If a transaction only needs to happen within the shard, processing it is very much like within classical blockchain: nodes within the shard have sufficient knowledge to fully validate it. Otherwise, there needs to be some sort of cross-shard communication. This brings three big questions:
- How to process cross-shard transactions, since most nodes only keep the state within their shard?
- For a node that only keeps state from its shard, how does it know with certainty that the state from other shards is consistent with protocol rules and is immutable (i.e. how do we prevent or process shard reorganizations, in relation to other shards)?
- How should the network deal with partitioning?
One of the important points when dealing with sharding is to get rid of proof-of-work (PoW). Since we are trying to build a homogenous network that consists of a huge number of parts, the computational resources will need to be spread thin, and performing a 51% attack on a particular shard will therefore be too easy.
Proof-of-stake, on the other hand, can possess several vital properties: random selection of stakers per round (so that coordinating an attack at one place is hard), stake slashing for byzantine behaviour (unlike with PoW, whereby failing at an attack has mostly opportunity costs) and stake locking (so that entering and exiting the staking game also has time costs).
Sharding with proof-of-authority
The sharding itself with this approach is most reminiscent of sharding in classic databases, since it more or less boils down to a trusted party — or a small fixed collegium of trusted parties — to maintain the data.
For the DLT maximalists, this is a conceptual resignation, since such a network can never be permissionless, i.e. fully independent of any realistically corruptible or coercible party or group.
On the other hand, it may still interest big enterprises and financial institutions, offering a medium for joint operations with cross-validation, provided there are activities that make business sense in the mutually transparent environment. The upside is that the trust requirements between counterparties can be lowered, if not eliminated completely, as long as the rules of interaction can be coded.
Delegated proof-of-stake
This design only has a handful of master nodes that validate transactions, emit new blocks, and promise to hold the full current state. The network users do not stake currency on new blocks (like in proof-of-stake), but instead stake currency on their preferred validators, which gives them voting power.
The idea is that the competition for being in a master node list, associated with high income in block rewards and fees, will drive the master nodes to perform well and have the best possible hardware, far beyond that of a personal computer.
There are concerns about possible tendencies to centralization. One of them is that since users only receive ROI on their delegate stake if their delegate is in the master node list, it is counter-productive to stake an outsider: until they get in, any voter just pays the opportunity cost of not staking an insider instead.
As a result, insiders have greater power, as they only need to worry about potential massive loss of votes, but can probably get away with smaller Byzantine stuff.
There are also uncertainties about auditability: huge state held inside a small number of paid validators creates a situation whereby fully auditing from outside the master node list is a big expense — since the hardware has to be matched — but provides zero revenue.
Some practical implementations of this architecture known to date also have opacity of the state, whereby an external observer, even one willing to commit resources, can never know what’s going on inside the master nodes.
General purpose interoperability
What if there was an inter-blockchain protocol to deliver in a trustless way transactions and state from any blockchain to any other blockchain?
Had it existed, such solution would allow scaling insofar as the state can be broken into separate chains. It would also mean great flexibility: blockchains can specialize at their particular business or data specifics and still have the ability to interact with other specialized chains. For instance, a content distribution network that uses an already existing medium of exchange network for paid interactions.
Unfortunately, this is a highly complex task. The elephant in the room is that it should handle forks and chain reorgs so that the logic on arbitrary blockchains relying on external state does not break. For instance, it needs to ensure that it isn’t possible to double spend on Aristotle chain by paying for something with a Plato transaction and then performing a 51% attack on Plato, forking the chain and removing the paid transaction.
Among other approaches to scaling, general purpose interoperability is perhaps the one that relies most heavily on game theory and incentive design. Little, if anything, is known a priori of the systems that should be connected, and the consumer of the relayed transactions cannot be expected to validate them for themselves, otherwise there’s no sense in the relay.
Plasma: hierarchical blockchains with exits into base layer
This concept for DLT was first proposed in August 2017. It involves multiple layers of blockchains: the child layer blockchain is anchored to the parent layer blockchain via a special smart contract that allows withdrawal of assets even if the operator of the child layer goes Byzantine.
Each block from the child layer is anchored in the smart contract, together with a Merkle root of the tree tracking assets. The child layer clients need to monitor the anchor contract in the parent chain and make sure that the operator sends them every block they submit to the parent chain.
If something is wrong (i.e. the operator doesn’t send a user the block they just committed, or the block is malformed), every user can start a withdrawal, asking the anchor contract to return their assets in the parent chain, by supplying a proof of ownership. After a waiting period, when the process can be contested with a fraud proof, the withdrawal completes, and the asset is recovered in the parent chain.
While a great concept, Plasma presents a number of its own challenges and problems. FIrst of all, all of its known architectures rely on the user storing full history of their assets on the chain and actively contesting malicious withdrawal attempts within the expected time windows. The window is the balance between how long the assets are stuck in the contract and how regular of a presence is expected from the user.
Secondly, the scenarios for mass withdrawals, especially from multiple plasmachains into the same parent chain at the same time, are tough to reason about, and no good security model has been presented so far.
Lastly, so far there have been no proposed architectures that would enable arbitrary smart contracts to hold their own assets in the plasma chain. There are only user-held non-fungible asset units (Plasma Cash), fungible asset units in form of payment channels (Plasma Debit), and arbitrary UTXOs (Minimal Viable Plasma).
Having contracts with both state and held assets presents a tough theoretical problem, as every proposed scenario for who and how exactly could contest a smart contract state in case of someone’s Byzantine behaviour have been prone to attacks.
Direct acyclic graphs
Instead of building a chain of blocks, where each new block is added at one end, why not grow a tree that expands in multiple directions? This way there is no need for one place or group that has to validate adding a block to a particular place, which is a bottleneck.
The computational load of updates is distributed among the current leaves of the tree. It could also mean that storage is broken up between branches that don’t need to be monitored all at once, as long as they are regularly cryptographically linked in some way.
With DAGs, it is quite non-trivial to define finality in a non-abusable way. If one adds or sees a transaction to a leaf, they need to have a strong expectation that the branch will stay inside the consensus state, which probably means that more transactions need to extend (and thus confirm) it.
The problem, then, is ensuring a robust way for the clients to perform leaf selection that fairly randomly builds on non-Byzantine branches and ignores Byzantine ones. If to do that the client then has to monitor the entire DAG, there is no scaling, because of the state space. If the client relies on a third party, that party becomes a trust bottleneck.
The challenge is in figuring out a way to do the random leaf selection that can be proven to be fair and tamper-resistant under reasonable assumptions. And it is, of course, connected with breaking up the state storage.
What’s next?
Many of the projects that have been developed throughout the year will likely bring first tangible results in the next six months. While we do not expect a fully production-ready protocol with horizontal scaling and arbitrary state — even a largely centralized one — powerful proof of concepts and minimally viable solutions are likely to hit the market soon.
And while 2019 may still remain the year of the Earth Pig, 2020 in DLT will likely be the year of the Scaly Armadillo.
The article was written by Collis Aventinus, a Blockchain expert at Modern Token.
