[node] Support oracle-based resolutions

[rhlsthrm]

We will need to support off-chain payments that can be unlocked based on the result of an HTTP call. On-chain resolution of the updates will have to be through an oracle. From my previous work with Oraclize, they charge you for on-chain calls, so we will need to avoid that when resolving off-chain and directly make the HTTP call.

CC @kthomas.

[rhlsthrm]

Some additional thoughts:

A bond (percentage of initial App stake) can be used to disincentivized participants from calling the oracle before the result has been determined (in case of oracle costs). The bond can be slashed and added to the other participant's balance.

[cf19drofxots]

@snario @IIIIllllIIIIllllIIIIllllIIIIllllIIIIll @emansipater any thoughts on this?

[rhlsthrm]

For an easier POC, I think we should demonstrate the following functionality:

• Send a payment that is unlockable by an API call to a public API (i.e. no fees).
• Allow payment to be unlocked off chain by confirming API call result.
• In the dispute case, the payment can be unlocked on chain by confirming API call through an oracle service.

I think the above solution without accounting for bonds and fees would be a good starting point, since there is probably a good amount of work to just get the oracle implemented and figure out the off chain resolution.

[cf19drofxots]

Allow payment to be unlocked off chain by confirming API call result.

By this you mean effectively updating the state conditional on the API call then calling resolve on that state?

[rhlsthrm]

By this you mean effectively updating the state conditional on the API call then calling resolve on that state?

Right, once the API call is approved as per business logic in the contract (let's say for simplicity, the API can return true or false, with true meaning the payment is unlocked), there should be able to be a "valid" state generated that can be signed by both parties. I know there are edge cases where the API call result can change if it's called again, but let's assume that won't happen for now.

[snario]

It would be useful to map this design to the following questions:

1. What is the on-chain scenario for determining the resolution? What does function resolve(...) view look like specifically?

2. What is the signing decision code going to look like in the Node? What function do I call to determine whether or not to sign proposed state from a counterparty?

3. Is there a function that needs to run before I sign my own proposed state?

4. Can this use a state transition function or will it be a unanimous consent app?

I want to divide this issue into the Solidity code, the Node plugin code, and any other unknown issues separately.

[rhlsthrm]

What is the on-chain scenario for determining the resolution? What does function resolve(...) view look like specifically?

I believe the resolve function should look very similar to the current PaymentApp function: https://github.com/ConnextProject/monorepo/blob/master/packages/apps/contracts/EthPaymentApp.sol#L22.

What is the signing decision code going to look like in the Node? What function do I call to determine whether or not to sign proposed state from a counterparty?

This is where the node can call the supplied API endpoint, which I believe would have to be in the AppState so that it can be pre-agreed upon. Also, the desired result or logic of the result should be agreed upon in the AppState.

Is there a function that needs to run before I sign my own proposed state?

Same as above, run the API call to verify that the result is as agreed upon to unlock the payment/payments.

Can this use a state transition function or will it be a unanimous consent app?

This can use state transition if it is unidirectional, until the CRDT functionality exists.

[snario]

Makes sense.

We're going to try to support this but will be blocked on @cf19drofxots's spike work on #1436.

[snario]

It might also make sense to split this task into two new issues.

(1) Add an Oracle-style example CounterfactualApp to the apps folder (2) Add an Oracle-style example plugin package for the Node (after #1436 is done)

Thoughts @cf19drofxots? We can do (1) now. Arguably ETHBalanceRefundApp is already that but the "oracle" is the address(...).balance call.