Arguably, the biggest challenge blockchain developers face is how to extend the capabilities of the system they are working on. The two usual ways to upgrade the protocol are commonly called a soft fork and a hard fork. Both suffer from serious drawbacks. In fact, the difficulty of upgrading the protocol is probably what led the block size scaling debate to end so poorly.

Hard forks

Hard forks ensure that the protocol is upgraded by changing the rules enforced on the blockchain from a given block extending forward. The rules can be changed in a completely arbitrary manner and generally changes can be significantly simpler.

However, a hard forks require everyone to upgrade prior to taking effect. This is a very costly operation and requires a fully unified ecosystem. As the size of the ecosystem grows, this becomes more and more expensive to the point of being prohibitive.

In addition, a hard fork can lead to a chain split, which is highly undesirable, especially for exchanges who need to protect themselves against replay and are at risk of losing a fair bit of money.

Soft forks

Soft forks have the benefit of not requiring everybody to upgrade at the same time. The trick is to add rules to part of the protocol that existing software will consider valid regardless.

Doing upgrades in such a way is significantly simpler, but has a significant drawback that it drastically limits the design space of the new features. This results in a higher level of complexity and sometimes tradeoffs that one would not usually accept if designing the system from scratch.

Extension points

Other protocols and file formats usually have what is referred to as extension points. An extension point is a part of the protocol left for future versions to define. For instance, the PDF format supports various extensions such as a form filling feature. Any PDF software that doesn't support this feature will be able to display the form and warn you about the fact that this PDF is using some feature it doesn't know about. More advanced PDF readers will be able to to provide you the form filling features.

For it to be successful, an extension to the protocol needs to provide a graceful degradation path. What do software that doesn't know bout the extension should do when encountering it ? Ideally, it needs to be able to do something that makes sense. It needs to degrade gracefully.

Extensible blockchain protocol

Creating an extensible blockchain protocol require it to have well defined extension points and a method to gracefully degrade them. Creating an extension point is in itself a hard fork, and therefore should be done as soon as possible in the life of a blockchain. In this article, let's assume we hard fork to change the output of a transaction to be made of a version field and a hash. The meaning of the hash is dependent of the value of the version field. The protocol can define a version for P2SH and for P2KH, and reserve all the remaining versions as extension points.

When a new feature is introduced in the protocol, a new version number can be used. The new software knows what this new version number means and how to validate its use. But what should old software do when an extension point it doesn't know about is used?

When encountering a version it doesn't know about in a transaction output, a node cannot decide if this transaction is valid or not. It can only verify that the transaction is using some feature that it doesn't know about. We already can ensure graceful degradation: the node can still check that the amounts in the inputs and outputs checks out and continue to maintain the UTXO set. It is, however, unable to validate that a TXO using a new version is appropriately spent.

In such a situation, the node can do a variety of things such as excluding itself from the network requesting its operator for an upgrade, simply continue to operate without validating these specific spend, or maybe chose an intermediary solution such as waiting for PoW to accumulate before accepting such a spend as valid.

Why are extension points superior to both hard and soft forks?

Extension points remove many of the design constraints associated with soft forks. A new feature can do whatever is desired provided it does not invalidate previous consensus rules. Upgrades need not conform to existing protocol rules, as an extension point can define new features in a way which can degrade gracefully. In addition, it provides a way to notify the rest of the network that new consensus rules are in effect, rather than fool old nodes as in the case of a soft fork. Every participant is aware that a new feature rolled out and can act accordingly.

In addition, extension point ensure that not everyone has to upgrade at once. It is possible for the old software to operate in SPV mode, exclusively for anything related to a new feature, while continuing to validate everything else properly. Extension points also ensure that a chain split will not occur.

How do extension points affect miners?

As far as miner are concerned, there is no such thing as a soft or hard fork. If they do not produce a block that the network will accept they are losing money. Miners are strongly incentivized to go with the flow, this is a feature of the network, which means they must upgrade on time.

As such, miner will want to activate a new extension point only when they are sure most of the network is ready to accept them. If they do not, then their blocks will become worthless and they will change their behavior accordingly.

On the other hand, using a PoW based acceptance is a very nice security feature for miners. This ensure that a miner who forgot to upgrade its software for some reason will cut its loss. Just like a security belt or an airbag, you sure hope you won't use it, but you are glad you have it.

Conclusion