Radish34 Explained - DEPRECATED

With the release of Baseline Protocol v0.1, much of the original Radish34 proof of concept has been altered, abstracted, generalized or deprecated. We include the work here for legacy and so that the history of the protocol can continue to be examined in the future. Also, the use case described below continues to be a good explanation of a use case that can benefit from _baselining_.

Radish34 is the result of a 2019 joint development effort to build a supply chain POC. The work led to the Baseline Protocol, a way for enterprises to use the Mainnet as middleware without compromising corporate information security practices. Radish34 remains the best way to show the general baseline approach in a specific example. You can build and run the proof of concept here. And you can see how a set of companies would integrate their supply chain management systems in this interactive demo.

The Procurement Use Case

Supply chain, as a topic, presented an obvious choice for exploring ways to use public blockchain in business. In particular, key steps in the manufacturing procurement process were a good focus for the Radish34 project.

First, the team from EY that helped start the Radish34 project are experts on the subject and were able to articulate a highly precise and detailed set of workflows with both functional and non-functional requirements.

Second, supply chain has been a classic starting point for enterprise blockchain explorations, because it involves such a tangle of different entities that must work together. But, one of the key problems with using private or public blockchains in a supply chain context is compartmentalization.

Even when different companies are partners in a single supply chain, there are things Party A shouldn't know about the relationship or activities of Parties B and C, even if those activities support the same Workflow for the same set of goods. The Radish34 team had to find a way to coordinate companies without anyone that was maintaining the integrity of the ledger learning anything about the business activities or relationships of the participants.

It turns out, ironically, that this problem is more insidious for private blockchains than for public networks, given the relative ease of analysis an attacker with access to a node can perform on a small group of known counter-parties. And so the choice was to show how the public Ethereum network could be used in a confidential procurement scenario without anyone being able to analyze the ledger and learn about the cadence, volume or particulars of any Party's business.

The Volume Discount Problem

Even with modern supply chain management (SCM) and order management systems, revenue recognition for a Supplier can take time. Take the case of a Buyer and a Supplier that agree to a volume discount arrangement, a tiered pricing table in their master service agreement (MSA). To keep it simple, imagine that the Supplier will give a 10% discount on orders over 100 units purchased over the next year. The first purchase order (PO) comes in for, say, 100 units. This is easy to calculate. The initial state of the agreement is zero -- no units yet ordered. No discount. After the PO is processed, the new state is 100. The next PO comes in for 100, and if everything goes right, the Buyer will receive 10% on each of those 100 units, because they all fall within the 10% discount tier. So far so good. But what if two POs come in at the same time and both calculate from a base of zero. This happens quite a lot in the real world. And it is one of the reasons why generally accepted accounting principles (GAAP) have rules about when a Supplier can recognize revenue from purchase activity. Until someone can go through and make sure that each PO calculated in the right order from the right starting position, there’s no way to be certain that the Buyer doesn’t owe more (or less) than what the Supplier thinks.

The Radish34 POC demonstrates how to ensure that each PO executes faithfully and in correct order (without double-execution from the same starting state) by using the Ethereum public network as the common frame of reference needed to be sure of what the Buyer owes more quickly. It does this without putting any of the Supplier or Buyer's data or running the shared code that executes the volume discount agreement of the MSA, and ensures that each PO is calculated faithfully against it, on any blockchain.

Instead, Radish34 implements the approach now called the Baseline Protocol. The public Mainnet is used not as a "single source of truth" (where the shared data is stored and the shared business logic is executed) but instead as a common frame of reference that enables the Supplier and Buyer to maintain their own systems of record in a verified state of consistency.

Even though this approach does not move the sensitive business data of the Buyer and Supplier's MSAs and POs to any kind of blockchain -- leaving it all right where any conservative security officer wants it, in their own internal high-security systems -- it does use the Mainnet's ability to store state and execute functions to provide this middleware service between the counterparties with great utility. And to be clear, while the approach uses well-known components such as peer-to-peer messaging, digital signatures, hashing, and zero-knowledge proofs, it’s how these elements work together that takes this from a simple "proof of existence" approach to something that can be used as a state marker, flow controller and "stealthy" private token for complex business processes in a widely distributed system environment.

Other Relevant Supply Chain Problems

The techniques used to work on the volume discount problem have other applications across the supply chain. Here are several that can reuse, more-or-less the same components and patterns as Radish34's demo Workflow, like a box of Legos, to construct solutions across the supply chain from end to end.

The Multilateral-to-Bilateral Compartmentalization Problem

Say a Buyer wishes to make the same request for proposal (RFP) to 10 different suppliers. It may be desirable, or even mandatory, for the suppliers to know about the presence of the others in the RFP process and know that the same RFP was made to all of them. But it would not be appropriate for Supplier A to have access to Supplier B's bid. In fact, Supplier A shouldn't even be aware that any of the other suppliers actually bid on the RFP, even though an ideal system would link each bid verifiably to the original multi-party RFP.

The Blind Coordination Problem

The terms that govern the movement of a shipment of product from, say, a Manufacturer to a Wholesaler are usually not only confidential...their existence is confidential. And likewise, the terms between the Wholesaler and a Retailer of that product can't, in some cases, be known to the Manufacturer. However, there are cases when some or all of the product must be returned to the Manufacturer from the retail channel. Especially in highly regulated industries, the product's serialization process requires tight coordination. When the product is put back into circulation, the Retailer may need to coordinate with the Manufacturer. In this scenario, the Retailer has no visibility or connection past the Wholesaler. If this were only a "three party" problem, the Wholesaler in the middle could be used to join the two Parties on each side, but in many real-world scenarios, there are more Steps and more Counterparties involved.

In this case, what's needed is a way to ensure the overall integrity of a Workflow and run complex business rules that can connect Counterparties only when appropriate, without Parties necessarily having any awareness of the Steps that don't directly involve them. Each Party must be confident that what is coming into their Step is correct, and that what happens downstream from their activity will proceed correctly.

This is a trivial problem if a common vendor is trusted by everyone to run things. But this historically leads to balkanization as many vendors, smelling profits, convince different sets of companies to use them as the common frame of reference. Another way to handle this is to set up a consortium and jointly invest in a shared ledger solution, however, this doesn't solve the problem of the double-blind requirement for any of the firms maintaining a node that validates activities on that ledger. Even if those activities are encrypted and masked, maintainers will inevitably see that some kind of activity is happening, and that itself may give them strategic information that other participants wouldn't knowingly permit. This is particularly acute within a ledger used by a relatively small number of known companies.

The Coopetition Problem

Say a Supplier happens to make a product that competes with a company that not only makes products but also runs a shipping operation. If the Supplier is obliged to use the competitor for shipping to the Buyer, and if they have committed to a late-delivery discount, then it’s important for the Supplier to get the verified delivery date from the Shipper. If the Shipper knows who the Supplier is (so that it can send them the delivery date), then they can use that information to know a lot about their product's competition: volumes, peak-and-troughs, and their customer base. What if the Shipper were only aware of its Step in the Workflow. What if, short of opening up a shipping box and inspecting the item, the Shipper didn’t know who was shipping the package to that address? The trick then is getting the delivery date to the Shipper without knowing where to send it. This is where having a common frame of reference, a message bus, is useful. The Shipper can 'dead-drop' the date and a topic (a key-value-pair). The Supplier can watch the topic and grab the date. This is a good use of a public Mainnet, if we can use it without leaving traces that others could use to discover and analyze the Supplier, Buyer or Shipper's activities.