The Cutting Edge of Sidechains: Liquid and RSK

On this post,  we analyze with RSK´s Chief Scientist, Sergio Lerner, the cutting edge of sidechains with Liquid and RSK.

By Sergio Lerner 

In 2016 Blockstream proposed Pegged Sidechains as possible path to scale Bitcoin. The first original Sidechain concept was a combination of atomic swaps using cross-chain SPV proofs (as in p2ptradex) and alt-chains.  A “sidechain” is not a formal term, but it frequently refers to a trust-minimized blockchain enabling payments in a foreign crypto-asset (an asset which is native to another blockchain). Bitcoin sidechains enable improving Bitcoin with minimal interference with Bitcoin’s incentive system. The most interesting benefits that can be achieved by sidechains are user asset-issuance, stateful smart-contracts enabling DeFi solutions, commit-chain scaling, faster settlement finality and higher privacy. Two sidechain projects stand out from the rest: Liquid and RSK.  Both are Bitcoin sidechains that have been very active since their launch.

Federated Pegged Sidechains

A federated pegged sidechain issues native tokens that are collateralized by mainchain tokens locked in a multi-signature address. The private keys of this multisig are created and managed by a set of functionaries. The mechanism used to lock and unlock the mainchain and sidechain tokens is generally called the Two-way Peg. There are many kinds of federated sidechains, and it’s important to understand the subtle differences between them.

First, I’ll briefly present the Liquid and RSK sidechains, as explained by Blockstream and RSK Labs respectively.

Liquid

Liquid is an inter-exchange settlement network linking together cryptocurrency exchanges and institutions around the world, enabling faster Bitcoin transactions and the issuance of digital assets. The Liquid Network is a blockchain for exchanges, brokers, and market makers that enables fast, private Bitcoin transactions with other members of the network. Through Liquid’s Issued Assets feature, members can tokenize fiat currencies, securities, or even other cryptocurrencies. Liquid peg and consensus is managed by a Federation of functionaries. The native token in the Liquid sidechain is LBTC.

Block Explorer: https://blockstream.info/liquid/

Network Statistics: https://liquid.horse/

Documentation: https://blockstream.com/whitepapers/

 

RSK

RSK is a stateful smart-contract platform secured by the Bitcoin miners, and is currently the most secure proof-of-work based smart contract network. It enables decentralized applications that can empower people and improve their freedom and quality of life. As a sidechain, it adds value to the Bitcoin ecosystem by expanding the use of the bitcoin currency. Decentralized Applications can be written using the Solidity compiler and the Web3 standard library, achieving Ethereum compatibility. Also, it enables scaling Bitcoin payments with more on-chain space and off-chain transactions provided by the RIF Lumino payment channel network. The RSK Two-way Peg is secured by the RSK Federation and block consensus is secured by merge-mining. The native token in the RSK sidechain is RBTC.

Block Explorer: https://explorer.rsk.co/

Network Statistics: https://stats.rsk.co/

Testnet Faucet: https://faucet.testnet.rsk.co/

Documentation: https://github.com/rsksmart/rskj/wiki

 

Comparison Chart

Both projects are leaders in the sidechain space. However, there are key differences. In the following diagram, we compare RSK and Liquid. RSK, the sidechain I’ve been collaborating with since 2015, which was launched on January 2018. Liquid is a sidechain created by Blockstream, and became active in September 2018. Since many details about the inner workings of Liquid’s HSM are still unpublished, I will try to provide the most accurate comparison based on what is currently known.

Feature	Liquid	RSK
Creator	Blockstream	RSK Labs
Source Code License	MIT, Defensive Patent License	LGPL
Block Generation
Consensus Protocol	BFT variant	Bitcoin Merge-mining
Settlement finality	2 blocks, irreversible settlement	Probabilistic settlement
Consensus group	closed	open
Block producers	15 multisig members  + 14 additional producers, round-robin	Bitcoin merge-miners (currently 41.3%)
Federated Two-Way Peg
Type	Federated 11 of 15 multisig, with a time-locked 2 of 3 multisig for an emergency recovery process.	Federated 8 of 15 multisig.
Hardware Security	Custom HSM (software and hardware)	Custom firmware for off-the-shelf HSM
Federation Openness	Federation	Addition/Removal of members by supermajority voting on-chain
Federation Members Change Transparency	Undisclosed	Published in the sidechain
Transparent Peg/Confidential	Confidential (between Crypto Exchange and user)	Transparent
All-or-Nothing censorship resistance	No. Could be achieved by a future planned atomic swap system.	Yes
Cold Storage	Yes, but requires periodic refresh of cold coins	No. Split hot/cold wallet possible in future releases.
Functionary-to-functionary communication	Over Tor	None. Communication flows from a smart-contract to each functionary, over the public sidechain
Main Platform Features
Issued Assets	Native	User-level contracts such as ERC-20
Light-client-friendly Issued Assets	Yes, but requires special server nodes	Yes
Confidentiality	Native by Confidential Transactions	User-level contracts such as Zether, Mobius and AZTEC. RSKIP in the roadmap describing account abstraction to reduce source account leakage.
Smart-Contracts	Stateless	Stateful
Average Fee per Simple Tx (1 input / 1 output)	10 cents (*)	0.66 cents (**)
Average Block interval	1 minute	30 seconds(*3)
Simple Transactions/Second based on current block limits	40	10

