mirror of
https://github.com/sigp/lighthouse.git
synced 2026-03-11 18:04:18 +00:00
3f6c11db0e
* #6447 - Move some deprecated pages to a new section under `Archived` - Remove fallback log in mev as the log will not be present after VC using `/eth/v3/validator/blocks` endpoint by default - Add warning against using Btrfs file system (thank you @ChosunOne for the report) - Add data shared by @mcdee on tree states API queries time - Rename partial withdrawals to validator sweep to differentiate it from the upcoming execution layer partial withdrawals - Update NAT API response - Update docs on IPv6 - Rename .md files to follow a standard prefix section name, e.g., installation_*.md, advanced_*.md - Standardise .md files using underscore `_` instead of hyphen `-` to be consistent with other files naming conventions.
1.3 KiB
1.3 KiB
Update Priorities
When publishing releases, Lighthouse will include an "Update Priority" section in the release notes. As an example, see the release notes from v2.1.2).
The "Update Priority" section will include a table which may appear like so:
| User Class | Beacon Node | Validator Client |
|---|---|---|
| Staking Users | Medium Priority | Low Priority |
| Non-Staking Users | Low Priority | --- |
To understand this table, the following terms are important:
- Staking users are those who use
lighthouse bnandlighthouse vcto stake on the Beacon Chain. - Non-staking users are those who run a
lighthouse bnfor non-staking purposes (e.g., data analysis or applications). - High priority updates should be completed as soon as possible (e.g., hours or days).
- Medium priority updates should be completed at the next convenience (e.g., days or a week).
- Low priority updates should be completed in the next routine update cycle (e.g., two weeks).
Therefore, in the table above, staking users should update their BN in the next days or week and their VC in the next routine update cycle. Non-staking should also update their BN in the next routine update cycle.