Sidechains are extensions to the main blockchain that brings in added functionality and features to the original protocol. The idea is to have a blockchain that runs in parallel to the main blockchain. It allows users to move tokens and other digital assets from the main blockchain to the side chain and vice-versa. RSK, the smart contract platform on top of Bitcoin, has been working on a new protocol called syncchains, which can be the next evolutionary step for sidechains. In this guide, we are going to look at how syncchains work and its benefits.
How do Sidechains work?
While we have covered this in detail before, we are going to give you a brief overview before we go ahead.
- The user of the parent chain needs to first send their funds to an output address.
- Once the coins are in that address, they get locked up. This means that the user is no longer able to use the coins anywhere else.
- To ensure interoperability between the sidechain and the main chain, communication is sent across the two and a waiting period is allowed after the user’s funds have been moved to the output address.
- Once the waiting period is over, a corresponding amount of coins are released on the side chain. Now, the user will be able to spend the coins on the sidechain.
- To move back to the main chain, the user needs to send the coins from the sidechain to an output address where they are locked.
- After a certain amount of time has passed, an equivalent amount of coins is transferred to the parent Blockchain, which the user can then unlock.
Main features of pegged sidechains
Let’s look at some key properties of the pegged sidechain:
- Assets that are moving between sidechains can only be transferred back to the main chain by the holder of the original asset.
- The sidechain must function independently from the main chain.
- Assets should be moved without counterparty risk.
- The transfer of assets should be atomic.
- Users don’t need to track the sidechains they aren’t using.
Underneath the hood – Federations and Security
Since these chains deal with a lot of money, it is essential to have a secure and trustless layer between the blockchain and sidechain. The issue here is that the Bitcoin script isn’t sophisticated enough to make this process entirely decentralized. By incorporating an m-of-n multisignature, we can create a Federation which doesn’t require trust between its members to operate. Blockstream’s Liquid has a federated peg which uses a consortium of exchanges.
Security and the SPV proof
Sidechains are independent of their main chain and are fully capable of taking care of their own security. Problems occurring on the sidechain won’t adversely affect the main chain and vice versa. However, a security problem on the main chain can lead to a decreased value of the peg. RSK maintains security with merged-mining, a technique that can be used to mine on both the main chain and the side chain. Merged mining establishes a relationship between RSK blocks and the Bitcoin blocks through a simple SPV proof. An RSK full node includes a compressed version of the SPV proof which consists of:
- The Bitcoin block header (80 bytes).
- A Merkle Branch to the Coinbase transaction (approximately 320 bytes).
- A mid-state of SHA-256 consuming the head of the coinbase transaction (32 bytes).
- A 64-byte aligned chunk that consists of a trail of the coinbase transaction and the RSK tag (max 169 bytes).
- An SPV merge-mining proof (max 780 bytes).
The Problems with Traditional Sidechains
As we have mentioned before, the RSK chain is independent of the main Bitcoin blockchain. Therefore to prevent any anomaly like a “double-spend,” the RSK chain assumes that Bitcoin will be resilient enough to stay strong under such attacks. However, sidechains are currently susceptible to the following attacks.
#1 Fake Peg-in Attack
- Imagine that merge-mining engagement is around 50%.
- There is a mining cabal that has 51% of the RSK hashrate and 25% of Bitcoin’s hashrate.
- The cabal could potentially leverage their superior hashrate to create a false header-only blockchain and feed it to the SPV bridge.
- The cabal can then trick the bridge into accepting fake and spammy transactions.
- Since the main chain works independently, the fake header chain won’t be disrupting its flow.
Keep in mind that this is a purely hypothetical scenario and it will never take place in a centralized-Federated implementation (like most of the sidechains are). However, all sidechains eventually plan to move on to a decentralized Federation structure. In that case, RSK believes this attack could be a possibility.
#2 Peg-in and Peg-out Double Spend
In peg-in double-spend, the attacker:
- Tricks the bridge contract into adopting an alternate chain.
- Isolates Federation members and convinces them that the malicious chain is the longest and best chain.
- If successful, the attacker can double-spend their initially invested amount.
In a peg-out double spend:
- The mining cabal performs a peg-out and reverts the RSK chain to the point where the transaction that defines the peg-out is located.
- This attack is also high-cost, but the amount of Bitcoins that can be stolen is pretty high.
- “Free” merge-mining attacks are still a possibility, even though the probability of it is really low.
- An SPV bridge requires 100 Bitcoin block confirmations (or equivalent RSK blocks wrt cumulative difficulty) for peg-ins and peg-outs. This makes the system relatively slow.
Syncchains – The Evolution of Sidechains
The innovation team behind IOVlabs has created a new merge-mined sidechain called “SyncChain.” It allows for faster peg-ins and peg-outs while protecting it from double-spends. A SyncChain requires that each sidechain client runs both an instance of the mainchain node and the sidechain-specific node. The three main features of syncchains are as follows:
- Delayed dual-parenting.
- Peg transaction linking.
- Coinbase anchoring.
#1 Delayed dual-parenting
Dual parenting is one of the core concepts behind syncchains. The idea is that each sidechain block must have a sidechain parent and a mainchain parent. RSK uses a variation of dual-parenting called delayed dual-parenting (DDP). The mainchain parent is also known as a “checkpoint.” With DDP, the checkpoint is set to lag by a number of blocks (let’s say K) based both on timestamps and mainchain block confirmation count.
In the diagram above, the value of the lag or K is 3. Since three blocks delay the checkpoint, which amounts to around 3*10 = 30 mins. So, why is there a delay here in the first place? Consider this:
- Let’s assume that the block time for the RSK chain is 30 seconds.
- Each Bitcoin block is mined in 10 mins. So, between two blocks is the main chain, 20 RSK blocks are mined in the side chain.
- What this means is, that if a single Bitcoin block gets overturned, it adversely affects 20 RSK blocks. This is why the delay helps in maintaining synchronization.
As you can see in the diagram above, overturning one block didn’t have any effect on the RSK chain.
To create this delayed effect, syncchains require a special kind of consensus algorithm called “Checkpoint Selection Algorithm” or CSA. A CSA selects the mainchain checkpoint and sees if it’s appropriately validated, or not. A CSA bases its decisions on the block timestamps.
The SyncChain white paper presents two RTA algorithms:
- MedianTime11: MedianTime11, requires the existence of 5 bitcoin blocks following the block to checkpoint. The algorithm establishes the reference time of a Bitcoin block B to be the median of 11 blocks centered on B.
- AdjustedTime: This algorithm sets the reference time of a Bitcoin block B to be the more recent of the block timestamp and previous block reference time.
#2 Peg transaction linking
All the peg-in and peg-out transactions are linked together for the following reasons:
- Avoid attacks where the attacker reorganizes the Bitcoin and RSK blockchains to double-spend funds from the point where the attacker himself has pegged-in or out.
- Secures peg-outs and makes peg-out double-spends infeasible.
The following diagram depicts a peg-in and a peg-out for a classic federated sidechain.
There are two things that you need to keep in mind about the diagram above:
- A federated multi-sig protects the peg funds, and the parties that have the private keys of this multisig are called functionaries.
- The red line in the diagram contains all the transactions signed by functionaries. Since each of the transactions consumes one dummy input and creates one dummy output, there is only one unspent transaction output or UTXO at all times. This UTXO is known as link token or “loken” and the red line is known as the loken chain.
The diagram above shows the peg-in process.
- The bridge smart contract automatically allows functionaries to forward the coins received in the peg-in transactions to a different UTXO. The bridge smart contract will be in control of the peg-in and peg-out transactions.
- The transaction that moves you from the Bitcoin blockchain into the sidechain is known as the link-in transaction. The link-in consumes a loken and creates a new loken
In the diagram, a user initiates a transaction in the main chain at block 1, to move into the side chain. This movement triggers several actions across the bridge where sidechain block A checkpoints the block 1.
- A waiting period of three sidechain blocks is initiated.
- The bridge orders the federation functionaries in block B to sign and broadcast the link-in transaction.
- Post-broadcast, the protocol immediately consumes the peg-in funds and moves them to the final multi-sig peg address.
- The sidechain coins are now released in block A.
- The user can’t peg-out of the sidechain until the link-in transaction is included in the mainchain.
In standard proof-of-work sidechains, the full atomicity of peg-in and peg-outs can’t be achieved without the collaboration of the miners. Theoretically speaking, if the attacker quickly moves in and out of the main and side chain, they can succeed in keeping both the mainchain and sidechain tokens.
To guarantee the infeasibility of peg-out double-spends, it’s necessary to add to the Nakamoto Consensus in the sidechain. As per IOVLabs’ research, three different protocols achieve that along with M.A.D. (Mutually Assured Destruction) and unconditional guarantees.
- Peg-out for a More-Populous-Chain-Wins (MPCW) SyncChain
- Peg-out for T-Synchronized (TS) SyncChain
- Peg-out for a GHOST-CSC (not T-synchronized) SyncChain
#3 Coinbase Anchoring
As per IOVLabs, an easy way to anchor transactions to a specific block by adding a new opcode to the Bitcoin protocol – OP_CHECK_INPUT_BLOCK_HASH. This code receives a block hash as an argument and invalidates the block if it doesn’t match up with the hash. However, since this opcode restricts moving transactions, it would make bitcoins less fungible, which it won’t be acceptable by the Bitcoin community. An alternative option with a lesser effect on fungibility would be OP_CHECK_INPUT_BLOCK_TIME. The opcode invalidates the transaction if the block corresponding to the spent input has a timestamp higher than the opcode argument.
However, one can achieve the same result without any new opcode, by consuming in the peg-out transactions as an output from a coinbase transaction that exists in a block B between the link-out and the peg-out transactions blocks. This can be seen in the image below.
This peg-out transaction would be invalid if B is reverted, and the only way to remove the link-out would be to revert to B.
However, there is one big disadvantage of coinbase anchoring. These coinbase transaction outputs have a 100-block maturity period, which introduces a 100-block delay for the peg-out. To bind the peg-out to a coinbase, RSK can request that RSK merge-miners to include an extra output paying an amount 1 satoshi to a specific federation address and that satoshi is consumed in the peg-out transaction.
While using the AdjustedTime algorithm, for low-value payments, the whole peg-out process takes only 12 minutes. In contrast, high-value payments would require coinbase anchoring, and therefore would take on average 16 hours (100 bitcoin blocks).
Syncchain represents the next evolution of sidechains and enables:
- A 32x reduction in the time of peg-in from 16 hours to 30 minutes.
- Reduces peg-out time from 16 hours to about 1.6 hours. This can only happen if the protocol has a rate limiter of no more than 38 BTCs transferred per hour.
- Presents a variant that uses coinbase anchoring to provide unconditional peg-out security, with a peg-out time of 16 hours.
- A lower number of confirmations for the same level of engagement.
- Reduces the amount of code RSK runs in consensus in rskj. Bitcoin presently provides some of the code functionality.
- Allows cross-address peg-ins, such as investing in a crowd-fund directly from Bitcoin
However, syncchains have one downside – they don’t really provide short-term settlement finality. But the pros definitely outweigh the cons, which makes syncchains the best possible option for being the next evolutionary step for sidechains.