Update EIP-7892: Add blob count per tx limit via blobSchedule

EIPS/eip-7892.md

@@ -12,7 +12,7 @@ requires: 7840
 
 ## Abstract
 
-This EIP introduces **Blob Parameter Only (BPO) Hardforks**, a lightweight mechanism for incrementally scaling Ethereum’s blob capacity through targeted hard forks that modify only blob-related parameters: `blob target`, `blob limit`, and `baseFeeUpdateFraction`. Unlike traditional hard forks, which require extensive coordination and introduce broader protocol changes, BPO forks enable rapid, low-overhead scaling of blob capacity in response to **real-world demand and network conditions**.
+This EIP introduces **Blob Parameter Only (BPO) Hardforks**, a lightweight mechanism for incrementally scaling Ethereum’s blob capacity through targeted hard forks that modify only blob-related parameters: `target`, `max`, `baseFeeUpdateFraction`, and `maxBlobsPerTx`. Unlike traditional hard forks, which require extensive coordination and introduce broader protocol changes, BPO forks enable rapid, low-overhead scaling of blob capacity in response to **real-world demand and network conditions**.
 
 ## Motivation
 
@@ -49,8 +49,9 @@ BPO hardforks are defined as protocol upgrades that modify only blob-related par
 
 The following protocol parameters are now managed by the blob schedule configuration:
 
-- **Blob Target (`blob_target`)**: The expected number of blobs per block.
-- **Blob Limit (`blob_limit`)**: The maximum number of blobs per block.
+- **Blob Target (`target`)**: The expected number of blobs per block.
+- **Blob Limit (`max`)**: The maximum number of blobs per block.
+- **Blob Limit per transaction (`maxBlobsPerTx`)**: The maximum number of blobs per transaction.
 - **Blob Base Fee Update Fraction (`baseFeeUpdateFraction`)**: Determines how blob gas pricing adjusts per block.
 
 To ensure consistency, when a regular hardfork changes any of these parameters, it MUST do so by adding an entry to the blob schedule configuration.
@@ -74,16 +75,19 @@ To facilitate these changes on the execution layer, each fork in the `blobSchedu
   "osaka": {
     "target": 9,
     "max": 12,
+    "maxBlobsPerTx": 9,
     "baseFeeUpdateFraction": 5007716
   },
   "bpo1": {
     "target": 12,
     "max": 16,
+    "maxBlobsPerTx": 12,
     "baseFeeUpdateFraction": 5007716
   },
   "bpo2": {
     "target": 16,
     "max": 24,
+    "maxBlobsPerTx": 12,
     "baseFeeUpdateFraction": 5007716
   },
 },
@@ -117,6 +121,7 @@ The parameters and schedules above are purely illustrative. Actual values and sc
 - Execution and consensus clients **MUST** share consistent BPO fork schedules.
 - The slot number in the EL's `blobSchedule` **MUST** align with the start of the epoch specified in the consensus layer configuration.
 - The `max` field in the EL's `blobSchedule` **MUST** equal the `MAX_BLOBS_PER_BLOCK` value in the consensus layer configuration.
+- The `maxBlobsPerTx` field is optional and defaults to value of `max` when omitted. It is not used by the consensus layer.
 
 ### Modified `compute_fork_digest`
 
@@ -182,6 +187,10 @@ No changes are needed in this interaction, but it is noted that the response pay
 
 No changes are required to topic structure or configuration. However, all topics will automatically rotate at a BPO fork due to changes in their `ForkDigestValue` component.
 
+#### Transaction Pool considerations
+
+A BPO fork may decrease the number of blobs allowed per block or transaction. This means that transactions in the pool with a high blob count may become ineligible for inclusion. Such transactions **MUST NOT** be propagated and should be considered for eviction from the transaction pool.
+
 ## Rationale
 
 ### Why not just use regular hardforks?