Blockchain and Enterprises Part III

Getting your Trinity Audio player ready...

This is a guest contribution by Jeri DeBitto. If you would like to submit a contribution please contact Bill Beatty or submission details. Thank you.

In the previous articles, I spoke on the technical scalability and the smart contract aspects of the different blockchains that an enterprise may consider.

In this installment of Blockchain and Enterprise, I’d like to talk more on the necessary conditions and characteristics that make a blockchains a viable prospect for the Enterprise to even consider in terms of use, namely that of stability.

I’m not talking about the kind of stability in terms of the network performance, I’m speaking more about the stability in terms of the protocol changes themselves.

The biggest obstacle to mass adoption of public blockchains for enterprises is the fact that the developers are not controlled or beholden to contracts, the protocol, due to its decentralized nature, can change outside of the enterprises control.  This is a very undesirable quality from the enterprise perspective.  Coming from working 10+ years in an enterprise development environment, I can tell you that these internal projects can take a long time.  Coordinating all the work between many teams, planning a smooth decommissioning project of an old enterprise system in a way that does not disrupt the flow of business, can be a very challenging task.  The last thing that any large company needs is another potential highly disruptive variable that will change their project plans, and cause delays which would cost them millions.  In public blockchains this is always a possibility because the platform rules are not controlled by any dev team, but the the collective consensus of the miners in the system which may be pseudo-anonymous.

We saw the problem with this model in the last large blockchain fork in BCH, between BAB and BSV.  Both sides had ideological differences, and because of this the protocol forked and so did the ledger, causing all companies that used it to have to pick sides, and also to possibly do some emergency business process changes in order to handle the split fork to ensure that their customers didn’t lose any money.

This is why a focus, nay, DOGMATIC adherence to the model that the base protocol should rarely ever change should be adopted.  This will indeed be counter what many developer groups in blockchains would advocate for, but then, of course they would, as constant regular hard fork (non-backward compatible) upgrades does keep all the developers very well paid and gives them job security.

Of the public blockchains, only Bitcoin, Bitcoin Cash, Ripple, Ethereum have experienced major splits, (creating BCH, BSV, Stellar, and ETC in the process) and these were very disruptive.  Of those, the BTC/BCH fork, BCH/BSV, and ETH/ETC forks were the most disruptive, given the amount of businesses that were using the chain at the time and the need for transactions to have to be preserved and ecosystems to be rebuilt.  While the ETH/ETC split was caused by the desire to claim back the stolen DAO funds, the Bitcoin splits were all centered around ideological differences on the need to have upgrades themselves.

BTC/BCH fork:

This fork was caused by one side being adament that hardfork (non-backward compatible) changes should never be done deliberately, and those that felt that a change was necessary to remove the 1mb block cap limit that was put into Bitcoin by Satoshi as a safety measure that made sense at the time (and wrote how it should be removed later).  This was really a split that was required, as one side had developers wanting to change and add sidechains and LN in order to fulfill the goal of Bitcoin as it was unable to fufill it natively (due to the limits put onto it), and the other side had developers wanting to return Bitcoin back to the way it was intended to be, which was scaling of the mining hardwares and ecosystem.

BCH/BSV fork:

This fork was interesting, because many have said it shouldn’t have happened and could have been avoided.  This split was because of the group that split away from BTC because they actually want to scale Bitcoin by changing the protocol, we had two fundamentally different groups.  One which wanted to have regular hard fork upgrades so that they could continuously add new features and innovative scaling technologies, and another one that wanted just to return the protocol back to the original design (as the BTC developers disabled many features in Bitcoin since 2011) and allow it to scale economically.  Thus precipitated the BCH/BSV split.  The result was very costly for all parties and played a big part of the late 2018 price crash and deflation of the crypto market as a whole, but now for the first time since 2011 we have a Bitcoin project that represents stability and the desire to keep all unnecessary changes out of the protocol.  This is genuinely a unique time as we can now possibly get to see what Bitcoin was meant to achieve if it was given its full potential to grow naturally.

In conclusion of this series, the enterprise concerns surrounding the use of blockchain platforms revolve around the predictability of the protocol changes, and minimizing those as much as possible.  There is a certain value to a system that just works without too many disruptive upgrades which uproots all the systems that have been written on top of it and may depend on it.  The best example that is often cited is that of IP. Only after IPv4 was standardized, did the internet start to grow, and the World Wide Web was created on top of it.  Prior to that, there were many different network protocols which never achieved that level of ubiquity, such as Novell, Framerelay, ATM.  But only by standardizing on a stable protocol did it foster real world uses to be built on top of it and we own very much everything that we know today to IP and how proponents resisted the urge to make IPv5 or IPv6 upgrades mandatory.  Indeed, even though IPv6 was adopted as a standard, even now it is still an option choice and nobody is forced to use it.  That is the way that blockchains should be.  Especially given its primary role as a global ledger writable by all, Bitcoin cannot afford to have too many disruptive global upgrades that could stand to leave those who do not upgrade left behind on a ledger which nobody recognizes anymore.

Finally, we get to see that simple idea in action and whether or not it can actually be used to change the world.