From a6070058f60be4f5f9fcffcd3bd1e97767046ee0 Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:12:25 +0100 Subject: [PATCH 1/9] typo eip-1485.md --- EIPS/eip-1485.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1485.md b/EIPS/eip-1485.md index 724623bcb9402d..ae8f0500595801 100644 --- a/EIPS/eip-1485.md +++ b/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) ``` From 35d55f194ed7bb145f92ce24aae50038a47fc94f Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:13:03 +0100 Subject: [PATCH 2/9] typo eip-158.md --- EIPS/eip-158.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-158.md b/EIPS/eip-158.md index 905e1d368f4c88..8267ce6361eded 100644 --- a/EIPS/eip-158.md +++ b/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 From 74bec303e95106cab9bbdb2be37b8c67faf0c55a Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:13:59 +0100 Subject: [PATCH 3/9] typo eip-1884.md --- EIPS/eip-1884.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1884.md b/EIPS/eip-1884.md index 3698c203becf8c..e085625dc199b9 100644 --- a/EIPS/eip-1884.md +++ b/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. From be1ea7860f61f770962ac5d7114ea116d784371b Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:14:30 +0100 Subject: [PATCH 4/9] typo eip-1959.md --- EIPS/eip-1959.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index bf6d5b29100789..5bec07770af010 100644 --- a/EIPS/eip-1959.md +++ b/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). \ No newline at end of file +Copyright and related rights waived via [CC0](../LICENSE.md). From fbc99b315f177af69c58b16addccf5d88e4b6e52 Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:15:27 +0100 Subject: [PATCH 5/9] typo eip-2294.md --- EIPS/eip-2294.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index 2b4cf5a11218b4..e13f5eb2fafbfa 100644 --- a/EIPS/eip-2294.md +++ b/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 From 5aa9d3543d94e07072330a9e182d10e946225f45 Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:15:57 +0100 Subject: [PATCH 6/9] typo eip-234.md --- EIPS/eip-234.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-234.md b/EIPS/eip-234.md index 5cd5a0ff3ab73b..ae8dde3607c514 100644 --- a/EIPS/eip-234.md +++ b/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, a 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). From da17c826e4803e1e99e1c221ddcd6f53aca0d088 Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:16:29 +0100 Subject: [PATCH 7/9] typo eip-2474.md --- EIPS/eip-2474.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2474.md b/EIPS/eip-2474.md index d3ae13e3e0948a..042a5c69032d1a 100644 --- a/EIPS/eip-2474.md +++ b/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. From 2e4d7df5d01a705a5f798a78b3dec5dd3edd6ae3 Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:17:14 +0100 Subject: [PATCH 8/9] typo eip-747.md --- EIPS/eip-747.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-747.md b/EIPS/eip-747.md index e60995651dfcda..4271e1799fb502 100644 --- a/EIPS/eip-747.md +++ b/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 From e6e7195f16d214a7f140471102aa4104f4a6f79b Mon Sep 17 00:00:00 2001 From: Tristav <124001124+Pricstas@users.noreply.github.com> Date: Tue, 24 Dec 2024 20:17:53 +0100 Subject: [PATCH 9/9] typo eip-7808.md --- EIPS/eip-7808.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7808.md b/EIPS/eip-7808.md index 86f440251b07bf..35074662ed8ce9 100644 --- a/EIPS/eip-7808.md +++ b/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