BTC Layer 2 is a layer on top of the BTC network. Its main purpose is to solve the issue of insufficient transaction throughput and the difficult expansion of the BTC network. Currently, the Bitcoin network is still unable to process thousands of transactions per second (TPS) and requires higher throughput to meet current BTC network demand. “Layer 2” is the general term for proposed solutions to the blockchain scalability problem. In layman’s terms, Layer 1 refers to the Bitcoin public chain. In order to solve the issues surrounding the throughput of the BTC network and avoid high fees, the transaction can be moved to Layer 2 for processing, and then the result is returned to Layer 1 after the processing is completed, thus relieving the pressure on the BTC network. The result is an expansion of the liquidity and scalability of BTC.
Comparing the three Mainstream Layer 2 Solutions
Bitcoin and Ethereum are the two most popular public chains in the world. As such, they are vigorously developing Layer 2 solutions. At present, BTC Layer 2 has three main entities: Liquid Network, Lightning Network, and ChainX.
Liquid Network
Liquid is a sidechain of the Bitcoin main chain developed by Blockstream. It is a sidechain-based settlement network for traders and exchanges. Its development team, Blockstream, is a global leader in Bitcoin and Blockchain technology, responsible for the operation and maintenance of the BTC core code. In the Liquid Network, faster and more private Bitcoin transactions and digital asset insurance can be achieved, but Liquid features a single, multisig escrow that is too centralized, and fees are expensive.
Lightning Network
Lightning Network is also a product developed by Blockstream. As Bitcoin’s second-tier payment protocol, the Lightning Network solves the inefficiency problem under Bitcoin’s PoW mechanism in a sense. The project cleverly uses RSMC (Revocable Sequence Maturity Contract) and HLTC (Hashed Timelock Contract) to build an off-chain payment network. Lightning Network is based on the state channel to achieve on-chain, off-chain collaboration, to provide users with instant, low-cost Bitcoin micro-payment. But with it comes a problem of expensive transaction fees that makes it unsuitable for smaller transactions.
ChainX
ChainX is developed by the PolkaX team, which has been committed to the exploration of cutting-edge technologies in the field of blockchain and privacy encrypted communication. They are committed to the development and research of BTC Layer 2, building a digital-asset gateway to the Polkadot Ecology and becoming Polkadot’s secondary relay chain. ChainX supports EVM/WASM contract extension through the sidechain technology by using light node + multisig hosting. ChainX allows users to achieve convenient asset bridging, fast payments, and secure transactions. However, the current multi-signature model is too centralized, the settlement fee is too expensive and the EVM/WASM technology has only been deployed in testing, not on a live network.
The Taproot Upgrade will bring a Technical Revolution to BTC
The Bitcoin Improvement Proposal (BIP) is a design document that introduces new features and information for Bitcoin, while the Taproot upgrade is a compilation of three BIPs.
The Three BIPs are as follows:
- The Schnorr Signature (BIP 340)
- Taproot (BIP 341)
- Tapscript (BIP 342)
These upgrades collectively referred to as BIP Taproot, will bring Bitcoin a more efficient, flexible, and private way of transmission, with Schnorr signature and Merkel Abstract Syntax Tree (MAST) at its core.
Schnorr signature is a digital signature scheme known for its simplicity and security. Schnorr signatures offer several advantages in terms of computational efficiency, storage, and privacy.
A typical digital contract generally includes the original data of the message, the public key, and the signature of three parts. Users confirm the identity of the signer through the public key, confirm the contents of the contract through the data, so as to verify the validity of the digital contract. The Schnorr aggregate signature compresses multiple signature data into a single aggregate signature. The validator validates a single aggregated signature through a list of all signature-related data and public keys, and if verified, the effect is equivalent to independently verifying all relevant signatures and passing them all.
Most blockchains currently use the ECDSA signature algorithm. For block data, each node generates a separate digital signature with its own private key and broadcasts it to other nodes. The other nodes verify the signature and write it to the next block of data. In this way, when the number of consensus nodes is large, it will cause the signature data stored in each round of consensus block to continue to increase, taking up storage space. Whenever a new node joins the network and needs to synchronize the history block, a large amount of signature data will pose a great challenge to the network bandwidth.
With aggregate signature technology, each node collects aggregated signature shards broadcast by other nodes and then aggregates the signature shards to save them. Thus, when a new node is added, the synchronization history block only needs to download the aggregated signature data, greatly reducing the consumption of network bandwidth, while reducing the cost of transaction fees.
In addition, key aggregation makes all Taproot outputs look similar. Whether multi-signature output,single-signature output, or other complex smart contracts will look the same on the blockchain, so many blockchain analytics will not be available, thus preserving privacy for all Taproot users.
MAST (Merkle Abstract Syntax Tree) is the use of a Merck tree to encrypt complex locking scripts (as above), the leaves of which are a series of scripts that do not overlap each other (for example, multi-signature or time lock). To spend, simply disclose the relevant script and the path from that script to the Merck tree root. For example, to use script 1, you only need to disclose script 1, script 2, and hash 3.MAST’s main advantages include: first, support for complex spending conditions. The second is not to disclose scripts that have not been executed or spending conditions that have not been triggered, providing better privacy protection. The third is to compress the transaction size. As the number of scripts increases, the non-MAST transaction size increases linearly, while the MAST transaction size increases logarithmically.
However, there is a problem with the Taproot upgrade, that is, P2SH does not behave the same as the common Pay-to-public-Key-Hash (P2PKH), there is still a problem of privacy protection. Is it possible to make P2SH and P2PKH look the same on the chain? To this end, Taproot proposes a solution that, for a script with a limited number of signers, can be broken down into two parts: the first part is a multi-signature, and all signers agree on an expense outcome, called a “collaborative expense”; and the second part is called a “non-collaborative expense”, which can have a very complex script structure. These two parts are “or” relationships. For example, in the figure above, Script 3 is a 2-of-2 multi-signature, which requires both Alice and Bob to sign to be valid, which is “collaborative expenditure”; Script 1 and 2 are “non-collaborative expenditure”. “Collaborative expenditure” and “non-collaborative expenditure”, both capable of spending this output, where：
(1)For the “non-collaborative spending” script, take the above MAST approach and use MerkleRoot to represent the Merck tree root.
(2)For the “collaborative spending” script, adopt a multi-signature algorithm based on the Schnorr signature. Use Pa and Pb to represent the public keys of Alice and Bob, and Da and Db to represent the private keys of Alice and Bob, respectively. Therefore, the aggregate public key is P=Pa+Pb, the corresponding private key is Da+Db.
(3)The “collaborative expenditure” and “non-collaborative expenditure” together expressed in the form of P2PKH, the public key is: P=P+H(P| / MerkleRoot) G; the corresponding private key is Da+Db+H(P||MerkleRoot).
(4) When Alice and Bob agree to “collaborative spending”, they use Da+Db+H(P| / MerkleRoot) (just one of them adds H (P||MerkleRoot) to their private key). On the chain, this behaves like a P2PKH transaction, with a public key and a corresponding private key, without the need to disclose the underlying MAST.
New cross-chain solution designed by ChainX and Taproot
In the new version of the scenario, n fixed custodians are selected. When user A wants to cross-chain BTC to ChainX, the custodian and user first need to provide the public key and generate the corresponding Bitcoin/ChainX escrow address, then the user transfers BTC to the Bitcoin escrow address, and finally complete the issuance of XBTC to user A on ChainX. Accordingly, when user A makes a withdrawal operation, the custodian and the user first need to provide an aggregate signature in order to complete the transfer from the escrow address to User A on Bitcoin, and then when the transfer is complete, the BTC will be destroyed on ChainX.
Transfer out of the aggregated multisig address of the asset, you need to initiate a multisig transaction, the execution of multisig transaction needs to reach the specified threshold, generally set to 2/3 of the total proportion. In the form of aggregated signatures, users and trusts can jointly initiate a multi-signature transaction, where the user’s signature accounts for 1/3 of the total weight, and the signature weight of other trusts is close to 2/3. In this setting, the escrow BTC completes the transfer on the premise that the user signs the transaction, and the total weight of the other trusts is less than 2/3, and the multisig transaction cannot be completed even if all pass. Therefore, in the case where the user participates in the aggregation signature, the user himself has effective control over the custody assets, reducing the centralized management of the trust in the previous scheme.
The use of aggregated public key and aggregated signature scheme can effectively compress the number of bytes of the transaction script to significantly reduce the transaction fee, and there is no maximum number of custodians, with the increase of the number of custodians N, the degree of decentralization of ChainX will continue to increase.
BTC’s Layer2 and ETH’s Layer2, which is the bigger market?
Bitcoin, as the leading cryptocurrency, is already developing in the direction of “digital gold”. The next step will be to focus more on the security and decentralization of the BTC network. The development of BTC Layer 2 is to enhance the liquidity of Bitcoin, so that bitcoin can be used for micro-payments, daily consumption, and expand the influence of Bitcoin.
But BTC Layer 2 has been slow to develop, such as the Lightning Network, which is committed to Bitcoin micropayments. After several years of effort, the number of bitcoins locked is not even a fraction of the number of BTC anchored on ETH. The reason is the poor scalability of Bitcoin technology. But the Taproot upgrade, mainly the technical upgrade, fits perfectly to solve this pain point, the number of BTC Layer 2 applications will inevitably get exponential growth, at the same time, the development of BTC Layer 2 will further solidify BTC’s position as a global currency, making it more advantageous in the competition with the positioning of “digital gold”.
Looking back at the current stage of the ETH Layer 2, has occupied part of the market, so the BTC Layer 2 network will be in the catch-up stage in the early stage of development, but who can win the largest market of Layer 2, this is beyond doubt. BTC Layer 2 and ETH Layer 2 technically are not very different, but in terms of market capitalization, it is clear that Bitcoin is in an absolute lead.
About ChainX
ChainX, the earliest launched project in Polkadot’s ecosystem, is committed to the research and application of Bitcoin layer 2 expansion, digital asset gateway and Polkadot second-layer relay chain, to realize cross-chain asset exchange, leading the new direction of Bitcoin Cross-DeFi.
Website | Github | Wallet | Twitter | Medium | Telegram | White paper
