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

[Oracles] Oracle Nodes Election #1278

Closed
belane opened this issue Nov 25, 2019 · 20 comments
Closed

[Oracles] Oracle Nodes Election #1278

belane opened this issue Nov 25, 2019 · 20 comments
Labels
discussion Initial issue state - proposed but not yet accepted oracles Oracle related issues

Comments

@belane
Copy link
Member

belane commented Nov 25, 2019

The Oracle node election is strongly bound to the consensus system. The general idea is to use the same voting process as for the election of consensus nodes and use the same governance mechanisms.

This topic is closely linked to oracle policy #1277

@belane belane added the discussion Initial issue state - proposed but not yet accepted label Nov 25, 2019
@belane belane added this to the NEO 3.0 milestone Nov 25, 2019
@vncoelho
Copy link
Member

vncoelho commented Nov 25, 2019

I am not sure if link it, compulsorily, to the voting system is a good idea.
Perhaps, the default oracles could just be elected by the consensus nodes themselves.
Let's thing more about it, because we are also discussing governance, @vang1ong7ang @igormcoelho, and the need of voters to stake both after vote and for GAS claims.


Edited:
After talking to other people, in particular, Igor and Vang1Ong7ang, I think that perhaps just a free market and the protocol is enough. No need for any election.

@doubiliu
Copy link
Contributor

I support the idea"the Oracle node election is strongly bound to the consensus system".One simple and direct implement is "One Consensus Node ,One Oracle Node".Each CN should operate a Oracle node.The reliability of the system is 2/3.
If we use a voting model to choose OracleNode,we must set some indicators to indicate that these nodes are eligible to become Oracle nodes.I think maybe it is difficult.
The reliability of the system maybe is 4/9 ?

@realloc
Copy link

realloc commented Nov 26, 2019

Oracle nodes must not be bound to CNs in terms of colocation or resource sharing or key for security and safety reasons.

It's possible to let CNs to decide which Oracle candidate nodes can be considered a proper nodes for particular oracle type, for example by listing Oracle nodes' Public Keys in some Oracle Policy Native Contract storage after doing some checks or observing candidates' behaviour.

BTW, please note that there must be lots of Oracle nodes for the whole system to work correctly and reliably, more then 7.

@vncoelho
Copy link
Member

vncoelho commented Nov 26, 2019

Talking to @vang1ong7ang we noticed that, perhaps, we do not need any default oracle, just the protocol. No need for any election.
Official oracles should be registered on NEO native contract. @erikzhang @igormcoelho

@doubiliu
Copy link
Contributor

@vncoelho Hi,vncoelho.We also discussed the concept of groups before.But is it too complex for in-build Oracle?Need discussion.

@doubiliu
Copy link
Contributor

Maybe I can upload the content of Oracle Group and we can make a discussion here?

@shargon
Copy link
Member

shargon commented Nov 26, 2019

@doubiliu open a new thread please

@belane
Copy link
Member Author

belane commented Nov 26, 2019

I would prefer that Oracle and consensus roles don't fall on the same node.
I mean they are different roles, one node can have both roles but not mandatory.

I would use the same method that is decided to decide the consensus nodes (vote), the same method but not the same vote.

I would use the same method that we decide to elect consensus nodes (voting), the same method but not the same vote.

@vang1ong7ang
Copy link
Contributor

vang1ong7ang commented Nov 26, 2019

Talking to @vang1ong7ang we noticed that, perhaps, we do not need any default oracle, just the protocol. No need for any election.
Official oracles should be registered on NEO native contract. @erikzhang @igormcoelho

Some comments here.

If we separate oracle nodes from consensus nodes and we use a election to choose oracle nodes:

  1. The elected oracle nodes is a group decision but not match everyone's preference. If I am one of the 49% voters, why I want to use such a default oracle?
  2. Voters may need to waste time on the election of oracle nodes and it is much more difficult to know whether an oracle node is a Byzantine node. (because it is hard to get the evidence to prove a oracle node is cheating.)

If we use consensus nodes as the oracle nodes:

  1. Oracle nodes may be easily cheated by data sources (websites) by view attack.
  2. It is much more difficult to know whether an oracle node is a Byzantine node.
  3. If oracle nodes (consensus nodes) submit wrong data, it is not good for the reputation of consensus nodes of neo.

@erikzhang
Copy link
Member

Too many elections. For consensus nodes, for oracle nodes, for NeoFS inner ring nodes. I don't think we need that many elections. I also don't think users will participate in so many elections. I think the best way is to have consensus nodes play both of these roles. Or each consensus node can specify one or two oracle nodes.

@doubiliu
Copy link
Contributor

@erikzhang So "One Consensus Node ,One Oracle Node" ?
When one node register to be consensus candidate node ,it should specify its oracle node address?

@realloc
Copy link

realloc commented Nov 27, 2019

