In this article, we learn about soft forks in blockchains. We also give some examples of soft forks in Bitcoin and conclude with some issues involved with soft forks.
Table of contents.
- Examples of Bitcoin Soft-Forks.
- Issues with Soft-Forks.
In the prerequisite article, we learned about how blockchain forks are formed, how miners diverge after a fork, retargeting, and the two main types of blockchain forks. Blockchain forks can either be contentious or non-contentious. We've already looked at contentious forks. In this article, we learn about non-contentious blockchain forks in depth.
While the contentious result in two very different chains that invalidate nodes and at the same time validate others, non-contentious forks allow for backward compatibility. In this case, nodes can refuse to change the client software but will remain valid. If a change is proposed such that nodes that refuse to upgrade still see transactions or blocks valid while applying the old consensus rule, then the change can happen without the need for a fork.
A soft-fork is a non-contentious fork. It is a forward-compatible change to the existing consensus rules that allow nodes refusing to change to continue their operations on blocks and transactions using the new consensus rules.
Soft-forks constrain the existing consensus rules in that for a fork to be forward-compatible, transactions and blocks that are mined using the new consensus rules must also be valid under the old consensus rules and not vice versa. Meaning that the new consensus rules only specify transactions and blocks that are valid and does not invalidate old ones otherwise we will have a hard-fork situation.
Examples of Bitcoin Soft-Forks.
In the Bitcoin blockchain, soft-forks have been implemented based on the reinterpretation of NOP codes.
NOP codes (New OP_CODES) were previously reserved by Bitcoin. There are 10 of them from 1(NOP1) through 10(NOP10). Under the consensus rules, when these were used in a transaction script, they had no effect whatsoever.
This means that a soft fork can be used to modify the semantics of a NOP OP_CODE and give it a purpose.
We saw this in BIP-65 that made NOP2 OP_CODE interpreted as an OP_CHECKLOCKTIMEVERIFY opcode. In this case, it imposed an absolute timelock consensus rule on a UTXO containing it in the locking script.
In this case, we classify such a change as a soft fork because transactions valid to nodes implementing BIP-65 remain valid to nodes ignorant of this BIP. To both nodes, the 'updated' and the 'ignorant', transactions and blocks are valid.
Another case in point of a soft-fork was the SegWit change to the existing protocol that moved unlocking scripts(witness) from a transaction to an external data structure thereby segregating it.
This change modified the fundamental structure of transactions and therefore deserved to be a hard fork, however, a change was proposed that would see it being implemented as a soft fork.
This change was proposed in 2015, it modified the locking script of the UTXO created under SegWit rules such that unmodified clients would see the locking script as redeemable with any other unlocking script.
This allowed SegWit to be activated without the need for every node to adopt it. It was backward-compatible, in that those nodes that choose to ignore it would still consider SegWit transactions and blocks valid.
Issues with Soft-Forks.
In the Bitcoin blockchain, soft-forks that are based on the use of NOP opcodes are controversial since the main reason they were added to the Bitcoin core was to allow changes that did not disrupt the underlying protocol.
It is a concern among the Bitcoin development community that certain soft forks come with huge trade-offs that compromise the original vision. In this section, we look at some of these issues.
Soft forks result in transactions being created with additional constraints. Remember that a soft fork is an addition, not a subtraction. We can add changes to the underlying protocol but not remove what was there otherwise it would invalidate blocks using the old rules. Consider the case we have a soft fork but then try to reverse it. In this case, all blocks and transactions created while the new rules were being implemented are invalidated. This has huge implications for example if the transactions are invalidated, so are the funds. In general, it is certain that a failed soft fork will lead to users losing funds.
It is much easier to write code from scratch than to make changes to existing legacy code, right? Soft forks correct bugs or add additional features to existing clients meaning they are more complex than hard forks since they have to work with the existing features, therefore they introduce technical debt. In that, the costs of the code being maintained increase because of the trade-offs made in the design. In other words, since these changes were not considered in the original architecture, there are chances of bugs and other security risks.
We said that a soft fork cannot invalidate nodes that don't upgrade. This means that old nodes will still view transactions created with the new rules as valid without the need of evaluating the new rules. This means that the old nodes are blind to the new rules and as such validate transactions based on their old rules.
A soft-fork / non-contentious fork is a forward-compatible change to the existing consensus rules that allow nodes refusing to change to continue their operations on blocks and transactions using the new consensus rules. Here upgraded nodes view blocks mined by non-upgraded blocks as valid and vice versa.
In Bitcoin, soft forks are been implemented based on the reinterpretation of NOP codes.
With soft forks, we have concerns such as technical debt, irreversible upgrades, and validation relaxation.