Dapps Inc. the leading EBC (enterprise blockchain computing co.) for the Salesforce platform and the worldwide CRM market has extended its DappSuite™ product to leverage the Baseline Protocol. Salesforce Customers can now leverage the public Ethereum Mainnet to execute secure and private CRM processes with advanced enterprise access controls.

Using DappSuite, Salesforce customers can maintain their Salesforce system of record (SOR) and have a consistent and common frame of reference with their counterparties on other systems of record for B2B intercompany automation. A Salesforce customer can baseline contracts (e.g RFP, MSA, SLA), b2b workflows and other sales processes between any number of Salesforce and non-Salesforce customer’s CRM or ERP systems. This product was developed to help Salesforce Customers synchronize with each other as well as with non-Salesforce customers in record time. Businesses can no longer wait for costly system and API portal integrations, data reconciliations, and manual time spent managing ETLs.

“The Baseline Protocol is a huge advancement for enterprise adoption of secure, private and collaborative workflows that leverage the public Ethereum Mainnet. Salesforce customers have been using DappSuite to seamlessly harness Ethereum. Increasingly, they have been demanding a common frame of reference across counterparties that Dappsuite now enables with the Baseline integration” — Dom Steil, Co-Founder and CTO of Dapps Inc.

Any number of Salesforce and non-Salesforce customers can instantiate CRM processes that provide the capabilities of non-repudiation, record consistency, workflow integrity and verifications of offchain private business logic execution. The Baseline initiative, originated by EY, Microsoft, Consensus and 14 other firms, has grown to hundreds of participants and seen a number of other integrations including Dynamics365, SAP and Google Sheets.

The Baseline Protocol community’s goal is to accelerate the development and adoption of the Ethereum Mainnet as an always-on, tamper-resistant, low cost integration fabric.

Applying Baseline

Baseline is a powerful protocol that makes it easy for any organization to use the EVM in a privacy preserving and secure manner. Baseline can be applied to any number of Salesforce workflows and business processes that include standard and custom Salesforce objects. The processes are focused on inter-company b2b processes such as RFP, MSA, Purchase Orders and Invoices. The value of leveraging the Baseline Protocol for inter-company processes is that there is a always on and verifiable way of connecting multiple companies using different systems of record without having to spend time leveraging B2B extract transform load (ETL) and services engagements to have the systems communicate. The other benefit of leveraging the baseline protocol is that the Ethereum Mainnet is neutral across counterparties therefore accelerating enterprise adoption of blockchain networks for b2b interactions.

How to Start

Salesforce customers can Baseline their b2b processes leveraging DappSuite, available on the Salesforce AppExchange. The open-source DappSuite middleware has also been updated to support the Baseline Protocol APIs and is available for review on Github. Download DappSuite; select the Baseline Global Action and then select which record you want Baselined to the Ethereum Mainnet.

About Dapps Inc. — Dapps Inc. is a San Mateo based software company that has led the enterprise blockchain computing (EBC) category with customer relationship management (CRM) applications since its founding in 2017. DappSuite is the BPaaS solution for Salesforce customers to quickly connect to the Ethereum Mainnet directly from their Salesforce platform environment. The company’s DappServices division partners with digital transformation teams at global organizations and consulting firms to define intelligent technology strategies utilizing enterprise blockchain computing. It is headquartered in San Mateo, California.

About the Baseline Protocol — The Baseline Protocol is an open-standards and open-source initiative of the Ethereum-Oasis Open Project, run by the venerable standards body, OASIS. It is an approach to using the public Mainnet as a common frame of reference between systems. The approach is designed to appeal to security and performance-minded technology officers.

Website | Twitter | YouTube | Telegram | GitHub |LinkedIn

Dappsuite extends the Salesforce Platform to leverage Baseline Protocol for B2B workflow… was originally published in Baseline Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the world of co-operative global trade, where multiple international enterprises have to work together, how do we keep everyone on the same page? How do we synchronize business processes and reduce the overhead of maintaining separate systems of record without exposing confidential internal data? Those are the questions that the Baseline Protocol open standards community spends its time on.

In the use cases below, we illustrate how the Baseline Protocol can leverage Chainlink oracles to create a powerful new design pattern for reconciling multiple databases through a mainnet blockchain, while utilizing validated off-chain data through an oracle network like Chainlink.

The Chainlink and Baseline Protocol communities are offering these use cases to the developer community as the basis for prospective demos, POCs and production projects.

Chainlink Provides Validated External Data For Baselined Workflows

The Baseline Protocol is a technique for synchronizing multiple independent databases and enterprise backend systems like ERP/CRM systems, which would be involved in a shared business process using the Ethereum Mainnet as an always-on, immutable common frame of reference. Chainlink provides a decentralized method of retrieving and validating external data, both guaranteeing it’s accuracy and delivering it on-chain or into backend systems.

While Chainlink ensures secure and reliable data inputs to systems, the Baseline Protocol is focused on how multiple independent internal databases can be kept in a state of consistency. It does this using p2p messaging, digital signatures, hashing, and cryptographic proofs that prove each counterparty consistently used the same common set of records and functions throughout an entire business process without internal data leaving their respective databases or letting uninvolved parties know when state changes occur. A practical example would be enforcing the consistency and sequencing of a series of purchase orders between a buyer and supplier without leaking information that would allow unauthorized parties to know anything about the buyer and supplier’s relationship or their business activities.

