# Extend Inclusion List (EIP-7547) for Blob Tx

Currently, Blob transactions (type-3) are not supported in the Inclusion list EIP (EIP-7547). This document explores ideas and proposed changes to enable blob tx support. It is organized into the following sections for easier comprehension.

### Consensus data structure changes

class InclusionListSummaryEntry(Container):
    address: ExecutionAddress
    nonce: uint64
    tx_type: uint64 # New for Blob Tx

class InclusionList(Container):
    signedSummary: SignedInclusionListSummary
    transactions: List[Transaction, MAX_TRANSACTIONS_PER_INCLUSION_LIST]
    blobs: List[Blob, MAX_BLOBS_PER_INCLUSION_LIST] # New for Blob Tx

- We have added `tx_type` to `InclusionListSummaryEntry` to quickly identify the type of transaction the summary refers to. However, its necessity remains to be evaluated.
- We have added `blobs` to `InclusionList`. To begin, `MAX_BLOBS_PER_INCLUSION_LIST` can be set to a small value, such as one, if there are concerns about bandwidth and a need for pending test data. For simplicity, I have included only `blobs`, leaving it to the receiver to calculate the rest commitment and proof. This approach assumes a reasonable client would gossip `InclusionList` during non-busy times, allowing sufficient time for the receiver to compute the rest.
- We assume that `blobs` are ordered in the same manner as `transactions` and `signedSummary`.

### Consensus check changes

- Where `MAX_BLOBS_PER_BLOCK` is applied, the check should be modified to `MAX_BLOBS_PER_BLOCK` + `MAX_IL_BLOBS_PER_BLOCK`.
- We must also ensure that `MAX_BLOBS_PER_BLOCK` + `MAX_IL_BLOBS_PER_BLOCK` does not exceed `MAX_BLOB_COMMITMENTS_PER_BLOCK`.

### Networking changes

We reserve some subnet indices for the inclusion list blob sidecar, these should be fixed. For example, if today's blob sidecar indices range from 0 to 5, we could choose a sufficiently high number, such as 100+, for the inclusion list blob sidecar indices.

### Proposer duty changes

#### To propose `inclusion_list`
`engine_getInclusionListV1` returns
1. `inclusionListSummary`: `InclusionListSummaryV1` - Summary.
2. `inclusionListTransactions`: `Array of DATA`
3. `inclusionListBlobs`: `Array of DATA` **# New for Blob Tx**

* The proposer retrieves `inclusionListBlobs` from the EL client, adds them to the `InclusionList`, and broadcasts that to the network.

#### To propose `beacon_block` and `blob_sidecars`
`engine_getPayloadV3` returns
1. `executionPayload`: `ExecutionPayloadV3`
2. `blockValue` : `QUANTITY
3. `blobsBundle`: `BlobsBundleV1`
4. `inclusionListBlobsBundle`: `BlobsBundleV1` **# New for Blob Tx**
5. `shouldOverrideBuilder` 

* The proposer constructs new IL blob sidecars from `inclusionListBlobsBundle` and broadcasts them to the respective network.
* The new IL blob sidecar's kzg commitments should be placed correctly in the beacon block body.

### Inclusion list verification changes

At slot `n` when `on_inclusion_list` gets triggered, a node needs to verify the new `blobs` field aligns with the `transactions` field. The CL will convert the individual `blob` to `version_hash` and pass that to `engine_newInclusionListV1`

`engine_newInclusionListV1` should contain a new parameter for version hashes.
1. `inclusionListSummary`: `InclusionListSummaryV1`
2. `inclusionListTransactions`: `Array of DATA`
3. `expectedInclusionListBlobVersionedHashes`: `Array of DATA` **# New for Blob Tx**

- The EL client will be able to verify `expectedInclusionListBlobVersionedHashes` aligns with `inclusionListTransactions` and `inclusionListSummary`.
- After this point, the CL client could discard the blob. However, the node could also perform an early verification and cache the result with `verify_blob_kzg_proof`, so it doesn't need to verify the blob again in subsequent slots.
- The blob sidecar could be satisfied in `n` or `n+1`, if it's already satisfied in `n` then you dont need to cache the result of `verify_blob_kzg_proof`

### Payload verification changes

At slot `n+1`, the node should receive the normal blob sidecars, maybe IL blob sidecars if it's not satisfied in `n`, and the signed beacon block containing the execution payload. All the blob sidecars should match the kzg, proof, and block body alignment and availability checks. The rest of the verification is done on the execution layer under `engine_newPayload` call. Argument `expectedBlobVersionedHashes` should have IL blob version hashes, but we could add another argument too.

### Execution verification changes

Warning: I may not have complete expertise in this area. It seems you need to follow the same process as before but use the `InclusionListSummaryEntry`'s `tx_type` field to determine whether the transaction should be treated as a normal transaction or a blob transaction. Additionally, for blob transactions, apply special checks to see if they match versioned hashes, whether they were included in the previous slot, among others.