Spark RSR: weight measurements using node reputation

[bajtos]

eta: 2025-02-06

Use the reputation introduced by #155 to give more weight to measurements from nodes with good reputations and less weight to nodes being too often in the minority.

This should make it more difficult for malicious parties to influence the fine-grained RSR score calculated from individual measurements.

Mitigate the following attack vector:

If I have 1% of the Spark Checkers and I always report that SPs fail, I can effectively bring everyone’s spark RSR down by 1 percentage point.

Related:

• Reputation score for Spark checker nodes and participants #155
• Deal Retrievability Score #156

[bajtos]

A related attack vector that we could mitigate using a similar mechanism:

Nodes can generate a new stationId on every request. This opens a potential attack vector where the node can generate many stationId values and then pick such stationId that allows them to pick the task they want to perform

I am proposing to include the stationId age in the weight too.

See also:

• Incentivise long-living Station IDs #122

[juliangruber]

I am proposing to include the stationId age in the weight too.

Attach vector: Generate many Station IDs, wait a month, now you have old ids to choose from

[bajtos]

I am proposing to include the stationId age in the weight too.

Attach vector: Generate many Station IDs, wait a month, now you have old ids to choose from

Great point!

There is a caveat, though: for each node (Station ID) and round, we choose the closest tasks using the following metric:

xor(
  sha256(StationID), 
  sha256(cid || miner_id || drand)
)

Where drand is unique for each round. Even if you know the entire set of (cid, miner_id) pairs, you still cannot predict the task hash in each round. I don't know how to calculate how many Station IDs you would have to pre-generate to give you a reasonable chance that one of those IDs will be close to a hash of your chosen task. You also need to submit at least one accepted measurement per Station ID to activate that ID. With 72 rounds per day and 15 tasks per round, you can activate only ~1k IDs every day per each IPv4/24 subnet. That does not seem enough to give you a reasonable probability that you will be enough to choose your tasks.

We can make it even more difficult for the attacker if we define Station ID age as the number of days when at least one measurement was accepted from that Station ID and reset the age back to zero for IDs with no accepted measurements in the last N days, where N can be around 30-90 (1-3 months).

With N=30, an attacker can keep at most 32,400 "alive" Station IDs per IPv4 /24 subnet.

[BigLep]

With 72 rounds per day and 15 tasks per round, you can activate only ~1k IDs every day per each IPv4/24 subnet. That does not seem enough to give you a reasonable probability that you will be enough to choose your tasks.

If I have ~1k "warm" station ids at my proposal, maxTasksPerNode is 24, and there are ~1600 retrieval tasks in a retrieval task list, then I think definitely at least one of those station ids will be able to submit a measurement for a given task.

(I got 1600 retrieval tasks in a round doing curl https://api.filspark.com/rounds/meridian/0x8460766edc62b525fc1fa4d628fc79229dc73031/17778 | jq . | grep "cid" | wc -l)

Anyways, I know this isn't the focus currently, but I think this conversation is just making clear for me that this is a tough problem.