Let’s Build A “Blockchain” for Inventory Mgmt (...and learn about how we can fail!)

In my previous article I detailed some of the issues with developing a blockchain solution for inventory management. It seems clear to me that “blockchain” buzzword is used today in the same way “internet” and “e-everything” was used in the late 90s — as ‘clickbait’ for investors, a cheap and easy way to drive up share price with no real long-term value add. What I want to do in this article is to walk through the process of brainstorming a blockchain-like solution for SCM/ISM and to demonstrate why blockchain is such a strange bedfellow in the context of inventory management.

Let’s start by coming up with a list of desirable features that would make businesses wet their corporate panties over a “blockchain solution” as it applies to inventory/supply-chain management:

1. Immutability — a double-edged sword, for sure, but seems like a win when you consider that deniability and data loss are even bigger issues.
2. Authentication — each transaction should be provably authorized (created and signed) by parties who cannot plausibly deny their actions.
3. Availability — data is stored with each player, increasing robustness of the system and preventing data loss.
4. Flexible permissions — data should be acted on only by authorized players in the ecosystem.
5. Flexible privacy — data should be seen only by ‘appropriate’ parties, but hidden from hackers/intruders — aka “bad actors”.
6. Flexible consensus — some type of mechanism should be present whereby multiple parties can collectively guarantee data validity and ensure that there is no one central point of failure.

Notice that the last 3 items are prefixed with “flexible” qualifier — the degree of importance of these will likely vary from one implementation to the next, while the first 3 are likely to be universal requirements.

OK, so if you are not completely new to designing computer systems, you can immediately see that there is nothing in this list that specifically calls for “blockchain” in order to provide the desired functionality. In fact, one can argue (and I do) that the only reason why something as computationally inefficient and resource-taxing as blockchain is only needed to achieve decentralized (aka permissionless) consensus among players who are both pseudonymous and potentially malevolent.

Once the requirement of pseudonymity (or anonymity) is removed, the very reason for blockchain as a preferred data sharing mechanism also falls to the ground. Let’s see how we could develop an alternative solution without the concept of “blocks” or “chain” altogether.

Below I present two slides that summarize the mechanics of a potential solution for an SCM/ISM system. The first one deals with transactions that supply identity management of the players and their respective permissions in the system. The last one deals with the actual transactions that model inventory movements.

Pic.1 — Establishing the Players

Pic.1

Imagine a consortium like Walmart and its vendors coming together to form an “ecosystem”. Well, first things first — they would want to establish a baseline of trust among the players — “who is who”. This is very easily done with a ‘Web-of-Trust’ type of setup, similar to certificate chains in a browser that establish trust of each signer. If you look at the top of your browser window, you will most likely see a green lock next to the medium.com URL. How do you know you are in fact on medium.com website and not on some spurious site that just claims to be medium.com through some clever manipulation of DNS entries? Well, because the medium.com that is authentic has a certificate that has been verified and signed by DigiCert Inc — a top-level authority that is included by default in your browser. The validity of DigiCert’s signature is easily verifiable by your browser — hence the green lock.

Pic.2

A pretty much identical setup can provide strong guarantees for a distributed system we are trying to build. All you you need is one “root” transaction that establishes the absolute trustworthy actor (a “DigiCert”) — let’s say Walmart, and then everyone else is verified either by that root account, or transitively, by one of the subsequently verified accounts.

While I use a familiar term “web of trust”, more precisely in computer terms this is a tree — a graph structure with a single root, a “Genesis” block, if you will, and multiple branches that can be ultimately traced back to it.

The certificate path can be enhanced with “permissions” — an initial weight assigned to each player that could determine predefined actions (add another user) or types of transactions that could be created/verified by each participant. As all the parties are initially known to each other or to the central player, there is no need for fancy decentralized consensus — all of this could be decided in a literal consortium-type conference meeting of the stakeholders. Let’s say that only certain parties are allowed to create new transactions, while others are allowed only to append to existing transactions (more on that below). How could you implement a rule like that? Well, you could incorporate it into “consensus rules” — any new transaction must be signed by a party whose public key has a minimum weight of say, 300. If a broadcasted transaction does not meet this requirement it can be immediately discarded instead of being propagated to the rest of the network. A weight of 100 might be required to add branches to the WoT, while a different weight might be needed to add an actual inventory transaction — you get the idea.

