There has been a fierce debate going on in Bitcoin space about how to upgrade the protocol. Currently the maximum block size, which represents the throughput for the network is set to 1 MB. There have been arguments to hard fork the protocol to increase the throughput.
What exactly is a hard fork?
I think the easiest way to think about a hard fork is thinking of a mathematical set with elements in it. The elements inside of this set represent consensus rules for the Bitcoin network. Whenever an element is removed from this mathematical set, it is a hard fork. When ever an element is added to the set it represents a soft fork. Here is an illustration of some current consensus rules in the bitcoin network:
Now, an example of hard forking the protocol is removing one element from the set of consensus rules. So an example of a hard fork would result in this mathematical set of consensus rules
This represents hard fork that sets an unlimited (!) block size.
We can also hard fork the protocol by making the making a consensus rule less restrictive. For instance, we can make the amount of possible coins on the Bitcoin network be 22M coins.
Notice though, if I were to have arbitrarily decided to remove all of the rules from the protocol (!!) this hard fork would be equivalent in terms of violating invariants promised by the Bitcoin protocol. When a hard fork is deployed to the network, all bets are off. Anything can be changed. If the economic majority agree with the change, you are forced to follow the change or have your Bitcoin become worthless.
What exactly is a Soft Fork?
Let’s go back to looking at this set of consensus rules:
One example of a soft fork is modifying the existing consensus rules to make a particular rule more restrictive than what was previously stated in the mathematical set. For instance, we could modify the block size to be less than what it previously was:
Another example of a soft fork is adding an entirely new consensus rule to the set of consensus rules. For instance, this could be a new op code. We have used this process to deploy OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY:
The reason this works is because OP_CLTV and OP_CSV are repurposed OP_NOPs. What that means is the previous op codes did nothing. Since they did nothing, we could make them have new consensus meaning. Now, if an old node that does not understand OP_CLTV/OP_CSV sees it, it always assumes it is valid. However, if an upgraded node sees it, it applies the new consensus rules specified by BIP65/BIP112. Therefore we restricted what was previously valid in Bitcoin.
TLDR: Soft forks preserve promises that initially made Bitcoin great. Hard forks decimate those promises and resurrect new ones, which can literally be anything.