We’ll describe in more detail the main differences.

Federated Peg

Both Liquid and RSK rely on a federated multi-signature to lock the bitcoins that are released in the sidechain in the form of sidechain native currency, but the design of their pegs differs greatly. Each sidechain design presents its own tradeoffs.

Both sidechains currently have 15 active functionaries; Liquid requires 11 signatures to release BTC, while RSK requires 8. It seems that Liquid prioritizes security over availability, while RSK prioritizes availability over security. However, Liquid implements an emergency release procedure using a time-locked 2 out of 3 multi-signature, that improves availability over security, which is the opposite tradeoff. Liquid’s emergency system introduces a new attack vector, in which the majority of Bitcoin miners can censor a BTC release transaction in order to force the activation of the emergency multi-signature. Each variant has its pros and cons, and it will be as easy for RSK to adopt an emergency system as for Liquid to remove it. I believe, in such a critical security system, simplicity wins.

Both sidechains make use of Hardware Security Modules (HSMs) to store the private keys. Neither Blockstream nor RSK Labs has disclosed much information about how these devices were designed or what code they run. RSK federation functionaries are allowed to audit both the HSMs’ firmware and hardware, and this is also true for Liquid.

Liquid has built its own hardware platform and firmware, which can be an advantage for security. However, I don’t know if Blockstream’s device rests on a Secure Element to protect the private keys or not. Secure Elements are specially designed to protect secrets from side-channel and fault-injection attacks, where standard microcontrollers generally fail. RSK Labs deployed off-the-shelf devices having Secure Elements with custom firmware, developed by RSK Labs.

Peg-ins

The protocol to lock BTC and unlock sidechain tokens is different for Liquid and RSK. In Liquid, the user first builds a new temporary federation address by deriving it from the known federation address using a random nonce of choice, then the BTC are sent to this new temporary address. After a high number of confirmations, the user or a federation functionary sends a Liquid transaction notifying the remaining members of the federation about the nonce. Afterward, LBTCs are issued in the same amount of the BTC previously locked in the temporary address.

 

Transferring BTC to LBTC (Liquid)

The process to transfer BTC to RSK is as follows. First, the sender must make sure the bitcoins to transfer are held in a P2PKH address. If not, then they must be transferred to a P2PKH address in a transaction Tx1. Then they are transferred from the P2PKH address to the Federation multisig address in a transaction Tx2. After a high number of confirmations, the federation issues a notification transaction in RSK containing a SPV proof for Tx2, and the blockchain immediately unlocks the equivalent number of RBTC to an address that is controlled by the same private key as the first input of Tx2. This is done by converting the Bitcoin public key into an RSK address. If the Federation doesn’t issue the notification transaction, any user can issue it by including the SPV proof: the process is the same, and therefore the peg-in process is fully trust-less.

Transferring BTC to RBTC (RSK)

Users can convert BTC to RBTC without registering with a crypto-exchange. In Liquid, any user could also peg-in but the recommended process is to register with one of the Federation participant exchanges and pass KYC verification procedures. This is because the Liquid Federation could ignore a user peg-in transaction.

At the time of writing, RSK Labs still holds a private key that can be used to limit the amount of bitcoins locked in the peg. RSK Labs has stated that this is a temporary security measure and that they will relinquish this power once merge-mining engagement goes over 51% of Bitcoin hashrate. The source code indicates that RSK Labs can lift this limitation by sending a special message to the smart-contract that controls the peg.

From Peg-Ins to Peg-Outs

A two-way-peg is transparent if any user can detect and inspect the peg-in and peg-out transactions, and therefore any user can audit the federation’s multisigs holdings. If the peg is transparent, any user can check that the sidechain’s circulating supply matches the funds locked in the multisigs. Also, it means that users can detect if the federation is misbehaving and blocking transfers, in or out of the peg.

RSK has a transparent peg, all peg-in and peg-out transactions can be identified and authenticated by the users: the full list of UTXOs belonging to the peg can be read from a smart-contract running on the platform. Also, the addresses of current and past federations are accessible from this contract. Peg-out transactions are identified because they consume peg UTXOs.  

RSK Peg-in and Peg-out Transaction are fully auditable

Liquid uses a combination of hot and cold wallets that increases security while trying to reduce the waiting time for peg-out transactions, but this benefit comes at a cost. On the Bitcoin side, Peg-in transactions are paid to multisig hot wallets that are controlled by the HSMs. The resulting UTXOS are periodically recycled to prevent the emergency recovery script to be enabled.

Liquid designers realized the highest system security risk was the peg-out process and decided that the bitcoins to be released by peg-out transaction should be sent to an exchange cold wallet, instead of going directly to user wallets. As in Liquid some of the functionaries are cryptocurrency exchanges, the bitcoins are moved to one of the exchanges cold wallets, the same exchange where the user must be registered. This gives the exchange a last chance to censor a transaction. The exchange pays back with its own hot wallets funds to the user, after receiving the funds into its cold wallet. Because these two payments are not atomic, there is always a risk that a) the exchange does not pay back to the user, if the HSMs pays the exchange first or b) the system malfunctions and does not reimburse the exchange, if the exchange pays the user first. In any case, the requirement to use an exchange as intermediary makes KYC a key and ineludible part of the system, and it may imply that the functionary is a temporary custodian of user’s funds in transit, a money transmitter, or both. Finally, it substantially obscures the transaction that pays BTC to the user, improving user confidentiality but as a tradeoff preventing decentralized peg transparency and censorship detection by the community (the peg-out transaction are counted on the private website liquid.horse). The time-locked emergency recovery script in Liquid UTXOs means also that the cold funds must be periodically refreshed to postpone the time-lock, which reduces the effectiveness of cold storage.

Even if transparent cold wallets can be implemented fairly easily for the RSK peg, at this point we think that the duties of the functionaries should be kept to a minimum. Any human action that a functionary needs to perform as part of a regular procedure, adds a point of censorship and pressure from governments and corporations. Higher security can be achieved by adding more functionaries having a more diverse set of hardware and software components.

Liquid receives btc in in multisig hot wallets (peg-in) but pays from one of the functionaries hot wallets for peg-outs, and receives reimbursements from multisig to cold wallets

 

Peg Censorship

A two-way peg provides all-or-nothing censorship resistance if federation members cannot selectively block any peg-in or peg-out transaction without significant side effects, such as blocking a large subset of subsequent peg-in or peg-out transactions. This property is vital as surreptitious censorship may be used by authoritarian governments to limit human rights. If censorship can be applied without public notice, regulators and governments may exercise pressure and force participating companies to block transfers at their own will and discretion.

In almost all blockchains, Liquid included, peg censorship can be overcomed with atomic swaps. However, efficiently finding an atomic swap counterparty requires a new active and decentralized network of trading peers and an emerging market with sufficient liquidity. Creating such a system involves solving many of the same challenges as building a decentralized blockchain, plus the added difficulty of preventing Sybil attacks without proof-of-work. Therefore, we highlight the importance of all-or-nothing censorship resistance tied to the sidechain’s consensus.

RSK peg provides Bitcoin-like censorship resistance for peg-ins, and all-or-nothing censorship-resistance for peg-outs. Peg-ins cannot be censored because users can submit their own Bitcoin inclusion proofs to the sidechain to command the sidechain to release RBTC. Peg-out transactions consume UTXOs that are chosen by a smart-contract. Some of the bitcoins consumed are paid to the user and the remaining return to the original same multi-signature address of the federation. These returned bitcoins are reused in subsequent peg-out transactions, creating an unbreakable chain. This means that to block a first release transaction, the federation functionaries must also block subsequent releases that depend on outputs created in the first transaction. The collusion of 51% of functionaries to spend any UTXO is still possible. However, this can be immediately detected by users. In a future network upgrade, RSK may implement full back-to-back linking of peg-outs to maximize censorship resistance. Also, it can require proof of inclusion of peg-out transactions in Bitcoin to prevent 51% of federators from disobeying the smart contract, yet attempting to fulfill the peg-out orders.

