@SunDrez asked:
No matter how I juggle this… the Oracle integration is not something i can get my head around.
Chef and I want to bet. We load the SC from a template, Chef takes England, I take Canada in a rugby match…
Now we both put our ZP tokens 50 each into the SC.
The SC has both our addresses. As to who will be paid out on the condition being met determining the winner in the game…
Now that SC needs an input, the input comes from a provider… the provider let’s say is Sport Illustrated www . SI .com
How is this information going to be interfaced with the ZP blockchain?
I can not understand this, as it just seems much to much…
I personally dont think it can be done…
Though I certainly hope it can be done…
2 Likes
Reply by Ariel: one of ZP devs.
The oracle we are currently working on is based on a contract, and it works like this:
The contract can be executed by 2 commands:
- “Commit” - which is executed by the provider of the data.
- “Attest” - which is executed by anyone who needs an attestation for the data.
The provider executes the contract with the “Commit” command and the relevant data and asks it to mint a commitment token using the hash of that data along with the PK of the provider (and a timestamp) as a subidentifier, and locks it to itself.
This ownership of that commitment token by the contract is now an embodiment of the commitment of the provider on that data.
Afterwards whenever someone needs to use that data they ask the contract to provide an attestation for it using the “Attest” command, so the contract mints another token (called the “attestation” token) which is derived from the commitment token (by taking the hash of its subidentifier again), locks it to the caller, and locks the commitment token to itself again.
The idea is as follows:
The only way to get the attestation token for the specified data is by asking the contract to generate a transaction by attestation (with the “Attest” command).
The only way for the transaction generated by the attestation to be valid is if the contract had the commitment token to begin with, since it has to lock it to itself and cannot do that with an asset it doesn’t have.
The only way for the contract to have a commitment token of that data is if the provider has invoked the contract with the “Commit” command and provided the contract with that data.
So in conclusion - the only way for someone to have an attestation token on some data is if the specified provider has committed to that data, so the attestation token functions as a guarantee for the authenticity of that data, and can be used whenever you need to prove that some data has indeed been committed to.
The bottom line is that the provider commits to some data and mints a token which embodies that commitment.
So it all boils down to a question of how much that provider is trustworthy.
There are of course ways to avoid the requirement to trust a single provider, for example by integrating data from multiple sources, but that’s a separate issue.
1 Like