neo-project / neo

NEO Smart Economy
MIT License
3.47k stars 1.03k forks source link

Design options and use cases for Oracles #967

Closed lock9 closed 4 years ago

lock9 commented 5 years ago

According to the accepted proposal https://github.com/neo-project/proposals/pull/78

List use cases Discuss what is the best way to implement it (best design) Discuss the scenarios we should cover Discuss security issues we should be concerned Implementation design

Edit: Implementation design proposals without images will be punished with a thumbsdown (👎 )

shargon commented 5 years ago

We will present our proposal soon, completely different to the proposal https://github.com/neo-project/proposals/pull/78

shargon commented 5 years ago

I think we should also discuss penalties in addition to incentives; it is important to have a way to keep nodes honest

Maybe the Oracle is honest but the server is cheating... Very hard to decide this... everytime you should think in random.org

doubiliu commented 5 years ago

@shargon yeah, it is very important.We collect some key trust problems of designing a distributed Oracle system. And we have design a incentives proposal.We need discuss carefully

igormcoelho commented 5 years ago

@shargon the text you made on proposals is still very good, perhaps this should be re-proposed on specification repo... as soon as we agree on basic oracle features.

shargon commented 5 years ago

The problem with this text is that was proposed for delegate all the work to the current CN and we thought now that we need other nodes, Oracle nodes. without touch the current consensus mechanism.

vncoelho commented 5 years ago

It was great discussions yesterday. Thanks to @shargon and @belane and @neo-project/ngd-shanghai for teaching the options.

Congratulations for the great job and all the design.

I agree with the comment of @igormcoelho here https://github.com/neo-project/neo/issues/967#issuecomment-516659103 (OPTION A), which is also the proposal @shargon and @belane are supporting, as well as a need of the guys from NEO-FS.

The incentives are still not clear but sure some good direction will soon appear.

As emphasized, the block finality is a good thing we have and should be used in our favor, providing a one-step on-chain solution with off-chain information sharing.

vncoelho commented 5 years ago

Following this line of reasoning,

I think that 2 consensus are not necessary for the Oracles to work properly.

Perhaps, the following flow could be considered:

pappas999 commented 5 years ago

What you guys are proposing sounds great, but it is extremely similar to what Chainlink have been developing for the past 2 years: Decentralized Oracle network, consisting of on and off chain parts, staking, penalties, threshold signatures, consensus/aggregation on results etc. If this is the case, wouldn't it make more sense to just integrate to that, and develop some form of atomic swap (GAS for LINK) for NEO Smart Contracts to be able to use and directly pay for data requests with GAS? Only suggesting this because their team has been in development on all this stuff for 2 years, so it requires great effort to achieve.

Having said that, if you do want to replicate that sort of functionality and have it baked into the NEO protocol that's also great, it may pay to have a read of the chainlink white paper for some ideas (or check out their github)

I have a question though. From the description of option A), it sounds like any Oracle Node can take a request from the Oracle pool and request data from the API and generate the response back? Or will it be like Chainlink where specific Oracle nodes are setup to obtain data from specific APIs? eg Alice has a node that obtains weather data from weather.com, Bob has an Oracle Node that gets data from accuweather.com. If this is a more 'general' Oracle implementation where any Oracle can obtain the results from the APIs due to them all being public and open etc, then how do we determine which Oracle Node in the available pool gets to make the request (and get the reward)?

eryeer commented 5 years ago

@pappas999 Our design is the former one, every Oracle node will request the same public API. The API url is specified by transaction. Any oracle node that requests the API and get the consistent result approved by consensus should be considered to contribute to the result of the request, and they should be rewarded equally.

pappas999 commented 5 years ago

@pappas999 Our design is the former one, every Oracle node will request the same public API. The API url is specified by transaction. Any oracle node that requests the API and get the consistent result approved by consensus should be considered to contribute to the result of the request, and they should be rewarded equally.

Thanks, that makes sense now. So the use case for the NEO Oracle network will be publicly accessible static or dynamic web services and URLs that return JSON data etc which can then be parsed and aggregated into a result that will be hashed and stored in the block.

I have some thoughts to add for incentives/penalties and considerations:

Incentives: The obvious way to incentivize Oracle nodes is for them to be paid in GAS for fulfilling requests. There are multiple payment structures/schemes possible: 1 - static fee per request, eg 1 GAS per request, split among all Oracle nodes that contribute to the response 2 - Let each Oracle node define their required fee, then ensure data requestor/Smart Contract has enough GAS for the request for x Oracle nodes to be able to fulfill their request. Perhaps x can be requested by the Smart Contract, giving them a choice in how much decentralization/aggregation they want. ie for something small and cheap, x can be 1 and only 1 Oracle node is used, or for higher value contracts that require better security and decentralization, x can be 20 so 20 nodes used to validate data. 3 - Have the fee calculated based on multiple things, a) how many oracle nodes are used (as per point 2 above), as well as b) size of the response/data obtained. 4 - Other?

Also, seeing as the URLs being accessed are public, there should be good incentive for NEO holders to be Oracle nodes if they wish. This plays in well to the token economics of the NEO ecosystem, and would allow them to collect more GAS from Oracle transaction fees. The only potential downside to this, is you don't want NEO holders with poor servers/internet connections being critical Oracle nodes in the network. Chainlink is implementing a 'marketplace' to combat this, where nodes will have reputations, and to be verified as a high quality data provider, you need to show solid uptime and response times for a certain length of time. Perhaps Consensus Nodes or NEO holders can vote in/out Oracle nodes somehow based on their performance.

Penalties: This would require a certain amount of NEO tokens to be used/staked by Oracle nodes as collateral to ensure they give back correct responses. If all Oracle nodes are to be treated equally, then perhaps a static amount of NEO can be specified as needing to be staked? Then governance needs to be defined as to what constitutes 'bad behavior', and what the process is of how an Oracle node gets its stake taken away.

data points/URLs: Need to be careful how many Oracle nodes will be accessing these URLs at a given time. Eg Will the URL be able to handle getting 100 GET requests within a couple seconds? I'm not an expert on web servers and requests/scaling so this point may be not applicable.

doubiliu commented 5 years ago

@pappas999 I like point2 in Incentives.So I want to add concept of group. Group Any node that enables Oracle functionality can become a potential Oracle service provider in Neo network. These nodes can be aggregated into one group according to certain rules and wishes, and the group provides Oracle services to users. The most authoritative group is a general-purpose group voted by the Neo consensus node, which can provide a more reliable Oracle service. User can decide which group to use. It is recommended to use generic groups, but in some special cases, such as special authorization, restricted access, etc., other groups can be used, but they are closer to centralization.

doubiliu commented 5 years ago

And Penalties is very difficult.Since there is not any evidence can be trusted to judge a node's behavior

joshuaellul commented 3 years ago

Would you be interested to see how this approach can help? https://joshua-ellul.medium.com/contrary-to-widespread-misconception-blockchain-dlts-and-smart-contracts-can-make-calls-to-94d864415ca7

Only 1 node needs to make an oracle call. The rest can verify it, if the oracle has signed it's response. In our work above we show that external calls from Blockchain systems are possible, contrary to widespread misconception.