Federated sidechains utilize key management to provide security and allow functionality beyond the Bitcoin mainchain.
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
Federated sidechains are currently the only deployed type of Bitcoin sidechain (the most recent paper here). The idea of using a federated peg and consensus system was actually an appendix in the original sidechains whitepaper. There was no concrete design for any type of two-way peg involving miners, so a federated peg was described as a way to deploy a sidechain now, and upgrade to a two-way verified peg using simple payment verification (SPV) proofs similar to what softchains do, when something was concretely designed that was safe and deployable. It was also pointed out that in terms of incentives, for very small systems it might be dangerous to use a miner-based peg as they could steal from a very small group of people without much consensus on doing anything about it from the wider Bitcoin system. Federations could be useful for smaller systems where the group of users isn’t big enough to be a disincentive for miners to steal coins.
The general idea is to effectively have a blockchain where a selected group of trusted parties custody bitcoin pegged into the system using multisig, and produce the blocks on the sidechain, signing them with cryptographic keys instead of using proof-of-work. The entire security model is based on having a decently large set of distinct participants in the group, or federation, that are very geographically distributed and are publicly known.
Federations use a threshold of members for both the custody of bitcoin on the mainchain and blocksigning, i.e., a 5-of-7 multisig. This is done instead of requiring all seven of the members to sign in order to balance the two major risks of such a system: theft versus loss. The federation together can steal all of the funds locked in a federated sidechain if they choose to cooperate together to do so; this is why the entire security model is based around many different actors in many different legal jurisdictions. You want it to be exceedingly difficult and unlikely that many different governments all cooperate in order to force a federation to do something malicious, so you want a large number of people needed to sign things. On the other hand, if you require all seven members to sign everything, then all it takes is a single member to lose access to their keys to result in permanent loss of all funds in the sidechain. Hence requiring a majority of members to sign, but not all of them. This leaves some margin of error for key loss while also still requiring a high number of members to be coerced or to conspire to result in a theft of funds.
This makes the security model of the system two-directional in terms of security thresholds. As previously stated, in order for the funds to be actively stolen, five out of the seven participants in this hypothetical situation must collude or be coerced into colluding in order to steal the sidechain funds. However, only three of the seven participants must lose, destroy or be coerced into disabling their keys in order to leave the sidechain funds frozen and unable to be moved — possibly permanently. The thresholds are a balancing act between these two risks.
Both of them simultaneously need to be high enough in order to make both worst cases unlikely to occur.
Aside from these core properties there is a large degree of freedom in how you could implement a federated sidechain, both in terms of how to design the sidechain itself as well as how to handle key management for the block signing and peg custody keys.
Liquid
Liquid was the first federated sidechain deployed on Bitcoin, designed for private transactions between exchanges for trading and issuance of other assets like stablecoins or equity tokens. Its codebase is built almost entirely on that of Bitcoin itself. One of the core features of the Liquid network was the implementation of Confidential Transactions, a feature using cryptographic range proofs to hide the amounts being sent in transactions but still provide a guarantee under certain assumptions that no money is being spent that doesn’t exist. Liquid also implemented Confidential Assets, an extension to Confidential Transactions. Confidential Assets hides what token is being spent in addition to the amount.
These two features combined provide a strong solution to one of the big shortcomings possible with a federated sidechain: censorship. A threshold majority (in our hypothetical 5-of-7 federation above) could all agree to censor specific transactions or UTXOs if they all had reason to, such as suspected or confirmed illegal activity. In such a case they would even have a rational incentive to do so, to not give governments a reason to go after the whole system. Confidential Transactions/Assets can provide a high enough level of privacy that even if a federation has reason to censor certain types of transactions they would have a very difficult time picking them out to do so.
A peg-in transaction on Liquid is a relatively simple two-step process. A user wishing to peg-in takes the multisig address of the federation and then “tweaks” each public key involved in it using pay-to-contract with a Liquid address they control, to create new public keys. The federation members can derive the matching private keys once they learn the Liquid address used. Until that information is revealed no one, not even the federation, knows that a transaction to this tweaked address is a Liquid peg-in. Then the user broadcasts the transaction on the mainchain and waits for 100 confirmations. Once the confirmations have built up, the user can submit a transaction on the Liquid network to send their coins to themselves. This transaction uses a special input that contains the Liquid address with which they tweaked the federation’s keys, a signature proving they control it and a Merkle proof showing the mainchain peg-in transaction has at least 100 confirmations.
The peg-out process is much simpler. A user constructs a transaction that burns bitcoin on Liquid using OP_RETURN, contains an address to send to on the mainchain, and a special zero-knowledge proof from one of the federation members (which one is hidden). When federation members see such a transaction with a valid member proof, they will sign a withdrawal on the mainchain. The proof is implemented to prevent fraudulent or invalid withdrawals and allows whichever federation member is providing the proof to enforce whitelisting or restrictions on peg-outs. Anyone can freely peg bitcoin into the Liquid network, but a relationship with a federation member is required to peg-out.
In terms of key management and handling security, Blockstream developed Hardware Security Modules (HSMs) to handle the keys and perform signing operations. These devices secure the keys used for block signing and peg-ins/outs, keeping them secure against tampering or key extraction. In order to provide some means of recovery in the event of failed devices losing keys, but to also protect against key extraction for malicious purposes, backups of each member key are maintained encrypted in a way as to require both that member and Blockstream to cooperate to decrypt the key for loading into a new HSM. Neither party can decrypt the backup on their own. A last line of defense against key loss is the Emergency Withdrawal keys. Every address that the federation sweeps peg-in coins to has two spending paths: the required threshold of the federation, and after roughly a month’s timelock (although the length of time could be changed) the required threshold of the emergency keys. These are a second set of keys that can be maintained by the federation, another party or a combination of them to ensure coins can be recovered if too many federation keys are lost. The federation regularly moves the coins on the mainchain in their custody before the timelock expires, so as long as the federation hasn’t failed, this emergency path will never be spendable. Currently Blockstream maintains the recovery keys that are geographically distributed.
Lastly there is a functionality called “Dynamic Federations.” This allows a large majority of the federation to update the membership, adding or removing members. This is done through a software update to the signing software after deciding on which new members to add or existing ones to remove and then a month-long signaling period. If, for one month, four-fifths of the blocks signaled for the federation change, the network “forks” to recognize the new federation as block signers. The network then begins using new peg-in addresses with the new federation, but still recognizes the old ones for an additional month to ensure no peg-ins are invalidated during the federation change. It is also not allowed to remove so many federation members that there are not enough left to sign for withdrawals from old addresses. All of these aspects of federation upgrades are part of the consensus rules and enforced/validated by the HSMs.
Rootstock (RSK)
Rootstock is a federated sidechain with many design differences versus Liquid. Firstly, it is essentially a copy-paste clone of Ethereum in terms of functionality. It fully supports Solidity, the scripting language used by Ethereum, so that any contract deployed on Ethereum is trivially portable to Rootstock. The rationale for doing this is obviously that Ethereum has a lot of demand and can deliver functionality that Bitcoin is not capable of. Obviously, there are many downsides and risks to Ethereum’s architecture, but you can’t deny there is demand for it.
Another major difference in terms of architecture is what the federation does — they collectively manage a multisig that custodies the funds on the mainchain, but the federation does not in normal circumstances participate in minting blocks. This is done by Bitcoin miners through merged mining, allowing them to mine Bitcoin and Rootstock at the same time. While this provides no meaningful security difference for Bitcoin pegged into the Rootstock chain, it does provide some for other assets issued on the sidechain. The federation can always steal the Bitcoin on the mainchain if enough collude, but because miners actually mine the sidechain it can continue and allow the other assets to keep being transacted. If those other assets have enough value, even without being backed by real bitcoin, the Rootstock BTC token should still have enough market demand to pay fees to utilize other assets to incentivize miners to keep mining.
The involvement of miners isn’t absolute, though. As long as a majority of Bitcoin miners are also mining Rootstock, they are in total control of organizing transactions and mining them into blocks, but if that percent of miners drops into the range of half (or slightly lower), there are consensus rules allowing the federation to sign checkpoints preventing reorgs back before the checkpoint. If the hash rate drops more drastically than that they are even capable of taking over as blocksigners, like Liquid’s federation members. It’s a very dynamic system that can function both without miners and without the federation in order to keep the blockchain progressing forward.
The peg-in process is very simple: send bitcoin to the RSK peg-in address and then wait for enough confirmations. After enough confirmations have built up, a Solidity smart contract on the sidechain will recognize the transaction and credit it to an account on the sidechain controlled by the same key that the UTXO you pegged-in was locked to. Pegging-out is also controlled by a smart contract, which will communicate with the federation’s HSMs, which will sign a mainchain withdrawal transaction when told to by the contract.
When Roostock first launched all that was required to peg out was a majority of the federation HSMs signing the transaction after being told to by the smart contract on the sidechain. In 2020 they implemented a new peg mechanism called POWPeg. This upgrade allowed the HSMs to actually validate SPV proofs from miners. The HSMs now refuse to sign peg-out transactions unless a majority of the current set of RSK miners build on the transaction from the peg-out initiation. The security model ultimately boils down to the HSMs remaining secure, but unless a majority of them are tampered with and the keys extracted they will not sign without sufficient Proof-of-Work attesting to peg-outs.
Close Out
People have been working on designing sidechains for eight years now, and while we have gone through four different designs (and there are a few more out there: these are just the ones that have gotten traction with technical Bitcoiners), there is nothing currently deployed except federated chains. Federated systems might not be the trustless sidechain that many people want, but they are still very useful systems — especially in any context where the only way to meet a market demand is to trust a single custodian to arbitrate something. Federations immediately become a default improvement by spreading the counterparty risk around to multiple players.
Well, that’s federated sidechains in a nutshell. Last piece coming next goes into all the downsides and negatives of the major current proposals, at least a few high-level thoughts on what people really want from a “perfect” sidechain and how to potentially achieve that.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
Federated sidechains are currently the only deployed type of Bitcoin sidechain (the most recent paper here). The idea of using a federated peg and consensus system was actually an appendix in the original sidechains whitepaper. There was no concrete design for any type of two-way peg involving miners, so a federated peg was described as a way to deploy a sidechain now, and upgrade to a two-way verified peg using simple payment verification (SPV) proofs similar to what softchains do, when something was concretely designed that was safe and deployable. It was also pointed out that in terms of incentives, for very small systems it might be dangerous to use a miner-based peg as they could steal from a very small group of people without much consensus on doing anything about it from the wider Bitcoin system. Federations could be useful for smaller systems where the group of users isn’t big enough to be a disincentive for miners to steal coins.
The general idea is to effectively have a blockchain where a selected group of trusted parties custody bitcoin pegged into the system using multisig, and produce the blocks on the sidechain, signing them with cryptographic keys instead of using proof-of-work. The entire security model is based on having a decently large set of distinct participants in the group, or federation, that are very geographically distributed and are publicly known.
Federations use a threshold of members for both the custody of bitcoin on the mainchain and blocksigning, i.e., a 5-of-7 multisig. This is done instead of requiring all seven of the members to sign in order to balance the two major risks of such a system: theft versus loss. The federation together can steal all of the funds locked in a federated sidechain if they choose to cooperate together to do so; this is why the entire security model is based around many different actors in many different legal jurisdictions. You want it to be exceedingly difficult and unlikely that many different governments all cooperate in order to force a federation to do something malicious, so you want a large number of people needed to sign things. On the other hand, if you require all seven members to sign everything, then all it takes is a single member to lose access to their keys to result in permanent loss of all funds in the sidechain. Hence requiring a majority of members to sign, but not all of them. This leaves some margin of error for key loss while also still requiring a high number of members to be coerced or to conspire to result in a theft of funds.
This makes the security model of the system two-directional in terms of security thresholds. As previously stated, in order for the funds to be actively stolen, five out of the seven participants in this hypothetical situation must collude or be coerced into colluding in order to steal the sidechain funds. However, only three of the seven participants must lose, destroy or be coerced into disabling their keys in order to leave the sidechain funds frozen and unable to be moved — possibly permanently. The thresholds are a balancing act between these two risks.
Both of them simultaneously need to be high enough in order to make both worst cases unlikely to occur.
Aside from these core properties there is a large degree of freedom in how you could implement a federated sidechain, both in terms of how to design the sidechain itself as well as how to handle key management for the block signing and peg custody keys.
Liquid
Liquid was the first federated sidechain deployed on Bitcoin, designed for private transactions between exchanges for trading and issuance of other assets like stablecoins or equity tokens. Its codebase is built almost entirely on that of Bitcoin itself. One of the core features of the Liquid network was the implementation of Confidential Transactions, a feature using cryptographic range proofs to hide the amounts being sent in transactions but still provide a guarantee under certain assumptions that no money is being spent that doesn’t exist. Liquid also implemented Confidential Assets, an extension to Confidential Transactions. Confidential Assets hides what token is being spent in addition to the amount.
These two features combined provide a strong solution to one of the big shortcomings possible with a federated sidechain: censorship. A threshold majority (in our hypothetical 5-of-7 federation above) could all agree to censor specific transactions or UTXOs if they all had reason to, such as suspected or confirmed illegal activity. In such a case they would even have a rational incentive to do so, to not give governments a reason to go after the whole system. Confidential Transactions/Assets can provide a high enough level of privacy that even if a federation has reason to censor certain types of transactions they would have a very difficult time picking them out to do so.
A peg-in transaction on Liquid is a relatively simple two-step process. A user wishing to peg-in takes the multisig address of the federation and then “tweaks” each public key involved in it using pay-to-contract with a Liquid address they control, to create new public keys. The federation members can derive the matching private keys once they learn the Liquid address used. Until that information is revealed no one, not even the federation, knows that a transaction to this tweaked address is a Liquid peg-in. Then the user broadcasts the transaction on the mainchain and waits for 100 confirmations. Once the confirmations have built up, the user can submit a transaction on the Liquid network to send their coins to themselves. This transaction uses a special input that contains the Liquid address with which they tweaked the federation’s keys, a signature proving they control it and a Merkle proof showing the mainchain peg-in transaction has at least 100 confirmations.
The peg-out process is much simpler. A user constructs a transaction that burns bitcoin on Liquid using OP_RETURN, contains an address to send to on the mainchain, and a special zero-knowledge proof from one of the federation members (which one is hidden). When federation members see such a transaction with a valid member proof, they will sign a withdrawal on the mainchain. The proof is implemented to prevent fraudulent or invalid withdrawals and allows whichever federation member is providing the proof to enforce whitelisting or restrictions on peg-outs. Anyone can freely peg bitcoin into the Liquid network, but a relationship with a federation member is required to peg-out.
In terms of key management and handling security, Blockstream developed Hardware Security Modules (HSMs) to handle the keys and perform signing operations. These devices secure the keys used for block signing and peg-ins/outs, keeping them secure against tampering or key extraction. In order to provide some means of recovery in the event of failed devices losing keys, but to also protect against key extraction for malicious purposes, backups of each member key are maintained encrypted in a way as to require both that member and Blockstream to cooperate to decrypt the key for loading into a new HSM. Neither party can decrypt the backup on their own. A last line of defense against key loss is the Emergency Withdrawal keys. Every address that the federation sweeps peg-in coins to has two spending paths: the required threshold of the federation, and after roughly a month’s timelock (although the length of time could be changed) the required threshold of the emergency keys. These are a second set of keys that can be maintained by the federation, another party or a combination of them to ensure coins can be recovered if too many federation keys are lost. The federation regularly moves the coins on the mainchain in their custody before the timelock expires, so as long as the federation hasn’t failed, this emergency path will never be spendable. Currently Blockstream maintains the recovery keys that are geographically distributed.
Lastly there is a functionality called “Dynamic Federations.” This allows a large majority of the federation to update the membership, adding or removing members. This is done through a software update to the signing software after deciding on which new members to add or existing ones to remove and then a month-long signaling period. If, for one month, four-fifths of the blocks signaled for the federation change, the network “forks” to recognize the new federation as block signers. The network then begins using new peg-in addresses with the new federation, but still recognizes the old ones for an additional month to ensure no peg-ins are invalidated during the federation change. It is also not allowed to remove so many federation members that there are not enough left to sign for withdrawals from old addresses. All of these aspects of federation upgrades are part of the consensus rules and enforced/validated by the HSMs.
Rootstock (RSK)
Rootstock is a federated sidechain with many design differences versus Liquid. Firstly, it is essentially a copy-paste clone of Ethereum in terms of functionality. It fully supports Solidity, the scripting language used by Ethereum, so that any contract deployed on Ethereum is trivially portable to Rootstock. The rationale for doing this is obviously that Ethereum has a lot of demand and can deliver functionality that Bitcoin is not capable of. Obviously, there are many downsides and risks to Ethereum’s architecture, but you can’t deny there is demand for it.
Another major difference in terms of architecture is what the federation does — they collectively manage a multisig that custodies the funds on the mainchain, but the federation does not in normal circumstances participate in minting blocks. This is done by Bitcoin miners through merged mining, allowing them to mine Bitcoin and Rootstock at the same time. While this provides no meaningful security difference for Bitcoin pegged into the Rootstock chain, it does provide some for other assets issued on the sidechain. The federation can always steal the Bitcoin on the mainchain if enough collude, but because miners actually mine the sidechain it can continue and allow the other assets to keep being transacted. If those other assets have enough value, even without being backed by real bitcoin, the Rootstock BTC token should still have enough market demand to pay fees to utilize other assets to incentivize miners to keep mining.
The involvement of miners isn’t absolute, though. As long as a majority of Bitcoin miners are also mining Rootstock, they are in total control of organizing transactions and mining them into blocks, but if that percent of miners drops into the range of half (or slightly lower), there are consensus rules allowing the federation to sign checkpoints preventing reorgs back before the checkpoint. If the hash rate drops more drastically than that they are even capable of taking over as blocksigners, like Liquid’s federation members. It’s a very dynamic system that can function both without miners and without the federation in order to keep the blockchain progressing forward.
The peg-in process is very simple: send bitcoin to the RSK peg-in address and then wait for enough confirmations. After enough confirmations have built up, a Solidity smart contract on the sidechain will recognize the transaction and credit it to an account on the sidechain controlled by the same key that the UTXO you pegged-in was locked to. Pegging-out is also controlled by a smart contract, which will communicate with the federation’s HSMs, which will sign a mainchain withdrawal transaction when told to by the contract.
When Roostock first launched all that was required to peg out was a majority of the federation HSMs signing the transaction after being told to by the smart contract on the sidechain. In 2020 they implemented a new peg mechanism called POWPeg. This upgrade allowed the HSMs to actually validate SPV proofs from miners. The HSMs now refuse to sign peg-out transactions unless a majority of the current set of RSK miners build on the transaction from the peg-out initiation. The security model ultimately boils down to the HSMs remaining secure, but unless a majority of them are tampered with and the keys extracted they will not sign without sufficient Proof-of-Work attesting to peg-outs.
Close Out
People have been working on designing sidechains for eight years now, and while we have gone through four different designs (and there are a few more out there: these are just the ones that have gotten traction with technical Bitcoiners), there is nothing currently deployed except federated chains. Federated systems might not be the trustless sidechain that many people want, but they are still very useful systems — especially in any context where the only way to meet a market demand is to trust a single custodian to arbitrate something. Federations immediately become a default improvement by spreading the counterparty risk around to multiple players.
Well, that’s federated sidechains in a nutshell. Last piece coming next goes into all the downsides and negatives of the major current proposals, at least a few high-level thoughts on what people really want from a “perfect” sidechain and how to potentially achieve that.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Feedzy
