Dlts — How to Choose the Right Blockchain for Your Business

Introduction

Blockchain first started to exist in our minds because of cryptocurrencies, however in this article we’ll focus on blockchain technologies for business, more commonly known as Distributed Ledger Technologies (DLT) *.

(*Not all DLTs are blockchains but I’ll simplify it here).

The basic promises of DLT are:

• Nobody will be able to modify data once it’s saved (without being detected) – immutability.
• All the independent business parties will have the same transactions, so they won’t be able to modify them and deny their existence – consistency.
• There’s complex hard-to-break crypto backing those promises up which makes the cracking efforts not a viable option (like hundreds of years, or hundreds of millions of dollars of processing power) – data security.
• There are multiple independent nodes and even if one of them is hacked the other nodes will ensure the truth about the transitions and they won’t be lost – security and resilience.

Business examples

One of the most popular is the safe storage and workflow of documents.

Let’s imagine a credit contract with a bank. Noone would like their bank to modify the signed document by any external party or the internal employee without being notified.

Or a scenario when a truck delivers goods, and the warehouse says “but we never ordered it” and you are unable to prove they did.

Another scenario could be the new drug test results from a lab to a pharma company.  Nobody wants to release the drug with faked test results, even when there is heavy business pressure to say “it’s alright”.

Or the tax office and tax payer. The tax office may say they sent the notice that requires you to fix an annual tax report and you didn’t fix it so there’s a penalty to pay; the same on the taxpayer’s side – to pretend we sent a document when we didn’t.

In the Internet of Everything (IoT) scenario, the typical case is thousands of meters sending their data (electricity for instance) to other systems, and then predictions and billing are done. The electricity distribution company has to have true data in order to minimize frauds. Blockchain can help with the problem of the last mile, i.e.,  trust of the data coming from the device to the cloud; it cannot be tampered with and has to be trustworthy.

These examples are a little stretched and simplified in order to help you understand. The reality of complex logistic chains is much more complicated and creates more opportunities for data loss or (usually worse) data tampering.

The nature of technology demands that there are multiple business organizations which are independent from each other, and can be translated to nodes independent from each other.

→More data services from Avenga

Options

If you are convinced that you need this type of solution,  there are multiple ways to go from a concept to a solution. Let’s review them now.

Your own solution based on open source frameworks

One of the options is to do what seems very natural in the software world, take the most popular open source frameworks and build your solutions on top of them. For example there are multiple technologies based on Ethereum.

You will have a high degree of freedom and control over the solution, which is a great pro, but you will have to fight with resource scarcity, manual upgrades of the underlying technologies, and a lack of support.

It will probably take longer, require many trials, and cause many errors, and it will be hard to debug, etc.  But eventually you will get there.

Plus, don’t forget about operations. It’s not a usual database, as it’s relatively easy to break the data, because of the inconsistencies that can be created due to errors.

Using custom blockchain tech

They are companies dedicated entirely to blockchain technologies, either they are experts in using open source frameworks or they are the creators of their own proprietary blockchain technology.

Usually, from the technological standpoint, their technologies address limitations of open source frameworks, add useful features, and improve on performance and security.

So what’s the problem?

There will be only a handful of people who know how the engine works, and if they leave the company (which very often is a startup), the codebase will be abandoned. Or the entire company will go out of business and your support options will disappear as well.

One of the workarounds is to demand and secure access to the source, but given its complexity, it may not help you that much as the experts required to manage it will be very hard to get and will probably be unwilling to help fix the solution, which they would have to learn from scratch.

Also blockchain focused companies will try to put their technology everywhere in your organization (land and expand). The most common mistake is to try to replace all the databases with distributed ledgers. Those companies do it on purpose to create a stronger vendor-lock and it will be impossible/hard to get rid of.

The best choice is to work with a partner who can benefit from known open source software (avoiding the deadlock of proprietary software), understands the blockchain internals and is able to combine it with the rest of the architecture. That’s what we do at Avenga with our partner Ubrich.

Using a public cloud

Amazon, Microsoft, IBM and others deliver blockchain as a service solution. They address several issues at once: complexity of the infrastructure, maintenance of the engines, adding developer friendly serverless or PaaS layers on top of it, plus integration with their logging and monitoring facilities.

Looks promising, except of course it has the usual problem of vendor-lock; you have to accept that your data and transactions will be there forever.

Forever? But what if they change their mind and decide to shut down the economically unsuccessful service? Not good.

The reduction of complexity is very often an overpromise: you have to manage nodes, deal with the underlying complex technologies, and use complex APIs.

These transactions are still slow due to the consensus nature of all the parties having to confirm the transaction.

→ Read more Is the hybrid cloud here to stay forever?

New alternatives – back to centralized

But what about a database which is as simple as any other cloud database but has DLT-like functionality and delivers on them?

Well, that is probably the best solution for many cases.

Yes, you still have a vendor-lock and the risk of the service continuity, but the reward is the simplicity and the very fast time to market.

One of the examples is Amazon QLDB which offers the simplicity of an API with the many advantages of blockchain technologies, to include immutability and transparency. Plus as the engine that is not based on consensus; it’s much faster and scalable.

The important thing is that it is centralized.

