Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed and open data validation oracles #29

Open
Varunram opened this issue Sep 19, 2019 · 0 comments
Open

Closed and open data validation oracles #29

Varunram opened this issue Sep 19, 2019 · 0 comments

Comments

@Varunram
Copy link
Member

Varunram commented Sep 19, 2019

Closed and Open Data Oracles

As openclimate is structured right now, we have oracles which perform multiple data validation tasks - from companies, individuals, etc. On a broad scale, such data might be divided into two categories:

  1. Open Data - data that is intended by the submitter to be public
  2. Closed data - data that is intended by the submitter to be private (in parts)

Open Data

In an open data ecosystem, the data of the submitter is published to ipfs and the hash is logged by the platform. Furthermore, the committer creates either

  1. A transaction with an OP_RETURN pointing to the stored ipfs hash, or
  2. An adaptor signature that commits to the point pertaining to the ipfs hash

An oracle can either

  1. Take the hash from the platform and proceed for verification, or
  2. Observe the blockchain for confirmed hashes and proceed to validate them.

A submitter can choose to withdraw submitted data within the block interval time by double spending the funds and data is not deemed final until it is in the blockchain.

Once an oracle observes said hashes, it can access the data from ipfs, perform analyses on it and come to a conclusion on whether the data submitted by the submitter was indeed correct. If the data is said to be correct, the oracle can either:

  1. Submit its own commitment transaction attesting to the validity of data, or
  2. Submit a commitment to the smart contract which publishes a final transaction attesting to data

Oracles can define their own models for verification or follow standards ones as defined by appropriate bodies.

Closed Data

In a closed data system, there are parts of data that are deemed sensitive to be released to the public and as a result, the submitter will not submit their data to the platform. Instead, the submitter must either

  1. Provide proofs (could be technical or legal) that their submitted data conforms to given standards
  2. Provide access to a random oracle towards which certain queries on data can be made (the random oracle here can be imagined similar to the Random Oracles used for analysing cryptosystems)

Random Oracle

In a random oracle model, the querier can make a certain (in cryptosystems, infinite) amount of queries to the oracle and the oracle gives them a set of responses. In our application, the oracle might have to answer specific questions about emissions, tons of CO2 emissions prevented, etc that would lead to the querier believing that the underlying data is correct.

As with the oracles in the open oracle case, these modes can be formulated either by the oracles themselves or by third parties. Once the verifier is convinced that the submitter isn't lying, they can submit a commitment to the blockchain attesting that the data submitted by the submitter is indeed correct. This would work similar to the open oracle case.

Consensus among Oracles

The system that we want to design is composed of multiple oracles each of which should have the capability to independently verify data. In the event that two oracles come to opposing conclusions, we must have a mechanism to verify or validate which oracle is correct. This could be done by verifying the different models, having external opinions, etc but the easiest way this can be solved would be to have a mechanism for consensus within the oracles themselves.

Since the main purpose of oracles is to validate data, we don't assume that they will be running on very complex machines (and as a result, a scheme like Proof of Work has to be ruled out). Instead, we can either rely on BFT or Proof of Stake schemes to ensure consistency between oracles.

In the event that we do have oracle validation pools, these pools could internally have their own consensus mechanism for ensuring consistency which would make for an interesting application.

Note that the thing described above does not describe how the models around the oracles are designed (data of the platform, oracle models, etc). It instead describes how an oracle scheme can be built on top of any base layer (ie the oracle layer is independent of the base layer).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant