Solving real-world problems with Distributed Ledger Technology

The first practical use of blockchain technology is well known: bitcoin. The creator intended to create a system for electronic transactions without relying on trust. We are now 10 years further and a vast range of blockchain apps have taken of since then. Of course, the majority of these apps revolve around cryptocurrencies. However, since the introduction of smart contracts we have seen new categories of blockchain applications gaining traction. These applications have left the area of early blockchain adopters and enthusiasts. Enterprises and governments have taken notice of this technology and have been looking at ways to incorporate it into their processes.

Now, this may seem like a solution that is looking for a problem. And to be fair, when I first read about blockchains this was my thought exactly. While a cryptocurrency seems like a legitimate use of the technology – the fact that they are actively used for transaction of value is proof of that – what else could it be used for? And if it’s basically a database with some specific characteristics, some would say downsides, wouldn’t a normal database be just a good or even better?

Blockchain or DLT?

Before we dive into the answer to these questions, let’s first examine the key elements of blockchains. It is also good to know that a blockchain is a specific implementation of a more common pattern known as a distributed ledger. Distributed ledger technology can be implemented with a blockchain, but there are newer platforms such as IOTA and Hashgraph that may be considered alternatives to blockchain. Being newer than platforms like Hyperledger and Ethereum these technologies have certain advantages over them, more specifically in terms of speed. So if, by the end of this article you are convinced that blockchains could benefit in your particular case if only it had more speed, then you should take a look at these implementations of DLTs.

Key Elements

For now, let’s focus on the elements that all blockchains have in common.

Feature #1: a shared ledger means decentralization

To start, the blockchain is a shared ledger. This means that it’s a database running on different nodes, all capable of showing the same data. As such, you can consider this data to be decentralized and taking down a single node would not affect the data nor its availability. There is no single point of failure.

Feature #2: smart contracts introduce deterministic behavior

When the Ethereum network came into existence it introduced the notion of smart contracts. To be fair, the bitcoin network also had a scripting language and you can consider the bitcoin transaction script to be the first smart contract on a blockchain. However, initially the platform didn’t allow for other scripts to run. As the bitcoin protocol evolved, it has gained support for smart contracts but it’s not as programmable and extensible as Ethereum. The smart contract makes the blockchain deterministic. This means that the outcome of a transaction is completely pre-determined by the logic in the contract. Given the same input, it will always produce the same output.

Feature #3: transparency leads to accountability

Blockchains are transparent in the sense that transactions of each public address is open to viewing. With an explorer and a user’s public address, it is possible to view holdings and transactions that the user has carried out. This level of transparency did not exist in financial or enterprise systems before and it provides accountability that we didn’t have before. This also means that the platform forces all parties to act with genuine integrity.

Feature #4: Anonymous == Privacy?

The transparency may lead to confusion as to the degree of privacy that blockchains can provide. How can both effectively exist on the same platform? The actual identity of a user is normally concealed behind a public address. Blockchain does not require any identity for the network layer itself. This means no name, email, address or any other information is needed to download and start utilizing the technology. The blockchain does not, by itself, provide identifiable records and users can interact with smart contracts without divulging their true identities. So in that regard, the users are anonymous. By analyzing a series of transactions, it may be possible to figure out who is behind a certain address. There are also use cases, for example when reputation is important, where the app can only operate pseudonymously.

Feature #5: This means trust

All these aspects of decentralization, determinism, transparency, and privacy produce the most profound quality of blockchain: trust. Or rather, trust is no longer a prerequisite to safely interact and transact. It used to be that trust was the basis upon which we decide whether or not to enter into a transaction with one another. We need trust to decide whether the party that we are interacting with is dependable and likely to fulfil their side of the deal. Especially in the current information age, the knowledge of and ability to trust is more difficult to obtain than ever. Many organizations that were once trusted without question have fallen from their pedestal. Reviews on e-commerce platforms, funds held in escrow, personal data in databases, we all know about the cases where it turns out that reputable organizations are compromised.

Rules

For these key elements to work, the blockchain follows a set of rules. It’s like the business logic of the blockchain.

Rule #1: consensus