Oracles can be important in this process, because without them, functions run by different counterparties can inject different parameters into functions, rendering them inconsistent. This is especially true for dynamic information sources like weather, time and price data. As a leading oracle provider and marketplace, Chainlink can ensure that each enterprise backend system involved in a multi-party contract receives the same external data as they execute shared functions.

So now that we understand the value of the baseline approach and Chainlink’s key role in it, what does this system look like in action?

Example 1: Baselining Purchase Orders Needing Weather Data

In the first example, we have a purchase order (PO) for bananas being baselined, which has a variable condition based on the cold-chain temperatures in which the bananas are being shipped. The reason for this is that the quality of the bananas may deteriorate quicker if they are subject to a certain temperature. Thus, it’s important for the retailer to track the state of the bananas to protect against the risk of paying full price for a spoiled shipment. As such, the following condition is part of the PO.

• If the temperature > 13° Celcius at any point during the shipment, the retailer pays $0.48 USD per bundle
• Else, the retailer pays $0.55 USD per bundle

In addition to cold-chain data from refrigerated shipping systems, the solution will track the weather at points where the bananas are exposed such as during initial container loading. The mean of three satellite weather data sources: NASA, NOAA, and OpenWeatherMap can be used. The counterparties also agree on the exact geographic location of the temperature reading and when the temperature reading is taken (at a certain time of day, the high, etc). They also choose to use nine independent, security reviewed Chainlink oracles; each data source is queried by three oracles to ensure against any availability or tampering problems.

Once a desirable oracle system is agreed upon, an aggregator contract is deployed through Chainlink, which outlines the job request, including the nodes involved, the time of the query, the data sources being queried, the aggregation method, and where the results are published. At the time of execution, the nodes query the off-chain APIs and feed the data points on-chain where they are aggregated together to form a single source of truth. This is then fed into the baselined systems of the participating parties. Once Chainlink’s threshold signatures feature is launched — a cryptographically secure form of off-chain aggregation — results can be aggregated completely off-chain and the output delivered directly into the backend systems of the enterprises.

The end result is that all parties involved have the same banana temperature data in their records and have the cryptographic proof on the blockchain that everyone else also has that same data. When it comes time to settle payments between parties, there is less of a need to hand-reconcile records since it is shared knowledge that all counterparty records are consistent. This opens up massive reductions in dispute overhead and paves the way for more reliable multi-party business automation based on reliable records and external reference data.

Example 2: Baselining Tokenized Invoices with Externally Sourced Interest Rates

Settling payments is a huge concern in many fields, not just supply chain and trade finance. At any given moment there are many billions in USD value locked up in various settlement processes, rendering it temporarily unusable. One of the ways enterprises unlock these funds is invoice factoring, where an investor buys the seller’s invoice. The seller gets immediate access to capital to fund other operations, while the investor charges an interest rate and turns a profit.

Blockchain technology offers a way to improve this process via the tokenization of invoices. Tokenization is simply repackaging an asset, which in this case represents the invoice as a blockchain token. Tokenization grants the ability to represent invoices as unique, hashed, and timestamped digital items on a shared blockchain ledger. This can reduce counterparty risk and thus expand markets and cut down settlement times.

In a baselined system, you issue only a cryptographic proof of the invoice on-chain with internal private databases holding the actual invoice data. Just as in the first example, the Baseline Protocol avoids any confidential data being held on a public blockchain while still offering the same authenticity guarantees through the on-chain proofs. But what happens when that invoice is subject to variable market conditions, such as fluctuating interest and foreign exchange rates?

Once again, we are encountering a data reconciliation inefficiency and security hole at the data input level, for which oracle providers like Chainlink offer a critical solution through the same design pattern as above. The counterparties are able to use Chainlink to create an accurate, tamperproof, and standardized method of pulling data from multiple data sources (e.g. interest rates from five leading banks) and aggregating it to create a single source of truth around the data input being used to calculate payments between them.

A New Design Pattern: Full Stack Data Synchronization Without Leaking Sensitive Data On-Chain

It’s not hard to imagine the wide variety of use cases where a business interaction is dependent on having a common frame of reference around external data inputs. In those cases, just as in the two examples outlined above, developers can follow the same general design pattern to maintain data consistency across the full stack of their baselined workflows.

Hopefully, this article has shed some light on the issues facing legacy systems of record, using the baselining technique to sync process flow and Chainlink to standardize the consumption of external data. Together they can reduce overheads from disputes and counterparty risk while allowing systems to maintain their existing database framework. If you would like to participate in the open-source development of these products or simply learn more, check out the resources below to start building today.

About the Baseline Protocol:

The Baseline Protocol is an open-standards and open-source initiative of the Ethereum-Oasis Open Project, run by the venerable standards body, OASIS. It is an approach to using the public Mainnet as a common frame of reference between systems. The approach is designed to appeal to security and performance-minded technology officers.

Website | Twitter I YouTube | Telegram | GitHub I LinkedIn

About Chainlink:

If you’re developing a product that could benefit from Chainlink oracles or would like to assist in its open-source development, visit the developer documentation or join the technical discussion on Discord.

Chainlink is an open source blockchain abstraction layer for building and running decentralized oracle networks that give your smart contract access to secure and reliable data inputs and outputs. It provides oracles to leading DeFi applications like Synthetix, Aave, and Kyber Network; numerous blockchains such as Ethereum, Polkadot, and Tezos; as well as large enterprises including Google, Oracle, and SWIFT.

Website | Twitter I Reddit | YouTube | Telegram | Events | GitHub | Price Feeds | DeFi

How the Baseline Protocol Integrates Chainlink Oracles was originally published in Baseline Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Official Press Release Here * Website Here

Open source proof of concept shows how to privately and securely synchronize data and business logic between companies, using the Ethereum Mainnet.

May 21, 2020, 10:00AM US-ET, New York, NY — Today, the Baseline Protocol, an OASIS open source initiative, published a demo of multiple companies digitally managing purchase orders and volume discount agreements across disparate systems. The demo uses an approach called “baselining” to prevent data inconsistencies and workflow errors that often lead to problems in revenue recognition.

Launched in March of this year, the Baseline Protocol initiative formed as part of the Ethereum OASIS Open Project. Baseline’s goal is to accelerate the development and adoption of the Ethereum Mainnet as an always-on, tamper-resistant, low cost integration fabric. The protocol ensures the integrity of complex, confidential workflows between enterprises without moving company data out of traditional systems of record.

The procurement use case in the demo released today highlights how two Enterprise Resource Planning (ERP) systems, Microsoft Dynamics and SAP can maintain consistency with each other using blockchain technology without exposing information about business activities or relationships to competitors or the public. Its use of the public Mainnet reduces capital expense while increasing operational integrity when automating business processes across multiple companies.

Alex Tapscott, co-founder of the Blockchain Research Institute, said, “The Baseline approach is a windfall for global enterprises looking to boost security and performance. Data is secured, contracts are governed digitally and companies can collaborate seamlessly without changing their current systems. This will change how enterprises interact in a digital setting.”

Several companies worked together to create the demo. Unibright extracted the domain model from the Unibright connector, set up a connection proxy to the Provide/Baseline stack and integrated SAP. Provide adapted the Baseline Protocol as a standard within the Provide stack, including its secure messaging infrastructure service. This was critical as it enabled orchestration of the baseline containers and management of key material. Envision Blockchain configured and integrated the Microsoft Dynamics 365 Finance and Supply Chain Management business apps.

The Baseline Protocol itself is a microservice architecture, where the different components reside in three Docker containers:

• Baseline Containers: Microservices providing the Baseline Protocol and Radish34 use-case, including several key enhancements (e.g., point-to-point messaging between parties, use of a generalized circuit for baselining agreements).
• Provide Containers: Microservices providing identity, key management, blockchain and messaging APIs representing the translation layer for data and Baseline Protocol messages, creating the messaging infrastructure leveraged by the Baseline stack for secure point-to-point messaging.
• Unibright Proxy: An extraction of the Unibright Connector (an integration platform), consisting of a simplified, context-related domain model and a RESTful API to integrate off-chain systems.

The demo’s developer package includes:

• Automated setup of a baseline environment for each process participant on their own infrastructure (i.e., using the participant’s own AWS or Microsoft Azure credentials); and
• A minimum domain model, following Occam’s razor principle, abstracting from the baseline targeted objects and offering a process oriented entry point for systems of record to integrate; and
• Integration patterns for a system of record via a service interface.

This work is the latest project on the Baseline Protocol roadmap, which builds on the initial project created in 2019 by EY, ConsenSys,and Microsoft. The work is actively being used to inform the first version of the protocol, expected in Fall of 2020.

On May 27 at 12 ET, the development team will host an open walk through of the system. To sign up for the meeting, click here.

For more information go to baseline-protocol.org/Baseline-SAP-Dynamics-Demo/.

About Ethereum OASIS

Ethereum OASIS is an OASIS Open Project that provides a neutral forum for supporting open source projects and specifications that advance interoperability for blockchain applications worldwide. The Ethereum OASIS community works to develop clear, open standards, first-rate documentation, and shared test suites that facilitate new features and enhancements for Ethereum. Everyone is welcome to contribute to Baseline, and suggestions for new Ethereum OASIS projects are encouraged.

For more information go to: https://github.com/ethereum-oasis/

About Unibright

Unibright is a team of blockchain specialists, architects, developers and consultants with 20+ years of experience in business processes and integration.

Unibright offers a blockchain framework, develops enterprise solutions, invests in start-ups, builds process modelling tools and integration platforms and offers a 360° ecosystem around tokenized assets.

For more information go to: https://unibright.io

About Provide Technologies

Provide Technologies is pioneering the tools, protocols and services to help organizations build and scale their blockchain investments with confidence. Our mission is making low-code enterprise blockchain application development accessible across any cloud or protocol. We are the foundation for how the most important companies are reshaping markets today through decentralization.

For more information go to: https://provide.services

About Envision Blockchain

Envision Blockchain Solutions is a Microsoft Gold Partner and systems integrator which provides enterprise consulting services and modern cloud application development. Our team innovates custom technology solutions that increase revenue and business process efficiency. Our mission is to reshape and align today’s enterprise systems allowing organizations a way to recognize new values in tomorrow’s industry vertical solutions.

For more information go to: https://envisionblockchain.com/

