IL building diff

.github/workflows/ci.yml

@@ -17,7 +17,7 @@ jobs:
   save-pr:
     name: Save PR Number
     runs-on: ubuntu-latest
-    
+
     steps:
       - name: Save PR number
         env:
@@ -38,7 +38,7 @@ jobs:
 
   htmlproofer:
     name: HTMLProofer
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-24.04
 
     steps:
       - name: Checkout EIPs
@@ -65,7 +65,7 @@ jobs:
           cd $GITHUB_WORKSPACE
           rm -rf ERCs
       - name: Setup Ruby
-        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1.196.0
+        uses: ruby/setup-ruby@fb404b9557c186e349162b0d8efb06e2bc36edea # v1.232.0
         with:
           ruby-version: '3.1' # Not needed with a .ruby-version file
           bundler-cache: true # runs 'bundle install' and caches installed gems automatically
@@ -74,7 +74,7 @@ jobs:
         run: bundle exec jekyll build
         env:
           JEKYLL_ENV: production
-          
+
       - name: Build Website
         run: |
           bundle exec jekyll doctor
@@ -88,11 +88,11 @@ jobs:
   link-check:
     name: Link Check
     runs-on: ubuntu-latest
-    
+
     steps:
       - name: Checkout EIP Repository
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
-        
+
       - name: Link Checker
         uses: gaurav-nelson/github-action-markdown-link-check@d53a906aa6b22b8979d33bc86170567e619495ec
         with:

.github/workflows/jekyll.yml

@@ -34,12 +34,12 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout EIPs
-        uses: actions/checkout@v4
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
         with:
           repository: ethereum/EIPs
           path: ''
       - name: Checkout ERCs
-        uses: actions/checkout@v4
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
         with:
           repository: ethereum/ERCs
           path: ERCs

EIPS/eip-1.md

@@ -105,7 +105,7 @@ Each EIP should have the following parts:
 - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).
 - Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should discuss important objections or concerns raised during discussion around the EIP.
 - Backwards Compatibility *(optional)* - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backwards incompatibilities, but this section must be included if backward incompatibilities exist.
-- Test Cases *(optional)* - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs, or included in `../assets/eip-###/<filename>`. This section may be omitted for non-Core proposals.
+- Test Cases *(optional)* - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs) or included in `../assets/eip-###/<filename>`. This section may be omitted for non-Core proposals.
 - Reference Implementation *(optional)* - An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. This section may be omitted for all EIPs.
 - Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
 - Copyright Waiver - All EIPs must be in the public domain. The copyright waiver MUST link to the license file and use the following wording: `Copyright and related rights waived via [CC0](../LICENSE.md).`

EIPS/eip-1015.md

@@ -10,12 +10,12 @@
 ---
 
 
 ## Simple Summary
 
 This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be maintained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance.
 
 ## Summary
 ### Thesis: many controversial issues boil down to resources
 These are current EIPs that are being developed or debated. They might seem unrelated but they have something in common, that they can be resolved by proper channel of funds.
 
 #### Casper and PoS
@@ -24,23 +24,23 @@
 
 #### Issuance Cap at 120 Million
 
 [EIP-960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision.
 
 #### Asics and advantages of PoW
 
 [EIP-960](https://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantages to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
 
 #### Recovery Forks
 
 After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](./eip-999.md). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. 
 
 
 #### Other Public Goods
 
 There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](./eip-908.md), fair distribution of tokens etc.
 
 ## Proposed Solution
 ### Issuance Contract
 
 This EIP proposes a future hard fork where block reward is not issued to miners/validators etherbase, but instead to a single contract, that then will activate the default function (with a fixed amount of gas) and then it will forward the ether to other contracts which will finally distribute to their final destinations. 
 
@@ -48,7 +48,7 @@
 
 ##### It can only deal with issuance
 
-It's not meant to be a general governance contract. The contract **should NOT be used to** to decide software updates, to freeze funds, change contracts balances or anything on the consensus layer other than the strict definition of *where block rewards go*. It should be seen as a platform to settle disputes to avoid the implementation of contentious hard forks, not as a mean to remove the power of users and developers to execute them.
+It's not meant to be a general governance contract. The contract **should NOT be used** to decide software updates, to freeze funds, change contract balances or anything on the consensus layer other than the strict definition of *where block rewards go*. It should be seen as a platform to settle disputes to avoid the implementation of contentious hard forks, not as a mean to remove the power of users and developers to execute them.
 
 ##### It cannot only decrease issuance, and once decreased it cannot be increased again
 
@@ -94,7 +94,7 @@
 The decision would be made by multiple signalling contracts, each one implemented by separate groups and representing one aspect of the community or one sort of measurement. Each signaling process would have a `int` bound in which they could vote and they would have their own internal process to decide that. As new governance methods are tested and debated, new signalling contracts should be added and removed. Suggested signalling contracts:
 
 * Futarchy and prediction markets based on multiple measures
-* Votes weighted by ether balance (optionally with multipliers if the voters where committed to locking votes)
+* Votes weighted by ether balance (optionally with multipliers if the voters were committed to locking votes)
 * Token votes, weighted by their own relative ether exchange rate
 * Votes by individual humans if a good sybil resistance, coercion mechanism is developed 
 * Block-signalling, as a way to measure validators/miners choices
@@ -115,5 +115,5 @@
 
 
 
 ## Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-1052.md

@@ -1,7 +1,7 @@
 ---
 eip: 1052
 title: EXTCODEHASH opcode
 author: Nick Johnson <arachnid@notdot.net>, Paweł Bylica <pawel@ethereum.org>
 discussions-to: https://ethereum-magicians.org/t/extcodehash-opcode/262
 status: Final
 type: Standards Track
@@ -9,11 +9,11 @@
 created: 2018-05-02
 requires: 161
 ---
 
 ## Abstract
 This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code.
 
 ## Motivation
 Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
 
 Contracts can presently do this using the `EXTCODECOPY` (`0x3c`) opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, `EXTCODEHASH`, which returns the keccak256 hash of a contract's bytecode.
@@ -46,9 +46,9 @@
 ignored) similarly to the semantics of the `BALANCE` (`0x31`), `EXTCODESIZE` (`0x3b`) and 
 `EXTCODECOPY` (`0x3c`).
 
-The `EXTCODEHASH` distincts accounts without code and non-existing accounts.
+The `EXTCODEHASH` distinguishes accounts without code and non-existing accounts.
 This is consistent with the way accounts are represented in the state trie.
-This also allows smart contracts to check whenever an account exists.
+This also allows smart contracts to check whether an account exists.
 
 
 ## Backwards Compatibility
@@ -59,7 +59,7 @@
 ## Test Cases
 
 1. The `EXTCODEHASH` of the account without code is `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`
-   what is the keccack256 hash of empty data.
+   what is the keccak256 hash of empty data.
 2. The `EXTCODEHASH` of non-existent account is `0`.
 3. The `EXTCODEHASH` of a precompiled contract is either `c5d246...` or `0`.
 4. If `EXTCODEHASH` of `A` is `X`, then `EXTCODEHASH` of `A + 2**160` is `X`.
@@ -71,8 +71,8 @@
 10. The `EXTCODEHASH` of an empty account that is going to be cleared by the state clearing rule.
 
 
 ## Implementation
 TBD
 
 ## Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-1057.md

@@ -69,10 +69,10 @@ With the growth of large mining pools, the control of hashing power has been del
 1. No natural distribution: There isn’t an economic purpose for ultra-specialized hardware outside of mining and thus no reason for most people to have it.
 2. No reserve group: Thus, there’s no reserve pool of hardware or reserve pool of interested parties to jump in when coin price is volatile and attractive for manipulation.
 3. High barrier to entry: Initial miners are those rich enough to invest capital and ecological resources on the unknown experiment a new coin may be. Thus, initial coin distribution through mining will be very limited causing centralized economic bias.
-4. Delegated centralization vs implementation centralization: While pool centralization is delegated, hardware monoculture is not: only the limiter buyers of this hardware can participate so there isn’t even the possibility of divesting control on short notice.
+4. Delegated centralization vs implementation centralization: While pool centralization is delegated, hardware monoculture is not: only the limited buyers of this hardware can participate so there isn’t even the possibility of divesting control on short notice.
 5. No obvious decentralization of control even with decentralized mining: Once large custom ASIC makers get into the game, designing back-doored hardware is trivial. ASIC makers have no incentive to be transparent or fair in market participation.
 
