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

Draft spec: Operator incentives #44

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Conversation

alrevuelta
Copy link

Draft spec: Operator incentives

@juanpmcianci
Copy link

Thanks for sharing. Here are some comments (apologies beforehand if they are too trivial). I tried going section by section. Let me know if something is not clear.

Abstract:

  • "participate in waku" -> Capitalize Waku?
  • "It is assumed that users pay recurrently for their RLN membership". Do we have an idea of the cost of being an operator? Are there any restrictions on who can join as an operator? (need to strike a balance; paid>distributed>costs)
  • "thee generated fees are distributed evenly to the operators participating in each epoch." are all operators putting equal input? Are there any other metrics that we care about? (uptime, etc?)
    -"Only registered operators that put a bond at stake are eligible for such rewards. And only the nodes that vote on the correct Merkle root get the reward." Given the comment above, I'm assuming that bonds are equal, then?

Background

  • what is the any sybil measure we are taking here?

Specification

The honest operator

  • "In order to prevent other operators from taking over the network, an operator SHALL wait an entry queue to start being eligible." How does this mechanism work? what if there is no queue?
    The contract SHALL process OPERATORS_ENTER_EPOCH new operators per RLN_EPOCH_SIZE_SECONDS.
    -"In order for the network to kick-off, a minimum of MIN_GENESIS_OPERATOR_COUNT SHALL exist before the network can start. This prevents the network from kicking off with a small set of operators." I think you also need to enforce a maximum, as this depends on the number of users too. Here's a simple example to illustrate my point. Suppose that there's one user that pays $1 worth of tokens every epoch. Suppose there's only one operator with an opex of 0.6. This works; the user pays and this is enough for the operator to cover their expenses and make some extra. Now, suppose a second operator with same OpExs joins and that the number of users stays the same. now this $1 that the user is paying would need to cover $1.2 in opex, which is not economically viable for neither operator, which can lead to undesirable behaviors.
  • Are all operators challenged equally? Can (non-honest) operators spam challenge others?

The lazy operator

  • "* A gossipsub challenge: Nodes are challenged to prove they know the content of random message hashes.
    If the challenge is not responded successfully, the peer gets de-scored and eventually disconnected.". Shouldn't scores then factor into the distribution?
  • "When the node fails multiple challenges in a row it SHALL lower its score to a point where a disconnection is triggered." can these operators still game the system if this is not done in a row? Ex: can I be lazy on one epoch and non-lazy in another and still be good?
  • What is the incentive to be lazy?

Node penalties

  • "The remaining stake SHALL be returned." Any reason behind this? not returning it and either redistributing it or burning it sounds like a stronger incentive.
  • How long is each epoch? Maybe I missed it, but are there any mechanisms to "make things up" without getting slashed in case of a legitimate reason for missing the deadline, e.g., a power outage?

Root consensus

  • "Any operator that voted to CONSENSUS_ROOT SHALL be eligible for rewards, computed proportionally given the number of operators participating in consensus." other metrics (score, reputation, etc) might be worth considering as well -- some might be trickier to measure on on-chain though.

  • "If no consensus is reached during the first round, a new round SHALL start until a consensus of SUPERMAJORITY_PERCENT is reached." what happens in this case? does it create a backlog?

informational/operator-incentives.md Outdated Show resolved Hide resolved
informational/operator-incentives.md Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants