# 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 ```python class InclusionListSummaryEntry(Container): address: ExecutionAddress nonce: uint64 tx_type: uint64 # New for Blob Tx ``` ```python 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.
Last changed by  
 
Terence Tsao
404

Read more

ePBS Builder Reveal Timing Games

This post begins by explaining consensus and execution block timing before and after ePBS. We then explores the dynamics of timing when the builder block is revealed, focusing on altruistic, honest, and greedy rational behaviors of builders. The discussion highlights potential advantages of greedy rational builder behavior. Finally, we will list out a series of open questions for further exploration.

4/30/2024
ePBS Annotated Validator Spec

get_inclusion_list retrieves a list of transactions and their corresponding summaries from an execution layer client using the Execution Engine API. The function's implementation may vary, similar to the implementation get_payload It interfaces with an external execution engine via the Engine API. The function returns a GetInclusionListResponse object, which includes both summaries and transactions. The summaries field consists of a list of execution addresses from the transaction senders, while transactions field consists of a list of transactions. Both the summary and transactions are of equal length and are limited by MAX_TRANSACTIONS_PER_INCLUSION_LIST.

4/22/2024
ePBS: Bypassing Relayer

TLDR: Relayers today represent both functionalities and entities. Under ePBS, the entities will disappear, but the functionalities may persist. Builders can and likely will absorb these relayer functionalities, which is positive for the MEV supply chain and the beacon chain for the reasons outlined below.

4/15/2024
ePBS vs ET

(The views expressed in this document represent only my own and not my team's)

4/8/2024
Read more from Terence Tsao
Published on HackMD