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

Fix spelling mistakes

Browse Source
This commit is contained in:
Paul Hauner 2022-01-13 06:56:38 +11:00
parent 0c2e416a6e
commit 6d72038f12
No known key found for this signature in database
GPG Key ID: 5E2CFF9B75FA63DF
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
sync/optimistic.md
View File

@ -310,9 +310,9 @@ Note the use of "feasibly" in the previous paragraph. One can imagine
mechanisms to check that a block is justified before importing it. For example,
just keep processing blocks without adding them to fork choice. However, there
are still edge-cases here (e.g., when to halt and declare there was no
justification?) and how to mitigate implemenation complexity. At this point,
justification?) and how to mitigate implementation complexity. At this point,
it's important to reflect on the attack and how likely it is to happen. It
requires some rather contrived circumstances and it seems very unlikley to
requires some rather contrived circumstances and it seems very unlikely to
occur. Therefore, we need to consider if adding complexity to avoid an
unlikely attack increases or decreases our total risk. Presently, it appears
that `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY` sits in a sweet spot for this