Validator Score #21
Validator Score #21
Conversation
❌ Deploy Preview for nimiq-developer-center failed. Why did it fail? →
|
❌ Deploy Preview for developer-center failed. Why did it fail? →
|
learn/validator-trust-score.md
Outdated
| $$ | ||
|
|
||
| $$ | ||
| \text{window\_duration\_ms} = 9 \times 30 \times 24 \times 60 \times 60 \times 1000 |
There was a problem hiding this comment.
Myabe explain what each number refers to?
There was a problem hiding this comment.
I need other opinions?
People, please vote: Yay 👍 or Nay 👎 ?
learn/validator-trust-score.md
Outdated
| C_i = \sum_{j=0}^{N-1} c_j \quad \text{for } i = 0, 1, 2, \ldots, m-1 | ||
| $$ | ||
|
|
||
| $c_j$ is the number of blocks that the validator produced in the batch $j$, where $j \in [0, N-1]$. |
There was a problem hiding this comment.
We could emphasize that is not only blocks produced but correctly produced or rewarded for
There was a problem hiding this comment.
Let me knwo if you like
learn/validator-trust-score.md
Outdated
|
|
||
| If a validator is not active producing blocks, it could still have a high Size and Reliability score. This would be misleading because they are not contributing to the operation of the network. The Liveness factor ensures that only active validators that are actually selected to produce blocks receive a higher score. We want to penalize validators that are not selected to produce blocks due of being inactive, jailed, offline, etc. | ||
|
|
||
| We use the term _liveness_ instead of _uptime_ because _uptime_ suggests precision, as in server contexts where the exact online time can be measured. In our context, there is no way to measure how long a validator has been online. We can only know when the validators have been active and producing blocks, but there is no way of knowing when they are active but not producing blocks, or when they are offline. In summary, to avoid confusion, we use _liveness_ to represent how often a validator is actively selected to produce blocks. |
There was a problem hiding this comment.
| We use the term _liveness_ instead of _uptime_ because _uptime_ suggests precision, as in server contexts where the exact online time can be measured. In our context, there is no way to measure how long a validator has been online. We can only know when the validators have been active and producing blocks, but there is no way of knowing when they are active but not producing blocks, or when they are offline. In summary, to avoid confusion, we use _liveness_ to represent how often a validator is actively selected to produce blocks. | |
| We use the term _liveness_ instead of _uptime_ because _uptime_ suggests precision, as in server contexts where the exact online time can be measured. In our context, there is no way to measure how long a validator has been online. We can only know when the validators have been active and producing blocks, but there is no way of knowing if they are active and not producing blocks or offline. In summary, to avoid confusion, we use _liveness_ to represent how often a validator is actively selected to produce blocks. |
I want to make clear that a validator can be active and offline at the same time.
A validator can be offline and not produce blocks for being offline, or active but not producing blocks because it was not selected in a specific epoch
There was a problem hiding this comment.
What about this?
We use the term liveness instead of uptime because uptime implies precise measurement, as in server contexts where you can measure online time. In our case, we can't measure how long a validator has been online. We can only see when validators are active and producing blocks. There's no way of telling when they're active but not producing blocks, or when they're offline.
To be clear, a validator can be active and offline at the same time. It could be offline and not producing blocks because it's offline, or it could be active but not producing blocks because it hasn't been selected in a certain period. This is why we use liveness to show how often a validator is selected to produce blocks.
|
As a higher level comment after an initial quick read it seems to me that An option would be to move Liveliness from purely being selected as the criteria, to not being selected due to a different reason than randomness (being jailed, being deactivated, etc). That is also implied by the paragraph leading up to it. This too must be done carefully as Another would be to scratch |
Co-authored-by: Alberto Monterroso <[email protected]>
Co-authored-by: Alberto Monterroso <[email protected]>
Co-authored-by: Alberto Monterroso <[email protected]>
Co-authored-by: Alberto Monterroso <[email protected]>
Co-authored-by: Alberto Monterroso <[email protected]>
also removed "trust" and now is only "trust score"
|
Validator Trust Score has been renamed to Validator Score? |
After a few conversations with Soeren, I thought it might not be such a good idea to add the adjective "trust". For now this is not a final decision, I will bring this discussion in the following days after Alberto has checked and verified that the code and the latest commit in this PR are ok. |
Preview
TODOs
validataor-trust-scoretovalidator-scoreHow soon after a validator starts can we begin scoring them? What is the minimum time required to provide a reliable score?
After he completed one epoch. After this, the liveness score will be close to 0. and it will quickly improve as it is not linear. I will add more info about this specific case