Why did we build on Bitcoin + Lightning + Nostr Part 2: Lightning Network vs Other L2s/Sidechains

Welcome to Part 2 of our series, “Why did we build on Bitcoin + Lightning + Nostr?”. In this segment, we embark on a comparative analysis, putting the Lightning Network head-to-head against other Layer 2 (L2) solutions and sidechains.

As we dive into this exploration, we’ll dissect the intricacies of various L2 architectures, examining their security models, scalability mechanisms, and interoperability frameworks.

Read the Chinese version of this Article

With a special focus on the Lightning Network’s distinctive attributes and challenges, our goal is to demystify the complexities surrounding L2 solutions and illuminate their role in bolstering Bitcoin’s functionality and scalability.

Come along as we navigate the landscape of Bitcoin’s layering solutions, aiming to chart the most promising course for our decentralized ecosystem.

Types of Bitcoin L2 and Sidechains

L2 solutions, such as Lightning Network, Bitcoin Rollups, Optimistic Rollups, ZK Rollups, and sidechains, offer distinct approaches to scaling Bitcoin transactions and enhancing its functionality. While each solution presents its own set of advantages and challenges, its overarching goal remains consistent: to augment Bitcoin’s capabilities while preserving its security and decentralization.

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 for Data Availability.

Optimistic Rollup

Optimistic rollups offer a compelling method to scale blockchain transactions while minimizing congestion on the main chain. In this model, transaction data is considered valid by default unless challenged. This highlights the importance of data availability, as users require access to historical data to dispute any fraudulent activity within a designated challenge period, typically lasting seven days.

The optimistic rollup model relies on the assumption that at least one validator will act honestly to prevent fraud, ensuring adherence to established network protocols and safeguarding against network takeovers.

However, in the absence of an honest actor, validators could potentially push through false transactions and unlawfully access user funds without facing a dispute.

Additionally, optimistic rollups introduce a delay in finalizing transactions until they remain undisputed, which is less than ideal for immediate transaction settlement.

Zk Rollup

Zk rollups represent a promising advancement in blockchain scalability and privacy, leveraging zero-knowledge proofs (ZKPs) to compile numerous transactions into a single succinct proof posted to the main blockchain. This innovative approach offers significant improvements in transaction throughput and data privacy, making it an attractive solution for scaling blockchain networks.

However, while Zk rollups hold great potential, some challenges need to be addressed.

Most general-purpose ZK rollups are

• complex and thus difficult to implement for developers
• lack compatibility with the popular smart contract environments across the space

Sidechains

The most important requirement for a Bitcoin L2 is to derive its security from the L1’s security. This is the reason sidechains are classified as such, they have their security. As an illustration, Stacks V1 relied on the STX token to ensure its security.

However, none of the existing rollups or sidechains qualify as an L2 in Ethereum’s context, We will elaborate on this in the following section.

Security and Data Availability

Ensuring the security of Bitcoin 2 L2 solutions is paramount, with their integrity reliant on the robustness of the underlying L1 blockchain. While Bitcoin stands as the pinnacle of security among blockchains, making L2 solutions just as secure is challenging.

L2 solutions need to ensure that transaction data is always available for checking and resolving disputes. They often embed this data into Bitcoin’s blockchain, but this can cause problems because Bitcoin can only handle a limited amount of data at once.

Technically speaking, there is no L2 rollup on the Bitcoin blockchain today (and ‘L2’ is being used very loosely across many L2s) because there is no way to validate a fraud-proof or zk proof on the Bitcoin blockchain. These proofs rely on external verification methods, and so far, no one has built a verifier that runs natively on the Bitcoin blockchain. Some are exploring the feasibility of posting the proof in the form of an Inscription on the Bitcoin blockchain i.e. a sovereign rollup whereby anyone can access the immutable proof and perform validation.

Also, efforts are underway to create a virtual computing environment compatible with the Bitcoin network, notably led by Robin Linus with BitVM.

BitVM enables the execution of Turing-complete contracts on the blockchain while adhering to existing consensus frameworks.

However, current limitations include the inability to adjust verification parameters flexibly, resulting in a fixed loss of BTC if verification fails. This rigidity poses implementation challenges and high costs, highlighting the need for establishing new standards, rigorous testing, and robust hardening measures before widespread adoption can occur.

There are ideas to improve this, like adding new tools such as:

• new opcodes enabling the validation of Zero-Knowledge Proofs (ZKPs) submitted by rollups
• initiatives like BitVM aim to implement fraud proofs without altering the L1 protocol

However, their effectiveness is hindered by high verification costs and the limitations in Bitcoin’s block size and block intervals may impede the storage of all L2 transactions, necessitating innovative approaches to address scalability while preserving security.

• While inscriptions enable the embedding of L2 transaction records into the Bitcoin L1, they also pose scalability challenges. Given Bitcoin L1’s block time limit of approximately 4MB every ~10 minutes, its data throughput is constrained to around ~1.1 KB/s.
• Even with L2 transactions highly compressed to roughly 10 bytes per transaction, Bitcoin L1 can only accommodate a combined L2 throughput of approximately ~100 transactions per second, under the assumption that all L1 transactions are allocated to storing L2 data.

On the other hand, Lightning Network keeps transaction data off-chain, with only final states posted to the main blockchain without straining the already limited block space.

Moving of Bitcoin Across Networks

