Classifying Bitcoin Layer 2s

Thank you to Red Sheehan for collaborating on L2 classifications and review. Thank you to Elena Giralt, Andre Serrano, Alexei Zamyatin, and Orkun Kilic for discussion and ongoing review.

Building on Bitcoin is back.

The world of Bitcoin scaling continues to develop and evolve. Over the last 18 months, we’ve seen a renewed focus on Bitcoin Layer 2 solutions. Validity rollups were introduced as a new scaling option, BitVM took the Bitcoin world by storm, and current sidechain solutions are moving forward with plans to decentralize and minimize trust within their architectures.

This new world of Bitcoin development is exciting, but for everyday users, it can be difficult to wrap your head around. Not everyone has time to read through documentation sites, and trying to get the answers to your questions on Bitcoin Twitter can be a challenge.

Bitcoin’s utility doesn’t solely come through hodling, being left cold and alone on a USB stick. Its future sees it bringing life to a thriving digital economy as a permissionless medium of exchange. As users begin adopting the solutions that enable this, they should be able to understand the various tradeoffs of the systems that they’re interacting with. Users deserve to know the risks they’re taking on, from an unbiased source.

That’s why we will be introducing Bitcoin Layers - a simple website that outlines the various tradeoffs when using Bitcoin Layer 2 solutions. The website will cover the technological nuances with various Bitcoin scaling solutions, certain risks, and which use case might be best suited for everyday Bitcoiners.

But, the question still remains. What is a Layer 2? How do we define it, and how do we determine where each project lies on the trust spectrum?

What is a Bitcoin Layer 2

First, we have to define what is, and what isn’t, a Bitcoin Layer 2 (L2). A few solutions exist in the market today. Most people are familiar with Lightning for small payments, and they may have heard of federated ecash protocols, which are similar to lightning but with different tradeoffs.

There’s also a group of sidechains working to provide further programmability to Bitcoin. And, we’re now even researching how zk-rollups can drive new forms of Bitcoin adoption.

How are these solutions different, and how do they compare to each other?

There are numerous projects building around the designs mentioned above that classify themselves as Bitcoin L2s. Traditional sidechains, for example, do not integrate with the Bitcoin base layer outside of enabling a trusted multi-sig to transfer BTC in and out of the sidechain. But, because they scale Bitcoin, add functionality to BTC, or both - we consider them an L2.

The Ethereum Layer 1 (L1), on the other hand, is not a Bitcoin L2. While it is another blockchain that has a bridge connected to Bitcoin, and provides utility to BTC the asset, it does not exist to scale Bitcoin.

In short, we define a L2 as 1) a protocol that lives off the Bitcoin L1, which exists to scale Bitcoin and provides different ways to use BTC and/or 2) a protocol that uses Bitcoin for security and pays fees to Bitcoin miners.

Defining trust-minimization

We analyze projects on their path to becoming trust-minimized. Trust minimization isn’t binary. It’s a wide spectrum of designs and tradeoffs that are tailored to specific use cases. But, that doesn’t mean that projects shouldn’t work towards minimizing the various trust assumptions within their ecosystems, whether that be at the protocol or application level.

Ultimately, we define trust-minimization, in the context of Bitcoin L2s, as not having to trust any individual or group with the custody of your Bitcoin. This means two things:

• Users do not need to trust any specific entity (including federated multi-sigs) with the custody of their BTC when bridging to a L2. They simply rely on Bitcoin consensus for securing the bridge contract
• Users can withdraw their BTC, or assets originating from Bitcoin, from the L2,to the Bitcoin L1, in the event that they’re censored by the L2 operator(s), or L2 block production is halted

Any L2 that has both of these two properties, is trust-minimized in theory. And, trust-minimization and maximal decentralization are the endgame for most projects. But today, these two properties are not even possible on Bitcoin due to limited Bitcoin script functionality. But, there are promising innovations happening in the Bitcoin space that might make this possible in the near future.

As new projects and teams continue to innovate with Bitcoin L2s, users need more tools to evaluate what's possible in theory versus what's available in the market today. And to be fair, it isn’t reasonable for every project to launch completely trust-minimized, so it’s crucial that we document their current state, and their path to more decentralized architectures. And, hold projects accountable to the claims they make.

Categorizing Bitcoin Layer 2s

This upcoming website will largely be inspired by the work of L2Beat in the Ethereum ecosystem. On the L2Beat website, they classify rollups, Ethereum’s primary scaling solution, via stages.

While rollups are coming to Bitcoin, there are other scaling solutions that are vastly different from rollups, and will continue to be developed to support various use cases.

So we need to review a number of diverse considerations when categorizing Bitcoin L2s. And, how we analyze various risks may differ between various protocols.