Baseline Protocol Secures Business Process Automation Across SAP and Microsoft Dynamics 365 Using… was originally published in Baseline Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Co-Written by Dermot O’Brien, Nico Elzer, and Huckleberry Hopper

Introduction

In case you missed the introductory article, the Baseline Protocol (not a product) enables counterparty state synchronization without exposing sensitive data to do so.

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.

Now, that doesn’t mean that every state-machine should be baselined to every other state machine (if these terms are confusing go read the introduction article!). Instead, it’s better to understand where baselining is valuable and, equally, where it’s not.

This article aims to help the reader tell the difference, and, in doing so, hopes to provide a starting point for the reader to consider problems that can be solved using the baseline design pattern.

A Starting Point: Shared Business Process Automation Between Counter-Parties

Businesses spend hundreds of millions of dollars on ERP, CRM and other internal systems of record. Failure to properly synchronize these systems between organizations causes considerable disruption and waste: disputes, lost inventory, inflated capital costs, regulatory actions, and other value leakage. So, in order to first identify whether two systems of record need to be baselined, the first requirement must be the requirement for synchronization between two separate parties and their respective systems of record. This synchronization must also have one primary goal — the execution and validation of an automatable process between the two parties. The key term there is automatable. Think of a repeatable business relationship with pre-determined and uniform steps. Within such a relationship, the counterparties are likely to have competing interests, lending to the need for process execution without the possibility of a disagreement or, worse, third-party agency problems.

Within this requirement, the misalignment of records must also cause harm to one or both parties. If it doesn’t, there isn’t value in establishing a shared proof prior to the disagreement occurring in the first place (because each step costs gas). So, when considering the two or more parties involved in any automatable workflow consider if —

Disagreement on some step within the overall workflow (no matter how simple) causes material harm to one or more parties.

Also, when reading the term workflow think — a series of this, then that, then this, statements bundled together to form a business-process. Within a workflow is a workflow step. A workflow step is simply a sub-process of if-then statements within the overall workflow.

Okay, back to it.

Assuming there is disagreement, and it does cause one or more of the parties harm (say, disagreement on an Invoice or an asset trade), then an unbiased frame of reference might be required to reconcile discrepancies.

To that end there are, of course, contextualizing factors that determine the real-world value of the Baseline Protocol as opposed to the theoretical application for the sake of technology. None of the technical stuff matters if it doesn’t provide real-value to people in the real world. But where does the Baseline Protocol provide compelling value over other methods of integration? What are the contexts that need to be considered?

At a high level, think in terms of —

1. The financial trade-offs of setting up counter-party integration systems
2. The security considerations of sharing data with a focus on data security and the regulatory environment in which those involved operate
3. The workflow requirements specific to the parties involved — both for today’s and potential future parties

Standard Integration vs Baselining

If multi-party process automation is the goal, then seek to identify situations where ‘baselining’ provides compelling value over traditional (meaning from the past and expensive) methods of integration. Enterprises spend hundreds of millions of dollars maintaining systems to manage business relationships with other organizations. Managing these relationships and shared record-keeping is traditionally solved through an intermediary or, alternatively, through the construction of complex integration systems. Unfortunately, this limits counter-party synchronization to only large companies with high-volume partnerships due to the CAPEX (capital expenditures) required to build such systems. Companies need to hire developers, consultants, set-up the integration architecture, make mistakes, tell the CFO about the mistakes, regroup, and so on. Alternatively, a ‘plug and sync architecture’ enables enterprises to trade their CAPEX for OPEX (operating expenses) while setting automatable business relationships up on the fly. In terms of value add, consider —

The attractiveness of reducing the upfront capital costs in the context of setting-up and executing business processes with counterparties.

For this to be valuable over traditional systems, it’s important to clarify what exactly qualifies the ‘attractiveness’ of reducing upfront capital expenditures as opposed to using an existing infrastructure as the Baseline Protocol proposes.This consideration is worth a discussion in its own right but there are two principally important considerations to make: the size of the counterparties involved and the volume in which the counterparties transact with one another. Traditionally, data sharing between large businesses and SMEs (small and medium sized enterprises) or between a large number of partners with low volume value/information/material transfers can be too costly to warrant the CAPEX of setting up integration networks.

This is especially true when considering all the accounting checks that are needed for each of the individual parties to confirm whether the value, information, and material was indeed received and accounted for. SMEs are particularly disadvantaged in these cost/benefit scenarios due to their lack of full integration of transaction systems; which, in turn, do not provide useful information to those who are authorized and require access — leading to data silos. So, consider the make-up of the involved partners. If —

Over 20% of partners are SMEs or do low volumes, then a ‘pay-as-you-go’ architecture may outweigh traditional solutions.

By opting to baseline, SME partners can remove their data silos through a standard shared interaction protocol while, at the same time, avoiding all the capital investment traditionally required to do so; thereby reducing the complexity of managing different interaction protocols and increasing the auditability (origin tracking, workflow step processing, etc) of SME interactions. This enables large organizations to justify business interactions with smaller organizations while not overburdening the SMEs in the process.

Traditional Systems of Records and Blockchains

Every business solution and its potential value-add must be considered in the context of the organization as a whole — especially in that of enterprise security and regulatory compliance. Paul Brody sets the stage nicely, “No CIO wants to be known as the CIO who shut the company down because he tried something really experimental and it didn’t work out.”