In addition, transactions, just like TCP/IP packets could have a list of recipients and/or list of allowed players who can append — all of this is magically available because, unlike a real “blockchain in the wild” — in this case, all the players are known at the outset via their identities in the WoT.

This mechanism solves items #2 (authentication) and #4 (flexible permissions). As the copy of the WoT tree can be propagated to each player in a peer-to-peer fashion, this also ensures #3 (availability) of this part of the system.

What about #1 (immutability)? Here one can use a simple scoring system to make sure that history does not get re-written and we do not end up with multiple competing trees. The “true” root will have the largest number of different signers that ultimately derive their identity to it. To illustrate, imagine, that after the setup phase we have 1 root signer and 100 signers that “spring” from that tree. If one of those players were to decide to proclaim himself as root and offer a completely alternative tree, he would literally need to collude with the rest of the network to pull it off. What if one were to come up with 101 fictitious identities? This is where we could use the actual transaction history to weight the signers by the # of verified transactions up to that point. The risk of tree mutability only exists initially when the value of the network is very close to 0 (no or very few transactions). As the history of transactions becomes more established — this risk becomes vanishingly small. However, the risk of transaction history rewriting is real — and is likely to be mitigated by appeal to real-world checks (after all, inventory can be verified independently offline).

More trivially, existing tree branches cannot be modified without changing their hashes and invalidating signatures — the same cryptographic mechanism used in the Merkle tree mechanism of most blockchains, thus ensuring that existing rules will stay in place; while, at the same time, allowing more players to be added to the system as long as they are properly validated by extending the path of certifications of trust.

Once each player’s identity and permissions are unambiguously established via links of trust and associated public keys (which could be expired and replaced from time to time for increased flexibility), the mechanics of the actual game become relatively straightforward.

Pic.3 —Playing the Game

Pic. 3

What we have in this slide are chains of transactions, where each left-most transaction is marked as transaction 0 (not linked to any parent). All of these can be processed in parallel, unlike the traditional blockchain. If you are familiar with NANO, it is similar to their block-lattice structure. Anyone with appropriate permissions can start a new “chain” of transactions (“Hey, here is widget X that I just produced!”). Similarly, anyone with appropriate permissions can verify and/or append to the transactions. Anyone can broadcast transactions. The immutability is once again guaranteed by the hashes and signatures of creator/verifier of each transaction. Authentication is guaranteed by signatures of the transaction creators and verifiers. Availability is a bit trickier but is generally not going to be an issue with large enough pool of participants.

One of the really exciting things about this system is the potential way to solve the privacy issue — a transaction can be encrypted with multiple public keys (see this) at the same time — thus ensuring that multiple parties are able to decrypt it — independent of each other and in any order (sic!), — and yet to the rest of the world the transaction is effectively hidden, but still verifiable. One can, for instance see how Walmart might want to hide certain information intended for one of its vendors for a particular product from other vendors servicing a different (or related) product. In a related refinement, one could implement addressing — a list of possible or obligate recipients / actors that are specified as part of transaction metadata.

The permissions system we had touched on could be further extended with things like appendThreshold which only allows certain players with minimum weight exceeding that to add transactions to a given chain. Transactions could be set to expire (if something is time-sensitive) and they can be appended with a “final” transaction — which means that they could be potentially “pruned”.

Moreover, because there is no single “chain” but rather a collection of transaction chains, all participants need not store all of the transactions — just the ones that they are a named party of. The redundancy is still going to be there because multiple copies will be stored — but the overhead will be significantly reduced.

How would a verification/validation process work in this system?

Let’s say I get a new transaction broadcasted to me. First thing I will do is to look at parentTx — if it is set to 0, I know this is the beginning of a new chain, otherwise — it must be referencing a verified endpoint of an existing transaction chain. Before I do anything else, I calculate the hash of the transaction payload and verify that 1) it matches the txHash in the SIGS section of the message, and 2) the signature of the hash matches what is in the producerSig in the PAYLOAD — the signature corresponding to the public key/userId in WoT ; it is in this step that I can validate that the signer has the appropriate weight to create this type of transaction — either new chain or append-to-chain.

