Apply suggestions from code review

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>

EIPS/eip-4844.md

@@ -149,7 +149,7 @@ For previous types of transactions the network encoding is no different, i.e. `T
 The `TransactionNetworkPayload` wraps a `TransactionPayload` with additional data: When a blob transaction is passed through the network,
 the `TransactionNetworkPayload` version of the transaction also includes `blobs` and `kzgs` (commitments list). This wrapping data SHOULD be verified directly before or after signature verification (see the [Networking](#networking) section below).
 
-There are also new validity conditions for blocks, both on the consensus-layer and the execution-layer side. See the [Consensus-layer validation](#consensus-layer-validation) and the [Execution-layer validation](#execution-layer-validation) sections below for details.
+There are also new validity conditions for blocks with respect to this transaction type, both on the consensus-layer and the execution-layer side. See the [Consensus-layer validation](#consensus-layer-validation) and the [Execution-layer validation](#execution-layer-validation) sections below for details.
 
 The signature is verified and `tx.origin` is calculated as follows:
 
@@ -280,19 +280,19 @@ The actual `data_fee` as calculated via `calc_data_fee` is deducted from the sen
 
 ### Consensus-layer validation
 
-On the consensus-layer the blobs are now referenced, but not fully encoded, in the beacon block body.
-Instead of embedding the full contents in the body, the contents of the blobs are propagated separately, as a "sidecar".
+On the consensus-layer the blobs are referenced, but not fully encoded, in the beacon block body.
+Instead of embedding the full contents in the body, the contents of the blobs are propagated separately, as "sidecars".
 
 This "sidecar" design provides forward compatibility for further data increases by black-boxing `is_data_available()`:
 with full sharding `is_data_available()` can be replaced by data-availability-sampling (DAS) thus avoiding all blobs being downloaded by all beacon nodes on the network.
 
 Note that the consensus-layer is tasked with persisting the blobs for data availability, the execution-layer is not.
 
-The `ethereum/consensus-specs` repository defines the following beacon-node changes involved in this EIP:
+The `ethereum/consensus-specs` repository defines the following consensus-layer changes involved in this EIP:
 
 - Beacon chain: process updated beacon blocks and ensure blobs are available.
-- P2P network: gossip and sync updated beacon block types and new blobs sidecars.
-- Honest validator: produce beacon blocks with blobs, publish the blobs sidecars.
+- P2P network: gossip and sync updated beacon block types and new blob sidecars.
+- Honest validator: produce beacon blocks with blobs; sign and publish the associated blob sidecars.
 
 ### Execution-layer validation