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

Fraud detection: limit number of measurements per round #78

Closed
1 task done
Tracked by #22 ...
bajtos opened this issue Nov 29, 2023 · 3 comments · Fixed by #104
Closed
1 task done
Tracked by #22 ...

Fraud detection: limit number of measurements per round #78

bajtos opened this issue Nov 29, 2023 · 3 comments · Fixed by #104

Comments

@bajtos
Copy link
Member

bajtos commented Nov 29, 2023

Detect when a checker node is submitting too many measurements.

In https://www.notion.so/pl-strflt/SPARK-tasking-v2-604e26d57f6b4892946525bcb3a77104, we are describing the following parameters:

  • CC - “committee count” - how many committees we want to form. Initially, this will be a hardcoded parameter. We will manually tweak it over time based on the number of active checker nodes.
  • TC - “tasks per committee” - how many tasks to define for each committee.
  • TN - “tasks per node” - how many tasks a node performs. This value should be a fraction of TC, e.g. TN = TC/5

At the moment, CC=1 and TC=400.

Assuming retrievals are fast and can be completed in ~1 second, and the spark checker waits for 10 seconds between tasks, and the SPARK round is ~60 minutes, then an honest node can complete around 327 tasks per round.

Proposed changes:

  • Add a new fraud detection step to reward only the measurements for the first 300 unique tasks. Because measurements are not associated with Station instances, we should use (participant_address, inet_group) as the identifier.
@bajtos
Copy link
Member Author

bajtos commented Dec 13, 2023

@juliangruber I think you already implemented this, right?

It would also be great to add telemetry & visualisation - p5/p50/p95 values for the "number of measurements submitted by a node" so that we know how often we slash nodes.

Should we keep this issue open to remind us of this remaining task?

@bajtos
Copy link
Member Author

bajtos commented Dec 13, 2023

See #101

@juliangruber
Copy link
Member

@juliangruber I think you already implemented this, right?

Yes, in #101.

It would also be great to add telemetry & visualisation - p5/p50/p95 values for the "number of measurements submitted by a node" so that we know how often we slash nodes.

Good idea!

#104

Should we keep this issue open to remind us of this remaining task?

Merging that PR will close this issue :)

@github-project-automation github-project-automation bot moved this from 🗃 backlog to ✅ done in Space Meridian Dec 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ done
Development

Successfully merging a pull request may close this issue.

2 participants