Provide has contributed a complete reference implementation of the core interfaces as specified in the v0.1.0 release of the Baseline Protocol. This reference implementation will inform the OASIS standard.
The reference implementation runs on the Ethereum Ropsten testnet and can be configured to run on many other public or permissioned EVM-based blockchains; a complete list of supported Ethereum clients will be curated over the coming months.
Clone the Baseline repository:
Checkout the bri-1-privacy branch:
Once checked out, navigate to the /examples/bri-1/base-examples folder.
Run the following to install local packages and run the test suite against the Ropsten testnet:
In a separate terminal window, run the following command to view all container logs while the tests are running:
The reference implementation illustrates Alice & Bob, respective owners of Alice Corp and Bob Corp, establishing a workgroup and baselining an in-memory record (i.e., a JSON object) using the Provide stack.
The following high-level architecture diagram illustrates how the concepts discussed in previous sections (i.e., the Provide and Baseline Protocol architecture sections) fit together in the context of two organizations deploying the Baseline Protocol using Provide as a common technology stack and their own cloud infrastructure vendors (i.e., AWS and Azure). The reference implementation deploys these same two distinct stacks to your local machine using docker-compose when running the test suite
There are several assertion and checks that have to be carried out, in full and in a specific order to ensure that the base example can run and fully demonstrate the functionality and potential of the Baseline protocol, leveraged by the Provide stack. Subsequent sections illustrate the necessary components and their outputs as well as the rationale for their importance.
Workgroup assertions All on-chain artifacts existence and accessibility will be asserted, this includes the ERC1820 contract, the organization registry, workgroup shield, workflow circuit verifier contract, and the circuit identifier. We will also assert we have established a connection with NATS, and that there is an active subscription to the baseline.proxy subject.
Vault assertions The user will be able to register its corporation in the local registry and the on-chain registry using the default secp256k1 address. We will the ensure all vault related services are fully functional. We will assert a default vault for the organization has been created as well as a set of key pairs for the organization for babyJubJub, secp256k1, and finally ensure the secp256k1 key pair can resolve as the organization address.
Messaging assertions We will also assert we have established a connection with NATS, and that there is an active subscription to the baseline.proxy subject.
SNARK assertions TBD
Decoded workgroup Invitation
The following JSON object represents the decoded invitation JWT signed by Bob Corp and delivered to Alice. The invitation has everything Alice needs to join Bob's new Baseline workgroup, register Alice Corp with the on-chain OrgRegistry contract and use the protocol to synchronize her local Provide stack.
Baseline Reference Implementation-1 using the core Provide stack.
This reference implementation of the core interfaces specified in the v1.0 release of the Baseline Protocol is called BRI-1 and has been contributed to the open source community under a public domain CCO-Universal license by individuals and companies including Provide, EY, Nethermind, ConsenSys, and others. It heavily utilizes the core Provide application stack and is compatible with Shuttle, an on-ramp for baselining.
The reference implementation is instrumented to run on the Ethereum Ropsten testnet and can be configured to run on many other public or permissioned EVM-based blockchain.
The BRI-1 "base" example codebase can be found here.
The Provide stack is a containerized microservices architecture written in Golang. The core microservices depend on NATS, NATS streaming, PostgreSQL and Redis. Note that the NATS server component is a fork that supports decentralized, ephemeral bearer authorization using signed JWTs.
Ident Identity and authorization services for applications (i.e., workgroups in the context of the Baseline Protocol), organizations and users. Read more about how authorization works here.
Vault Key management for traditional symmetric and asymmetric encrypt/decrypt and sign/verify operations in addition to support for elliptic curves required for advanced messaging and privacy applications.
NChain REST API for decentralized application building, and deploying and managing peer-to-peer infrastructure. The service provides daemons for (i) monitoring reachability of network infrastructure and (ii) creating durable, real-time event and analytics streams by subscribing to various networks (i.e., EVM-based block headers and log events). Privacy REST API Service that provides zero knowledge proof circuit management (creation and verification) to enable trust minimized enterprise ecosystems. Privacy delivers an agnostic privacy and cryptography solution, with built-in Gnark compatibility, at enterprise-scale.
PostgreSQL
Each microservice has an isolated database; each service connects to a configured PostgreSQL endpoint with unique credentials. When running the stack locally (i.e., via docker-compose), each isolated database runs within a single PostgreSQL container.
NATS
NATS and NATS streaming are used as a fault-tolerant messaging backplane to dispatch and scale idempotent tasks asynchronously. Each NATS subject is configured with a ttl for the specific message type which will be published to subscribers of the subject; if no positive acknowledgement has been received for a redelivered message when its ttl expires, the message will be negatively acknowledged and dead-lettered.
Redis Caches frequently-updated and frequently-accessed key/value pairs (i.e., real-time network metrics).
Provide CLI Command line interface to build and deploy provide services programatically.
Each microservice requires the presence of a bearer API token to authorize most API calls. A bearer API token is an encoded JWT which contains a subject claim (sub) which references the authorized entity (i.e., a User, Application or Organization). The encoded JWT token will, in most cases, include an expiration (exp) after which the token is no longer valid. Tokens issued without an expiration date (i.e., certain machine-to-machine API tokens) can be explicitly revoked. The standard and application-specific JWT claims are signed using the RS256 algorithm. The authorized entity may use the signed bearer Token to access one or more resources for which the Token was authorized. Unless otherwise noted, all API endpoints require the presence of a bearer Authorization header.
Baseline Proxy An Integration middleware for baselining systems of record is implemented in the form of the baseline proxy which is fetched and deployed directly from the provide-cli. BRI-1 makes use of the the baseline proxy image to complete the setup of a generalized baseline ecosystem that is fully compliant with the Baseline standard.
This implementation of the Baseline Protocol leverages the Provide stack for security (i.e., authn and authz), managing key material, signing transactions, subsidizing transaction fees (i.e., if a gas/subsidy faucet is configured at runtime), etc. The various APIs in the core Provide microservices fully implement the interfaces defined in the Baseline Protocol specification (i.e., IRegistry and IVault interfaces).
As illustrated above, NATS is used to facilitate the handling of inbound and outbound protocol messages; in the context of the Baseline Protocol, NATS acts as a control plane to route inbound protocol messages to an appropriate asynchronous handler. Such handlers could, for example, ensure that BLINE protocol messages represent verifiable, valid state transitions (i.e., as governed by the business process and privacy protocol) prior to updating baselined records within a system of record such as SAP or Microsoft Dynamics.
This reference implementation provides a complete, robust implementation of the Baseline Protocol specification.
It is important to note that a subset of the specification can be implemented using the core concepts demonstrated in this reference implementation without depending on the entire Provide stack.
For example, implementing only NATS as a control plane for dispatching inbound protocol messages is possible using only the @baseline-protocol/messaging package. In such a case, the entire protocol as demonstrated within this reference implementation would be far from complete, but protocol messages could be sent and delivered.
