Develop to Main #285
Merged
Develop to Main #285
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a bug in the accounting of sync committees. One validator could participate in the same sync committee multiple times under different committee indexes. Previously in the code, there was an implicit assumption that a validator can be presented in a sync committee of the particular block only one time. This led to an incorrect accounting of sync committees and incorrect calculation of validator rewards for participation in sync committees. For example, in the 5-th Pectra devnet, the validator 8568 https://dora.pectra-devnet-5.ethpandaops.io/validator/0x9617f22db51844882a8115ee19613cf7a6211107a878aefc61111ad650304f0557aa10f977c38b9b978349c5eaf8ecc2 proposed a slot 179518 https://dora.pectra-devnet-5.ethpandaops.io/slot/179518 in the epoch 5609 https://dora.pectra-devnet-5.ethpandaops.io/epoch/5609 The sync committee for epoch 5609 contains validators with indexes 1298, 2561, 4326, 8113, and 9377 two times. Rewards for participation of these validators in the sync committee for the second time were not taken into account. So, when slot 179518 is proposed, EVM calculated rewards for proposing this slot incorrectly. Now the bug is fixed. The `sync_meta` field of the `ValidatorDutySummary` structure was extended to contain several synced blocks if a validator participate in the same committee multiple times. Also, the calculation of the percentage of sync committee participation and the calculation of rewards for sync committee participation have been updated.
The `summaryValidator` object in the `check` method of `SyncService` might be null. In this case, addressing the `is_sync` property of this variable caused an error. Now this bug is fixed.
Add intermediate variables to the `sync_percent` calculation formula.
Remove unnecessary variables from the "Rewards & Penalties" dashboard.
Add a new `CL_API_MAX_SLOT_DEEP_COUNT` env variable that specifies a maximum number of slots that the app uses to find a not missed consensus-layer slot. Previously, this number was hard-coded in the appropriate constant in the `ConsensusProviderService`. As after the Pectra hardfork on Holeksy blocks became proposed significantly more rarely than usual, it became possible not to have any proposed blocks in the closest 32 slots, and so, the app gave up trying to find the closed proposed block and threw the error. Now it is possible to configure this depth for cases like we see now on Holesky and extend this depth to any necessary value. So the app can look deeper into the slots chain and find the next (or previous) proposed block. Also, some minor refactoring has been done in the `ConsensusProviderService` and fixed incorrect numbers in the error message that is shown when the app cannot find the closest proposed block. Previously in case of such errors, the error message always looked like "Error when trying to get next not missed block header. From N to N" because of the recursive call.
…ky-workflows Workflows adjustments for hoodi/holesky deployments
…kflow EVM holesky workflow
…t-deep-count feat: configurable max slot deep count
The current calculation algorithm of missed rewards for attestations is working incorrectly for validators with a max effective balance greater than 32. As a result of this calculation, the value of the missed attestation reward for such validators might be negative. The attempt to store a negative value of missed attestation reward to the DB causes failures that lead to a complete inability to update the "validators_summary" table and loss of data about all validators in the epoch where this calculation error happened. The calculation of missed attestation rewards for 0x02 validators is temporarily disabled until we understand better how to calculate missed attestation rewards for all types of validators.
…ds-calculation fix: missed rewards for attestations
Proper fix for missed attestations rewards calculation. In the previous version of the missed rewards calculation algorithm, there was a hard assumption that the effective balance of any validator must be 32 ETH. After Pectra hardfork this assumption is no longer valid. So, now to calculate the "perfect" attestation rewards that a validator could earn if it fully executes all attestation duties the algorithm should use the actual validator effective balance, not 32. This PR makes the rewards calculation algorithm use the actual validator balance in missed rewards calculation and also extracts some common multiplications to new variables.
Move the `getRewards` function call out of the cycle.
…ds-calculation-3 fix: missed rewards for attestations - 2
refactor: rewards dashboard
Exclude validators with the "pending_initialized" status from the reward calculation. There was an error with the reward calculation for some validators on Hoodi testnet on the epoch when the Pectra hardfork was activated (2048). At the time of the hadrfork, many validators of the "Attestant (BVI) Limited" node operator were waiting for the activation. Most of these validators had the status "pending_queued" at the last epoch before the hardfork (2047). All validators with this status had 32 ETH on their balance. On the epoch 2048 (Pectra hardfork activation epoch), some of these validators changed their status from "pending_queued" to "pending_initialized" (for example, validators with indexes from 1073611 to 1074310) and their balance became zero. To calculate reward calculation error EVM compares all the rewards calculated by EVM algorithms with the validators' balance change. As in the previous epoch balance of many validators was 32, and in the next epoch it became zero, it led to an incorrect reward calculation error. To avoid this kind of issue in the future, validators with the "pending_initialized" status are now excluded from the rewards calculation. As these validators are not active anyway and don't participate in validator duties, no rewards or penalties can be applied to them.
fix: sync committee accounting
…zed-validators-from-rewards-calculation fix: exclude pending initialized validators
dputko
approved these changes
Apr 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.