status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-26 14:51:17 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 1154

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Alan Lu 2018-09-05 12:02:20 -05:00 committed by EIP Automerge Bot
parent 0ff6220872
commit cc61e826d7
1 changed files with 20 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
EIPS/eip-1154.md
View File

@ -34,7 +34,7 @@ Both the ID and the results are intentionally unstructured so that things like t
<dt>Oracle</dt>
<dd>An entity which reports data to the blockchain.</dd>
<dt>Oracle handler</dt>
<dt>Oracle consumer</dt>
<dd>A smart contract which receives data from an oracle.</dd>
<dt>ID</dt>
@ -44,12 +44,12 @@ Both the ID and the results are intentionally unstructured so that things like t
<dd>Data associated with an id which is reported by an oracle. This data oftentimes will be the answer to a question tied to the id. Other equivalent terms that have been used include: answer, data, outcome.</dd>
<dt>Report</dt>
<dd>A pair (ID, result) which an oracle sends to an oracle handler.</dd>
<dd>A pair (ID, result) which an oracle sends to an oracle consumer.</dd>
</dl>
```solidity
interface OracleHandler {
function receiveResult(bytes32 id, bytes32 result) external;
interface OracleConsumer {
function receiveResult(bytes32 id, bytes result) external;
}
```
@ -57,21 +57,23 @@ interface OracleHandler {
`receiveResult` MUST revert if `receiveResult` has been called with the same `id` before.
`receiveResult` MAY revert if the `id` or `result` cannot be handled by the handler.
`receiveResult` MAY revert if the `id` or `result` cannot be handled by the consumer.
Consumers MUST coordinate with oracles to determine how to encode/decode results to and from `bytes`. For example, `abi.encode` and `abi.decode` may be used to implement a codec for results in Solidity. `receiveResult` SHOULD revert if the consumer receives a unexpected result format from the oracle.
The oracle can be any Ethereum account.
## Rationale
The specs are currently very similar to what is implemented by ChainLink (which can use any arbitrarily-named callback) and Oraclize (which uses `__callback`).
With this spec, the oracle _pushes_ state to the handler, which must react accordingly to the updated state. An alternate _pull_-based interface can be prescribed, as follows:
With this spec, the oracle _pushes_ state to the consumer, which must react accordingly to the updated state. An alternate _pull_-based interface can be prescribed, as follows:
### Alternate Pull-based Interface
Here are alternate specs loosely based on Gnosis prediction market contracts v1. Reality Check also exposes a similar endpoint (`getFinalAnswer`).
```solidity
interface Oracle {
function resultFor(bytes32 id) external view returns (bytes32 result);
function resultFor(bytes32 id) external view returns (bytes result);
}
```
@ -80,25 +82,29 @@ interface Oracle {
`resultFor` MUST return the same result for an `id` after that result is available.
### Push vs Pull
Note that push-based interfaces may be adapted into pull-based interfaces. Simply deploy an oracle handler which stores the result received and implements `resultFor` accordingly.
Note that push-based interfaces may be adapted into pull-based interfaces. Simply deploy an oracle consumer which stores the result received and implements `resultFor` accordingly.
Similarly, every pull-based system can be adapted into a push-based system: just add a method on the oracle smart contract which takes an oracle handler address and calls `receiveResult` on that address.
Similarly, every pull-based system can be adapted into a push-based system: just add a method on the oracle smart contract which takes an oracle consumer address and calls `receiveResult` on that address.
In both cases, an additional transaction would have to be performed, so the choice to go with push or pull should be based on the dominant use case for these oracles.
In the simple case where a single account has the authority to decide the outcome of an oracle question, there is no need to deploy an oracle contract and store the outcome on that oracle contract. Similarly, in the case where the outcome comes down to a vote, existing multisignature wallets can be used as the authorized oracle.
#### Multiple Oracle Handlers
In the case that many oracle handlers depend on a single oracle result and all these handlers expect the result to be pushed to them, the push and pull adaptations mentioned before may be combined if the pushing oracle cannot be trusted to send the same result to every handler (in a sense, this forwards the trust to the oracle adaptor implementation).
#### Multiple Oracle Consumers
In the case that many oracle consumers depend on a single oracle result and all these consumers expect the result to be pushed to them, the push and pull adaptations mentioned before may be combined if the pushing oracle cannot be trusted to send the same result to every consumer (in a sense, this forwards the trust to the oracle adaptor implementation).
In a pull-based system, each of the handlers would have to be called to pull the result from the oracle contract, but in the proposed push-based system, the adapted oracle would have to be called to push the results to each of the handlers.
In a pull-based system, each of the consumers would have to be called to pull the result from the oracle contract, but in the proposed push-based system, the adapted oracle would have to be called to push the results to each of the consumers.
Transaction-wise, both systems are roughly equivalent in efficiency in this scenario, but in the push-based system, there's a need for the oracle handlers to store the results again, whereas in the pull-based system, the handlers may continue to refer to the oracle for the results. Although this may be somewhat less efficient, requiring the handlers to store the results can also provide security guarantees, especially with regards to result immutability.
Transaction-wise, both systems are roughly equivalent in efficiency in this scenario, but in the push-based system, there's a need for the oracle consumers to store the results again, whereas in the pull-based system, the consumers may continue to refer to the oracle for the results. Although this may be somewhat less efficient, requiring the consumers to store the results can also provide security guarantees, especially with regards to result immutability.
#### Result Immutability
In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical handlers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the handler enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the handler would also have to handle result immutability.
In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical consumers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the consumer enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the consumer would also have to handle result immutability.
For data which mutates over time, the `id` field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millenia).
## Implementation
* [Tidbit](https://github.com/levelkdev/tidbit) tracks this EIP.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).