You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently the slasher (#1567) runs batch updates at a user configurable interval -- optimally once per slot. In future it might be nice to make it so that it runs, e.g. just after most attestations are expected to have been received, or just in time to finish before the next block proposal. This would ensure that a validator doesn't accidentally miss out
Currently the slasher updates will often run for longer than 12 seconds (particularly when spinning up), so this issue is likely more relevant once we can guarantee its runtime within substantially less than 12 seconds.
The text was updated successfully, but these errors were encountered:
## Issue Addressed
Closes#2112Closes#1861
## Proposed Changes
Collect attestations by validator index in the slasher, and use the magic of reference counting to automatically discard redundant attestations. This results in us storing only 1-2% of the attestations observed when subscribed to all subnets, which carries over to a 50-100x reduction in data stored 🎉
## Additional Info
There's some nuance to the configuration of the `slot-offset`. It has a profound effect on the effictiveness of de-duplication, see the docs added to the book for an explanation: https://github.com/michaelsproul/lighthouse/blob/5442e695e5256046b91d4b4f45b7d244b0d8ad12/book/src/slasher.md#slot-offset
Description
Presently the slasher (#1567) runs batch updates at a user configurable interval -- optimally once per slot. In future it might be nice to make it so that it runs, e.g. just after most attestations are expected to have been received, or just in time to finish before the next block proposal. This would ensure that a validator doesn't accidentally miss out
Currently the slasher updates will often run for longer than 12 seconds (particularly when spinning up), so this issue is likely more relevant once we can guarantee its runtime within substantially less than 12 seconds.
The text was updated successfully, but these errors were encountered: