Merge branch 'origin_master' into master

EIPS/eip-4337.md

@@ -189,8 +189,6 @@ We define the following method in the `EntryPoint` interface to expose these val
 function getNonce(address sender, uint192 key) external view returns (uint256 nonce);
 ```
 
-The function returns the entire nonce value containing both the `key` and the `sequence`.
-
 For each `key` the `sequence` is validated and incremented sequentially and monotonically by the `EntryPoint` for
 each UserOperation, however a new key can be introduced with an arbitrary value at any point.
 

EIPS/eip-5656.md

@@ -119,6 +119,8 @@ post:
 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
 ```
 
+gas used: 6
+
 `MCOPY 0 0 32` - copy 32 bytes from offset 0 to offset 0.
 
 pre:
@@ -133,34 +135,40 @@ post:
 0101010101010101010101010101010101010101010101010101010101010101
 ```
 
+gas used: 6
+
 `MCOPY 0 1 8` - copy 8 bytes from offset 1 to offset 0 (overlapping).
 
 pre:
 
 ```
-000102030405060708 000000000000000000000000000000000000000000000000
+000102030405060708 0000000000000000000000000000000000000000000000
 ```
 
 post:
 
 ```
-010203040506070808 000000000000000000000000000000000000000000000000
+010203040506070808 0000000000000000000000000000000000000000000000
 ```
 
+gas used: 6
+
 `MCOPY 1 0 8` - copy 8 bytes from offset 0 to offset 1 (overlapping).
 
 pre:
 
 ```
-000102030405060708 000000000000000000000000000000000000000000000000
+000102030405060708 0000000000000000000000000000000000000000000000
 ```
 
 post:
 
 ```
-000001020304050607 000000000000000000000000000000000000000000000000
+00000102030405060708 00000000000000000000000000000000000000000000
 ```
 
+gas used: 6
+
 ## Security Considerations
 
 TBA

EIPS/eip-6066.md

@@ -4,7 +4,8 @@ title: Signature Validation Method for NFTs
 description: A way to verify signatures when the signing entity is an ERC-721 or ERC-1155 NFT
 author: Jack Boyuan Xu (@boyuanx)
 discussions-to: https://ethereum-magicians.org/t/eip-6066-signature-validation-method-for-nfts/11943
-status: Review
+status: Last Call
+last-call-deadline: 2023-07-10
 type: Standards Track
 category: ERC
 created: 2022-11-29

EIPS/eip-6110.md

@@ -2,7 +2,7 @@
 eip: 6110
 title: Supply validator deposits on chain
 description: Provides validator deposits as a list of deposit operations added to the Execution Layer block
-author: Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo)
+author: Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo), Peter Davies (@petertdavies)
 discussions-to: https://ethereum-magicians.org/t/eip-6110-supply-validator-deposits-on-chain/12072
 status: Draft
 type: Standards Track
@@ -30,25 +30,27 @@ Advantages of in-protocol deposit processing consist of but are not limit to the
 
 ## Specification
 
-### Constants
+### Execution Layer
+
+#### Constants
 
 | Name | Value | Comment |
 | - | - | - |
 |`FORK_TIMESTAMP` | *TBD* | Mainnet |
 
-### Configuration
+#### Configuration
 
 | Name | Value | Comment |
 | - | - | - |
 |`DEPOSIT_CONTRACT_ADDRESS` | `0x00000000219ab540356cbb839cbe05303d7705fa` | Mainnet |
 
 `DEPOSIT_CONTRACT_ADDRESS` parameter **MUST** be included into client software binary distribution.
 
-### Definitions
+#### Definitions
 
 * **`FORK_BLOCK`** -- the first block in a blockchain with the `timestamp` greater or equal to `FORK_TIMESTAMP`.
 
-### Deposit
+#### Deposit
 
 The structure denoting the new deposit operation consists of the following fields:
 
@@ -70,7 +72,7 @@ rlp_encoded_deposit = RLP([
 ])
 ```
 
-### Block structure
+#### Block structure
 
 Beginning with the `FORK_BLOCK`, the block body **MUST** be appended with a list of deposit operations. RLP encoding of an extended block body structure **MUST** be computed as follows:
 