Translation: good security practices don’t usually involve trading risk for new technology unnecessarily — especially when it comes to something like a blockchain.

This doesn’t change the fact that enterprise systems still need to coordinate their shared-records. There’s a nuance here. Being generally security minded, enterprises need to know how their shared logic is being executed without adding attack vectors to their already existing infrastructures. The more complex the system, the more difficult it will be to change and the tighter security practices tend to be.

The resulting business need is integration without significant modification. When considering this, ask if —

Primary partners involved in the shared-interaction maintain tradition systems of record and don’t wish to sunset them

In such cases, there’s value in being able to integrate shared processes and workflows without (a) the need to dramatically entangle existing ERP systems (which are probably incompatible anyway) and (b) exposing additional security risk to already strained IT departments. Think value through ease of integration and value in safety.

A technical reader will note that enterprises are still going to be hesitant to put data — even if it’s encrypted — on a immutable, public, and permission-less blockchain. The Baseline Protocol addresses this by adding only ‘a proof’ of a shared business process to the Mainnet rather than the process being executed on the blockchain itself. To the network the proof looks how a metronome sounds — tick, tick, tick. There’s no proprietary symphony there.

Applied correctly, traditional systems of records (SAP, Oracle, etc) can verify those involved ran their respective processes verifiably without having to move sensitive data out of their systems in the first place. That’s the beauty all of this from a security standpoint. The counter-parties don’t even need to store sensitive data outside of their secure systems to begin with!

The Shared Logic Itself: Workflow Considerations

Okay stop! Take a breath. We’re flip-flopping between computer science concepts, ERP integration, terms like CAPEX , OPEX, sunsetting. It’s a lot. But stick with it!

Let’s do a quick recap. Investigate situations where two or more counterparties wish to automate a shared-business process between them. Within that requirement those involved both maintain traditional systems of record (Oracle, SAP, etc) and the value of ‘paying-as-you-go’ outweighs the benefits of setting up the integration systems needed to verify state between the counterparties. Within such a relationship, both parties don’t wish to significantly modify their current systems and are risk-adverse when it comes to protecting their sensitive company information.

The next step is to define the specific characteristics and requirements of the entanglement. These are the workflow considerations. The easiest way to conceptualize these are in terms of —

1. Who should have access to what workflow step, when, and why
2. What future workflow integrations could potentially be needed
3. The importance of workflow consistency and standardization to all parties involved (counterparties, regulators, auditors, etc)

First, consider access control. When two parties are interacting, controlling access to workflow steps is important because shared data unveils strategic information about each counterparty involved — much of which is likely material to begin with. Sometimes counterparties can trust one another to protect their shared and material information. Maybe the right incentives align.

But what if they don’t? What could happen if an untrustworthy counterparty had access to the entire workflow or more information than they need? Would it be possible for a counterparty to utilize this information in a manner that could compromise strategic information of their engaged partner (eg,. the blind coordination problem)? What if the regulations specify that certain counter-parties should only see certain parts of the total workflow?

In such cases —

Not all partners should have access to (or even awareness of) every step in the workflow

This refers to the concept of atomic compartmentalization (AC) — or (for you rappers among us), need to know workflows. A workflow can be said to contain atomic compartmentalization when, “it can restrict party access and awareness to a specific set of Parties down to a single Step or Record.” Recall that a process step could just mean signing a document, generating an invoice, generating a purchase order, etc. AC can be thought of as a method to restrict who gets access to (awareness of) what at any given point in time.

The challenge is achieving AC without creating additional data silos (boxes of information controlled by someone probably untrustworthy). In terms of business value, silo-less AC enables enterprises with competing interests and compliance requirements to still collaborate by utilizing a Mainnet as a common frame of reference.

There’s a key term there — Mainnet. The Mainnet is defined here as an, “always-on public utility, a state machine that resists tampering and censorship but sacrifices speed, scalability and fast finality in order to allow anyone to help maintain the integrity of the database.” In other words, it’s a unbiased (and therefore trustless) frame of reference that counter-parties can use to prove a workflow step is verifiably true; a place where two enterprises can agree that some shared state is true without having to question the provider of the truth itself.

One such implication of achieving atomic compartmentalization using a public, silo-less, Mainnet is the ease of integration of potential future workflows to existing workflows. This is in contrast to traditional methods of integration, which tend to create data silos. For illustration, imagine running a supply chain operation for a Tire company. Buyer Corp. spends millions to build a rubber procurement consortium on a private blockchain, and then realizes that it has to integrate with an automotive supply chain running an entirely different integration system. Now Buyer Corp. has to invest millions more to integrate this new supply chain component while simultaneously creating a brand new series of data silos to manage it. But if Buyer Corp is baselining, then it’s possible to take its existing workflow and simply find the steps where it needs to integrate with the other existing workflows. So if —

The chance of encountering other workflows that will require new integration later is high, then there’s value in silo-less integration

That said, access to and awareness of workflows is not limited simply to the counterparties directly involved. Buyer Corp. may be able to verify their shared-logic with Supplier Corp., but there are others who need access to verify the workflow’s integrity. This is where regulators, industry bodies, and legal requirements enter the picture (see figure).

