Soft chains are a side chain implementation that interacts with consensus mechanisms more deeply, which has both advantages and disadvantages.
In this article, which examines several side chain implementation approaches, we’ll discuss soft chains. This is another side chain mechanism idea from Ruben Somsen. Space chains, the design I mentioned in my earlier essay, is very different from this. It needs a change to the Bitcoin Core protocol that is designed to set up a side chain. It also needs to charge Bitcoin full nodes a new validation fee and support a two-way peg mechanism that doesn’t rely on a federation to hold funds.
The structure block
The fundamentals of the notion are based on a mechanism to increase simplified payment verification (SPV) security for wallets proposed by Somsen earlier, referred to as POW fraud proofs. The concept is based on a straightforward observation about blockchains: if an invalid block is mined, the blockchain will probably fork because any honest miners will refuse to build on it and eventually mine a valid one. The likelihood of an invalid block being generated and no fork being initiated by honest miners is extremely small, effectively indicating that the network’s consensus mechanism has completely failed. As a result, the appearance of a fork can be interpreted as a form of warning: “Hey, something might have happened here; check this out.” Clients might use forks like this as a type of warning to download these blocks and check the situation out.
However, this poses a fundamental issue because a UTXO must be set in order to verify a block. A UTXO set can only be created once all the preceding blocks in the chain have been validated. Consequently, how does this work as an SPV mechanism? Commitments made by UTXO are the solution.
Each node builds and keeps a local database of all the bitcoins that are currently in existence but have not yet been spent, as it scans the blockchain from the beginning in order to validate each block against the UTXO set. A UTXO set commitment creates a Merkle tree from the UTXO set and, ideally, commits the hash of the tree inside of each block. This enables you to get a block that has some extra information in it, such as a Merkle branch for each transaction’s input, confirming it was included in the previous UTXO set commitment, and verifying it that way. A system would offer a security guarantee practically identical to a complete node if it implemented such a commitment method from the beginning and was really utilised by many users to fully verify the chain. You can download every block involved in a chain split once it occurs to make sure the chain you are following is still legitimate. The longest still prevails even if both arguments for the divide are true. However, if one of them was false, you would know right away thanks to this.
The 2 way Peg
According to the soft chain design, main chain nodes would need to download and validate each soft chain block header as well as any chain split blocks using the UTXO set commitments. The foundation for the pig-out mechanism to permit a two-way peg would be this. When claiming coins on the side chain, the user would point to the main chain transaction that assigned the coins to a certain soft chain in order to claim them there. In contrast, if you were trying to peg out of the side chain, you would do the exact reverse. The POW fraud proofs are useful in this situation. The objective of a peg out is to construct a main chain transaction that references a side chain withdrawal transaction. Those coins would remain “frozen in the soft chain” if the withdrawal transaction on the side chain was reorganized out or determined to be illegitimate until after a lengthy confirmation time, such as a year. The latter would be found because, in the case of a chain split, the main chain node will download every block on both sides of the split and verify it using UTXO set commitments.
The lengthy confirmation window for peg outs was created to give even a small number of trustworthy miners enough time to create a single valid block, split the chain, and start a validation process using UTXO set commitments. By catching fake side chain pay-outs before the withdrawal is verified on the main chain, main chain nodes can invalidate that transaction without having to validate the whole side chain, which would be the same as making the block size bigger.
Security Risks and Parameters
Regarding the degree of security based on specific factors and how such a side chain would interact with miners, this approach raises several doubts. First of all, any soft chain should be deployed with a minimum difficulty requirement for blocks, such that if the hash rate gets too low, blocks on the side chain would simply take longer to findโi.e., the block interval would lengthenโrather than the difficulty dropping below this minimum. This is required by the POW fraud-proof validation that the main chain nodes of this design must carry out. If the difficulty of the soft chain is set too low, it will be easy for miners to fork the soft chain on purpose. This will make it easy for them to launch a denial-of-service (DOS) attack on main chain nodes by giving them more data to validate.
Merged mining is a remedy for this issue. The problem of DOS attacks on the main chain by causing a soft chain on the soft chain is solved as far as it can be if all Bitcoin miners also mine blocks on the side chain. Splitting the soft chain would be equally labour-intensive as splitting the main chain, limiting arbitrary and inexpensive attempts to increase the amount of information required to validate the main chain. But it also creates a new problem because it raises the cost of validating miners to stop DOS attacks.
To verify that the blocks they are mining are genuine, miners must run the nodes if they intend to mine the soft chains as well. They run the danger of becoming orphaned and losing the fee money from an invalid block if they aren’t. It may become increasingly difficult and expensive to participate in mining if numerous hard-to-verify soft chains, such as Ethereum-clone chains or large blockchains, are enabled. This isn’t truly optional because miners need to validate a chain to ensure they aren’t constructing on an invalid block and losing money. Making validation more expensive defeats the purpose of maximising mining decentralization.
The largest problem is the possibility that a soft chain consensus defect will really result in a main chain consensus split. A valid peg-out transaction on the side chain side may become invalidated by significant side chain reorgs just as the main chain side is about to become valid. Keep in mind that the main chain nodes also follow the soft chain headers. If separate portions of the network are on different sides of a soft chain peg-out split just as a side chain peg-out is being validated on the main chain, this could result in the main chain splitting. A main chain split could also be caused by problems with non-deterministic consensus on the soft chain. For example, if some nodes thought a peg out was wrong but others thought it was validated; this could cause the main chain to split.
This side chain design is somewhat dangerous and possibly something that shouldn’t be done due to its closer link to the main chain consensus. Instead of deploying a single fork that would allow soft chains to be spun up at will, soft chains should, at the very least, be activated one at a time in distinct forks? Because chain splits require main chain nodes to check more data, the fact that you can turn on multiple soft chains at once creates a way to attack the main chain.
Although there are numerous dangers associated, soft chains are more involved in the main chain’s consensus layer than space chains are. As a result, there is more room for potential use cases because they support a native two-way peg. I’ll discuss drive chains next, followed by some concluding remarks on side chains in general.
Mark T is a guest author on this page. The author's views are his or his own and may or may not be those of coinbaazar LLC. or cryptoplo.com.