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

Conversation

Projects
None yet
2 participants
@cag
Copy link
Contributor

commented Jun 17, 2018

Please see #1161 for the discussions thread.

cag and others added some commits Jun 14, 2018

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

This comment has been minimized.

Copy link
@Arachnid

Arachnid Jun 18, 2018

Collaborator

Please add a discussions-to URL.

This comment has been minimized.

Copy link
@cag

cag Jun 18, 2018

Author Contributor

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.

This comment has been minimized.

Copy link
@Arachnid

Arachnid Jun 18, 2018

Collaborator

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.

This comment has been minimized.

Copy link
@Arachnid

Arachnid Jun 18, 2018

Collaborator

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

This comment has been minimized.

Copy link
@cag

cag Jun 18, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@Arachnid

Arachnid Jun 18, 2018

Collaborator

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;

This comment has been minimized.

Copy link
@Arachnid

Arachnid Jun 18, 2018

Collaborator

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?

This comment has been minimized.

Copy link
@cag

cag Jun 18, 2018

Author Contributor

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.

This comment has been minimized.

Copy link
@Arachnid

Arachnid Jun 18, 2018

Collaborator

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

@elopio elopio referenced this pull request Jun 18, 2018

Closed

Better oracle interfaces #16

@cag cag referenced this pull request Jun 19, 2018

Open

EIP 1154: Oracle interface #1161

@Arachnid Arachnid merged commit 02cf4dd into ethereum:master Jun 28, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

Arachnid added a commit to Arachnid/EIPs that referenced this pull request Jul 19, 2018

Oracle interface (ethereum#1154)
* 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 cag:oracle-interface branch Jul 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.