Update EIP-7542: Update EIP-7542 to reflect its alignment with EIP-4444

Merged by EIP-Bot.

EIPS/eip-7542.md

@@ -12,15 +12,15 @@ requires: 5793
 ---
 ## Abstract
 
-The purpose of this EIP is to introduce a method that allows an Ethereum node to communicate the range of blocks it has available. By knowing the block range a node can serve, peers can make more informed decisions when choosing whom to connect to, especially when looking for specific block ranges. This can lead to more efficient network behavior.
+The purpose of this EIP is to introduce a method that allows an Ethereum node to communicate the range of blocks it has available. By knowing the block range a node can serve, peers can make more informed decisions when choosing whom to request blocks from or whom to connect to, especially when looking for specific block ranges. This can lead to more efficient network behavior.
 
-This EIP proposes extending the Ethereum wire protocol (`eth`) handshake, introducing a new version, `eth/69`, which will contain information regarding the block range a node can serve. Furthermore, it extends the protocol with 2 new message types to share the updated block ranges when requested.
+This EIP proposes extending the Ethereum wire protocol (`eth`) handshake, introducing a new version, `eth/69`, which will contain information regarding the block range a node can serve. Furthermore, it extends the protocol with two new message types to share the updated block ranges when requested.
 
 ## Motivation
 
-There are scenarios where nodes might be interested in specific block ranges, such as when syncing historical data or analyzing past transactions. Currently, nodes need to connect to peers and request specific blocks to determine if a peer has the required data. This can be inefficient, leading to unnecessary data requests and wasting both bandwidth and time.
+In a first stage of [EIP-4444](./eip-4444.md), some nodes will still need to serve the historical data of the chain and others might be interested in starting to prune it. Currently, nodes need to connect to peers and request specific blocks to determine if a peer has the requested data. This can be inefficient, leading to unnecessary data requests and wasting both bandwidth and time. Consequently, this change empowers nodes that still want to retrieve historical data from the network to do so efficiently.
 
-This also can count as a step towards implementing [EIP-4444](./eip-4444.md).
+As a bonus, This change enhances the efficiency of synchronization by allowing a node to determine if a peer, potentially still in the process of syncing, has the necessary blocks available, thereby avoiding unnecessary block requests and potential empty responses.
 
 ## Specification
 
@@ -57,7 +57,7 @@ Testing will involve ensuring that nodes can correctly communicate and understan
 
 ## Security Considerations
 
-None
+This change is not a standardization of not storing and serving historical blocks before the implementation of alternative historical blocks storage solutions.
 
 ## Copyright