diff --git a/EIPS/eip-7742.md b/EIPS/eip-7742.md index 4cb6a87ffdd305..8deae63f0d57e3 100644 --- a/EIPS/eip-7742.md +++ b/EIPS/eip-7742.md @@ -44,9 +44,9 @@ and deployment of changes to the blob count easier. #### Maximum blobs per block -The max blob count is now provided and controlled by the CL during block production which the ELs must use to bound the maximum blobs it can pack in a block. +The blob maximum is verified in the CL node and the EL inherits this verification during the consistency check of the versioned hashes corresponding to each blob as specified by the Engine API. Because of this, the strict check specified by EIP-4844 is unnecessary. -For purposes of block validations, ELs already validate new payloads from CL against expected CL blob versioned hashes. For optimistically synced blocks from peer nodes, EL may further assume that the entire ancestor EL peer synced chain blocks correctly obeys this condition by the canonicality and correctness of the block they backfilling from as instructed by the CL. +For optimistically synced blocks from peer nodes, EL may further assume that the entire ancestor EL peer synced chain blocks correctly obeys this condition by the canonicality and correctness of the block they backfilling from as instructed by the CL. Hence we entirely deprecated the `MAX_BLOB_GAS_PER_BLOCK` checks from [EIP-4844](./eip-4844.md). @@ -54,7 +54,7 @@ Hence we entirely deprecated the `MAX_BLOB_GAS_PER_BLOCK` checks from [EIP-4844] The target is currently specified as a fixed value in relation to the blob count. The Ethereum community intends to increase the blob parameters as part of its scaling strategy and the ability to have a more flexible target value in relation to the blob max is desirable to reduce rigidity in this protocol parameter. -To this end CL now provides a blob count target as well during block production and the EL block header is extended with this `target_blob_count` value to preserve the security of optimistic sync as well as for the purpose of `excess_blob_gas` and blob base fee calculations. +Even if the EL keeps a fixed target value based on the max, removing the max implies the EL would not know what the target value should be. To address this lack of information, this EIP proposes the CL sends the current target value to the EL with each provided payload over the Engine API. The EL block header will also need to be extended with this `target_blob_count` value to preserve the security of optimistic sync. #### Updated Fee calculations