# Extending Blob Txs to FOCIL

This document highlights FOCIL to support blob transactions using the execution layer's blob pool. It covers high-level changes followed by potential implications.
### Beacon Chain
- Add `blob_version_hashes` to `InclusionList` to handle up to `MAX_BLOBS_PER_INCLUSION_LIST`.

class InclusionList(Container):
    blob_version_hashes: List[Bytes32, MAX_BLOBS_PER_INCLUSION_LIST]

### Fork Choice
- Update `Store` to track blobs in the local blob pool at the cutoff.

class Store(object):
	seen_version_hashes: List[Bytes32, MAX_BLOBS_PER_INCLUSION_LIST * IL_COMMITTEE_SIZE]

### Engine API
- Add `engine_hasBlobsV1` endpoint to verify if blobs exist in the local blob pool.
- **Parameters**
- Array of 32-Byte blob version hashes
- **Response**
- Array of Booleans
- `engine_getInclisionList` provides inclusion list transactions and blob hashes for proposers to build `InclusionList`.

### Beacon P2P
- Introduce a new RPC endpoint for requesting individual blobs and proofs, checked against the local database and blob pool without penalizing peers if sidecars are missing. Bandwidth constraints may require rate limiting.
- **Protocol ID:** `/eth2/beacon_chain/req/blob_and_proof_by_root/1/`
- **Request Content:** `List[Bytes32, MAX_REQUEST_BLOB_AND_PROOF]`
- **Response Content:** `List[BlobAndProof, MAX_REQUEST_BLOB_AND_PROOF]`

### Slot Interval Changes
- When attesters freeze their view, they capture blobs in their local blob pool and cache that info onto fork choice store.
- When Proposers freeze their view, they check if they meet the threshold for IL satisfaction. If below satisfaction threshold, they manually request blobs and proofs via P2P.
- When attesters validate the block, they check if it contains the maximum blobs per block or any cached versioned hashes from the previous slot’s freeze interval. Attesters will not vote for the block if it is neither full nor contains version hashes up to a certain threshold.

### Implications
- Proposers might need to fetch blobs over P2P if the local blob pool is insufficient to meet IL thresholds, which could take significant time.
- Nodes requesting blobs and proofs over P2P may experience delays due to reliance on the EL blob pool.
- A new IL satisfactory rule based on blob transactions: if the block contains the maximum number of blobs, the blob satisfactory check is ignored. If the block has space for more blobs but lacks version hashes up to a certain threshold, it should not receive any votes