“Blockchain Not Bitcoin”: Unwrapping Enterprise Blockchains

The first thing many people think when they hear the term blockchain is Bitcoin. Some may think about Ethereum and fewer may reference newer altcoins though it’s important to take a step back and recognize that cryptocurrencies aren’t the only use case for blockchain-based technologies. There are a multitude of benefits that traditional enterprises can take advantage of from the implementation of an untokenized blockchain solution. SAP, IBM, Deloitte, Nasdaq, General Motors and R3 among other companies are at the forefront of these solutions, and within this article, we hope to shine some light onto the different blockchains that they’re leveraging.

Past Experience and Takeaways

At Fitzner Blockchain, our experience has largely revolved around new clients hoping to incorporate a blockchain for the promise of a unique fundraising vehicle, primarily an Initial Coin Offerings (ICOs) or Security Token Offerings (STOs). In the large majority of these implementations, the “use-cases” have been centered around a tokenized incentive layer rather than an underlying blockchain that improved the efficiency, security and/or immutability of shared datasets.

As we continue to have entities new to the space coming to us for our ability to explain blockchain, it’s increasingly clear that the benefits of this technology are still very difficult for the average for the general public to understand. Over the course of this article, we will introduce the concept of enterprise blockchains and the companies responsible for creating them. Additionally, we hope to identify how consensus is achieved in the absence of an incentive layer.

*For those of you who are also interested in unpermissioned public blockchain solutions for enterprise clients, stay tuned for our upcoming articles.

What is an Enterprise Blockchain?

An Enterprise Blockchain can most commonly be classified as a permissioned blockchain that sacrifices decentralization for performance and privacy.

While there are rare edge cases where an enterprise may seek to decentralize their infrastructure, most traditional companies exploring blockchain integration have long been accustomed to permissioned systems, i.e., a system in which access is limited to a clearly defined and chosen set of actors.

Benefits of Permissioned Blockchains

A permissioned blockchain allows the issuing entity to appoint a specific group of participants (nodes) the authority to validate transactions and propose new blocks. By hand-selecting validators, the issuing entity benefit from peace of mind that all validators are trusted, identifiable parties.

As we’ve seen during times of conflict and their subsequent hard forks, governance can quickly become a major issue when relying on participation from an entirely decentralized system to transition to an “improved” system (with Ethereum’s transition to Proof of Stake being the perfect example). To this point, permissioned blockchains can allow for efficient governance within their own consortium.

As companies quickly adapt and shift to new demands, it’s important that their underlying systems can be easily optimized. By using a permissioned blockchain, enterprises can quickly reach consensus to implement new upgrades without having to rely on a general decentralized public to come to a majority agreement.

Now that we’ve taken a look at a few benefits from permissioned blockchains let’s take a deeper look at some of the most notable companies creating them.

Who Are Most Popular Enterprise Blockchain Providers?

R3’s Corda

Built in 2016, the Corda Platform, R3’s open source blockchain platform, was created to provide an industry-level system of immutable records. Corda creates trust through code, particularly between big banks, that would otherwise be speculative. Their platform also removes costly friction in business transactions by enabling institutions to transact directly using smart contracts while ensuring the highest levels of privacy and security. From its inception, Corda was built specifically for business.

Unlike other designs in this space, Corda’s starting point is individual agreements between firms (“state objects,” governed by “contract code” and associated “legal prose”). Corda rejects the notion that all data should be copied to all participants, even if it is encrypted.

Secondly, Corda is focused on the need to link legal agreements from inception. Corda acknowledges there will always be disputes and attempts to specify how to settle problems from the start of each agreement.

Most importantly, Corda was built to make it easy to write business logic and integrate with existing code. Corda focuses on interoperability and is intended to support the choreography between firms as they build up new partners and financial agreements.
To date, R3 has partnered with major financial institutions including but not limited to: ING, BBVA, Bank of America, Barclays and Citibank.

Key Features:

