07 Jun Journey Around Workflow Properties of Blockchains for Enterprises

Here at CreedPro, we have hourly conversations with folks exploring the perfect blockchain use case using shared ledger technologies and implementing smart contracts throughout the workflow fabric.

In our chats, we lead with a conversation reminder that blockchain is in its infancy.  Most folks are learning through proof of concepts where vendors are working side x side with an enterprise building strategic roadmaps.  Each trying to figure out where this new technology, were it will be distributed and accessed.

A concern we are seeing is in the enterprise with private sign-in authentication for their end-users.  They want to know how to restrict rights and modify the way users can interact with the data while keeping the integrity of the decentralized blockchain.

The one thing to remember, from Vitalik Buterin the founder of Etherum, is there are three main databases:

1. Public blockchains: A public blockchain is a blockchain that anyone in the world can read, anyone in the world can send transactions to and expect to see them included if they are valid. Anyone in the world can participate in the consensus process (the process for determining what blocks get added to the chain and what the current state is).As a substitute for centralized or quasi-centralized trust, public blockchains are secured by cryptoeconomics (the combination of economic incentives and cryptographic verification using mechanisms such as “proof of work” or “proof of stake”) following a general principle that the degree to which someone can have an influence in the consensus process is proportional to the quantity of economic resources that they can bring to bear. These blockchains are generally considered to be “fully decentralized”.
2. Consortium blockchains: A consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of nodes. For example, one might imagine a consortium of 15 financial institutions, each of which operates a node and of which 10 must sign every block for the block to be valid. The right to read the blockchain may be public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks being public together with an API that allows members of the public to make a limited number of queries and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered “partially decentralized”.
3. Fully private blockchains: A fully private blockchain is a blockchain where write permissions are kept centralized to one organization. Read permissions may be public or restricted to an arbitrary extent. Likely applications include database management, auditing, etc. internal to a single company. Public readability may not be necessary at all, though in other cases where public auditability is desired.

Many early-adopters who have attempted to reconfigure the initial intent of decentralization have failed to launch their projects. Here is where the foundation of smart contracts can come into play.

Smart Contracts

A blockchain smart contract is a piece of code that defines the rules of a transaction. In asset based blockchains, a transaction may be defined as the transfer of an asset (or part of an asset) from one account to another. Smart Contracts allow you to extend that model. So, instead of simply transferring cryptocurrency value or other assets, the blockchain allows users to create a contract. These contracts can contain data, permissions and workflow logic which permits accounts on the blockchain to interact with such contract and in different scenarios.

Smart Contract Example:

Suppose you rent an apartment from me. You can do this through the blockchain by paying in cryptocurrency. You get a receipt which is held in our virtual contract; I give you the digital entry key which comes to you by a specified date. If the key doesn’t come on time, the blockchain releases a refund. If I send the key before the rental date, the function holds it releasing both the fee and key to you and me respectively when the date arrives. The system works on the If-then premise and is witnessed by hundreds of people, so you can expect a faultless delivery. If I give you the key, I’m sure to be paid. If you send a certain amount in cryptocurrency, you receive the key. The document is automatically cancelled after the time, and the code cannot be interfered by either of us without the other knowing, since all participants are simultaneously alerted.

You can use smart contracts for all sort of situations that range from financial derivatives to insurance premiums, breach contracts, property law, credit enforcement, financial services, legal processes and crowd funding agreements.

Blockchain for Cross-Entity Workflow

There are two common types of automated electronic communications workflows vetted when one or more entities are interacting. Both come with reliability and trust issues.

1. APi/Messaging: One entity sends the other entity a message when they need to share information. This works well in many scenarios, but it is not very reliable. What if either system in the API connection goes out of sync – how could that be reconciled? Who would hold the most valid copy of an interaction/transaction history? This could be devastating in the financial or legal vertical markets.
2. Share Intermediary service: Where it is important to keep an accurate shared view of the state of interactions/transactions, a trusted intermediary can resolve the problem. Each party interacts directly with a trusted intermediary, rather than directly with the counterpart. In such arrangement, the trusted intermediary holds the master copy of interactions/transactions history. This may seem like an excellent solution but it is less than ideal because a department’s own internally hosted copy of the interactions/transactions history may still desynchronize with the trusted intermediary’s (cloud hosted) copy.

This is where blockchain solves the above problems through the electronic distributed ledger. It eliminates the intermediary. The shared ledger of interactions/transactions resides within each entity. So, with a distributed ledger, there is no danger of individual systems becoming desynchronized with the counterparty. The result is an agreed, immutable history of interactions/transactions.

As we continue to move through Proof of Concepts (POC’s) with our enterprise customers we continue to share our journey around the successes and pitfalls that we find.
www.creedpro.com/blockchain