Update EIP-1485: Fix typographical errors in Documentation (#9186)

* typo eip-1485.md

* typo eip-158.md

* typo eip-1884.md

* typo eip-1959.md

* typo eip-2294.md

* typo eip-234.md

* typo eip-2474.md

* typo eip-747.md

* typo eip-7808.md

* Update EIPS/eip-234.md

Co-authored-by: g11tech <[email protected]>

---------

Co-authored-by: Sam Wilson <[email protected]>
Co-authored-by: g11tech <[email protected]>

Author: 3 people

EIPS/eip-1485.md

@@ -71,7 +71,7 @@ Provide original Ethash proof of work verification with minimal set of changes b
 
 Previous proposed algorithm based on FNV1 [EIP-1355](./eip-1355.md)
 
-There's a implementation that looks like "Missing Offset Bias" at **FNV1A**.
+There's an implementation that looks like "Missing Offset Bias" at **FNV1A**.
 
 Quotation of [original algorithm FNV1A](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-1a_hash)
 ```

EIPS/eip-158.md

@@ -12,7 +12,7 @@ created: 2016-10-16
 
 For all blocks where `block.number >= FORK_BLKNUM` (TBA):
 1. In all cases where a state change is made to an account, and this state change results in the account state being saved with nonce = 0, balance = 0, code empty, storage empty (hereinafter "empty account"), the account is instead deleted.
-2. If a address is "touched" and that address contains an empty account, then it is deleted. A "touch" is defined as any situation where if the account at the given address were nonexistent it would be created.
+2. If an address is "touched" and that address contains an empty account, then it is deleted. A "touch" is defined as any situation where if the account at the given address were nonexistent it would be created.
 3. Whenever the EVM checks if an account exists, emptiness is treated as equivalent to nonexistence. Particularly, note that this implies that, once this change is enabled, there is no longer a meaningful difference between emptiness and nonexistence from the point of view of EVM execution.
 4. Zero-value calls and zero-value suicides no longer consume the 25000 account creation gas cost in any circumstance
 

EIPS/eip-1884.md

@@ -82,7 +82,7 @@ state clearing efforts are implemented before that happens.
 It is comparable to `EXTCODESIZE` and `EXTCODEHASH`, which are priced at `700` already. 
 
 It has a built-in high variance, since it is often used for checking the balance of `this`, 
-which is a inherently cheap operation, however, it can be used to lookup the balance of arbitrary account which often require trie (disk) access. 
+which is an inherently cheap operation, however, it can be used to lookup the balance of arbitrary account which often require trie (disk) access. 
 
 In hindsight, it might have been a better choice to have two 
 opcodes: `EXTBALANCE(address)` and `SELFBALANCE`, and have two different prices. 

EIPS/eip-1959.md

@@ -38,7 +38,7 @@ The approach proposed by EIP-1344 is to give access to the latest chainID. This
 
 That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract. 
 
-While this works (except for a temporary gap where the immediately previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before an hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs.
+While this works (except for a temporary gap where the immediately previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before a hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs.
 
 Indeed letting contracts access the latest chainID for L2 message verification is dangerous. The latest chainID is only the tip of the chainID history. As a changing value, the latest chainID is thus not appropriate to ensure the validity of L2 messages.
 
@@ -76,4 +76,4 @@ Similarly to EIP-1344, it might be beneficial to update EIP-712 (still in Draft)
 This was previously suggested as part of [EIP-1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/39).
 
 ## Copyright
-Copyright and related rights waived via [CC0](../LICENSE.md).
+Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-2294.md

@@ -50,7 +50,7 @@ all cases.
 
 This EIP introduces a change that affects previous implementations of this feature. However, as of time of writing(2022-10-18) no known chain makes use of a value outside of the suggested bounds, there should not be an issue in adopting this limit on the size of this parameter, therefore the impact should be non-existent.
 
-If any other chain is operating with a incompatible `chainId`, we advised they make proper arrangement when this EIP becomes adopted.
+If any other chain is operating with an incompatible `chainId`, we advised they make proper arrangement when this EIP becomes adopted.
 
 ## Security Considerations
 

EIPS/eip-234.md

@@ -28,7 +28,7 @@ A client (dApp) who needs reliable notification of both log additions (on new bl
 
 In order to deal with this while still providing a robust mechanism for internal block/log additional/removal, the client can maintain a blockchain internally (last `n` blocks) and only subscribe/poll for new blocks.  When a new block is received, the client can reconcile their internal model with the new block, potentially back-filling parents or rolling back/removing blocks from their internal model to get in sync with the node.  This can account for any type of disconnect/reorg/outage scenario and also allows the client (as an added benefit) to talk to a cluster of Ethereum nodes (e.g., via round-robin) rather than being tightly coupled to a single node.
 
-Once the user has a reliable stream of blocks, they can then look at the bloom filter for the new block and if the block *may* have logs of interest they can fetch the filtered logs for that block from the node.  The problem that arises is that a re-org may occur between when the client receives the block and when the client fetches the logs for that block.  Given the current set of filter options, the client can only ask for logs by block number.  In this scenario, the logs they get back will be for a block that *isn't* the block they want the logs for and is instead for a block that was re-orged in (and may not be fully reconciled with the internal client state).  This can be partially worked around by looking at the resulting logs themselves and identifying whether or not they are for the block hash requested.  However, if the result set is an empty array (no logs fetched) then the client is in a situation where they don't know what block the results are for.  The results could have been legitimately empty (bloom filter can yield false positives) for the block in question, or they could be receiving empty logs for a block that they don't know about.  At this point, there is no decision the client can make that allows them a guarantee of recovery.  They can assume the empty logs were for the correct block, but if they weren't then they will never try to fetch again.  This creates a problem if the block was only transiently re-orged out because it may come back before the next block poll so the client will never witness the reorg.  They can assume the empty logs were for the wrong block, an refetch them, but they may continue to get empty results putting them right back into the same situation.
+Once the user has a reliable stream of blocks, they can then look at the bloom filter for the new block and if the block *may* have logs of interest they can fetch the filtered logs for that block from the node.  The problem that arises is that a re-org may occur between when the client receives the block and when the client fetches the logs for that block.  Given the current set of filter options, the client can only ask for logs by block number.  In this scenario, the logs they get back will be for a block that *isn't* the block they want the logs for and is instead for a block that was re-orged in (and may not be fully reconciled with the internal client state).  This can be partially worked around by looking at the resulting logs themselves and identifying whether or not they are for the block hash requested.  However, if the result set is an empty array (no logs fetched) then the client is in a situation where they don't know what block the results are for.  The results could have been legitimately empty (bloom filter can yield false positives) for the block in question, or they could be receiving empty logs for a block that they don't know about.  At this point, there is no decision the client can make that allows them a guarantee of recovery.  They can assume the empty logs were for the correct block, but if they weren't then they will never try to fetch again.  This creates a problem if the block was only transiently re-orged out because it may come back before the next block poll so the client will never witness the reorg.  They can assume the empty logs were for the wrong block, and refetch them, but they may continue to get empty results putting them right back into the same situation.
 
 By adding the ability to fetch logs by hash, the client can be guaranteed that if they get a result set, it is for the block in question.  If they get an error, then they can take appropriate action (e.g., rollback that block client-side and re-fetch latest).
 

EIPS/eip-2474.md

@@ -17,7 +17,7 @@ Allow contracts to be called directly by `block.coinbase` (block validator), wit
 
 _In proof-of-work blockchains, validators are known as miners._
 
-The validator might want to execute functions directly, without having to sign a transaction. Some examples might be presenting a proof in a contract for an change which also benefits the validator. 
+The validator might want to execute functions directly, without having to sign a transaction. Some examples might be presenting a proof in a contract for a change which also benefits the validator. 
 
 A notable example would be when a validator want to act as an [EIP-1077](./eip-1077.md) Gas Relayer, incentivized to pick up fees from meta transactions.
 Without this change, they can do so by signing from any address a `gasPrice = 0` transaction with the gas relayed call. 

EIPS/eip-747.md

@@ -106,7 +106,7 @@ Displaying a user's assets is a basic feature that every modern DApp user expect
 
 Automatically listing assets makes assets into a sort of spam mail: Users suddenly see new assets that they don't care about in their wallet. This can be used to send unsolicited information, or even to conduct phishing scams. This phenomenon is already common with airdropped tokens, a major cause of network congestion, because spamming people with new tokens has, so far, been rewarded with increased user attention.
 
-When a user is manually adding a asset, they had likely previously learned about it from a website. At that moment, there was a natural alignment of interests, where both parties wanted the user to track the token. This is a natural point to introduce an API to easily allow these parties to collaborate.
+When a user is manually adding an asset, they had likely previously learned about it from a website. At that moment, there was a natural alignment of interests, where both parties wanted the user to track the token. This is a natural point to introduce an API to easily allow these parties to collaborate.
 
 ## Security Considerations
 

EIPS/eip-7808.md

@@ -16,7 +16,7 @@ This EIP reserves a [transaction-type](./eip-2718.md) range for use by the Rollu
 
 ## Motivation
 
-For L2s to use new transactrion types, it is necessary to reserve an transaction-type range for use by the RIP process so as to ensure there are no conflicts between transaction types used by RIPs and EIPs.
+For L2s to use new transactrion types, it is necessary to reserve a transaction-type range for use by the RIP process so as to ensure there are no conflicts between transaction types used by RIPs and EIPs.
 
 ## Specification