Sidechains are not Secure
Note: when referring to sidechain security I exclude one-way-pegged sidechains. Those are not affected by the problems I examine in this article.
Sidechains propose a way to link one blockchain to another, such that funds can be moved seamlessly between them. They are being researched mostly as a way to add new features to the Bitcoin network. For more information about sidechains look at the Sidechains paper and also Drivechain. The concept and proposed solutions are undoubtedly clever, but there are flaws that make sidechains fundamentally insecure.
In order to be able to move funds between a sidechain and the main chain—a process known as two-way pegging—certain methods have been proposed, some of them relying on trust, others on consensus soft forks on the main chain (i.e. Bitcoin).
The simplest method for sidechain funding involves a set of functionaries that own keys that can sign transactions that spend funds from a multi-signature locker account. This locker account is the recipient of funds moving from the main chain to the sidechain, and the originator of funds for withdrawals from the sidechain to the main chain.
Signing functionaries could—and probably should—double as validators for transactions in the sidechain. The security of this model depends on the trustworthiness of the signers.
This model is fine as long as trust holds, especially if both withdrawal transactions and sidechain consensus depend on signatures from the same set of functionaries. Since validators are not expected to ever sign a double-spend or invalid withdrawal, as doing so would expose them as fraudsters, this system is at its best when relying on identity of validators and law enforcement for security.
Soft Fork for SPV Proof Validation
With an SPV-proof-based system, sidechain funding is achieved by sending funds to an account that requires an SPV proof from the sidechain in order to build a valid transaction spending from it. To validate this proof a soft fork is required on the main chain. The SPV proof is included in the spending transaction input script.
This model allows sidechain miners to construct valid SPV proofs that satisfy main chain requirements but that do not necessarily satisfy sidechain consensus, such as a valid SPV proof for an orphan sidechain, consequently allowing subtraction of sidechain funds from its main chain account.
Soft Fork to Vote for Transactions
A proposed solution to the orphan SPV proof problem above is to allow main chain miners to collectively vote for a transaction to be included in a block. The transaction must include an opcode—soft fork required—in its script that will validate that a vote has succeeded. The vote takes place by including the transaction id in the coinbase of a number of mined blocks for a stretch of main chain.
The security model of this system assumes that miners will vote for valid sidechain withdrawal transactions in order to eventually profit from their transaction fees. Voting miners must run node software for the sidechain in order to identify valid withdrawal transactions to vote for. This is an improvement over SPV proof validation as it happens at the chain rather than transaction scale.
This model allows miners to vote on withdrawal transactions that are invalid per sidechain rules, leading to subtraction of sidechain funds from the main chain.
When the main chain or a sidechain experiencies block reorganization (reorg) its consistency as well as that of pegged chains should be maintained. Some sidechain systems assume that consistency is maintained as long as a reorg is no longer than certain number of blocks.
A proposed system of merge-mining a sidechain allows it to reuse the main chain proof-of-work block validation. Ordering of blocks on the sidechain depends on their order of inclusion in the main chain. This allows main chain reorgs to affect the sidechain while still retaining consistency on both chains.
Two-way pegging becomes a problem when a reorg occurs, since the sidechain may consider a withdrawal to no longer be valid, but that withdrawal transaction could still end up included in the main chain. This is expected to be mitigated by allowing withdrawals from the main chain only after the sidechain has been validated to certain depth.
A sidechain with different consensus paths for its withdrawals and block validation can decohere in a way that funds end up being subtracted from its main chain account. An example of this would be a sidechain that uses proof-of-stake to validate its blocks and a multisig lockbox for its main chain account. If a reorg happens in the sidechain due to a proof-of-stake consensus change, it cannot force transactions already signed by the lockbox functionaries to become invalid on the main chain.
When main chain miners validate a sidechain by running a sidechain node, they are expected not to build upon valid main chain blocks that include invalid sidechain withdrawals. This situation is analogous to what happens when some nodes running different consensus software encounter an otherwise-valid block that is rejected only by their software. A fork occurs and the blockchain temporarily branches off in a new direction for these users. If a sidechain’s rules are enforced only by some miners and nodes, forks like this may become common, degrading performance of the main chain. To avoid this every node and miner should run the same set of consensus rules, which includes every two-way-pegged sidechain, excluding those using multisig consensus.
When everybody running nodes and mining blocks is also validating consensus for a set of sidechains, these sidechains cease to be sidechains at all and become part of the regular consensus, and can no longer be considered insecure.