Oracle interface #1154
Oracle interface #1154
Conversation
| @@ -0,0 +1,94 @@ | |||
| --- | |||
| eip: 1154 | |||
| title: Oracle Interface | |||
There was a problem hiding this comment.
Please add a discussions-to URL.
There was a problem hiding this comment.
I've pointed it at this PR. I hope that is okay, but LMK if the preferred process is to have the discussion elsewhere or something.
There was a problem hiding this comment.
This PR exists for just this change, not the EIP itself. Please use somewhere that can be used for ongoing discussion of the EIP - such as an Ethereum Magicians thread, or an issue in this repo.
| In order for ethereum smart contracts to interact with off-chain systems, oracles must be used. These oracles report values which are normally off-chain, allowing smart contracts to react to the state of off-chain systems. A distinction and a choice is made between push and pull based oracle systems. Furthermore, a standard interface for oracles is described here, allowing different oracle implementations to be interchangeable. | ||
|
|
||
| ## Motivation | ||
| The Ethereum ecosystem currently has many different oracle implementations available, but they do not provide a unified interface. Smart contract systems would be locked into a single set of oracle implementations, or they would require developers to write adapters/ports specific to the oracle system chosen in a given project. |
There was a problem hiding this comment.
Can you provide example use-cases? What sort of oracles is this intended to support? Who would benefit from standardising such an interface?
There was a problem hiding this comment.
The use case I had in mind originally was for answering questions about "real-world events", where each ID can be correlated with a specification of a question and its answers (so most likely for prediction markets, basically).
Both the ID and the results are intentionally unstructured so that things like time series data (via splitting the ID) and different sorts of results (like one of a few, any subset of up to 256, or some value in a range with up to 256 bits of granularity) can be represented.
Another use case could be for decision-making processes, where the results given by the oracle represent decisions made by the oracle (e.g. futarchies).
There was a problem hiding this comment.
Can you expand on this in the EIP? And maybe make the title of the EIP more specific?
|
|
||
| ```solidity | ||
| interface OracleHandler { | ||
| function receiveResult(bytes32 id, bytes32 result) external; |
There was a problem hiding this comment.
This seems to assume one particular type of oracle - one that returns exactly 32 bytes of data, and is a trusted party. There are many other types of oracle; what about them?
There was a problem hiding this comment.
Regarding the trusted party factor: I've intentionally decided to start drafting the spec in as strict a manner as possible. With that said, there isn't a clear mandate about the authorization model, so it's not necessarily a single account which is authorized to make the report. Also, mechanisms like multisignature wallets, side/child chains, or something else may be used to distribute the trust if it was mandated to be a single account.
Regarding the 32 bytes of data: I am still debating and open to making the result an arbitrary-size blob of bytes. My contention is two-fold:
- Putting much more than a word of result data (say like a paragraph) is probably not very actionable. Large amounts of input data is more suitable for, say, the field of machine learning, instead of smart contracts.
- You can carve out an index byte in the ID if you want to pass 256 consecutive words to the handler, so it doesn't necessarily limit the result size in some sense, but at that point, I'd seriously ask whether this should even be going on the chain.
There was a problem hiding this comment.
Services like Oraclize would seem to demonstrate uses for more than 32 bytes of onchain data, however.
* Started writing proposal * Added more commentary and removed comments * Update and rename eip-oracle_interface.md to eip-1154.md * Add discussions-to URL * Corrected discussions-to link * Expand on use cases and types of oracles supported
Please see #1161 for the discussions thread.