Blockchain has been one of the most loudly trumpeted new technologies on the enterprise database scene in recent history. However, the concept of a blockchain is not really a new notion. It is more of a repackaging of existing constructs to deliver a new set of benefits to any organization leveraging it for their use cases. It provides the benefit of irrevocable proof, and it reduces friction with information exchange.
At the heart of a blockchain we have the notion of a shared distributed ledger. This is exactly what it sounds like: a ledger, which is equivalent to a checkbook. Each entry is written to the ledger, which contains a complete history of all entries/records. Importantly, in order to make a change to a single entry, the entire ledger would need to be rewritten. This ledger is at the core of using the blockchain as a system of record. Because of its underlying immutability, it can deliver a higher level of trust. When leveraging the sharing feature to share the ledger with a notary service, there is an additional layer to prove that nefarious actors could not have tampered with the data in the ledger.
Smart contracts is the next piece of blockchain technology getting people excited about its possibilities. Smart contracts do not in any way have anything to do with legal contracts, and, as a result, some consider this to be poorly named. The concept of a smart contract is most closely associated with the technologies of microservices and function-as-a-service (FaaS). The internals of FaaS consist of a microservice (a single and logical unit-of-work) and a trigger event that causes the microservice to be executed. A smart contract is fully audited to show that it was executed and the result of its execution.
The final piece for enterprises concerned with blockchain is the notion of consensus. This is the piece of logic that dictates how information is allowed to be placed into a shared distributed ledger. Consensus is where we see the first major difference between public and private blockchain use cases. With public blockchains, the intent is to prevent any single person from owning or being able to place information on the blockchain at their own discretion. The concept is to trust no one. There are some very complex consensus models in public blockchain implementations because of this trust issue. Proof-of-work is a model popularized by Bitcoin that requires substantial investments in hardware and energy consumption to be allowed the ability to write to the blockchain. There are other models, such as proof-of-stake and proof-of-time, which are seen as alternatives to proof-of-work. However, these proof-of models are not the fastest when it comes to placing transactions onto a blockchain.
While “trust no one” is the motto of public blockchains, the concept of trust already exists within the enterprise, at least to some extent. Whether through physical security tokens, biometrics, or even passwords, trust is established. A consensus model within an enterprise can be as simple or as complex as required. The model might require that any single individual can only be trusted 50%. This would then require a minimum of two-party approval for something to get written to the blockchain; otherwise, the information would not be allowed to be placed onto the blockchain. Business approval workflows have existed for more than 30 years, and this doesn’t have to be different.
Public blockchain implementations were not built for analytics of any type, which makes a blockchain just another data silo, and it is critical to understand this up-front. Those actively relying on a public blockchain use a sidecar database of some sort in order to index, search, and aggregate information for analytical purposes. A sidecar database such as this in the enterprise is a potential weakness, as bad actors could manipulate the database, causing false reports and subverting the blockchain. If bad actors can cause the production of erroneous reports, then the use of a blockchain has not accomplished the goal.
Blockchains built upon an event stream system that can replicate (share) in real time and support analytics in place do not have the same cause for concern and are considerably easier to manage. They don’t require the data to be loaded into a sidecar database since analytics can be performed in-situ. All software development, regardless of the intended purpose of the application, should have a strong focus on data architecture and operations practices, even blockchain solutions.