Skip to Content
Author's profile photo Thomas Steinmetz

Business Opportunities and Caveats of Blockchains – Part 1

As my colleagues already wrote in the recent blog posts Will you recognize innovation when you see it? and The blockchain voyage, the SAP’s Innovation Center Network team is currently evaluating the blockchain paradigm in a business context. As part of this team, it is my role to assess technologies and use cases to be integrated within SAP software. I would like to share some thoughts about the business opportunities and caveats of blockchains. I’m happy to discuss them with you.

As I have a technical background, I picked out some of the more technical aspects of blockchain and evaluated them with business in mind. I’ve split up the post into two parts, talking about trust, transparency and data-security in the first part. In the second part, I’ll focus on performance and the revocability of transactions, and finally conclude both blog posts with my personal opinion about the usefulness of blockchains in a business world.

Please be aware that both posts talk about public blockchains, i.e. permission-less blockchains. Private/Consortium/Permissioned blockchains are not yet covered by these posts and might follow soon. The different bullet points show a first indication of how helpful ( + ) or painful ( – ) a blockchain would be in the business.

Trust & Responsibility: Nobody should be trusted?

With blockchain technology you can reduce the need to trust someone: You could agree on terms and trigger a transaction, the network commits it and after some minutes everything is rock-solid. But my personal opinion is that trust cannot be completely erased – nor should it be.

There is always a certain level of implicit trust in the world and in every business transaction. If you buy something on the market, you always have to trust that the quality of the good is what you expect. Even if a fruit looks fabulous, it doesn’t mean that it tastes good or that it is not foul on the inside – or that the price is reasonable. In the real world, you could always walk back to the trader and complain about the foul apple. I would guess in more than 90% you would get a new one. For more complex scenarios humans try to embed all the eventualities in a contract. But even then, both parties think differently and understand terms differently – ultimately fighting at court for their rights.

With a blockchain, this is no longer possible: You commit something that can’t be revoked, so you’ve to be sure about the terms of trade. It is believed that Smart Contracts might be an answer to the trust problem, because a decentral instance is evaluating the terms, and triggers predefined actions all parties know about. Problem would be, that in addition of trusting a lawyer you now also need to trust a Smart Contract developer for setting up and understanding a contract. Even then, you have to trust the network to take the correct actions – there also might be bugs which influence decisions or trigger wrong actions.

However, once there is a bridge to the “analog” world, you will usually encounter obstacles. Let me make an example: If you buy something with Bitcoin and have it delivered to you, how could you trust that the good is really delivered? Even if you would have a chain of signatures that the delivery service got the parcel and it was correctly delivered, who could tell what is in that parcel? Or even if the content is the one you think you bought and that it is working? Those are certainly no blockchain specific problems nor even new. But it is what influences the scenario and its applicability in real life.

Transparency: The showdown of data

A basic concept of a blockchain is the traceability of all transactions back to the very first transaction. This is needed to validate the complete chain and to have a holistic picture about the state of the network. Every block also incorporates a cryptographic hash of the block beforehand. This means that every node which extends the network must have access to every bit of all the blocks of the blockchain – in order to validate the integrity of the blockchain and its transactions. This also dictates on how one can use and share data on the blockchain.

Let us take a look at some of the points:

There is no access control to the data and also no license agreement how to use the data: every entity which has access to the blockchain’s data could replicate the data for their own use/abuse.

This could have some severe impacts on legal aspects, for example if there is illegal content in the blockchain, may you or your company further share the content?

Although blockchains create transparency about the data, they do not create transparency of the data usage – there are no access control logs or anything related.

Nobody knows how many times a blockchain was downloaded, accessed or analyzed. For public content this is generally good, for content intended to remain private this can be quite bad (see below).

Secrecy is not possible, but is usually needed in business
Secrecy is part of our community, and also important in the business context: competitors must not be able to read recipes, numbers or contracts. Ultimately this leads to trust, because you won’t tell someone a secret you don’t trust.

Transparency is a good thing – most of the time

In a transparent world, misuse of assets could be detected by everyone. Information hiding leads to abuse, corruption or misinformation of the public. This would not be possible anymore with information stored on blockchain.


Everybody has access to the data, so they could check upfront if you tell the truth, have enough assets, etc…

This is especially important if systems are not integrated with each other. Think about crossing a border and having your passport checked by the country you arrive in. Blockchain won’t substitute the passport check, but it would ease up the process a lot. The same goes for credit proposals – a bank could just ask you to reveal your blockchain identity (or identities) to them, with all the attached assets and liabilities.


