Technical Articles
Blockchain – Leveraging a Standard
A few months ago, I wrote a Blog Post on the Blockchain Essentials. In todays blog post, I will focus on the usage of the Blockchain, more specific I’ll treat Blockchain as an existing standard.
As a guideline, please assume that the two Essential Blockchain Capabilities are available as a standard in the Internet and you can use a wallet to access the capabilities.
A Standard
When talking about Blockchain with a friend who is working in the cable industry, he gave the right impulse. If Blockchain wants to scale, you need standards – he had similar experience with high-voltage cable before a standard was established – each company had to build each cable twice, as they needed one for testing the specifications. With the standard, the cable only needed to comply with the standard.
Take a shipping container as another example. The value lies not in what it is, but in how it is used. The container is at the core of a highly automated system for moving goods from anywhere, to anywhere.
Instead of discussing Blockchain capabilities let’s focus on using these capabilities.
Single Source Of Truth standard
All Blockchains provide immutability – everything that is written in the Blockchain stays there forever. This means that there is one shared state – seen by all parties who can access the Blockchain – which can be viewed as single source of truth.
Bank Account example
Take your bank account as a simple “Single Source Of Truth” scenario. Instead of using an IT system that manages your bank account, the bank account uses a Blockchain to manage all its interactions. The interactions are
- Bank Account gets created by the Owner
- Bank Account receives money from Sender’s Bank Account
- Bank Account sends money to Receiver’s Bank Account
Interactions in the Blockchain space means a Wallet interacts with the Blockchain which will lead to a Blockchain transaction.
The wallets which can interact with the Bank Account are
- Wallet of the Owner
- Wallet of the Receiver
- Wallet of the Sender
The following table shows the “History” of all interactions with the Bank Account. It assumes that BankAccount2 (owned by Sender) and BankAccount3 are already existing.
| Wallet | Timestamp | Interaction | Data | Transaction ID |
| Owner | 20.10.2022 14:32:01 | create | – | 1 |
| Sender | 20.10.2022 14:33:02 | receive money | 100 from BankAccount2 | 2 |
| Owner | 21.10.2022 08:23:22 | send money | 70 to BankAccount3 | 3 |
| Sender | 22.10.2022 11:17:45 | receive money | 20 from BankAccount2 | 4 |
The interactions with the Single Source Of Truth are logged in the Blockchain and you can “replay” all interactions to get to the current state.
In the example above, the balance of the bank account is calculated by using all interactions starting from the creation of the bank account. The “receive money” adds money to the balance and the “send money” reduces the balance.
The current balance is: 100 (Transaction 2) -70 (Transaction 3) + 20 (Transaction 4) = 50.
ERP Process Example
Let’s take a simplified ERP process and apply the “Single Source Of Truth” standard.
Simple ERP Process
The process diagram above shows two companies who collaborate with each other. Each company executes some tasks of the process. In todays world, each company would run an ERP system where they store their parts of the process.
The companies assume that the truth about the process is stored in their IT system.
This may lead to multiple truths – like Company 2’s ERP system may show that the payment was done while Company 1’s ERP system shows that the payment was not done.
Here is the updated process diagram using the Blockchain Standard.
Simple ERP Process with Single Source of Truth
The Blockchain standard is visualized as a pool between the pools of Company 1 and Company 2. Each company uses their Blockchain Wallet to interact with the Blockchain based Single Source of Truth.
The wallet of Company 1 creates the Single Source of Truth for the invoice. The following table shows all interactions with the Single Source of Truth of the invoice.
| Wallet | Timestamp | Interaction | Data | Transaction ID |
| Company 1 | 20.08.2022 14:32:01 | create | – | 1 |
| Company 2 | 20.08.2022 14:33:02 | receive invoice confirmation | – | 2 |
| Company 2 | 21.08.2022 08:23:22 | receive payment | – | 3 |
| Company 1 | 22.08.2022 11:17:45 | receive payment confirmation | – | 4 |
If Company 1 or Company 2 wants to know the status of the Invoice they will ask the Single Source of Truth or you could say “They ask the Invoice“. As the invoice is using Blockchain it cannot cheat.
Your Single Source of Truth Use Cases
Now it’s time for you to be creative. What are your use cases for the Single Source of Truth standard based on Blockchain? Where do you need the Single Source of Truth ? What are the business benefits that you would expect?
Please feel free to post any questions regarding this topic in the Blockchain community or approach us directly:
Frank Albrecht (Developer, SAP Innovation Center Network)
Where do I see the need for the Single Source of Truth in form of a Blockchain?
The main technical aspect under which any candidate scenario should be examined:
What would be the benefit of a blockchain-based solution over a central authority solution?
And a follow-up question about the business case should be:
Does the party that has to pay for it benefit from the blockchain solution?
Thus, I am not so sure, if, e.g., banking will appreciate blockchain solutions. Here, it's usually one central authority - the bank - dealing with many, usually smaller business partners. The bank would have to pay for the blockchain approach and the question is, if it gans any benefit over a central authority approach.
I'd see a benefit and a need in blockchain scenarios where processes among equally weighted, equally influential, equally responsible players happen. For example, these could be large-scale coopetition scenarios. An example I know from my Geology days could be claims management in oil, gas and other natural resources. These claims are often shared by competing organizations in the per-exploration and exploration stage and sometimes even when productive.
Hello Karsten, thanks for the comment and the two questions.
1. Where do I see the need for the Single Source of Truth in form of a Blockchain?
I talked to SAP customers about their thoughts. One argument focused on accountability. The customers said that they are responsible to ensure the immutability of their data/IT solutions - and this creates yearly costs. They want to shift this accountability to "we are using the blockchain" which will save them a yearly investment. Like "we are using https" instead of "we have created a great secure encryption" - that we need to maintain for its complete service life.
2. Does the party that has to pay for it benefit from the blockchain solution?
The idea of the standard is to create a new marketplace where this question can be answered. Each one can leverage the standard and evaluate the business benefit - without the need of huge upfront investments and infrastructure operation costs.
Hi Frank!
If the blockchain really saves customers money in the area "ensuring immutability" then that's obviously a valid argument, as it would automatically answer question 2 with "yes".
The transparency and transaction finality of blockchains is hard to beat. It could really deliver some extra benefits of non-repudiation in business process.
The privacy aspect is a big one to consider, as by blockchain's nature can't change data in previous blocks and there would be certain data from the ERP of the invoicing and payment process you wouldn't want to directly place in the blockchain.
One area that I'm actively building is a zero-knowledge (ZK) solution for ERPs. ZK has a well established record not only for privacy protection but enhancing the scaling of blockchains as well.
Scaling is a big issue too - the entire weight of the transactional volume of even a single large ERP could very well crush and break many blockchains in the marketplace.
If you're interested in building out the use case - I have an open source abapGit repository I maintain called proUBC that incorporates zero knowledge and smart contract integration for S/4 HANA. Give me a shout if you want to learn more!