Blockchain alternatives [in supply chain and beyond]

Gartner estimates that in 2020 the blockchain hype will reach its peak and then drop into Through of Disillusionment. It is a phase in the hype cycle which brings the realization that expectations towards the technology were too high too early.

Before that happens, however, there is still a lot of buzz around blockchain and you may ask yourself – should I use it in my enterprise project? Will I miss out by ignoring it now?

If you’re considering using blockchain besides just simple experimenting and learning about the technology, you’re probably wondering what are its key properties that would make a difference when properly leveraged in your project. What’s more – are there more mature alternative approaches that would also work?

Let’s take a look at these properties and see if we can find any equivalents outside of the blockchain world.

Maybe there are some other technologies available that meet your expectations and needs in a simpler or more efficient way?

Ledger-like for full traceability

What is a ledger?

A ledger records all transactions that happened over time, not only the final state of your finances.

Think about the traditional bank account example. You notice the balance of your bank account seems a bit off. You could swear there should be more money, but somehow there’s not. How did that happen?

Maybe the bank made a mistake? Then you browse through the transaction history and suddenly you remember this LEGO® Star Wars™ set you bought but haven’t had time to assemble yet. If you didn’t have the full history of your transactions, you would have a bit harder time believing the balance of your bank account.

One of the fundamental properties of blockchain is its append-only nature. Most of the data stored eg. on Bitcoin blockchain is transaction events tracking BTC transfers between accounts.

The balance of these accounts is just a projection of the whole transaction history. In a more general case, you could store any events on the blockchain (not only financial transactions), assuming the underlying implementation supports it.

This property is often contrasted with the traditional approach to storing data in a database.

The infamous CRUD operations modify the data, and you get a new state of the database. The state you had previously is forever lost. It’s like updating the balance of a bank account without recording where and when you spent the money.

But hey, it doesn’t have to be that way. Event Sourcing comes to the rescue!

Event Sourcing

Event Sourcing assumes that all business events are captured and stored in an append-only manner.

You have a full history of what happened over time and you can always go back to debug problems, see the previous state or make temporal queries. These events can reflect far more complex business scenarios than simple money transfer.

At some point, of course, you’ll need to get the current, “flat” state of data, e.g. to display it in the UI. You usually don’t read it directly from the events, but rather project it into an appropriate read model.

All of this sounds very familiar. Does it mean that Event Sourcing is an alternative to blockchain? Well, no, it is something else.

Event Sourcing is an approach to building an application and blockchain might be one of the underlying technologies enabling it. But you can use another data store as well. There are a lot of other options for implementing the concept of the Event Store.

Examples:

• EventStoreis a database dedicated for this use case
• Martenhas a module that implements EventStore on top of PostgreSQL
• SQLStreamStoreis an implementation on top of MS SQL Server and possibly other SQL RDBMSes
• …and you can, of course, build your own

Note: If you are interested in Event Sourcing and happen to be a .NET developer, I can recommend the book “Hands-On Domain-Driven Design with .NET Core” by Alexey Zimarev. It introduces both the concept and implementation details.

Immutable

How does it work in blockchain?

Blockchain takes the immutability of data one step further than Event Sourcing on traditional databases.

It provides strong cryptography-based guarantees that the data, once written, can never be changed or removed. This property is embedded in the core of the data structure on blockchain and cannot be switched off or worked around by a rogue DBA.

Note: there are some exceptions to the immutability of written data, e.g. when your transaction makes it to the shorter chain.

If you need a strong guarantee of the data immutability, but at the same time consider blockchain an overkill for the scenario, there are other options you may consider.

Blockchain alternatives for ensuring immutability

• One option is to implement some measures yourself, e.g. using digital signatures to ensure data consistency and prove its origin.
• Another option is to use a database that already has some mechanisms in place.

Let’s take a look at two examples here.

ProvenDB is a document database that should be easy to use for anyone familiar with MongoDB. In ProvenDB, any data written creates a new database Version. All previous versions of the database are still available and can be browsed.

