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.