First rule is that there needs to be consensus among the participants in the network. All nodes have to agree on the state of the ledger. There are a different algorithms to achieve this consensus. Most known is the Proof-of-Work algorithm that is designed to make it relatively expensive to tamper with transactions. Too expensive, in fact, to be economically feasible. The cost is related to the amount of energy and hardware necessary to add batches, the blocks, to the ledger. Since this is not a very sustainable method, various platforms have moved to Proof-of-Stake. This algorithm rewards nodes that are working to process transactions with a higher stake in the network. This usually means nodes with a locked amount of wealth, in the form of tokens, get a better chance to add a valid block to the ledger. It’s in the interest of wealthier owners to keep the system honest.

With either algorithm, and there are others, the goal is to have all participants that share the same ledger agree that a set of transactions is indeed valid.

Rule #2: data provenance

Another rule in the blockchain is that all transactions can be traced back to their origin. This is called data provenance and this means that the system needs to be able to track changes, where data originates and moves to, and who made the changes. It’s a complete historical record for any piece of data.

Rule #3: immutability

It may seem a bit contradictory to the previous rule, the data is immutable. But this means that once a transaction is stored in the ledger it can no longer change. It’s fixed and there’s no tampering. If a transaction is in error, you need to initiate a new transaction to reverse the error. This is achieved by means of cryptographic hashing. Through hashing, every piece of data in the ledger gets a unique signature. Changing even the tiniest part of that data would change the hash and thereby the hash of related transactions breaking the complete sequence. Obviously, this is not allowed and the only way to pull this off is if you can get enough nodes to re-validate the set of transactions. This is known as the 51% attack. The older the transaction, the more difficult it becomes.

Rule #4: finality

The ownership of an asset or the completion of a transaction can only be found in a single place: the shared ledger. If you take it a philosophical point, there can never by finality in the literal sense of the term. The only thing we can achieve to make it as final as possible. With a paper ledger, it’s fairly easy to add a digit to an amount, or just burn the paper. With a centralized system in a bank you can make it more difficult with the help of firewall and other security measures. If the state of the ledger is still questioned, we can always try the courts. In a decentralized system, we can achieve as much finality as is technically possible.

Flaws

Now that we know what a blockchain is and the rules by which it is governed, we could start looking for cases in which this technology makes a lot of sense. There are plenty of examples where things like trust, accountability and privacy is important. Especially when multiple parties are involved. Logistics, healthcare, insurance and finance are the easy ones. However, before we simply conclude that those industries should embrace blockchains immediately, we have to take a look at potential flaws or downsides in the technology.

Cost

Given that the technology is relatively new and still undergoing a lot of innovation, it’s pretty hard to decide on the investment. It can be quite expensive to support a decentralized architecture and commit resources to storing data and execute transactions. You wouldn’t want to make it too cheap either, so as to not attract participants with malicious intent. The resource utilization in general-purpose blockchains like Ethereum is also quite poor if you compare it to general-purpose computing power. Operations that are cheap on a normal computer can be outrageous expensive on a blockchain.

Speed

The algorithms responsible for the blockchains characteristics will also make it operate more slowly than traditional centralized solutions. The need for transactions to be broadcast to the blockchain’s network and for the consensus to converge being among the first and foremost. This inherent slow processing of transactions affect the performance of applications. This, by the way, only affects applications that need to change state in a blockchain. Applications that tolerate slow writes and mostly read data are not affected.

Interaction with the real world

Code, in the blockchain in the form of a smart contract, runs within the confines of a virtual machine. This VM does not have external interfaces, making it impossible to interact with anything outside of the blockchain, including other blockchains. If you were to attach a real-world device to the blockchain, that device would have to become a full node in the network, speak the protocol and have enough storage and processing power to keep up. Reaching external data sources is also difficult if not impossible since they cannot be accessed outside of the blockchain’s execution environment. You can add data to the blockchain, but that may turn out to be very expensive. You may have heard about oracles. An oracle, in the case of blockchains and smart contracts, is an agent that collects data from real-world occurrences and submit that information to a smart contract. Likewise, an oracle can act on events and conditions in a smart contract. It all adds to the complexity of the final solution.

