This is an opinion piece by Shinobi, a self-taught educator in the bitcoin space and tech-oriented bitcoin podcast host.
In this next article looking at different sidechain implementation designs, we’ll go over soft chains. It is another of Ruben Somsenproposals for a sidechain mechanism. This differs greatly from spatial warps, the design covered in my previous article. It requires a specific modification to the specifically structured Bitcoin Core protocol to implement a sidechain, imposes a new validation cost on Bitcoin full nodes, and supports a two-way peg mechanism that does not rely on a federation to hold funds.
The building block
The core of the idea builds on an earlier proposal by Somsen called PoW Fraud Evidence, 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 is likely to be a fork in the blockchain because any honest miner in existence will refuse to build on the invalid block and possibly take any. operate a valid. An invalid block produced and no forks created by honest miners essentially means that there has been a complete breakdown in the network’s consensus process, so the statistical chances of this happening are insignificant. Therefore, a fork that occurs can be seen as a kind of signal that “Hey, something could have happened here, so you should check that out.” Clients could use forks like this as a kind of alarm that they should actually download those blocks and check what’s going on.
This poses a fundamental problem, however – to verify a block, you need to have a UTXO set. To have a UTXO set, you must have checked all previous blocks in the chain to build it. So how does this work as an SPV mechanism? The answer is the commitments defined by UTXO.
Each block must be validated against the UTXO set, a database of every existing bitcoin that has not yet been spent and currently it is only a local database that each node builds and records as it traverses the blockchain from the start. A UTXO set commit takes the UTXO set, builds a Merkle tree of it, and ideally commits the hash inside each block. This allows you to receive a block with additional data – a Merkle branch for each entry of each transaction proving it was in the last UTXO set commit – and verify it that way. If a system used such a commitment scheme from the start, and it was actually used by a large number of users fully verifying the chain, then they would provide a security guarantee almost equivalent to a full node. Whenever a chain split occurs, you can download all the blocks involved and ensure that the chain you are following is valid. If both sides of the division are valid, the longest always wins. However, if any of them were invalid, it would allow you to detect them immediately.
The two-way ankle
As part of the software chain design, mainchain nodes should download and validate block headers for each software chain, and in the case of any chained download and validate those blocks using commitments defined by UTXO. This would form the basis of the linking mechanism to allow for two-way linking. To migrate coins to the sidechain, the user would create a mainchain transaction by assigning them to a specific software chain, and then point to that transaction when confirmed to claim coins on the sidechain. Conversely, you would do the opposite when attempting to exit the sidechain. This is where PoW cheat proofs come in. During a pegout, the idea is to create a mainchain transaction that references a sidechain pullout transaction. These coins would only become usable after a long confirmation window (say a year) and would remain “locked in the softchain” if the withdrawal transaction on the sidechain was rearranged or deemed invalid. The latter would be discovered because in the event of a chain split, the mainchain node will download all the blocks on either side of the split and verify them using the commits set by UTXO.
The long confirmation window for pegs is such that even a tiny percentage of honest miners may have enough time to produce a single valid block splitting the chain and triggering a validation of everything from that point on with the commitments set by UTXO. This allows mainchain nodes to catch fraudulent sidechain tethers before the withdrawal is confirmed on the mainchain, thus invalidating that transaction without requiring them to validate the entire sidechain – which does not would be no different from an increase in block size.
Security settings and risks
This design creates questions in terms of level of security based on certain variables and how such a side chain would interact with miners. First of all, any software chain should be deployed with a minimum block difficulty requirement, so that if the hash rate gets too low instead of the difficulty to adjust below that minimum block on the sidechain, it would just take longer to find – i.e. the block interval would increase. This is necessary due to the PoW anti-fraud validation mainchain nodes that need to be run as part of this design. If the difficulty of the software chain is too low, then it would become easy for miners to regularly fork the software chain maliciously and effectively perform a denial-of-service (DoS) attack against the mainchain nodes by increasing the amount of additional data they need to validate.
Merged mining is a solution to this problem. If all Bitcoin miners also mined blocks on the sidechain, then the problem of DoS attacks on the mainchain by creating chain splits on the softchain is about as good as it gets solved. It would take as much work to split the software chain as the main chain, preventing arbitrary and low-cost attacks from increasing the amount of data needed to validate the main chain. However, by solving the DoS attack problem, it creates another problem: the increased cost of validating miners.
If miners are also going to mine software chains, they need to run the nodes for them to ensure that the blocks they are mining are valid. If they are not, they run the risk of being orphaned and losing the revenue from invalid block fees. If many expensive-to-verify software chains were enabled, such as Ethereum clone chains or large blockchains, it could make mining more centralized and expensive to participate. Miners have to validate a chain to know that they are not building on an invalid block and losing money, so it’s not really optional. Making validation more costly compromises efforts to maximize the decentralization of mining.
The biggest problem is the risk that a consensus bug on a software chain will actually cause a consensus split in the main chain itself. There is a risk that major sidechain reorganizations invalidate a valid pegout transaction on the sidechain side just when the mainchain side is about to become valid. Remember that the main chain nodes also follow the software chain headers. This could lead to the mainchain splitting if different parts of the network are on different sides of a softchain split just when a sidechain anchor is being validated on the mainchain. Non-deterministic consensus bugs on the software chain could also cause a main chain split, i.e. if some nodes saw a reattachment as invalid but others saw it as valid.
This deeper connection to the mainchain consensus makes this sidechain design somewhat risky and potentially something that shouldn’t be done. At the very least, software chains should be activated one at a time in individual forks, instead of deploying a single fork that would allow software chains to be launched at will. The fact that in this design, chain splits force mainchain nodes to verify more data makes the ability to simply activate many software chains at the same time an attack vector on the mainchain.
Software chains engage more in the consensus layer of the mainchain than space chains, which comes with a lot of risks, but it allows for native two-way anchoring and therefore more potential room 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 from Shinobi. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.