Update EIP-3690: typo fix

EIPS/eip-3690.md

@@ -33,18 +33,18 @@
 
 ### EOF container changes
 
 1. A new EOF section called `jumpdests` (`section_kind = 3`) is introduced. It contains a sequence of *n* unsigned integers *jumploc<sub>i</sub>*.
 2. The *jumploc<sub>i</sub>* values are encoded with [unsigned LEB128](https://en.wikipedia.org/wiki/LEB128#Unsigned_LEB128).
 
    | description         | encoding        |
    |---------------------|-----------------|
    | jumploc<sub>0</sub> | unsigned LEB128 |
    | jumploc<sub>1</sub> | unsigned LEB128 |
    | ...                 |                 |
    | jumploc<sub>n</sub> | unsigned LEB128 |
 
 3. The jump destinations represent the set of valid code positions as arguments to jump instructions. They are delta-encoded therefore partial sum must be performed to retrieve the absolute offsets.
    ```python
    def jumpdest(n: int, jumpdests_table: list[int]) -> int:
        return sum(jumpdests_table[:n+1])
    ```
@@ -68,7 +68,7 @@
 
 ### Jumpdests section is bounded
 
-The length of the `jumpdests` section is bounded by the EOF maximum section size value 0xffff. Moreover, for deployed code this additionally limited by the max bytecode size 0x6000. Then any valid `jumpdests` section may not be more larger than 0x3000.
+The length of the `jumpdests` section is bounded by the EOF maximum section size value 0xffff. Moreover, for deployed code this is additionally limited by the max bytecode size 0x6000. Then any valid `jumpdests` section may not be larger than 0x3000.
 
 ### Delta encoding
 
@@ -87,7 +87,7 @@
 This is another option for encoding inspired by UTF-8. The benefit is that the number of following bytes is encoded in the first byte (the top two bits), so the expected length is known upfront.
 
 A simple decoder is the following:
 ```python
 def decode(input: bytes) -> int:
     size_prefix = input[0] >> 6
     if size_prefix == 0:
@@ -128,21 +128,21 @@
 | ----------------- | ----- | ----- | ---- | ---- | ------- |
 | worst             | 65535 | 65535 | 9.11 | 9.36 |   2.75% |
 | RoninBridge       |  1760 |    71 | 3.57 |      | -89.41% |
 | UniswapV2ERC20    |  2319 |    61 | 2.10 |      | -88.28% |
 | DepositContract   |  6358 |   123 | 1.86 |      | -90.24% |
 | TetherToken       | 11075 |   236 | 1.91 |      | -89.58% |
 | UniswapV2Router02 | 21943 |   468 | 2.26 |      | -91.17% |
 
 For the worst case the performance difference between JUMPDEST analysis and jumpdests section loading is very small. The performance very slow compared to memory copy (0.15 cycles/byte).
 
 However, the maximum length for the worst cases is different. For JUMPDEST analysis this is 24576 (0x6000) for deployed contracts and only limited by EVM memory cost in case of _initcode_ (can be over 1MB). For jumpdests sections, the limit is 12288 for deployed contracts (the deployed bytecode length limit must be split equally between jumpdests and code sections). For _initcode_ case, the limit is 65535 because this is the maximum section size allowed by EOF.
 
 For "popular" contracts the gained efficiency is ~10x because the jumpdests section is relatively small compared to the code section and therefore there is much less bytes to loop over than in JUMPDEST analysis.
 
 ## Reference Implementation
 
 We extend the `validate_code()` function of [EIP-3670](./eip-3670.md):
 ```python
 # The same table as in EIP-3670
 valid_opcodes = ...
 
@@ -223,7 +223,7 @@
     assert(len(jumpdests) == 0)
 ```
 
 ## Test Cases
 
 #### Valid bytecodes
 

EIPS/eip-7705.md

@@ -16,7 +16,7 @@ Add two opcodes, `NONREENTRANT` and `REENTRANT`, which set and clear a contract'
 
 ## Motivation
 
-Reentrancy attacks account for a substantial portion of user funds stolen on EVM chains, including the famous "DAO hack". However, due to the cost of preventing against reentrancy attacks in application code, developers often opt-out of reentrancy protection. This cost has come down with the advent of transient storage ([EIP-1153](./eip-1153.md)), but it is still not cheap enough where it is a "no-brainer" to use it by default. This EIP proposes opcodes which make it cheaper to protect against reentrancy in application code.
+Reentrancy attacks account for a substantial portion of user funds stolen on EVM chains, including the famous "DAO hack". However, due to the cost of preventing reentrancy attacks in application code, developers often opt-out of reentrancy protection. This cost has come down with the advent of transient storage ([EIP-1153](./eip-1153.md)), but it is still not cheap enough where it is a "no-brainer" to use it by default. This EIP proposes opcodes which make it cheaper to protect against reentrancy in application code.
 
 ## Specification