In RSK, if a peg-out transaction is censored then many following transactions get automatically blocked due to the I/O linking

In Liquid, functionaries could collude to censor a specific peg-out transaction, and it won’t be noted by individual users of Liquid, as the input UTXOs of the peg-out transaction are chosen by a designated functionary that provides KYC for the receiving party. However, since Liquid implements very strong privacy guarantees, it would be difficult for Exchanges to censor each other, as an exchange can hide their own source LBTC addresses and use new BTC addresses for peg-out. Because Liquid is tailored for Exchanges, and not individual users, Liquid does not provide additional censorship resistance. Individual users are exposed to the same level of censorship as normal Exchange accounts.

In Liquid a peg-out transaction could be censored and the system would continue working as normal

 

Federation Membership Management

The management of the members of the Federation is a crucial difference between RSK and Liquid. In Liquid, adding or removing members seems to require stopping the network and manually configuring the particular nodes run by functionaries to reference the onion addresses and/or public keys of the remaining nodes. This is an assumption, as the procedures have not been published.

RSK can orchestrate an open protocol to add or remove members under public scrutiny, and all messages are exchanged over sidechain transactions. The whole process executes without interrupting regular transaction processing, not even the processing of peg-in and peg-out transactions. The protocol is time-delayed to enable external audits, and it ends with a new federation replacing the previous one and the funds automatically being moved from the previous UTXOs to new UTXOs.

The RSK funds transfer from the old Federation’s multisig to the new Federation’s multisig, is an interesting multi-stage process. When a new Federation is established, a new multisig address is returned when a full node is queried by the node through a JSON-RPC endpoint.  However, the old multisig address is kept active for a while, to give enough time for still unconfirmed transactions to get included in blocks. Afterward, a smart contract commands the sweep of the remaining funds into the new multisig, and the previous multisig is deprecated.

RSK Membership Management, an Auditable Procedure

Privacy

One of the strongest properties of Liquid is its native support for Confidential Transactions (CT) both for LBTC and for issued-assets. Liquid can hide the transacted amount, but not the sender and the receiver addresses. These addresses must be handled with care to prevent accidental linking, as in Bitcoin. Clients wallets must be adequately protected to avoid leakage of private information through side-channels, such as traffic analysis. Confidential transactions are much bigger than regular transactions, so it is expected that confidential transaction fees be higher if Liquid blocks become full.

RSK can provide almost any scheme for private transactions in the form of user-level contracts developed by third parties. Some existing examples are Zether, Mobius, and AZTEC.  It’s even possible to achieve the broadest possible anonymity set by using zCash-like protocols on top of RSK.

Currently, these user-level solutions hide transacted amounts and destination addresses, but source addresses still can be linked. Protecting source addresses requires either a market of meta-transactions (paying third parties to broadcast your transactions) or modifications to the RSK consensus. RSK is planning to deploy an account abstraction improvement, which will enable any contract to receive messages directly from an external transaction without source address, achieving complete sender anonymity, if the sender is using Tor.

The field of cryptography is advancing at a pace never seen before, with a particular interest in non-interactive arguments of knowledge, which is the building block of many coin anonymization schemes. Every year we see new, faster and better schemes, such as Bulletproofs, Sonic and Lelantus being developed. Also, there are new developments in systems that combine privacy with smart contract execution, such as Zexe and ZkVM. I think the continuous improvements in this privacy schemes is a good reason to keep the platform agnostic to a specific cryptographic system.

Consensus Protocol

Liquid’s consensus is based on a PBFT variant executed by a selected group of functionaries. The functionaries take turns following a round-robin scheduling to produce new blocks, and after two confirmation blocks transactions are considered settled. The functionaries are interconnected via the Tor overlay network, hiding their real geographical location and IPs. This is an interesting feature which is mandatory in Liquid, but it’s only optional in RSK.

RSK uses SHA-256D Merge-Mining and provides probabilistic transaction settlement, the same as Bitcoin. Currently, between 30% and 50% of Bitcoin miners are engaged in RSK merge-mining.

In both Liquid and RSK, block producers earn fees from transactions included in blocks. In Liquid, miners could collude to ignore other miners’ blocks and become block producers more often than they should, to obtain a higher share of transaction fees, as a side-effect of the round-robin scheduling. But this would be detected by the skipped functionaries, and therefore it would be difficult to perform this attack multiple times surreptitiously. RSK uses a shared mining account with fee-smoothing and the DECOR+ reward sharing protocol to incentivize cooperation over competition between miners.

