Welcome to the Baseline Protocol Community

The Baseline Protocol initiative was announced on March 4, 2020 and launched as an OASIS open source project on March 19, 2020, supported by fourteen founding companies. More companies joined the effort shortly thereafter and continue to do so. In 2021, the Enterprise Ethereum Alliance and OASIS collaborated to establish the Baseline Protocol and other projects as EEA Community Projects.

The work of the community is maintained under a public domain license.

The Baseline Protocol is a set of techniques that must be implemented in a standard way across different systems. The draft open standard was completed in September, 2021 and submitted to OASIS for review. The current specifications are maintained here.

There are lots of opportunities to get informed, get involved, and get value out of developing reusable components, and ultimately deploying the Baseline Protocol in your own offerings. Go to https://baseline-protocol.org and click "Join the Team".

New Contributors to the codebase and standard: Go here for contribution guidelines.

About the Baseline Protocol

The Baseline Protocol is the emerging standard for synchronizing state across different systems of record over the internet, using a public blockchain as a common frame of reference. This applies to traditional corporate systems of record, any kind of database or state machine, and even different blockchains or DLTs. It is particularly promising as a way to reduce capital expense and other overheads while increasing operational integrity when automating business processes across multiple companies.

The approach is designed to appeal to security and performance-minded technology officers.

You can find all the details on the current version of the Baseline Protocol here.

The Baseline Protocol Source Code

Version 1.0 of the Baseline Protocol has been released. It is composed of a set of 6 core packages that are available open-source, under the CC0 1.0 Universal public domain dedication. For the full license text, refer to license.

You can find more about the source code here.

The Baseline Protocol Standard

The Baseline Protocol Standard will be a set of three specifications - CORE, API and CCSM that together, provide the requirements to be satisfied to implement a compliant Baseline Protocol Implementation (BPI).

It is developed and will be ratified as an Oasis open standard, available under the CC0 1.0 Universal public domain dedication. For the full license text, refer to license.

You can find more details on the Baseline Protocol Standard here.

The Baseline Protocol Reference Implementations

A growing number of Reference Implementations and demos to help you understand baselining and give you ideas for your own projects can be found here.

The first complete reference implementation, BRI-1 has been developed by individuals and community leaders including Provide, EY, Nethermind, ConsenSys, and others.

Today, there are demos, prototypes, and production systems being developed in more places than can be tracked, and some have been submitted as public domain contributions to the community.

Baseledger and other Resources

The Baseline Protocol standard does not stipulate the use of any particular state machine as the common frame of reference, where baseline proofs are deposited and managed, in a baselined workgroup. However, the first public Layer-2 implementation of this service is called Baseledger, details about which may be found at https://baseledger.net.

The Baseline Protocol initiative was announced on March 4, 2020 and launched as an OASIS open source project on March 19, 2020, supported by fourteen founding companies. The number of active companies and individuals contributing to the work and using it in products and enterprise solutions grew quickly through the Summer of 2020 and currently is estimated at over 600.

The initiative is strongly aligned with the Mainnet Working Group, a joint effort of the Enterprise Ethereum Alliance and the Ethereum Foundation.

This work is active and open to contributors.

All work in the Baseline Protocol public repo is released under the CC0 1.0 Universal public domain dedication. For the full license text, refer to license.

Leadership

