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

Oracle interface #1154

Merged
merged 6 commits into from Jun 28, 2018
Merged

Oracle interface #1154

merged 6 commits into from Jun 28, 2018

Conversation

@cag
Copy link
Contributor

@cag cag commented Jun 17, 2018

Please see #1161 for the discussions thread.

@@ -0,0 +1,94 @@
---
eip: 1154
title: Oracle Interface
Copy link
Contributor

@Arachnid Arachnid Jun 18, 2018

Please add a discussions-to URL.

Copy link
Contributor Author

@cag cag Jun 18, 2018

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.

Copy link
Contributor

@Arachnid Arachnid Jun 18, 2018

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.
Copy link
Contributor

@Arachnid Arachnid Jun 18, 2018

Can you provide example use-cases? What sort of oracles is this intended to support? Who would benefit from standardising such an interface?

Copy link
Contributor Author

@cag cag Jun 18, 2018

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).

Copy link
Contributor

@Arachnid Arachnid Jun 18, 2018

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;
Copy link
Contributor

@Arachnid Arachnid Jun 18, 2018

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?

Copy link
Contributor Author

@cag cag Jun 18, 2018

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:

  1. 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.
  2. 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.

Copy link
Contributor

@Arachnid Arachnid Jun 18, 2018

Services like Oraclize would seem to demonstrate uses for more than 32 bytes of onchain data, however.

@cag cag mentioned this pull request Jun 19, 2018
@Arachnid Arachnid merged commit 02cf4dd into ethereum:master Jun 28, 2018
1 check passed
Arachnid added a commit to Arachnid/EIPs that referenced this issue Jul 19, 2018
* 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
@cag cag deleted the oracle-interface branch Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants