The 5 Pillars & 3 Layers to Enterprise Blockchain Solution Design. (2024)

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 today.

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 which addresses the correct requirements on the correct layers

Requirements:

Banks, FinTech entrepreneurs & legacy infrastructure providers like IBM have requirements which far exceed Public Blockchain's (bitcoin) 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..

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 & immutability for scale & privacy.

(Some of) what is being explored today:

• Clearing & Settlement (ASX NASDAQ & various others)
• Syndicated-Loans (Independently: over 10 banks - Consortium: R3)
• Smart-Contracts & Smart-Assets (Tradle, Wave & various)
• Federated Bank Feeds & Invoicing (Techemy.co)
• Payments (Swift, R3, Western Union & various others)
• 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 between all permissioned participants and of equal importance; distributing the number of full copies of the ledger to maximize 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 & enforcement of complex permission settings for participants and 3rd parties.

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

Blockchain technology for enterprise applications, particularly for the financial service sector, requires these 5 pillars in its solution design, to ensure it 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 & has baked-in, an excellent monetary incentive for transaction processors to keep updating and verifying records. 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 built 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 2 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 which can service the demands of enterprise applications without compromising on one of the 5 key enterprise solution design pillars.

Let's take a look at the 3 integral layers required and where each of the above 5 pillars is serviced ~

The 3 Layers: 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 5 key pillars (solution design requirements) on 1 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 run 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 the open Blockchains. However, for people or machines who 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), 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. IfLehman Brothers built a blockchain and everybody used it, the company's collapse would also mean a systemic network collapse, effecting all applications built on such a private network. There would be no bail-outs in this scenario.

This is the solution design epiphany: 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 particularly, the preferred choice, but our technology can work with any blockchain required.

The 3 Layers: 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 data is recorded on the public Blockchain and 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 the 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 hashed 1.9m datapoints which make up the historic component of our Bitcoin Liquid Index, onto the blockchain with a single hash and now hash 120 points via 1 small bitcoin transaction per hour, to keep it notarized ongoing.

This means the rapid scaling part happens on the private chain, not requiring enterprise to 'spam' a public ledger with every new record created.

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 are permissioned to enter.

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 the absolute security and privacy of participants full transactional data.

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 records, 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 (limited) look at a real business case we are currently exploring with some banks;

Bank-Feeds on the Blockchain:

In this design, the application layer is where the Bank, Intuit & 3rd 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 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 inter-operability, paving the way for 2nd and 3rd generation applications and Entrepreneurs.

Of-course some serious development went into building the integral middle-layer, 'The Data-Store', but we are pleased to say it works well and we are now exploring several applications ourselves.

If anybody would like to explore our technology & solutions further, please drop us a line on contact@techemy.co

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