From f72a26cac6168fa85b3cc5bd2596c2f95ade073d Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 16 Feb 2023 11:02:58 +0100 Subject: [PATCH 1/3] Fix: typos --- sync/optimistic.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sync/optimistic.md b/sync/optimistic.md index 79a5271c2e..14eb99fb11 100644 --- a/sync/optimistic.md +++ b/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? From b3db3ec83ad16e50f1d97c370a7fa354b44c391a Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Sat, 25 Mar 2023 12:23:03 +0100 Subject: [PATCH 2/3] Fix: typo --- fork_choice/safe-block.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fork_choice/safe-block.md b/fork_choice/safe-block.md index 490d245381..b76285b3a8 100644 --- a/fork_choice/safe-block.md +++ b/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. From 3115d1140b23dd4c9c23fbd9e2428186cf816bde Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Sat, 25 Mar 2023 13:14:57 +0100 Subject: [PATCH 3/3] Fix: typos --- specs/phase0/beacon-chain.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/phase0/beacon-chain.md b/specs/phase0/beacon-chain.md index 3794cd6be3..b77e017ab7 100644 --- a/specs/phase0/beacon-chain.md +++ b/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]))) ```