Since the launch of Bitcoin by Satoshi Nakamoto in 2009 [1], there has been numerous articles and developments of second layers on top of Bitcoin. Some of them are working live, others still need a BIP (Bitcoin Improvement Proposal) approved. Here presented is an overview of the different solutions with pro's, cons and status for each.
In 2014 Back et al proposed sidechains with an independent peg mechanism to allow transfers from the Bitcoin main chain to sidechains [2]. This design is one of a 2-way peg, meaning that the Bitcoin on the sidechain can also be trustless transferred back to the mainchain. Since then one-way pegs (meaning the Bitcoin on the main chain would get burned) have proposed as well. We will not go deeper into one-way pegs here.
The big problem to solve is how to ensure that the users on the Bitcoin main chain can verify that whichever Bitcoin comes back from the sidechain can be trusted. To further explain this: If we consider Alice to be a user on the Bitcoin mainchain and Bob has Bitcoin on a sidechain and wants to bring this back to Bitcoin main chain. How can Alice verify that Bob tells the truth?
At this moment, 3 different technical solutions can be identified. They are very similar in nature to the different rollups and 2nd layers seen on the Ethereum chain namely federations or multisig solutions, protocol security and
Trust by Federation. Also often referred to a multi-sig solution. Here you trust a certain third party to be honest (An organization or a group of people). The organization can only be compromised if multiple parties or people collude. The organization typically has a multitude of safeguards in place to avoid single people having control. Examples of this on Bitcoin are Liquid, wBTC etc... Example on Ethereum includes Polygon/Matic.
Trust by algorithm. This solution entails a certain cryptographic protocol (ZK, Optimistic, ... ?) to prove that the Bob can be trusted and according to the sidechain, he does own the Bitcoin. However, for this setup the mainchain needs to have the capability to validate the ZK proof or validity proof in case of an optimistic rollup. Both are currently not possible on the Bitcoin mainchain and need additional opcodes, which have been proposed in different BIPs. [4,5,6] At the time of writing there is currently no widespread approval within the Bitcoin community to implement any of these.
Trust the miners. Also known as the SPV peg. A third solution entails putting more trust in the hands of the miners. Controversial because of the blocksize war history in '15/16 [7]. As the miners will play a role in only verifying the sidechain, this might give too much power and impact the node vs miner balance. It is unclear how this incentive divide might play out. Examples include Drivechain [8].
Trust state channels. AKA Lightning Network [9]. A payment network that consists of two-party state channels. The state of the channels constantly changes until it is closed and the final balance is finalized on the Bitcoin main chain.
Sources
[1] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, 2009, https://www. bitcoin.org/bitcoin.pdf.
[2] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille, Enabling blockchain innovations with pegged sidechains, 2014, https://www.blockstream.com/
sidechains.pdf.
[3] https://medium.com/dataseries/3-active-solutions-for-the-bitcoin-second-layer-bc71ea08f564
[4] https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html#performance-analysis
[5] https://bitcoinrollups.org/
[6] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev, Scalable, transparent, and post-quantum secure computational integrity, Cryptology ePrint Archive, Report 2018/046, 2018, http://eprint.iacr.org/2018/046.
[7] Jonathan Bier. The Blocksize War. 2021
[8] P. Sztorc and CryptAxe, Drivechain documentation – hashrate escrows bip, 2017, https://github.com/drivechain-project/docs/blob/master/ bip1-hashrate-escrow.md
[9] J Poon, T Dryja. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 2016. https://lightning.network/lightning-network-paper.pdf
