Layer-3 (Application Layer) Scaling Solution
(This article was first published on Altcoin Magazine)
“How can you build a house without the foundation?!” This is the feedback most ambitious entrepreneurs get especially from investors when they share their projects to develop decentralized applications. It is no secret that scalability is the number one issue right now preventing wider adoption of blockchain technology. Most decentralized applications with reasonable usage require higher transaction-per-second (TPS) than distributed ledgers that live in the market (such as Ethereum) can offer today.
Scaling is a significant challenge because of the “blockchain trilemma” described in Figure-1. Since blockchain systems can only have at most two of the three properties — security, decentralization, and scalability — most blockchains choose security and decentralization and hence sacrifice scalability.
While there are significant research and many projects tackling the scalability issue, almost all of them focus on layer-1 or layer-2 solutions such as VRF, sharding, plasma, state channel, and other solutions. Unfortunately, these solutions are nowhere even close to being launched or usable in the market anytime soon.
Could and should scalability challenges also be addressed at the layer-3 (application) layer? Could some decentralized applications make optimizations at layer-3 so they can move forward, instead of being blocked and waiting for the layer-1 or layer-2 solutions to be deployed and become usable? The answers are a resounding YES for most decentralized applications.
The Blockchain Tetralemma
The biggest advantage of a layer-3 scaling solution is that it does not require any change to the existing underlying blockchain infrastructures. This means the system can have all three properties as shown in Figure-1. How can this be possible? It is counter-intuitive, as there must be a tradeoff when optimizing the blockchain system.
Even though it is not obvious, there is an implicit assumption in the blockchain trilemma. It assumes every transaction needs on-chain settlement as quickly as possible and hence the blockchain system should never sacrifice on-chain settlement time (OCST). If we add the OCST property into the ring, we actually have Tetralemma as shown in Figure-2.
This tetralemma treats the whole problem as a system-level problem while the trilemma treats the problem as an infrastructure-only problem. This different philosophical thinking is critical in unlocking many new solutions that can quickly change the current landscape where “no real-world impact decentralized applications have been developed and deployed due to the scalability issue at the blockchain infrastructure layer”.
Layer-3 scaling solutions require sacrificing on-chain settlement times (OCST) to provide security, decentralization, and scalability all at the same time. Obviously, only applications that do not require fast on-chain settlement time can benefit from such solutions. Luckily, most applications meet that requirement.
For example, for a commerce application like Amazon, it is a totally acceptable user experience to confirm and settle a commerce transaction at the end of the day instead of immediately. Hence Amazon can batch many transactions into one on-chain settlement transaction so that it can overcome the scalability limitation at the blockchain infrastructure layer. And in case an on-chain settlement generates the problem, Amazon can always withhold the shipment or take some other actions. This is not much different from waiting for a credit card transaction to confirm.
Deja Vu
Looking back at the history of technology, the scalability challenges that blockchain faces today has happened many times in other technologies during their early days. Smart solutions at the application layers are developed to overcome the throughput limitations at the underlying infrastructure layers. Historically, it has always been the case that applications figure out solutions to move forward without waiting for the underlying constrained infrastructure to be fully developed, eventually inspiring new infrastructure to be built and enable new applications, starting and driving the so-called apps-infrastructure cycle.
The Internet is a perfect example In the early days of the Internet, most people accessed the Internet via a dial-up phone line, which has a maximum theoretical transfer speed of 56 kbit/s. To overcome the bandwidth limitation, many applications used compression technology to compress the data first before transmitting the data via the dial-up Internet connection. With good compression technologies, the Internet throughput could be increased by 10x if the data was compressed to 10% of its original uncompressed size.
Wireless communication provides another good example, as spectrum is always a limited resource. To transmit more data through the same wireless bandwidth size, better wireless data encoding technologies such as GSM, CDMA, OFDM were developed. Each generation of encoding technology has increased the spectrum efficiency significantly.
Existing Scaling Solutions at Layer-3
A simple approach to push more transactions through the resource-limited underlying blockchain infrastructure is to batch transactions. In Bitcoin, batching is achieved by combining many transactions from one sender into one transaction, which can save up to 80% on the Bitcoin transaction fee. (More advanced batching such as signature aggregation and Taproot are coming.) In Ethereum, batching is achieved by creating a smart contractwhich can be called only once to transfer funds from one sender to multiple recipients. Even though batching is easy to implement, the usage of batching only starts taking off when Bitcoin transaction fees hit all-time highs or a token project needs to send tokens to hundreds of recipients. Fundamentally, batching in the blockchain system is similar to compression in the dial-up Internet.
Batching can improve scalability but is bounded by the limitations of the underlying blockchain systems. For example, Bitcoin is limited by its block size and Ethereum is limited by its gas cap per block. Recently, Vitalik Buterin, Ethereum founder, proposed to scale Ethereum to potentially ~500 transactions per second using ZK-SNARK, which has seen its first implementation and inspired many new projects including roll-up, side-chain, and full data availability. Without going into too much technical detail, ZK-SNARK is a cool technology that can compress computation off-chain and requires very little computation and data storage for on-chain settlements. The downside is that ZK-SNARK is very expensive to implement right now even though it is being improved. Fundamentally, ZK-SNARK in the blockchain system is similar to encoding technology in wireless communication.
Scalability can be further improved for a specific application. For example, in a commerce application, many transactions will share the same receiver — the vendor selling products. These transactions can be combined to reduce the total transaction size, leading to further scalability improvement. As you can see, application-specific scaling solutions require more optimized programming, which is lacking right now, unfortunately. However, I am confident that the decentralized application developers will improve quickly once they understand that they can move forward with layer-3 scaling solutions instead of waiting for the layer-1 or layer-2 scaling solution to be developed and deployed.
Conclusion
Scalability is the number one issue that has prevented wider adoption of blockchain technology. However, scaling challenges similar to the “blockchain trilemma” have happened many times before during the early development of other technologies. Just like we saw in the growth of the Internet and wireless communication applications, smart scaling solutions are being developed at the layer-3 (application layer) to overcome the throughput limitation in the underlying blockchain layer. Decentralized application developers: stop waiting and start building. We are looking to you to “build a house without the foundation!”
Acknowledgment: Thanks Jason Teutsch, Alex Gluchowski, Michael Lapinski, Brandon Bidlack, Danny Yang, Ryan Gentry, Chris Peel, for their reviews, comments, and suggestions.
