Reply to post: This was never a suitable project for Blockchain

This was never a suitable project for Blockchain

The lofty ideals behind TradeLens hold true. There is a mess of paperword, where errors cause disruption to supply chains and increase costs. The need to do something here is not dispiuted. But this was not a use case for a blockchain. The actual parts behind TradeLens are a smart contract, which is based on a blockchain, in this case HyperLedger. But it doesn'nt need to be.

The problems that TradeLens faced are multiple. But a couple are easy to point out. This was a closed community where a finite number of players trade with each other. They are all ananonymous, but have a fixed account code / wallet address. Despite thsi being a long string of numbers, it is noit beyond the wit of man, nor a simple computer to work out that if 1234 was TradeCo1 today it will be tomorrow. I know this because I traded with TradeCo1. Now I trade with TradeCo2, whose address is 9875. Oh look I can see that 9875 has a trade with 1234, so I can deduce the TradeCo1 is working with TradeCo2. And because its a shared ledger, everyone can see this. This is a major problem for trading companies who like to keep all their trades secret. So the first problem is that TradeLens ingtroduced too much transparency. It meant that Maersk were perceived as having too much visibility of all the trade chains, and thus gave them a market advantage. That is reason one why it was not widely adopted.

The second is the concept of the distributed ledger itself. To play on the blockchain you need to have a node where your part of the ledger resides. These are computers. Possibly several working together if you want some form of redundancy, and most traders do. These are not just simple applications that you run, backup and forget. You have a ledger that is growing with each trade, even if you don't participate in that trade. It needs management, backup, security, and all the other good things that data centre managers need. But because this is all encrypted, and you con't know all the keys, you can't get under the covers to manage the backups. As this was IBM, it is highly likely that DB/2 was that database. Thats not helpful when your whole company is an Oracle / MYSql / Postgres shop (other databases are also available). So now you have a bit of complex, mission critical computering power in your data centre which you know nothing about.

The solution to this is to outsource the management of your node to, well, TradeLens. They can run and manage your node on your behalf. They will throw up a virtual machine to run this one. What you now have is a network of distributed ledgers runing as a number of virtual machines on a single large computer. Why not save all the problems and just run a large application to do this without all teh blockchain complexity?

The final issue is growth. Adding new nodes to a closed blockchain network is not trivial. Depending on the implementation it often means taking the whole network down and distributing a new set of public keys to all parties. This is a nightmare of key management but with distributed ledgers. So growth was always going to be problematical.

TradeLens is needed. The concept is right. It just doesn't need a blockchain. But then I really don't understand what does need a blockchain unless you need to have that phrase in your buzzword soup.