Best practices dictate that shared business logic be verifiable by the regulatory bodies. Unfortunately, adherence to standards (ISO standards), regulatory frameworks (MIFI, EMIR), and reporting to authorities, is already expensive. To further muddy the waters, reporting requirements and standards often change and, along with them, the automation process requirements between counterparties. So after an organization has already invested considerable capital into automating their reporting process, they will need to continually re-invest into upgrading their systems as legislative frameworks and reporting requirements change.

Such requirements necessarily inhibit SMEs from entering markets due to the large compliance costs to adhere to standards and regulatory frameworks. This, however, doesn’t change the fact that data exchange and workflow rules must still comply with the regulatory parties (auditors, standard bodies, etc). So within the subset of requirements consider if the —

Shared business rules must adhere to standards and be performed consistently and verifiably across all parties

By opting to baseline, enterprises can execute shared-logic with one another without creating the additional administrative load of building out regulatory compliant integration systems for each counter-party (data silos!). This whole could instead be facilitated by creating a common library for all the participants to use. So when considering this final component look for situations where standards and regulatory frameworks change frequently, requiring businesses to update their internally automated reporting systems.

Putting It All Together: A Test-Kit Supply-Chain

Procurement presents a natural application of the Baseline protocol because it requires that two or more counterparties entangle their records to enable the exchange of goods given a simple set of terms. For relevance, consider a situation where a large pharmaceutical company (buyer) wishes to purchase COVID testing-kits from a supplier. Should their records be baselined?

The buyer needs to issue a series of requests for proposals (RFP) from a series of potential suppliers, identify the most favorable proposal, create a Master Service Agreement (MSA) with that supplier, then issue purchase orders and payments according to the specifications of the terms of the MSA. This workflow is definitely a business process between two counterparties that requires automation.

Stepping now into the business context, the buyer’s primary concern is getting the best price possible on their order and is therefore indifferent to the size of the supplier. The consequent supplier could be a small, medium, or large enterprise. It doesn’t matter to the buyer. Now given that these are relatively new suppliers (COVID testing kits are hopefully only a temporary need), it’s not worthwhile to invest in the large, capital intensive integration systems for each supplier. The volume is also going to be limited and the partners could be small, medium, or large. So the benefits of opting for a ‘pay-as-you-go’ infrastructure outweigh the CAPEX required to set up traditional integration systems.

Within the relationship itself, the supplier and buyer only care about the volume ordered and the price per unit defined by the volume ordered (higher volume, lower price). Given the volume ordered, the price per unit should calculated and the proper transactional steps should execute following the calculation. Now consider what happens if their records misalign — say, a supplier accidentally mixes up the volume order and calculates the wrong price per unit. If this happens then the seller is invoicing incorrectly; the supplier and buyer’s accounting suddenly requires fixing, costing them both money; the terms of the contract are violated, leading to potential legal action; the buyer could quickly lose faith in the seller, compromising future relationships; the list goes on. Ultimately, though, misalignment will end up costing both parties money. So synchronization has value.

Next is the security context. Because the buyer is a pharmaceutical company it wishes to maintain its security-centric ERP systems by default. Compromising supply-chain data could very well provide valuable insight to their competitors. So this particular buyer has a strong incentive to maintain their traditional systems of records and be slow to change them. Yet, record synchronization is still needed. Both parties therefore require integration without dramatically changing their existing systems — which are likely to be different anyway.

Finally, compliance and workflow requirements. Thinking forward, this supply-chain workflow could very well require later integrations with other partners — such as hospitals wishing to coordinate more closely with their suppliers. Given the uncertainty of the product itself (COVID-19 test kits are evolving) there’s a good chance later integration is needed.

Yet integration doesn’t imply that all the workflow steps can be public to all parties involved at all times. Definitely not. Instead, the buyer wishes to restrict the supplier’s knowledge to only what they need to know so as not to sacrifice key information about their extended strategic operations. Imagine, for example, the supplier knows who the buyer ultimately sells their test kits to (the theoretical hospital). They could then use that information to undercut the buyer and sell-directly to the retail client or sell that information to one of the buyer’s competitors. This problem would be even worse if the buyer later decides to integrate workflow steps with their end-customers. So not all partners should have access to or even awareness of every step in the workflow.

Yet, regulators, the buyer, and the supplier still need to be able to prove that each workflow step (plus the workflow as a whole) was executed properly. The buyer and supplier want to know price and volume. The regulators want to know who sold what, to whom, and whether or not the product adheres to the medical standards required for the test-kits. So standard verification by all parties involved is critical.

There you have it. Multiple parties need an automatable business process. The partners could be SMEs and the volumes are likely to be low (or at least limited). The value of opting for OPEX outweighs the need for CAPEX. Later on workflow integrations are likely. And, finally, the counterparties need atomic compartmentalization while simultaneously staying compliant in a verifiable and secure way.

Parting Thoughts

The answer to — What should be baselined? — is, unsurprisingly, a series of clarifying questions. While this article frames these questions sequentially, it doesn’t mean that all future considerations should be made in the same manner. We expect (hope) that many of you will come up with better ways to think about the value propositions using this design pattern.

Actually, the Baseline Community is already doing this. There are currently developers working to enable verifiable COVID status without sacrificing privacy to do so. Others are working to solve long-standing problems in procurement, potentially saving companies millions of dollars around the world while simultaneously enabling SMEs to enter markets that were too cumbersome in the past.

