Merge branch 'ethereum:master' into AuthCreate

.github/renovate.json

@@ -13,5 +13,6 @@
     "ethereum/eipw-action",
     "ethereum/eip-review-bot",
     "ethereum/EIP-Bot"
-  ]
+  ],
+  "enabled": false
 }

EIPS/eip-1.md

@@ -87,7 +87,7 @@ If this period results in necessary normative changes it will revert the EIP to
 
 A PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it.
 
-**Stagnant** - Any EIP in `Draft` or `Review` or `Last Call` if inactive for a period of 6 months or greater is moved to `Stagnant`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `Draft` or it's earlier status. If not resurrected, a proposal may stay forever in this status.
+**Stagnant** - Any EIP in `Draft` or `Review` or `Last Call` if inactive for a period of 6 months or greater is moved to `Stagnant`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `Draft` or its earlier status. If not resurrected, a proposal may stay forever in this status.
 
 >*EIP Authors are notified of any algorithmic change to the status of their EIP*
 

EIPS/eip-101.md

@@ -56,7 +56,7 @@ This essentially implements signature and nonce checking, and if both checks pas
 Miners can follow the following algorithm upon receiving transactions:
 
 1.  Run the code for a maximum of 50000 gas, stopping if they see an operation or call that threatens to go over this limit
-2.  Upon seeing that operation, make sure that it leaves at last 50000 gas to spare (either by checking that the static gas consumption is small enough or by checking that it is a call with `msg.gas - 50000` as its gas limit parameter)
+2.  Upon seeing that operation, make sure that it leaves at least 50000 gas to spare (either by checking that the static gas consumption is small enough or by checking that it is a call with `msg.gas - 50000` as its gas limit parameter)
 3.  Pattern-match to make sure that gas payment code at the end is *exactly* the same as in the code above.
 
 This process ensures that miners *waste* at most 50000 gas before knowing whether or not it will be worth their while to include the transaction, and is also highly general so users can experiment with new cryptography (eg. ed25519, Lamport), ring signatures, quasi-native multisig, etc. Theoretically, one can even create an account for which the *valid signature* type is a valid Merkle branch of a receipt, creating a quasi-native alarm clock.

EIPS/eip-1901.md