Oh no? But many of the existing blockchain solutions are controlled by a single entity, so why bother with multiple nodes, consensus performance, etc. when the data is controlled by that one entity.

It makes sense to me in many cases, when centralized solutions are OK.

Reality – public, private, hybrid

One of the common scenarios is to create something I used to call ‘fake-chain’.

One entity controls all the nodes so the owner of the infrastructure is able to modify the data on demand. The most important behavior of the technology is that data integrity and immutability are destroyed immediately. It is usually combined with a promise to the clients that their data is safe because we use blockchain (internally), and many of them are very happy to hear that.

So ask yourself: are you creating a decentralized DLT solution or a centralized solution?

For instance, some banks promise they use DLTs to make sure nobody modifies their documents, which ( banks usually control all the nodes) can be done without their clients knowing about it. Maybe that’s good enough and it should stay centralized,  but this decision has to be made prior to implementation with the full understanding of possible consequences.

Who’s in control?

The question is, how many nodes are there, if there are nodes, and who controls them. Let me remind you of the typical flow for centralization detection:

• The first question is usually the simplest – yes, we do have multiple nodes.
• The second question is a little bit more complicated – we have it in multiple data centers so they are distributed.
• The third question is what? – It’s our ledger, so how would anybody else have access to it?

So they (financial institutions, for instance) have built a centralized database using blockchain technologies, and it is more secure and consistent probably than a regular database. But they should not promise that it guarantees anything for you as their client or business partner. They have full control and they can do whatever they want. They often call it fancy names such as enterprise DLT or something similar, so as to give the perception that it is more secure and cutting edge.

The cost

By the way, it is more expensive to maintain and it is slower, however it does use blockchain technology inside (probably, how can anybody from the outside even prove that claim?).

When anyone creates a centralized distributed ledger, there’s a 99% probability that a normal database will suit them just fine without the added cost and complexity of blockchain technologies.

Blockchain as a database?

Or you can think about a ‘blockchainized’database solution with elements that will make it harder to modify the data and ensure stronger consistency and immutability than regular databases.

User friendly?

The other problem is dealing with inconsistencies and the simple question of how can there be a user friendly interface to see if all my transactions are OK? And when they are not, why not, and what to do then? Almost nobody talks about this (or at least not at the beginning) as they always assume the best case scenario and ask the business owners to believe them when they say “trust us, it’s secure”.

Hope for better data

One of the misconceptions is to believe that this technology will ensure data quality.  It ensures the consistency of what was ‘put in’ will be there and cannot be (easily) removed, however, if what came in was garbage it will stay garbage. There’s no simple ‘update’ in case some incorrect data enters the system. And it’s one of the reasons why, in many cases, blockchain is avoided.

Summary?

The traditional choices in a simplified version look like this:

What about something in between? It’s almost never simply zeros and ones in IT strategic choices.

Smart hybrid

The contrast between public and private is really fundamental. So, what about the hybrid? Yes, it can be done.

One of our partners, Ubirch, has created very interesting ideas and technologies around the blockchain concept in order to avoid the pitfalls of both the totally decentralized public blockchain (speed especially) and the local blockchain nodes controlled by one entity (speed, central management).

The blocks are created and encrypted locally but then added to the public decentralized blockchain to ensure the consistency of the data and that no single entity can modify or delete the old blocks.

They have combined the benefits of the public decentralized blockchain with the security of local devices and encryption that occur as soon as possible.

There is a trade off of 1 minute but for the majority of cases that’s acceptable.

As a reward, you get much better security and message integrity.

Read more about this technology here.

Future

How important is the need for dedicated technology to enable the higher data consistency and the ability to prove nobody has modified the data?

Does it matter? How much?

It seems not as important as was predicted. Why? Usually when there are multiple parties involved in a business process, they keep their own databases of transactions and communications with their partners. So in most of the cases nobody wants to lose any data.  Even so, the other parties can prove they sent the data to them using their communication systems.

It’s also highly unlikely that the other parties would pretend that they hadn’t received the purchase order because it would hurt their own business as well, and they don’t have any business incentive to do that.

Trust issues in the human world cannot be fixed with technology, that’s how business partnerships work. If someone breaks the agreement there’s the danger of losing business and being replaced by another partner.

The right place

However there are cases where a stronger consistency is required. For example, tracking assets such as nuclear waste and the transactions between companies and government offices. So there’s still, and will be, a significant part of the market that requires full blown blockchain technology solutions.

Choices

It’s much easier now. We have multiple options available in the market to quickly build an interface for readily available engines and the ability to use them.

We deeply believe you are not condemned to the usual extremely different choices between the slow but secure public blockchain or the private but much less trustworthy ‘local’ solution.

Sometimes it’s like a choice between ice or steam when all you want is normal liquid water.

As we proved with our partner Ubrich, there are ways to combine the benefits of both worlds in an effective way, marrying the contrasting requirements of trust and performance.

Future

Maybe we’ve just moved to the post-blockchain era where many of the promises will be implemented in more convenient and easier to use ways. I think all major database vendors should embrace the best of DLTs and add it to their database engines. That would address the majority of business cases, leaving the traditional blockchain solutions to special cases.

And again, the hybrid solution combines the best of what’s available here right now, and may be the way to go for your particular business needs. Avenga and our partner Ubrich are more than happy to help you make the best decision.