But what is more important, a version can be anchored to a public blockchain (in most cases Bitcoin). This means that you can prove certain data existed in your database at a certain point in time. If the data was changed, that could be detected by comparing the Proof stored on the blockchain against the Proof calculated from the state of the database.

ProvenDB uses Merkle Tree to calculate proofs and Chainpoint format to store them on the blockchain. Instead of writing all the data to the blockchain, just a single hash is written. Of course, writing to public blockchain has its cost in time and money, so not all versions of the database should be anchored.

Let’s say you don’t want to deal with a public blockchain and trusting a single central authority like a cloud provider is enough for you.

In that case, you might try Amazon’s Quantum Ledger Database. This database keeps a cryptography-based audit trail of all changes to the data and the underlying structure is an append-only journal.

Note: data immutability is not always the desired property. For example, GDPR law requires you to remove a user’s personal data on demand, if you no longer have a reason to process it. If you decided to store this data on the blockchain then… you are out of luck.

Distributed

The actual blockchain vantage

Amazon’s QLDB is a great example of the trust vs efficiency problem. It is fast and easy to use compared to blockchain. It is also a fully managed service, which is very convenient. But you have to trust Amazon to keep everything in check – they own the encryption keys.

In theory, a rogue Amazon employee could tamper with the data because it is centralized and there are no other parties to validate it. Although I’m pretty sure they have procedures in place protecting against such malicious behavior.

Another aspect is that solutions like ProvenDB or QLDB will work only if there is a single trusted writer of the data.

If you have multiple organizations with limited trust towards each other, all making writes to the data, that is a completely different situation.

I would argue that the distributed nature of blockchain is its main advantage in the environment of limited trust.

If you need to ensure that:

• multiple parties writing data must all adhere to previously agreed rules,
• everyone gets a copy of the data
• and data cannot be manipulated

…then blockchain is worth considering as an underlying technology.

At the same time, the distributed nature comes at a cost. The blockchain consensus algorithms increase data write latency by orders of magnitude. This could be seconds in case of private blockchain or minutes in case of a public one.

The storage is also a problem because now each node in the distributed network needs to keep a full copy of the data. The storage capacity of blockchain does not scale with the number of nodes.

Blockchain alternatives for building trust across actors

BigchainDB is an interesting take on the subject, that attempts to remedy the problem of scalability while retaining properties of decentralization and immutability.

It combines a regular off-the-shelf distributed database with a blockchain-like validation mechanism. The data model in this database is a bit limiting though, as it focuses mostly on asset creation and transfer. This very interesting paper explains the architecture and design choices.

Some sources also bring up the aspect of reliability when talking about blockchain as a distributed ledger technology. Having tens, hundreds or thousands of copies of the data in different geographical locations make the network immune to node failures. Personally, I think in most cases such redundancy is not needed and a reasonable level of redundancy can be achieved with other means.

As an alternative, cloud providers usually offer highly redundant databases that can be replicated to multiple geographical locations. One example is the Azure CosmosDB.

In conclusion

Blockchain technology brings together a very powerful combination of features that are game-changing in some scenarios.

For example, Tradelens – the widely used container logistics platform for managing and tracking the supply chain of goods transported by sea, created by Maersk and IBM, uses it to store hashes and ensure the immutability of documents.

This way smaller and big industry players can cooperate smoothly knowing that blockchain not only guarantees reliability and immutability of data stored in the system but also flattens the disproportion of size and power between the players by ensuring the unmediated democratic access to data.

In other scenarios, however, the cost of using blockchain might be too high when considering the current state of the technology. If you only need some of the blockchain features, like ledger data structure or immutability of data, you may be better off using alternative approaches.

For example blockchain in supply chain management is expected to bring unprecedented transparency and security, drive efficiency, help automate commercial processes and reduce the complexity of doing international trade.

But, as I tried to present above, at this stage of development some of those goals can be obtained eg. with the use of event sourcing, specific database architectures or digital signatures.

If you need some help in deciding whether it is worth developing your solution with the use of blockchain or would it be better to rely on some other technological solutions, just use the contact form below and get in touch with Skyrise.tech.