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

EIPS/eip-7594.md

@@ -8,7 +8,7 @@ status: Review
 type: Standards Track
 category: Networking
 created: 2024-01-12
-requires: 4844
+requires: 4844, 7840
 ---
 
 ## Abstract
@@ -21,6 +21,8 @@ DAS is a method of scaling data availability beyond the levels of [EIP-4844](./e
 
 Providing additional data availability helps bring scale to Ethereum users in the context of layer 2 systems called "roll-ups" whose dominant bottleneck is layer 1 data availability.
 
+Limiting the number of blobs per transaction allows transaction pool to not become a new bottleneck and to be scaled independently of consensus layer.
+
 ## Specification
 
 We extend the blobs introduced in EIP-4844 using a one-dimensional erasure coding extension. Each row consists of the blob data combined with its erasure code. It is subdivided into cells, which are the smallest units that can be authenticated with their respective blob's KZG commitments. Each column, associated with a specific gossip subnet, consists of the cells from all rows for a specific index. Each node is responsible for maintaining and custodying a deterministic set of column subnets and data as a function of their node ID.
@@ -29,6 +31,8 @@ Nodes find and maintain a diverse peer set and sample columns from their peers t
 
 A node can reconstruct the entire data matrix if it acquires at least 50% of all the columns. If a node has less than 50%, it can request the necessary columns from the peer nodes.
 
+We also propose adding a configurable limit to the number of blobs that can be included in a single transaction. This setting will be incorporated into the `blobSchedule` section of the client configuration.
+
 The detailed specifications are on [ethereum/consensus-specs](https://github.com/ethereum/consensus-specs/tree/9d377fd53d029536e57cfda1a4d2c700c59f86bf/specs/fulu/).
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
@@ -60,7 +64,25 @@ The node MUST validate `tx_payload_body` and verify the wrapped data against it.
 - The KZG `commitments` hash to the versioned hashes, i.e. `kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i]`
 - The KZG `commitments` match the corresponding `blobs` and `cell_proofs`. This requires computing the extension cells for all `blobs`, and verifying all `cell_proofs`. (Note: all cell proofs can be batch verified at once)
 
+### Configuration
+
+`blobSchedule` is required to be extended with an additional optional field `maxPerTx`:
+
+```json
+"blobSchedule": {
+  ...
+  "osaka": {
+    ...
+    "maxBlobsPerTx" : 6
+  }
+}
+```
+
+The field defines maximal allowed blob count per transaction.
+
+Clients **MUST** consider this setting during validating transactions received from the network, during block building and validation.
 
+When the field is omitted, a transaction can contain as many blobs as a block.
 
 ## Rationale