Scalability. The word has haunted Bitcoin since the network’s founding. To reduce the strain on the Bitcoin network, a new batch of Layer 2 (L2) solutions have emerged, in the hopes of scaling transaction volume.
But what exactly constitutes a Bitcoin L2 network, and how do its critical components like bridges, consensus, and validation work? To understand these details, we’ll first look at how L2s can enhance Bitcoin's capabilities and why the models of today fall short of achieving practical scalability.
This article will outline what defines a Bitcoin L2 and take a look at the intricacies of today’s offerings. With several teams working out their own solutions to the trilemma of security, scalability, and decentralization, the competition is heating up—here’s what it all means.
#Anatomy of an L2
At a glance, a Bitcoin L2 is a network that combines the security of the Bitcoin protocol with improved scalability, enabling greater access to bitcoin the asset. A trust-minimized L2 network must ensure a cryptographically secure means for participants to hold sovereign custody of their assets. Transaction security on these networks is maintained through proof-based consensus mechanisms like Bitcoin's Proof of Work (PoW) or economic incentives derived from the network's native asset like Proof of Stake (PoS) on Ethereum.
Ultimately a Bitcoin L2 must support the notion that BTC ought to be accessible to all. On Bitcoin mainnet, this tenet is exhibited in that nearly anyone can use a computer with internet access to create an account, interact with the network, and engage in commerce. Building on this concept, a properly engineered Bitcoin L2 deployment must scale commerce levels, reduce the load on the Bitcoin network, and by doing so promote wider accessibility of BTC.
To achieve the desired levels of scalability while upholding Bitcoin’s security model, an L2 relies on data availability to maintain network integrity. In this context, that means ensuring that sufficient information is constantly accessible for validation and dispute resolution, a crucial facet for eliminating trust and upholding security when transactions processed on an L2 are finalized on the Bitcoin network. With a perpetual and immutable record of an L2 network’s transaction data available, auditors can always validate the state of what resolves on-chain.
Different L2 designs handle data availability for Bitcoin in various ways. For instance, in Lightning Network’s state channels transaction data is kept off-chain, with only the final states posted to the main blockchain. For Lightning Network to function, all parties in a channel must have access to the most recent transaction state. This data availability is vital for dispute resolution, allowing parties to contest and prove if an attempt is made to close the channel with an outdated state.
Although it is a technically aligned L2 solution (more on this later), some things about the Lightning Network leave room for improvement, such as setup complexity, the fear of bugs that could potentially stall or result in lost funds, or potential network disruption by malicious actors through various methods.
Bitcoin must move to a state where transaction fees and network activity account for a more significant share of miner earnings—as it stands today Lightning cannot be the only answer for Bitcoin scaling if it can’t offer globally priced transaction fees. These issues must be addressed before we can consider consumer adoption of the Lightning Network a possibility.
#Bitcoin Rollups
Rollups are a category of L2 solutions that process and store transaction data off-chain, and then post either raw transaction data or “proofs” to the main blockchain. Rollups are broadly classified into two types: optimistic rollups and zero-knowledge (ZK) rollups.
In optimistic rollups, the transaction data is presumed valid unless contested. This presumption places high importance on data availability, as users need access to historical data to challenge and prove any fraudulent activity during the designated challenge period, generally seven days. This model presumes that at least one of the participating validators will act “honestly” to prevent fraud, meaning that at least one actor will follow established network protocols to prevent a network takeover.
Without at least one honest actor in an optimistic rollup, validators can push forward a bunch of untrue transactions and steal funds from users without dispute. The optimistic rollup model also defers finality for the period that it takes for a block to go undisputed, which is less than ideal.
On the other hand, a ZK rollup compiles numerous transactions into a single ZK proof that is in turn posted to the main blockchain. While bitcoin-facing ZK rollups seem to be cropping up everywhere, almost akin to the proliferation points programs across social graphs, they seem to be riding the coattails of successful products in the space and are more marketing than substance.
Today’s general-purpose ZK rollups are complex and thus difficult to implement for developers. They can’t be verified on the Bitcoin network, and many ZK rollups lack compatibility with the popular smart contract environments across the space. This can stifle adoption across an entire batch of solidity developers who cannot easily integrate their existing smart contracts.
What’s more, the existing ZK rollup offerings aren’t built to be validated on Bitcoin. The solutions out there today rely on external verification methods, and so far, no one has built a ZK verifier that runs natively on the Bitcoin network.
Efforts to produce a virtual computing environment compatible with the Bitcoin network are underway, most notably by Robin Linus with BitVM, which introduces a method for executing Turing-complete contracts on the blockchain while adhering to its existing consensus frameworks. BitVM allows for arbitrary logic validation, and complex off-chain computations, relegating any on-chain activity to disputes.
However, BitVM has yet to enable flexible parameterization of verifications, meaning that should a verification fail, a fixed amount of BTC will always be lost. Inflexibility is inconvenient, and it makes implementation difficult. Not to mention the costs! Executing an arbitrary computing environment on Bitcoin is expensive. Before BitVM is ready, we’ll need new standards, testing, and hardening.
#Sending Bitcoin Across Networks
The state channel-based Lightning Network integrates directly with the Bitcoin network, again perhaps exhibiting the greatest technical alignment in terms of native support for BTC. For other L2 solutions to function, however, L1 assets from Bitcoin must be transferred via a network bridge that connects to the L2 network.
How bridges manage consensus, which is to say how they validate state to verify a user’s genuine efforts to secure, store, or issue assets, varies from project to project. The structure of these bridges is perhaps the most important component of Bitcoin L2s. While a completely trustless solution sounds ideal, it’s currently not possible to build this type of bridging protocol—that would require smart contract level readability on Bitcoin mainnet.
What can be built today is a trust-minimized bridge. The lower the trust inherent in a bridge design, the more comfortable users will be bridging their funds to a given L2 network. Deep liquidity is the building block of the DeFi ecosystems built on top of Ethereum, and without it, those ecosystems would cease to exist.
An example of a trusted bridging setup that exists today is called a federated governance model, such as that used by Liquid network. This approach passes off block validation duties to a cadre of members who function in various roles in the transaction verification process.
Federated networks offer general efficiency, however, the gated nature by which membership is approved is a centralized bottleneck. As such, a federated approach to bridging BTC to an L2, while useful for certain applications, lacks the permissionless nature that is a core value of the Bitcoin network and a majority of its users.
The most popular form of bridging is “wrapping” the BTC, where users can send their bitcoin to a designated address and be issued a “wrapped” BTC on the destination chain via smart contract. BitGo’s wBTC is an example of such a protocol. While entirely reliant on BitGo, a centralized entity, wBTC is widely utilized and a backbone of DeFi, currently ranked in the top 20 major cryptocurrencies with a current market cap of $7.8B.
A reserve of native BTC backs the wrapped BTC, which sits in the above-mentioned address and is managed by the custodian of the bridge. Naturally, this presents yet another point of centralization—if anything goes wrong with the bridge’s asset reserve, the wrapped token's value becomes worthless.
So, if a central service provider experiences a glitch in its code, experiences a hack, or otherwise suffers a security breach, the potential result is a loss for those with value locked on the bridge at the time of the incident.
#Remote Staked BTC
One alternative to bridging, currently in development, is to “remotely stake” BTC from the Bitcoin network. The BTC would essentially be locked in a contract with slashing conditions that activate in the event of a protocol violation. However, the limited expressiveness of Bitcoin’s scripting language presents challenges around a reliable mechanism for on-chain BTC slashing.
Some headway on these challenges has been made by the Babylon team. Their protocol is multifaceted and includes a system of accountability assertions to reveal private keys in the event of contradictions, and finality gadgets to transform all safety violations into contradictions of responsible claims. If a private key is leaked, Bitcoin covenant emulation ensures the burning of funds, and Bitcoin timestamping guarantees the penalty transaction can be executed before a user begins un-staking.
Even with its approach, Babylon’s staked BTC still requires a bridge of some form to enable a fully functional Bitcoin L2 network.
#BTC As A Bridged Usable Asset
A significant issue that all of the abovementioned solutions face is insufficient outside collateral to scale. For an L2 solution to thrive, it needs access to the Bitcoin network’s most important asset—BTC.
For tBTC, reserves are fully backed by BTC on the decentralized Threshold custody network. How? To balance network validation and integrate trust-minimized validation with bridging, the system relies on an honest majority of participants. Participants aren’t limited to BTC holders—it also includes those staking a slashable additional token which serves not as a backing of liquidity, but instead as a critical security measure for token bridging. Validation parameters around new wallet selection amongst stakers can be tuned under the assumption of an honest majority, lowering the custodial risk of the model to a negligible degree.
This structure lays the foundation necessary for a functional BTC L2 solution; one that is capable of providing a widely accessible, decentralized, secure network. By its native support for Bitcoin, that L2 network can scale without needing external capital to manage collateral reserves.
As opposed to relying on an asset like ETH to hold as a reserve against the L2’s BTC-based assets that hinder network adoption, any BTC deployed to the L2 would natively secure the network. The form that BTC takes can be, as we propose, a form of tokenized BTC managed by Sybil-resistant agents, or a permissioned custodial form of BTC.
#Conclusion
As the hardest asset to back DeFi applications, BTC holds enormous potential, evidenced by its continuous acquisition by institutions, governments, high-net-worth individuals, family offices, hedge and sovereign funds, as well as retail investors. The attributes of BTC are extremely valuable in DeFi markets, and it should continue to be a cornerstone to the growth of Defi.
With the growing demand for BTC, why bother to deploy it on another network by way of quasi-centralized gymnastics? Instead, BTC requires an L2 that is directly compatible with its network—one that affords the same benefits other L2s boast in terms of cost savings to transaction throughput while preserving the decentralized, secure, and widely accessible traits of Bitcoin itself.
A trust-minimized Bitcoin L2 is the holy grail of Bitcoin development and will unleash billions in passive capital.
But by the numbers, today’s projects just don’t cut it. However, with a slew of entrants, it’s only a matter of time until a Bitcoin L2 solution arises that satisfies the conditions to unlock the latent potential and widely serve BTC to a new range of participants.
Moving ahead, we must wait and see how such implementations will take shape, and who will be the first mover to offer up a native Bitcoin L2 protocol that satisfies the dynamic criteria laid out by Bitcoin’s core network layer.
