update mempool issues section

EIPS/eip-4844.md

@@ -450,17 +450,12 @@ instead, they go into the `BeaconBlockBody`. This means that there is now a part
 
 ### Mempool issues
 
-Blob transactions are unique in that they have a variable intrinsic gas cost. Hence, a transaction that could be included in one block may be invalid for the next.
-To prevent mempool attacks, we recommend a simple technique: only propagate transactions whose `gas` is at least twice the current minimum.
-
-Additionally, blob transactions have a large data size at the mempool layer, which poses a mempool DoS risk,
+Blob transactions have a large data size at the mempool layer, which poses a mempool DoS risk,
 though not an unprecedented one as this also applies to transactions with large amounts of calldata.
-The risk is that an attacker makes and publishes a series of large blob transactions with fees `f9 > f8 > ... > f1`,
-where each fee is the 10% minimum increment higher than the previous, and finishes it off with a 21000-gas basic transaction with fee `f10`.
-Hence, an attacker could impose millions of gas worth of load on the network and only pay 21000 gas worth of fees.
 
-We recommend a simple solution: both for blob transactions and for transactions carrying a large amount of calldata,
-increase the minimum increment for mempool replacement from 1.1x to 2x, decreasing the number of resubmissions an attacker can do at any given fee level by ~7x.
+We recommend two solutions:
+- include a 1.1x (or potentially higher) data gasprice bump requirement to the mempool replacement rules
+- modify the Ethereum Wire Protocol to stop automatically broadcasting large transactions
 
 ## Test Cases