Bitcoin’s development landscape is currently populated by several strategies to enhance the functionality and scalability of the network. These approaches, however, have some key fundamental differences in terms of their architecture, intended utility, and ease of deployment. In this report, we explore the design space for Bitcoin’s “layers” and attempt to characterize the advantages and disadvantages of various approaches currently in development.
In our view, the Lightning Network (a layer-2 protocol) has an advantage over alternative scaling approaches because it leverages bitcoin as the native asset. Other solutions introduce external blockchains (or sidechains), new tokens, and bridges that require a trusted third-party, but the Lightning Network is simply a peer-to-peer communications network that interacts directly with Bitcoin’s base layer. The Lightning Network is not without its own issues and limitations, but as a Bitcoin-native solution, it has achieved greater social consensus amongst the Bitcoin development community. This has helped catalyze a growing ecosystem of applications and projects with real-world utility ranging from remittances to content monetization.
Within the context of the blockchain trilemma, the Bitcoin base layer has been optimized for security and decentralization, at the expense of scalability. The network is rate-limited to produce finalized blocks of transactions every ~10 minutes which can be large – up to 4 megabytes (MB) in size (including up to 1MB of transaction data and 3MB of signature data). On one hand, these limitations are critical in supporting the security and decentralization of the network, as they allow the barriers to entry for participating in protocol consensus to remain low enough (in terms of computation, storage and bandwidth) to be truly permissionless and secure. Conversely, the throughput limitations (~7 transactions per second) inherent to Bitcoin’s base layer make micropayments largely impractical and have historically prevented the protocol from fulfilling a role as an effective medium of exchange.
In order to transcend the “digital gold” narrative and become an effective medium of exchange (able to service billions of users), bitcoin’s infrastructure must scale to facilitate higher throughput and lower cost transactions. That is, as new bitcoin issuance declines (i.e. lower rewards), it’s possible that miners could feel less incentivized to secure the network, and we believe they would need to be compensated by fees generated by demand for blockspace. Therefore, we believe future demand for blockspace will play an important role in the long-term security of the network.
Importantly, the result of the block size war in 2017 further ossified the base layer of Bitcoin. One outcome of the block size war was the activation of the SegWit (Segregated Witness) soft fork, which “increased” the block size by separating the witness data from the transaction data, thus enabling more transactions per block (from 1650 to 2700). (Incidentally, it was this change that ultimately allowed the Lightning Network to be developed.) The success of the “small-block” cohort ensured that Bitcoin’s block size would not be increased (beyond the limits made possible by SegWit) in order to facilitate higher throughput, thereby placing an emphasis on scalability via layered approaches.
The "layer" landscape
The Lightning Network is just one approach to enhancing the scalability of the Bitcoin network. Detailed in Table 1 is a comparison of the most prominent layer-based scaling strategies currently in development. The fundamental difference between the Lightning Network and the alternative strategies (highlighted in gray) is that these layers – whether they be sidechains, independent layer-1s or rollups – currently rely on trusted “pegging” mechanisms to deposit/withdraw bitcoin to/from the external execution environments. Further, they typically introduce a separate token that is representative of bitcoin, which could be considered more of an abstraction relative to a network like Lightning which leverages the actual native asset.
These alternative approaches also differ from Lightning in that their intended utility is oriented towards more expressive smart contracts that go beyond the capabilities of Bitcoin’s scripting language and facilitate specific applications such as liquidity pools, decentralized lending pools, NFT marketplaces, and automated market makers (AMMs). Conversely, Lightning represents more of a Bitcoin-native solution that utilizes the native asset and its corresponding scripting language (Script) to enable near-instantaneous and low-cost payments, which can be applied to a variety of useful applications.
Table 1. Comparison of various approaches to scaling Bitcoin
(project links: Lightning / Liquid / Rootstock / Stacks / Rollkit)
The eventual goal in terms of future development for these alternative approaches (outside of Lightning) is to create a decentralized (trustless) pegging mechanism or bridge. Stacks is one such approach that recently unveiled an updated whitepaper that aims to facilitate the permissionless use of bitcoin in an external execution environment. Separately, Bitcoin developer John Light recently published a research paper as part of the Human Rights Foundation’s ZK-Rollup Research Fellowship that explores the potential of implementing zero-knowledge (ZK) proof technology on Bitcoin. As his research suggests, ZK rollups (or validity rollups as he calls them) could theoretically facilitate a trustless pegging mechanism or bridge, but would likely require new opcodes (operation codes, specific commands capable within Bitcoin’s scripting language) such as proof verification and recursive covenants to be implemented via Bitcoin Implementation Proposals (BIPs). As BIPs necessitate a soft fork of the protocol, these solutions will need to achieve significant social consensus before they can be actualized.
Lightning, on the other hand, requires no changes to the Bitcoin base layer in order to function in a trustless manner. Accordingly, developers can readily build applications and projects that leverage the Lightning Network and be confident they’ll be able to easily deploy their ideas to the masses. Moreover, because building on Lightning does not require changes to the Bitcoin base layer, it is less likely to threaten the ongoing ossification of Bitcoin’s existing protocol rules, which helps support bitcoin’s reliability as a store of value asset.
Underneath the hood of Lightning
The Lightning Network consists of nodes running software that allows peer-to-peer transactions via bidirectional multisignature Bitcoin addresses that act as payment channels. (A multisignature address is a specific type of Bitcoin address that requires multiple private keys in order to authorize a transaction; the typical structure is referred to as “m-of-n” where “n” is the total number of private keys associated with the address, and “m” is the minimum number of private keys required to sign a given transaction.)
Functionally similar to bar tabs that must be reconciled at the end of the night, payment channels can be opened by creating a two-party (2-of-2) multisignature address and funding said address with a certain amount of bitcoin via a base layer transaction. Once a channel is open and funded with bitcoin (representing the upper limit of transactional capacity for the channel), the two parties can conduct an unlimited number of transactions for very low cost. Transactions within a channel are conducted “off-chain.” When users want to close the payment channel, only the net change in value between the two parties is finalized via a single base layer transaction.
Importantly, the architecture of the Lightning Network protocol allows for the routing of payments across the network of interconnected nodes and corresponding payment channels. This means that users can send and receive payments to and from Lightning addresses without having to create a dedicated payment channel between two parties. Lightning achieves this routing process by implementing a specific type of Bitcoin transaction called a Hashed Timelock Contract (HTLC). A HTLC is a type of smart contract that combines two cryptographic concepts – hashlocks and timelocks – to ensure payments can be trustlessly routed across multiple “hops” to and from intermediary channels. This structure suggests that the effectiveness of the network is directly a function of the number of users participating in the network, as they are additive to the overall liquidity of the network as well as the number of available routing destinations.
Improving the infrastructure
Despite its architectural advantages, Lightning is not without its own issues and limitations. Intricacies associated with managing payment channels and maintaining appropriate liquidity can be burdensome for individual users. As a result, the network is susceptible to denial-of-service and Sybil attacks (attempts to control a network by creating multiple fake identities), as well as other vulnerabilities related to potentially malicious counterparties. In order to protect themselves from dishonest actors, Lightning users can utilize “justice transactions” which serve as a punitive mechanism involving the closure of a lightning channel that may be under attack. Moreover, users can outsource these protective measures to “watchtowers,” third-party services that charge a fee to monitor specific Lightning channels.
Bitcoin and Lightning developers are acutely aware of these challenges to usability and are working to improve the infrastructure of the network. One such open-source project called the Lightning Development Kit (initially supported by Chaincode Labs and Spiral). It aims to help developers more easily integrate Lightning functionality into user-friendly applications. A specialized library of APIs, the LDK meaningfully reduces the friction for developers to build and launch applications that can further expand the usability of the Lightning Network.
Separately, an important factor in Lightning payments being reliable is the aggregate liquidity of channels across the network. A recently announced initiative from TBD (a Bitcoin-focused subsidiary of Block) called “c=” aims to create an enterprise-grade “Lightning Service Provider ” (LSP) to bolster channel liquidity accessible to the network. In other words, c= has committed to contributing bitcoin liquidity to the network in order to run a dedicated routing node that can be utilized by individuals and businesses alike. Initiatives like this that support the usability of Lightning will be critical to the maturation of the network and are helping catalyze the proliferation of Lightning-enabled applications.
Measuring adoption growth
Lightning adoption and activity have been steadily increasing, with aggregate channel capacity hovering around all-time highs (currently ~5,480 BTC, or ~US$153M, as shown in Chart 1). While this growth trajectory is encouraging, the channel capacity of the network (a proxy for user activity) is still relatively small compared to the user activity on a network like Ethereum which has a current total-value-locked (TVL) of ~US$29B. Nevertheless, Lightning channel capacity compares favorably to the TVL of the aforementioned scaling alternatives such as Stacks and Rootstock, as shown in Chart 2. It is also worth noting that because Lightning channels are not required to be made public, the available data on channel capacity likely understates the entirety of network activity (an estimated ~30% of channels are private). Further, there are roughly ~18k active Lightning nodes at current, up over 116% since the start of 2021. Another important gauge of Lightning adoption is merchant and corporate integrations. Enterprises such as Shopify, Clover, and Robinhood have announced their intentions to support Lightning-based payments for their respective merchants and users.
Chart 1. Lightning channel capacity (BTC and USD)
Chart 2. Comparison of TVL (channel capacity for Lightning)
Perhaps the most insightful signal of adoption, however, is the emergence of a diverse ecosystem of Lightning-enabled applications in recent years. Detailed in Table 2 are several innovative projects that are leveraging the Lightning Network in some capacity to broaden the utility of bitcoin. Notably, several of these initiatives represent potential solutions to real-world problems including reducing frictions for remittances/cross-border payments, empowering content creators to more effectively monetize their work, and fostering censorship-resistant social networks.
Table 2. Key projects leveraging the Lightning Network
(project links: Strike / Fedimint / Fedipool / Synota / Nostr / Fountain / Wavlake / Mash / Kollider / Taro)
(please also see our report Bitcoin Fedimints)
The efforts detailed above stand in contrast to the applications currently being built on alternative scaling platforms, many of which simply replicate certain products and services already available on dedicated smart contract platforms like Ethereum. For instance, the most popular application on Stacks is a DEX platform called ALEX which accounts for ~93% of the network’s TVL. Similarly, a lending application called MoneyOnChain accounts for ~62% of Rootstock’s TVL. Broadly speaking, sidechains and rollups are more oriented towards expressive smart contracts and programming languages to enable DeFi-like applications, while Lightning is more purely focused on fostering an effective payments layer for Bitcoin. That said, Lightning Network development is supporting more than just payments applications – Fedimint and Fedipool are important examples of leveraging the Lightning Network to build trust-minimized custody solutions and reduce centralization risks for mining pools, respectively.
While far from perfect, the Lightning Network is integral to the future of Bitcoin in that it promises to broaden the utility of the protocol beyond a store of value without needing to infringe upon any existing protocol rules. Moreover, one could argue that some of the most impactful projects in terms of real-world utility are being built on the Lightning Network. Importantly, these projects are complementary to the Bitcoin network and can function with the existing native asset and corresponding scripting language. Alternative scaling solutions – those that introduce external chains, new tokens, or bridges – differ from the Lightning Network in terms of their architecture, intended utility, and ease of deployment. For these reasons, we believe the Lightning Network is well positioned to remain the focal point of future Bitcoin development.
Nevertheless, we feel the various approaches being pursued to build incremental functionality and usability atop the Bitcoin base layer should not be dilutive to one another. While we believe that the Lightning Network possesses some critical advantages relative to its alternatives, we do not view the landscape for Bitcoin’s scalability as winner-take-all. Each approach brings its own set of tradeoffs, and they all share the common goal of broadening the utility of bitcoin and represent sources of potential future demand for blockspace. Overall, we believe the design space for Bitcoin’s layers is more vibrant than most realize and the network should benefit from the diversity of scaling approaches being developed.
On a separate but related note, we would be remiss not to mention the recent advent and rise in popularity of the Ordinals protocol. As discussed in our weekly commentary from early February, the Ordinals protocol allows individual satoshis to be inscribed with data, effectively repurposing them as NFTs that can be transferred and stored on the Bitcoin blockchain. While this protocol effectively represents another “layer” atop Bitcoin, the intended purpose of the protocol is to embed arbitrary data in Bitcoin blockspace, which may prove to be a niche use case for on-chain “digital artifacts,” but is unrelated to the discussion of scalability.
Chart 3. Bitcoin transaction fees (avg. USD) & block size (avg. MB)
Notably, however, Ordinals has seemingly reinvigorated the broader Bitcoin design space and may act as a catalyst for the future development of innovative constructs that leverage the security of the Bitcoin base layer. In fact, the team behind the release of Rollkit (mentioned in Table 1) noted that their designs were inspired by the advent of Ordinals and inscriptions. Moreover, Bitcoin’s long-term security budget will increasingly rely on a robust fee market for blockspace. As shown in Chart 3, the average transaction fee earned by miners as well as the average size of finalized blocks has increased since the release of Ordinals in late January. Within that context, incremental sources of demand for blockspace – whether they stem from arbitrary NFT data, Lightning channel reconciliation, or sidechain/rollup activity – represent positive competitive forces that ultimately increase fees paid to miners, further incentivizing them to secure the network.