In an openly governed open standards / open source initiative, leadership is organic. One need not be seated to a committee to lead. One need not be the chair to lead the community in a direction. (Indeed, the chair's primary job is to harmonize the interests of others and help the community move to a shared vision, not necessarily to forward their own point of view.)

The way to lead is to start something, help something, fix something...even spellcheck something! The way to lead is to get others to amplify what you are doing (best done by listening deeply to others first). The way to lead is to serve your own (and your company's) enlightened self interest. You should be able to draw a straight line from your time on this work to real impact for your own offerings.

Below are the things you need to know to get informed, get involved and get value out of the work.

Working Together

Anyone can join the Baseline Protocol communication channels (see below), and anyone with a Github ID can view the roadmap (don't forget to log in with github id), fork the repo, and submit pull requests to contribute to the work.

You can also become a regular Member of the initiative, which will allow you to manage Issues and push directly to most repo branches (other than Master). Members who step up to be accountable for projects can become General Assembly members. Members who take on responsibility for maintaining the integrity of the work and merging contributions to the master branch of the repo can become Core Developers. And finally, contributors can nominate and vote-in members to be on the governing Technical Steering Committee (TSC) annually.

Below are the things to know about how to get involved and work with the team.

Meetings and Meetups

There are regular meetings of the TSC, General Assembly, Core Developers and other groups. These are typically listed here. If the times we have don't work for your timezone, we can do 1-1's or make changes to the schedule.

Onboarding: Help Getting Started

It's critical that new contributors have a good idea about what the focal points of the community are and where one can make a real impact. It's hard to beat having a real conversation about how to get started in an intimate setting where you can ask questions and get immediate answers.

We will hold Onboarding office hours once a week. Watch the Calendar for details or inquire on one of the communication channels below. Sessions and other learning material will be posted on our YouTube Channel and on Medium.

Technical Steering Committee

The TSC meets typically once a month to review progress. Members of the TSC receive invitations and you can rsvp to join any meeting by sending a message to the TSC Chair.

General Assembly

The General Assembly meets typically once a month to review roadmaps and set high-level priorities. Members of the General Assembly receive invitations, and you can join any meeting by sending a message to the TSC Chair.

Communications: Connecting with Each Other Directly

Slack / Discord / Telegram

The Baseline Protocol initiative maintains a Slack channel that is moderated but public. Sign up here. It's an active group, and you can directly connect with folks doing the work and coordinate with each other to get the work done.

Thanks to an enterprising member of the community, we now also have a shared Matterbridge-enabled channel between Slack, Telegram, and Discord. You can post -- and read what anyone posts -- on the shared channel, regardless of which platform you are using. In Slack, use the #community-chat channel to broadcast to Slack, Discord and Telegram. In Discord, use the #general channel. In Telegram, just use the main /baselineprotocol thread.

Members Directory

You can sign up to the baseline protocol members list and get access to the Directory. This will show you any members who have elected to be displayed publicly. There are others who will choose to be hidden but will receive group emails.

Group Email

While most communication seems to go through the Slack/Discord/Telegram channel, we do have email. When you sign up in the members directory, you will have the option to get email that's sent to the mailing list or directly from anyone in the group. You can control how that impacts your inbox here.

Forums

The Baseline Protocol initiative is launching soon a Discourse forum. Reddit is also likely. We also actively use commenting on Epics and Issues to conduct threaded discussions on key projects and engineering topics. To View the Zenhub Board for these, sign into Github with your ID, or you can install the Zenhub plugin to your Chrome browser and sign in that way. If you are member of the Ethereum-Oasis Org.

The Baseline Protocol initiative maintains the @baselineproto Twitter account, to which members of the TSC, General Assembly and some maintainers can post. We also use the #baselineprotocol tag.

Medium

The Baseline Protocol initiative uses Medium to post blogs. Here is the publication. Reach out on Slack to the TSC Chair, OASIS team or members of the steering committees, if you want to be a writer or editor.

YouTube

The Baseline Protocol initiative maintains a YouTube Channel. If you have videos that you'd like to add to the Channel or would like to help on Baseline Protocol video assets, use the Slack #comms-and-marketing channel and raise your hand.

​

The Baseline Protocol Standard will be a set of three specifications - CORE, API and CCSM that together, provide the requirements to be satisfied to implement a compliant Baseline Protocol Implementation (BPI). The v1.0 draft for each of those documents is available on Github: here.

CORE Specification

The CORE specification describes the minimal set of business and technical prerequisites, functional and non-functional requirements, together with a reference architecture that when implemented ensures that two or more systems of record can synchronize their system state over a permissionless public Distributed Ledger Technology (Consensus Controlled State Machine) network. An overview of the CORE specification is available here.

API Specification

The API specification describes the Baseline programming interface and expected behaviors of all instances of this interface together with the required programming interface data model. An overview of the API specification is available here.

CCSM Specification

The CCSM specification describes the requirements that a CCSM must satisfy for it to be used in a BPI as Distributed Ledger Technology or Consensus Controlled State Machine (CCSM) is the foundational enabler of a Baseline Protocol Instance with no or limited trust assumptions. An overview of the CCSM specification is available here.

There are four ways to contribute:

• Write code (Architecture, Spikes, Issues, Tasks)

• Write specifications (Epics, Stories, Prioritizations, Use Cases)

There is one other way to contribute, and it's the most important: use the work in the Baseline Protocol to improve your own offerings. The Baseline Protocol is not a product or platform..the product is YOUR product.

Code of Conduct

Here is the link to the Baseline Protocol code of conduct:

Technical Contributors

BLIPs

Issues Organization and Community "Sprints"

Technical tasks are written as Github Issues. Issues will be reviewed, lightly prioritized, and communicated as "hey, help out here!" messaging to the developer community every two weeks. The TSC will periodically review what Issues and communications best succeeded in attracting help.

An Issue should be constructed, in particular, with acceptance tests. All other elements of a good Issue should be known to any practicing developer.

Most Issues should be attached to an Epic (see below).

A good Task/Issue starts with a Verb: "Implement xyz."

Submitting a pull request

Follow these steps when submitting a pull request:

2. Create a new branch, based on the master branch, with a name that concisely describes what you’re working on (ex. add-mysql).

3. Ensure that your changes do not cause any existing tests to fail.

4. Submit a pull request against the master branch.

Good practice strongly favors committing work frequently and not loading up a long period of work in isolation. Be brave...let others see what you are working on, even if it isn't "ready."

eCLA and iCLA

Core Developers and Commit Rules

Merging to Master requires review by THREE Core Developers. The TSC seeded the initial set of Core Developers. Now, any active Member can become a Core Developer. Core Developers may add more Core Developers by rough consensus, and the TSC may step in to resolve cases where this process fails.

Specifications Contributors

Epics and Stories Organization

Zenhub enables Epics to nest, while Issues don't nest...not really. Therefore, the community will employ the practice of using Issues for engineering Tasks and Epics to contain high level topics, which may have nested within them a set of agile Epics, and in them a set of Stories, and even Stories may have other Stories nested in them. Engineering meets planning where a Story (in the form of a Zenhub Epic) is referenced by an Issue/Task. (This can work very well, but Zenhub's choice in calling Epics, Epics can cause confusion.

A Good Story

A Zenhub "Epic" used as a high-level container for a grouping of work should be in short topic form -- primarily nouns.

A Zenhub "Epic" used as a Story should almost always follow the form: "As X, I need Y so that I can Z." An acceptable variant is the "now I can" form (note the "so that" clause is preserved):

• A Party's System Administrator can look up Counterparties in an OrgRegistry (a public phone book) and add them to a Workgroup, so that they can start Baselining Records and Workflows.

• A Party's System Administrator can quickly and easily verify a Counterparty's identity found in the OrgRegistry, so that they can be confident in adding the Counterparty to a Workgroup.

• A Party's System Administrator can use some or all of the Counterparties and Workflow Steps defined in one Workgroup in Workflow Steps created within another Workgroup, so that Workgroups don't become yet another kind of silo.

​Contributors

The Baseline Protocol provides a framework that allows Baseline Protocol Implementations (BPIs) to establish a common (business) frame of reference enabling confidential and complex (business) collaborations between enterprises without moving any sensitive data between traditional Systems of Record.

Presented below, a reference architecture that when implemented ensures that two or more systems of record can synchronize their system state over a permissionless public Consensus Controlled State Machine (CCSM) network.

Reference Architecture Layers

A Baseline Protocol Stack Reference Architecture as depicted above in Figure 1 is comprised of the following layers:

• Baseline Protocol (BPI) Abstraction Layer: This layer enables accessing all externally available BPI functions through APIs as defined in the Baseline Protocol API Standards document

• Middleware Layer: This layer manages all counterparties to an agreement and its associated workflows and worksteps with business rules and business data as well as all counterparty delegates. In addition, it manages all messaging between counterparties to an agreement and instantiation of processing layers based on newly created or updated agreements and their workflows, worksteps, business rules, and business data.

• Processing Layer: Manages, properly sequences, and deterministically processes and finalizes in a privacy-preserving, cryptographically verifiable manner all state change requests from counterparties to all agreements represented in the BPI.

• CCSM Abstraction Layer: This layer enables accessing all required BPI functions implemented on one or more CCSMs through APIs as defined in the Baseline Protocol API Standards document.

• CCSM Layer: This layer manages, properly sequences, and deterministically processes in a privacy-preserving, cryptographically verifiable manner all transactions from the Processing Layer as well as either deterministically or probabilistically finalizes on the CCSM all CCSM state transitions based on said transactions.

Components of each layer

• BPI Abstraction layer

  • API Gateway: An API gateway that exposes all required functionality to the counterparties to an agreement and enforces all necessary authentication and authorization of API calls as well as properly directs the API calls within the Baseline Protocol Stack

  • Application: The application logic which manages the pre-processing and routing of all API requests, as well as the enforcement of authentication and authorization protocols and rules.

• Middleware Layer

  • Workflows: A Business Process Management engine that allows for the definition, management, and instantiation of workflows and worksteps and associated business rules and data based on (commercial) agreements between counterparties

  • Identity/Accounts/Workgroups: A capability that allows for the identification and management of counterparties and their delegates as well as members of workflows and worksteps organized in workgroups that are derived from the counterparties to an agreement.

  • Messaging: A messaging capability that allows the exchange of secure and privacy-preserving messages between counterparties to an agreement to communicate and coordinate an agreement on proposed (commercial) state changes.

• Processing Layer

  • Transaction Pool: one or more transaction pools that hold, properly sequence, preprocess and batch for processing by the Virtual State Machine all requested state change transactions of a BPI.

  • Virtual State Machine: one or more Virtual State Machines which deterministically processes and finalizes in a privacy-preserving, cryptographically verifiable manner all state change request transactions.

  • Storage: A storage system for the cryptographically linked current and historical state of all (commercial) agreements in a BPI.

• CCSM Abstraction Layer

  • API Gateway: An API gateway that enables accessing all required BPI functions implemented on one or more CCSMs, and properly directs the requests within the CCSM Abstraction layer to the proper CCSM API application logic

  • Application: The CCSM API application logic manages the pre-processing, as well as the proper usage of the underlying CCSM and BPI authentication and authorization.

• CCSM Layer is comprised of

  • Messaging: A messaging capability that allows the exchange of messages between CCSM nodes that comprise either received transactions or a new proposed CCSM state.

  • Transaction Pool: A transaction pool holds, properly sequences, pre-processes, and batches for processing by the CCSM Virtual State Machine all submitted CCSM transactions.

  • Virtual State Machine: A Virtual State Machine deterministically processes in a cryptographically verifiable manner all submitted transactions for CCSM state changes.

  • Storage: A storage system for the cryptographically linked current and historical state of all CCSM State Objects.

Glossary

What is the Baseline Protocol?

Why Baseline Different Systems of Record?

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. To avoid these problems, systems require a common frame of reference. But only the largest high-volume partnerships can afford the capital expense involved in setting up such integrations. The baseline approach requires a common frame of reference that is always on, strongly tamper resistant and able to prevent any individual or group from taking over the system and locking companies out of valid operations. These requirements strongly suggest the use of a public blockchain or Layer-2 network anchored to a public blockchain.

Past approaches to blockchain technology have had difficulty meeting the highest standards of privacy, security and performance required by corporate IT departments. Overcoming these issues is the goal of the Baseline Protocol.

Illustrative High-Level Example

An illustrative example of the use of a Baseline Protocol Implementation (BPI) is a Buyer placing an order to a Seller. Normally a Buyer system creates an Order and transmits it to the Seller system through some preestablished messaging system without providing proof that the Order created is correct or even that both parties processed and stored the message consistently. This forces the Seller and Buyer systems to validate the order, often manually. This then leads to a time-consuming and often expensive back and forth between Seller and Buyer to rectify inconsistencies.

A Master Services Agreement (MSA) between a Requester (Buyer) and a Provider (Seller) is implemented on a BPI and contains billing terms, pricing, discounts, and Seller information such as billing address, etc. Once established and agreed upon by Buyer and Seller, the BPI provides state synchronization between Buyer and Seller, since the ERP systems for Buyer and Seller can now refer to mutually agreed-upon data as a common frame of reference.

Based on this mutually agreed-upon state in the MSA, the Buyer creates an Order based on the MSA, employing a cryptographic proof that confirms not only the correct application of business logic but also the correct application of commercial data in the Order creation. This proof is submitted together with the Order through the BPI and then is validated by the Seller. If the proof is validated, the Seller accepts the proposed state change by generating its cryptographic proof, confirming its acceptance of the state change. The Seller then updates the state of the business workflow in the BPI and sends the new proof to the Buyer.

The figure below visually demonstrates high-level Buyer and Seller Order generation and acceptance assuming that an MSA between Buyer and Seller already exists and is recorded on a BPI and that the commercial state has been synchronized up to this workstep in the commercial business workflow.

Figure 1: Illustrative Example of how the commercial state between Buyer and Seller is synchronized and an Order created.

Without a BPI, both Buyer and Seller must assume that the MSA between them and all its values are correctly represented in the other party’s respective Systems-of-Record. Hence, if an order is created based upon the MSA but does not comply with the MSA, it will likely result in extensive manual interactions between Seller and Buyer at one stage or another to resolve the problem to their mutual satisfaction.

Glossary