Could your application use a blockchain (Part 2)?

Published in

Liquid Insights

6 min readJul 26, 2022

In Part 1 of this article, we defined terms needed to assist in determining whether your application can use a blockchain. Now it’s time to develop key questions on whether you can actually use a blockchain or not. This list is not exhaustive, but should give you a general sense if a blockchain could benefit your use case.

To reiterate something I discussed in Part 1 — I’m focusing on enterprise-like applications — not crypto trading applications. (Although it is important to note that, by its very structure, blockchains involve trading assets.)

I also want to explicitly state, that, in my opinion, there are very few applications that can only use a blockchain. The vast majority of enterprise-like applications will require multiple data store technologies — and that means we need to expect that we will mix blockchains with private data stores. Even Brave Browser, which integrates the Basic Attention Token (BAT) to provide rewards for browsing, uses your local file system to store bookmarks and (when you approve) cookies, so using private data stores in tandem with blockchains should not come as a surprise to anyone.

With that as an intro, and remembering that a blockchain is a “…digital ledger on a distributed database that leverages cryptography to secure the stored transactions”, we begin with the following:

Do you have transactions that follow the structure of a ledger?

As a reminder, ledgers were historically used to record the movement of an asset (say a cow, gold, deeds) from party A to party B.

Almost every application stores transactions, but ledger transactions are specific — an ‘asset’ moves from party A to party B on Date D and Time T under Conditions C.

What are some examples of applications that could potentially follow a ledger structure?

A personnel system that records a title change of an employee (Employee Edward become a Director on Date D). In this case, the “asset” is actually a company title.
A health insurance application that records what and when an employee started their health insurance policy. (Employee Emily purchased Health Insurance Company Plan Gold on October 1, 2021 and it is valid through Sept 30, 2022
A purchasing system that records the order of office supplies. (Company A sends 20 cases of stock white paper to Company B on Date D, and received $X on Date D+45.)
A retail investing application that records the transfer of equities (not just crypto) to a retail investor. (Financial Services firm F bought stock S for Investor Ivy on Date D.)
A compliance application that validates the legitimacy of a document. Was the document that we used to approve the loan the same document we received from the borrower?
A loan investment application that transfer ownership of a loan from one investor to another.

As you can see from this short list of above — many applications can leverage ledger data structures. This leads us to the next question:

Does the asset itself have longevity?

If the asset itself has an extended shelf life, and therefore could be transferred again (loans, investment vehicles, automobiles, planes, ships, art, precious metals) then an app that tracks these types of assets almost certainly will benefit from a blockchain. In our examples above, the personnel system doesn’t pass this test because the employee title does not really have a shelf life. The purchasing system might not pass this test either, although it would depend on what type of assets were purchased.

How important is having an historical record of the asset transferring? Is it important to more than two parties?

Another aspect of the longevity concern is “is the asset important to more than two parties”? Knowing the history of an asset (How many people have owned this automobile?, When was the roof on this house replaced?) can be critically important to parties engaged in the transfer of that asset in the future.

In the above example, while a title promotion is certainly important to the individual promoted, and to the HR department who managed the promotion, it’s not that important once the promotion is completed. Once a person leaves a company, their history of title changes at that company just doesn’t have much value. A blockchain is just not needed to store employee title changes — for this, use a private database.

However, the remaining examples have assets whose transfer does have importance well past the date of the transaction. Have you ever received a doctor’s bill after having left a company and changed insurance? Audits that occur three (or more) years after a transaction often occur in purchasing, investing, and compliance applications. Having a history of transactions that you can guarantee the validity of is critical in these types of applications.

Does one party have to trust another?

In almost every single current enterprise-like application, there is an element of trust necessary from at least one of the parties.

Employees need to trust the company to maintain the employee database.
Employees need to trust their company (or vendor) to accurately maintain health insurance data.
Retail investors need to trust their investment company to accurately maintain their investment portfolio.

This list could continue. The point is, any application that requires trust of one party, could benefit by using a blockchain to provide that trust mechanism.

Each one of the above questions are important to determine whether your application could effectively use a blockchain. There is no hard and fast rule either (with the exception of does the transaction follow a ledger structure) and you will have to determine the importance of asset history, trust and importance to multiple parties before deciding whether your application can use a blockchain.

These are the basics to get you started. Once you’ve determined whether you think your application can leverage a blockchain, here are a few more considerations.

Should you use a permissioned or permissionless blockchain?

A permissionless blockchain can be thought of as a utility for public use whose governance is executed through the members of the blockchain (usually those that run nodes). Simply put — you can get an account on a permissionless blockchain without approval from anyone. If you want your application on a permissionless blockchain, you simply pay for the transaction costs associated with your application. (This assumes you don’t want to actually be a part of the peer-to-peer network and run a node on that blockchain.)

A permissioned blockchain provides the same technology as a permissionless blockchain, but has one significant difference — you need to be given permission to use the blockchain by a central administrator.

So how do you decide which is best for your application?

Is privacy and transparency important to your app or do you have know-your-customer (KYC) constraints?

Simply put, if your application is focused on transparency, then a permissionless blockchain is for you. These blockchains allow everyone to join and look at all the transactions. If KYC is an important aspect of your application — then you have two options. You could use a permissioned blockchain (which will provide the added security you will need, provided outside organizations are not part of your blockchain) or you could use a permissionless blockchain coupled with a private vault to store your KYC data.

Do you have personally identifiable information (PII)?

As a general rule, PII should never be stored on a blockchain. I can only think of one exception to this rule, and that’s if the application is internal to an enterprise, and the blockchain is a) permissioned and b) managed solely by that enterprise. Bottom line — PII goes in a vault but transactional information relative to that PII can be stored on a blockchain using public keys, which will anonymize the PII.

Conclusions

Not every application can leverage a blockchain — but many can. In this article we have suggested a list of questions to address to help you determine whether your enterprise-like application can leverage blockchain. Feel free to send me comments or your thoughts. Cheers!