• Corda achieves consensus between firms at the level of individual deals, not the level of the system
• Corda only shares information between parties with a legitimate need to see the data within an agreement
• Corda’s design directly enables regulatory and supervisory observer nodes
• Corda choreographs workflow between firms without a central controller
• Corda has no native cryptocurrency
• Corda transactions are validated by parties to the transaction rather than a broader pool of unrelated validators
• Corda supports a variety of consensus mechanisms
• Corda records an explicit link between human-language legal prose documents and smart contract code

Consensus

Corta’s consensus is split by validity and uniqueness. To be committed, transactions must achieve both valid and unique consensus. It’s import to note that Corda was intentionally designed for consensus to be customizable and has many different applications. Once a transaction has achieved both forms of consensus, it is reviewed and signed by a notary and added to the chain.

Validity consensus

Validity Consensus checks that the following conditions hold for both the proposed transaction and for every transaction in the transaction chain that generated the inputs to the proposed transaction:

The transaction is accepted by the contracts of every input and output state
The transaction has all the required signatures

It is not enough to verify the proposed transaction itself. Validity consensus must also verify every transaction in the chain of transactions that led up to the creation of the inputs to the proposed transaction. This is known as “walking the chain.”

Suppose that a party on the network proposes a transaction transferring a treasury bond. Corda will only be sure that the bond transfer is valid if:

The treasury bond was issued by the central bank in a valid issuance transaction
Every subsequent transaction in which the bond changed hands was also valid

The only way to be sure of both conditions is to walk the transaction’s chain. This process is visualized as follows:

When verifying a proposed transaction, a given party may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer(s). The transaction proposer(s) will always have the full transaction chain since they would have requested it when verifying the transaction that created the proposed transaction input states.

Uniqueness consensus

Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. If one or more of the inputs have already been consumed in another transaction, this is known as a double spend, and the transaction proposal is considered invalid.

Imagine that Bob holds a valid central-bank-issued cash state of $1,000,000. Bob can now create two transaction proposals:

A transaction transferring the $1,000,000 to Charlie in exchange for £800,000
A transaction transferring the $1,000,000 to Dan in exchange for €900,000

This is a problem because, although both transactions will achieve validity consensus, Bob has managed to “double-spend” his USD to get double the amount of GBP and EUR. This is visualized as follows:

To prevent this, a valid transaction proposal must also achieve uniqueness consensus. As described above, once a transaction has achieved both validity and uniqueness, it is signed by a notary and added to the chain.

HyperLedger

Hyperledger launched in 2016 as an open source collaborative effort created to advance cross-industry blockchain technologies with a technical and organizational governance structure and 30 founding corporate members. This global collaboration, hosted by The Linux Foundation and hundreds of other organization can be thought of as a larger scale operating system for marketplaces, data-sharing networks, micro-currencies, and decentralized digital communities.

Hyperledger hosts a multitude of permissioned blockchain frameworks and tools for entities to leverage blockchain technology. Existing frameworks include but are not limited to: Hyperledger Burrow (Permissioned EVM), Hyperledger Fabric (Modular Architecture), and Hyperledger Indy (Decentralized Identity).

The Hyperledger community is focused on the development, deployment, and use of open, transparent, reliable and interoperable enterprise blockchains. For this reason, Hyperledger Fabric was chosen as the foundation for the IBM Blockchain Platform along with support from SAP’s HANA Blockchain service.

HyperLedger Burrow

Burrow uses the Tendermint consensus engine whereby transactions are ordered and finalised by a deposit-based Proof of Stake Engine. Tendermint is a Byzantine Fault Tolerant consensus algorithm which provides high transaction throughput over a set of permissioned validators along with instant-confirmation finality.

HyperLedger Fabric

Fabric leverages Apache Kafka to reach consensus. Kafka is a permissioned voting based consensus algorithm where the leader does ordering and only in-sync replicas (nodes) can be voted as the leader. Apache Kafka provides crash fault tolerance and finality is able to occur in seconds. However, Kafka is not Byzantine Fault tolerant which prevents the system from reaching agreement in the case of malicious or faulty nodes.

