Update EIP-3670: Improve wording

Merged by EIP-Bot.

EIPS/eip-3670.md

@@ -25,9 +25,7 @@ validity into consensus, so that it becomes easier to reason about bytecode.
 Moreover, EVM implementations may require fewer paths to decide which instruction is valid in
 the current execution context.
 
-If it will be desired to introduce new instructions without bumping EOF version, having undefined
-instructions already deployed would mean such contracts potentially can be broken (since some
-instructions are changing their behaviour). Rejecting to deploy undefined instructions allows
+If there's a desire to introduce new instructions without bumping the EOF version, having undefined instructions already deployed could potentially break such contracts, as some instructions might change their behavior. Rejecting to deploy undefined instructions allows
 introducing new instructions with or without bumping the EOF version.
 
 ### EOF1 forward compatibility
@@ -42,7 +40,7 @@ The EOF1 format provides following forward compatibility properties:
 
 *Remark:* We rely on the notation of *initcode*, *code* and *creation* as defined by [EIP-3540](./eip-3540.md).
 
-This feature is introduced on the very same block EIP-3540 is enabled, therefore every EOF1-compatible bytecode MUST be validated according to these rules.
+This feature is introduced on the same block EIP-3540 is enabled, therefore every EOF1-compatible bytecode MUST be validated according to these rules.
 
 1. Previously deprecated instructions `CALLCODE` (0xf2) and `SELFDESTRUCT` (0xff) are invalid and their opcodes are undefined.
 2. At contract creation time *instructions validation* is performed on both *initcode* and *code*. The code is invalid if any of the checks below fails. For each instruction: