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 this series, I’d like to evaluate and explore the value of blockchains in the enterprise, and the obstacles that most enterprises face in adopting a blockchain strategy. This will be a comprehensive study of all the issues that surround the adoption of blockchains in the enterprise.

Enterprises have very unique requirements when it comes to blockchains. Of course the appeal of having a shared ledger in which one party does not need to be the sole administrator nor supporter of the network is very appealing. There is much potential to saving costs and also removing a whole class of errors that could occur in a system that is centrally administered.

This article will discuss the considerations of enterprise blockchain use, starting with the general classes of blockchains and distributed ledgers that are under consideration and their ideal use cases, the tradeoffs that the different blockchains make in comparison with traditional databases, and finally, the unique considerations that any enterprise must consider when evaluating whether or not to utilize a blockchain strategy.

The different types of blockchains

Private or public ledger?

The issue of whether or not to use a public or private ledger is the most fundamental question that your enterprise needs to grapple with. They are fundamentally different in terms of the use case that they address. Private blockchains or permissioned blockchains (shared within a group of trusted parties) are more synonymous with a multiparty shared database, with a signed transaction history. Therefore we will mostly be speaking about permission-less blockchains, such as Bitcoin, Ethereum or Ripple. It is worth mentioning that each of these blockchains have different degrees of permission-less participation, which we will speak more on later.

Do you need your data to be publicly verified? Or do validators need to be approved by a central authority? The answer depends on whether or not you want to have central administrative control over the ledger, shared control, or no control? Are you interested in blockchains simply because of their fail-over data resiliency? Should the costs of the infrastructure be shared between participants? Or run for free by the network itself?

Permissioned vs permission-less blockchains

Most of the time when dealing with enterprises with an existing association of partners, a permissioned blockchain is sufficient as the information need not be trusted beyond the closed circle of validators.

In the case where the information needs to incorporate outside information or tokens, then the use of a permission-less blockchain is more appropriate as the possibility of atomic swaps between asset tokens on the public blockchain will greatly simplify settlement in tokens other that the native one.

What are the benefits of permissioned blockchains? For one they have very fast transaction finality. Ledger inconsistencies can be resolved by a quorum of the validators.

By comparison, permission-less blockchains due to their lack of coordinated governance, their consistency is only eventually guaranteed, but not immediately guaranteed. Some permission-less blockchains have come very close to rivaling the finality of permissioned ones, by way of sacrificing some other aspects of the design.

As all of the aforementioned blockchains (or more correctly termed distributed ledgers, as Ripple and Stellar are not blockchains) are ostensibly permission-less to a degree, we should examine the differences between each in terms of their permissioned status.

Bitcoin (Bitcoin Cash):

1. Permission-less validation
2. Permission-less participation
3. Infrastructure is self-supported by validators through built-in economic model
4. Highly available
5. Highly partition resilient
6. Eventually Consistent (~10m)
7. Highly Scalable

Ripple (Stellar)

1. Somewhat Permission-less validation
2. Permission-less participation
3. Infrastructure is funded by participants and validators alike.
4. Highly available
5. Somewhat partition resilient
6. Highly consistent
7. Somewhat Scalable

Ethereum:

1. Permission-less validation
2. Permission-less participation
3. Infrastructure is self-funded by validators through built-in economic model
4. Highly available
5. Highly partition resilient
6. Very good consistent (~30sec)
7. Poor Scalability

In a chart summary:

You can see that depending on the needs of the enterprise, the different blockchain technologies may be appropriate. All of the above technologies are permission-less, but they all make some tradeoffs to achieve this. If your enterprise needs a solution that is highly available, consistent, partition resistant and scalable then the best solution is to run a completely private database system, which is accessible only by permissioned users.

Bitcoin:
Bitcoin is the base line for comparison as it was the first blockchain. It sacrifices some consistency for the fact that only validators need to run full network nodes and the fact that the validators need not coordinate with each other. It sacrifices scalability in exchange for keeping the requirements for running a full network node low, so that participants still have the option to keep the whole ledger, without being validators for the network. Attempts to make up for the scalability sacrifice by pushing transactions to off-chain payment channel networks such as Lightning.

