Merge branch 'master' into master

.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*
 
@@ -338,6 +338,24 @@ Which renders to:
 
 [CVE-2023-29638 (2023-10-17T10:14:15)](https://nvd.nist.gov/vuln/detail/CVE-2023-29638)
 
+### Chain Agnostic Improvement Proposals (CAIPs)
+
+Links to a Chain Agnostic Improvement Proposals (CAIPs) specification may be included using normal markdown syntax, such as:
+
+```markdown
+[CAIP 10](https://github.com/ChainAgnostic/CAIPs/blob/5dd3a2f541d399a82bb32590b52ca4340b09f08b/CAIPs/caip-10.md)
+```
+
+Which renders to:
+
+[CAIP 10](https://github.com/ChainAgnostic/CAIPs/blob/5dd3a2f541d399a82bb32590b52ca4340b09f08b/CAIPs/caip-10.md)
+
+Permitted Chain Agnostic URLs must anchor to a specific commit, and so must match this regular expression:
+
+```regex
+^(https://github.com/ChainAgnostic/CAIPs/blob/[0-9a-f]{40}/CAIPs/caip-[0-9]+\.md)$
+```
+
 ### Ethereum Yellow Paper
 
 Links to the Ethereum Yellow Paper may be included using normal markdown syntax, such as:
@@ -361,12 +379,12 @@ Permitted Yellow Paper URLs must anchor to a specific commit, and so must match
 Links to the Ethereum Execution Client Specification Tests may be included using normal markdown syntax, such as:
 
 ```markdown
-[Ethereum Execution Client Specification Tests](https://github.com/ethereum/execution-specs/blob/9a1f22311f517401fed6c939a159b55600c454af/README.md)
+[Ethereum Execution Client Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/d5a3188f122912e137aa2e21ed2a1403e806e424/README.md)
 ```
 
 Which renders to:
 
-[Ethereum Execution Client Specification Tests](https://github.com/ethereum/execution-specs/blob/9a1f22311f517401fed6c939a159b55600c454af/README.md)
+[Ethereum Execution Client Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/d5a3188f122912e137aa2e21ed2a1403e806e424/README.md)
 
 Permitted Execution Client Specification Tests URLs must anchor to a specific commit, and so must match this regular expression:
 

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-1011.md

@@ -342,7 +342,7 @@ Most other decisions were made to minimize changes across clients. For example,
 #### Deploying Casper Contract
 The `MSG_HASHER_CODE` and `PURITY_CHECKER_CODE` both do not require any initialization so the EVM bytecode can simply be placed at `MSG_HASHER_ADDR` and `PURITY_CHECKER_ADDR`. On the other hand, the casper contract _does_ require passing in parameters and initialization of state. This initialization would normally occur by the EVM init code interacting with the CREATE opcode. Due to the nature of this contract being deployed outside of normal block transactions and to a particular address, the EVM init code/CREATE method requires client specific "hacks" to make it work. For simplicity of specifying across clients, the EVM bytecode -- `CASPER_CODE` -- is placed at `CASPER_ADDR` followed by an explicit `CALL` to a one-time `init` method on the casper contract. `init` handles all of the logic that a constructor normally would, accepting contract parameters as arguments and setting initial variable values, and can only be run _once_.
 
-`CASPER_INIT_DATA` is composed of the the byte signature of the `init` method of the casper contract concatenated with the 32-byte encodings of the following variables in the following order:
+`CASPER_INIT_DATA` is composed of the byte signature of the `init` method of the casper contract concatenated with the 32-byte encodings of the following variables in the following order:
 
   * `EPOCH_LENGTH`
   * `WITHDRAWAL_DELAY`

EIPS/eip-1015.md

@@ -20,7 +20,7 @@ These are current EIPs that are being developed or debated. They might seem unre
 
 #### Casper and PoS
 
-Moving to PoS has been on the roadmap since day 0 for ethereum, along with a reduction in issuance to a cost equivalent to the Validator's cost of security (considered to be more eficient than PoW). But the exact issuance necessary for PoS has yet to be determined and is currently being researched. Casper validation will be an on chain contract and therefore it will need to be funded. It's unlikely that a definitive final answer on how much issuance is needed for validation will be reached in the next years as new research will uncover new arguments, so it would make sense to allow some flexibility on this matter
+Moving to PoS has been on the roadmap since day 0 for ethereum, along with a reduction in issuance to a cost equivalent to the Validator's cost of security (considered to be more efficient than PoW). But the exact issuance necessary for PoS has yet to be determined and is currently being researched. Casper validation will be an on chain contract and therefore it will need to be funded. It's unlikely that a definitive final answer on how much issuance is needed for validation will be reached in the next years as new research will uncover new arguments, so it would make sense to allow some flexibility on this matter
 
 #### Issuance Cap at 120 Million
 

EIPS/eip-1052.md

@@ -61,7 +61,7 @@ There are no backwards compatibility concerns.
 1. The `EXTCODEHASH` of the account without code is `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`
    what is the keccack256 hash of empty data.
 2. The `EXTCODEHASH` of non-existent account is `0`.
-3. The `EXTCODEHASH` of an precompiled contract is either `c5d246...` or `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`.
 5. The `EXTCODEHASH` of an account that selfdestructed in the current transaction.
 6. The `EXTCODEHASH` of an account that selfdestructed and later the selfdestruct has been reverted.

EIPS/eip-1057.md

@@ -326,12 +326,12 @@ uint32_t math(uint32_t a, uint32_t b, uint32_t r)
 
 The flow of the inner loop is:
 * Lane `(loop % LANES)` is chosen as the leader for that loop iteration
-* The leader's `mix[0]` value modulo the number of 256-byte DAG entries is is used to select where to read from the full DAG
+* The leader's `mix[0]` value modulo the number of 256-byte DAG entries is used to select where to read from the full DAG
 * Each lane reads `DAG_LOADS` sequential words, using `(lane ^ loop) % LANES` as the starting offset within the entry.
 * The random sequence of math and cache accesses is performed
 * The DAG data read at the start of the loop is merged at the end of the loop
 
-`prog_seed` and `loop` come from the outer loop, corresponding to the current program seed (which is block_number/PROGPOW_PERIOD) and the loop iteration number.  `mix` is the state array, initially filled by `fill_mix`. `dag` is the bytes of the Ethash DAG grouped into 32 bit unsigned ints in litte-endian format.  On little-endian architectures this is just a normal int32 pointer to the existing DAG.
+`prog_seed` and `loop` come from the outer loop, corresponding to the current program seed (which is block_number/PROGPOW_PERIOD) and the loop iteration number.  `mix` is the state array, initially filled by `fill_mix`. `dag` is the bytes of the Ethash DAG grouped into 32 bit unsigned ints in little-endian format.  On little-endian architectures this is just a normal int32 pointer to the existing DAG.
 
 `DAG_BYTES` is set to the number of bytes in the current DAG, which is generated identically to the existing Ethash algorithm.  
 

EIPS/eip-107.md

@@ -93,7 +93,7 @@ the error object cannot be a javascript Error object due to postMessage limitati
 ## Rationale
 
 The design for that proposal was chosen for its simplicity and security. A previous idea was to use an oauth-like protocol in order for the user to accept or deny a transaction request. It would have required deeper code change in the node and some geth contributors argues that such change did not fit into geth code base as it would have required dapp aware code.
-The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guarantess by browsers' cross domain policies.
+The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guaranteed by browsers' cross domain policies.
 
 The use of iframe/ window was required to have both security and user friendliness. The invisible iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653).
 

EIPS/eip-1109.md

@@ -47,7 +47,7 @@ The return will be 1 in case of success call and 0 in any of the next cases:
 1.- mu_s[0] is an address of an undefined precompiled smart contract.
 2.- The precompiled smart contract fails (as defined on each smart contract). Invalid input parameters for example.
 
-Precompiled smart contracs, does not execute opcodes, so there is no need to pass a gas parameter as a normal `CALL` (`0xf1`).  If the available gas is less that 2 plus the required gas required for the specific precompiled smart cotract, the context just STOPS executing with an "Out of Gas" error.
+Precompiled smart contracts, does not execute opcodes, so there is no need to pass a gas parameter as a normal `CALL` (`0xf1`).  If the available gas is less that 2 plus the required gas required for the specific precompiled smart contract, the context just STOPS executing with an "Out of Gas" error.
 
 There is no stack check for this call.
 

EIPS/eip-1153.md

@@ -4,8 +4,7 @@ title: Transient storage opcodes
 description: Add opcodes for manipulating state that behaves almost identically to storage but is discarded after every transaction
 author: Alexey Akhunov (@AlexeyAkhunov), Moody Salem (@moodysalem)
 discussions-to: https://ethereum-magicians.org/t/eip-transient-storage-opcodes/553
-status: Last Call
-last-call-deadline: 2022-12-08
+status: Final
 type: Standards Track
 category: Core
 created: 2018-06-15
@@ -98,6 +97,10 @@ This EIP requires a hard fork to implement.
 
 Since this EIP does not change behavior of any existing opcodes, it is backwards compatible with all existing smart contracts.
 
+## Test Cases
+
+A test suite for this EIP can be found [here](https://github.com/ethereum/execution-spec-tests/tree/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip1153_tstore).
+
 ## Reference Implementation
 
 Because the transient storage must behave almost identically to storage within the context of a single transaction with regards to revert behavior, it is necessary to be able to revert to a previous state of transient storage within a transaction. At the same time reverts are exceptional cases and loads, stores and returns should be cheap.

EIPS/eip-1193.md

@@ -1,7 +1,7 @@
 ---
 eip: 1193
 title: Ethereum Provider JavaScript API
-author: Fabian Vogelsteller (@frozeman), Ryan Ghods (@ryanio), Victor Maia (@MaiaVictor), Marc Garreau (@marcgarreau), Erik Marks (@rekmarks)
+author: Fabian Vogelsteller (@frozeman), Ryan Ghods (@ryanio), Victor Maia (@MaiaVictor), Marc Garreau (@wolovim), Erik Marks (@rekmarks)
 discussions-to: https://github.com/ethereum/EIPs/issues/2319
 status: Final
 type: Standards Track

EIPS/eip-1380.md

@@ -11,9 +11,11 @@ requires: 150
 ---
 
 ## Abstract
+
 Reduce the gas cost for call instructions, when the goal is to run a new instance of the currently loaded contract.
 
 ## Motivation
+
 The current gas cost of 700 for all call types (`CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL`) does not take into account that a call to a contract itself
 does not need to perform additional I/O operations, because the current contract code has already been loaded into memory.
 
@@ -26,32 +28,38 @@ must be swapped in and out of the calling functions context. A desired feature i
 them through `JUMP` requires a bigger effort from the compiler as opposed to being able to use `CALL`s.
 
 Using call-to-self provides the guarantee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both
-contract writers and contract consumers against potentially undetetected edge cases were memory could poison the context of the internal function.
+contract writers and contract consumers against potentially undetected edge cases were memory could poison the context of the internal function.
 
-Because of the `JUMP` usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerbly faster, if nested
+Because of the `JUMP` usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerably faster, if nested
 function calls with many in and/or outputs are required.
 
 Reducing the gas cost, and thereby incentivising of using call-to-self instead of `JUMP`s for the internal function implementation will also benefit static
 analyzers and tracers.
 
 ## Specification
+
 If `block.number >= FORK_BLKNUM`, then decrease the cost of `CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL` from 700 to 40,
 if and only if, the destination address of the call equals to the address of the caller.
 
 ## Rationale
+
 EIP150 has increased the cost of these instructions from 40 to 700 to more fairly charge for loading new contracts from disk, e.g. to reflect the I/O charge more closely.
 By assuming that 660 is the cost of loading a contract from disk, one can assume that the original 40 gas is a fair cost of creating a new VM instance of an already loaded contract code.
 
 ## Backwards Compatibility
+
 This should pose no risk to backwards compatibility. Currently existing contracts should not notice the difference, just see cheaper execution.
 With EIP150 contract (and language) developers had a lesson that relying on strict gas costs is not feasible as costs may change.
 The impact of this EIP is even less that of EIP150 because the costs are changing downwards and not upwards.
 
 ## Test Cases
+
 TBA
 
 ## Implementation
+
 TBA
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-1474.md

@@ -293,10 +293,10 @@ Common chain IDs:
 ```sh
 # Request
 curl -X POST --data '{
-    "id": 1337
+    "id": 1337,
     "jsonrpc": "2.0",
     "method": "net_version",
-    "params": [],
+    "params": []
 }' <url>
 
 # Response

EIPS/eip-161.md

@@ -66,4 +66,4 @@ On 2016-11-24, a consensus bug occurred due to two implementations having differ
 1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158
 2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161
 3. https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/
-> Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes.
+> Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes.

EIPS/eip-1706.md

@@ -26,7 +26,7 @@ https://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_consta
 
 ## Specification
 
-Add the following condition to to the SSTORE opcode gas cost calculation:
+Add the following condition to the SSTORE opcode gas cost calculation:
 
 * If *gasleft* is less than or equal to 2300, fail the current call frame
   with 'out of gas' exception.

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-1930.md

@@ -127,7 +127,7 @@ This solution does not require to compute a ```E``` value and thus do not relies
 But this check still pass if the gas given was less AND the external call reverted or succeeded EARLY (so that the gas left after the call > txGas / 63).
 This can be an issue if the code executed as part of the CALL is reverting as a result of a check against the gas provided. Like a meta transaction in a meta transaction.
 
-Similarly to the the previous solution, an EVM mechanism would be much better.
+Similarly to the previous solution, an EVM mechanism would be much better.
 
 ## Backwards Compatibility