HyperLedger Indy

Indy uses Redundant Byzantine Fault Tolerance (RBFT) to reach consensus. RBFT is a permissioned voting-based strategy with a pluggable election. All instances do ordering but only the requests ordered by the master instance are actually executed. RBFT naturally provides Byzantine Fault Tolerance with finality happening in seconds. However, the more nodes that exist on the network, the more time it takes to reach consensus.

HyperLedger Sawtooth

Sawtooth utilizes Proof of Elapsed Time (PoET) to reach consensus. PoET is a pluggable election strategy set to a permissioned, lottery-based strategy. PoET provides a highly scalable consensus algorithm while also Byzantine Fault Tolerant. However, finality can be delayed due to forks that must be resolved.

J.P. Morgan Chase’s Quorum

Quorum is an Ethereum-based enterprise blockchain solution built by J.P. Morgan Chase that provides the financial services industry with a permissioned implementation of Ethereum to support transaction and contract privacy. Quorum is ideal for any application requiring high throughput for processing private transactions within a permissioned group of known participants.

Quorum is almost identical to Ethereum, but with four major distinctions: permission management, increased transaction, and contract privacy, voting-based consensus mechanisms, and higher throughput.
While signature validation in a permissioned network adds peace of mind not present in anonymous networks, Quorum doesn’t compromise on distributed block validation, creation, or a single chain architecture.
Quorum is GPL/LGPL licensed to ensure that the platform will be free to use in perpetuity and encourages experimentation. Additionally, Quorum was designed to develop and evolve alongside Ethereum. Seeing as it only minimally modifies Ethereum’s core, Quorum is able to incorporate the majority of Ethereum updates quickly and seamlessly.

Consensus

Quorum offers multiple consensus mechanisms which better fit consortium chains. Due to the highly technical documentation regarding these consensus protocols, interested readers can find further details here.

Raft-Based Consensus

The Raft consensus algorithm is useful in close permissioned systems where Byzantine Fault Tolerance isn’t required. In this consensus, there is a leader/follower model among a cluster of nodes in which all blocks are created by the leader. As a result, there is an inability for the network to fork and ensures instant finality on all transactions.

A leader is elected following a period of voting in which all nodes in the cluster participate. Once elected, all other nodes assume the position of a follower in which they verify transactions flowing through the network.

Istanbul BFT (Byzantine Fault Tolerance)

The Istanbul BFT consensus algorithm is inspired by the PBFT consensus algorithm where there are no hard forks and all blocks are final. Through this consensus model, the network can tolerate up to ⅓ of validators being faulty while still having instant transaction finality. In this system, the nodes are either validators or proposers with a periodic consensus round where validators in the network elect a “proposer” who has the right to mint new blocks onto the blockchain.

Conclusion

With the majority of retail discussion surrounding blockchain platforms being focused on platforms that use a tokenized incentive layer (Ethereum, EOS, Stellar, NEO, Ontology, etc.) we believe that traditional enterprises will feel more comfortable working with systems that can easily adapt to their existing systems.

While we recognize the future potential for new startups to leverage a tokenized incentive layer to expedite adoption, in the large majority of short-term use cases we envision enterprise solutions being much more appealing than a permissionless, decentralized platform in which the large majority of a firm’s data is encrypted and made public to individuals who don’t need to access or see it in the first place.

Additionally, in the case of a platform like Ontology being able to offer private solutions, we believe that the presence of an advanced token system to facilitate transactions will be a barrier to entry as the industry continues to mature. In short, we believe that most traditional enterprises would not be comfortable with purchasing native cryptocurrencies to fuel their underlying systems.

In our next follow-up piece, we will examine a handful of industries benefiting from enterprise solutions provided by the companies listed above. In this sense, we hope to shed some light on the long-term potential for blockchain outside of the realm of cryptocurrencies that had become vastly popular among a largely retail-oriented demographic.

Writers: Cooper Turley — https://twitter.com/Cooopahtroopa
Lucas Campbell — https://twitter.com/0x_Lucas