Generally, there is no central point of failure. Which is good when thinking about backups, cyber-criminality, disaster recovery, or load distribution.

Even if whole parts of the network break down, nodes could still operate and have to find a consensus when every node is back online.

Trust and transparency go along with each other. If you have a trustless world, everything must be transparent, otherwise you can’t control the process or outcomes. If you have secrets, you need to trust the persons to not tell anybody. Like the “trust bridges” mentioned above, there might always be the need for disguising or hiding transactions to the public – think about military spending for example.

Data Security & Privacy: Everything is secure – for now…

Because blockchains are shared publicly, one of the most important data-security aspects are gone: the access control on data. Now people are trying to find a way around this obstacle and use cryptographic algorithms on the data shared in the blockchain, to only allow access to certain individuals. For example, you can use Steganography to hide the existence of data inside the blockchain or just simply encrypt it with the strongest encryption algorithm out there and hope nobody cracks it.

However, there are still some data security drawbacks which highly influence the business capabilities:


Data in a transaction could be encrypted by an author so that only the recipients could read it, but then users or nodes could not verify or validate the data in terms of consistence.

Bitcoin is based on checking the balance of a wallet by summarizing the values of all transactions of a wallet, which would not be possible if these values would be encrypted.

Even if you encrypt data in order to hide the content of your transactions, the transaction itself or the count of transactions to a recipient could mean a breach of privacy.

Think about a retailer selling every good via blockchain transactions. Everybody (including competitors) could see how many customers the retailer has on which day or even which good sells best.

The anonymity or pseudonymity of accounts using a blockchain might complicate a potential data-sniffing attack. However, good analysts can always extract valuable data out of even a multitude of anonymous accounts. Companies would need to have account-management systems to hide their transactions – or be completely public.

Even if Satoshi Nakamoto is unknown, the community was able to retrace some transactions back to some wallet ids which are believed to be in possession of Satoshi Nakamoto.

Because you can’t change anything in a blockchain. passcodes for encrypted data cannot be changed. That means there needs to be a passcode management system for encryption, creating new passcodes for every transaction stored in the blockchain.

But how to keep track of the passcodes and who has access to them?

Furthermore if you encrypt data, you can’t guarantee that the best encryption algorithm nowadays is still good enough in 10-50 years.

Also think about the random number generator problems in some tools, what happens if the encryption tools have bugs which will severely weaken the security of their encryption?

And even if you could ensure the highest security, there is always the chance that passcodes are leaked – either accidental, by fraud, by bribery or by hacking. Once passcodes are leaked, the information is public with no chance to restrict the data loss.

Original Snowden Wiki leaks where shared encrypted over P2P networks and therefore stored de-centrally.  Only few people had the key and they controlled what was ultimately released and published in the media. Unfortunately a journalist wrote a book about Julian Assange publishing the original key. As everything was still out in P2P networks this information was now publicly accessible – which was clearly not intended.

Finally, if somebody loses his or her keys the data is most probably gone.

There is nobody out there one could ask for resetting a password or copy data from one account to another. For bitcoin, your wallet would be lost and all your money with it.

It is clear that blockchain has some big disadvantages here – which might be relevant or irrelevant to businesses, highly depending on the scenario. There are scenarios where data security is not really important, because for example only hashes of the original data is stored. There are also scenarios where data is split up into “data-atoms” which by themselves won’t make sense but can be combined with the correct sequence. In the end, these are well known problems for the cryptographers since centuries… but still not completely solved.

Most of the points discussed in this chapter are tightly coupled to encryption in general. One could argue that most of the Internet traffic nowadays is still unencrypted and that the currently used encryption algorithms of highly sensitive websites are less secure than anything which could be used for storing data in the blockchain. Yes, in the end it all boils down to the one single fact that an attacker already has the access to the data due to the nature of the blockchain. Brute-forcing your transactions is then using the proof-of-work paradigm just differently.

To be continued on part 2.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Bravo, I really liked the business aspects you presented in your post. it gave me an additional angle to look at the Blockchain technology.

      Author's profile photo Former Member
      Former Member

      This is very good read and am so happy SAP has started looking at the potential of this technology. What i love about this concept is the  transparency, traceability and security aspect of it. I beleive the immediate application of blockchain can be in government and NGOs where it is necessary to have all earnings and spends seen by everyone on a very safe platform that cannot be hacked. This will be possible once we have a solution on keys to use and not being able to loose key which soon will be possible i believe