Hard forks vs soft forks

Development and Technical Discussion
1

Some time ago I’ve read a good argument why soft forks are not as good as people think and I think it’s important to share it so that we have a better understanding of them and can debate their usefulness. Everything written bellow this line is copied from here.

Hard Forks Preferred

The two primary methods for updating consensus rules are commonly referred to as soft forks and hard forks. The key difference between the two methods is that soft forks involve changing the rules in a way that older nodes are not aware that the change has happened whereas hard forks require older nodes to upgrade in order to continue following the chain and therefore are fully aware when the rules have changed.

This ability to trick older nodes into believing they are faithfully validating every transaction when in reality they are not completely undermines the primary reason for running a fully-validating node. In some scenarios, it enables a certain class of attacks against people running those out of date nodes by taking advantage of the fact they are not actually validating things according to the latest consensus rules.

The main takeaway is that hard forks are the preferred method and the Decred voting process allows stakeholders to seamlessly choose which side of a hard fork is the agreed upon winner in a transparent and cryptographically-provable way.

Here’s another good explanation from Dave in one of his comments on the same page:

… what advantages if any are there to a soft-fork capability remaining in play?

I am personally of the opinion that there are none because all of the advantages that are typically attributed to soft forks are either outright incorrect due to a misunderstanding of what is actually going on or are misrepresentations that ignore important security aspects.

For example, a claim I have seen repeated extremely often is that soft forks are backwards compatible while hard forks are not. This is entirely incorrect! Backwards compatibility is the ability for newer systems to interoperate with older systems. When it comes to cryptocurrencies and full nodes, regardless of whether a hard fork or soft fork is used, all newer versions of the software must necessarily be backwards compatible or they wouldn’t be able to fully validate historical blocks nor would people be able to spend coins created in older versions. Backwards compatibility is an absolute requirement no matter which method is used.

What soft forks actually provide that hard forks do not is forwards compatibility. That is to say the ability of older systems to accept input created by newer versions of the system. In the context of cryptocurrencies and Decred specifically, that means older versions of the software would still able to follow the chain with the most Proof-of-Work. On the surface, this might sound like a desirable property, but it really is not, because it undermines the very rules that make cryptocurrencies trustless and safe to begin with! When you are running an old version of a node under a soft fork, you are delegating trust to a 3rd party, namely to people running the newer versions of the software, instead of actually verifying everything yourself while simultaneously not even being aware that is what you’re doing.

5 Likes
2

That’s a very good point. The old nodes preserve the same validation rules, but these are now only a subset of all the rules the new nodes have. I’d also prefer a hard fork over a soft fork if one was necessary, it requires more coordination, but it seems like a cleaner procedure - though these should be minimized.
Soft forks still have some merit though. If you want to have a system that follows at least rules S, then soft forking guarantees this constraint will still hold.

3

Would be an interesting case If a soft fork gains the majority (51% POW) for a while, and then later loses it, and runs as a minority or dies.

4

I can’t think of a case where you would want to have this. All participants must know all of the rules imo, it’s cleaner, seems safer and probably easier to argue that things work as expected

5

A soft fork comes with a guarantee for all participants that they’ll still be able to validate the set of rules their node contains. But I do agree all forks are problematic and some things would be better off when done as a hard fork. I also believe the protocols will eventually ossify where not even soft forks will be possible to pass once the whole ecosystem and architecture spreads far enough (including Bitcoin). But we’re far from that right now. For what it’s worth, I think Grin avoids a lot of possible hard fork suggestions because it doesn’t have a scripting language on chain. This avoids a lot of the drama and politics other communities have to go through when people propose a new opcode.

6

Sure but what’s the point if that’s not a complete set of rules?

7

There’s some value into having a guarantee that you won’t change the existing rules. It makes a subset of rules predictable and such protocols should be predictable. But I do agree that everyone having the exact set of rules is the optimal outcome.