Second Layers are Not the Scalability Silver Bullet
Second layers are a big part of Logos’ scalability plan. But our primary focus is scaling the first layer to the limits of hardware and beyond.
To many people, this seems redundant. Indeed, one of the most common questions we field is why Bitcoin plus Lightning is not the killer solution for decentralized payments. Bitcoin and, more generally, legacy proof-of-work networks as a whole (with some notable exceptions) are largely banking on these second layer solutions to solve their scalability woes and provide a viable path to adoption, generating significant excitement in the process.
So why does a project like Logos that focuses on the first layer need to exist? Despite popular belief, second layer solutions, like Lightning, are not the cure-all scalability solution.
There are several issues, both practical and theoretical, that have huge implications for the usefulness of second layer for many use cases. Most importantly, second layers are neither secure nor efficient without a massive increase in first layer security.
As a result, it is critical to scale the first layer instead of relying on second layers to fix legacy, outdated technology.
A Brief Overview of Second Layers
How Second Layers Work
Before describing the limitations of second layers, we’ll briefly explain how they work.
At its most basic, a second layer is a mechanism that moves transactions off the first layer but still benefits from the same security. The first layer is the base validation layer for processing transactions. It includes all transaction data as well as a consensus process like mining.
The idea behind second layers is that you can combine many bilateral transactions together and only settle the net exchange on the first layer periodically. This theoretically would substantially reduce the number of transactions on the first layer.
The simplest type of second layer is a payment channel, which is typically implemented using a hashed timelock with multisignatures. Payment channels involve locking up funds in a bilateral escrow-like account with one on-chain transaction, transacting (hopefully) several times, and settling the net transaction with another on-chain transaction.
For example, if Alice and Bob want to transact with one another, they can set up a payment channel with $5 each. If Bob then sends $2 to Alice, the payment channel would reflect that Alice has $7 and Bob has $3. If Alice then sends $6 to Bob, the channel would show that Alice has $1 and Bob has $9. However, both transactions occur in the payment channel rather than on the first layer. When the payment channel settles to the first layer, it nets both transactions into a single first layer transaction!
A simple analogy to payment channels are Amex gift cards. If you receive a gift card and want to use it, you spend it like any other debit card online or in person. This involves the Amex network validating the transaction and moving the money from the gift card to the recipient’s account (and paying a very large fee in the process!).
Let’s say you and a friend want to transact back and forth with one another using Amex gift cards. This would get very inefficient, with Amex taking a big fee for each transaction. Here, the Amex network is equivalent to the first layer.
Alternatively, you could physically give the card to the recipient — anyone who holds the card can spend the money. Of course, this would require that the recipient know that the gift card has the value you claim, but that can easily be verified online. You and your friend could repeatedly give the card to each other any number of times, at no cost! Eventually, someone will spend it directly, but only when they expect the other will not have something valuable they will want to pay for in the future. This effectively nets all the transactions between you and your friend into one single transaction. This is essentially what second layers do.
Advanced Second Layers
Other second layers largely use payment channels as the fundamental building block, and all share common characteristics such as locking up funds off chain. A single payment channel, of course, is not very useful by itself. Chances are there are not many people you transact with regularly enough to make establishing a bilateral payment channel worth it. What makes them more generally useful is the ability to chain together several different payment channels.
For example, if Alice wants to transact with Carol but they do not have a payment channel set up, they could instead use a common friend Bob to facilitate the transaction. Alice sends the funds to Bob in their channel, and Bob sends the same amount (but different tokens!) to Carol. In effect, the funds can hop between nodes on the payment channel network until they get to the intended destination.
This is the fundamental idea behind the Lightning Network, which is the second layer project that has generated the most excitement. Lightning is being implemented on Bitcoin, Litecoin, and other networks.
Alternative proposed second layers include Celer and Sprites. There are several Ethereum focused second layer projects, notably Plasma and Raiden.
For this article, we will focus on Lightning, although the arguments apply to all second layers generally.
Benefits of Second Layers
The potential benefits of second layers are compelling.
Payment channel transactions require only a simple cryptographic signature exchange. This means they can happen virtually instantaneously, limited only by the latency between the parties involved and a quick computation.¹
These transactions are also very cheap compared to normal first layer consensus. Even with chaining several payment channels together, they should significantly cut transaction costs.
A payment channel can theoretically handle unlimited transactions, assuming that the parties are consistently transferring roughly the same value back and forth with one another.
Most importantly, by netting several transactions together, they can allow the network as a whole (both first layer and second layer) to process more transactions overall.
Given these benefits, it would seem that second layers are indeed a great scalability solution. And they are for many use cases, particularly those that require many small, quick transactions like IoT networks. But are they the ultimate scalability solution in general, as their proponents suggest?
Are Second Layers a Silver Bullet?
There are several fundamental issues with assuming Lightning and other second layers will be a silver bullet solution for all payments needs.
Capital Inefficiency
Payment channels lock up value for extended periods of time. It is clear that each payment channel needs to handle at least three transactions to be more efficient than transacting on the first layer, as establishing that channel and settling it requires two first layer transactions.
In fact, to make a meaningful impact on scalability, they would need to handle tens or even hundreds of transactions each. Realistically, this means that for an everyday user, the channel needs to be open for a week or more to make economic sense.
Furthermore, each user on the network almost certainly needs several channels established to ensure they can reach everyone they would like to transact within a reasonable number of hops. Each hop incurs a cost that, while presumably smaller than first layer validation, is non-trivial.
While channels can be chained together, the value from one channel cannot directly transfer into another channel owned by that same user. This means that each intermediary is effectively financing the transaction. Mathematically, the average value in each channel on the network needs to equal the average amount transacted per channel times the average number of hops per transaction.
All these factors mean that second layers are quite inefficient, both in terms of the amount of funds required for each transaction and the length of time those funds are locked up in channels. Capital locked in channels is unproductive, and anyone with finance experience can attest that capital is costly — it’s how banks are able to earn trillions of dollars each year. This cost increases with risk, and, as explained below, there are several risks that second layer projects typically fail to consider.
Consequently, for the payment channels to be efficient economically, they need to be limited in size or charge users significant fees.
Volatility Risk
One of the risks of locking funds up for significant periods of time is volatility. Bitcoin and other cryptocurrencies are highly volatile, with annualized vol often exceeding 100%. Since no one (even hardcore enthusiasts) entirely lives their lives in Bitcoin (at the very least, they need to pay taxes in fiat!), volatility is a direct cost of holding Bitcoin for any period of time — and an expensive one at that.
In fact, there is a key catch-22 in achieving adoption for something like Bitcoin: there aren’t many real economic transactions using cryptocurrency due to volatility (which is very expensive to hedge), but volatility is high because there aren’t many real economic transactions.
Fundamentally, volatility exposure is proportional to the square root of time, so breaking this cycle requires minimizing the amount of time real economic users need to hold the crypto asset.
Payment channels, as outlined above, do just the opposite. In fact, projects like Lightning often assume a user will lock up enough funds in the second layer to last a year (c.f. Lightning white paper). Requiring that a user lock up substantial funds in a payment channel and eat the cost of volatility personally is highly unrealistic. Opening and closing channels rapidly can only reduce volatility exposure to the first layer confirmation time (which is ten minutes or longer for proof-of-work networks like Bitcoin), and, regardless, defeats the purpose of second layers.
Given this volatility, any initial use of Lightning with Bitcoin will be highly specialized and require many channels being opened and closed rapidly (besides early adopter enthusiasts who get some utility from participating). Thus, it is more reasonable to assume an early Lightning user will be opening/closing thousands of channels per year rather than two or even twelve — any lower assumption fails to recognize the cost of volatility.
The volatility issue can be mitigated with the use of stablecoins, but adding stablecoins to second layers in both Ethereum and Bitcoin is difficult in their current architectures and somewhat unproven. Even assuming they can be incorporated, there are several other issues that hamstring second layers.
Centralization Issues
Since the amount of funds required per channel scales with the number of hops between users, and each hop incurs direct cost, the economic equilibrium of any second layer network mandates a hub-and-spoke topology. In other words, rather than each user connecting to many other users on the network, they would connect with a few hubs that have channels with large fractions of users.
While this topology makes the network economically viable, it comes at the price of increased centralization by giving hubs significant power. A single hub could possibly censor an account that it did not like, or, at the very least, make it much more expensive and difficult for that account to transact. It also leads to a key settlement security risk that we will detail later. One of the key improvements that DLT networks offer over traditional solutions is decentralization, and migrating all use cases to the second layer would eliminate many of these benefits.
Channel Drift
Think about your own daily life and your transactions. Chances are there are very few incoming transactions (your paycheck), while there are many more outgoing transactions going to stores, restaurants, and other merchants. Due to the capital inefficiency issues outlined above, among other issues, it’s not realistic to assume people are going to receive their paychecks via Lightning,² which means that almost all your transactions will be outbound!
More generally, almost all channels would be expected to have a dominant direction. Even organizations that have roughly balancing inbound and outbound transactions overall would have almost all channels predominantly moving in a single direction — otherwise, why would the transactions need an intermediary in the first place?
This is the phenomenon of channel drift. The consequence of channel drift is that the proportion of first layer channel openings and closings to second layer transactions will be much higher than second layer proponents suggest. This means that second layers do not provide unlimited scalability; in fact, we’d expect a relatively constant ratio of first and second layer transactions at equilibrium.
There are some clever ways to replenish depleted channels from other open channels, but these are only partial mitigations that do not work for general cases.
Routing Difficulties
What do these economic and practical limitations mean for everyday use?
Given the issues, we would not expect that second layers would be useful for any meaningful-sized transactions. In fact, the larger the transaction, the more difficult it will be to complete through the second layer. Since each channel traversed between the originator and recipient needs to have sufficient funds in the right direction, the number of possible routes declines with transaction size.
While a large transaction could be broken into many smaller transactions, this adds another layer of complexity and cost, and the aggregate connections between the two counter-parties still need to be sufficient to handle the transaction size in the desired direction. As noted above, this needs to work for all transactions, not just a single transaction, and once a channel is depleted it needs to be replenished via first layer transactions in general.
In addition to these theoretical arguments, there is substantial empirical evidence that indicates second layers do not work well for non-trivial transaction sizes.
Due to all these issues, as well as others, second layers are a very incomplete solution for payments. While promising for microtransaction settings, second layers are not a practical answer for many of the most compelling use cases for decentralized payments, like point-of-sale.
Why Second Layers Require Scalable First Layers
The general applicability of second layers is widely debated. Less discussed but in many ways more important is the fact that first layer scalability is required for second layers to work under any reasonable real-world circumstances, regardless of use case.
A second layer deployed on a first layer with limited capacity is not only practically hamstrung but also a serious security risk. Even the architects of Lightning acknowledge that, along with several other of the issues raised in this article, Lightning requires significantly more first layercapacity than existing networks provide to be secure.
Security issues with limited first layer capacity
Fundamentally, the recourse that a Lightning user has if someone is trying to steal their funds is to settle down to the first layer, within a limited time window. This time window cannot be too long without exposing payment channels to liveness attacks, as it represents the minimum time a user must wait to settle an unresponsive channel.
This recourse, of course, assumes that there is enough capacity on the first layer for the victim’s channel to settle.
For such a unilateral commitment transaction to be economically successful, its fee must be (1) not too high given the value in the channel (or else it ends up being a large cost), and (2) not too low so that it doesn’t get processed (i.e. several times the current market rate).
Due to the hub-and-spoke topology, these networks require to be economically viable in the first place, a single attacker or a small group of attackers can force a significant portion of the network channels to settle simultaneously. Thus, second layers assume that the potentially tens of thousands of other users or more being attacked simultaneously can settle.
If there is insufficient capacity, the settlement transactions become competitive with one another, causing a perverse increase in fees when they need to be lowest. This means that the richest channels will be advantaged (since the fee would be a lower percentage of value at risk), a phenomenon seen in other markets.
For the economic reasons noted previously, Lightning is most useful for small transactions, which makes the fee conditions a fundamental issue if there is any chance for fees to increase significantly.³ In the context of Bitcoin, fees are likely already too high even with basically no real-world adoption. It certainly would not work for any meaningfully sized user base.
Even without the fee issue,⁴ if there is not enough capacity on the first layer, the attacked users are at risk of losing their funds. This is a simple mathematical observation — after the time locks expire, there is a race condition between the victim’s settlement transaction and the attacker’s.
It is important to also consider that second layer transactions will not be the only first layer transactions, which limits capacity for settlement transactions even further.
The Ethereum team has articulated a similar argument, while Vlad Zamfir has postulated a security concern in the reverse direction (i.e. second layer decreases first layer security) and other second layer attack vectors.
So it is clear that second layers require sufficient first layer capacity to be secure. Consequently, second layer capacity can only scale with a commensurate increase in first layer capacity. But how much capacity is needed?
Capacity required for non-trivial number of users
At a minimum, the first layer needs sufficient capacity for (1) channels opening and closing, (2) channels settling from attacks (with room to accommodate all attacks), and (3) direct use of the first layer by users and other applications.
From a practical usability standpoint, 100mm users would require 43 transactions per second (tps) just to refill their channels once per month (including closing old channels). Due to the economic issues like channel drift, volatility, and capital inefficiency as well as the need to maintain several channels to ensure connection with a broad network, users will likely refill much more frequently than this. So we likely require 500 tps or more for a moderate number of users, just for everyday channel transactions.
However, as explained previously, you need many times that normal channel transaction capacity to accommodate channels that have been attacked settling down to the main net and overall security.
Growing to a global scale requires thousands of tps at a minimum, but more realistically tens of thousands of tps.
This scalability issue is acknowledged in the Lightning white paper, where the authors estimate Bitcoin will require 133MB blocks (vs 1MB currently) just to facilitate the opening of 2 channels per year per person on a global scale. It is well established that proof-of-work cannot safely scale beyond several MB blocks, which means that any proof-of-work system will not be able to securely support a second layer with any meaningful adoption in any reasonable timeline.
Limits and Use of Second Layers
Given these realities, it is very hard to see how Lightning can be successful on a legacy network like Bitcoin. Lightning requires low volatility, relatively low fees, and, most importantly, capacity on the first layer. But Bitcoin cannot provide those without massively improving its first layer scalability and attracting real economic transactions first. Assuming that Lightning will be the path to these two outcomes ignores the technology’s dependencies and is circular reasoning.
It is naive to think that Bitcoin, with a max capacity of 7 tps, will be adequate as a settlement layer for millions or billions of users on second layers. While second layer solutions provide an important role for many applications, such as micropayments, in-game transactions, IoT networks, and ad tech, it is critical that they have both theoretical and practical security.
At Logos, providing the highest performance first layer in terms of capacity, speed, and cost is the top priority. A second layer is never going to be the primary channel for point-of-sale, peer-to-peer, or B2B payments due to economic realities and limitations. But this first layer infrastructure, as well as other features like native stablecoin support, makes Logos the ideal second layer platform for those niche use cases where they are the optimal solution.
[1] Note that this is not actually instantaneous like many people claim. Logos consensus only takes a small constant factor longer.
[2] Lightning proponents would beg to differ, but getting to this point, even ignoring the capital cost factor, would require many hurdles to be overcome with no clear reason why they would. This is a common issue with arguments for second layers — many use cases only work assuming a vastly different state of the world (e.g. everyone lives their lives in Bitcoin), but there is no way for that state to be reached!
[3] Without getting too technical, the basic partial mitigation mechanism for such settlement attacks is limiting the transaction fee that the attack transaction can have, typically by fixing it at channel opening. This allows the victim to submit a higher transaction fee and hopefully beat the race condition. However, the preset settlement fee must be sufficiently high so that it can settle in a reasonable time frame. This leads to the problem outlined above, which becomes a very restrictively binding condition without sufficient first layer capacity.
[4] Lightning in its current formulation requires fees for security.
If you’d like to keep up with what we are doing:
Follow us: Twitter | Discord | Telegram | Reddit
Read: White paper | Logos website
