Scaling Solutions: Making Blockchain Faster
As Ethereum and other blockchains begin to drastically slow down due to real-world usage, there have been several proposals set forth to address the problem. While Ethereum 2.0 is still underway, some are developing solutions for layer 1 on Ethereum to help speed up the network. In this article, we will discuss the ideas for supplementing layer 1.
What is Layer 1
Layer 1 is the network on which the consensus algorithm was initially built. Ethereum and Bitcoin are both layer 1 networks. The processes of mining and transacting all takes place within that network. The virtue in having this consensus algorithm is the security of having every node verify every transaction. That way, only validated transactions can occur on the network. The nodes that run the network also have to keep a record of past transactions on the network within their ledgers. As transactions take place, nodes must re-verify every transaction on their ledger to make sure that their record matches those of other nodes. Such a process ensures that no tampering takes place on older transactions. This also requires a great amount of computing power. As the network becomes older and the ledgers become longer, the strain on the network to verify these transactions grows. The computing power from the network’s nodes, however, does not grow at the same pace. This results in a slower layer 1 network.
Layer 2 Solutions for Layer 1
As more developers build on layer 1, the computing bandwidth on the networks begins to diminish. This is because each network holds only as much computing power as the nodes that support it. The blocks on Ethereum and other blockchains also have a limit on how many transactions can be processed on them. This means that there is a limited amount of transactions that can be processed by the network. Such a characteristic becomes an issue when the number of transactions on network spikes. On public chains, there is no filter for interacting on the network, so any developer can deploy their projects using the collective computing on layer 1. As a result, there are too many pending transactions on Ethereum (Ethereum can only process about 15 transactions per second). With discussions of web 3.0, a key obstacle then becomes scalability on a slow network.
To remedy this obstacle, two main approaches have been set forth. The first proposal is to divide the responsibility of processing transactions so that each node on a network only processes a fraction of the total transactions. This is known as sharding.
The other proposal is to build a layer on top of the network to process the bulk of transactions, sparing the collective computing power of the network, layer 1. Through this method, the combined layer 1 and layer 2 can then process more transactions with the current layer 1 bandwidth. Interactions on layer 2 are kept outside of the main net, being recorded on off-chain ledgers. Only essential interactions are then relayed to layer 1, limiting the transactions on layer 1.
Participation on Layer 2
Even if this second proposal were adopted by the majority of users on the network, there would still be some notable challenges to scalability. Grouping transactions and sending them to the main network in bulk works to lower the number of transactions only insofar as every actor on the network does this. If an application like Tether arises and does not follow the principle of this proposal, the network would soon be overwhelmed with transactions, and the grouped transactions would be as slow as if no grouping had taken place. Ultimately, there is no way to force everyone on the network to process the bulk of their transactions off-chain. Therefore, there is no way of making this solution a long-term fix for this scalability problem.
Liquidity
Another concern to note when implementing this grouping mechanism on layer 2 is its effect on the liquidity of the market. These off-chain transaction channels require users to lock a certain amount of their cryptocurrency on the network in order to verify that they have enough funds to transact. These channels are only bilateral, meaning that the crypto one blocks on a transaction channel can only be used to transact with the sole other party on that channel. As a result, users would have a significant portion of their portfolio locked in several channels yet not actually used.
Interoperability
Lastly, there is the issue of interoperability. The chances that one single payment channel provider like the Lightning Network captures a significant portion of the layer 2 market are slim to none. Crypto users are by nature against the idea of centralization. Only using one payment provider would go against the implicit values of crypto. There would also surely be other companies looking to profit from this idea. Consequently, it would be quite expensive to transact on layer 2 as the multitude of providers would require users to lock their crypto on several services. Most users won’t have such liquidity and would be inclined to not participate in this mechanism.
Alternative Solutions to Transaction Latency
In Michael Anderson’s work on transit systems in Los Angeles, Anderson claims that public transportation does not reduce congestion as much as transit systems. This is because the key factor in congestion is the driver in the most congested area. Consequently, those drivers have the most marginal impact on traffic; if the transportation system can reduce the commute for those commuters, it will reduce the commute for everyone on the transportation system. The commuter in the most congested area is the most attracted to transit systems. Since this type of commuter is in the worst position in traffic, they will be more inclined to pay a fee for a less congested highway. This means that providing pay-for-use alternatives is the best way to reduce congestion.
This principle applies for the slow crypto platforms with massive amounts of pending transactions. As with public transportation, some have proposed the grouping of transactions off-chain to reduce the amount of transactions on-chain. This is not an efficient solution for the same reason that public transportation is not an efficient solution: it does not target the root of the congestion problem. In the world of crypto, those who strain the network the most are those with the largest amount of transactions. These users also suffer from the most latency as they have more transactions to process. As a result, such users would be the most attracted to paid alternatives for transacting on the network. Like in the traffic example, lowering the latency for the users with the most latency will have the most significant impact on lowering latency across the network. By providing a faster, paid option for processing these larger amounts of transactions, the latency on the main network would decrease significantly.
Conclusion
Before discussing layer 2 solutions, it is important to first contemplate the feasibility of layer 1. Perhaps public ledgers will not be able to deal with large amounts of transactions due to their layer 1 designs. In this context, it could be said that permissioned ledgers like Hedera Hashgraph are more prepared for scaling as their paid layer 1 systems are more prepared to handle larger demand. This is confirmed by the fact that Hedera has been shown to process 100,000 transactions per second (TPS) while public chains like Ethereum lag behind at around 15 TPS. In the end, these scaling solutions, while presenting feasible solutions to increase transactions per second, are not whole in their design and must be further developed if they are to fix a less-than-perfect layer 1.
On the Author
Benjamin Sarquis is a senior at Georgetown University, studying Finance and Chinese. With a background in banking, he works in the Finance Team at Hashing Systems.