@@ -16,7 +16,7 @@ This is a proposal to add [OpenRPC](https://github.com/open-rpc/spec) support to
 
 The OpenRPC Document and generated Documentation that specifies all the methods an EVM-based blockchain should implement can be found [here](https://github.com/etclabscore/ethereum-json-rpc-specification).
 
-This was first proposed [here as an ECIP](https://github.com/etclabscore/ECIPs/blob/master/ECIPs/ECIP-1053.md), but the benefits of this kind of tooling is apparent across Bitcoin, Ethereum Classic, Ethereum and other JSON-RPC accessible blockchains.
+This was first proposed [here as an ECIP](https://github.com/etclabscore/ECIPs/blob/master/ECIPs/ecip-1053.md), but the benefits of this kind of tooling is apparent across Bitcoin, Ethereum Classic, Ethereum and other JSON-RPC accessible blockchains.
 
 ## Motivation
 

EIPS/eip-2537.md

@@ -356,9 +356,7 @@ There are no backward compatibility questions.
 
 Scalar multiplications, MSMs and pairings MUST perform a subgroup check.
 Implementations SHOULD use the optimized subgroup check method detailed in a dedicated [document](../assets/eip-2537/fast_subgroup_checks.md).
-
 On any input that fail the subgroup check, the precompile MUST return an error.
-
 As endomorphism acceleration requires input on the correct subgroup, implementers MAY use endomorphism acceleration.
 
 ### Field to curve mapping

EIPS/eip-2935.md

@@ -71,11 +71,14 @@ def resolve_blockhash(block: Block, state: State, arg: uint64):
 Exact evm assembly that can be used for the contract to resolve `BLOCKHASH`
 
 ```
-// check if inputsize>32 revert
-push1 0x20
-calldatasize
+// check if input > 8 byte value and revert if this isn't the case
+// the check is performed by comparing the biggest 8 byte number with
+// the call data, which is a right-padded 32 byte number.
+push8 0xffffffffffffffff
+push0
+calldataload
 gt
-push1 0x31
+push1 0x39
 jumpi
 
 // check if input > blocknumber-1 then return 0
@@ -85,24 +88,24 @@ sub
 push0
 calldataload
 gt
-push1 0x29
+push1 0x31
 jumpi
 
-// check if blocknumber > input + 8192 then return 0
+// check if blocknumber > input + 8192 then return 0, no overflow expected for input of 8 bytes
 push0
 calldataload
 push2 0x2000
 add
 number
 gt
-push1 0x29
+push1 0x31
 jumpi
 
 // mod 8192 and sload
-push2 0x2000
+push2 0x1FFF
 push0
 calldataload
-mod
+and
 sload
 
 // load into mem and return 32 bytes
@@ -130,6 +133,10 @@ revert
 stop
 ```
 
+Note that the input contract read `32` bytes input as `calldataload`. Users and clients doing EVM call to this contract should left pad the `arg` correctly.
+
+<!-- TODO: bytecode is based off on first version and will be updated once assembley is locked down as it changes contract sender and address -->
+
 Corresponding bytecode:
 `60203611603157600143035f35116029575f356120000143116029576120005f3506545f5260205ff35b5f5f5260205ff35b5f5ffd00`
 

EIPS/eip-2982.md

@@ -43,7 +43,7 @@ In addition to the above, PoS has synergies with the sharding scaling solution.
 
 ## Specification
 
-Phase 0 is designed to require _no breaking consensus changes_ to existing Ethereum mainnet. Instead, this is the bootstraping a new PoS consensus that can, once stable, supplant the current PoW consensus.
+Phase 0 is designed to require _no breaking consensus changes_ to existing Ethereum mainnet. Instead, this is the bootstrapping a new PoS consensus that can, once stable, supplant the current PoW consensus.
 
 Phase 0 specifications are maintained in a repository independent of this EIP. `SPEC_RELEASE_VERSION` release of the specs at `SPEC_RELEASE_COMMIT` are considered the canonical Phase 0 specs for this EIP.
 
@@ -394,7 +394,7 @@ The deposit contract maintains a Merkle root of all deposits made so far. Once a
 
 #### Activation
 
-The validator immediately joins the validator registry, but is at first inactive. The validator becomes active after $N \ge 4$ epochs; the minimum of 4 is there to ensure the RANDAO is not manipulable, and $N$ may exceed 4 if too many validators try to join at the same time. If the active validator set has size $|V|$, a maximum of $max(4, \frac{|V|}{65536})$ valdators can join per epoch; if more validators try to join, they are put in a queue and processed as quickly as possible.
+The validator immediately joins the validator registry, but is at first inactive. The validator becomes active after $N \ge 4$ epochs; the minimum of 4 is there to ensure the RANDAO is not manipulable, and $N$ may exceed 4 if too many validators try to join at the same time. If the active validator set has size $|V|$, a maximum of $max(4, \frac{|V|}{65536})$ validators can join per epoch; if more validators try to join, they are put in a queue and processed as quickly as possible.
 
 #### Exiting
 

EIPS/eip-3074.md

@@ -95,7 +95,7 @@ If `length` is greater than 97, the extra bytes are ignored for signature verifi
 The arguments (`yParity`, `r`, `s`) are interpreted as an ECDSA signature on the secp256k1 curve over the message `keccak256(MAGIC || chainId || nonce || invokerAddress || commit)`, where:
 
  - `chainId` is the current chain's [EIP-155](./eip-155.md) unique identifier padded to 32 bytes.
- - `nonce` is the signer's current nonce, left-padded to 32 bytes. Any other value is considered invalid.
+ - `nonce` is the signer's current nonce, left-padded to 32 bytes.
  - `invokerAddress` is the address of the contract executing `AUTH` (or the active state address in the context of `CALLCODE` or `DELEGATECALL`), left-padded with zeroes to a total of 32 bytes (ex. `0x000000000000000000000000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA`).
  - `commit`, one of the arguments passed into `AUTH`, is a 32-byte value that can be used to commit to specific additional validity conditions in the invoker's pre-processing logic.
 

EIPS/eip-3085.md

@@ -4,7 +4,7 @@ title: wallet_addEthereumChain RPC Method
 description: Adds an RPC method to add EVM-compatible chains
 author: Erik Marks (@rekmarks), Pedro Gomes (@pedrouid), Pandapip1 (@Pandapip1)
 discussions-to: https://ethereum-magicians.org/t/eip-3085-wallet-addethereumchain/5469
-status: Review
+status: Stagnant
 type: Standards Track
 category: Interface
 created: 2020-11-01

EIPS/eip-3091.md

@@ -4,7 +4,7 @@ title: Block Explorer API Routes
 description: API Routes for Blockchain explorers
 author: Pedro Gomes (@pedrouid), ligi (@ligi)
 discussions-to: https://ethereum-magicians.org/t/eip-3091-block-explorer-api-routes/4907
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Interface
 created: 2020-11-02

EIPS/eip-3155.md

@@ -153,7 +153,7 @@ This EIP is fully backward compatible with go-ethereum. OpenEthereum, Besu and N
 
 ## Implementation
 Implementation in [go-ethereum](https://github.com/ethereum/go-ethereum/tree/master/cmd/evm)
-Implementation in [OpenEthereum](https://github.com/openethereum/openethereum/tree/master/evmbin)
+Implementation in [OpenEthereum](https://github.com/openethereum/openethereum/tree/main/bin/evmbin)
 Implementation in [Besu](https://github.com/hyperledger/besu/tree/master/ethereum/evmtool)
 Implementation in [Nethermind](https://github.com/NethermindEth/nethermind/tree/master/src/Nethermind/Nethermind.State.Test.Runner)
 

EIPS/eip-5283.md

@@ -59,9 +59,9 @@ abstract contract ReentrancyGuard2 {
 }
 ```
 
-### Parallellizable storage-based RPGs
+### Parallelizable storage-based RPGs
 
-The only way to paralellize prexistent contracts that are using the storage RPG construction is that the VM automatically detects that a storage variable is used for the RPG, and proves that is works as required. This requires static code analysys. This is difficult to implement in consensus for two reasons. First, the CPU cost of detection and/or proving may be high. Second, some contract functions may not be protected by the RPG, meaning that some execution paths do not alter the RPG, which may complicate proving. Therefore this proposal aims to protect future contracts and let them be parallelizable, rather than to paralellize already deployed ones.
+The only way to parallelize preexistent contracts that are using the storage RPG construction is that the VM automatically detects that a storage variable is used for the RPG, and proves that it works as required. This requires static code analysis. This is difficult to implement in consensus for two reasons. First, the CPU cost of detection and/or proving may be high. Second, some contract functions may not be protected by the RPG, meaning that some execution paths do not alter the RPG, which may complicate proving. Therefore this proposal aims to protect future contracts and let them be parallelizable, rather than to parallelize already deployed ones.
 
 ### Alternatives
 

EIPS/eip-5749.md

@@ -30,8 +30,9 @@ At present, `window.ethereum` is the prevailing method by which Ethereum-compati
 	- Enkrypt
 	- Trust wallet
 	- Rainbow
+
 
-Replacing `window.ethereum` with `window.evmproviders` will allow solutions such as web3modal and web3onboard to display all injected wallets the user has installed. This will simpify the UX and remove race conditions between wallet providers in case multiple wallets are installed. Over time, as `window.evmproviders` supplants the current standard and removes barriers to choice, we can hope to see a wallet landscape more reflective of user preference.
+Replacing `window.ethereum` with `window.evmproviders` will allow solutions such as web3modal and web3onboard to display all injected wallets the user has installed. This will simplify the UX and remove race conditions between wallet providers in case multiple wallets are installed. Over time, as `window.evmproviders` supplants the current standard and removes barriers to choice, we can hope to see a wallet landscape more reflective of user preference.
 
 ## Specification
 

EIPS/eip-615.md

@@ -510,11 +510,11 @@ There is a large and growing ecosystem of researchers, authors, teachers, audito
 * [Ethereum 2.0 Specifications](https://github.com/ethereum/eth2.0-specs)
 * [Formal Verification of Smart Contracts](https://www.cs.umd.edu/~aseem/solidetherplas.pdf)
 * [JelloPaper: Human Readable Semantics of EVM in K](https://jellopaper.org/)
-* [KEVM: A Complete Semantics of the Ethereum Virtual Machine.](https://www.ideals.illinois.edu/bitstream/handle/2142/97207/hildenbrandt-saxena-zhu-rodrigues-guth-daian-rosu-2017-tr.pdf)
+* [KEVM: A Complete Semantics of the Ethereum Virtual Machine.](https://www.ideals.illinois.edu/items/102260)
 * [Making Smart Contracts Smarter](https://eprint.iacr.org/2016/633.pdf)
 * [Securify: Practical Security Analysis of Smart Contracts](https://arxiv.org/pdf/1806.01143.pdf)
 * [The Thunder Protocol](https://docs.thundercore.com/thunder-whitepaper.pdf)
-* [Towards Verifying Ethereum Smart Contract Bytecode in Isabelle/HOL](https://ts.data61.csiro.au/publications/csiro_full_text//Amani_BBS_18.pdf)
+* [Towards Verifying Ethereum Smart Contract Bytecode in Isabelle/HOL](https://trustworthy.systems/publications/full_text/Amani_BBS_18.pdf)
 *[A Lem formalization of EVM 1.5](https://github.com/seed/eth-isabelle/tree/evm15)
 
 

EIPS/eip-6873.md

@@ -4,7 +4,7 @@ title: Preimage retention
 description: Execution clients must retain the preimages of addresses and slots accessed between the fork preceding the verge, and the verge itself.
 author: Guillaume Ballet (@gballet)
 discussions-to: https://ethereum-magicians.org/t/eip-6873-preimage-retention-in-the-fork-preceding-the-verge/15830
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2023-04-14

EIPS/eip-6963.md

@@ -248,7 +248,7 @@ The security considerations of [EIP-1193](./eip-1193.md) apply to this EIP. Impl
 
 ### Prototype Pollution of Wallet Provider objects
 
-Browser extensions, and therefore Wallet extensions, are able to modify the contents of the page and the Provider object by design. The provider objects of various Wallets are considered a highly trusted interface to communicate transaction data. In order to prevent the page or various other extensions from modifying the interaction between the DApp and the Wallet in an unexpected way, the best practice is to "freeze" the provider discovery object by utilizing `object.freeze()` on the  `EIP1193Provider` object before the wallet dispatches it in the `eip6963:announceProvider` Event. However, there are difficulties that can occur around web compatability where pages need to monkey patch the object. In scenarios like this there's a tradeoff that needs to be made between security and web compatibility that Wallet implementers are expected to consider.
+Browser extensions, and therefore Wallet extensions, are able to modify the contents of the page and the Provider object by design. The provider objects of various Wallets are considered a highly trusted interface to communicate transaction data. In order to prevent the page or various other extensions from modifying the interaction between the DApp and the Wallet in an unexpected way, the best practice is to "freeze" the provider discovery object by utilizing `object.freeze()` on the  `EIP1193Provider` object before the wallet dispatches it in the `eip6963:announceProvider` Event. However, there are difficulties that can occur around web compatibility where pages need to monkey patch the object. In scenarios like this there's a tradeoff that needs to be made between security and web compatibility that Wallet implementers are expected to consider.
 
 ### Wallet Imitation and Manipulation
 

EIPS/eip-7002.md

@@ -224,6 +224,8 @@ def reset_withdrawal_requests_count():
     sstore(WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS, WITHDRAWAL_REQUEST_COUNT_STORAGE_SLOT, 0)
 ```
 
+Each withdrawal request must appear in the EIP-7685 requests list in the order they are returned from `dequeue_withdrawal_requests()`.
+
 ##### Bytecode
 
 ```asm
@@ -477,7 +479,6 @@ jumpdest
 push0
 push0
 revert
-
 ```
 
 ##### Deployment

EIPS/eip-7378.md

@@ -4,7 +4,7 @@ title: Add time-weighted averaging to the base fee
 description: Using geometric weights to average past block sizes into consideration
 author: Guy Goren (@guy-goren) <guy.nahsholim@gmail.com>
 discussions-to: https://ethereum-magicians.org/t/add-time-weighted-averaging-to-the-base-fee-mechanism/15142
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2023-07-22

EIPS/eip-7495.md

@@ -2,7 +2,7 @@
 eip: 7495
 title: SSZ StableContainer
 description: New SSZ type to represent a flexible container with stable serialization and merkleization
-author: Etan Kissling (@etan-status)
+author: Etan Kissling (@etan-status), Cayman (@wemeetagain)
 discussions-to: https://ethereum-magicians.org/t/eip-7495-ssz-stablecontainer/15476
 status: Review
 type: Standards Track
@@ -16,6 +16,8 @@ This EIP introduces a new [Simple Serialize (SSZ) type](https://github.com/ether
 
 A `StableContainer[N]` is an SSZ `Container` with stable serialization and merkleization even when individual fields become optional or new fields are introduced in the future.
 
+Furthermore, to continue supporting versioned containers, e.g., fork-specific consensus data structures, `Variant[S]` is introduced, selecting only a subset of fields of the underlying `StableContainer` `S`. `Variant[S]` shares the merkleization of `S`, but has a more compact serialization and provides better type safety.
+
 ## Motivation
 
 Stable containers are currently not representable in SSZ. Adding support provides these benefits:

EIPS/eip-7519.md

@@ -4,7 +4,7 @@ title: Atomic Storage Operations SCREDIT and SDEBIT
 description: Add atomic operations for incrementing and decrementing storage slots
 author: Danno Ferrin (@shemnon)
 discussions-to: https://ethereum-magicians.org/t/eip-7519-atomic-storage-operations-scredit-and-sdebit/15818
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2023-09-16

EIPS/eip-7600.md

@@ -25,9 +25,11 @@ This Meta EIP lists the EIPs formally considered for and included in the Prague/
 * [EIP-7002](./eip-7002.md): Execution layer triggerable exits
 * [EIP-7251](./eip-7251.md): Increase the MAX_EFFECTIVE_BALANCE  
 * [EIP-7549](./eip-7549.md): Move committee index outside Attestation
+* [EIP-7685](./eip-7685.md): General purpose execution layer requests 
 
 ### EIPs Considered for Inclusion
 
+* [EIP-7212](./eip-7212.md): Precompile for secp256r1 Curve Support
 * [EIP-7547](./eip-7547.md): Inclusion lists
 * [EIP-7623](./eip-7623.md): Increase calldata cost
 * EOF, consisting of the following EIPs: 

EIPS/eip-7658.md

@@ -4,7 +4,7 @@ title: Light client data backfill
 description: Mechanism for beacon nodes for syncing historical light client data
 author: Etan Kissling (@etan-status)
 discussions-to: https://ethereum-magicians.org/t/eip-7658-light-client-data-backfill/19290
-status: Draft
+status: Review
 type: Standards Track
 category: Core
 created: 2024-03-21
@@ -166,17 +166,9 @@ This EIP requires a hard fork as it introduces new consensus validation rules.
 
 Only light client data following the hard fork can be proven to be canonical and optimal. However, after finalization of the fork transition block, earlier light client data can no longer change and could be locked in using a hash.
 
-## Test Cases
-
-TBD
-
-## Reference Implementation
-
-TBD
-
 ## Security Considerations
 
-TBD
+None
 
 ## Copyright