While right now a lot of this may sound complicated, the future should be simple — even a bit mundane perhaps. Using a couple really boring tools, some consensus, and a public place to store all it, proof of process no longer has to come at the expense of privacy. With the advent of collaboration networks and some math, human beings don’t have to rely on other humans to verify what humans think is true between humans. If that’s confusing, it should be. Collaboration is complicated. Baselining aims to make it simple, and, more importantly, verifiable.

All we’ve done is give you a starting point for where to look.

This article was co-written by Dermot O’Brien, Nico Elzer, and Huckleberry Hopper. It would not have been possible without the awesome edits of Charlie Morris and the ever-growing and infinitely helpful Baseline Community.

If you enjoyed our work leave a few claps to say so (we hear them in real life). More importantly, bias yourself towards action and join the mixing pot that is the Baseline Community. There’s already a diverse group of people involved and we are truly at the beginning of an exciting time in enterprise blockchain.

Works Cited

Baseline Protocol Documentation: https://docs.baseline-protocol.org/

“Enterprise Resource Planning (ERP) — SpringerLink.” 27 May. 2014, https://link.springer.com/article/10.1007/s10796-014-9506-5. Accessed 30 Apr. 2020.

“Implementation Challenges of an Enterprise System and Its ….” https://www.semanticscholar.org/paper/Implementation-Challenges-of-an-Enterprise-System-Conteh-Akhtar/bb7ac434e09f936fbce982643638f6d2b0595a19. Accessed 30 Apr. 2020.

“Cross-organizational workflow integration using contracts ….” https://www.sciencedirect.com/science/article/pii/S0167923602000155. Accessed 30 Apr. 2020.

“Towards a Framework for Semantic Business Process ….” http://ceur-ws.org/Vol-339/paper1.pdf. Accessed 30 Apr. 2020.

“A framework for beef traceability from farm to slaughter using ….” https://www.sciencedirect.com/science/article/pii/S0168169908002329. Accessed 30 Apr. 2020.

“Information Security Management Best Practice Based on ISO ….” https://pdfs.semanticscholar.org/53f1/6a5a62e2bac36fea38158c1e8af80fac683a.pdf. Accessed 30 Apr. 2020.

“The Integration and Interoperability Issues of … — IEEE Xplore.” http://ieeexplore.ieee.org/document/4027181. Accessed 30 Apr. 2020.

“Risk-aware Migration of Legacy Data Structures — IEEE Xplore.” https://ieeexplore.ieee.org/document/6619488/. Accessed 30 Apr. 2020.

“Temporal Consistency of View Based Interorganizational ….” https://link.springer.com/chapter/10.1007/978-3-540-78942-0_11. Accessed 30 Apr. 2020.

“Facilitating cross-organisational workflows with a workflow ….” https://www.sciencedirect.com/science/article/abs/pii/S0169023X04000357. Accessed 30 Apr. 2020.

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

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:

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 Baseline Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let us begin with what is Baseline?

Baseline is a protocol and an open-source initiative that combines advances in cryptography, messaging and blockchain to execute secure and private business processes at low cost via the public Ethereum Mainnet.

The protocol enables confidential and complex collaboration between enterprises without leaving any sensitive data on-chain.

The core of the baseline protocol:

Blockchain: The public Ethereum Mainnet)

Messaging Service: Whisper, a communication protocol for DApps / a P2P messaging service

Zero-Knowledge-Proofs — ZKP’s: A method by which one party ( prover) can prove to another party (verifier) that they know a value X, without conveying any information apart from the fact that they know the value X.

This blog is an outcome of the conversation currently going on [COVID Test Result Baseline]

Let us get into a series of questions, that focuses on how baselining a medical test could be really useful:

• Q: Why is a blockchain useful for storing medical test results?
  A: To have an immutable record of when, where, who + test result + salt for entropy (all hashed data) pushed on-chain by a trusted source (hash pushed on-chain by Eth address owned by test clinic). The patient can then share this hash and the underlying data with event organizers to prove they are safe to attend.
• Q: What added benefit(s) does baseline provide beyond storing a hash on-chain?
  A: It inherently provides the needed infrastructure (database for storing hash’s underlying data + Eth block/tx for reference, Eth provider to query blockchain data, messenger for sharing data from clinic to patient) so that the patient/clinic doesn’t have to manage that on their own. Also, the OrgRegistry or DID should help prove the link between the test clinic’s Eth address and their off-chain identity (through x509 cert?)
• Q: Do we need baseline’s secret messenger or would email work fine here?
  A: The value of the data doesn’t require the same privacy as high-value enterprise applications. However, the baseline system is integrated with a secret messenger to communicate data between parties (test clinic and patient) so it is still needed unless you want to build your own integrations with another messaging service.
• Q: Besides the infrastructure, do we need baseline’s shield contracts and zkp service? Is the added complexity and cost (on-chain transactions + computing resources) worth the benefit in this case?
  A: I’m leaning towards no. The main benefits of shielding and zkp in Radish are to provide privacy and enforce business rules that (1) require events to happen in a predefined order (buyer sends RFP, supplier responds with Proposal that references that RFP), and (2) require checking against agreed-upon limits (ex. the sum of purchase order product quantities cannot exceed MSA total quantity). The “medical test” use-case doesn’t have the same structure where we are tracking progression through a predefined series of events. Rather, this feels like a one-time hash pushed on-chain. It can be referenced multiple times but is there a “second state” in this “state machine” beyond the initial one?

