Bitcoin Upper Layers Explained: Types, Origins, & Future
By Sergio Demian Lerner, Chief of Innovation, IOV Labs
Bitcoin is on the path to becoming a world store of value. However, as it currently stands, it has bandwidth and privacy limitations that hinder its adoption by the billions of users who desperately need it. Even with the Lightning Network, fewer than a hundred million users could transact in Bitcoin before giving up self-custody of their funds or payments becoming excessively expensive. Without expanding Bitcoin’s payment capabilities, people will be forced to deposit their bitcoins in custodial financial institutions or custodial wallets, bringing back all the security problems (hacks), fiat problems (fractional reserves, censorship, bank runs, restrictions, seizures, etc.), and operational problems (single point of failure). This is far from the Bitcoin ideal of providing a decentralized, antifragile, open currency on the Internet for all the world to use.
While Bitcoin’s growth is capped, other altcoins are slowly filling this functionality gap: they have become cheap payment networks for all kinds of digital assets. But the altcoin path is quite risky: Altcoins cannot protect the civil society if governments ever attack or censor people as they are fragile relative to Bitcoin. Decentralization will only be fully appreciated when civil liberties are at stake, and someday they will.
At this point in time, it seems that usability has won over decentralization. If this trend continues, and we fail to expand Bitcoin’s capabilities using additional protocol layers, the Internet currency will become a centralized and censorable stablecoin. But there is hope.
Possible Solutions: Bitcoin Upper Layers
Researchers and developers have come up with many ideas on how to expand Bitcoin without changing its consensus protocol: Softchains, Spacechains, Fedmints, Federated Sidechains, Spiderchains, RGB, the Lightning Network, DLCs, Taproot Assets, and most recently BitVM. Some of these ideas like the Lightning Network and Federated Sidechains have been successfully implemented, but many others have been abandoned as inadequate. Other sidechain designs are inefficient or require unacceptable security or privacy tradeoffs. What is shared by most of them is that they would require changes in the Bitcoin scripting language to scale to billions of users.
Currently, the Bitcoin community has bet on three main layer 2s to reach mass adoption: payment channels based networks (e.g. Lightning Network), client-side smart-contracts (e.g. RBG) and sidechains (e.g. Rootstock). In this section we analyze their potential and their relation with sidechains.
RGB, which stands for Really Good Bitcoin, is a new type of Bitcoin Layer 2 for creating smart contracts using the Bitcoin infrastructure. It was conceived in 2016, but was only actively developed in the last two years and recently launched. It is based on the idea that all processing should be performed on the client side, without requiring anything from Bitcoin consensus. RGB only uses the Bitcoin blockchain as an anchoring mechanism that establishes the order of transactions, and prevents skipping important contract state transitions. Similar concepts, called overlay blockchains, like Counterparty and Colored-coins, were developed and launched in the early times of Bitcoin, but unlike Counterparty, RGB uses the minimum amount of space in Bitcoin blocks. And unlike colored coins, RGB does not use the bitcoin output amounts for any purpose.
Client side smart contracts are promising, but lack a key element required to interact with Bitcoin: a bridge to transfer Bitcoins into RGB contracts, so that the contracts store or pay in BTC. RGB is capable of issuing and managing programmable and private assets, but it cannot enable transactions in bitcoins, unless they are wrapped or bridged somehow. Therefore, RGB piggybacks on Bitcoin rails, but it’s not a Bitcoin scaling solution. To really become a Bitcoin scalability layer, RGB needs a two-way-peg, which is exactly what sidechains have been pushing for, and perfecting, all these years.
The Lightning Network (LN) is a network of nodes that have pairwise payment channels precreated. These individual channels can be combined to route a payment from any source to any destination in the network, provided that there is enough capacity on the paths that connect these nodes. Most channels are publicly advertised, and they require the pre-deposit of an amount of bitcoins in a shared account known as Hashed Timelock Contract (HTLC). These HTLCs are generally opened with an equal amount of bitcoins provided by the two parties establishing the channel.
Because LN must rely on the very limited capabilities of the Bitcoin scripting language, and because LN is an interactive payment system, it has become a really complex system, and fundamental design problems still arise today. There are success stories of LN used in El Salvador, Cuba and Africa, but it cannot provide the desired level of scalability for global use.
We will present four core impediments for using the LN as a mass payment method. The first fundamental problem is that every LN user needs to open at least one channel, which requires an onchain transaction. Since the block space is limited, and assuming LN transactions use segwit but they cannot take more than 50% of the block space, the LN can only open a maximum of 15M channels/month. Expecting even a moderate block size increase by means of a hard-fork is unrealistic after the blocksize wars. While onboarding 15M user per month is a considerable achievement, it puts a bottleneck in the onboarding rate.
The second problem is that most of the LN users would need to periodically top-up or settle their channels (“rebalance”) for various reasons. For example, when people receive their monthly salary, they are expected to top up their LN channels to pay for everyday bills. Some of the channels will have enough incoming payment capacity, but many others will need to be recreated, consuming block space. Assuming 30% of the users need to recreate their channels in a month, then the LN can only support 50M users.
There is a proposal, called Channel Factories, which can alleviate the problem. It allows a group of users to share a factory contract that enables the future creation of pairwise channels without onchain transactions. The pairwise channels can potentially reach the funds locked in the combined contract, increasing peak capacity. However, it has limitations: the more users participate in a channel factory, the more problematic it becomes to manage users joining and leaving the group, and more vulnerable the factory is to non-cooperating members. Factories also require most members of the group to be online to allow pairwise channels to be created.
The third problem is simultaneous channel closures. We can imagine that certain combinations of unexpected events can result in massive closures. For example, in case of the sudden regulatory attack on LN nodes, big hubs can turn malicious and attempt to steal during channel closures taking advantage of congestion.
Recently, a vulnerability was discovered in the LN, and if this vulnerability had been easier to exploit, this could have triggered a race to close channels. The rush can clog the mempool, saturating the block space. Since LN channels depend on time-locks, a delay in processing punishments to malicious forced closures can lead to chaos, similar to bank runs, as users could be forced to spend most of their funds on fees to accelerate closures. A typical timelock value is 2016 blocks, which is equivalent to about 14 days. Bitcoin can only handle 15M successful forced closures a month without putting users’ funds at risk. In other words, it can’t handle more than 7.5M users trying to withdraw their funds before expiration.
The fourth problem is that a LN user needs a counterparty willing to lock bitcoins in a channel when it is opened. This represents a financial loss for the counterparty that is generally compensated with LN payment fees. However, the situation disfavors the unbanked or poorer population, who may not generate significant income in payment fees to justify the peer deposit. Therefore, poor people may get excluded from the system, forcing them into centralized solutions. Also, channels with little funds allocated are no good for routing other payments, and channels asymmetrically funded will frequently become unbalanced and blocked.
The Lightning Network has other weak spots, like having only rudimentary privacy, although some of these problems may be technically solved in the future. Having presented the problems in scaling the LN, there are nevertheless promising paths for LN scalability. The most interesting growth path for the LN is expansion by being connected with other lightning networks whose channels are settled in Bitcoin sidechains. Sidechains can offer cheaper channel management costs, more channel operations per block, and faster channel operations. Therefore sidechains can contribute to the success of the Lightning Network much more than people imagine. For example, Liquid could host a lightning network that connects to Bitcoin’s. Therefore LN does not compete with sidechains, but actually they can benefit from each other. This leads us to our next section.
A sidechain is a blockchain that allows bitcoins to flow from and to the Bitcoin blockchain, without requiring a new token taking the function of money (i.e. being a collateral for DeFi). As we’ve shown in the previous sections, all scaling paths would benefit from higher block space (without compromising decentralization) and the solution to the two-way-peg problem, both are central problems sidechains aim to solve. Contrary to the LN, Bitcoin sidechains do not require pre-deposits to be able to receive payments, and they can offer a great user experience. The capabilities of sidechains are unlimited, and they are opt-in. If Bitcoin provided better support for sidechains, this could be what Bitcoin needs to reach mass adoption. Sidechains can provide enormous value to Bitcoin, value that is currently being channeled to altcoins. Sidechains can enhance Bitcoin privacy, scale payments, make them faster and cheaper. Sidechains can also provide higher self-custody security using vaults and covenants. Sidechain can fulfill the promise of creating a truly decentralized financial system with DEXes and AMMs, stablecoin lending and borrowing, all using Bitcoin as the main collateral. Better sidechains would allow permissionless innovation.
In the last 6 years, there has been unprecedented innovation in cryptography applied to blockchains, and only a small part builds on or applies to Bitcoin. The fruit of that research has been applied to other (more vulnerable) blockchains. Given Bitcoin’s importance for humanity as the basis for an immutable permissionless and uncensorable financial infrastructure, we should incentivize developers to channel that productive energy into Bitcoin.
But Bitcoin does not currently support a form of sidechain that is fully decentralized, open and permissionless. All existing sidechains require varying degrees of trust in third parties. They may be trust minimized, but not fully trustless. Launching a new sidechain involves creating yet another federation, which is costly and requires bootstrapping its security all over again. Nevertheless, there are promising technologies that could change the state of affairs: hashrate escrows and Blind Merge Mining (BMM).
The Origins of Sidechains
The first attempt to build a sidechain dates back to 2012, much earlier than people think. The first technical paper that fully describes a Bitcoin sidechain was published in 2014 by Blockstream’s researchers. To avoid confusion with the remaining sidechains, we call this original design spvchain. Soon after the spvchain paper was published, the project was abandoned. The reason is that Blockstream scientists discovered that any decentralized peg mechanism can be subject to censorship from Bitcoin miners, and therefore it is insecure or requires an honest majority assumption (this result was formalized many years later by Zamyatin et al).
In 2015 Rootstock whitepaper was published, and a team of developers began immediately working on it. Rootstock implemented a federated peg, but used merged mining for consensus. Meanwhile, Blockstream started working on their own fully federated sidechain, and published their design. In 2018 both sidechains were launched, first Rootstock and then the Liquid Network.
Since then, no other Bitcoin sidechain has been launched to production, although there have been some advancements in drivechains, and a drivechain BETA client has been released. Other sidechain designs were proposed since then, but none was implemented or launched.
Currently, 7 years after sidechains were envisioned, there are two true Bitcoin sidechains: Rootstock and Liquid Network. Rootstock consensus is based on merge-mining, making it open and permissionless. Bitcoin miners produce Rootstock blocks. On the contrary, Liquid block production is delegated to a predefined set of functionaries, which increases the risk of censorship of transactions by authorities. In relation to the peg mechanism, both of them rely on a form of federation, because Bitcoin is not powerful enough to enable a fully decentralized peg. However, both Rootstock and Liquid improve upon the classical federated model by using HSMs, which protects the bitcoins from theft and confiscation.
Sidechains in the Future
The Rootstock community’s desire is for Rootstock to become as decentralized as possible: even if the community has spent countless hours and resources in designing and securing the Powpeg (the current peg system), there is no “commercial” attachment to it. There is no yield on deposits that pegnatories may want to keep. The goal of the community is to move to a more decentralized peg, even if that means getting rid of the Powpeg. To improve Rootstock decentralization, the most promising model is the one that combines a hash rate escrow peg with blind merged mining consensus.
In the future, we will need more sidechains with different security and decentralization trade-offs. Free choice and competition is important.
Ossification of Bitcoin. Good or Bad?
The world needs Bitcoin to become a store of value, a payment network, and a DeFi innovation hub. However, as of today. Bitcoin can’t provide all these features, nor can any other blockchain. Reaching this ideal by applying successive changes to Bitcoin is impossible because Bitcoin is ossifying. After the blocksize wars, each new change proposed for the Bitcoin protocol has brought more and more controversy. Changes are less likely to occur every day that passes. Ossification is good as it protects Bitcoin from rogue changes. However, Bitcoin still needs improvements to enable better layer 2s before the protocol is set in stone. Achieving the escape velocity to enable more secure and decentralized L2s may require abandoning the stateless and non-Turing completeness of Bitcoin script by adding opcodes for covenants and the verification of SNARKs.
We live in a Cambrian explosion of crypto ideas. They grow, evolve and some of them die. The best ones will become interoperable protocols in what is now called the DeFi ecosystem. Companies, developers, and academics are attracted by the potential that can be unleashed by future innovations. Bitcoin should not ossify before establishing a path to capture this value.
In this article, we reviewed the different existing Bitcoin layers 2s, and we focused on sidechains as the key driver in the growth of Bitcoin DeFi. The sidechain journey started in 2012 and will hopefully evolve in more decentralized and secure Bitcoin sidechains enabling Bitcoin mass adoption. Bitcoin sidechains are already shaping the DeFi on Bitcoin ecosystem, and there is a widespread hope that they will bring even more value to Bitcoin in the upcoming years. Rootstock community is at the forefront of sidechain research and development. As a community we strive to help developers to build on Rootstock and encourage other sidechain projects to participate in and create a Bitcoin sidechain ecosystem. Join us!