Oracles blockchain for NEO 3.0

[shargon]

The objective of this proposal is to be the first chain capable of not needing oracles to interact with non-deterministic content. Our mission is to make NEO capable of performing REST API calls and other types of non-deterministic functionalities that can be extended in the future.

[igormcoelho]

Well done @shargon! This would bring amazing oportunities for external executions and interaction with real world. Protecting IP could be done through vpn, I guess that wont be an issue. Congratulations!

[belane]

We believe that it is a great functionality and it will provide Neo with great value by incorporating the Oracles into the blockchain.

Currently Shargon and I have an open discussion of where it would be better to include the information from the Oracles.

• Include the data in the header of the block, which would reduce the size of the block and consume less external requests.
• Include the data into the TX itself which would allow all nodes to verify the transaction when receive it and before relay it, decreasing the processing in the consensus nodes.

[vncoelho]

Congratulations for the proposal, Belane and Shargon.

I need to understand it more deeply but looks like something interesting for several applications.

[vncoelho]

Hey, SharLane, why you mention REST API calls? Would it be the same as an RPC call?

[vncoelho]

Now I got it, metadata will storage results of that specific executions.

Did you think about a zero knowledge proof to be sure that that non-determinism, at least, followed the correct pattern? Toff question...aehauheauheaea

[vncoelho]

I did not get the Return Result.
Will it call the execution again? What is the different between the Save?

[vncoelho]

As I understood until, I think I prefer in the TX, but I need to understand it further.

[vncoelho]

More organization, please.. Where is the indentation in this figure? jajajajajaja

[vncoelho]

I did not get this last point of duplicated information.

[trueinsider]

I imagine that with storing each URL content on-chain ledger size could become quite big quite fast. Is there a possibility in using this somehow with NeoFS, so that metadata would be stored there instead of directly in block?

[erikzhang]

In order to ensure the consistency of contract execution, you cannot rely on NeoFS.

[trueinsider]

@erikzhang I see, I didn't know about consistency guarantees that NeoFS provides (or don't). That makes sense then, thanks

On another note, I can think of several different approaches to Oracles:

1. Querying arbitrary deterministic data. Even though the current proposal mentions non-deterministic data it's still, in a sense, deterministic. Because URL content should be the same each time it's queried by consensus nodes during verification, otherwise it'll fail. This, however, doesn't allow us to query data that will be different on each call (e.g. random numbers).
2. Querying specially-formatted non-deterministic data. When using Oracles you explicitly trust the resource you're getting data from, only thing that we can ensure is that that data definitely came from that resource and wasn't modified by Oracle or someone else. For that purpose we can enforce the data format, which contains data itself and signature that allows us to verify that that date came from the expected resource and wasn't modified. This approach won't allow us to query arbitrary APIs, but still will allow us to query data from off-chain after some preparation. Example of such API is random.org Signed API https://api.random.org/json-rpc/2/signed using which you can guarantee that number was generated by no one else than random.org itself.
3. Querying arbitrary non-deterministic data. This is a slight modification of previous approach. We allow SCs to query arbitrarily-formatted data while verifying it's correctness is SC dev responsibility. If there is a signature present like in above-mentioned API then SC dev should extract and verify it. Though this will require interop/opcode for signature verification in SCs. If there is no signature then authenticity of data can't be verified but this still can be used for some non-mission-critical data.

Last two approaches also allows for another implementation strategy, which doesn't bring any overhead to block structure or transaction verification.
We can't use consensus because data is non-deterministic, but since it's signed there is no need for consensus anyway (we can verify that it came from expected source w/o consensus).
This could be implemented like this:

1. Original SC submit data request (and pay GAS for it) to Oracle SC
2. One of the oracle nodes sees request, fetches data and submit it on-chain. First one to submit would receive GAS sent along with request to this data.
3. Original SC can then query this data from on-chain and continue execution (this should be separate tx from the one in 1).

That way we don't need to change the block structure, Oracles nodes is decoupled from Consensus nodes and there is incentive for people to run Oracle nodes, guaranteeing that there always will be someone to put requested data on-chain as he is incentivized to do so.
It's possible (if we want) to implement some kind of Oracle node registration mechanism so that only trusted people will be able to run one.
It's also possible to implement another rewarding rule instead of "first one wins" to ensure more fair reward distribution process (e.g. round-robin).

Another advantage of this approach is that it could be safely backported to Neo 2.0, we only need to make sure that Oracle SC hash won't change in Neo 3.0. And we could use CGAS to pay to Oracle (which should have same contract hash as GAS native contract in Neo 3.0 for backwards compatibility reasons)

[erikzhang]

This should be implemented in NEO 3.0.