I meet a lot of businesses that want to use a blockchain. One common subset of enterprise clients is as follows:
Sharing certain information in my industry and across my value chain in a secure and private manner selectively will allow us to reduce delays or increase trust allowing me to significantly reduce operational costs/create new businesses. Customers will post their information to a blockchain and this information will be validated by different parties. We will use smart contracts to ensure faster processing and payment settlement.
Sounds familiar? This subset rest on a simple premise: this industry or value chain will benefit a lot from the ability to share accurate real-time data selectively with other participants. But how exactly does Blockchain help? Blockchain is confusing because it is the combination of several technologies offering different benefits. In looking at an idea, I often ask people to dive deeper into the specific features they expect blockchain, especially a permissioned blockchain, to provide that they lack today. What are some of these features?
The first three aspects are relatively straightforward, and it is often on point 4 that many customers stumble in understanding a blockchain based system. For point 1, most clients want a system where only the people that have to see the data get to see the data. For point 2, they seek a system that is tamperproof. For point 3, often they want faster and automatic processing of business to business or business to customer interactions, often involving payments.
What is Validation and Consensus
I find point 4 to be the most interesting aspect of blockchain, and one important differentiator of a centralized system from a de-centralized one. Many enterprise customers think of validation as a multi-sig process. Here’s an example which can be generalized to many other enterprise examples:
Party A posts its financials on the blockchain. Party C is an auditor and attests to the accuracy of the financial documents. Party B agrees to transact based on this information. Party A, B and C work off the same documents.
In this case, what we call “validation” is a process of three parties agreeing on the truth of some data. It is a “notary” function where a third party attests to the truth of some information. The blockchain network could also then broadcast that certain changes (e.g. data has been posted) or agreements (these three parties have agreed to something) have been made depending on how the blockchain is set up. This is a centralized system as the underlying truth of the data relies on agreement among a set of (relatively small). Some enterprise blockchains are designed specifically to validate based on this architecture.
This is different from the rules-based validation that nodes in a public network conduct for cryptocurrencies. An example of such a rule is “no double spending”. Using this rule, the blockchain network can scan all the posted transactions and ensure that final transactions do not violate all the rules that govern transactions.
This distinction is important when we think about how a blockchain is architected – many business use cases people suggest today do not require network validation for the logic of the underlying transaction. What they need from a blockchain is a secure database sharing platform and notarization.
Tokenization Changes Things
However, examples can change when we introduce tokenization. In the oft-cited Letters of Credit industry, introducing tokenization allows us to treat validation of token exchange in the same way we do for cryptocurrencies. Let’s say we represent ownership of an asset that is making its way from a manufacturer in China to a retailer in Singapore as a token. We can then have the network validate this token according to a customized logic (“no double spend”, “one owner at one time”…etc.). This will clear up confusion in supply chain financing over who has title over the asset at any one point in time as it moves through the supply chain. However, for each industry, this logic has to be customized and thought through to enable network validation instead of multi-signature validation.
So as you define your blockchain use cases, do think through what you need from a blockchain, and what the underlying business logic is that you need to validate.
