Blockchain projects are springing up like mushrooms. However, there has never been a real, decentralised, private blockchain network in practice. Until the project participants went ahead and created one. We report on the technology used and the architecture of the pilot solution, and provide insights into the findings of the practical test.
The pilot project initiated by GS1 Germany was primarily intended to test blockchain technology using standardised pallet notes as an example. But what is behind the blockchain technology applied? And, of course, how well did it all work?
Blockchain has the potential for forming an ecosystem at the process level – in this case, for an exchange process involving reusable load carriers. The great advantage of the technology is that data can be shared confidently in a network of independent parties without an individual participant (such as an intermediary) ever having full data sovereignty (the ability to view and manipulate the data). This forms the basis for efficient digitalisation of complex, sensitive processes.
Furthermore, creating a shared, consistent global process framework greatly facilitates communication and consensus-finding in problematic situations, creating trust and, in the best-case scenario, promoting behaviour that conforms to the rules. Another project goal is to show that selective sharing of data can highlight further optimisation potential, specifically looking back at things.
Currently, there are many blockchain technologies that lend themselves to the enterprise environment (private permissioned blockchain, a blockchain form in which access is restricted), but they vary greatly in complexity and functionality. Examples are:
The blockchain technology used should always reflect the requirements of the use case. This is why, for this project, we consciously chose the simplest technology that could be used in the pallet note scenario – MultiChain. MultiChain is derived directly from the Bitcoin blockchain, but does not share its disadvantages (such as low throughput and high energy consumption). This solution also enables an easy understanding of the original blockchain concepts. A heterogeneous MultiChain network is set up so that the concept of decentralisation can be evaluated without specialist IT knowledge or a major investment of resources. All other blockchain technologies are much more complex and costly to operate. Of course, MultiChain’s simplicity has its price: a pre-defined programme code (such as smart contracts) cannot be executed on the blockchain. Furthermore, it wasn’t designed to support restricted data visibility, which makes such restrictions complex to implement. The blog article on technological considerations for future deployment goes into this in more detail.
The project participants were able to choose whether they played an active or passive role in the blockchain network using various channels:
During the development phase, the team initially focused on needs analysis. It proved beneficial to focus on the end users (user-centric design) and derive the process and procedures from their needs. A first workshop, attended by a large number of the later pilot participants, resulted in a detailed description of the process and initial drafts outlining the functionality of the application.
This rough description served as the basis for the design of the final application. ‘Design’ has a number of meanings here, since it was not only screens that needed designing, but the procedures in an application. This resulted in the following tasks:
During the development phase, long after we had considered the user needs, we also came up with several more interesting ideas. This explains why, for instance, quick identification using a GS1 QR code was only tested and validated with the companies’ representatives during the development process. The final version of the high-fidelity design, therefore, came very close to the application used in the field test.
The data model was planned to be oriented closely around the GS1 EPCIS standard – which was, incidentally, one of the participants’ requests. The transactions themselves were no problem at all, but correcting transactions and dealing with the special case of exchanging via a pallet service provider proved trickier. At the end of long discussions, with smoke coming out of our ears, we finally managed to bring the standard and the blockchain together. You can find out more about the GS1 standards used in this blog article.
A blockchain-based application is not fundamentally special in architecture or design. But there were a few things that required attention:
We decided to use MultiChain streams, based on the possibility of throughput optimisation. In other words, each pair of exchange partners essentially had their own ‘table’ or ‘virtual blockchain’ to avoid having to bring all transactions into the usual order required for blockchains.
Transaction proposals themselves should not be permanently written to the actual blockchain, or rather, the relevant stream. This is why we agreed on a special ‘proposal’ stream to enable a decentralised exchange of proposals. Any other form of communication, such as a message queue shared between participants, could be used as an alternative. However, in our case, this would only have increased complexity unnecessarily.
To reach a consensus among partners about the content of a transaction, we decided to use multi-signature transactions. This means that both exchange partners must sign with their private key to complete the transaction.
An integral component for testing the blockchain technology is the user interface of the pallet exchange application. The operability of the prototype was evaluated via a usability test before the pilot phase and improved based on the feedback. This ensured that data and transactions were stored and that operator error returned insufficient data or none at all. The usability test showed us that, for example, text legibility is critical for older users and that the font size we had selected was too small. It also showed us that many forwarding agents work internationally and that we therefore needed to incorporate more languages if all user groups were to be able to operate the application. The optimised draft then went into the pilot phase and was tested in the field in parallel to the day-to-day paper-based operations.
“Simple to use, sometimes slow to save data”
Project Manager Logistics, Dr. August Oetker Nahrungsmittel KG
The speed of the application was perceived in conflicting ways. Most users were coming into contact with blockchain technology for the first time. During our pilot project, participants compared saving to the blockchain with their experience of the internet, where normal response times are in the low two-digit millisecond range. Because it took a while for the exchange partner to be able to see the proposed transaction, participants perceived the speed of exchange as slower than what they were used to. Nevertheless, the real-time processing of the transaction, the clarity of the information, and the transparency of the exchange process were all perceived as being very advantageous. Project participants believe that there is optimisation potential, especially with regard to downstream processes.
Based on the initial usability tests, companies participating in the pilot phase were sent a questionnaire after testing the application in their routine operations. The following feedback was received:
Responses underlined the application’s ‘attractive and intuitive design’ and also included feedback on functionality.
The construction of the core network marked the real start of the test. The services provided via the SAP Cloud Platform allowed the network to be set up quickly, before connecting the other project participants.
Both subjectively and objectively (based on the survey), the installation and integration of MultiChain nodes ran very smoothly. After the actual installation, we began connecting to the existing part of the network. In other words, the administrator of the specific node ran a command in the command line – which needs to include the name of the blockchain and the physical address (IP address) of a node that is already being run. In non-public networks, this command issues the address (wallet) of the node. As soon as this has been approved by the other party (white list), the connection is established.
During the actual field test, we were unable to push the blockchain to the limits of its performance – there were simply too few transactions for that. Nevertheless, the results are fascinating.
Overall, we mapped 590 real exchange procedures between 19 exchange partners over the course of two test weeks. Every day, drivers, logisticians, and back-office employees recorded more than 50 new transactions. The number of transactions was spread relatively evenly across exchange partners during the pilot operation, although the logistics participants had a slight majority.
Minor problems such as faulty log-ins, display errors, and problems with blockchain communication were either solved or worked around with other solutions.
The 590 transactions mentioned were very evenly distributed over time. There are daily peak cycles and a noticeable drop in activity over weekends. Both of these phenomena can be explained by the limited framework of the test, involving 19 test partners.
The CPU of a MultiChain (small plan) instance on the SAP Cloud Platform has a constant load of about 40% – a very respectable value, since no load spikes occurred, even during the load test (see below). The main memory had a very balanced load at 30% and is thus a reserved value of the MultiChain instance, since it does not appear to fluctuate based on use. Throughout the entire test phase, at least 11 (and no more than 13) nodes were connected in the network.
We were often met with a great deal of scepticism regarding the latency in reading from and writing to the blockchain, since this aspect has a certain reputation in public blockchains. In our case, observations fell into the categories of proposal and confirmation. For transaction proposals, the waiting time was constant at roughly 700 ms (0.7 s), while confirmation required about 1.7 s. This is primarily due to the implementation of our solution, which requires multiple writing operations in various streams to enable confirmation. There was a global error rate of 0.2% – cases in which the MultiChain network did not react quickly enough, for example.
Another important point is the storage space used. A transaction (an exchange) takes a total of about 6.4 kB of storage on the globally replicated MultiChain. In other words, the 543 exchange transactions in the field test generated about 20 MB of data. The difference arose from indexes, volatile data, and caches.
The load test
As mentioned above, because we were didn’t come anywhere near to the performance limits of the blockchain network during the field test, we decided to perform a load test on our blockchain network as a follow-up. This test was performed with an increasing number of transactions – up to one exchange per second. The results were very positive here, as well.
As previously mentioned, CPU load, storage use, and latencies did not increase during the load test, providing positive feedback for the technology used. The test itself ran for 24 hours at an average load of one transaction per second. A total of 116,665 exchange procedures were simulated. Around 700 MB of data were generated during the tests. Even at this high load, the error rate remained constant at 0.2% of transactions.
Conclusion
In both field test and the load test, the project returned a very positive technological conclusion. The technologies in direct focus were tested successfully, and the blockchain network was set up quickly and used without complications. This explains why almost all participants decided to run their own node, either in their own data centres or in the cloud. It was a great result that underscored the feasibility of decentralisation while providing good reasons for choosing MultiChain as a blockchain technology. No participants needed to solve problems with the blockchain or restart their own node during the test.
“The idea behind the application, if introduced on a large scale/in the whole industry, has the potential to greatly improve an outdated, cumbersome and inefficient process. The app fulfils the necessary requirements. It is critical that implementation in existing systems is as simple as possible if it is to be widely accepted.”
Forwarding Manager, DHL Freight GmbH Hamburg
Most participants (8 out of 11) also confirmed that they enjoyed working with the pilot solution and would continue to use it in future. This is probably because we were able to show that digitalisation does not always have to involve a loss of control and high barriers for users. A strictly user-centred design in the initial definition process, interim user tests and flexibility in designing the project framework all contributed to this fantastic result.
However, our conclusion is somewhat more nuanced with respect to blockchain as a technology and the way in which it is currently implemented. For instance, most participants ultimately state their preference to limit transparency of exchange transactions – which makes this an issue to be addressed in the event of further deployment. The use of the GS1 standard was very well-received, however, especially with respect to the integration of a pallet-exchange system in its own system landscape.
Project participants believe that digitalising the process brings significant added value; however, the greatest potential to be exploited lies after the actual pallet exchange. It now remains to be seen how a true consortium can be developed from the project – perhaps the greatest potential here also lies after the pilot project?
SAP
Comments
No Comments