@@ -95,7 +97,7 @@ def compute_trie_root_from_indexed_data(data):
 block.header.deposits_root = compute_trie_root_from_indexed_data(block.body.deposits)
 ```
 
-### Block validity
+#### Block validity
 
 Beginning with the `FORK_BLOCK`, client software **MUST** extend block validity rule set with the following conditions:
 
@@ -155,6 +157,29 @@ assert block.body.deposits == expected_deposits
 
 A block that does not satisfy the above conditions **MUST** be deemed invalid.
 
+### Consensus layer
+
+Consensus layer changes can be summarized into the following list:
+
+1. `ExecutionPayload` is extended with a new `deposit_receipts` field to accomodate deposit operations list.
+2. `BeaconState` is appended with `deposit_receipts_start_index` used to switch from the former deposit mechanism to the new one.
+3. As a part of transition logic a new beacon block validity condition is added to constrain the usage of `Eth1Data` poll.
+4. A new `process_deposit_receipt` function is added to the block processing routine to handle `deposit_receipts` processing.
+
+Detailed consensus layer specification can be found in following documents:
+
+* [`eip6110/beacon-chain.md`](https://github.com/ethereum/consensus-specs/blob/2660af05390aa61f06142e1c6311a3a3c633f720/specs/_features/eip6110/beacon-chain.md) -- state transition.
+* [`eip6110/validator.md`](https://github.com/ethereum/consensus-specs/blob/2660af05390aa61f06142e1c6311a3a3c633f720/specs/_features/eip6110/validator.md) -- validator guide.
+* [`eip6110/fork.md`](https://github.com/ethereum/consensus-specs/blob/2660af05390aa61f06142e1c6311a3a3c633f720/specs/_features/eip6110/fork.md) -- EIP activation.
+
+#### Validator index invariant
+
+Due to the large follow distance of `Eth1Data` poll an index of a new validator assigned during deposit processing remains the same across different branches of a block tree, i.e. with existing mechanism `(pubkey, index)` cache utilized by consensus layer clients is re-org resilient. The new deposit machinery breaks this invariant and consensus layer clients will have to deal with a fact that a validator index becomes fork dependent, i.e. a validator with the same `pubkey` can have different indexes in different block tree branches.
+
+#### `Eth1Data` poll deprecation
+
+Consensus layer clients will be able to remove `Eth1Data` poll mechanism in an uncoordinated fashion once transition period is finished. The transition period is considered as finished when a network reaches the point where `state.eth1_deposit_index == state.deposit_receipts_start_index`.
+
 ## Rationale
 
 ### `index` field
@@ -177,15 +202,37 @@ This EIP introduces backwards incompatible changes to the block structure and bl
 
 ### Data complexity
 
-At the time of writing this document, the total number of submitted deposits is 478,402 which is 88MB of deposit data. Assuming frequency of deposit transactions remains the same, historic chain data complexity induced by this EIP can be estimated as 50MB per year which is negligible in comparison to other historic data.
+At the time of the latest update of this document, the total number of submitted deposits is 824,598 which is 164MB of deposit data. Assuming frequency of deposit transactions remains the same, historic chain data complexity induced by this EIP can be estimated as 60MB per year which is negligible in comparison to other historical data.
 
-After the beacon chain launch in December 2020, the biggest observed spike in a number of submitted deposits was on March 15, 2022. More than 6000 deposit transactions were submitted during 24 hours which on average is less than 1 deposit, or 192 bytes of data, per block.
+After the beacon chain launch in December 2020, the biggest observed spike in a number of submitted deposits was on June 1, 2023. More than 12,000 deposit transactions were submitted during 24 hours which on average is less than 2 deposit, or 384 bytes of data, per block.
 
 Considering the above, we conclude that data complexity introduced by this proposal is negligible.
 
 ### DoS vectors
 
-With 1 ETH as a minimum deposit amount, the lowest cost of a byte of deposit data is 1 ETH/192 ~ 5,208,333 Gwei. This is several orders of magnitude higher than the cost of a byte of transaction's calldata, thus adding deposit operations to a block does not increase Execution Layer DoS attack surface.
+The code in the deposit contract costs 15,650 gas to run in the cheapest case (when all storage slots are hot and only a single leaf has to be modified). Some deposits in a batch deposit are more expensive, but those costs, when amortized over a large number of deposits, are small at around ~1,000 gas per deposit. Under current gas pricing rules an extra 6,900 gas is charged to make a `CALL` that transfers ETH, this is a case of inefficient gas pricing and may be reduced in the future. For future robustness the beacon chain needs to be able to withstand 1,916 deposits in a 30M gas block (15,650 gas per deposit). The limit under current rules is less than 1,271 deposits in a 30M gas block.
+
+#### Execution layer
+
+With 1 ETH as a minimum deposit amount, the lowest cost of a byte of deposit data is 1 ETH/192 ~ 5,208,333 Gwei. This is several orders of magnitude higher than the cost of a byte of transaction's calldata, thus adding deposit operations to a block does not increase DoS attack surface of the execution layer.
+
+#### Consensus layer
+
+The most consuming computation of deposit processing is signature verification. Its complexity is bounded by a maximum number of deposits per block which is around 1,271 with 30M gas block at the moment. So, it is ~1,271 signature verifications which is roughly ~1.2 seconds of processing (without optimisations like batched signatures verification). An attacker would need to spend 1,000 ETH to slow down block processing by a second which isn't sustainable and viable attack long term.
+
+An optimistically syncing node may be susceptible to a more severe attack scenario. Such a node can't validate a list of deposits provided in a payload which makes it possible for attacker to include as many deposits as the limitation allows to. Currently, it is 8,192 deposits (1.5MB of data) with rough processing time of 8s. Considering an attacker would need to sign off on this block with its crypto economically viable signature (which requires building an alternative chain and feeding it to a syncing node), this attack vector is not considered as viable as it can't result in a significant slow down of a sync process.
+
+### Optimistic sync
+
+An optimistically syncing node have to rely on the honest majority assumption. That is, if adversary is powerful enough to finalize a deposit sequence, a syncing node will have to apply these deposits disregarding the validity of deposit receipts with respect to the execution of a given block. Thus, an adversary that can finalize an invalid chain can also convince an honest node to accept fake deposits. The same is applicable to the validity of execution layer world state today and a new deposit processing design is within boundaries of the existing security model in that regard.
+
+Online nodes can't be tricked into this situation because their execution layer validates supplied deposits with respect to the block execution.
+
+### Weak subjectivity period
+
+This EIP removes a hard limit on a number of deposits per epoch and makes a block gas limit the only limitation on this number. That is, the limit on deposits per epoch shifts from `MAX_DEPOSITS * SLOTS_PER_EPOCH = 512` to `max_deposits_per_30m_gas_block * SLOTS_PER_EPOCH ~ 32,768` at 30M gas block (we consider `max_deposits_per_30m_gas_block = 1,024` for simplicity).
+
+This change affects a number of top ups per epoch which is one of the inputs to the weak subjectivity period computation. One can top up own validators to instantly increase a portion of stake it owns with respect to those validators that are leaking. [The analysis](../assets/eip-6110/ws_period_analysis.md) does not demonstrate significant reduction of a weak subjectivity period sizes. Moreover, such an attack is not considered as viable because it requires a decent portion of stake to be burned as one of preliminaries.
 
 ## Copyright
 

EIPS/eip-6239.md

@@ -4,7 +4,8 @@ title: Semantic Soulbound Tokens
 description: Adding RDF triples to ERC-5192 token metadata to capture social meaning
 author: Jessica Chang (@JessicaChg)
 discussions-to: https://ethereum-magicians.org/t/eip-6239-semantic-soulbound-tokens/12334
-status: Review
+status: Last Call
+last-call-deadline: 2023-07-06
 type: Standards Track
 category: ERC
 created: 2022-12-30

EIPS/eip-6909.md

@@ -2,7 +2,7 @@
 eip: 6909
 title: Minimal Multi-Token Interface
 description: A minimal specification for managing multiple tokens by their id in a single contract.
-author: Joshua Trujillo (@jtriley)
+author: Joshua Trujillo (@jtriley-eth)
 discussions-to: https://ethereum-magicians.org/t/eip-6909-multi-token-standard/13891
 status: Draft
 type: Standards Track