History Random Strategy is broken? off by 12% of estimated value

[KolbyML]

Carver shared a picture of the random audit graph #411 (comment)

As I said in the image above, 90% doesn't make any sense for Random audit currently. I would expect it to be ((17034870 (capella fork) + 500k (an optimistic guess of how much the bridges might have gossiped already)/ 22491839 (latest)) * 100 == 77.96%

So this graph should be around 77.96% or less. So the graph is off by 11% which is pretty massive.

[KolbyML]

If I remember correctly last time I heard, random audit did a random audit of known content keys added by glados monitor of latest content items, instead of a truely random audit of 0 to latest.

I think we should update random from 0 to HEAD - 8192

[Ktl-XV]

Regarding the unexpectedly high 90%

• Random only applies to History, so an "empty" Beacon network should not impact the metrics (even with bug Random strategy should be history-specific #418)
• Like @KolbyML mentioned, "Random" Audit is not truly random, this could explain why the metric is higher than expected

I think we should update random from 0 to HEAD - 8192
Agree with this. One approach could be to have Monitor fetch all the contents since genesis (possibly loading them from a snapshot instead of having each Glados request the entire chain via RPC). A different approach can be adding an RPC to Audit and getting a random block for each audit. Both approaches have the downside of adding all historical contents to the DB, which would likely mean needing a bigger host for the DB.

I think the first approach is best, especially if the historical contents are bulk loaded (but that might make Glados' first start take very long to seed the DB)

[KolbyML]

Regarding the unexpectedly high 90%

• Random only applies to History, so an "empty" Beacon network should not impact the metrics (even with bug Random strategy should be history-specific #418)
• Like @KolbyML mentioned, "Random" Audit is not truly random, this could explain why the metric is higher than expected

I think we should update random from 0 to HEAD - 8192
Agree with this. One approach could be to have Monitor fetch all the contents since genesis (possibly loading them from a snapshot instead of having each Glados request the entire chain via RPC). A different approach can be adding an RPC to Audit and getting a random block for each audit. Both approaches have the downside of adding all historical contents to the DB, which would likely mean needing a bigger host for the DB.

I think the first approach is best, especially if the historical contents are bulk loaded (but that might make Glados' first start take very long to seed the DB)

I think you need to use both strategies, as you can never have an up to data snapshot

[Ktl-XV]

Yes, a bulk approach for "old" history and monitor could take it from there.

Another bug that very slightly increases the fail rate is #430 glados-monitor for history does not handle reorgs.

Is having to store all historical content in Glados's DB an issue?

[KolbyML]

Is having to store all historical content in Glados's DB an issue?

The header chain is very small, I think the main storage problems is census's and audits