Having many independent Oracle nodes run by third party owners makes the whole network more robust, credible and faster. If ability to run Oracle node, and benefit from it, would be bound somehow to Neo token, it will also add value to Neo token existence itself. Right now there are not many good answer why the one would need NEO tokens, but Oracle nodes setup may add one. Hence, complexity of voting or passing qualification would pay off.

The Oracle election or qualification process can be simplified by delegating it to SmartContracts or some automation regulations, not just human voting process.

Technically it's not good to bind a small number of Oracle nodes to even smaller number of CNs. Besides credibility reasons, Oracle nodes may require to be in different parts of Internet to even serve simple http, and even for this simple task it's almost impossible to cover the majority of cases. Moreover, dApp owner could want to setup own groups of Oracle nodes with access to some restricted area to use exclusively by his SCs.

In short, I propose to consider having a decentralized Oracles run by independent owners, rather then concrete small set bound to CNs. Voting or qualification complexity would pay off.

@belane
Copy link
Member Author

belane commented Nov 29, 2019

@vncoelho, keeping the conversation about "official oracles". What do you think of this idea?

We can have two different Oracle Roles.

  • The first role, Oracle Validators. Each consensus node chooses an Oracle Validator node, responsible for carrying out the consensus between all OracleAgrement messages for each Oracle transaction (it can be by dBFT or by agreement).

  • The second role is the Oracles itself, they are open and any user can run one. Each time they receive an oracle transaction in their pool, they will make the necessary requests and build the OracleAgrement message that the Oracle Validators will then use to validate the transactions.

@doubiliu
Copy link
Contributor

doubiliu commented Dec 3, 2019

Well, to make a summary. Currently, we have 5 options:

Option A

Oracle node election is strongly bound to consensus node. Each consensus node should operation a Oracle node.

  • Advantage:
    • Easy to implement.
    • Strong credit guarantee.
  • Disadvantage:
    • Too much duty on consensus node.

Option B

Oracle node is elected by consensus nodes. Consensus node elect Oracle nodes based on certain criteria.

  • Advantage:
    • Reduce node responsibility.
  • Disadvantage:
    • Difficult to set election standards.
    • Matthew Effect,The weight of the elected node is too large.

Option C

Oracle 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 open Oracle services to users.

  • Advantage:
    • The user chooses the Oracle node autonomously, but is responsible for this behavior.
  • Disadvantage:
    • Rule design is flexible and requires rigorous access and management rules.

Option D

Similar to option B but introducing two different Oracle roles.

  1. Oracle Validators. Each consensus node chooses an Oracle Validator node, responsible for carrying out the consensus between all OracleAgrement messages for each Oracle transaction (it can be by dBFT or by agreement).
  2. Oracles, they are open and any user can run one. Each time they receive an oracle transaction in their pool, they will make the necessary requests and build the OracleAgrement message that the Oracle Validators will then use to validate the transactions.
  • Advantage:
    • Simplify node election.
    • Open oracles, anyone can run an oracle.
    • Election guaranteed by Consensus.
  • Disadvantage:
    • Centralizes more responsibility in consensus nodes.
    • It makes the rewards more difficult by having to reward the two different roles.

Option E

Use the same election model as for consensus nodes.

Option A: 👍
Option B: 👎
Option E: 🎉

@doubiliu
Copy link
Contributor

doubiliu commented Dec 3, 2019

@belane ,can you do some explanation about your comment?

@doubiliu
Copy link
Contributor

doubiliu commented Dec 3, 2019

After belane's explanation, we can do a vote

@belane
Copy link
Member Author

belane commented Dec 9, 2019

@doubiliu well it was more an open idea, but I think you've described it very well. I updated your comment with the missing details.

I think that we should also add the option of using the same election model that we will decide for the consensus nodes.

@belane
Copy link
Member Author

belane commented Jan 3, 2020

It seems we have a winner, Option A, which in fact is very similar to B.

Option A
Each consensus node is responsible for operating an Oracle node (or several) and also responsible for saving or deleting it from the oracle policy contract.

Note: For security reasons, should we prevent both roles from running simultaneously on the same machine?

@realloc
Copy link

realloc commented Jan 4, 2020

@belane But how did Option A become a winner if Option B has more votes?

@belane
Copy link
Member Author

belane commented Jan 4, 2020

Sorry @realloc for not explaining. Option A has a few more votes from core developers which have a little more weight.

I usually apply the following rules, but I am open to new ideas.

  • Core developer, one vote.
  • Communities involved in development, one vote per community.
  • Rest of the community, one vote per ~100 users calculated based on the average opinion.

@shargon shargon mentioned this issue Apr 18, 2020
@erikzhang erikzhang removed this from the NEO 3.0 milestone Sep 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Initial issue state - proposed but not yet accepted oracles Oracle related issues
Projects
None yet
Development

No branches or pull requests

7 participants