The True Trilemma for Bitcoin Layers

Chainway Labs
13 min readNov 6, 2023

--

There has been a struggle in identifying and addressing the scalability trilemma for Bitcoin layers. Previous attempts to address Bitcoin scalability have adopted a restricted viewpoint, fixated solely on utilizing BTC. This fixation has resulted in constraining the Bitcoin scalability discourse to the BTC. However, it is essential to adopt a broader stance, recognizing and considering the Bitcoin blockchain as a foundation for Layer 2 solutions.

Bitcoin is ideal. It is the most decentralized and secure base layer. This neutral base layer should be leveraged and utilized for a variety of on-chain financial activities, extending well beyond simple payments. We should be forward-thinking and provide users the privilege of relying on Bitcoin’s blockchain security while engaging in more advanced on-chain financial activities. Crypto users deserve the peace of mind knowing that their activities are secured by the most decentralized base layer.

Bitcoin is designed to be as simple as possible to be as secure as possible, and it perfectly achieves its goal in its current form. New layers that emerge on top of Bitcoin should inherit Bitcoin’s full security to create a scalable and programmable infrastructure for on-chain finance.

Visiting The Trilemma

The Blockchain Scalability Trilemma

The blockchain scalability trilemma is originally put forward for Layer 1 solutions to explain the inherent tension of achieving all three properties ​​simultaneously. We can reinterpret each aspect to apply it for Bitcoin Layer 2 solutions. Let’s establish simple definitions for these aspects and delve into them in detail.

Scalability: In the context of Layer 2s (L2s), scalability should refer to the ability to exceed the performance of the base layer. For Bitcoin layers, an ideal scalable solution should not only handle a larger volume of transactions than the base layer but also support a wider range of transaction types that are more expressive.

Security: Defining security for Layer 1s can be complex due to the multifaceted aspects like token economics or consensus mechanisms. However, for Bitcoin layers, we can easily identify security as a spectrum of properties inherited from Bitcoin. This spectrum is the degree to which a layer relies on what Bitcoin provides for its security. For instance, a layer might anchor its block hashes to Bitcoin’s blocks while maintaining the blocks off-chain, thereby inheriting Bitcoin’s resistance to reorganization but not its liveness. There are four primary properties that define a layer’s security: liveness (data availability), censorship resistance, re-org resistance, and validity.

Decentralization: Similarly, when decentralization is discussed in the context of Bitcoin layers, the decentralization of Bitcoin layers should parallel the decentralization of the base layer to a large extent. Although the metrics for measuring base layer decentralization are often misunderstood, the key focus should be the ease with which one can verify the blockchain. For Bitcoin, emphasis should be placed on nodes rather than miners. While miners are tasked with producing blocks, it is the nodes that verify the validity of these blocks. Put simply, nodes enforce consensus and chain rules, not the block producers. For L2s, we can apply the same metric: how easy is it to validate the L2? This includes both accessing the L2 data and verifying it. We will explore this in greater detail.

Scalability of a Bitcoin Layer

The scalability of a Bitcoin layer is a multifaceted challenge. At the most basic level, we would want a layer that not only processes more transactions but also has the capacity to perform a wider range of financial operations than the base layer.

The first aspect of scalability is relatively straightforward, referring to the throughput of the layer, typically measured in transactions per second (TPS). The second aspect, however, requires a deeper examination. For an ideal Bitcoin layer, we envision functionalities extending beyond simple payment transactions. This could encompass lending, swapping, or executing complex payment contracts.

To facilitate such advanced operations, a layer would need a Virtual Machine (VM) capable of programming and executing these functions. While not essential for scalability per se, the ease of programming such a VM is advantageous as it can accelerate development activity within the layer. History has shown that many base and secondary layers with intricate VMs have struggled or failed to attract significant development activity, indicating that complexity alone is not a silver bullet for success.

The Ethereum Virtual Machine (EVM) is by far the most popular VM for blockchains, and several Bitcoin layers have adopted it or variations of it. However, it is important to note that there are varying degrees of EVM compatibility when integrated into new layers. Therefore, it is crucial to recognize that not all VM implementations offer the same range of functionalities as the original, with some providing full equivalence and others only a subset of capabilities.

Understanding these distinctions is vital in assessing the scalability of a Bitcoin layer, as it directly impacts the type and scope of financial activities that can be performed securely and efficiently on top of the base blockchain.

Security of a Bitcoin Layer

