Softchain’s Use Cases and Security Costs – Bitcoin Magazine
This is an opinion piece by Shinobi, a self-taught Bitcoin educator and tech-savvy Bitcoin podcast host.
In this next piece looking at different sidechain implementation designs, we’ll walk through softchains. This is another one of Ruben Somsentheir proposals for a side chain mechanism. This differs greatly from space chains, the design covered in my previous article. It requires a specific change to the Bitcoin Core protocol that is specifically structured to implement a sidechain, imposes a new validation cost on Bitcoin full nodes, and has support for a two-way linking mechanism that does not rely on a federation of custodians.
The building block
The core of the idea builds on an earlier proposal by Somsen called PoW fraud proofs, a mechanism to improve the security of simplified payment verification (SPV) for wallets. The idea is based on a simple observation about a blockchain – if an invalid block is produced, there will likely be a fork in the blockchain, as the honest miners that exist will refuse to build on the invalid block and eventually mine a valid one. An invalid block being produced and no fork created by honest miners essentially means that there has been a complete breakdown in the consensus process of the network, so the statistical chances of that happening are negligible. Therefore, a fork that occurs can be seen as a kind of signal that “Hey, something could have happened here, so you should check this out.” Clients can use forks like this as a kind of alarm that they should actually download these blocks and confirm what’s happening.
However, this poses a fundamental problem – to confirm a block you need a UTXO set. To have a UTXO set, you must have verified all the previous blocks in the chain to construct it. So how does this work as an SPV mechanism? The answer is UTXO set commitments.
Each block must be validated against the UTXO set, a database of every bitcoin in existence that hasn’t been spent yet, and currently this is just a local database that each node constructs and stores as it scans through the blockchain from scratch. A UTXO set commit takes the UTXO set, builds a Merkle tree from it, and ideally commits the hash of it inside each block. This allows you to receive a block with some extra data – a Merkle branch for each entry of each transaction that proves it was in the last UTXO set commit – and verify it that way. If a system used such a commitment scheme from the very beginning, and it was actually used by a large number of users who fully verified the chain, they would provide a security guarantee almost equivalent to a full node. Every time a chain split happens, you can download all the blocks involved and ensure that the chain you are following is valid. If both sides of the split are valid, the longest still wins. But if one of them was invalid, this would let you detect it right away.
The two-way stick
As part of the softchain design, mainchain nodes must download and validate the block headers for each softchain, and in the case of chain splitting, download and validate those blocks using the UTXO set’s commits. This will form the basis of the pegout mechanism to enable a two-way peg. To migrate coins to the sidechain, the user would create a mainchain transaction that assigned them to a specific softchain and then point to that transaction when it was confirmed to claim coins on the sidechain. Conversely, you would do the opposite when trying to get stuck out of the side chain. This is where the PoW fraud proofs come into play. During a pegout, the idea is to create a transaction on the main chain that references a withdrawal transaction on the side chain. These coins would not be used until after a long confirmation window (say a year) and would remain “locked in the softchain” if the withdrawal transaction on the sidechain was reordered or found to be invalid. The latter will be detected because in the event of a chain split, the main chain node will download all the blocks on either side of the split and verify them using UTXO set commitments.
The long confirmation window for pegouts is such that even a small percentage of honest miners can have enough time to produce a single valid block that splits the chain and triggers a validation of everything from that point on with UTXO commits. This allows the mainchain nodes to catch false sidechain pegouts before the withdrawal is confirmed on the mainchain, thereby invalidating the transaction without requiring them to validate the entire sidechain – which would be no different than an increase in block size.
Safety parameters and risks
This design raises some questions regarding the level of security based on certain variables and how such a sidechain will interact with miners. First, any soft chain should be deployed with a minimum block difficulty requirement so that if the hash rate gets too low rather than the difficulty of adjusting below this minimum blocks on the sidechain will simply take longer to find – i.e. the block interval will increase. This is necessary due to the PoW fraud proof validation main chain nodes must perform as part of this design. If the difficulty of the softchain is too low, it will become easy for miners to maliciously split the softchain regularly and effectively carry out a denial of service (DoS) attack against the main chain nodes by increasing the amount of extra data they have to validate.
Pooled mining is a solution to this problem. If all the Bitcoin miners also mined blocks on the sidechain, the problem of DoS attacks on the mainchain by creating chain splits on the softchain is solved about as well as it can be. It will take as much work to split the softchain as the main chain, and prevent arbitrary and reasonable attacks to increase the amount of data needed to validate the main chain. But by solving the DoS attack problem, it creates another problem: increasing the validation costs of miners.
If miners are also going to mine softchains, they need to run the nodes for them to ensure that the blocks they mine are valid. If they are not, they risk being orphaned and losing the fee income from an invalid block. If many expensive to verify soft chains were activated, such as Ethereum clone chains or large blockchains, this could make mining more centralized and expensive to participate in. Miners need to validate a chain to know they are not building on an invalid block and losing money , so this isn’t really optional. Making validation more expensive undermines efforts to maximize the decentralization of mining.
The biggest problem is the risk that a consensus failure on a softchain actually causes a consensus split of the mainchain itself. There is a risk that major sidechain reorganizations invalidate a valid pegout transaction on the right sidechain page as the mainchain page is about to become valid. Remember that the main chain’s nodes also follow the softchain headers. This can cause the main chain to split if different parts of the network are on different sides of a soft chain split right as a side chain connection is being validated on the main chain. Non-deterministic softchain consensus errors can also cause a main chain split, i.e. if some nodes saw a pegout as invalid but others saw it as valid.
This deeper connection with main chain consensus makes this side chain design somewhat risky and potentially something that should not be done. At the very least, softchains should be activated one at a time in individual forks, rather than using a single fork that allows softchains to be spun up at will. The fact that chain splits in this design cause the main chain’s nodes to verify more data makes the ability to turn on many soft chains simultaneously an attack vector on the main chain.
Softchains become more involved in the consensus layer of the main chain than space chains, which comes with many risks, but they allow for a natural two-way coupling and therefore more potential space for different use cases. Next, I’ll go over drive chains, and then some final thoughts on side chains in general.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