First, we review how L2s come to consensus. We also consider how it verifies its state update, and leverages Bitcoin’s network security for block production.

Consensus

Here’s are the different mechanisms that L2s can generally come to consensus:

• Offchain: A separate consensus protocol where consensus is agnostic to Bitcoin.
• Offchain and Onchain: A separate consensus protocol where consensus is dependent on the L1, or L1 can play a part in securing the network (e.g. Merge-mining)
• Onchain: A separate protocol that inherits consensus from the Bitcoin L1.

This is the primary way that we categorize L2 solutions. We view that inherited consensus is ultimately the best way for L2s to come to consensus, and should be the long term goal. We prefer that L2s inherit their consensus from the L1 because it can ensure that users will be able to exit the L2 should they need to, and the L2 ultimately pays Bitcoin miners to post its data to the L1.

It is worth noting that full-fledged, inherited consensus is currently not possible on Bitcoin layer 2s today.

Bitcoin Hashpower

We also consider how the L2 leverages Bitcoin hashpower for security, and if fees are paid to Bitcoin miners for validating L2 blocks. The classifications are as follows:

• Offchain: None of Bitcoin hashpower influences block production. If the protocol is independent of Bitcoin
• Offchain and Onchain: Some Bitcoin hashpower influences block production
• Onchain: All of Bitcoin’s hashpower influences block production
  • This includes L2s that leverage alternative block production for faster pre-confirmations, but ultimately post state updates to the Bitcoin L1 for finalization.

We view that L2 solutions should find a way to include Bitocoin’s hashpower in their block production processes. However, we do believe that L2s can remain sufficiently trust-minimized, for certain use cases, if they opt to not use Bitcoin hashpower for any aspect of block production.

Data Availability

In another category, we provide more granular definitions Here’s how L2s can write their state updates onto Bitcoin for data availability:

• Offchain: Data is not stored on Bitcoin and Bitcoin is not involved in verifying execution
• Offchain and Onchain: Data is initially not stored on Bitcoin, state identifiers are stored on Bitcoin, or partial data is stored on Bitcoin
• Onchain: Full data is stored on Bitcoin every Bitcoin block

Writing state updates can also be done on a variety of trust assumptions. We view that L2s aiming to be as decentralized, and aligned with Bitcoin, as possible should post all data to the Bitcoin L1 so Bitcoin full nodes can read the data and verify the state of the L2. However, we do believe that there is a large spectrum of trust assumptions and design here, and acknowledge that some use cases may require different tradeoffs versus others.

Bitcoin Layer 2 Categories

Considering these factors, and the overlap between some of the definitions, we’ve decided to generalize the definitions and initially classify Bitcoin L2s as:

• Federations: Protocols that rely on permissioned entities to manage all aspects of the protocol
• Channel protocols: multi-signature contracts where parties can perform transactions while the channel is open. These transactions are off-chain and settled back to Bitcoin L1 once the channel is closed.
• Sovereign Chains: Fully separate consensus protocols that provide different functionalities with varying security assumptions.
• Client Side Validation protocols: Where users (or light clients) validate the history of their transactions and/or Layer 2 state
  • Sovereign Rollups: Separate protocols where settlement is verified by a network of light nodes reading data stored on the Bitcoin L1.
• Integrated Chains: Separate consensus protocols where block production, data availability and consensus is in some way dependent on the Bitcoin L1.
• Bitcoin Verified Chains: Separate protocols where the L2 state and execution is fully verified by the L1.

Assessing Layer 2 Risk

When assessing L2 risk, the first thing users should know is how the BTC they are using in the L2 is custodied. The more custodial the BTC bridge, the more trust assumptions and centralization risks users have to take on when interacting with the L2. Users must be aware of those tradeoffs when interacting with L2s.

After this custodial risk is assessed, we need to dive deeper into the various design tradeoffs and associated risks. The initial version of Bitcoin Layers will focus solely on sidechains and sovereign rollups. This is because validia chains and L1-verified rollups are not yet possible on Bitcoin (but may be possible with the help of BitVM). We will have risk analyses for federated protocols and state channel layers (i.e. Lightning) in Q2/Q3 of next year.

For risk assessment, we evaluate each L2 in five areas described in more detail below.

BTC Bridge

As mentioned, the first thing we consider is if the L2 uses a bridge that custodies user assets to bring BTC to the consensus protocol. Here we have four levels of risk:

• Custodial: One entity custodies the funds of L2 users (Very High Risk)
• Federated Multi-Sig: Permissioned nodes used to secure the bridge contract custodying funds for users (High Risk)
• Third party consensus: Permissionless consensus protocol used to secure the bridge contract custodying funds for users (Medium Risk)
• Trust-minimized: Bitcoin consensus enforces the rules of the bridge (Low Risk)

Data availability

• Offchain: State updates are not stored on Bitcoin (High Risk)
• Offchain and On-chain: Data is primarily stored on another publicly available network, but Bitcoin full nodes can access that data (Medium Risk)
• On-chain: Data is stored on the Bitcoin and L2 writes state updates onto Bitcoin directly (Low Risk)

Bitcoin full nodes cannot reject invalid state updates inscribed onto the network by L2s. Invalid state updates must be rejected by L2 nodes/light nodes.

Upgradeability

• Single operator: One entity can upgrade the system and change the code that secures the system at any point (Very High Risk)
• Multi-sig: Permissioned signers can upgrade the system and change the code that secures the system at any point (High Risk)
• Delegated governance: Community participants must delegate their given stake in the network to a third party who votes on their behalf (Medium Risk)
• Community governance: Community participants can directly participate in consensus and upgrading the system (Low Risk)

Governance can not currently be verified on the Bitcoin L1 in a trust-minimized fashion. All L2 governance is verified solely by L2 validators. Also, there are additional cavaets to L2s requiring L1 signers for upgrading their system. If the L2 upgrades happen on the L1 via a multi-sig, and the multisig has no delay, funds are at risk to be stolen via malicious upgrade. If it has a delay (through covenants or its emulation), users have a timespan to exit the L2 before the upgrade happens.

Block producer failure

• Cannot access funds: If centralized block production in the L2 fails, or your transaction is censored, you are stuck in the L2 and cannot access funds or withdrawal (Very High Risk)
• Decentralized block production: If decentralized block production in the L2 fails, a user’s transaction is censored, or a user cannot self-sequencer, they are stuck in the L2 and cannot access funds or withdrawal (High Risk)
• L1 escape hatch: If centralized block production in the L2 fails, or your transaction is censored, you can submit your transaction to the L1 directly (Medium Risk)
• Decentralized block production + L1 escape hatch: If decentralized block production in the L2 fails, or your transaction is censored, you can submit your transaction to the L1 directly (Low Risk)

State validation

• Onchain, in development: The system permits invalid state roots and doesn’t have an active proving system in place (High Risk)
• Offchain: State validation is only done by L2 nodes (Medium Risk*)
• Onchain, Permissioned: The system allows a permissioned actor to post state updates to Bitcoin (or challenge state updates in a fraud proof scheme) (Medium Risk)
• Merge-mining: Bitcoin miners and full nodes can opt-in to validating Layer 2 blocks (Medium Risk)
• Onchain, Permissionless: The system enables anyone meeting requirements to poststate updates to the L1, or challenge state updates previously posted to the L1 (Low Risk)

This section has multiple categories to cover the distinct way Bitcoin L2s can validate state. Offchain state validation, performed by protocols such as sovereign rollups or CSV protocols, is more of a choice than a direct risk.

The best approach?

Candidly, individuals must be the ones to determine the best approach depending on their use case. Earlier on, we mentioned that trust-minimization is defined as being able to trust Bitcoin consensus for securing the bridge contract, and being able to exit the L2 if needed. However, even if the system is trust-minimized, there can still be risks.

For example, if Bitcoin has an extremely high fee market, and a centralized block producer censors an L2 user, that user might not have enough funds to exit the L2. In a system independent of Bitcoin consensus where there is no exit mechanism, but permissionless block production, the same user may have to wait awhile for their transaction to be mined, but can be assured that it will eventually be mined.

Additionally, we primarily focus on risks, without covering the "rewards" namely. Some protocols with higher risk could offer faster throughput, additional programmability, improved privacy or other benefits. Even if the system is maximally trust-minimized and decentralized, it may not meet the needs of a given user.

That’s why each user should take the information presented on Bitcoin Layers as a part of their own personal research process, and make the best decision for their particular use case.

We don’t aggregate our scores and assign a general risk score, because risk is different to every user. Again, users should just simply take the presented information and make the best decision for themselves.

Closing

We will be releasing our first iteration of Bitcoin Layers by the end of December. In this iteration, we will present risk scores for current L2s/Sidechains and also publish a page for upcoming projects whose risk we will assess when they go live on their respective mainnets.

If you have any feedback on how we will assess L2 risk, please comment on this blog.

We’re excited for the upcoming wave of Bitcoin development. There’s never been a more exciting time to be a Bitcoiner.

But, even as we build new applications and protocols to onboard the next wave of Bitcoiners, we must hold each other accountable in accurately disclosing risks when interacting with L2s.

Onwards!