# Optimistic Sync: Unforkable Blocks

This document describes an issue with [Optmistic Sync](https://hackmd.io/Ic7VpkY3SkKGgYLg2p9pMg) where a block that is added to fork choice but later invalidated cannot be "forked out" (i.e. a competing chain cannot be built). This is a liveness attack.

Notably, this is *not* an issue with the core Ethereum specs. It only applies to optimistic sync.

## Scenario

SLOTS_PER_EPOCH = 4
MERGE_FORK_EPOCH = 0

Consider the following range of slots, starting at slot 40 (S40) and epoch 10 (E10):

(E10) S40 S41 S42 S43 (E11) S44 S45 S46 S47 (E12) S48 ...

A malicious proposer is assigned to slots 47 and 48:

(E10) S40 S41 S42 S43 (E11) S44 S45 S46 S47 (E12) S48 ...
                                         😈        😈

As of slot 46, epoch 10 only requires the inclusion of *one more attestation* in order to justify. I.e., if slot 47 contains an attestation to epoch 10, then epoch 10 will justify.

(E10) S40 S41 S42 S43 (E11) S44 S45 S46 S47 (E12) S48 ...
       ^                                 😈        😈
       |                                 ^
       |                                 |
       ----- S47 must contain attn -------
          with target S40 in order for
        E10 to justify during transition
                    to E12.                                   

For completeness, assume that there are not enough attestations at slot 46 to justify E11.

## Attack

Assume `is_execution_enabled() == False` for slot 46 (and prior slots).

At slot 47, the malicious proposer creates a block which includes the attestation required to justify E10. The block also contains the first non-empty `ExecutionPayload`, indicating the terminal PoW block. *However* the payload references a junk `parent_hash` and is therefore invalid.

At slot 48, the malicious proposer (illegally) creates a block atop the *invalid* block at slot 47.

Optimistic nodes will apply the malicious blocks at slot 47 and 48 to thier fork choice, keeping a note that those blocks were only *optimistically* verified (not fully verified). They will assume that the junk `parent_hash` is a valid PoW block they just haven't seen yet.

Now, assume the honest proposer for slot 49 supports optimistic sync and imported both those blocks. Importing the malicious block at slot 48 via [`on_block`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/fork-choice.md#on_block) would have updated the [fork choice store](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/fork-choice.md#store) of the honest proposer to have a `justified_checkpoint` at epoch 10.

Now, any block produced by the honest proposer will rejected by [`filter_block_tree`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/fork-choice.md#filter_block_tree), specifically `correct_justified == False`.

This is because the honest proposer must build atop slot 46 which *does not* contain sufficient attestations to justify epoch 10. Since they're building a block at slot 49 (epoch 12) and are not assigned to any intermediate slots, they are no longer able to include attestations to epoch 10.

It is impossible for the honest proposer to build a block that justifies epoch 10, therefore it is impossible for the honest proposer to build a block that becomes the head of the chain. The chain is no longer live.

Importantly, no validator ever attested to an invalid payload. Therefore, liveness is broken without breaking any assumptions of optimistic sync.

Regarding the *duration* of the liveness failure, it depends on the portion of nodes that optimistically imported the invalid blocks. Any node that was *not* optimistic will be able to continue the chain. How the optimistic nodes attest to that chain is somewhat complicated and not covered in this document.

## Mitigations

This attack is only truly effective during the time of the merge transition (terminal block). Nodes that are syncing ancient history will not be affected if we assume there were non-optimistic nodes to produce a chain. Eventually epochs >= to 10 will be justified and fork choice will start selecting good heads again.

Therefore, a potential mitigation is to declare that nodes cannot perform an optimistic sync (i.e., apply a SYNCING block to fork choice) until the finalized checkpoint has `is_execution_enabled() == True`. This means that an invalid payload can only enter fork choice if it is a descendant of a payload which has been voted upon by >= 2/3rds of validators.

## Additional Considerations

Generally, this is a problem introduced by applying blocks to fork choice that cannot be built on (e.g., because they have an invalid execution payload). Fork choice has not been designed to accept blocks that are impossible to build atop.

Therefore, we enter dangerous waters when we optimistically apply blocks to fork choice. Whilst the attack I've mentioned only applies to the transition, we are open to this type of attack *whenever* a payload returns SYNCING. If an external entity can figure out how to trigger a SYCNING response post-transition, then I would expect to see more classes of attack emerge.

Even if we apply a mitigation for the specific attack in this doc, I still feel we need to do one of two things:

1. Stop applying potentially-invalid blocks to fork choice. I understand this will significantly complicate optimsitic sync.
2. Establish very clear guidelines around what a SYNCING response can be returned. I suggest that SYNCING can only ever mean "the parent_hash is not known".