In the former case it involves finding the signer in the WoT graph and retrieving his weight and comparing it to the consensus weight for the corresponding action (this could be hard-coded or dynamically determined, like block difficulty in a bitcoin consensus). In the case of appending a transaction, the parent tx needs to be retrieved and its list of allowed actors (“to” array) and threshold weight compared to the signer’s weight. In addition, if the parent tx has an expiration date, it would also be checked.

If the transaction passes all the checks, but is not addressed to me as one of the recipients, I simply forward it along to other peers. On the other hand, if it is intended for me, I decrypt it, perform any real-world operations related to validating it and sign it. I can also verify other signers if they are present — verifying that their signature corresponds to their public key and the correct transaction hash and that they are allowed to sign this transaction. In case when my signature is enough to finalize the transaction, I can mark it as verified and forward it along to others.

If any of the checks fail — I drop the transaction, and temporarily blacklist the sender.

The described system can be summarized via a familiar concept of layers presented in a pic.4 below.

Pic.4

Well, that wasn’t so hard, right? So, where is the proverbial Achilles’ heel then?

Well, it is the consensus aspect of the system. While a player cannot forge or change a transaction in this scheme of things, it is quite possible for them to either spam or what is even worse, to withhold transactions. (I will not dwell too much on another consensus issue, namely “re-writing of history”, except to say that in a system where transactions are signed by their creators and verifiers, and the subject matter of transactions can be physically audited — it becomes counterproductive in the long term to engage in faking transactions — because one is essentially incriminating themselves in fraud. In addition, since transactions can be encrypted, how does one fake what is unknown?).

Transaction withholding, on the other hand is much trickier to deal with. Spam issue could be solved with some sort of metrics (like if I get too much garbage from you — I can simply disconnect from you as a peer and stop sending you valuable info), but what about data withholding? Sure, once again, I could devise some sort of metric like “information gain” per peer — perhaps a % new info I get from a peer vs. information I have already seen, and could potentially disconnect or throttle down connections based on that.

One must keep in mind that you cannot prove a negative — if you send me spam, you are unequivocally guilty, but if you do not send me something — I cannot definitively say whether you were malicious or just statistically >unlucky.

This brings us full circle back to the fundamental problem inherent in these types of “distributed consensus” systems — a misalignment of “network incentives” with “real-world” goods incentives that are completely external to the system.

Let’s say I am a vendor in this ecosystem and I get a transaction destined for someone else. I cannot necessarily even read it, I just know it is not for me. Should I forward it to others or should I just drop it? What are my incentives of playing fair? Maybe if I sabotage the network with spam and drop these transactions it will slow down inventory processing of my competitors — this will allow me to gain an advantage and win the next contract in lieu of my competitor.

Or, as an alternative strategy, maybe I will be a “good little player” on the network to get some sort of ‘excellence sticker’ for my network reputation score in the hopes of winning a contract with Walmart, which by any other measure of real-world competitiveness I should not get. Even if the network generates some sort of reward for “good players” on the network, it is not clear how that could ever compete with multi-million dollar contracts in real life.

Now, at this point it is not yet clear if the parties involved will resort to these types of “games”. Will the benefits outweigh the costs — both in terms of reputation and in terms of operational resources? It depends on the details of the game. It is entirely possible that in this type of ecosystem some type of Nash equilibrium will emerge where the optimal strategy of each player will be to co-operate rather than to sabotage each other. However, it is hard to postulate as a given without knowing all the details of the incentive structure of each player (and how it could dynamically evolve).

This is where one really starts to appreciate the genius of the actual blockchain proof-of-work (PoW) system — like the one implemented in Bitcoin. The incentives for playing fair in the Bitcoin network are rewarded solely by “coins” that are only valuable in terms of that same network, but the punishment exacted on bad actors is in the form of expendable real-world asset — energy. There is a beautiful symmetry of incentives that is completely not obvious until you attempt to replicate the system in a context that involves physical assets and incentives outside the system.

The ensuing amalgamation of misaligned incentives is precisely the reason why these systems are not going to add much value beyond “Look, Ma — we have a ‘blockchain’!” marketing hype. The technology can solve most of the issues related to security of a distributed system — but it cannot solve the fundamental issue of trying to mix oil and water of different incentive structures.