The 5 Pillars and 3 Layers to Enterprise Blockchain Solution Design

By Fran Strajnar, BNC

Originally published on Tabb Forum

The quest to find functional blockchain solution designs that can scale to enterprise requirements is at fever pitch. But neither public nor purely private blockchains meet the requirements of the financial services sector. Rather, a systemic approach that effectively provides two blockchains is required.

Unless you've been living under a FinTech rock, you would have noticed that blockchains are the hottest topic in the space today. The quest to find functional blockchain solution designs that can scale to enterprise requirements is at fever pitch.

After having reviewed countless “private blockchain” designs for the financial services sector, I have come to understand that most solutions are striving for a single cryptographic or mathematical solution to all key requirements (outlined below).

I believe a systemic approach is required. Instead of the everything-on-the-blockchain approach, we recognize the key considerations and layers involved, and build a solution design that addresses the correct requirements on the correct layers.

Requirements

Banks, FinTech entrepreneurs and legacy infrastructure providers such as IBM have requirements that far exceed public blockchains’ (e.g., Bitcoin) current capabilities.

For instance, with Bitcoin’s capacity today sitting at 220 million transactions per year, any substantial bank will single-handedly exceed this limitation.

When you start using blockchain transactions as a record and data-integrity management service, the number of transactions can quickly explode.

The problem with this unfolding thought-process of “Bitcoin can’t do it; we’ll build our own,” is the resulting “purely private blockchain” designs, which sacrifice security and immutability for scale and privacy.

(Some of) what is being explored today:

• Clearing & Settlement (ASX NASDAQ & various)
• Syndicated-Loans (R3 & many others in stealth mode)
• Smart-Contracts & Smart-Assets (SmartContracts.com, Tradle)
• Federated Bank Feeds & Federated Invoicing (Techemy.co)
• Payments (Swift, Ripple, Western Union & various)
• Digital Identity (Skucard, OneName & various)

Solutions vary in application, but they all share the same infrastructure design considerations, whether they know it or not.

Let’s take a look at key solution requirements.

The 5 Pillars of Enterprise Blockchain Solution Design:

1. Permissioned/Private. Writing records is exclusive to members; third parties can be granted read access, with the general public excluded. The permissions architecture goes beyond “access = everything” and allows third-party access to specific raw data, as deemed appropriate, for interoperability and application requirements.
2. Decentralized/P2P. Allowing for equal control over the shared database among all permissioned participants and of equal importance; distributing the number of full copies of the ledger to maximize the probability that there will always be a complete record in existence and available for those with permissions to access.
3. Immutability & Data Integrity. Records are guaranteed to be cryptographically secure, with no possibility for bad actors to threaten data integrity.
4. Scalability. The ability to secure trillions of transactions or records without compromising the networks synchronization, security, accessibility or data integrity.
5. Security. Support for data encryption and the management and enforcement of complex permission settings for participants and third parties.

How do we achieve all 5 pillars in a solution design?

Blockchain technology for enterprise applications, particularly for the financial service sector, needs to ensure it not only can scale, but comply with regulation, offer consumer protection through privacy and security, and meet a growing list of feature requirements.

Most private blockchain solutions build their own blockchain and end up offering vast scalability at the expense of solid immutability and security.

We propose, instead of a single mathematical or cryptographic solution, to take a systemic approach by offering effectively two blockchains: One acts as a private data-store, security and integrity engine; the other being public and incentivized, addresses the finality, security and immutability requirements.

Separating immutability from scalability considerations, solves several current blockchain design bottlenecks.

The outcome is a foundation that can service the demands of enterprise applications without compromising on one of the five key enterprise solution design pillars.

Let’s take a look at the three integral layers required and where each of the above 5 pillars is serviced.

The 3 Layers: #1 The Blockchain

Solution considerations of the Blockchain Layer:

• Used for: “Pointers”
• Pillars: #2 - Decentralized/P2P & #3 - Immutability & Data Integrity

The Blockchain Layer doesn’t need: Storage, Business Logic (complex permission structures), Data Storage, etc.

Instead of trying to achieve all five key pillars (solution design requirements) on one public network, we accept the fact that public blockchains are a terrible storage solution and will struggle to scale.

A public Blockchain is not Dropbox …

... nor is it a conventional database capable of running a billion-plus transactions per week. Therefore we will not see Bitcoin or Ethereum (as they are designed today) power global trade or the Internet-of-Things on their own.

“Pointers” or “hashes” (see: Merkle-Trees) are transactions that do not disclose any valuable information to the public, who can also access the open blockchains. However, for people or machines who know which addresses to track for a new hash, these pointers offer two uses:

1. Notification to a status change or new entry made on the secondary, private blockchain, in the next layer - The Data-Store Layer (see below); and
2. Validate the integrity of the data placed in said private chain.

Using only a purely private blockchain will result in a struggle to provide immutability. If Lehman Brothers built a blockchain and everybody used it, the company’s collapse would also mean a systemic network collapse and bring down all applications reliant on this private blockchain.

The epiphany: Use the strength and utility of open, distributed and incentivized blockchains for a part solution and complete the solution “off-chain” on a private distributed database designed for scale and business logic.

The 3 Layers: #2 The Data-Store

Solution considerations of the Data-Store Layer:

• Used for: Encryption, Business Logic (permission structures), Data Storage, etc.
• Pillars: #1 - Permissioned/Private, #4 - Scalability & #5 - Security

The Data-Store Layer doesn’t need: Open-Access or limited transaction payloads due to block sizes or other public blockchain constraints.

In our Enterprise Blockchain Design, very limited raw data is recorded on the public blockchain; the majority of data is recorded in a private data store that behaves like a distributed relational database. The data-store is then configured to auto-hash, in bulk, transactions sets onto a public chain, at any required interval, creating a merkle-tree-“receipt,” which notarizes and validates the full dataset hosted on the private data-store. We recently ran a proof using our Bitcoin Liquid Index, to create the world’s first Blockchain-Secured-Index, allowing us to power decentralized derivatives in a trustless manner.

The data-store is also capable of creating child-accounts (sub-data-stores), therefore offering deep business logic and complex permission settings.

This compartmentalization of data ensures the absolute security and privacy of participants’ full transactional data.

The 3 Layers: #3 The Application

Solution considerations of the Application Layer:

• Used for: Processing the first two layers into a useful business application.
• Pillars: None

The Data-Store Layer doesn’t need: Any of the Blockchain or Data-Store Layer functions or considerations.

The Application Layer is the “connector” into and out of the Data-Store (and from there, the public blockchain of choice, for the underwriting of data integrity).

The Application Layer can be anything – a bank’s front-end customer portal or a back-end lender’s portal for managing applications or repayments.

Conclusion

The key to viable Enterprise Blockchain Solution Designs is a systemic approach in which the five key pillars are separated into the correct design layers.

This approach not only will allow for rapid deployment of blockchain technology in enterprise solutions, it also will create a symbiotic feedback loop between public and private blockchains, which only diversifies design risk and increases interoperability, paving the way for second- and third-generation applications and entrepreneurs.

Of course, some serious development went into building the integral middle layer, “The Data-Store,” that we used in our proof of concept, but it is available for commercial use today.

Remember: Networks always end up demanding interoperability. Build well and build for the future.