Ocean Protocol Review


10 min read
Ocean Protocol Review

Someone asked about this project the other day and, while intriguing, there were a few points of contention that I brought up with the project's premise and design.

Keeping in mind that in the world of decentralized finance (and staking), the premise of a project means little to nothing - there are still certain factors that must be considered before deeming a project to be worthy of investment.

Taking a Look at Ocean Protocol

The quickest way to dissect what this project is about is to visit its main site - oceanprotocol.com

Upon arrival, we're instantly greeted with the site's premise:

Specifically, the screenshot above contains text stating:

"Ocean Protocol helps developers build marketplaces and other apps to privately & securely publish, exchange, and consume data."

With this definition, the initial impression that I got of this project was that it was a SDK provider of some sort (sort of like Tendermint/Cosmos).

However, since there is a token associated with 'Ocean Protocol', this cannot be the case (by itself), so I knew that there was more digging to be done.

Fortunately, not too much since the project's main premise was presented directly below this one:

The screenshot above provides a more detailed breakdown of the project, stating:

"Quickly launch your own data marketplace, using Ocean software components, connected tot he decentralized Ocean data sharing network. Data providers can monetize data while preserving privacy and control; data consumers can access data that they couldn't get before: private data

Where the Qualms With the Idea Begin

The idea of a 'decentralized exchange' premised on sharing data (presumably data gathered from cookies / trackers that analyze user habits, clicks, behaviors & preferences) is nonsensical.

There are already very well-established channels for advertisers / others that are seeking to purchase said information.

Any company with any level of repute is extracting that information for themselves or at the very least, using a 3rd-party / contracted entity in order to obtain such information. I'm not sure how one could expect that a user / entity on the 'open market' would have curated data that Coca Cola would be interested in (that Coca Cola has not already hired a firm to obtain directly).

There is no protection of the buyer in this situation. Since it is promoted as a 'decentralized' structure, there is no provision / workaround in place to give buyers any level of confidence that they're purchasing quality information / data / analytics.