Thank You, Samuel Stokes, for coming up with the above Q & A’s.

After going through the series of Q & A we know how baselining can play a vital role ( 2nd Q&A)

Could these be the steps to baseline a medical test?

Steps:

1. An individual visits a testing centre for a medical test. The centre collects the samples and sends it for the specific test that the individual has asked for.
2. Once the test results are received the testing centre contacts the individual and hands over their reports to them.
3. Here, let us baseline it, the received reports are stored in both the databases say for example the patient’s/ individual’s database and the testing centre’s database and the hash for the report is stored on the Ethereum Mainnet. How? Let us not get into the technical details of it. If you are curious to know, how? you can go through this Github discussion, this idea is still in the POC phase and yet to be implemented from a technical point of view.
4. Once it has been done suppose an individual wants to attend Tomorrowland — 2021, he/she can show that they are COVID-19 negative directly by submitting the baseline proof which the event organizers can verify on the go and decide whether to let the individual in or not.

From a technical standpoint:

1. Try to build an understanding of the Radish34 (Supply Chain Management) which uses the baseline protocol for requesting proposals (RFPs), creating master service agreements (MSAs) etc based on this started code refactoring.
2. Refactoring the code as per the requirement of baselining a medical test, Medical Test Baseline, this is a work in progress, contributions are welcome.
3. Contributions are needed to identify the flow right from genesis to completion similar to that of creating RFP’s to finalizing MSA’s between a buyer and a supplier in case of Radis34.
4. The flow includes communicating via whisper, using graphql wherever required, zkp’s for proving (this comes at a cost, do we really need it in this case?), answering what? why? how? when? etc of different workflows.

With the discussions said above and coming to a conclusion, these could be the final steps to baselining a medical test report

A potential use case, as laid down by John Wolpert for this:

Abbott Labs machines baseline their results for verified fast patient use —

When a physician, hospital other clinical provider receives one of the new Abbott Labs testing machines, they go through a quick web setup where they create a Workgroup consisting of everyone who should get any results from this machine. When this occurs, a Shield Contract, orgRegistry and Verifier Contract is created on Mainnet. (Not included at this point is the later inclusion of a specific Patient in the Workgroup. This is a difference to be considered from the Radish34 POC, where everyone is included at Workgroup setup…will need a way to add parties to the orgRegistry mid-stream.)

Just before a Patient gets tested by the machine, they are offered the opportunity to get their test results baselined to their private database. In this story, let’s imagine 1Password has been equipped to receive baseline messages and interact with baseline proofs and workflows. So here the patient would provide their orgRegistry data, which would include the 1Password endpoint that will receive the test result messages. (1Password is just one storage idea…could also be Uport. Using 1Password to make the point that this component can be old-school and not a cryptosystem.)

Now they have the actual in-the-clear data of their test results, sent via p2p secret message into their 1Password API endpoint. And they also have the baselineProof/hash and its location on the Mainnet (which now sits inside the Workgroup’s shield contract).

Now, say the Patient wants to go to Coachella 2021, and their new policy is you need to have shown that you actually had COVID and recovered more than N weeks or months prior to the event (imagining a scenario where an event would only want to admit post-symptomatic positives because they are sure to be immune and no longer shedding virus). The Patient goes to Coachella’s web site and provides the baseline proof from 1Password. Here’s another “wrinkle” from the Radish34 example. Here, we want a method to bring the Coachella system into the baseline in such a way that they get only a subset of the data that is baselined between the Patient and the clinic/etc….or another approach would be to set things up in such a way that 1Password messages Coachella with the name/ID and the material (“result is positive,” “date is XYZ”) that can be checked against the baseline to confirm authenticity without having to get the clinic or other healthcare providers involved.

Note:

• Let us come together in fighting COVID-19 pandemic from a technical perspective, this could be our little contribution, however, it has the potential to impact millions of lives.
• Refactoring the code as per the requirement of baselining a medical test, Medical Test Baseline, this is a work in progress, contributions are welcome.

I would like to thank John Wolpert for coming up with this idea, Heather Flannery for discussing this over a call, Samuel Stokes for the Q&A’s, and all the participants on this discussion thread.

Baselining — A medical test (COVID-19) was originally published in Baseline Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today at noon, the open source Baseline Protocol initiative opened its Github repo to the public.

You can find it at: https://github.com/ethereum-oasis/baseline

And the documentation is here: https://docs.baseline-protocol.org

And of course, the website (currently getting an upgrade) is at: https://baseline-protocol.org

There’s a lot out there already about what the baseline approach is and why it might be important. And there will be more here as we go forward. This is the official Baseline Protocol Medium Publication, edited and contributed to by the community.

If you want to be part of the community, join us on Slack, sign up as a member, get involved in working sessions (lead some!), and star, watch, fork and contribute to the repo.

The code hasn’t been available for three hours and already there are product MVPs cooking, spontaneously-generated explainer videos on YouTube, and even a paid course on this very new blockchain subject on the Azure Marketplace.

The bus is leaving the station. Hop aboard.

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