Update EIPS/eip-234.md

Co-authored-by: g11tech <develop@g11tech.io>

EIPS/eip-234.md

@@ -28,7 +28,7 @@ A client (dApp) who needs reliable notification of both log additions (on new bl
 
 In order to deal with this while still providing a robust mechanism for internal block/log additional/removal, the client can maintain a blockchain internally (last `n` blocks) and only subscribe/poll for new blocks.  When a new block is received, the client can reconcile their internal model with the new block, potentially back-filling parents or rolling back/removing blocks from their internal model to get in sync with the node.  This can account for any type of disconnect/reorg/outage scenario and also allows the client (as an added benefit) to talk to a cluster of Ethereum nodes (e.g., via round-robin) rather than being tightly coupled to a single node.
 
-Once the user has a reliable stream of blocks, they can then look at the bloom filter for the new block and if the block *may* have logs of interest they can fetch the filtered logs for that block from the node.  The problem that arises is that a re-org may occur between when the client receives the block and when the client fetches the logs for that block.  Given the current set of filter options, the client can only ask for logs by block number.  In this scenario, the logs they get back will be for a block that *isn't* the block they want the logs for and is instead for a block that was re-orged in (and may not be fully reconciled with the internal client state).  This can be partially worked around by looking at the resulting logs themselves and identifying whether or not they are for the block hash requested.  However, if the result set is an empty array (no logs fetched) then the client is in a situation where they don't know what block the results are for.  The results could have been legitimately empty (bloom filter can yield false positives) for the block in question, or they could be receiving empty logs for a block that they don't know about.  At this point, there is no decision the client can make that allows them a guarantee of recovery.  They can assume the empty logs were for the correct block, but if they weren't then they will never try to fetch again.  This creates a problem if the block was only transiently re-orged out because it may come back before the next block poll so the client will never witness the reorg.  They can assume the empty logs were for the wrong block, a refetch them, but they may continue to get empty results putting them right back into the same situation.
+Once the user has a reliable stream of blocks, they can then look at the bloom filter for the new block and if the block *may* have logs of interest they can fetch the filtered logs for that block from the node.  The problem that arises is that a re-org may occur between when the client receives the block and when the client fetches the logs for that block.  Given the current set of filter options, the client can only ask for logs by block number.  In this scenario, the logs they get back will be for a block that *isn't* the block they want the logs for and is instead for a block that was re-orged in (and may not be fully reconciled with the internal client state).  This can be partially worked around by looking at the resulting logs themselves and identifying whether or not they are for the block hash requested.  However, if the result set is an empty array (no logs fetched) then the client is in a situation where they don't know what block the results are for.  The results could have been legitimately empty (bloom filter can yield false positives) for the block in question, or they could be receiving empty logs for a block that they don't know about.  At this point, there is no decision the client can make that allows them a guarantee of recovery.  They can assume the empty logs were for the correct block, but if they weren't then they will never try to fetch again.  This creates a problem if the block was only transiently re-orged out because it may come back before the next block poll so the client will never witness the reorg.  They can assume the empty logs were for the wrong block, and refetch them, but they may continue to get empty results putting them right back into the same situation.
 
 By adding the ability to fetch logs by hash, the client can be guaranteed that if they get a result set, it is for the block in question.  If they get an error, then they can take appropriate action (e.g., rollback that block client-side and re-fetch latest).