diff --git a/scaled-node-operators/updates-at-scale.md b/scaled-node-operators/updates-at-scale.md index 3b21ad8..bbf8961 100644 --- a/scaled-node-operators/updates-at-scale.md +++ b/scaled-node-operators/updates-at-scale.md @@ -59,7 +59,7 @@ Alternatively, you can develop a custom bot tailored to your requirements for tr Proper planning is crucial for the smooth execution of software upgrades. By incorporating software upgrade planning into your project management process, you can ensure timely implementation, address the risk of de-prioritization, and mitigate potential technical issues due to more time to research and prepare. -* Ensure that all important data is backed up in advanced. Have a detailed, repeatable process for this. A backup is only truly a backup if you are actually able to restore it, so make sure to test the full end to end process, not just to assume that if you too a backup that it will work. +* Ensure that all important data is backed up in advanced. Have a detailed, repeatable process for this. A backup is only truly a backup if you are actually able to restore it, so make sure to test the full end to end process, not just to assume that if you took a backup that it will work. * Make sure you talk about software upgrades in the planning session: For example, if your team uses Scrum and conducts planning every two weeks, allocate 20 minutes just to go through all the software new releases. This practice will help ensure that upgrades are prioritized and completed within the designated time frame. * Check for deadlines and breaking changes: When you go through the releases, make sure you check for any deadlines associated with software upgrades, such as hard forks or security patches, and plan accordingly. Also, examine the release notes for breaking changes that may require additional work or adjustments to your existing configurations. Keep in mind that some changes, like database upgrades, might be irreversible and must be rolled out with care. diff --git a/validator-clients/validator-effectiveness.md b/validator-clients/validator-effectiveness.md index 6bfa16e..f01de8e 100644 --- a/validator-clients/validator-effectiveness.md +++ b/validator-clients/validator-effectiveness.md @@ -38,7 +38,7 @@ For an attestation to become part of the chain it needs to be included in a bloc Block production failure has a second impact, which is that it increases the total number of attestations that are eligible for inclusion in the next block that is produced. If there are more attestations available than can fit in a block the producer is likely to include the attestations that return the highest reward, which will be those with the lowest inclusion distance. This can result in attestations that miss their optimal block also missing subsequent blocks due to being less and less attractive to include. -The fact that block production is out of the validator’s control (except for those the validator itself produces) requires the definition of the term earliest inclusion slot, where the earliest inclusion slot is the first slot greater than the attestation slot in which a valid block is produced. This takes in to account the fact that attestations cannot be included in blocks that do not exist, and is no reflection on the effectiveness of the validator. +The fact that block production is out of the validator’s control (except for those the validator itself produces) requires the definition of the term earliest inclusion slot, where the earliest inclusion slot is the first slot greater than the attestation slot in which a valid block is produced. This takes into account the fact that attestations cannot be included in blocks that do not exist, and is no reflection on the effectiveness of the validator. ## Malicious Activity