Skip to content

audit: add LEP-6 shadow scoring for storage truth#119

Open
j-rafique wants to merge 1 commit intoLEP-6-report-ingestionfrom
LEP-6-shadow-scoring
Open

audit: add LEP-6 shadow scoring for storage truth#119
j-rafique wants to merge 1 commit intoLEP-6-report-ingestionfrom
LEP-6-shadow-scoring

Conversation

@j-rafique
Copy link
Copy Markdown
Contributor

No description provided.

@roomote-v0
Copy link
Copy Markdown

roomote-v0 bot commented Apr 20, 2026

Rooviewer Clock   See task

The shadow scoring implementation is well-structured with thorough test coverage across result classes, decay, escalation, contradictions, and trust band scaling. Two minor items flagged:

  • storage_truth_scoring.go: Redundant GetParams store reads inside applyReporterReliabilityDelta and applyTicketDeteriorationDelta -- params are already fetched in the caller and should be threaded through
  • storage_truth_scoring.go: scaleInt64TowardZero can silently overflow on value * numerator for extreme score values, inconsistent with the saturated arithmetic used elsewhere in the scoring pipeline

Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.

ReporterSupernodeAccount: reporterAccount,
ReliabilityScore: next,
LastUpdatedEpoch: epochID,
TrustBand: reporterTrustBandForScore(next, k.GetParams(ctx).WithDefaults()),
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

k.GetParams(ctx).WithDefaults() is called here and again at line 247 inside applyTicketDeteriorationDelta, even though the params are already fetched at the top of applyStorageTruthScores (line 41) and passed into storageTruthBookkeepingForResult. These inner functions re-read from the store on every invocation. With N results per report, that is 2N redundant store reads per SubmitEpochReport. Consider threading the already-fetched params into these two methods as a parameter.

Fix it with Roo Code or mention @roomote and request a fix.

Comment on lines +411 to +414
if value > 0 {
return (value * numerator) / denominator
}
return -(((-value) * numerator) / denominator)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

value * numerator can silently overflow when value is large. Since scores use saturated arithmetic and can theoretically reach math.MaxInt64, calling scaleInt64TowardZero(math.MaxInt64, 50, 100) would overflow the multiplication, wrapping to a negative value and producing an incorrect result. In practice this requires extreme score accumulation, but the rest of the scoring pipeline is careful about saturation. A safe pattern would be to divide first: value / denominator * numerator + (value % denominator * numerator) / denominator, or check for overflow before multiplying.

Fix it with Roo Code or mention @roomote and request a fix.

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.

1 participant