Fix typos

lists/evm/opcode-blocks.md

@@ -1,9 +1,9 @@
 Opcode Blocks
 -------------
 
-| Prefix | Available | Propsoed | Name                            |
+| Prefix | Available | Proposed | Name                            |
 |--------|----------:|---------:|---------------------------------|
-| 0x0    |         3 |          | Aritmetic                       |
+| 0x0    |         3 |          | Arithmetic                      |
 | 0x1    |         2 |          | Comparison / Bitwise            |
 | 0x2    |        15 |          | Cryptography                    |
 | 0x3    |         0 |          | Environmental                   |

lists/evm/pending-opcodes.md

@@ -2,7 +2,7 @@ Opcodes under active consideration
 ----------------------------------
 
 This list includes opcodes under active consideration for adding to the
-next or subsuquent hard fork.
+next or subsequent hard fork.
 
 |  Opcode  | Name            | Description                                     | EIP                                                                          |
 |:--------:|-----------------|-------------------------------------------------|------------------------------------------------------------------------------|
@@ -12,7 +12,7 @@ next or subsuquent hard fork.
 |   0x5D   | TSTORE          | Transient data store                            | [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)                          |
 |   0x5E   | MCOPY           | Memory copy                                     | [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)                          |
 |   0xE0   | RJUMP           | relative jump                                   | [EIP-4200](https://eips.ethereum.org/EIPS/eip-4200)                          |
-|   0xE1   | RJUMPI           | relative conditional jump                       | [EIP-4200](https://eips.ethereum.org/EIPS/eip-4200)                          |
+|   0xE1   | RJUMPI          | relative conditional jump                       | [EIP-4200](https://eips.ethereum.org/EIPS/eip-4200)                          |
 |   0xE2   | RJUMV           | relative jump table                             | [EIP-4200](https://eips.ethereum.org/EIPS/eip-4200)                          |
 |   0xE3   | CALLF           | EOF Subroutine Call                             | [EIP-4750](https://eips.ethereum.org/EIPS/eip-4750)                          |
 |   0xE4   | RETF            | EOF Subroutine return                           | [EIP-4750](https://eips.ethereum.org/EIPS/eip-4750)                          |
@@ -26,12 +26,12 @@ next or subsuquent hard fork.
 |   0xEC   | CREATE3         | Create from EOF contained initcode              | TBD - [mega EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification) |
 |   0xED   | CREATE4         | Create from transaction contained initcode      | TBD - [mega EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification) |
 |   0xEE   | RETURNCONTRACT  | Contract to be created, references EOF data     | TBD - [mega EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification) |
-|   0xEF   | -               | Reserved for EOF compatability                  | TBD - [mega EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification) |
+|   0xEF   | -               | Reserved for EOF compatibility                  | TBD - [mega EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification) |
 |   0xF6   | PAY             | transfers value from caller to target           | [EIP-5920](https://eips.ethereum.org/EIPS/eip-5920)                          |
-|   0xF8   | CALL2           | CALL without gas and output memory              | [EIP-7069](https://eips.ethereum.org/EIPS/eip-7069)                          ||
+|   0xF8   | CALL2           | CALL without gas and output memory              | [EIP-7069](https://eips.ethereum.org/EIPS/eip-7069)                          |
 |   0xF9   | DELEGATECALL2   | DELEGATECALL without gas and output memory      | [EIP-7069](https://eips.ethereum.org/EIPS/eip-7069)                          |
 |   0xFB   | STATICCALL2     | STATICCALL without gas and output memory        | [EIP-7069](https://eips.ethereum.org/EIPS/eip-7069)                          |
-|   0xFC   | SETCODE         | Change the code for the current contract        | [EIP-6913](https://eips.ethereum.org/EIPS/eip-6913)                          |                                                                            |
+|   0xFC   | SETCODE         | Change the code for the current contract        | [EIP-6913](https://eips.ethereum.org/EIPS/eip-6913)                          |
 
 Pending Opcode Table
 --------------------
@@ -42,7 +42,7 @@ Existing Opcodes
 ----------------
 
 Current up to Shanghai. Opcodes not operation in mainnet (and are either
-scheduled or accepted) are in *itallics*.
+scheduled or accepted) are in *italics*.
 
 | Number | Name             | Execution spec category | Initial Release  | EIP                                                                            |
 |--------|------------------|-------------------------|------------------|--------------------------------------------------------------------------------|

network-upgrades/README.md

@@ -10,7 +10,7 @@ In an effort to separate this process from the EIP standardization process, thre
 
 **Considered for Inclusion**: Signals that client developers are generally positive towards the idea, and that, assuming it meets all the requirements for mainnet inclusion, it could potentially be included in a network upgrade. This means the EIP may be included in client integration testnets. It is similar to "concept ACK" in other open source projects, and is not sufficient to result in deployment to mainnet.
 
-**Client Integration Testnets**: Short-lived integration testnets which are stood up to test cross-client implementations of certain EIPs. This does not guarantee mainnet deployement, and for some EIPs with small or non-applicable changes, this step may be skipped.
+**Client Integration Testnets**: Short-lived integration testnets which are stood up to test cross-client implementations of certain EIPs. This does not guarantee mainnet deployment, and for some EIPs with small or non-applicable changes, this step may be skipped.
 
 **Mainnet**: Signals that client developers wish to include the EIP into an upgrade to the public Ethereum networks (i.e. testnets such as Goerli, Ropsten and Rinkeby and mainnet).
 
@@ -43,4 +43,4 @@ Note: by this point, your EIP should be in `Review` status.
 
 ### Deploying your EIP to Mainnet
 
-If client developers reach rough consensus to include your EIP in a network upgrade, it will be added to a spec under the `mainnet-upgardes` folder. When the upgrade spec gets finalized (i.e. the list of EIPs is final and blocks are selected), your EIP should be moved to the `Last Call` status. 
+If client developers reach rough consensus to include your EIP in a network upgrade, it will be added to a spec under the `mainnet-upgrades` folder. When the upgrade spec gets finalized (i.e. the list of EIPs is final and blocks are selected), your EIP should be moved to the `Last Call` status. 

network-upgrades/mainnet-upgrades/shanghai.md

@@ -18,7 +18,7 @@ Changes included in the Network Upgrade.
 | Goerli  | `1678832736` | 3/14/2023, 10:25:36 PM	 |  `0xf9843abf` | 162304 
 | Mainnet | `1681338455` | 4/12/2023, 10:27:35 PM |  `0xdce96c2d` | 194048 
 
-### Implementation Progresss
+### Implementation Progress
 
 Implementation status of Included & CFI'd EIPs across participating clients.
 

network-upgrades/retrospectives/london.md

@@ -85,7 +85,7 @@ July 22, 2021
 assert sender.balance >= gasLimit * transaction.max_fee_per_gas
 ```
 
-A few lines above (L207), though, `sender.balance` is modified to substract from it the transaction's amount (`sender.balance -= transaction.amount`). This led to confusion, as some client teams used the full `sender.balance` (i.e. pre-subtraction of `transaction.amount`) when checking the assertion defined on line 217, rather than the updated value. 
+A few lines above (L207), though, `sender.balance` is modified to subtract from it the transaction's amount (`sender.balance -= transaction.amount`). This led to confusion, as some client teams used the full `sender.balance` (i.e. pre-subtraction of `transaction.amount`) when checking the assertion defined on line 217, rather than the updated value. 
 
 One suggested fix is to move this assertion closer to when the `sender.balance` value is updated, similarly to the other assertion on line 208. 
 

src/ethereum/arrow_glacier/bloom.py

@@ -13,7 +13,7 @@
 general theory of bloom filters see e.g. `Wikipedia
 <https://en.wikipedia.org/wiki/Bloom_filter>`_. Bloom filters are used to allow
 for efficient searching of logs by address and/or topic, by rapidly
-eliminating blocks and reciepts from their search.
+eliminating blocks and receipts from their search.
 """
 
 from typing import Tuple

src/ethereum/arrow_glacier/fork.py

@@ -275,7 +275,7 @@ def validate_header(header: Header, parent_header: Header) -> None:
     quantities in the header should match the logic for the block itself.
     For example the header timestamp should be greater than the block's parent
     timestamp because the block was created *after* the parent block.
-    Additionally, the block's number should be directly folowing the parent
+    Additionally, the block's number should be directly following the parent
     block's number since it is the next block in the sequence.
 
     Parameters
@@ -622,7 +622,7 @@ def validate_ommers(
     To be considered valid, the ommers must adhere to the rules defined in
     the Ethereum protocol. The maximum amount of ommers is 2 per block and
     there cannot be duplicate ommers in a block. Many of the other ommer
-    contraints are listed in the in-line comments of this function.
+    constraints are listed in the in-line comments of this function.
 
     Parameters
     ----------

src/ethereum/arrow_glacier/vm/memory.py

@@ -59,7 +59,7 @@ def memory_read_bytes(
 
 def buffer_read(buffer: Bytes, start_position: U256, size: U256) -> Bytes:
     """
-    Read bytes from a buffer. Padding with zeros if neccesary.
+    Read bytes from a buffer. Padding with zeros if necessary.
 
     Parameters
     ----------

src/ethereum/arrow_glacier/vm/precompiled_contracts/modexp.py

@@ -22,7 +22,7 @@
 
 def modexp(evm: Evm) -> None:
     """
-    Calculates `(base**exp) % modulus` for arbitary sized `base`, `exp` and.
+    Calculates `(base**exp) % modulus` for arbitrary sized `base`, `exp` and.
     `modulus`. The return value is the same length as the modulus.
     """
     data = evm.message.data

src/ethereum/berlin/bloom.py

@@ -13,7 +13,7 @@
 general theory of bloom filters see e.g. `Wikipedia
 <https://en.wikipedia.org/wiki/Bloom_filter>`_. Bloom filters are used to allow
 for efficient searching of logs by address and/or topic, by rapidly
-eliminating blocks and reciepts from their search.
+eliminating blocks and receipts from their search.
 """
 
 from typing import Tuple

src/ethereum/berlin/fork.py

@@ -206,7 +206,7 @@ def validate_header(header: Header, parent_header: Header) -> None:
     quantities in the header should match the logic for the block itself.
     For example the header timestamp should be greater than the block's parent
     timestamp because the block was created *after* the parent block.
-    Additionally, the block's number should be directly folowing the parent
+    Additionally, the block's number should be directly following the parent
     block's number since it is the next block in the sequence.
 
     Parameters
@@ -519,7 +519,7 @@ def validate_ommers(
     To be considered valid, the ommers must adhere to the rules defined in
     the Ethereum protocol. The maximum amount of ommers is 2 per block and
     there cannot be duplicate ommers in a block. Many of the other ommer
-    contraints are listed in the in-line comments of this function.
+    constraints are listed in the in-line comments of this function.
 
     Parameters
     ----------

src/ethereum/berlin/vm/memory.py

@@ -59,7 +59,7 @@ def memory_read_bytes(
 
 def buffer_read(buffer: Bytes, start_position: U256, size: U256) -> Bytes:
     """
-    Read bytes from a buffer. Padding with zeros if neccesary.
+    Read bytes from a buffer. Padding with zeros if necessary.
 
     Parameters
     ----------

src/ethereum/berlin/vm/precompiled_contracts/modexp.py

@@ -22,7 +22,7 @@
 
 def modexp(evm: Evm) -> None:
     """
-    Calculates `(base**exp) % modulus` for arbitary sized `base`, `exp` and.
+    Calculates `(base**exp) % modulus` for arbitrary sized `base`, `exp` and.
     `modulus`. The return value is the same length as the modulus.
     """
     data = evm.message.data

src/ethereum/byzantium/bloom.py

@@ -13,7 +13,7 @@
 general theory of bloom filters see e.g. `Wikipedia
 <https://en.wikipedia.org/wiki/Bloom_filter>`_. Bloom filters are used to allow
 for efficient searching of logs by address and/or topic, by rapidly
-eliminating blocks and reciepts from their search.
+eliminating blocks and receipts from their search.
 """
 
 from typing import Tuple

src/ethereum/byzantium/fork.py

@@ -200,7 +200,7 @@ def validate_header(header: Header, parent_header: Header) -> None:
     quantities in the header should match the logic for the block itself.
     For example the header timestamp should be greater than the block's parent
     timestamp because the block was created *after* the parent block.
-    Additionally, the block's number should be directly folowing the parent
+    Additionally, the block's number should be directly following the parent
     block's number since it is the next block in the sequence.
 
     Parameters
@@ -507,7 +507,7 @@ def validate_ommers(
     To be considered valid, the ommers must adhere to the rules defined in
     the Ethereum protocol. The maximum amount of ommers is 2 per block and
     there cannot be duplicate ommers in a block. Many of the other ommer
-    contraints are listed in the in-line comments of this function.
+    constraints are listed in the in-line comments of this function.
 
     Parameters
     ----------

src/ethereum/byzantium/vm/memory.py

@@ -59,7 +59,7 @@ def memory_read_bytes(
 
 def buffer_read(buffer: Bytes, start_position: U256, size: U256) -> Bytes:
     """
-    Read bytes from a buffer. Padding with zeros if neccesary.
+    Read bytes from a buffer. Padding with zeros if necessary.
 
     Parameters
     ----------

src/ethereum/byzantium/vm/precompiled_contracts/modexp.py

@@ -22,7 +22,7 @@
 
 def modexp(evm: Evm) -> None:
     """
-    Calculates `(base**exp) % modulus` for arbitary sized `base`, `exp` and.
+    Calculates `(base**exp) % modulus` for arbitrary sized `base`, `exp` and.
     `modulus`. The return value is the same length as the modulus.
     """
     data = evm.message.data

src/ethereum/constantinople/bloom.py

@@ -13,7 +13,7 @@
 general theory of bloom filters see e.g. `Wikipedia
 <https://en.wikipedia.org/wiki/Bloom_filter>`_. Bloom filters are used to allow
 for efficient searching of logs by address and/or topic, by rapidly
-eliminating blocks and reciepts from their search.
+eliminating blocks and receipts from their search.
 """
 
 from typing import Tuple

src/ethereum/constantinople/fork.py

@@ -200,7 +200,7 @@ def validate_header(header: Header, parent_header: Header) -> None:
     quantities in the header should match the logic for the block itself.
     For example the header timestamp should be greater than the block's parent
     timestamp because the block was created *after* the parent block.
-    Additionally, the block's number should be directly folowing the parent
+    Additionally, the block's number should be directly following the parent
     block's number since it is the next block in the sequence.
 
     Parameters
@@ -507,7 +507,7 @@ def validate_ommers(
     To be considered valid, the ommers must adhere to the rules defined in
     the Ethereum protocol. The maximum amount of ommers is 2 per block and
     there cannot be duplicate ommers in a block. Many of the other ommer
-    contraints are listed in the in-line comments of this function.
+    constraints are listed in the in-line comments of this function.
 
     Parameters
     ----------

src/ethereum/constantinople/vm/memory.py

@@ -59,7 +59,7 @@ def memory_read_bytes(
 
 def buffer_read(buffer: Bytes, start_position: U256, size: U256) -> Bytes:
     """
-    Read bytes from a buffer. Padding with zeros if neccesary.
+    Read bytes from a buffer. Padding with zeros if necessary.
 
     Parameters
     ----------

src/ethereum/constantinople/vm/precompiled_contracts/modexp.py

@@ -22,7 +22,7 @@
 
 def modexp(evm: Evm) -> None:
     """
-    Calculates `(base**exp) % modulus` for arbitary sized `base`, `exp` and.
+    Calculates `(base**exp) % modulus` for arbitrary sized `base`, `exp` and.
     `modulus`. The return value is the same length as the modulus.
     """
     data = evm.message.data

src/ethereum/crypto/finite_field.py

@@ -317,7 +317,7 @@ def deg(self: U) -> int:
 
     def multiplicative_inverse(self: U) -> U:
         """
-        Calculate the multiplicative inverse. Uses the Euclidian algorithm.
+        Calculate the multiplicative inverse. Uses the Euclidean algorithm.
         """
         x2: List[int]
         p = self.PRIME

src/ethereum/dao_fork/bloom.py

@@ -13,7 +13,7 @@
 general theory of bloom filters see e.g. `Wikipedia
 <https://en.wikipedia.org/wiki/Bloom_filter>`_. Bloom filters are used to allow
 for efficient searching of logs by address and/or topic, by rapidly
-eliminating blocks and reciepts from their search.
+eliminating blocks and receipts from their search.
 """
 
 from typing import Tuple

src/ethereum/dao_fork/fork.py

@@ -82,7 +82,7 @@ def apply_fork(old: BlockChain) -> BlockChain:
     When forks need to implement an irregular state transition, this function
     is used to handle the irregularity.
 
-    The DAO-Fork occured as a result of the `2016 DAO Hacks
+    The DAO-Fork occurred as a result of the `2016 DAO Hacks
     <https://www.gemini.com/cryptopedia/the-dao-hack-makerdao>`_ in which an
     unknown entity managed to drain more than 3.6 million ether causing the
     price of ether to drop by nearly 35%. This fork was the solution to the
@@ -207,7 +207,7 @@ def validate_header(header: Header, parent_header: Header) -> None:
     quantities in the header should match the logic for the block itself.
     For example the header timestamp should be greater than the block's parent
     timestamp because the block was created *after* the parent block.
-    Additionally, the block's number should be directly folowing the parent
+    Additionally, the block's number should be directly following the parent
     block's number since it is the next block in the sequence.
 
     Parameters
@@ -512,7 +512,7 @@ def validate_ommers(
     To be considered valid, the ommers must adhere to the rules defined in
     the Ethereum protocol. The maximum amount of ommers is 2 per block and
     there cannot be duplicate ommers in a block. Many of the other ommer
-    contraints are listed in the in-line comments of this function.
+    constraints are listed in the in-line comments of this function.
 
     Parameters
     ----------

src/ethereum/dao_fork/vm/memory.py

@@ -59,7 +59,7 @@ def memory_read_bytes(
 
 def buffer_read(buffer: Bytes, start_position: U256, size: U256) -> Bytes:
     """
-    Read bytes from a buffer. Padding with zeros if neccesary.
+    Read bytes from a buffer. Padding with zeros if necessary.
 
     Parameters
     ----------

src/ethereum/frontier/bloom.py

@@ -13,7 +13,7 @@
 general theory of bloom filters see e.g. `Wikipedia
 <https://en.wikipedia.org/wiki/Bloom_filter>`_. Bloom filters are used to allow
 for efficient searching of logs by address and/or topic, by rapidly
-eliminating blocks and reciepts from their search.
+eliminating blocks and receipts from their search.
 """
 
 from typing import Tuple

src/ethereum/frontier/fork.py

@@ -194,7 +194,7 @@ def validate_header(header: Header, parent_header: Header) -> None:
     quantities in the header should match the logic for the block itself.
     For example the header timestamp should be greater than the block's parent
     timestamp because the block was created *after* the parent block.
-    Additionally, the block's number should be directly folowing the parent
+    Additionally, the block's number should be directly following the parent
     block's number since it is the next block in the sequence.
 
     Parameters
@@ -493,7 +493,7 @@ def validate_ommers(
     To be considered valid, the ommers must adhere to the rules defined in
     the Ethereum protocol. The maximum amount of ommers is 2 per block and
     there cannot be duplicate ommers in a block. Many of the other ommer
-    contraints are listed in the in-line comments of this function.
+    constraints are listed in the in-line comments of this function.
 
     Parameters
     ----------

src/ethereum/frontier/vm/memory.py

@@ -59,7 +59,7 @@ def memory_read_bytes(
 
 def buffer_read(buffer: Bytes, start_position: U256, size: U256) -> Bytes:
     """
-    Read bytes from a buffer. Padding with zeros if neccesary.
+    Read bytes from a buffer. Padding with zeros if necessary.
 
     Parameters
     ----------