An Overview of the Ocean Protocol

Both Ocean and Computable are working on creating decentralized data exchanges. If you’re a casual observer following along, you might be curious what the similarities and differences are. If you’re reading along on this forum, you might have a pretty decent idea of how Computable works (if you’re new, check out our whitepaper). But you might not have a clear idea of how Ocean operates. In this post, I’ll try to explain the core architecture of Ocean and the pieces of software that underpin its stack.

Let’s start with terminology. The Ocean team has put together a useful terminology resource that covers some of the core terminology in their protocol. I’ll do a quick review and comparison with our terminology:

  • Ocean Network: A network of EVM nodes that runs the Ocean contracts. At present these are private networks, but the Ocean Production Network will be a network of Parity EVM nodes that runs the Ocean main-net. The Computable contracts will be deployed on Ethereum, so there isn’t a direct analogue.
  • Ocean Tokens: The central network token that underpins the Ocean network. Here’s a description of the function of the token. There isn’t a similar network token in Computable at present.
  • Asset: An asset is anything that can be registered and made available on Ocean. This could be a datasets, algorithms, pipelines, models or more. An asset is roughly analogous to a Listing in Computable.
  • Data Owner: A data owner is someone who has data they want to sell or distribute. A data owner is analogous to a Maker in Computable.
  • Publisher: A mediating party for data owners. A publisher is analogous to the Datatrust Operator in Computable.
  • Consumer: A consumer is someone who wants access to assets. A consumer is analogous to a Buyer in Computable.
  • Marketplace: A place where publishers can list available assets and consumers can peruse and buy data. A marketplace is analogous to a Data Market in Computable.
  • Verifier: A party who checks a step in a transaction. There isn’t a direct analogue in Computable at present. The Delivery object has some safeguards in place to control transactions, but these are algorithmic without third-party verification.
  • Service Execution Agreements: A contract-like agreement between a publisher, consumer, and verifier that specifies which assets are to be delivered to the consumer from publisher with the verifier ensuring delivery. A SEA is roughly analogous to a SLA (Service Level Agreement) in standard business terminology. There doesn’t exist a direct analogue in Computable at present.

There’s a complex software ecosystem that underlies the Ocean protocol. The Ocean team has put together a helpful resource page. Here’s a brief review of the core components:

  • Keeper: A computer running an EVM compatible blockchain. Think of this as the parity EVM client
  • Keeper Contracts: The blockchain that keepers form should have these contracts deployed. The contracts are themselves implemented in solidity. The analogous repo is computable which implements the core Computable contracts in vyper.
  • Secret Store: This is the parity secret store, which is used for distributed key generation. This system is used to manage access control to assets. This is an interesting system for which there isn’t currently a direct analogue in Computable.
  • Aquarius: This is a metadata store that a marketplace runs to host metadata about the data that’s available. The datatrust is responsible for this functionality in Computable.
  • OceanDB: The off-chain database software used to store data. Behind the scenes, this is going to be a standard database such as MongoDB, Elasticsearch, or BigchainDB. The datatrust implements the database access in Computable. For our present prototype, we use DynamoDB, but the choice of database isn’t enforced by the Computable protocol
  • Brizo is a piece of software that publishers run to provide extra services on top of assets such as running computation on top of data. At present, the datatrust doesn’t provide such functionality.
  • Osmosis Driver: This is the file storage driver used by Brizo for storage needs. This can be a standard cloud service such as S3.
  • Squid: These are the client libraries that provide access to Ocean protocol. There are variants in javascript, python, and java. The analogous tools are and computable.js
  • Pleuston, Commons: Sample web app for consumers to explore and download data assets.

The Ocean team has written up an overview of their protocol design here. They divide the structure of Ocean into three conceptual layers:

  • “Keeper Layer” - manages service agreements (see keeper contracts)
  • “Verifier Layer” - manages cryptographic challenges to maintain integrity of the protocol
  • “Curator Layer” - manages discoverability of data.

At present there does not appear to be a custom software suite for verifiers to run (this functionality looks to be provided by the Keeper contracts). There are a few web apps for curators but there doesn’t appear to be a standard software layer there either.

I’ve mentioned some elements of Ocean that don’t have a direct analogue in Computable, but there are also a number of components in the Computable protocol that don’t have a direct analogue in the Ocean ecosystem. These include the market token, reserve, and patrons among others. As a crude summary, the Computable protocol focuses more on data governance and protecting the rights of data owners, while Ocean focuses more on interoperability between data sources as part of one seamless layer.

I’ve highlighted some similarities and differences in both protocols above, but it’s important to emphasize that both Computable and Ocean are attempting to solve challenging problems in bootstrapping a decentralized marketplace of data. Given the large open source footprint for both projects, there’s a lot of value in learning from each other’s efforts towards solving the challenge of democratizing access to the world’s data.