Bitcoin Cash:
Bitcoin Cash is largely the same model as Bitcoin with the exception that it does not sacrifice forward scalability for the option to cheaply run full network nodes by network users. Instead it focuses on the use of SPV (light) clients which only validate their own transactions, for users, and only network miners need to run full nodes (although many businesses such as exchanges may still opt to).

Ripple:
Not a blockchain proper, but a distributed ledger. Partition resistance is sacrificed for high consistency (within a partition). Nodes keep a list of the other nodes that it knows about and trusts and only messages from those nodes which are on the trusted list are validated and further passed along to a node’s peers. Therefore, the most efficient network topology of a Ripple network would be a group of nodes which all trust each other. (This is the same for a Bitcoin network of miners). Scalability suffers somewhat by the fact that there are no light clients, and all clients need to be consistent and in sync with the rest of the network in order to create a transaction. There is no such thing as an offline transaction creation. (Therefore removing some use cases where the offline creation and private sharing of transactions may be useful). Ripple is unlike the other blockchains evaluated because it does not have a native economic model. Its native token is a virtual token created privately and distributed to partners of Ripple Labs directly.

Ethereum:
A cross between Bitcoin and Ripple, it shares the same general validation model as Bitcoin (mining) though developers want to transition it to be a staked system. (With time locked bonded stakes earning the right to validate and earn inflation interest). Ethereum was initially planned to be a smart contract layer on top of Bitcoin, but due to the restrictions that the BTC core developers put onto the system the founders of Ethereum decided to create their own blockchain and fund the development with an ICO of its own token network instead. Ethereum sacrifices forward scalability for flexibility in smart contract expressivity, enforcing that every validator execute every smart contract code independently and redundantly.

Economic model? Or just a ledger infrastructure?
Does it matter if the blockchain has its own economic model? Most permission-less blockchains come with their own economic model, that is because of the decentralized nature of the validators (miners in a PoW system) there must be a way for the validators to be reimbursed for their resources committed to building out the network infrastructure. For a permissioned blockchain this is not necessary, nor even desired. Any economic model (such as controlled distribution of native tokens) is normally controlled out-of-system. This is acceptable because there is an implied level of trust between the validators and their cohorts. Normally the native token in such a system, has little intrinsic value beyond that of a utility token for the use of the network paid by the participants who do not contribute infrastructure themselves.

Transaction immutability or reversibility
Do you need the transactions to be irreversible? (If no, then evaluate whether or not your business case can be served with just a database. If you need immutability then the permissioned blockchain will do if you are okay with the notion that transactions are only as immutable as having the verifiers of the blockchain agree on changes. Permission-less blockchains will have validators or miners which are operating under their own economic model which is separate from your business, and thus would be effectively immutable.

Validators vs miners
Distributed ledgers have validators. The same role is performed by miners in a blockchain. The difference between the 2 is that validators are necessarily participants in the network as primarily users, (albeit likely large ones), while miners operate as their own businesses with their own economic model.

This provides for a measure of isolation for the businesses that want to use the blockchain, because you can be relatively certain that the miners will act independently and in their own best interests, instead of interfering with users. In fact, the economic model of mining on blockchains is such that miners which are seen to be violating the consensus rules or even social ones can be easily identified, and the network will penalize them. This is much harder to detect in distributed ledger systems, as the validators do not publish a proof of their work in a form which is public and transparent for the world to see. It would be much more difficult to determine if a cartel of validators were to deliberately censoring certain transactions from certain users.

This concludes the overview of the blockchains technologies which are popular considerations for enterprises, and gives a sufficient introduction to the general characteristics of each. In part II of this series, I’ll explore some of the common application use cases that enterprises look for and evaluate how each of the technologies fairs in these applications in turn.

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post Blockchains in the enterprise: The different types of blockchains appeared first on Coingeek.