Replies: 3 comments
-
I think it's a great idea! Though, I'd prefer to clarify whether the users need №3 (we need to think/ask somewhere about the usecases). |
Beta Was this translation helpful? Give feedback.
-
We may save epoch summaries at the last block of the epoch (see https://docs.near.org/docs/api/rpc/network#validation-status). This will allow us to track something like https://github.com/frol/near-validators-scoreboard/blob/scoreboard-mainnet/validators_scoreboard.csv I am not sure it is worth to store the exact block height of the non-produced blocks (I imagine someone would only care about the amount of missing blocks rather than a specific height) |
Beta Was this translation helpful? Give feedback.
-
Given that we always have 126060 blocks with the same epoch, I am concerned about storing this much of duplicate information in the database. Having a separate table with the epoch summary (epoch id, start block height, end block height, rewards, number of missed blocks, number of missed chunks, ???) seems to be a better option
I have the same concern as with the missed blocks, but less so since these blocks are actually produced and we might want to track bad actors (though we can do that with RPC calling individual blocks of the epoch that we find suspicious) |
Beta Was this translation helpful? Give feedback.
-
During the recent issues with 1.24.0-rc.1 release of
nearcore
chain team had to investigate what is going on. Afterward, they said:Here's the clarification about what kind of data may be useful. I think we should consider storing it:
@frol @telezhnaya what do you think?
Beta Was this translation helpful? Give feedback.
All reactions