Update EIP-8052: Fix grammar and spelling errors in EIP-8052, 8061, 8068, 8077

EIPS/eip-8052.md

@@ -33,7 +33,7 @@
 Integrating post-quantum signature schemes is crucial to future-proof Ethereum and other EVM-based environments. It shall be noted that infrastructure for post-quantum signatures should be deployed *before* quantum adversaries are known to be practical because it takes on the order of years for existing applications to integrate.
 
 Falcon, a lattice-based scheme standardized by NIST, offers high security against both classical and quantum adversaries. Its compact signature size (~666 bytes for Falcon-512) and its efficient verification algorithm make it well-suited for blockchain applications, where gas usage and transaction throughput are critical considerations.
 <!-- When the public key is also stored together with the signature, it leads to 666 + 897 = 1563 bytes.
 Using the recovery mode, it can be reduced to 1292 + 32 = 1324 bytes. -->
 <!--
 For Falcon,
@@ -346,7 +346,7 @@
 * Verify that the salt in the signature is 40-bytes long.
 
 **Gas burning on error**
-if one of the above condition is not met then all the gas supplied along with a CALL or STATICCALL is burned.
+if one of the above conditions is not met then all the gas supplied along with a CALL or STATICCALL is burned.
 it shall also be burned if an error happens during decompression (incorrect encodings).
 
 

EIPS/eip-8061.md

@@ -99,7 +99,7 @@ def compute_weak_subjectivity_period(state: BeaconState) -> uint64:
 
 ### Deposit processing
 
-The only modification is replacing `get_activation_exit_churn_limit` with `get_activation_churn_limit`, maintaing the current cap on deposit churn respects, while removing the cap from exits. This reverts to the pre-Electra status quo, when activations were capped but exits were not.
+The only modification is replacing `get_activation_exit_churn_limit` with `get_activation_churn_limit`, maintaining the current cap on deposit churn respects, while removing the cap from exits. This reverts to the pre-Electra status quo, when activations were capped but exits were not.
 
 ```python
 def process_pending_deposits(state: BeaconState) -> None:

EIPS/eip-8068.md

@@ -128,7 +128,7 @@ The blue line is compounding `0x02` validators, which on average will have 0.75
 
 The red lines capture `0x02` validators that repeatedly withdraw down to the downward hysteresis threshold at $-0.25$ relative to an integer EB, thus achieving a surplus 0.25 EB relative to their actual balance. They let the balance grow until it is optimal to withdraw it, accounting for a partial withdrawal costing 84500 gas. So for example, starting at 32.75 ETH and with a 0.5 gwei base fee, that works out to making the withdrawal at around 32.80 ETH. The staker then earns 0.56% more staking yield than the baseline, factoring in a 4.5 days delay between when the withdrawn ETH stops earning yield and when it is available at the EL (dashed red line). This delay accounts for a 256 epoch withdrawal eligibility period and an average wait time until the sweep hits of 3.4 days (at a hypothetical future 770 000 active validators). Without the delay, that figure is 0.60%. When the base is 0 and there is a 4.5 days delay, the validator instead earns 0.72% more staking yield (full red line).
 
-The green circles are sweeped `0x01` validators. They earn slightly less than the baseline due to the accruing balance in excess of 32 ETH and 2048 ETH not counting toward the EB, and being delayed by around 3.4 days.  (in this specific example where the delay )
+The green circles are swept `0x01` validators. They earn slightly less than the baseline due to the accruing balance in excess of 32 ETH and 2048 ETH not counting toward the EB, and being delayed by around 3.4 days.  (in this specific example where the delay )
 
 This comparison could be nuanced further by potentially accounting for a deposit delay, but the ETH does not necessarily need to be deposited directly into the staking contract to bring value to its holder. Another nuance is that a slashing is driven by EB and not validator balance.
 

EIPS/eip-8077.md

@@ -44,7 +44,7 @@ At the receiver side of `NewPooledTransactionHashes` messages the extra informat
 
 ## Rationale
 
-To solve the transaction propagation issues mentioned in the Motivation section, nodes require more information about a transaction then its hash, size, and type. By adding the source and the nonce, the receiver has enough information to make better fetch decisions.
+To solve the transaction propagation issues mentioned in the Motivation section, nodes require more information about a transaction than its hash, size, and type. By adding the source and the nonce, the receiver has enough information to make better fetch decisions.
 
 ### Overhead