Conversation
Local benchmarksBefore changesTest 1STATISTICS Test 2STATISTICS After changesWithout Response Cache implementationSTATISTICS With Response Cache implementationSTATISTICS |
Deploying mvkt-atlasnet with
|
| Latest commit: |
5d6c1d5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://7719ae9f.mvkt-atlasnet.pages.dev |
| Branch Preview URL: | https://feature-backer-kpis.mvkt-atlasnet.pages.dev |
Deploying mvkt-mainnet with
|
| Latest commit: |
5d6c1d5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://1d854eb7.mvkt.pages.dev |
| Branch Preview URL: | https://feature-backer-kpis.mvkt.pages.dev |
Deploying mvkt-basenet with
|
| Latest commit: |
5d6c1d5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://883aad19.mvkt-basenet.pages.dev |
| Branch Preview URL: | https://feature-backer-kpis.mvkt-basenet.pages.dev |
|
Passed! - Failed: 0, Passed: 75, Skipped: 0, Total: 75, Duration: 2 s @TristanAllaire |
| }; | ||
| } | ||
|
|
||
| async Task<BakerStatsTotals> GetBakerStatsTotals(int bakerId, int? cycle, int cyclesLimit) |
There was a problem hiding this comment.
Regarding the SQL query, I also considered using a materialized view, something like a snapshot of cycle data for a particular validator. However, that introduces some overhead because the data must remain strictly consistent when a cycle changes. Also, we don’t only query all cycles; sometimes we query a specific cycle, and storing snapshots for everything would be too much data. I don’t think it’s necessary right now.
| SUM("BlockRewardsStakedShared" + "EndorsementRewardsStakedShared") AS "TotalRewardsStakedShared", | ||
| SUM("BlockRewardsStakedOwn" + "EndorsementRewardsStakedOwn") AS "TotalRewardsOwnStake", | ||
| SUM("BlockRewardsStakedEdge" + "EndorsementRewardsStakedEdge") AS "TotalEdgeFees" | ||
| """; |
There was a problem hiding this comment.
I also concluded that it’s faster to aggregate the data at the SQL level rather than pulling it into the method and calculating it with loops:
- We already filter efficiently in the query using WHERE "BakerId" = @bakerId ORDER BY "Cycle" DESC.
- This reduces load on both CPU and GC on the application side.
| public DalPublishCommitmentCommit(ProtocolHandler protocol) : base(protocol) { } | ||
|
|
||
| public async Task Apply(Block block, JsonElement op, JsonElement content) | ||
| public new async Task Apply(Block block, JsonElement op, JsonElement content) |
There was a problem hiding this comment.
Could you please detail both changes? Are they needed?
| { | ||
| public BlockCommit(ProtocolHandler protocol) : base(protocol) { } | ||
|
|
||
| public async Task ApplyRewards(JsonElement rawBlock) |
There was a problem hiding this comment.
Could you explain this change? Is it needed?
| } | ||
|
|
||
| async Task<List<MvktQuote>?> GetQuotes(DateTime from, DateTime to) | ||
| async Task<List<MvktQuote>> GetQuotes(DateTime from, DateTime to) |
There was a problem hiding this comment.
Could you explain this change? Is it needed?
| Logger = logger; | ||
| } | ||
|
|
||
| public async Task Init() |
There was a problem hiding this comment.
Could you explain the changes in this file? Are they needed?
|
|
This logic will be moved to the mvkt-bff service. @TristanAllaire |
2 participants
Extends
GET /v1/rewards/bakers/{address}/statswith optional cycle / cyclesLimit query parameters and a new kpis object in the response. Enables validator dashboards to show per-cycle and lifetime metrics (rewards, efficiency, shares) without extra round-trips.Response
?cycle=N).cyclesLimit).kpis fields: