The 5 Pillars and 3 Layers to enterprise blockchain solution design

Fran Strajnar is an entrepreneur, early bitcoin adopter and Blockchain enthusiast. Co-Founder & CEO of Techemy Ltd, the parent company to BraveNewCoin.com & Techemy.co**This article was originally posted on Linkedin

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, which 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 an ‘everything-on-the-Blockchain’ approach. We recognize the key considerations and layers involved, and addresses the correct requirements on the correct layers.

Requirements:

Banks, FinTech entrepreneurs and legacy infrastructure providers like IBM have requirements which far exceed Public Blockchain’s (bitcoin’s) current capabilities. For instance, with bitcoin’s capacity today sitting at 220m transactions per year, any substantial bank will single-handedly exceed this limitation.

When you start using transactions as a record and data integrity management service, the number of transactions can quickly explode, ie notarization to prove the existence or authenticity of a record/document and its status.

Once we start factoring in business logic, consumer-protection and privacy laws, the need for permission structures becomes obvious, and makes public Blockchains somewhat less appealing.

The problem with this unfolding thought-process, of bitcoin can’t do it so we’ll build our own, has resulted in Permissioned Blockchain designs, which sacrifice security and immutability for scale and privacy.

(Some of) what is being explored today:

• Clearing and Settlement (ASX, NASDAQ)
• Syndicated-Loans (Numerous Independent banks, R3 consortium)
• Smart-Contracts and Smart-Assets (Tradle, Wave)
• Federated Bank Feeds and Invoicing (Techemy.co)
• Payments (Swift, R3, Western Union)
• Digital Identity (Skucard, OneName)

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, 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, between all permissioned participants, and of equal importance. Distributing the number of full copies (nodes) of the ledger to maximize probability that there will always be a complete record in existence and available for those with permission to access.

3. Immutability and Data Integrity

Records are guaranteed to be cryptographically secure, with no possibility of bad actors threatening 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, requires this core set of functions, the five pillars, in its solution design. These functions will ensure that the solution can not only scale, but comply with regulation, offer consumer protection through privacy and security, and meet a growing list of feature requirements. Typical solutions often fall short on 1-2 of the above 5 key requirements.

For example, and perhaps contrary to some thought-processes evident in various solution designs today, building on the bitcoin Blockchain is currently the best chance of longevity. Bitcoin has the biggest network effect and an excellent monetary incentive for transaction processors to keep updating and verifying records, all baked-in.

However, it does not currently allow for the transaction volumes, permission settings and data-storage/sharing requirements of enterprise companies. This is often looked at as a ‘shortfall’ of bitcoin’s own solution design. Most private Blockchain solutions are built on 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 effectively offering two Blockchains. One acts as a private data-store, security and integrity engine. The other being public and incentivized, addressing the finality, security and immutability requirements.

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

The outcome is a foundation which can service the demands of enterprise applications without compromising on one of the 5 key enterprise solution design requirements.

Let’s take a look at the 3 integral layers required, and where each of the above 5 pillars fit in.

The 3 Layers: The Blockchain

Solution considerations of the Blockchain Layer:

• **Used for: ‘**Pointers’
• Pillars: #2 – Decentralized/P2P, and #3 – Immutability and Data Integrity

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

Instead of trying to achieve all 5 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 + 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 which do not disclose any valuable information to the public, who can also access open Blockchains like bitcoin. However, for people or machines that know which addresses to track for a new hash, these pointers offer 2 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).

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 have meant a systemic network collapse, affecting all applications built on such a private network. There would be no bailouts in this scenario.

This is the epiphany I hope you take away: Use the strength and utility of bitcoin’s open, distributed and incentivized Blockchain for a part solution, and complete the solution ‘off-chain’ on a private distributed database designed for scale and business logic. The high probability that at least 1 node with full ‘pointer’ history will exist in the distant future makes bitcoin, in particular, the preferred choice, but our technology can work with any blockchain if required.

The 3 Layers: The Data-Store

Solution considerations of the Data-Store Layer:

• Used for: Storage, Business Logic (permission structures), Data Storage, etc
• Pillars: #1 – Permissioned/Private, #4 – Scalability and #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 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 configured to auto-hash transaction sets onto the public chain in bulk, at any required interval. We recently hashed 1.9m data points, which make up the historic component of our Bitcoin Liquid Index, onto the blockchain with a single hash. To keep it updated we hash an additional 120 points via 1 small bitcoin transaction per hour.

This means the scaling part happens on the private chain, reducing the costs inherent with public blockchain transactions. The data-store is also capable of creating child-accounts (sub-data-stores) and separating data into various child-accounts as required. This business logic (complex permission settings) is again ‘baked-into’ our solution design by default, on the data-store layer, and is imperative as only trusted third-parties will have access to the private data stores they have permission to access.

In addition, a third-party cannot derive any meaningful information from the data store unless they have specific keys, which allow them to decrypt each individual data record.

"This compartmentalization of data ensures that participants transactional data is security and private".

The data recorded on the blockchain serves as a secure way to ensure that the private data store is in sync with any permissioned participant’s master copy, and as a way for trusted third-parties to discover when there are new records that are relevant to the accounts they are entitled to monitor.

The 3 layers: The Application

Solution considerations of the Application Layer:

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

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). For ease of explanation let’s take a look at a real business case we are currently exploring;

Bank-Feeds on the Blockchain:

In this design, the application layer is where the Bank, Intuit and third Party sit up top, and would be the interface to connect these parties and their systems into the layers below.

The diagram above further illustrates how network participants interact with the data at each layer:

1. Bank writes an encrypted data record for Customer[c] to the Private Data Store.
2. Bank broadcasts a transaction under Customer[c]’s address to the Blockchain with a pointer to the data record.
3. Third-party [Intuit] was monitoring for transactions under Customer[c]’s address and reads the pointer.
4. Third-party[Intuit] initiates a key exchange with the Bank to retrieve a shared secret for the data record.
5. Third-party[Intuit] uses the shared secret to decrypt the data record and can now read the transactional data from the Private Data Store.

Conclusion:

I believe that the key to viable Enterprise Blockchain Solution Designs is a systemic approach, where the 5 key pillars are separated into the correct design layers.

This approach will not only allow for rapid deployment of Blockchain technology in enterprise solutions, but 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.

If anybody would like to explore our technology and solutions further, please drop us a line on [email protected]

Special thanks to Paul Salisbury from Techemy.co , Lawrie Dipple (co-founder) from Bravenewcoin.com and Jarred Spriggs from Smartbit.com.au