blockchain SAP bitcoin [shutterstock: 1079935373, Visual Generation]
[shutterstock: 1079935373, Visual Generation]
Blockchain Blog

Blockchain: Where Are We Now?

Many years back - when I was still working for SAP - the blockchain hype started to pick up, and SAP analyzed its potential. Back then, I though that blockchain might be a nice concept for some cases at the edge but provides no advantage for broader use.

Accordingly, I expected the hype to cool down quickly. Evidently, that did not happen. In fact, in recent months, I had multiple conversations, all centered around the same arguments. Hence, I would like to write up some thoughts for anybody considering a blockchain project.

As somebody with a mathematical background, the first logical step to me is to define the term blockchain: a distributed ledger with append-only, where no central entity can be trusted. Only when all three factors are in play together, the system deserves the title blockchain. In all other cases, a database with the required qualities is the cheaper alternative.

Blockchain makes change impossible

An important component of a blockchain is that each block contains the hash value of the previous block as part of the payload and hence of this block’s hash value. This way, an old block cannot be changed as all subsequent blocks would show a wrong hash value. Reducing the term blockchain to just this aspect is dangerous. Firstly, blocks can still be manipulated. All that must be done is modifying the desired block and recalculating all subsequent blocks. This creates an alternate branch of reality, e.g., one where my payment never happened. To prevent that, the distribution aspect is required. Secondly, if “prevent changes” is the only requirement, it could also be implemented with databases. Every row has the hash value in one column and its value is based on the current row and the previous row. This is relatively easy to implement, especially if using an Oracle database: CREATE BLOCKCHAIN TABLE… But here as well, recreating the blockchain table is one line of code, it just takes a while.

However, if that is the case, then the chain is just another way of enforcing permissions. Using a regular table with insert-only permissions would achieve the same outcome.

Nobody can be trusted

If there is no central authority to be trusted, the truth must be negotiated between all parties for every change. There are various ways to implement that: proof of work, proof of stake, qualified majority, consensus. However, before using blockchain to solve a business problem, one should ask: Can all involved parties, including the entity overseeing the system, be trusted? One use case I discussed recently was a government land register in the form of a blockchain. By definition, there is one party overseeing all entries. If this government agency cannot be trusted, we have an entirely different problem. So, what is the value of using a blockchain, then?

There is a similar argument to be made in logistics by example of proving that the food container never exceeded a certain temperature. The logistics company has many options to manipulate the data; for example, they could disconnect the sensor or manipulate data during entry. We must trust them despite it. Just protecting the system record from later changes provides little additional security.

The blockchain system SAP developed in BTP targets business cases where multiple businesses work together as equals. From a trust perspective, all must agree to the same truth, but there are just two or three parties. A distributed database can achieve the same but at lower costs.

From this point of view, the arguments in favor of the central reserve bank issuing money via a blockchain are odd. Why would the bank need to use blockchain? Because the central reserve bank cannot be trusted? Sure, you can use blockchain technology and, given the volume, it might even make sense, but any other highly scalable distributed database would work just as well.

Smart contracts

The concept of smart contracts is something new and interesting. Essentially, it is the ability to add code in the system of record which is executed in the case of events. Ethereum is the best known blockchain with this functionality. It can store code and execute it. In other words, it consists of two parts, a trigger and a stored procedure. Hence, the technology also exists in databases, it is just a matter of how you use it.

Summary

Per my arguments, the blockchain is a very expensive implementation for storing and updating data. The same can be achieved using a distributed database; in many cases, even a single database is sufficient. Only the most extreme use cases, where “no trust”, “impossible to change” and “highly distributed” are the requirements, the blockchain concept provides enough advantages. For all other use cases, you could use blockchain, but there are cheaper methods.

Addendum: Bitcoin

Finally, a few thoughts about Bitcoin, as this is often seen as synonymous with blockchain.

To avoid a fraudulent party to recreate an alternate reality, it is using a proof-of-work algorithm. This is highly inefficient in case of the Bitcoin protocol, but that is not the fault of blockchain as such. Alternatives exist, each with their own pros and cons.

The weakest link in Bitcoin is that the reality validation happens via a 50 percent majority vote. Today, the two largest mining farms together have more than 50 percent validation power. We must trust that those two do not join forces to steal some money here and there for some add-on profit. Which contradicts one of the key pillars of the blockchain – nobody can be trusted.

As seen from a money theory standpoint, there are also a few questionable arguments. Bitcoins are independent from the central reserve bank’s manipulations, that is true. The task of the reserve bank, however, is to keep the volume of the circulating money constant. That is the important point: It is not about the number of bank notes, it is about how often they are used. Simple example: In scenario one, I get 100$ and keep the money. In scenario two, I buy something for the 100$, the seller themself buys something, their seller buys something, etc. Obviously, the amount of money spent is different in those two scenarios.

As we cannot force how often a 100$ bill must be spent per year, it requires a corrective. The reserve bank adds and removes money to keep the circulating volume of money constant. Well, almost constant. There should be a slight nudge to rather spend money – an inflation of 2 percent. To summarize, the reserve bank is responsible to keep the inflation rate constant and low. Otherwise, money would lose its use as a neutral exchange unit. With a purely Bitcoin-based financial system, each minor crisis would result in a major one, and a prospering economical period would turn into an overheated market.

So yes, no reserve bank at all is better than one with its own agenda. However, an independent reserve bank is better than none.

Another claim is that money that is not backed by a physical equivalent, usually gold, can by created whereas Bitcoins are limited. As the volume of money is constant, each 100$ bill is a document proving its owner has the equivalent of a part of the gross input product of the country. In case of Bitcoins, the owner has a bunch of zeros and ones. The value of a Bitcoin is defined by pure believe in its value, the current balance of supply and demand.

About the author

Werner Daehn, rtdi.io

Werner Daehn, former SAP employee, is an expert on big data and smart data integration. He is also the CEO of rtdi.io.

Add Comment

Click here to post a comment

Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy.termsandconditions.

Our Authors