-While the goal of “ASIC resistance” is valuable, the entire concept of “ASIC resistance” is a bit of a fallacy.  CPUs and GPUs are themselves ASICs.  Any algorithm that can run on a commodity ASIC (a CPU or GPU) by definition can have a customized ASIC created for it with slightly less functionality. Some algorithms are intentionally made to be  “ASIC friendly” - where an ASIC implementation is drastically more efficient than the same algorithm running on general purpose hardware. The protection that this offers when the coin is unknown also makes it an attractive target for a dedicate mining ASIC company as soon as it becomes useful.
+While the goal of “ASIC resistance” is valuable, the entire concept of “ASIC resistance” is a bit of a fallacy.  CPUs and GPUs are themselves ASICs.  Any algorithm that can run on a commodity ASIC (a CPU or GPU) by definition can have a customized ASIC created for it with slightly less functionality. Some algorithms are intentionally made to be  “ASIC friendly” - where an ASIC implementation is drastically more efficient than the same algorithm running on general purpose hardware. The protection that this offers when the coin is unknown also makes it an attractive target for a dedicated mining ASIC company as soon as it becomes useful.
 
 Therefore, ASIC resistance is: the efficiency difference of specialized hardware versus hardware that has a wider adoption and applicability.  A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms.  Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated.  If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack.
 
