You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Open Data - data that is intended by the submitter to be public
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
A transaction with an OP_RETURN pointing to the stored ipfs hash, or
An adaptor signature that commits to the point pertaining to the ipfs hash
An oracle can either
Take the hash from the platform and proceed for verification, or
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:
Submit its own commitment transaction attesting to the validity of data, or
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
Provide proofs (could be technical or legal) that their submitted data conforms to given standards
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).
The text was updated successfully, but these errors were encountered:
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:
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
An oracle can either
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:
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
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).
The text was updated successfully, but these errors were encountered: