Merge pull request #3306 from omahs/patch-2

Fix: typos

fork_choice/safe-block.md

@@ -15,7 +15,7 @@
 ## Introduction
 
 Under honest majority and certain network synchronicity assumptions
-there exist a block that is safe from re-orgs. Normally this block is
+there exists a block that is safe from re-orgs. Normally this block is
 pretty close to the head of canonical chain which makes it valuable
 to expose a safe block to users.
 

specs/phase0/beacon-chain.md

@@ -269,7 +269,7 @@ Additional preset configurations can be found in the [`configs`](../../configs)
 
 - The `INACTIVITY_PENALTY_QUOTIENT` equals `INVERSE_SQRT_E_DROP_TIME**2` where `INVERSE_SQRT_E_DROP_TIME := 2**13` epochs (about 36 days) is the time it takes the inactivity penalty to reduce the balance of non-participating validators to about `1/sqrt(e) ~= 60.6%`. Indeed, the balance retained by offline validators after `n` epochs is about `(1 - 1/INACTIVITY_PENALTY_QUOTIENT)**(n**2/2)`; so after `INVERSE_SQRT_E_DROP_TIME` epochs, it is roughly `(1 - 1/INACTIVITY_PENALTY_QUOTIENT)**(INACTIVITY_PENALTY_QUOTIENT/2) ~= 1/sqrt(e)`. Note this value will be upgraded to `2**24` after Phase 0 mainnet stabilizes to provide a faster recovery in the event of an inactivity leak.
 
-- The `PROPORTIONAL_SLASHING_MULTIPLIER` is set to `1` at initial mainnet launch, resulting in one-third of the minimum accountable safety margin in the event of a finality attack. After Phase 0 mainnet stablizes, this value will be upgraded to `3` to provide the maximal minimum accountable safety margin.
+- The `PROPORTIONAL_SLASHING_MULTIPLIER` is set to `1` at initial mainnet launch, resulting in one-third of the minimum accountable safety margin in the event of a finality attack. After Phase 0 mainnet stabilizes, this value will be upgraded to `3` to provide the maximal minimum accountable safety margin.
 
 ### Max operations per block
 
@@ -1036,7 +1036,7 @@ def get_total_balance(state: BeaconState, indices: Set[ValidatorIndex]) -> Gwei:
     """
     Return the combined effective balance of the ``indices``.
     ``EFFECTIVE_BALANCE_INCREMENT`` Gwei minimum to avoid divisions by zero.
-    Math safe up to ~10B ETH, afterwhich this overflows uint64.
+    Math safe up to ~10B ETH, after which this overflows uint64.
     """
     return Gwei(max(EFFECTIVE_BALANCE_INCREMENT, sum([state.validators[index].effective_balance for index in indices])))
 ```

sync/optimistic.md

@@ -375,7 +375,7 @@ Given all of this, we can say two things:
    justify an honest chain.
 2. **BNs which are syncing can optimistically import transition blocks.** In
    this case a justified chain already exists blocks. The poison block would be
-   quickly reverted and would have no affect on liveness.
+   quickly reverted and would have no effect on liveness.
 
 Astute readers will notice that (2) contains a glaring assumption about network
 liveness. This is necessary because a node cannot feasibly ascertain that the
@@ -408,13 +408,13 @@ Such a scenario requires manual intervention.
 
 An alternative to optimistic sync is to run a light client inside/alongside
 beacon nodes that mitigates the need for optimistic sync by providing
-tip-of-chain blocks to the execution engine. However, light clients comes with
+tip-of-chain blocks to the execution engine. However, light clients come with
 their own set of complexities. Relying on light clients may also restrict nodes
 from syncing from genesis, if they so desire.
 
 A notable thing about optimistic sync is that it's *optional*. Should an
 implementation decide to go the light-client route, then they can just ignore
-optimistic sync all together.
+optimistic sync altogether.
 
 ### What if `TERMINAL_BLOCK_HASH` is used?