# Optimistic Syncing for EIP-4844
We need to tweak the way optimistic sync works. Right now, a `VALID` block means all of its ancestors will also become `VALID` blocks. This breaks with EIP-4844 when blob sidecars are introduced as an optimistcally imported block lacking its sidecar will be incorrectly promoted to `VALID`. This makes It then becomes easy for an attacker to trick peers into treating actual invalid blocks with missing data as valid.

To fix this all we have to do is change the block used as a basis for the block status transition. When a block transitions from `NOT_VALIDATED` to `VALID`, identify the latest ancestor whereby all of its own ancestors satisfy data availability:

(using the same type definitions in the [optimistic sync spec](https://github.com/ethereum/consensus-specs/blob/0ba5b3b5c5bb58fbe0f094dcd02dedc4ff1c6f7c/sync/optimistic.md))

def latest_valid_candidate_block(opt_store: OptimisticStore, block: BeaconBlock) -> BeaconBlock:
    # Assuming the input `block` is VALID
    chain = []
    while True:
        chain.append(block)
        if not is_optimistic(opt_store, block) or block.parent_root == Root():
            break
        block = opt_store.blocks[block.parent_root]
    b = next(b for b in reversed(chain)
          if not is_data_available(b.slot, hash_tree_root(b.body), b.body.blob_kzgs), None)
    return opt_store.blocks[b.parent_root] if b is not None else None

Starting from the block returned by the function we can safely transition it and all of its ancestors to the `VALID` state.

For example:

In the diagram, `B` is the only block missing data. We ignore both `A` and `B` to set `C` and its ancestors as `VALID`.