.png)
Bitcoin, conceived as a decentralised peer-to-peer electronic cash system, has excelled in its decentralised promise. However, its potential as an everyday peer-to-peer payment system is compromised due to inherent scalability issues. Addressing these challenges without sacrificing the core principles of decentralisation and security has led to the development of a variety of Layer 2 (L2) solutions.
The most prominent L2 scalability solution for Bitcoin is the Lightning Network, which enhances transaction throughput using micropayment state channels. Conceived by Joseph Poon and Thaddeus Dryja in 2016, it has undergone continuous refinement ever since.
The Lightning Network operates on the principle of off-chain transactions, thereby reducing the load on the main blockchain, which is used only for final settlement. This network is an assembly of nodes running Lightning Network software, currently accounting for 13,413 nodes and 55,016 open channels. Notably, 4,705.29 BTC (approximately $244M) are locked within the network, emphasising that these figures represent the nodes that have elected to connect to block explorers, hinting at potentially higher actual numbers.
To elucidate, consider payment channels akin to open bar tabs, with the blockchain as the bartender and transactions as the ordered drinks. Lightning Network transactions are off-chain, akin to a tab where the final bill represents the sole transaction recorded on the main blockchain.
Utilising Hash Time-Locked Contracts (HTLC), the Lightning Network secures funds and transactions, enabling transactions across existing payment channels for a nominal fee. BOLT (Basis of Lightning Technology) is instrumental in constructing the network, encompassing:
The network does not operate as a parachain (as defined in the Polkadot ecosystem); rather, it functions independently from Bitcoin to enhance transaction throughput.
Several concerns arise with the Lightning Network:
Rootstock represents an L2 smart contract platform that functions as a Bitcoin sidechain, allowing the deployment of EVM-compatible smart contracts and benefitting from Bitcoin's robust security. With over 50% of Bitcoin's hashing power through merged mining, Rootstock asserts substantial security for its network.
Rootstock's sidechain architecture emerges from a two-way peg to the Bitcoin blockchain, enabling users to transfer Bitcoin and receive RBTC (Rootstock Smart Bitcoin), which interacts with smart contracts on the RSK blockchain. Essentially, this allows users to engage with decentralised applications and execute complex contracts, bolstering Bitcoin's functionality. Furthermore, the Rootstock Virtual Machine (RVM) extends compatibility with Ethereum smart contracts.
$RBTC enhances Bitcoin's utility within DeFi protocols and dApps on the Rootstock network, providing a seamless transition between the main chain and the sidechain without the need for token wrapping, maintaining a 1:1 peg to Bitcoin.
Stacks introduces smart contracts to Bitcoin without altering its fundamental protocol by operating as a sidechain. Viewing Bitcoin as a foundational layer, Stacks adds programmability and smart contract functionality on top of it.
PoX(Proof-of-Transfer) is the consensus mechanism used by Stacks and it consistsof stacks miners sending Bitcoin to a special address on the Bitcoin blockchain exchange for STX tokens on the Stacks blockchain.
Using an analogy to understand the PoX consensus:
As it can be appreciated, Stacks uses Bitcoin solely for its reputation and trust worthiness without needing to alter Bitcoin's foundation.
Stacks connects toBitcoin by anchoring every Stacks block into a Bitcoin block. This means that the Stack’s blockchain state is continuously recorded on the Bitcoin blockchain. This ensures that Stacks inherits Bitcoin’s security and Stacks’ record becomes immutable.
For context, let’s explore how Ethereum rollups work:
The core principle of rollups involves performing transaction execution outside the main chain and then sending the transaction data back to the main Ethereum network. Ethereum rollups come in different types: Optimistic and ZK rollups.
Use zero-knowledge proofs to validate the transactions in a batch by leveraging those proofs as evidence that the transactions are valid and follow the rules of the Ethereum blockchain.
For these rollups, transactions are executed off-chain, a network of nodes generates transaction data and proofs of validity which are then submitted back to the main chain in the form of call data.
ZKRollups have 3 main components:
1. Transactions: Users sign transactions, which sends them to layer-two producing blocks and batches.
2. State Commitments: These are snapshots of the current L2’s state. These snapshots are later hashed and stored in the main chain as call data.
3. Zero-Knowledge validity proofs: Proofs that serve as cryptographic validity guarantees of transactions in a batch being valid, that they follow Ethereum’s rules, and that they won’t mess with the blockchain’s state.
The data flow in a ZK rollup goes as follows:
Users sign transactions and send them to the operator.
Transactions are collected in an off-chain pool where the rollup operator will aggregate many transactions into a single batch.
The batch is processed off-chain which involves executing the transactions and updating the state accordingly.
After processing the transactions, the operator generates a ZK proof that says the transaction batch is valid. It also generates a State Commitment which is a hash that contains the updated state of the accounts after the batch was processed.
The main chain will quickly verify the ZK proof against the state commitment to ensure transactions’ authenticity.
Once verified, the main chain smart contract updates the blockchain’s state to reflect the new state commitment.
The separate under a similar concept to ZK Rollups, with the main difference that optimistic rollups assume the transactions’ validity by default until proven otherwise. In a few words, the difference between ZK and Optimistic rollups relies on the way each of them validate proofs.
Considering this context and process of Ethereum ZK rollups, are they possible in Bitcoin, or more so, why are ZK rollups not possible on Bitcoin? In short, Bitcoin’s inability to support a rollup is due to its inability of running smart contracts.
Smart contracts play a crucial role to run a range of computations within the rollup data flow.As it can be appreciated previously, there are several points in which data must be offloaded and uploaded from the layer 2 to the main chain and vice versa. In contrast, Bitcoin doesn’t support this on-chain logic.
The second reason is Ethereum is a stateful blockchain which means transactions can depend on data not only included within a transaction. On the other hand, Bitcoin is considered a stateless blockchain, meaning blocks don’t contain a complete copy of the entire state of the network. Instead, the blockchain only records transactions and data associated to them, such as the sender, recipient, and amount of Bitcoin transferred (Bitcoin only tracks UTXOs) and this makes it more difficult to build state-based solutions.
Lastly, Bitcoin’s consensus mechanism doesn’t align well with the implementation additional transactions and computations that will only lead to block space limitations.As mentioned above, a ZK Rollup requires not just the submission of proofs but also constantly updating the blockchain’s state.
While ZK Rollups are not natively possible on Bitcoin, there are projects that still explore ways to build similar solutions on Bitcoin. Nevertheless, due to the fundamental differences previously mentioned, all Bitcoin “L2s” are in reality sidechains can provide scalability and privacy.
Read more: https://www.simplicitygroup.xyz/blog
Twitter: https://twitter.com/SimplicityWeb3
Telegram: https://t.me/SimplicityGroup
Newsletter: https://thoughts.simplicitygroup.xyz/subscribe