Update EIP-7549: Various spelling fixes of EIP 7549

EIPS/eip-7549.md

@@ -18,7 +18,7 @@ Move the committee `index` field outside of the signed Attestation message to al
 
 This proposal aims to make Casper FFG clients more efficient by reducing the average number of pairings needed to verify consensus rules. While all types of clients can benefit from this EIP, ZK circuits proving Casper FFG consensus are likely to have the most impact.
 
-On a beacon chain network with at least 262144 active indexes it's necessary to verify a minimum of `ceil(32*64 * 2/3) = 1366` attestations to reach a 2/3 threshold. Participants cast two votes at once: LMD GHOST vote and Casper-FFG vote. However, the Attestation message contains three elements:
+On a beacon chain network with at least 262144 active indices, it's necessary to verify a minimum of `ceil(32*64 * 2/3) = 1366` attestations to reach a 2/3 threshold. Participants cast two votes at once: LMD GHOST vote and Casper-FFG vote. However, the Attestation message contains three elements:
 
 1. LMD GHOST vote `(beacon_block_root, slot)`. Note: includes slot in the event (block, slot) voting is adopted.
 2. FFG vote `(source, target)`
@@ -36,8 +36,8 @@ This requires no changes to the Execution Layer.
 
 ### Consensus layer
 
-- Set `index` field from `AttestationData` to fixed value of zero
-- Move committee indexing data to the outter `Attestation` container with `committee_bits`
+- Set `index` field from `AttestationData` to a fixed value of zero
+- Move committee indexing data to the outer `Attestation` container with `committee_bits`
 - Increase the capacity of `aggregation_bits` to all committees in a slot
 
 The full specification of the proposed change can be found in [`/specs/electra/beacon-chain.md`](https://github.com/ethereum/consensus-specs/blob/2c1f677187e6534aec77057a7d1cc746a40d3630/specs/electra/beacon-chain.md).
@@ -49,28 +49,28 @@ The full specification of the proposed change can be found in [`/specs/electra/b
 The `index` field in `AttestationData` can be deprecated by:
 
 1. Removing the field 
-2. Preserving the field and setting it to be zero
+2. Preserving the field and setting it to zero
 3. Changing the field type to Optional (from [EIP-7495](./eip-7495.md) StableContainer)
 
 This EIP chooses the second option to not complicate the inclusion of `AttesterSlashing` objects. While the `Attestation` container changes, `AttesterSlashing` includes indexed attestations without committee data.
 
 ### `MAX_ATTESTATIONS` value
 
-The maximum size of an attestation increases, with a bitfield 64 times larger on networks with maxed committees. `MAX_ATTESTATIONS` value is reduced to limit the beacon block size while still increase the total capacity of votes. A value of 8 increase the vote capacity by 4 while having the same attestation space size with a network of 1.2M active indices.
+The maximum size of an attestation increases, with a bitfield 64 times larger on networks with maxed committees. `MAX_ATTESTATIONS` value is reduced to limit the beacon block size while still increasing the total capacity of votes. A value of 8 increases the voting capacity by 4 while having the same attestation space size with a network of 1.2M active indices.
 
 ### `MAX_ATTESTER_SLASHINGS` value
 
-On-chain `AttesterSlashing` includes a list of indices of all participants. With this EIP the worst-case size increases by 64 times, resulting in an uncompressed size of 488 KB per `AttesterSlashing` in a network of 1M validators. Snappy compression reduces it to 320 KB, which is still significant. To bound the maximum size of block this proposal reduces `MAX_ATTESTER_SLASHINGS` from 2 to 1, the minimum value.
+On-chain `AttesterSlashing` includes a list of participants' indices. With this EIP the worst-case size increases by 64 times, resulting in an uncompressed size of 488 KB per `AttesterSlashing` in a network of 1M validators. Snappy compression reduces it to 320 KB, which is still significant. To bound the maximum size of the block this proposal reduces `MAX_ATTESTER_SLASHINGS` from 2 to 1, the minimum value.
 
 ## Backwards Compatibility
 
 This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.
 
 ## Security Considerations
 
-### First block after fork
+### First block after the fork
 
-Because the on chain `Attestation` container changes, attestations from the prior fork can't be included into post-electra blocks. Therefore the first block after the fork may have zero attestations. LMD votes can still be applied to fork-choice via on_attestation handler, so there will be only a 1/32 loss of FFG votes. Attesters assigned to the last slot of the fork will incur one epoch worth of offline penalties. One possible mitigation is to change the electra block body type to allow including attestations from both forks. However, the mitigation increases complexity for little gain so this proposal choses to not address the issue.
+Because the on-chain `Attestation` container changes, attestations from the prior fork can't be included in post-electra blocks. Therefore the first block after the fork may have zero attestations. LMD votes can still be applied to fork-choice via `on_attestation` handler, so there will be only a 1/32 loss of FFG votes. Attesters assigned to the last slot of the fork will incur one epoch worth of offline penalties. One possible mitigation is to change the Electra block body type to allow including attestations from both forks. However, the mitigation increases complexity for little gain so this proposal chooses to not address the issue.
 
 ### Mutation over gossip