Apply suggestions from code review

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
Co-authored-by: Jimmy Chen <jchen.tc@gmail.com>

specs/deneb/fork-choice.md

@@ -24,7 +24,7 @@ This is the modification of the fork choice accompanying the Deneb upgrade.
 
 ## Helpers
 
-#### `validate_blob_sidecars`
+#### `validate_blobs`
 
 ```python
 def validate_blobs(expected_kzg_commitments: Sequence[KZGCommitment],
@@ -47,7 +47,8 @@ The block MUST NOT be considered valid until all valid `Blob`s have been downloa
 
 ```python
 def is_data_available(beacon_block_root: Root, blob_kzg_commitments: Sequence[KZGCommitment]) -> bool:
-    # `retrieve_blobs_and_proofs` is implementation and context dependent, raises an exception if not available. It returns all the blobs for the given block root.
+    # `retrieve_blobs_and_proofs` is implementation and context dependent
+    # It returns all the blobs for the given block root, and raises an exception if not available
     # Note: the p2p network does not guarantee sidecar retrieval outside of `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS`
     blobs, proofs = retrieve_blobs_and_proofs(beacon_block_root)
 

specs/deneb/p2p-interface.md

@@ -228,7 +228,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 blobs sidecar is well-formatted and correct w.r.t. the expected KZG commitments through `validate_blobs_sidecar`.
+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`.
 
 `BlobSidecarsByRange` is primarily used to sync blobs that may have been missed on gossip and to sync within the `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS` window.
 
@@ -255,11 +255,11 @@ to be fully compliant with `BlobsSidecarsByRange` requests.
 participating in the networking immediately, other peers MAY
 disconnect and/or temporarily ban such an un-synced or semi-synced client.
 
-Clients MUST respond with at least the first blobs sidecar that exists in the range, if they have it, and no more than `MAX_REQUEST_BLOB_SIDECARS * MAX_BLOBS_PER_BLOCK` sidecars.
+Clients MUST respond with at least the first blob sidecar that exists in the range, if they have it, and no more than `MAX_REQUEST_BLOB_SIDECARS * MAX_BLOBS_PER_BLOCK` sidecars.
 
-The following blobs sidecars, where they exist, MUST be sent in consecutive `(slot, index)` order.
+The following blob sidecars, where they exist, MUST be sent in consecutive `(slot, index)` order.
 
-Clients MAY limit the number of blobs sidecars in the response.
+Clients MAY limit the number of blob sidecars in the response.
 
 The response MUST contain no more than `count * MAX_BLOBS_PER_BLOCK` blob sidecars.
 

specs/deneb/validator.md

@@ -104,7 +104,7 @@ def get_blob_sidecars(block: BeaconBlock, blobs: Sequence[Blob]) -> Sequence[Blo
 
 ```
 
-Then `signed_sidecar = SignedBlobSidecar(message=sidecar, signature=signature)` is constructed and published to the `blob_sidecar_{index}` topics according to its index.
+Then for each sidecar, `signed_sidecar = SignedBlobSidecar(message=sidecar, signature=signature)` is constructed and published to the `blob_sidecar_{index}` topics according to its index.
 
 `signature` is obtained from: