I would like to kick off the process submitted in the Watchtower Update Proposal Thread to propose the first upgrade, so-named Rewards Tree Spec v2. As you can see, a few of us have already spent some time discussing it and even implementing it in both the official Watchtower and the Rocketscan backend (thanks to @Peteris) but I wanted to ensure that everyone had time to comment on it and run through the process first.
There are 2 notable breaking changes from the original (v1) version of the rewards tree spec:
Validators that are
stakingaccording to Rocket Pool on the Execution Layer but do not currently have an index on the Beacon Chain are no longer included in the tree. This was something that wasn’t made explicitly clear in the spec, and thus my watchtower code incorrectly included minipools without indices while Peteris’s code did not. There is a very narrow window (4 hours) that can occur once in a validator’s life where both deposits have been submitted on the Execution Layer, but the Beacon Chain hasn’t picked up on either one yet and this hasn’t assigned the validator an index. At each interval, I store a mapping of indices (integers) to validator pubkeys. These validators always showed up with index 0 which is the default when the Beacon Chain does not have any data about them. This always overwrites anything with an existing index of 0. Thus, once during interval 2 and once during interval 3 there was one extra validator that copied validator 0’s performance when it should not have been there at all.
Minipool rewards are now weighted by how long that minipool has been alive, in addition to how long the Node has been opted into the Smoothing Pool. This is an actual change to the way rewards are calculated, not just a clarification and a bug fix. Currently, minipools can be created merely a day or two before the rewards snapshot; if their owning Node has been opted in the whole time, the minipool will receive full credit as though it had been contributing the whole time when clearly it had not. In this change, we weigh the minipool’s rewards by the following (using pseudocode):
intervalSlots := intervalEndSlot - intervalStartSlot modifier := min(intervalSlots, (validatorExitSlot - validatoAactivationSlot)) / intervalSlots
In other words, it is prorated based on how much time it has been
active in the current interval. Being active for the whole duration effectively eliminates this weight.
In my mind, v1 should have shipped with these updates baked directly in. Since these changes are small and do not detract unfairly from anyone’s rewards, I do not believe them to be controversial. That being said, I would like the community and Oracle DAO to discuss them.
As I mentioned, Peteris and I already built, tested, and compared implemntations of this code. You can view it in the comparison between v1 and v2 here:
I would like to ship these as part of Smartnode v1.7.1, which is scheduled for mid-to-late next week depending on other client releases. The Oracle DAO change would not activate until Interval 4’s checkpoint on 2022/12/22 05:35:39 UTC. This would give them ample time to inspect and approve the changes before upgrading to v1.7.1 or beyond.
Thanks all, looking forward to your feedback on these changes!