Let’s build on our ongoing discussion of distributed ledger technology by offering a bit of specific guidance as to when you really need to use DLT.
By the way, we’re focusing on ledger technology for a very good reason: its programmable flexibility using embedded SmartContract language. For enterprises, flexibility is the key ingredient for efficiency and simplicity of use.
DLT focuses on ledgers designed to support global business transactions, including major technological, financial, and supply chain companies, with the goal of improving many aspects of performance and reliability. With ledger technology, you get a modular framework that supports different components for different uses, including a variety of chains with their own consensus and storage models, and services for identity, access control, and contracts.
SmartContracts are applications —embedded, self-executing programs —with a state stored in the blockchain. They can facilitate, verify, or enforce the negotiation or performance of a contract. A SmartContract can facilitate the exchange of money, content, property, shares, or anything of value.
When a SmartContract runs on the Ethereum blockchain, it becomes a self-operating computer program that automatically executes when specific conditions are met. And they run exactly as programmed without any possibility of censorship, downtime, fraud, or third party interference.
Beyond merely handling accounts and transactions, a SmartContract can store a multitude of interrelated computer programs, such as “If xx account has $yy balance … and if today is December 31, 2017 … then transfer $5 to zz account … if not, take no action.”
Is the ledger for you?
Ledger technology is unparalleled in its ability to create immutable and trustworthy databases, but how do you go about determining if you really should invest time and money and effort into a ledger system for segments of your business?
Generally, enterprise organizations are targeting ledger solutions toward their supply chain and inventory control challenges. These are issues that most every enterprise is going to face at some time.
The question is how best to enhance your current system. Note that the key word there is “enhance.” DLT enhances, it doesn’t replace. The data does not change, but how you manage, store, use, and share the data are the things that change.
So here are four questions to consider when it comes to DLT:
Does your need involve a database, and if so, how many users are there for that database? If it’s two or more users and it involves critical business operations, there’s a very good chance DLT will benefit you.
The greater the number of users and inputs, the stronger the business case gets, because there are economies of scale in the way that ledger technology works compared with other methods of safely dealing with data.
Do the users of your database need to trust each other? If the answer is yes, then DLT is for you. Ledger technology allows trust to exist between “trustless” entities. My company and yours may both benefit through the sharing of a database, but what do we do if the nature of our business means we can’t fully trust each other’s systems?
Why would I share a database with you if I can’t be sure you aren’t going to change some entries in that database, accidentally or maliciously? There’s no way to tell how much damage that might do.
The immutability and autonomy of DLT databases is their strength. Once data entries are correctly committed, they become permanent. This data is ratified and accurate for the life of the database. You can look at my data all you want, but you can’t change it, and any attempts to do so are prevented by the sequence of cryptographic signatures that would make it glaringly obvious that you tried.
By the way, if the answer to the trust question is no, then you can probably function sufficiently by simply using multiple copies of centralized, synchronized databases.
Is there any sort of central or third party entity that could cause problems? If the answer is yes, these problems might revolve around any related inaccuracies that crop up, or that may lie in structural inefficiencies that stand in the way of doing business effectively.
It could be a question of “float,” for instance. If I have a net 30- or 60-day payment schedule, that’s fine, but for everyone involved, that brings in the issue of one party trying to use the other party’s money for as long as possible to gain financial advantages before remitting it.
But when you move to a ledger-based settlement system, your net 30 days becomes net 30 seconds. Payment is immediate. This changes how you do business, and there may be distinct advantages for your company to doing business transactions in that way.
If the answer is no, it may work fine to use a third party or intermediary data system.
Do the transactions depend on or interact with each other? If yes, then know that ledgers are by their nature interdependent.
Your business very likely makes decisions based on factors such as cash flow or days on hand of cash. The interaction of databases and data elements is an important aspect in the day-to-day management of an organization.
For example, if the product you shipped to me arrived at my dock today as the contract promised, that’s great, and I pay you right then. But if the goods that arrived were damaged, then my system has to know not to make that payment. Business rules such as this are particularly important in the arbitration of supplier-customer relationships.
If the transactions are not interdependent, then a legacy database will suffice.
Just remain aware that there is tremendous potential in ledger technology. DLT and its associated algorithms may not solve all your business problems, but it can and should solve some of them.
We’re seeing this already, as DLT is being used by hundreds of organizations globally today. But they only moved to DLT carefully, after doing their research and due diligence to justify the deployment.