Introduction

On March 19, 2020, a group of 14 companies released and open-sourced the Baseline Protocol to the world. The Baseline Protocol employs the public Ethereum Mainnet as a common frame of reference because it’s always on, companies can’t be locked out or restricted from using it, and they only need to pay for what they use.

This article aims to provide a brief explanation as to what Baseline Protocol is, what it solves, and how the reader can conceptualize the future use-cases using this design pattern.

First, a definition —

The Baseline Protocol defines a series of steps to privately and securely synchronize data and business logic between multiple independent systems of record, using the Ethereum Mainnet as an auditable common frame of reference. This protocol implements best practices around data consistency and compartmentalization, and leverages public Ethereum for verifying execution of private transactions, contracts and tokens on the Mainnet using ZKP (zkSnarks). The Baseline Protocol is designed such that it can be extended and applied to any database/workflow.

That’s a mouthful but don’t worry. The rest of this article will unpack this statement in terms that make sense to those of us who aren’t master programmers and cryptographers.

So, why Baseline?

A good place to start unpacking Ethereum, zkSnarks, tokenization, and everything else that makes us feel stupid, is to understand it in the context of the problem it solves:

What problem does the Protocol purport to solve? In what context is it needed in the first place?

Let’s start with a simple premise: data consistency matters to enterprises and large organizations are pretty good at managing their internal systems of record. This is thanks, in part, to the advent and development of ERP (Enterprise Resource Planning) systems.

In the words of Paul Brody —

To this day, if you ask a lot of companies how much inventory you have, the answer they’ll tell you is in weeks, but if you ask how much money they have, they can tell you down to the penny in many cases. The reason for that is that large enterprises didn’t have very robust and fully integrated information systems. ERP means that now they have an end to end integration of their information systems, they have an end to end processes that are common and standardized, and they have analytics and other tools.

Unfortunately one of the main issues enterprises face today is that fully integrated information systems largely stop the moment the data leaves their front-door.

Knowing the details of what your organization has in its databases is one thing. Synchronizing what you know with what other counter-parties know is an entirely different challenge altogether. Actually —

It is incredibly difficult to synchronize data between organizations, especially when the incentives differ.

What is needed is an arbiter of truth between counter-parties who don’t necessarily trust one another; an intermediary to say what’s true and what isn’t. Take the not-so-simple example of managing purchase data between multiple counter-parties in a supply-chain. How do we know which system of record to trust when they could have competing incentives and/or misaligned data?

One traditional avenue to solve for this is to create a centralized, web-based industry portal. If you’ve ever used a ride-sharing service you’ve used a web-based portal.

Unfortunately, these centralized portals can create (a) unintended risks for enterprises that rely on them, and (b) a series of new data silos that don’t easily talk to one another (think data silos of intermediaries).

Take a supply-chain portal operator. This portal exists to connect the buyers with the suppliers — facilitating the business messages between the parties and settling any disputes that may occur. They make the digital and contractual facilitation possible between counter parties.

In multi-party procurement, being the digital message bus and arbitrator is a position of power with fantastic network effects. Should this portal manage to monopolize their particular market place and, consequently, the flow of information between the buyers and sellers, the incentive structure becomes precarious for their customers.

What happens if this portal operator suddenly decides that it’s better to sell your precious company data, lock your enterprise out of the supply chain, or (but certainty not limited to) use your agreements against you for their own benefit? Plus, if they are the source of truth, how do you even know that what they say is true is in fact true?

For supply chain risk-analysts this should be some cause for alarm.

The Solution — Remove the Portal, Break Down the Silos, & Replace it with Consensus

This is where Ethereum enters the discussion. Disclaimer here, understanding the technical aspects of Ethereum is a bit like trying to learn how the internet works. If you’re technically inclined, or just curious, read this.

There is one key characteristic and functionality that makes Ethereum revolutionary. Ethereum is able to handle transactions and execute nearly any form of business logic without requiring a center party to validate the state change and verify the records.

It sounds simple, admittedly, but its implications are incredible.

Suddenly, counter-parties can conduct business with one another without trusting one another nor any third-party validation. Instead, trust is a matter of the quality of code instead of the enforce-ability of contracts and the changing incentives of business partners.

To substantiate this idea, it’s worth mentioning the concept of State. State can be thought of as a representation of a particular system at a particular point in time. Take the human body for example. Say we want to model a human body as of right now. We will call this human-body state zero. As a system, we could measure:

The Heart Beat

Blood pressure

Body Temperature

Weight

Body Fat Percentage

The list goes on. The key here is that each representation at some point in time is considered the state of the system. Visualize state changes like this:

Figure credits to Preethi Kasireddy

Ethereum is a shared state machine that uses a special economic system called consensus to execute changes in state given some inputs, data, and addresses. In Ethereum, smart contracts (for our purposes, business logic as code) enable business agreements to be enforced exactly as they are written, thereby eliminating the untrustworthy intermediaries altogether.

The catch is that in a shared-state machine the addresses of the users (senders, receivers, and contracts are all users to Ethereum) can be viewed by anyone. Go look, it’s intended to be public! This doesn’t tend to be a problem for most retail users because individual transactions are generally mundane. But —

Public transactions imply that anyone who’s carefully watching (like an AI) can decode where a transaction is coming from and what the internal contents of the transaction are. For enterprises that’s a problem.