The definition of security within the scalability trilemma has indeed evolved significantly from its original conception for base layers. For a base layer, security is contingent on various factors, including sybil protection mechanisms, consensus models, and more. There are four key properties that define the security of a base layer:

  1. Liveness (Data Availability): This pertains to users’ ability to access the entire blockchain state by verifying each state transition. If data publication on base layers is compromised — for example, if a block producer creates a block and publishes the header but withholds the transaction data — liveness is not achieved. As a result, no one can independently verify the state and maintain the blockchain’s operation.
  2. Censorship Resistance: This is the capacity of users to have their transactions included in a block. Multiple block producers and nodes, which can propagate transactions, ensure this resistance in base layers.
  3. Reorg Resistance: This is the blockchain’s resilience against reorganization attacks. While base layers may experience temporary reorganizations due to network delays or varying incentives, these are typically resolved in a short time. In Bitcoin’s context, it’s generally accepted that a block is finalized once six subsequent blocks have been added to the chain. Although finality in Bitcoin is probabilistic, reorganizations deeper than six blocks are highly unlikely.
  4. Validity: This is the users’ ability to verify state transitions effectively. With Bitcoin, anyone operating a full node can validate the transition from one UTXO set to another by processing the corresponding blocks, and this process is deterministic. Validity is closely tied to liveness as data must be accessible before it can be validated.

When discussing the security of Bitcoin Layers (Layer 2 solutions), we define it as a spectrum that indicates the extent to which the security properties of the underlying chain are inherited.

Layer 2 solutions can inherit the aforementioned properties from the base layer to varying degrees, forming a spectrum. For instance, a Layer 2 might have its transactions validated on the base layer but keep transactional data off-chain, resulting in inheriting validity from the base layer but not liveness.

Due to Bitcoin’s limited programmability, direct validation of external state transitions (like those of Layer 2) isn’t feasible currently. However, indirect validation by Layer 2 users can rely on Bitcoin’s security model, closely approximating the security assurances of direct Bitcoin validation. We will explore this concept further.

Decentralization of a Bitcoin Layer

Decentralization encompasses several aspects and is intrinsically linked to security. Being decentralized implies that any individual can join the network without permission to access the blockchain state, validate state transitions, broadcast transactions, and potentially produce blocks. Let’s break down these components as they relate to the different aspects of decentralization:

  • Accessibility to Retrieve State (Liveness): This correlates with liveness. A decentralized network should allow anyone to retrieve the current state of the blockchain, ensuring data availability.
  • Ability to Verify State Transitions (Validity): This is about validity. Decentralization ensures that any participant can independently verify the correctness of state transitions.
  • Freedom to Broadcast Transactions (Censorship Resistance): This aspect is connected to censorship resistance, emphasizing users’ ability to submit their transactions to the network without facing the risk of being blocked or ignored, thereby ensuring freedom from censorship.
  • Capability to Produce Blocks: While this can be viewed as part of censorship resistance, it’s somewhat distinct and arguably the least critical aspect. The ability to produce blocks doesn’t hold as much importance because block producers do not dictate the blockchain’s rules. Block production is essentially about compiling a set of transactions that adhere to the established consensus rules. It is actually the nodes, not the block producers, who enforce these rules.

A telling example is the incident of a Bitcoin mainnet block mined by Marathon at block height 809478. Despite utilizing considerable hashing power, it was rejected by the nodes and consequently not added to the main chain.

This leads to a fundamental equation:

More Nodes = Greater Decentralization

That’s why each Bitcoin layer should prioritize the ease of running nodes. If a Bitcoin layer demands software that requires excessive memory, storage or bandwidth, it will inherently be less verified and, consequently, less decentralized.

Ideally, a Bitcoin layer would be integrated directly into the Bitcoin network, allowing users to validate the layer with minimal additional effort beyond what is required for validating the Bitcoin network itself. This approach promotes maximum decentralization and leverages the security and established trust of the Bitcoin base layer.

Bitcoin Layers’ Trilemma

The True Trilemma for Bitcoin Layers

Taking into account all the definitions we’ve discussed, we can slightly modify the original trilemma to make it compatible with Bitcoin layers. While the changes are subtle, the revised trilemma will likely be more coherent in light of the explanations provided.

You might now be curious about how existing or proposed models fit within this trilemma. Let’s examine the various models and attempt to position them accordingly.

Positioning Bitcoin Layers

There are numerous layers that could be evaluated in the context of the blockchain trilemma, but for brevity, we will focus only on the well-known and currently operational Layer 2 projects that don’t require a soft fork to function.

Lightning Network

