We are entering the golden age of supply chain traceability. It is now accepted that companies and individuals should be able to know what they are purchasing and under what conditions it has been produced. Now global brands, international organizations, and regulators are all pushing for global supply chain transparency.
Since the blockchain boom of 2017, technology companies, including Minespider, have rushed to lead this transformation, and a great deal of progress has been made. Now serious traceability projects are running in the mining and metals industry, pharmaceuticals, agriculture, textiles, and many more.
All of this is very promising. However, we are still in the early days of this transformation, with so many fundamental issues left to solve before traceable supply chains become the norm — instead of the exception. Nevertheless, the industry is already thinking ahead to solve tomorrow’s problem — interoperability.
I have participated in policy workshops, round tables, multi-stakeholder working groups, and trade organization meetings with some of the biggest players in the world. It is rare that a meeting passes without the question of interoperability being raised:
“Can we draft guidelines for interoperability?”
“Can we pilot interoperability next with multiple technology providers?”
Interoperability is such a hot topic because of the fear of a monopoly in supply chain tracking. This makes perfect sense from an industry perspective. Once a company integrates with a blockchain traceability provider it can be difficult to change, especially if they transformed processes to collect the right data, and had to integrate their ERP system to communicate with the blockchain. If global tracked supply chains will be the norm in just a few years, it is conceivable that one quick moving company will form a monopoly. They would be the sole gatekeeper to selling commodities in the global market, which would be a precarious outcome.
Interoperability is often hailed as the solution to this thorny issue. The idea seems like a no-brainer from a business point of view. If we allow each business in the supply chain to use whichever blockchain traceability company they prefer, we just need to have a set of standards to have these blockchains interoperate, and we can have a competitive landscape for supply chain traceability and a healthy ecosystem overall.
The only problem is that interoperability in supply chain blockchains is hard. Really, really hard. Hard enough that it is very unlikely that true interoperability would ever make sense to implement in real life.
The short answer is that blockchains are not databases. A blockchain is closer to a network of databases that all keep track of the same data. There is a common language, or protocol, between these databases that lets them communicate to ensure that the data is accurate.
The difference between a database and a blockchain is a little like the difference between a computer and the Internet.
We create a supply chain traceability blockchain so that the different databases have a common way to communicate with each other. This gives us confidence that the data is accurate and secure. If we say we want two supply chain blockchains to interoperate, it’s a bit like saying “we want to have two Internets that talk to each other”. It is hard to do, and in general, it defeats the purpose of having a common way to communicate in the first place.
If we were making two DATABASES interoperate, the process would be straightforward. Look at the data stored in database 1, and in database 2, and make a map that translates between them, like so:
Blockchains, on the other hand, might be thought of as a network of identical databases.
Below we can see an example blockchain keeping track of the flow of 5 tons of some metal from company A, to company B, C, and D. Let’s assume each company uses the blockchain and enters their own data when they make the transfer of material. For every transaction, the sending and receiving company both sign off that the transaction really did happen.
Each transaction of metal is recorded on each node of the blockchain. We cannot change the data in the transaction because there are identical copies of the data on the other nodes.
Now imagine D was actually using Blockchain 2. How could we get data between them?
If we do a database map like the first example, and just take all of the data from the last transaction and copy it over to Blockchain 2, and then just continue with D selling to E, and E selling to F down the supply chain we would get something like this:
Blockchain 1 has a record of the 5 tons starting at A, going all the way through B, C, and D.
Blockchain 2 has a copy of the transaction from C to D, and then onward through E and F.
In the above example, if we are company F, we have no record that our metal came from A, because we are not using Blockchain 1. Given that traceability is our goal, maybe when D enters the data in Blockchain 2 they should include the entire record of where it came from.
In the above scenario, D is using Blockchain 2. They enter all the data from Blockchain 1 (A → D) before sending their 5 tons onto E. Now F can see that the material is ostensibly from company A.
However, because company A, B, and C are not using Blockchain 2 and entering their own data, all F really sees is what D claims. D could claim they received 5 tons or 5000 tons, and F wouldn’t know the difference.
So what if we made a computer program to copy this data automatically?
This model means we no longer need to trust D to report accurately, but it generates new issues:
If we think about it, this defeats the purpose of using a blockchain completely. In the worst case, it would not be only two blockchains, but hundreds of them, and each company would be using a different one.
This means every transaction would need to go through a third party. We would achieve the same result more cheaply by just having a third party with a database and not using blockchain at all.
What if, instead of a third party, we had the developers of Blockchain 2 make some software that would read everything off of Blockchain 1 and copy it into their blockchain, so there was a record of transactions? And the developers of Blockchain 1 could do the same.
This is what most people think of with interoperability. A computer program automatically collects data from one blockchain and adds it to the other.
At this point we should note that this is indeed possible to do, but it is very hard technically to implement. Teams from both Blockchain 1 and Blockchain 2 will need to work closely together to make sure it is done correctly, and it is not clear how either can make a business case from doing so.
In the above examples we only looked at the scenario where the blockchains were very similar, and keeping track of the same data that may simply be named differently. However there are a number of ways that this can get even more complicated. For example, if:
The more dissimilar the blockchains’ designs, the less feasible it will be to have them interoperate.
If we return to the original purpose of talking about interoperability, the reason was to have competition between service providers.
How can we have that competition while avoiding the technological complexity of interoperability?
The answer is, again, like the Internet. Instead of multiple blockchains, we have one, but it is run by multiple service providers. Each different service provider runs a node of that blockchain. When a company uses the data from the blockchain, they can pay one of the many service providers for access, and the service providers compete to provide the best looking app, the best customer service, and the best insight into the supply chain. But all of them use the same blockchain protocol.
Blockchain is still an emerging technology. There is a lot of work still to be done before it can handle global trade in a proper decentralized way. It is important that pilot projects continue with different service providers so that we can learn what data is important to capture on the blockchain, how best to capture it, and how to scale it globally.
In the long run, there is only one realistic solution to having traceability and competition between service providers. There has to be an Internet-style solution of a single agreed-upon protocol, with service providers running their own nodes.