Say Hello to the Baseline Protocol

0
36

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 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.

Notice that the volume discount table (from the MSA) dictates that from zero to 99 units the price is $1.00 per unit, from 100 units to 499 units the price $0.90 per unit, and so on.

With that, Buyers are now able to confidently begin sending POs knowing with certainty they’re getting the correct price because each fulfilled PO is updated under a Zero-Knowledge contract that proves the unit price is correct according to volume discount-table terms of the MSA. In other words, they are getting the right price at the right volume.

Suppliers follow a similar pattern except from an invoicing and volume perspective. They need to know what quantity to fulfill and how much they are to charge their customers in accordance to their MSA.

When those two perspectives agree, the counter-parties have state-synchronization.

Got it? Now — Go Apply it

Hopefully this article answers some of your basic questions about the Baseline Protocol and gives you a Baseline understanding (I’m sorry. I couldn’t help myself) as to how it can be applied. While one of our unifying cries in the Baseline community is to, “embrace the boring” we certainly don’t believe its potential is boring.

Getting two or more databases to agree with each other is a simple idea but a monumental task in practice. The Baseline Protocol is intended as a design pattern (not a product) that can be extended to any database/workflow.

Actually, in theory, any state machine should be able to be baselined. Though, this doesn’t mean that every state machine should be baselined.

So , the question remains —

What should be Baselined?

Here’s with John Wolpert suggests:

Look for situations where multiple parties currently run traditional systems of record.
Find places where there is serious and costly failure when those systems record different data when they should have had more or less the same information in each database, like a credit/debit on two GLs, or an Invoice or an asset trade.
Within that set of circumstances, look for workflows (simple or complicated ones) where there are more than two parties to different steps in that workflow AND where all parties must be confident in the overall integrity of the workflow, AND where, in some cases, the parties to, say, Step 5 MUST have no access to, visibility into, or even awareness of some or all of the other steps…or awareness of who the Parties involved in those other steps are.
Find that pattern in any domain, and you have a reason to use the baseline pattern over, say a shared database.This is especially useful when that pattern shows up in environments where the organization must deal with both larger and smaller counter-parties.
In such cases, the benefit of pay-as-you-go on a common bus that does not need setting up and configuration for every partner is helpful.

Got it? Good. Now, be boring and get building.


Say Hello to the Baseline Protocol was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.