@@ -528,7 +528,7 @@ We do not recommend implementing this fix at this time. Ethash will not be explo
 
 After the completion of the audits a clever finding by [Kik](https://github.com/kik/) disclosed a vulnerability to [bypassing ProgPoW memory hardness](https://github.com/kik/progpow-exploit).  The vulnerability is present in Ethash as well but is near-impossible to exploit.  In progPoW it is not possible to exploit -- it assumes the ability to create variants of the candidate block's header hash in a fashion similar to bitcoin, which is actually not possible in Ethereum.  An attacker would need modified block headers, would need customized nodes able to accept the modified block headers, and uses extraNonce/extraData as entropy -- which isn’t the standard.  And the required brute-force search would be difficult to accomplish in one blocktime.  And even if supported by a customized node the block propagation of such mined blocks would be immediately blocked by other peers as the header hash is invalid.
 
-The author's have since found another vulnerability similar to Kik's, but it adds too much overhead to be ASIC-friendly.  See Lanfranchi's full explanation [here](https://github.com/ifdefelse/ProgPOW/issues/51#issuecomment-690155355).  To completely prevent such exploits we could change the condition modifying the input state of the last keccak pass from
+The authors have since found another vulnerability similar to Kik's, but it adds too much overhead to be ASIC-friendly.  See Lanfranchi's full explanation [here](https://github.com/ifdefelse/ProgPOW/issues/51#issuecomment-690155355).  To completely prevent such exploits we could change the condition modifying the input state of the last keccak pass from
 * header (256 bits) +
 * seed for mix initiator (64 bits) +
 * mix from main loop (256 bits)

EIPS/eip-1679.md

@@ -1,14 +1,14 @@
 ---
 eip: 1679
 title: "Hardfork Meta: Istanbul"
 author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)
 discussions-to: https://ethereum-magicians.org/t/hardfork-meta-istanbul-discussion/3207
 type: Meta
 status: Final
 created: 2019-01-04
 requires: 152, 1108, 1344, 1716, 1884, 2028, 2200
 ---
 
 ## Abstract
 
 This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul.
@@ -32,10 +32,10 @@
   - [EIP-2028](./eip-2028.md): Calldata gas cost reduction
   - [EIP-2200](./eip-2200.md): Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change
 
 ## References
 
-1. Included EIPs were finalized in [All Core Devs Call #68](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2068.md)
+1. Included EIPs were finalized in [All Core Devs Call #68](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2068.md)
 2. https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df
 
 ## Copyright
 

EIPS/eip-1898.md

@@ -4,8 +4,7 @@ title: Add `blockHash` to defaultBlock methods
 description: Add `blockHash` option to JSON-RPC methods that currently support defaultBlock parameter.
 author: Charles Cooper (@charles-cooper)
 discussions-to: https://ethereum-magicians.org/t/eip-1898-add-blockhash-option-to-json-rpc-methods-that-currently-support-defaultblock-parameter/11757
-status: Last Call
-last-call-deadline: 2025-03-04
+status: Final
 type: Standards Track
 category: Interface
 created: 2019-04-01

EIPS/eip-225.md

@@ -192,7 +192,7 @@ This list may be expired after a certain number of blocks / epochs, but it's imp
 ## Test Cases
 
 ```go
-// block represents a single block signed by a parcitular account, where
+// block represents a single block signed by a particular account, where
 // the account may or may not have cast a Clique vote.
 type block struct {
   signer     string   // Account that signed this particular block

EIPS/eip-2294.md

@@ -12,15 +12,15 @@ requires: 155
 
 ## Abstract
 
-This EIP informationally defines the "Safe Range" and "Max Range" of ChainId based on a few known restrictions such as [EIP-155](./eip-155.md) and major wallet and JsonPRC representation of ChainId.
+This EIP informationally defines the "Safe Range" and "Max Range" of ChainId based on a few known restrictions such as [EIP-155](./eip-155.md) and major wallet and JSON-RPC representation of ChainId.
 
 ## Motivation
 
-1. We want chainId to be safe across the different components of the ecosystem such as smart contract, wallet, dApp and JsonPRC etc.
+1. We want chainId to be safe across the different components of the ecosystem such as smart contract, wallet, dApp and JSON-RPC etc.
 2. We want to enable Cross-Chain function call
 3. We want to ensure [EIP-712](./eip-712.md) domains have a clear definition of how to pack ChainID.
-4. Enable possbile expansion of chains, such as increasing amount of L2s, L3s, or shards of Ethereum mainnets.
-5. Enable hashed based temparary chain: There have been suggestions of using a hash-based identifier in place on Chain ID to allow the value to adapt over time to different contentious forks and other scenarios. This proposal does not describe this behavior, but ~63 bits of entropy should be enough to ensure that no collisions are likely for reasonable (e.g. non-malicious) uses of this feature for that purpose.
+4. Enable possible expansion of chains, such as increasing amount of L2s, L3s, or shards of Ethereum mainnets.
+5. Enable hashed based temporary chain: There have been suggestions of using a hash-based identifier in place on Chain ID to allow the value to adapt over time to different contentious forks and other scenarios. This proposal does not describe this behavior, but ~63 bits of entropy should be enough to ensure that no collisions are likely for reasonable (e.g. non-malicious) uses of this feature for that purpose.
 
 ## Specification
 
@@ -43,7 +43,7 @@ and suggests a reasonable maximum enforced size in order to ensure that there ar
 
 Without a well-chosen value of Chain ID, there could be differences in the implementation of [EIP-155](./eip-155.md) (and [EIP-1344](./eip-1344.md) by derivative) in both client codebase and external tooling that could lead to consensus-critical vulnerabilities being introduced to the network. By making this limit explicit, we avoid this scenario for Ethereum and any project which uses the Ethereum codebase.
 
-Also, the field `chainID` have experienced increasing usage and dependencies, due more and more contracts are depending on [EIP-1344](./eip-1344.md) to expose CHAIN ID in the smart contract execution. For example when used with [EIP-712](./eip-712.md), [ERC-1271](./eip-1271.md) for on-contract signature verification, chainId has been increasingly introduced for replay attack prevention. It's security critical to ensure clients depending on the chainId computation in cryptography yields identical result for verification in
+Also, the field `chainID` has experienced increasing usage and dependencies, due more and more contracts are depending on [EIP-1344](./eip-1344.md) to expose CHAIN ID in the smart contract execution. For example when used with [EIP-712](./eip-712.md), [ERC-1271](./eip-1271.md) for on-contract signature verification, chainId has been increasingly introduced for replay attack prevention. It's security critical to ensure clients depending on the chainId computation in cryptography yields identical result for verification in
 all cases.
 
 ## Backwards Compatibility

EIPS/eip-2537.md

@@ -4,8 +4,7 @@ title: Precompile for BLS12-381 curve operations
 description: Adds operation on BLS12-381 curve as a precompile in a set necessary to efficiently perform operations such as BLS signature verification.
 author: Alex Vlasov (@shamatar), Kelly Olson (@ineffectualproperty), Alex Stokes (@ralexstokes), Antonio Sanso (@asanso)
 discussions-to: https://ethereum-magicians.org/t/eip2537-bls12-precompile-discussion-thread/4187
-status: Last Call
-last-call-deadline: 2025-04-01
+status: Final
 type: Standards Track
 category: Core
 created: 2020-02-21
@@ -195,10 +194,6 @@ Error cases:
 - An input is on its respective elliptic curve but not in the correct subgroup
 - Input has invalid length
 
-Note:
-
-If any input is the infinity point, pairing result will be 1. Protocols may want to check and reject infinity points prior to calling the precompile.
-
 #### ABI for mapping Fp element to G1 point
 
 Field-to-curve call expects `64` bytes as an input that is interpreted as an element of Fp. Output of this call is `128` bytes and is an encoded G1 point.