Remove extraneous length check from deneb forkchoice

specs/deneb/fork-choice.md

@@ -8,7 +8,6 @@
 - [Introduction](#introduction)
 - [Containers](#containers)
 - [Helpers](#helpers)
-    - [`validate_blobs`](#validate_blobs)
     - [`is_data_available`](#is_data_available)
 - [Updated fork-choice handlers](#updated-fork-choice-handlers)
   - [`on_block`](#on_block)
@@ -24,21 +23,10 @@ This is the modification of the fork choice accompanying the Deneb upgrade.
 
 ## Helpers
 
-#### `validate_blobs`
-
-```python
-def validate_blobs(expected_kzg_commitments: Sequence[KZGCommitment],
-                   blobs: Sequence[Blob],
-                   proofs: Sequence[KZGProof]) -> None:
-    assert len(expected_kzg_commitments) == len(blobs) == len(proofs)
-
-    assert verify_blob_kzg_proof_batch(blobs, expected_kzg_commitments, proofs)
-```
-
 #### `is_data_available`
 
 The implementation of `is_data_available` will become more sophisticated during later scaling upgrades.
-Initially, verification requires every verifying actor to retrieve all matching `Blob`s and `KZGProof`s, and validate them with `validate_blobs`.
+Initially, verification requires every verifying actor to retrieve all matching `Blob`s and `KZGProof`s, and validate them with `verify_blob_kzg_proof_batch`.
 
 The block MUST NOT be considered valid until all valid `Blob`s have been downloaded. Blocks that have been previously validated as available SHOULD be considered available even if the associated `Blob`s have subsequently been pruned.
 
@@ -54,7 +42,7 @@ def is_data_available(beacon_block_root: Root, blob_kzg_commitments: Sequence[KZ
     if isinstance(blobs, str) or isinstance(proofs, str):
         return True
 
-    validate_blobs(blob_kzg_commitments, blobs, proofs)
+    assert verify_blob_kzg_proof_batch(blobs, blob_kzg_commitments, proofs)
     return True
 ```
 

specs/deneb/p2p-interface.md

@@ -264,7 +264,7 @@ Requests blob sidecars in the slot range `[start_slot, start_slot + count)`, lea
 
 The response is unsigned, i.e. `BlobSidecarsByRange`, as the signature of the beacon block proposer may not be available beyond the initial distribution via gossip.
 
-Before consuming the next response chunk, the response reader SHOULD verify the blob sidecar is well-formatted and correct w.r.t. the expected KZG commitments through `validate_blobs`.
+Before consuming the next response chunk, the response reader SHOULD verify the blob sidecar is well-formatted and correct w.r.t. the expected KZG commitments through `verify_blob_kzg_proof_batch`.
 
 `BlobSidecarsByRange` is primarily used to sync blobs that may have been missed on gossip and to sync within the `MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS` window.