The Lightning Network is the most recognized and widely adopted layer on Bitcoin, dedicated to enabling near-instantaneous payments. Having been in operation for nearly five years, its capacity to process instant payments exceeds that of the Bitcoin base layer. This advantage stems from its architecture, which is tailored to a single use case. As of today, Lightning’s functionality is limited to peer-to-peer Bitcoin exchanges — essentially, facilitating payments. Although it enhances the throughput of payments, it doesn’t expand the underlying infrastructure of Bitcoin to encompass additional functionalities, which considerably restricts its scalability potential.

From a security standpoint, the Lightning Network operates peer-to-peer atop Bitcoin. This means that properties such as liveness, censorship resistance, and resistance to chain reorganizations are managed off-chain, between two parties. The only aspect tethered directly to Bitcoin is the validity of transactions, which is verified optimistically. The peer-to-peer component of Lightning doesn’t bring in any new trust assumptions from external chains, allowing us to consider it as one of the most secure layers to Bitcoin.

When it comes to decentralization, Lightning’s peer-to-peer nature is advantageous. Each participant must establish and maintain their own distinct node. This requirement ensures that the network remains decentralized, as the nodes are individually operated and not centrally controlled.

To sum up, the Lightning Network enhances Bitcoin’s capacity for processing payments with near-instantaneous settlement times and maintains a high degree of decentralization due to its design, which requires participants to run individual nodes. However, while it leverages Bitcoin’s secure infrastructure for final settlement, it introduces new security considerations that are unique to off-chain networks. Additionally, its functionality is specialized for scaling payment transactions and does not extend to other types of on-chain financial applications, limiting its applicability in the broader landscape of blockchain finance. Consequently, the Lightning Network achieves one aspect of trilemma with its high degree of decentralization and is well positioned on the security spectrum except for the implementation complexity of the protocol. However, it remains limited on the spectrum of scalability.

Liquid Network

Liquid is a federated sidechain developed by Blockstream, which relies on a consortium of trusted entities to manage its operations. Its design enables it to handle a higher volume of transactions and offer enhanced functionality beyond what traditional Bitcoin transactions can provide. The scalability of Liquid is generally seen as satisfactory within its existing framework.

However, when it comes to security, Liquid stands apart from Bitcoin. It operates as a distinct network that does not share or inherit security features from the Bitcoin blockchain. This independence implies that the operators of Liquid have the capacity to withhold data, initiate chain reorganizations, and censor transactions within the Liquid network. Such potential actions could hinder users from fully verifying the blockchain, leading to concerns about centralization and questioning the robustness of its decentralization.

To conclude, Liquid presents a different approach to scaling Bitcoin transactions by introducing a sidechain that offers higher throughput and additional features beyond the Bitcoin mainchain’s capabilities. However, its security model diverges from Bitcoin, as it is predicated on a federated structure controlled by a consortium of trusted entities. Consequently, while Liquid manages to satisfy the scalability property of the trilemma, it faces challenges with other two properties due to the centralization risks associated with its governance and security model.

Stacks

Stacks is a sidechain that employs a Proof of Transfer (PoX) mechanism for sybil resistance. It utilizes the Clarity smart contract language to facilitate a broader range of functionalities than what Bitcoin can support. Additionally, Stacks has the capability to process a greater number of transactions compared to Bitcoin due to its larger block size and reduced block interval.

Operating with a distinct consensus mechanism, Stacks functions independently from the Bitcoin network. This means that the production and broadcasting of new blocks in Stacks are managed within its own network. Concerning liveness, Stacks relies on its own network for continuous data availability.The process of censorship resistance is also separate from Bitcoin. Users send their transactions to Stacks block producers through nodes within the Stacks ecosystem, therefore depend on the goodwill of Stacks block producers to have their transactions included in blocks. While reorganization resistance is somewhat tied to Bitcoin, the duration for finalization is currently too extended for critical financial operations. Stacks is exploring improvements in its forthcoming updates to enhance finalization times by anchoring block hashes to the Bitcoin network daily.

To participate in network verification, users are required to operate a Stacks node, which necessitates connecting to a network that is distinct from Bitcoin’s, downloading blocks, and conducting validations. The number of nodes participating in the network is inherently limited due to the requirement for a separate network connection and custom node software, resulting in a node count much lower than that of the Bitcoin network.

In conclusion, Stacks enhances the scalability of blockchain functions beyond Bitcoin’s capabilities through larger block sizes and smart contract functionalities, thereby achieving the scalability aspect in the trilemma. However, it encounters challenges with the decentralization and security properties of the trilemma. Stacks’ security relies on a separate consensus mechanism and network infrastructure, introducing different trust assumptions from Bitcoin. As for decentralization, the requirement for users to run Stacks nodes creates a distinct network whose degree of decentralization is yet to be fully assessed.