If data is an asset (hint: it is), then all private enterprise data (including meta-data) should be considered an exploitable resource. Suppose Apple executed its procurement logic on-chain using publicly available smart-contracts. Also, it’s 2007 — two hundred days before the release of the first iPhone.

Suppose an equity trader/traitor (either spelling works) spots that address 0xD0C8B6c2AA1de705e458261e7802262BAc13Eb94 just instantiated a smart-contract to purchase three-million iPhone screens from their main supplier in China. There’s a pretty good chance that this information is valuable to Apple’s competitors. This opportunistic trader could then sell the information to Apple’s competitor who could, in turn, use that information to ruin Apple’s press release, copy their design, anger Steve jobs — okay, you get the point.

For enterprises, having a public supply-chain is a bit like telling the enemy general where you intend to move your troops. It’s problematic to say the least. Surprise, data privacy matters.

One of the proposed solutions was to enable privacy on chain. Now enter Nightfall. EY created Nightfall (which they released open-source) —

… to make transactions on public blockchains secure and private. Nightfall replaces sensitive business information with a type of cryptography called a Zero Knowledge Proof (ZKP). The idea is simple even if the math is hard: instead of showing the actual information, you simply show the mathematical proof that you did something instead. Other parties on the blockchain cannot determine who passed what information to whom, but they can use the proof to verify the truthfulness of the statement.

Nightfall solves the problem of observable addresses and what amount of value was transferred between parties by putting a verifiable proof of the change on-chain rather than the change itself. That’s a massive simplification, admittedly, but if you’re keen to get a deeper understanding of Zero-Knowledge Proofs read this.

Through Nightfall, enterprises could now hide who they were, who their counter-parties were (e.g. a supplier), and how much they’ve transferred between parties while simultaneously confirming that their business workflows were executed.

Again, there’s a catch. Although Nightfall can hide who is sending payments and how much of that payment is being sent to whom, the nefarious actors can still deduce some key information based on the transaction volume and other metrics associated with the transactions. Part of the problem, both technically and philosophically, is that most solutions rely on using Ethereum as a, “single source of truth and shared logic execution environment.” This makes IT Professionals working at enterprises uncomfortable.

But —

What if instead of using the Ethereum Mainnet as a single source of truth that handles all business logic and state-changes it could instead be used as a common frame of reference that allows counter-parties to verify their own systems of record in a provable state of consistency?

Introducing the Baseline Protocol (With Context)

The Baseline Protocol’s primary value proposition is state-synchronization between enterprise databases— which is easy to conceptualize but difficult to execute. State-synchronization answers the question of — do what I have in my databases agree with what you have in your databases?

By enabling this agreement of state, and its subsequent state changes based on coded logic, the Baseline Protocol enables enterprises to synchronize independent databases on the public ledger (shared records) without having to give up the sensitive information that companies guard so heavily.

With it, Company A can confirm their shared-state with Company B (eg., that a MSA was signed between a supplier and a buyer) without all of the agency and data-silo problems mentioned above. Good, time to generalize. Something is said to be ‘baselined’ when —

Two or more machines store data and run business logic in a verified state of consistency, enabled by using the Mainnet as a common frame of reference.

But what the heck does that mean?

The Radish-34 Use-Case

An natural illustration for state synchronization is that of enterprise procurement due to the complexity of the number of parties involved and the distinct workflow requirements. Using the Radish-34 workflow (click here for an interactive demonstration), the end-goal is to facilitate a two or more party exchange where a buyer intends to procure goods and a supplier can provide the goods in exchange for payment. Obvious right? For the sake of simplicity, let’s assume only one supplier and one buyer exists — naturally there could be many more.

The 30,000 foot workflow has two business objectives: (1) privately validate the initial agreement between the Buyer and the Supplier (the initial ‘Baselined’ agreement) and (2) continually synchronize the key inputs (Price per Unit X given a Volume N) as a state marker for continuous purchasing.

The first objective is to issue an RFP (Request for Proposal), select a supplier, and come to a verifiable MSA (Master Service Agreement) under specific terms with a particular supplier(s). The key interactions are outline below:

Buyer issues a RFP to potential Suppliers → Supplier responds to RFP with terms privy only to Buyer (eg,. we will give a volume discount @ Price X given Volume N, etc) → Buyer views the details of the Proposal from potential Supplier and sends a MSA (Master Service Agreement) to the Supplier of their choice → Supplier views and signs the agreement and sends the signed agreement back to the buyer → Buyer validates, then confirms the agreement, and sends it back to Supplier → Supplier confirms the agreement.

At this point a few important questions to ask are — how is the agreement ‘baselined’ to the Ethereum blockchain? What makes the data not-sensitive? How is this any different from how things operate now?

The short answer to these questions (with respect to a ton of important details), is that a mathematical-proof of the MSA agreement, proof that they agreed, is included on-chain without actually putting the terms of the agreement or the parties identities on the blockchain. Everyone else just sees that —

Someone sent something to someone and we can prove it, BUT that something is just a nonsense set of characters that only the direct counter parties know is anything at all.

To the Buyer and Supplier it represents their MSA agreement as a state marker from which they can baseline all future purchase orders (POs). In this example, the two things we care about are purchase volume and per unit price as a function of purchase volume.