Merge-mining sidechains as a way to add value and functionality to Bitcoin has to be weighed against other alternatives, such as extension blocks, and hard-forks to increase the block-size, which are highly controversial and miners have been tempted to adopt in the past. As Paul Sztorc puts it “the created powers [ of drivechains ] disable older, more dangerous powers”. The same is true for sidechains. Finally, merge-mining provides the advantage that block production is open to new participants, so not only the federation functionaries can earn transaction fees.

Issued Assets

Both Liquid and RSK provide a way to create user-issued assets. Assets in RSK can be issued using the ERC-20 token standard commonly used in Ethereum. Liquid provides a native implementation of user-issued assets.

In both platforms, issued assets can be freely transferred between users. However, issued-assets in Liquid are not light-client compatible, as Liquid does not include a commitment on the current UTXO set or asset issuance set in each block header. In both sidechains, any participant can issue assets, re-issue them, and transfer them to other users. However, RSK provides much greater control of the operations allowed by the assets because the asset creator also defines operations in a high-level programming language. Using higher-level programs, RSK can support paying dividends on security tokens, interests, demurrage, and most DeFi ideas.

Both sidechains can support second-level payment networks such as RIF Lumino Payments (in the case of RSK) and the Lightning Network ported to Liquid. While Lumino is natively multi-asset, I don’t think the Lightning network supports multi-asset nodes, multi-asset links, and multi-asset routing in its current version.

Transaction Cost

RSK is currently 10 times cheaper than Liquid (0.0066 USD vs 0.10 USD per simple payment). This is in part explained by the fact that simple RSK transactions are 5 times smaller than Liquid counterparts. However, cheap transactions can be a double-edged sword, as they may increase the blockchain’s size beyond acceptable limits for regular users and centralize the peer-to-peer network.

Liquid functionaries have to pay a monthly fee to Blockstream to become part of the Liquid Federation. RSK federation members do not pay fees, but being a member requires following security standards, and maintaining a predefined uptime.

The Future

RSK foundational white paper establishes a roadmap and a community agreement regarding immutability and censorship resistance for RSK. Improvement proposals are publicly debated and merged into the reference implementation by core developers. Some of the upcoming features include switching to the Unitrie storage model and adopting a storage rent system. RSK repository shows continues improvements since 2016 and several network upgrades that required hard forks.

Blockstream roadmap is not published. However Liquid’s github repository, which seems to be the Elements Project, shows continuous improvements since 2016, but no hard-forking change.

One key characteristic of RSK’s foundation paper is that it states the intention to migrate to a more decentralized two-way peg system, such as a Drivechain, whenever Bitcoin is ready to adopt a community-backed soft fork. RSK Labs has created a Drivechain BIP and reference implementation that Bitcoin core developers may use in the future.

Summary

RSK is a sidechain that aims to be the cornerstone for financial inclusion and focuses on Decentralized Finance (DeFi). Liquid is a sidechain platform designed for providing shared liquidity for exchanges. It focuses on protocol simplicity, security, and privacy. Therefore RSK  intent is to solve a much broader set of use cases while Liquid focuses on being extremely efficient in one.

By adopting a stateful VM, RSK provides more openness and programmability, while Liquid prioritizes succinct verification over arbitrary code execution.

RSK compatibility with Ethereum enables easy porting Ethereum dApps and tools to RSK, accessing a large pool of open source resources. Liquid requires developers to use Blockstream’s own libraries to make use of its privacy features, and there are no currently community alternatives.

Both sidechains are maintained by experienced development teams. Liquid is backed by the Blockstream company, while RSK is backed by the IOV Labs for-purpose organization.

Both sidechains have prominent exchanges participating in their respective federations and their sidechain tokens (RBTC and LBTC) are currently traded on renowned exchanges.

We are witnessing the creation of a new future for Bitcoin, one that is not limited by Bitcoin onchain capacity but being expanded by the Lightning Network, Liquid, and RSK.

Thanks to Dr. Adam Back for reviewing this article and providing useful feedback.

(*) Source: Average fee extracted from https://blockstream.info/liquid/

(**) Source: http://rskgasstation.info/

(*3) The average block interval can decrease to 15 seconds if the number of uncle blocks decreases to zero.