Privacy only goes so far

We have also seen that privacy is a relative concept in a blockchain. There are specific blockchains like Monero and Zcash that achieve privacy for the specific use case of a digital currency. For general purpose blockchains this level of privacy is not yet feasible. While blockchains do not automatically connect transaction data to a certain individual, it does leave a trail that researchers can follow. Combined with other pieces of data it is possible to deduce who made the transaction. Not only is this a problem for individual users, it is also a large issue for companies that need to keep their investments, payments, and similar data a secret from the competition. Work is done by various development teams to increase confidentiality, but it is not an easy task and the perfect solution has not been found.

Errors can have serious consequences

A specific problem for developers is that mistakes are easy to make when developing a smart contract. Blockchains with a single use case like Bitcoin and Electroneum do not have this issue. However, platforms like Ethereum, NEO, EOS, and many others with the specific intent to run smart contracts make it pretty easy to get yourself into trouble. The programming language for Ethereum, Solidity, has concepts that, if not understood properly, can result in a bug which in turn can end up in loss of money. In simple applications this loss can usually be corrected, but more complex solutions can suffer greatly from this drawback. Illustrative examples include the DAO (Decentralized Autonomous Organization) hack in which $70 million was stolen and the Parity bug triggering a freeze of over $280 million worth of Ether.

What’s important?

With these drawbacks in mind, we have to look more closely at each use case to figure out if the pros outweigh the cons. We cannot simply suggest that if decentralization matters, we need blockchain. Likewise, we can also not conclude that if latency is important we cannot use blockchain. For each aspect we need to determine its level of importance. That determination could look somewhat like the following table.

Example: insurance claims

If we take the example of the insurance industry, it suffers from a number of issues like fraud, contract complexity, human error, information flows in reinsurance and claims processing. How would a blockchain help in processing insurance claims? We can go through the aspects to find out.

The shared ledger could be used to hold the relevant policy details such as proof of insurance, claims forms, evidence to support claims. This information can be added to the ledger by the policy holder when a claim is made. Having the data stored on a decentralized system means that it is not affected by downtime, due to maintenance or security breaches.

Using smart contracts the claims can be processed efficiently by having each party in the transaction execute its necessary processing activities. These smart contracts can validate the state of the policy, compare the details of the claim against the policy and notify parties of state changes.

All the actions can be traced so it’s clear for every concerned party what the state of the claim is and any modification that was made to the claim. Being immutable, there is no room for tampering like there is when you’re dealing with paper or simple database records. Fraud is a serious problem, and accountability can eliminate common sources of it.

Parties involved do not necessarily need a high level of anonymity. In the case of health insurance this may be more of an issue, but usually the parties involved in handling an insurance claim need to know each other anyway or don’t really care.

The blockchain creates implicit trust, which is a positive effect especially when multiple parties do not necessarily share the same goal. The policy holder wants the claim to be approved as quickly and complete as possible. At the same time he would want premiums to be low. The insurer wants to eliminate fraud and keep costs down.

To the effect that costs are an issue, we need to recognize that setting up a blockchain infrastructure to handle insurance claims can be expensive. While a lot of money is managed in the industry, not every participant will want to run their own node or validate transactions. A policy holder usually has no interest at all. So it’s more likely that for such an investment to be cost effective for the individual insurance company other insurance brokers need to join. While a blockchain enables trustless transactions it offers little trust if the network is in essence operated by a single player.

We know that transactions in a blockchain are processed relatively slow. Especially compared to financial transactions that can run into the thousands per second. For the insurance claims process moving from a single transaction per day to a potential couple of transactions per hour is already a huge improvement. These processes usually do not run on a millisecond timeframe.

When it comes to interacting with external data we may encounter one of the most difficult issues in trusting the data in blockchain. Smart contracts that process input need to rely on the fact that that particular input is indeed valid. Sidestepping for a minute to supply chain management, another popular use case of blockchain, transactions and thereby the entire blockchain can be rendered useless if the system generating the input is corrupted. The oracles that allow for the interaction with a blockchain need to have a high level of security and integrity. There are technical solutions to this problem like Oraclize, ChainLink and Delphi Systems.