It’s crucial to understand how different L2 solutions and sidechains facilitate interoperability with the Bitcoin network and if any trust assumption is made.

Lightning Network

The state channel-based Lightning Network integrates directly with the Bitcoin network.

By its native support for Bitcoin, that L2 network can scale without needing external capital to manage collateral reserves.

Other L2s and sidechains

1. Trust-Minimized Bridge
Transferring assets from Bitcoin’s L1 to an L2 network or sidechain requires a network bridge. However, achieving consensus on bridge operations varies among projects and is crucial for the security of Bitcoin’s L2 solutions.

Building a bridge secured by all L1 miners isn’t feasible. Instead, a multi-signature (multi-sig) wallet is commonly used to store L2 assets, and the bridge’s security relies on the multi-sig setup, including the number and identity of signers. Improving bridge security involves using multiple multi-sig wallets instead of a single one to hold all bridged assets.

While a completely trustless bridge isn’t currently possible due to limitations in Bitcoin’s scripting capabilities, a trust-minimized bridge is feasible. The less inherent trust required in the bridge’s design, the more confident users will feel about transferring their funds to an L2 or sidechain network.

Three types of trust-minimized bridges exist:

Type 1: Federated Governance Model
In this model, block validation duties are assigned to a group of members with diverse roles in the transaction verification process.

However, the centralized approval process for selecting members creates a bottleneck in the system. An example of this model is the Liquid network.

Type 2: Wrapped BTC
This method allows users to transfer their Bitcoin to a specified address and receive an equivalent “wrapped” BTC on the destination blockchain through the execution of smart contracts. The wrapped BTC is supported by a reserve of native BTC, which remains in a designated address overseen by the bridge’s custodian.

However, this introduces another point of centralization. If there are any issues with the bridge’s asset reserve, such as a glitch in its code or a hack, the value of the wrapped token could become worthless. An example of this is BitGo’s wBTC.

Type 3: BitVM Bridge implementation.
The proposed BitVM bridge involves multi-sig signers providing a security bond. Within this multisig, any signer can initiate a peg-out transaction. The peg-out process is safeguarded by BitVM fraud proofs.

If a signer engages in malicious behavior, other signers (verifiers) can submit a fraud-proof on the L1 blockchain, resulting in the slashing of the malicious signer.

However, there’s a limitation due to the cost of executing the fraud-proof on the L1, which increases exponentially with the size of the off-chain program of BitVM (as set out above).

2. Remote-staked BTC

Staking BTC remotely from the Bitcoin network involves locking it in a contract with slashing conditions triggered if protocol violations occur. The Babylon team has addressed these challenges by developing a comprehensive protocol.

It includes accountability assertions to reveal private keys in case of contradictions and finality gadgets to convert safety violations into contradictions of responsible claims. In case of a private key leak, Bitcoin covenant emulation ensures fund burning, while Bitcoin timestamping allows the penalty transaction to be executed before unstaking begins.

However, despite these advancements, Babylon’s staked BTC still requires a bridge of some sort to facilitate a fully operational Bitcoin L2 network.

For an L2 solution or sidechain to succeed, it requires access to Bitcoin, the network’s most important asset.

Finality

Finality is the assurance that a transaction has been settled and is irreversible. While on-chain Bitcoin or Ethereum transactions achieve finality through confirmation on the blockchain, finality in the Lightning Network is nuanced due to its off-chain nature.

In the Lightning Network, finality is reached when a channel is closed, and the latest channel state, reflected in the most recent commitment transaction, is broadcasted to the Bitcoin blockchain. However, challenges to finality can arise if a node attempts to cheat by publishing an outdated commitment transaction. In such cases, the counterparty can use a revocation secret to invalidate the outdated transaction and claim all funds.

While the finality of a Lightning transaction is probabilistic and depends on the network’s security mechanisms and participants’ behavior, the likelihood of such occurrence is low, and as such the most recent commitment transaction can be considered a ‘soft’ finality. Nonetheless, the finality of other Layer 2 solutions and sidechains is determined differently, typically through the posting of sequencers’ Merkle tree root hash to the Bitcoin blockchain via Inscriptions i.e. finality is achieved at least at the block time of Bitcoin of 10 minutes.

MEV Extraction

MEV, short for “Maximal Extractable Value,” refers to the extra profits that searchers/miners can get from arranging and executing transactions in a blockchain.

This happens because they can control the order of transactions and smart contract operations.

By doing this, they can tilt things in their favor, making more money beyond regular rewards and fees. MEV can lead to unfair practices like front-running and transaction censorship, affecting how fair, efficient, and secure the blockchain network is.

In the Lightning Network, MEV isn’t a concern, but bugs could still cause problems, risking funds and network stability due to potential attacks. However, in other L2 solutions and sidechains, MEV could be an issue.

These solutions often delegate transaction ordering to Bitcoin-bonded sequencers or L1 miners, which could lead to MEV extraction by these parties.

Conclusion

In conclusion, while Lightning Network offers significant advantages in comparison to other L2s, its limited programmability restricts its use cases primarily to micropayments. Unlike Turing complete virtual machines like Ethereum’s EVM, Lightning Network relies on Bitcoin Scripts, which lack expressive power.

Our upcoming article will further explore how the Nostr protocol enhances Lightning Network’s programmability, unlocking new potential applications and use cases. Stay tuned for more insights into our innovative approach.