Scaling solutions come in two forms: on-chain and off-chain. Both come with pros and cons, but as of now, there is no agreement as to which is more promising for future growth.
On-chain scaling
On-chain scaling refers to the philosophy of changing something about the blockchain itself to make it faster. For example, one approach to scaling includes shrinking the amount of data used in each transaction so that more transactions fit into a block. This is akin to what Bitcoin achieved with its Segregated Witness update, otherwise known as SegWit. By altering how the transaction data is handled, this patch to Bitcoin allowed a notable improvement to overall network capacity.
Another way to potentially boost the TPS of a network is to increase the rate of block generation. While this can be helpful up to a point, there are limitations to this method relating to the time it takes to propagate a new block through the network. Basically, you don’t want new blocks being created before the previous block was communicated to all (or virtually all) of the nodes on the network, as it can cause issues with consensus.
Creating seamless communication between discrete blockchains is another potential way that these systems could scale. If different chains can all transact between each other, then each individual network doesn’t have to handle as much data and the throughput of each should improve. Of course, a system would be needed to ensure the data being sent between networks is 100% accurate, and this is what projects such as Polkadot are working to do right now. By combining multiple native chains as well as smart contracts, this platform makes it possible for the entire decentralized ecosystem to scale together, once fully implemented.
Then there’s a technique called sharding, in which transactions are broken up into “shards,” and different nodes only confirm certain shards, effectively performing parallel processing to speed up the system. This can be applied to proof-of-work or proof-of-stake systems and is going to form a major component of Ethereum 2.0. This offers the potential to improve the capacity and speed of the network, and developers are hoping that we will see upward of 100,000 TPS become a reality.
On the other hand, it should be noted that it will still take a few years before the sharding process is fully implemented into Ethereum, and detractors have pointed out that it also adds complexity and hurts security. This is due to the fact that sharding increases the chances of a “double-spend” occurring as a result of an attack. The issue here is that it takes notably fewer resources to take over individual shards than it does to perform a traditional 51% attack. This can lead to transactions being confirmed that would otherwise be seen as invalid, such as the same Ether (ETH) being sent to two different addresses.
Some projects have attempted to improve network speeds by limiting the amount of validating nodes — a very different philosophy from Ethereum’s. One example is EOS, which has limited its validators to just 21. These 21 validators are then voted on by token holders in an attempt to keep a fair, distributed form of governance — with mixed results. This has given the network a reported 4,000 TPS, and developers are confident that they can continue to scale, which has positioned the project as one of Ethereum’s main competitors in this space. However, limited validators are often looked down upon as a form of centralization, so not all users are sold on the model.
Of course, one of the most frequently discussed means to scale a blockchain is to increase the size of individual blocks. This was the approach that Bitcoin Cash famously took when it forked away from Bitcoin in 2017. Not wanting a limit of 1 MB, the Bitcoin Cash community changed the rules so that the project could have 8 MB, and later 32 MB, blocks. While this certainly means there is more room in each block for added transaction data, some point out that it is infeasible to continue growing block sizes indefinitely. Many consider this solution to be merely pushing the problem down the road, and at worst, they see it as again primed for harming the decentralized nature of the blockchain. Given that, in practice, the average block on the Bitcoin Cash network is still under 1 MB, the debate on this is as of yet unsettled, and we will explore the issue more thoroughly below.
Off-chain scaling
There are also ways to improve network throughput that don’t directly change anything about the blockchain. These are often called “second-layer solutions,” as they sit “on top of” the blockchain. One of the most well known of these projects is the Lightning Network for Bitcoin. Basically, Lightning Network nodes can open up “channels” between each other and transact back and forth directly, and only when the channel is closed does the Lightning Network transmit the final tally to be recorded on-chain. These nodes can also be strung together, making a much faster, cheaper payment system that only interacts with the main network a fraction of the time.
Ethereum, of course, also has solutions along these lines. For one, there is the Raiden Network, designed to be Ethereum’s version of the Lightning Network, as well as a more general blockchain product called the Celer Network. These projects implement not only off-chain transactions but also state changes, which allow for the processing of smart contracts. Currently, the biggest drawback with these systems is that they are a work in progress, and there are still bugs and other technical issues that can arise if channels aren’t created or closed correctly.
A similar idea is something called “sidechains.” These are basically blockchains that are “branched off” of the main chain, with the ability to move the native asset between them. This means sidechains can be created for specific purposes, which will keep that transaction activity off of the primary network, freeing up the overall bandwidth for things that need to be settled on the main chain. This is implemented for Bitcoin through the Liquid sidechain, and Ethereum’s version is known as Plasma. One downside here is that each sidechain itself needs to be secured by nodes, which can lead to issues with trust and security if a user is unaware of who is running them behind the scenes.