The fact that all transactions are visible to involved parties makes it easier to fight fraud. In fact insurance companies already share intelligence on insurance claims and fraud detection. So far they have been limited by technical, legal and commercial challenges. Sharing personally identifiable data, across borders or even between companies can be bound by privacy legislation. Companies are hesitant to share sensitive data with competitors. In this case, a blockchain that is managed by a single institution has little added value. Transparency, in this case, seems like a good thing.

As for consequences when a smart contract is flawed, the repercussions can be mitigated by updating the code when bugs have been discovered. A claim that is still being processed in a previous smart contract would not benefit. However, a bug in a smart contract does not render the entire blockchain useless, nor will it impact other claims. Bear in mind that when a smart contract is use to transfer actual value, e.g. a cryptocurrency, this is a different story.

In conclusion a blockchain allows insurers can create receipts at different points in the claims process, resulting in an immutable, auditable record of all claims activities, which can be revisited by all parties including the regulators. This could lead to lower transactional cost, lower transaction risk and trustless computation.

The analysis of this use case and its fit for blockchain could be something like this.

What are the alternatives?

Now that we’ve looked at the features of blockchains, listed them and evaluated them against a use case you might conclude that our model is complete. This is not the case, however. The features of blockchains are not offered by blockchains exclusively. Just because a blockchain solution ticks most of the boxes in a potential solution, you could fall in the trap of overengineering because new technology is cool and exciting. We need to consider alternatives as well.

Peer-to-peer protocols

Decentralization can be achieved through peer-to-peer protocols. Classic P2P protocols like BitTorrent have been around for a couple of decades. The P2P architecture was originally brought into mainstream use by the file sharing application Napster in 1999, where files such as music or film were stored across multiple computers. Decentralized storage is available without resorting to blockchains. Decentralized computing is pretty rare. Note that there’s a difference between decentralized computing and distributed computing. Decentralized means that there is no single point where the decision is made. Every node makes a decision for its own behavior. Distributed computing means that processing is shared across multiple nodes but the final decision may still be centralized. In other words, centralization and decentralization refer to levels of control. Distributed and non-distributed refer to differences in location.

Local execution

Deterministic behavior comes from the fact that the both the smart contract and its execution environment are publicly known. You can mathematically and logically predict the output given a certain input. You could achieve the same guarantee if you were to publish the source code, compile and then run the application on a users’ device. Assuming of course that the user trusts the compiler. If the application runs remotely, you cannot provide the same level of guarantee that a decentralized app can.

Secure logging

Accountability in terms of responsible information disclosure are usually matters of policy, more so than technology. Reporting systems are technological solutions to accommodate the obligation of disclosure. But an application must publish to an append-only log all events subject to audit, as they occur, and must be trusted not to omit events. Secure loggers are a recent example of auditability achieved through a blockchain alternative.

Tor/VPNs

If parties involved in a transaction wish to remain anonymous, there are protocols available to achieve that. Onion routing (Tor) is the most common way to have both organizations and individuals share information over public networks without compromising their privacy. VPNs may work as well to achieve this, but you would have to trust the VPN provider.

Conclusion

In the end it comes down to going through the following steps.

1. Understand the specific features of a blockchain.
2. Decide to what degree the pros and cons help or hinder application development.
3. Determine what features are relevant to the given problem.
4. Check to see if alternatives for a specific feature would simplify the solution.

We should recognize that blockchains are a tool, not a feature. There is no need to advertise to a customer that an application uses blockchain, no more than it needs to promote the fact that it was written in C#, Rust or Python. In the end, it only matters what the application does.

Resources

If you are looking for more use cases, analyses or potential blockchain solutions, here’s a list of resources used while writing this article.

• Blockchain,a catalyst for new approaches in insurance
• Blockchain Demystified: Looking Under the hood of the Blockchain
• Blockchain Technology: Application And Development In Five Different Key Industries
• How blockchain is eating the world
• Exposing the Myth of Blockchain: Why the Hype Is Holding You Back
• Blockchain for Enterprise
• Enforcing accountability in media