Hello, fellow crypto enthusiasts!
Have you ever wondered how some of the more abstract network metrics in blockchain dashboards come about?
No? We honestly do! Yes, that sounds nerdy, but our curiosity and attention to detail are the reasons we enjoy being a blockchain infrastructure service provider so much.
Celo’s validator uptime score
Let’s have a look at the score on celostats for example. The parameter that indicates how reliably a validator signs new blocks on the Celo network, therefore usually referred to as the validator’s uptime score. When we launched our new setup on the baklava testnet, we asked ourselves how our score would develop over time.
Image: Celo Stats. Click to enlarge.
Checking the always helpful Celo Discord it seemed other node operators – 1, 2, 3 – have had similar questions. And the answers either were a link to a rather complex Celo docs article about validator rewards on mainnet, a sequence in the celo-monorepo on GitHub or a self-written script. However, since not every node operator is an analyst with experience in exponential moving averages and knowledge about the current state of the governable constants or a developer familiar with Solidity code, we looked for a more hands-on approach. Fortunately, even with only a few data points, we believe to have found a mathematical relation that provides fairly accurate insight into the expected increases in score. At least for the current conditions and the initial build-up phase of a validator setup that is almost 100% reliable.
Non-linear relation and assumptions made
Looking at our uptime scores after the completion of the first few epochs, it quickly became apparent that there was no linear relation. Although the infrastructure availability remained virtually unchanged over time, we gained less with each subsequent day.
Table: Completed epochs, raw uptime score, and raw uptime gain
The engineers among us from the old, mechanical world, surely know that fresh gears first have to break in, and therefore there is a little more friction loss at the beginning of a new operation. And all of us techies learn early on that mathematical relations and scientific laws often show slight deviations in practical application or require some form of empiric adjustments to make them work. Therefore, please forgive us for assuming that, ideally, a maximum of 10% can be achieved in the first epoch, and for simplifying the gains of the second and third to 9% and 8.1%, respectively, and those of the following days to 7.29% and 6.561%. These values then also became the basis for our mathematical derivation, which proved workable for our setup as we proceeded.
How? You will ask. And sadly, we cannot provide you with a universal answer. When it became clear that the underlying relation was non-linear, we simply tried to find an approximation that was not overly complicated, and fortunately, it seems, we did. Since 10*0.9=9 was obvious, we checked whether the quotient of a 90% increase in score compared to the previous epoch remained constant for the subsequent ones, and it indeed was: 10*0.9*0.9=8.1, 10*0.9*0.9*0.9=7.29, and 10*0.9*0.9*0.9*0.9=6.561.
Geometric series as an approximation
The mathematically trained eye will notice that this can be summed up and expressed in a shortened, albeit somewhat more technical way, in the form of a geometric series, where d = number of days validated – 1 (which equals the completed epochs).
Image source: Geometric Series. Click to enlarge.
Image: Geometric Series Limit. Click to enlarge.
Also, as can be seen in the comparison of our raw scores and the values projected by the series, in daily application there is only a slight deviation between the approximation and the exact mechanism. The effect of which is most recognizable after the first epoch. However, the differences of the projected and the practically achieved scores – for the result of an individual day set the upper and lower limits to the same value – show an interesting non-conformance. For the second to the last epoch considered here, we have gained a larger percentage than was expected or mathematically possible according to our series – 100.026%. We have not yet found an explanation for the offset, but the fact that we have only experienced a one-time deviation from it of -0.02%, are reliably signing blocks and constantly belonging to the validators with the highest uptime on baklava, reassures us this can only be due to one of the assumptions made, and we still provide the best possible service to the network. Now we are curious if the series is viable for other operators as well and if we could thus offer other Celo validators an additional possibility to analyze their setups. Finally, if you have an idea where our function’s offset might come from or how to integrate a mechanism to take into account the potential downtime penalties we of course all try to avoid, please let us know.