Rootstock

Rootstock (RSK) is a sidechain that brings Ethereum’s Virtual Machine (EVM) compatibility to Bitcoin through merge mining. This approach allows for the simultaneous creation of sidechain and Bitcoin blocks, aiming to improve the network’s scalability beyond what Bitcoin natively offers.

Despite its scalability advantages and EVM compatibility, Rootstock’s security differs significantly from Bitcoin. Notably, unlike Stacks, Rootstock does not even have inherent reorganization (reorg) resistance, leading to fully independent trust and security assumptions.

Similar to Stacks, Rootstock operates on a separate network and requires specific software for node operators to validate its blockchain. Merge mining contributes to a higher hashrate, which is beneficial for the network’s security, but it does not inherently guarantee the honesty of block producers. The degree of decentralization, a critical factor for a blockchain’s robustness, is measured by the number of independent nodes. The number of nodes in Rootstock is inherently limited for the same reasons as Stacks, resulting in a node count significantly lower than that of the Bitcoin network.

In brief, Rootstock enhances Bitcoin’s scalability by introducing EVM compatible smart contract capabilities. However, it diverges from Bitcoin’s security model, as it does not inherit any of Bitcoin’s security features. The security of Rootstock is based on its own trust assumptions, independent of Bitcoin. In terms of decentralization, Rootstock’s reliance on an external set of nodes just like Stacks creates an upper bound for its decentralization property. Consequently, while Rootstock satisfies the scalability aspect of the trilemma, it struggles with both security and decentralization properties.

Chainway’s Sovereign ZK Rollup

Chainway’s Sovereign ZK Rollup represents a significant innovation in the blockchain space, being an EVM-compatible ZK rollup directly built on the Bitcoin network. It utilizes zero-knowledge proofs, specifically ZK-STARKs, for transaction verification and efficient use of Bitcoin’s block space. Chainway’s ZK Rollup distinguishes itself as the only Bitcoin Layer 2 solution that meets the highest standards across all three fundamentals of the Bitcoin Layer 2 trilemma.

The EVM-equivalent design enables a seamless transition for developers to deploy applications, preserving the familiar Ethereum environment while utilizing the robust Bitcoin network. The ZK architecture’s strength lies in processing thousands of transactions instantly, with the recursive proofs ensuring scalability within the parameters of the blockchain trilemma.

Chainway ZK Rollup introduces a method for verifying state changes by inscribing proofs to the Bitcoin blockchain. These inscribed proofs can later be extracted and verified. The proofs output the state differences from the previous proofs, providing all the essential information needed to retrieve the full blockchain state using the Bitcoin network.

The block space proof ensures Bitcoin-equivalent censorship resistance, as users can inscribe their transactions on the Bitcoin network themselves. This approach also ensures that block producers cannot exclude these transactions due to the constraints of ZK circuit generation.

Reorg resistance is inherently achieved because the proofs are inscribed on the Bitcoin blockchain, thus anchoring the rollup state to Bitcoin blocks.

The fact that anyone running Bitcoin Core can verify the rollup’s proofs maximizes decentralization in the validation process. This strategy effectively turns every Bitcoin node into a rollup node, drastically improving the decentralization.

As a result, Chainway’s Sovereign ZK Rollup appears to effectively address the blockchain trilemma by achieving scalability without compromising on security or decentralization. It ensures liveness, censorship resistance, and reorg resistance, leveraging Bitcoin’s security properties, and avoids the need for a separate trust-dependent network.

Conclusion

The categorization and evaluation of Bitcoin Layer 2 solutions is not simple. Suggesting a new trilemma or comparison may lead to an oversight of the nuances that are important for scalability, security, and decentralization. Within the original trilemma framework, each corner represents a fundamental blockchain property that successful Layer 1 blockchains must achieve simultaneously, or at the very least, strike a balance among them. By subtly extending the definitions at each corner, we applied the core trilemma effectively to Bitcoin layers.

This adherence to the original trilemma ensures that we do not confine Layer 2 projects within rigid yes-or-no categories but rather appreciate the spectrum of decentralization and various factors that categorize Layer 2s. Maintaining this established framework not only promotes a more accurate assessment of the status quo within Bitcoin layers architecture but also extends the fundamentals of blockchain properties to the Layer 2 paradigm.

Chainway

Twitter | X

Github

--

--