The Building Block

The core of the idea builds on an earlier proposal by Somsen called PoW fraud proofs, a mechanism to improve simplified payment verification (SPV) security for wallets. The idea builds on a simple observation about a blockchain - if an invalid block is produced there will likely be a fork in the blockchain as whatever honest miners exist will refuse to build on the invalid block and eventually mine a valid one. An invalid block being produced and no fork being created by honest miners essentially means that there has been a complete breakdown in the consensus process of the network, so the statistical odds of that happening are insignificantly tiny. Therefore, a fork occuring can be seen as a kind of signal thatHey, something could have happened here so you should check this out.Clients could use forks like this as a sort of alarm that they should actually download these blocks and verify what is going on.

This presents a fundamental problem though - in order to verify a block you have to have a UTXO set. In order to have a UTXO set you have to have verified all the previous blocks in the chain to construct it. So how does this function as an SPV mechanism? The answer is UTXO set commitments.

Every block needs to be validated against the UTXO set, a database of every bitcoin that exists that has not been spent yet and currently this is just a local database that each node constructs and saves as it scans through the blockchain from the beginning. A UTXO set commitment takes the UTXO set, builds a Merkle tree of it and ideally commits the hash of it inside of each block. This allows you to receive a block with some extra data - a Merkle branch for each input of every transaction proving it was in the last UTXO set commitment - and verify it that way. If a system used such a commitment scheme from the very beginning, and it was actually used by a wide number of users fully verifying the chain, then they would provide a security guarantee almost equivalent to a full node. Whenever a chainsplit happens, you can download all of 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. However if one of them was invalid, this would let you detect it right away.

The Two-Way Peg

As part of the softchain design, mainchain nodes would have to download and validate the block headers for each softchain, and in the case of any chainsplit download and validate those blocks using the UTXO set commitments. This would 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 assigning them to a specific softchain and then point to that transaction when confirmed to claim coins on the sidechain. Conversely, you would do the opposite when attempting to peg out of the sidechain. This is where the PoW fraud proofs come into play. During a pegout the idea is to create a transaction on the mainchain referencing a withdrawal transaction on the sidechain. Those coins would not become spendable until after a long confirmation window (say a year) and would remainlocked in the softchainif the withdrawal transaction on the sidechain was reorged out or found to be invalid. The latter would be discovered because in the event of a chainsplit, the mainchain node will download all of the blocks on each side of the split and verify them using UTXO set commitments.

The long confirmation window for pegouts is so that even a tiny percentage of honest miners can have enough time to produce a single valid block splitting the chain and triggering a validation of everything from that point with UTXO set commitments. This allows the mainchain nodes to catch fraudulent sidechain pegouts before the withdrawal confirms on the mainchain, therefore invalidating that transaction without requiring them to validate the entire sidechain - which would be no different than a blocksize increase.

Security Parameters And Risks

This design creates some questions in terms of the level of security based on certain variables and how such a sidechain would interact with miners. First of all, any softchain should be deployed with a minimum difficulty requirement for blocks, so that if hash rate gets too low instead of the difficulty adjusting below this minimum blocks on the sidechain would simply take longer to find - i.e., the block interval would increase. This is necessary because of the PoW fraud proof validation mainchain nodes must perform as part of this design. If the difficulty of the softchain is too low, then it would become easy for miners to maliciously fork the softchain on a regular basis and effectively perform a denial-of-service (DoS) attack against mainchain nodes by increasing the amount of extra data they have to validate.

Merged mining is a solution to this problem. If all the Bitcoin miners also mined blocks on the sidechain, then the issue of DoS attacks on the mainchain by creating chainsplits on the softchain is solved about as well as it can be. It would require as much work to split the softchain as it does the mainchain, preventing arbitrary and low-cost attacks to increase the amount of data needed to validate the mainchain. However, in solving the DoS attack issue it creates another issue: increasing the validation cost of miners.

If miners are going to mine the softchains as well, then they have to run the nodes for them to ensure the blocks they are mining are valid. If they arent, they run the risk of being orphaned and losing the fee revenue from an invalid block. If many expensive-to-verify softchains were activated, such as Ethereum-clone chains or big block chains, this could make mining more centralized and expensive to participate in. Miners have to validate a chain to know they are not building on an invalid block and losing money, so this isnt really optional. Making validation more expensive undermines efforts to maximize the decentralization of mining.

The biggest issue is the risk of a consensus bug on a softchain actually causing a consensus split of the mainchain itself. There is a risk of major sidechain reorgs invalidating a valid pegout transaction on the sidechain side right as the mainchain side is about to become valid. Remember, mainchain nodes also are following the softchain headers. This could lead to the mainchain splitting if different parts of the network are on different sides of a softchain split right as a sidechain pegout is being validated on the mainchain. Non-deterministic consensus bugs on the softchain could also cause a mainchain split, i.e., if some nodes saw a pegout as invalid but others saw it as valid.

This deeper connection with the mainchain consensus makes this sidechain 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, instead of deploying a single fork that would allow softchains to be spun up at will. The fact that in this design chainsplits cause mainchain nodes to verify more data makes the ability to simply turn on many softchains all at once an attack vector on the mainchain.

Softchains get more involved in the consensus layer of the mainchain than spacechains, which comes with many risks, but they allow for a native two-way peg and therefore more potential room for different use cases. Next up, Ill be going through drivechains, and then after that some final thoughts on sidechains in general.