When it comes to blockchain (which is the space we're in), most information / API data is freely available all over the place.

If that information is not freely available, then there are no shortage of data analytics firms, projects, geeks, incubators etc., that are pedaling their data distribution / connecting services.

More About the Project's True Premise

Outside of the main website, promotional content for Ocean Protocol has been structured around the following concept:

Based on what we can see above, it appears that the entity that wrote the statement is proselytizing for Ocean Protocol by characterizing it as a marketplace where "artificial intelligence" data can be sold.

Ocean Protocol's Idea Has Gone Off the Rails

Artificial Intelligence?

Perhaps 'DeFi' is a hard sale for most people (and for good reason), but artificial intelligence should be out of the question.

This isn't Science Fiction

To be clear, artificial intelligence is in existence currently but to leverage the sharing of data premised on discoveries in the field of artificial intelligence (or perhaps A.I. itself) onto blockchain, sorry, no, a token breaches the realm of possibility and lands us squarely within the frame of science fiction.

Sadly, this appears to be where Ocean Protocol is going with their idea here.

Ocean Protocol Doubles Down on Their Preposterous Proposal to Integrate Artificial Intelligence With Blockchain

Below is a screenshot from a recently released article (June 4th) by Ocean Protocol (on Medium), titled, 'Ocean Compute-to-Data in Jupyterlab'

link = https://blog.oceanprotocol.com/ocean-compute-to-data-in-jupyterlab-3729b7901c18

Interesting.

Let's Fast Forward to the Relevant Information

A few paragraphs into the article, we can see a link to 'Data Science'.

Chasing the link to 'datascience.oceanprotocol.com'.

JupyterLab Notebook Example

To Ocean Protocol's credit, it appears that they've given us a Jupyter Lab Notebook example that users can run (on their own personal hosted / deployed JupyterLab instance) to test the efficacy of Ocean Protocol's design.

Okay, fair enough.

As listed above, the link is

datascience.oceanprotocol.com

Which takes us to their 'Manta Ray' project (depicted below):

It appears that they were also kind enough to offer a direct link to their own hosted JupyterLab instance (shown in the pink button in the middle of the screenshot above).

Perfect.

But before we go there, let us evaluate the example notebook, shall we?

That can be found here: https://github.com/oceanprotocol/mantaray_jupyter/blob/master/s05_compute_to_data.ipynb (ipynb file ending designated for Python files, which JupyterLab is designed to run, in essence).

Evaluating the Notebook

There's probably no easy way to do this from within a report, but the smartest course of action for a user to take would be to copy each one of the separate 'pages' of the notebook & paste them within the running JupyterLab instance that Ocean Protocol has hosted through their 'Manta' data science website.

We can, however, evaluate the purpose of the Jupyter Lab notebook presented to us (in the meantime).

It is re-posted below for convenience:

Apparently, these services will require the integration of:

Identity Management / Authentication Modules: Reflected in the requirements of the publisher, which must, "manage permissioned access to the compute resource that si allowed to access the private data."

Resource Publishing Capabilities: This is reflected in the mandate that the publishing of an asset consists of, "Make files URLs or identifiers that can be used to identify the data files when running compute jobs."

To be clear, number two could be facilitated by the creation of hashes on the blockchain (i.e., by delineating various hash outputs to a corresponding file), but that would also require one to establish this fact (whilst remaining private, because everything that is published on the blockchain is done so publicly and in clear text; hashes only obfuscate information - not encrypt it). But the purpose here would only be for identification, explicitly, which makes me question how this would be implemented (it also doesn't appear to be addressed within the context of the Jupyter Notebook either - but I could be wrong -- welcoming the team's critique on any facet of this analysis here).

Mention of Aquarius

This seems to be another moving part within the 'Ocean Protocol' ecosystem that is intertwined in the setup proposed her, but we haven't encountered any information about Aquarius yet.

However, a quick visit to Ocean Protocol's documentation provides us with more information (located here: https://docs.oceanprotocol.com/references/aquarius/)

Hmm. Another off-chain process and database store? (isn't the purpose of blockchain to function as a decentralized, distributed relational database of sorts, too?)

The documentation below shows us API documentation, specifically.

What Does That Mean?

Various API endpoints for the 'Aquarius' service are defined in this documentation for reference for those seeking to make calls to those endpoints in order to extract certain information.

This would explain the code notes within the Jupyter Lab notebook that refers to the external calls to an API of some sort for data (see below):

The API in question = "squid"

This extensive API attachment to this protocol begs the question though of, 'How are the API endpoints protected?'

Again, remember there must be some sort of identity management integrated into the protocol (by the publisher, according to the specifications here).

And I'm failing to see where that authentication would come from.

Without Authentication / Protection of API Endpoints, API = Vulnerable!

One of the most common ways to protect and secure an API endpoint is through the use of JWT tokens (JSON web tokens).

link = jwt.io

JSON Web Tokens are actually defined through various RFCs by the IETF for use within the context of API identification, authentication, signing of data (and encryption as well).

link = https://tools.ietf.org/html/rfc7519

Multiple Different Types of JWT Tokens

To be clear, JWT tokens refer to their 'state' before they've been put into 'use'.

Once a JSON Web Token is in use, it can either become a JWS (Web Signing) or JWE (Web Encryption). The latter can also contain information form the former within it (this is important to remember).

Generally, these two different token standards are used in different contexts, but information is handled by both of them through the use of JSON -- which actually makes the idea of authentication via the blockchain far from implausible.

An example of the type of data that is covered (and subsequently rendered) from these tokens can be seen below:

Notably, this data is in JSON, which is the same format in which data is delivered via the 'Aquarius' API, designed by Ocean Protocol, that we were discussing earlier.

Below is a reference from their documentation:

I'll stop things right here, because we're going to get a little too far off the beaten path if we keep explaining the functionality of JWT (JSON) tokens (there are also Paseto tokens as well, which have their own RFCs and claim to be easier to deploy, manage and secure endpoints and API with - but if we cover that, then we'll really find ourselves lost in an inescapable rabbit hole).

Why I'm Harping On API Endpoint Security

If we move just a bit farther down the Jupyter Notebook, we can see the following directives:

My points of contention specifically are:

  1. Publisher account address must be created and relayed over the API here ; this could be susceptible to a MITM attack without any authentication
  2. The fact that there are addresses being produced here (which inherently requires the use of some cryptography library), but there is no authentication scheme premised on JWT that's included as well! (that's another missed opportunity and a point off of the design here for me)
  3. The fact that the continuation of the protocol is premised on a call for the account balance (but I'm not entirely sure how that call is made because its not within the logic of a smart contract since we're off-chain now); my qualm is not necessarily that this can't be done or that there would be any difficulties in doing so, but there is already logic that exists on Ethereum to facilitate such a process, why introduce greater counterparty risk by circumventing the smart contract standards altogether for the sake of deploying these functions outside of the protocol? (off-chain)

Conclusion

I think the idea of artificial intelligence on the blockchain (in the way that Ocean Protocol proposes they will implement it), is far-fetched at best (more than likely not possible in the least bit).

However, they could do something interesting if they decided to take this in another direction entirely.

If I were in contact with the team, I would urge them to:

  • Scrap the A.I. idea altogether ; its not ever going to be used by anyone and it won't work anyway. I get it - this sounds very impressive and like something that will move the needle forward on convincing people that this token is radically different than anything we've ever seen before, but it won't have that impact. Instead, you'll just end up with assholes like me that give your project a super harsh critique.
  • There is a lot of opportunity here to integrate an authentication / identification schema / protocol with Ocean. That alone would be a huge money earner - and I mean that outside of the context of markets. The fact that the team is aware of the DID Protocol (which involves sidetree deployment), tells me that this concept is not foreign to them. However, since there is no valid authentication scheme embedded within the project, it almost feels like this integration / usage of the DID is a complete waste.
  • To be clear, the integration of the DID scheme is a complete waste because the sidetree protocol was originally designed / created within Ethereum! There are even online, open demos of how the sidetree protocol works. This should be removing the need for all of these external API calls / JupyterLab notebooks etc. (unless they're being used explicitly to communicate with the sidetree and extract relevant information; remember this is a protocol in itself and it also serves as an effective keystore!)
Apart from that...if at lest some of these ideas I proposed above (among others) aren't embraced, then the team is more than likely wasting their time moving forward with Ocean Protocol unless they're able to get some decent attention in the blockchain sphere, and I'm questioning how plausible that is when considering the slew of DeFi projects that have croppped up over the past few weeks and months that are now taking the crypto space by storm.

GO TOP