Expose per-round measurement count

[juliangruber]

Required for CheckerNetwork/spark-api#385

In addition to measurements/daily, add measurements/round/:n or measurments/per-round/:n.

[bajtos]

We are storing daily values to keep the database size reasonable and the aggregate queries fast.

I propose to introduce a new table for these per-round measurement counters.

Questions to consider:

• Do we need/want to keep historical per-round measurement values for api: Add fixed # tasks per round. Closes space-meridian/roadmap#82 spark-api#385? If not, then we can keep only the data for the last X rounds, e.g. 72 rounds (one day).
• Which measurements do you want to count - accepted measurements only, measurements in majority, or all measurements?

You will need to start in spark-evaluate - create a DB schema migration script to add the new table and modify lib/public-stats.js to populate it.

[juliangruber]

Do we need/want to keep historical per-round measurement values for CheckerNetwork/spark-api#385? If not, then we can keep only the data for the last X rounds, e.g. 72 rounds (one day).

Great point! In the current algorithm, we only ever need the previous round. From that perspective, if we can make the API only expose stats for the previous round, then we can make the consumer even simpler: It doesn't need to know the index of the previous round.

To me this is a win on storage and ease of use 👍

Which measurements do you want to count - accepted measurements only, measurements in majority, or all measurements?

I was wondering about this as well! Honest nodes will be more likely to respect the task count set out by spark-api -> majority measurements > accepted measurements > all measurements. I think majority measurements is the best one. Wdyt?

[bajtos]

On the second thought, I am not very happy about tracking measurements-per-round in spark-stats. It requires keeping three repos in sync (spark-api, spark-stats, spark-evaluate).

Have you considered the following alternative?

• In spark-publish, when we are publishing a batch of measurements, we know how many were added to the batch.

• When we call Meridian's addMeasurements method, it gives us back the round index to which these measurements were added (committed to).

  https://github.com/Meridian-IE/impact-evaluator/blob/14f630fb871f9b2e90bbcc8ad8b3e34c98d6ab2f/src/ImpactEvaluator.sol#L109-L116

• At that point, we have all the data we need for tracking measurements-per-round (roundIndex, measurementCountDelta).

So instead of going through spark-publish->spark-evaluate->spark-stats->spark-api, we can keep everything inside spark-api repository & database. We don't even need to expose this in a public API.

Of course, this works only if we want to use "total measurements".

From that perspective, if we can make the API only expose stats for the previous round, then we can make the consumer even simpler: It doesn't need to know the index of the previous round.

I think this is going to be problematic - it takes a while until the measurements go through the smart contract and spark-evaluate. Depending on when exactly your task-limit algorithm executes, it will see data from rounds N-1 or N-2. I am concerned this will make troubleshooting difficult. It will also complicate caching.

Which measurements do you want to count - accepted measurements only, measurements in majority, or all measurements?

I was wondering about this as well! Honest nodes will be more likely to respect the task count set out by spark-api -> majority measurements > accepted measurements > all measurements. I think majority measurements is the best one. Wdyt?

IMO, this depends on what we are trying to achieve.

My understanding is that we want to limit the load created by the Station network. In that light, we must limit the total number of measurements performed.

[juliangruber]

My understanding is that we want to limit the load created by the Station network. In that light, we must limit the total number of measurements performed.
So instead of going through spark-publish->spark-evaluate->spark-stats->spark-api, we can keep everything inside spark-api repository & database. We don't even need to expose this in a public API.

Of course, this works only if we want to use "total measurements".

Right! Ok, total measurements it is.

Cool, I'll add this inside spark-api internally :)