Better oracle interfaces about openzeppelin-contracts HOT 9 CLOSED

An EIP relevant to this feature: ethereum/EIPs#1154

from openzeppelin-contracts.

I think you have more than enough to start :D I would recommend to start with a very basic usecase, and grow from there. If you make a PR for your work-in-progress, we can give you feedback early.

Thank you!

from openzeppelin-contracts.

Town Crier: Authenticated Data Feeds for Smart Contracts

from openzeppelin-contracts.

We are currently implementing an oracle with https://tls-n.org/, I can let you guys know how our experience was. (TLS-N needs no special Hardware as compared to town crier, but a plugin on the webserver)

from openzeppelin-contracts.

That's actually very interesting @superphil0!

from openzeppelin-contracts.

Using inversion of control (oracle is calling the contract) is a very interesting idea!
There are multiple ways to achieve that, the most trivial would be that contract owner would designate particular oracle (allow them to send data in) and then only this oracle would be allowed to update the state.
Challenges here: 1) oracle is 'coupled' with the contract (as it has to be designated by the contract creator), hence changing the oracle will be an issue

2. what would be an incentive for an oracle to call contract back?

ad1) adding a proxy: owner is picking the proxy, and via this proxy oracle will be decoupled. fixes the issue with coupling, and introducing own additional issue: how proxy could be trusted.
Are there better options?

ad2) in the contract method, when called (only by designated oracle), paying back could be implemented (ie fee based).

is this a correct direction of thinking?

from openzeppelin-contracts.

Hey @miktam, those sound like good points to explore.

Maybe, at the same time that an oracle is designated, some money can be left for it to pull. This money will be transferred as the last step of the method that the oracle calls to deliver the data.

We can just trust the oracle, and use an small allowance that will be dripping every time we receive data. We could add some time based constraints so we receive data slowly, and the oracle can't call the method a million times at once.

Or we can research how to validate the data that we receive from the oracle. This is hard because it will depend on the type of data, but filecoin is exploring that for storage, foam for location, wibson for personal data. You can also check Oraclize.

This is a very interesting problem, please let us know if you need some help from our side :)

from openzeppelin-contracts.

@ElOpio, thank you for your help!

to continue:

1. pick data type to be updated, probably would be good to define struct, eg struct ExternalData.
   Examples above (from filecoin/foam/wibson) could be used for a start
2. designate an external oracle which would be able to update ExternalData, defining:

• fee per call, paid to the oracle
• minimum/maximum frequency to update needed values (eg at least once per hour, and not more than one per day)

3. supporting more than one oracle wold improve reliability and resiliency.
   in this case there are multiple options to find a consensus, eg take a simple average, or take the values in the middle (eg OracleA reports 10, OracleB reports 20, OracleC reports 16 - then extremes would be dropped, keeping only 16). those rules could be defined while creating ExternalData struct.
   With more than one oracle, fee distribution could be implemented in a few ways:
   a) fee would be paid randomly only to one of them (they would not need to gain the result). problem with this approach that any random oracle could win, no matter how accurate the data is.
   b) pay to all of them, and reward the most "correct" one, eg pay 50% of the fee to the one in the middle, and remaining to share among the rest.
   c) during the defining ExternalData, creator would specify sane limits (eg if its a temperature, then limits would be [-50, 50]
   d) historical data could be also used to filter out extreme results (eg accept results which do not vary more than 5% from the historical average).

now its becoming quite a complex problem, still manageable tho.
does it sound enough to draft an interface?

should be enough for a start, what do you think?

from openzeppelin-contracts.

Closing as outlined in #971.

from openzeppelin-contracts.