status-im/eth2.0-specs
2
0
Fork 0
mirror of https://github.com/status-im/eth2.0-specs.git synced 2025-02-03 14:24:24 +00:00
Code Issues Projects Releases Wiki Activity

Fix: typos

Browse Source
This commit is contained in:
omahs 2023-02-16 11:02:58 +01:00 committed by GitHub
parent ab11a014ee
commit f72a26cac6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
sync/optimistic.md
View File

@ -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?