Closed dimpar closed 1 year ago
I don't see how the v2.0.0-m2 special case is managed in the code.
I mean, we don't want to apply the 2 weeks upgrade delay for this version. Instead of this, we want to accept all nodes with v2.0.0-m1 until February 27th, right?
How does the code manage this special case? Sorry if dumb question.
I don't see how the v2.0.0-m2 special case is managed in the code.
I mean, we don't want to apply the 2 weeks upgrade delay for this version. Instead of this, we want to accept all nodes with v2.0.0-m1 until February 27th, right?
How does the code manage this special case? Sorry if dumb question.
For February we will enter this if statement, ie. the latest tag was created before the interval (Jan 25th) and cutoff date for the upgrade is somewhere within the interval. We will validate two versions: the latest and the one before the latest.
When calculating February rewards, we'll need to change https://github.com/threshold-network/merkle-distribution/blob/build-version-req/src/tbtcv2-rewards/rewards-constants.ts#L1 to 2886195
which will be added to the latest version timestamp that marks the cutoff date to Feb 28th 00:00:00 GMT. I assumed we can do it by hand, but if we need a PR then certainly I can create one. But for March rewards, we will need to revert that back to 2 weeks.
When calculating February rewards, we'll need to change https://github.com/threshold-network/merkle-distribution/blob/build-version-req/src/tbtcv2-rewards/rewards-constants.ts#L1 to
2886195
which will be added to the latest version timestamp that marks the cutoff date to Feb 28th 00:00:00 GMT. I assumed we can do it by hand, but if we need a PR then certainly I can create one. But for March rewards, we will need to revert that back to 2 weeks.
Ah, got it. It makes sense. I think it's better to change this const variable in the same PR that the new distribution allocation.
Note: the following changes did not affect past rewards distributions because we had only 1 available version of the
keep-core
client.This PR is about refactoring and fixing how we determine the build version requirement for the client in a given rewards interval. Here's an example:
It can happen that between June 8th and June 30th a node operator might still run an older version v1 but switches to the latest version just before the end of the rewards interval, ie. June 30th. This PR captures all the instances and marks an operator as it didn't fulfill the version requirement, since starting June 8th every single instance must run on the latest version.
This PR also changes the way how we display versions in the JSON output file for a given instance, e.g.