From 59843422c15649a521863d16fede003eeb35a356 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Tue, 11 Jun 2024 13:00:23 +0700 Subject: [PATCH 01/28] Update EIP-7251: Add EL triggered consolidations Merged by EIP-Bot. --- EIPS/eip-7251.md | 509 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 501 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-7251.md b/EIPS/eip-7251.md index 3c63ca90e98bff..1859ce2a844b46 100644 --- a/EIPS/eip-7251.md +++ b/EIPS/eip-7251.md @@ -2,13 +2,13 @@ eip: 7251 title: Increase the MAX_EFFECTIVE_BALANCE description: Allow validators to have larger effective balances, while maintaining the 32 ETH lower bound. -author: mike (@michaelneuder), Francesco (@fradamt), dapplion (@dapplion), Mikhail (@mkalinin), Aditya (@adiasg), Justin (@justindrake) +author: mike (@michaelneuder), Francesco (@fradamt), dapplion (@dapplion), Mikhail (@mkalinin), Aditya (@adiasg), Justin (@justindrake), lightclient (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-7251-increase-the-max-effective-balance/15982 status: Draft type: Standards Track category: Core created: 2023-06-28 -requires: 7002 +requires: 7002, 7685 --- ## Abstract @@ -24,6 +24,27 @@ With the security model of the protocol no longer dependent on a low value for ` ### Constants +#### Execution layer + +| Name | Value | Comment | +| - | - | - | +| `CONSOLIDATION_REQUEST_TYPE` | `0x02` | The [EIP-7685](./eip-7685.md) type prefix for consolidation request | +| `CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS` | `0x` | Where to call and store relevant details about consolidation requests mechanism | +| `SYSTEM_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe` | Address used to invoke system operation on contract | +| `EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT` | `0` | | +| `CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT` | `1` | | +| `CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT` | `2` | Pointer to head of the consolidation request message queue | +| `CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT` | `3` | Pointer to the tail of the consolidation request message queue | +| `CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET` | `4` | The start memory slot of the in-state consolidation request message queue | +| `MAX_CONSOLIDATION_REQUESTS_PER_BLOCK` | `1` | Maximum number of consolidation requests that can be dequeued into a block | +| `TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK` | `1` | | +| `MIN_CONSOLIDATION_REQUEST_FEE` | `1` | | +| `CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION` | `17` | | +| `EXCESS_INHIBITOR` | `1181` | Excess value used to compute the fee before the first system call | +| `FORK_TIMESTAMP` | *TBD* | Mainnet | + +#### Consensus layer + | Name | Value | | - | - | | `COMPOUNDING_WITHDRAWAL_PREFIX` | `Bytes1('0x02')` | @@ -32,7 +53,479 @@ With the security model of the protocol no longer dependent on a low value for ` ### Execution layer -This requires no changes to the Execution Layer. +#### Consolidation request + +The new consolidation request is an [EIP-7685](./eip-7685.md) request with type `0x02` consisting of the following fields: + +1. `source_address`: `Bytes20` +2. `source_pubkey`: `Bytes48` +3. `target_pubkey`: `Bytes48` + +The [EIP-7685](./eip-7685.md) encoding of a withdrawal request **MUST** be computed as the follows: + +```python +encoded = CONSOLIDATION_REQUEST_TYPE ++ rlp([source_address, source_pubkey, target_pubkey]) +``` + +#### Consolidation request contract + +The contract has three different code paths, which can be summarized at a high level as follows: + +1. Add consolidation request - requires a `96` byte input, concatenated public keys of the source and the target validators. +2. Excess consolidation requests getter - if the input length is zero, return the current excess consolidation requests count. +3. System process - if called by system address, pop off the consolidation requests for the current block from the queue. + +##### Add Consolidation Request + +If call data input to the contract is exactly `96` bytes, perform the following: + +1. Ensure enough ETH was sent to cover the current consolidation request fee (`check_fee()`) +2. Increase consolidation request count by `1` for the current block (`increment_count()`) +3. Insert a consolidation request into the queue for the source address and pubkeys of the source and the target (`insert_withdrawal_request_into_queue()`) + +Specifically, the functionality is defined in pseudocode as the function `add_consolidation_request()`: + +```python +def add_consolidation_request(Bytes48: source_pubkey, Bytes48: target_pubkey): + """ + Add consolidaiton request adds new request to the consolidation request queue, so long as a sufficient fee is provided. + """ + + # Verify sufficient fee was provided. + fee = get_fee() + require(msg.value >= fee, 'Insufficient value for fee') + + # Increment consolidaiton request count. + count = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT) + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT, count + 1) + + # Insert into queue. + queue_tail_index = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT) + queue_storage_slot = CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET + queue_tail_index * 4 + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot, msg.sender) + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot + 1, source_pubkey[0:32]) + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot + 2, source_pubkey[32:48] ++ target_pubkey[0:16]) + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot + 3, target_pubkey[16:48]) + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT, queue_tail_index + 1) +``` + +###### Fee calculation + +The following pseudocode can compute the cost an individual consolidation request, given a certain number of excess consolidation requests. + +```python +def get_fee() -> int: + excess = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT) + return fake_exponential( + MIN_CONSOLIDATION_REQUEST_FEE, + excess, + CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION + ) + +def fake_exponential(factor: int, numerator: int, denominator: int) -> int: + i = 1 + output = 0 + numerator_accum = factor * denominator + while numerator_accum > 0: + output += numerator_accum + numerator_accum = (numerator_accum * numerator) // (denominator * i) + i += 1 + return output // denominator +``` + +##### Excess Consolidation Requests Getter + +```python +def get_excess_consolidation_requests(): + count = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT) + return count +``` + +##### System Call + +If the contract is called as `SYSTEM_ADDRESS` with an empty input data, perform the following: + +* The contract's queue is updated based on consolidation requests dequeued and the consolidation requests queue head/tail are reset if the queue has been cleared (`dequeue_consolidation_requests()`) +* The contract's excess consolidation requests are updated based on usage in the current block (`update_excess_consolidation_requests()`) +* The contract's consolidation requests count is reset to `0` (`reset_consolidation_requests_count()`) + +Specifically, the functionality is defined in pseudocode as the function `process_consolidation_requests()`: + +```python +################### +# Public function # +################### + +def process_consolidation_requests(): + reqs = dequeue_consolidation_requests() + update_excess_consolidation_requests() + reset_consolidation_requests_count() + return reqs + +########### +# Helpers # +########### + +class ConsolidationRequest(object): + source_address: Bytes20 + source_pubkey: Bytes48 + target_pubkey: Bytes48 + +def dequeue_consolidation_requests(): + queue_head_index = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT) + queue_tail_index = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT) + num_in_queue = queue_tail_index - queue_head_index + num_dequeued = min(num_in_queue, MAX_CONSOLIDATION_REQUESTS_PER_BLOCK) + + reqs = [] + for i in range(num_dequeue): + queue_storage_slot = CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET + (queue_head_index + i) * 4 + source_address = address(sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot)[0:20]) + source_pubkey = ( + sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot + 1)[0:32] + sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot + 2)[0:16] + ) + target_pubkey = ( + sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot + 2)[16:32] + sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, queue_storage_slot + 3)[0:32] + ) + req = ConsolidationRequest( + source_address=Bytes20(source_address), + source_pubkey=Bytes48(source_pubkey), + target_pubkey=Bytes48(target_pubkey) + ) + reqs.append(req) + + new_queue_head_index = queue_head_index + num_dequeued + if new_queue_head_index == queue_tail_index: + # Queue is empty, reset queue pointers + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT, 0) + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT, 0) + else: + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT, new_queue_head_index) + + return reqs + +def update_excess_consolidation_requests(): + previous_excess = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT) + # Check if excess needs to be reset to 0 for first iteration after activation + if previous_excess == EXCESS_INHIBITOR: + previous_excess = 0 + + count = sload(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT) + + new_excess = 0 + if previous_excess + count > TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK: + new_excess = previous_excess + count - TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK + + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT, new_excess) + +def reset_consolidation_requests_count(): + sstore(CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT, 0) +``` + +##### Bytecode + +```asm +caller +push20 0xfffffffffffffffffffffffffffffffffffffffe +eq +push1 0x98 +jumpi + +calldatasize +iszero +iszero +push1 0x28 +jumpi + +push0 +sload +push0 +mstore +push1 0x20 +push0 +return + +jumpdest +calldatasize +push1 0x60 +eq +iszero +push2 0x0144 +jumpi + +push1 0x11 +push0 +sload +push1 0x01 +dup3 +mul +push1 0x01 +swap1 +push0 + +jumpdest +push0 +dup3 +gt +iszero +push1 0x59 +jumpi + +dup2 +add +swap1 +dup4 +mul +dup5 +dup4 +mul +swap1 +div +swap2 +push1 0x01 +add +swap2 +swap1 +push1 0x3e +jump + +jumpdest +swap1 +swap4 +swap1 +div +callvalue +lt +push2 0x0144 +jumpi + +push1 0x01 +sload +push1 0x01 +add +push1 0x01 +sstore +push1 0x03 +sload +dup1 +push1 0x04 +mul +push1 0x04 +add +caller +dup2 +sstore +push1 0x01 +add +push0 +calldataload +dup2 +sstore +push1 0x01 +add +push1 0x20 +calldataload +dup2 +sstore +push1 0x01 +add +push1 0x40 +calldataload +swap1 +sstore +push1 0x01 +add +push1 0x03 +sstore +stop + +jumpdest +push1 0x03 +sload +push1 0x02 +sload +dup1 +dup3 +sub +dup1 +push1 0x01 +gt +push1 0xac +jumpi + +pop +push1 0x01 + +jumpdest +push0 + +jumpdest +dup2 +dup2 +eq +push1 0xf1 +jumpi + +dup1 +push1 0x74 +mul +dup4 +dup3 +add +push1 0x04 +mul +push1 0x04 +add +dup1 +sload +swap1 +push1 0x01 +add +dup1 +sload +swap1 +push1 0x01 +add +dup1 +sload +swap1 +push1 0x01 +add +sload +swap3 +push1 0x60 +shl +dup5 +mstore +swap1 +dup4 +push1 0x14 +add +mstore +dup3 +push1 0x34 +add +mstore +swap1 +push1 0x54 +add +mstore +push1 0x01 +add +push1 0xae +jump + +jumpdest +swap2 +add +dup1 +swap3 +eq +push2 0x0103 +jumpi + +swap1 +push1 0x02 +sstore +push2 0x010e +jump + +jumpdest +swap1 +pop +push0 +push1 0x02 +sstore +push0 +push1 0x03 +sstore + +jumpdest +push0 +sload +dup1 +push2 0x049d +eq +iszero +push2 0x011d +jumpi + +pop +push0 + +jumpdest +push1 0x01 +sload +push1 0x01 +dup3 +dup3 +add +gt +push2 0x0132 +jumpi + +pop +pop +push0 +push2 0x0138 +jump + +jumpdest +add +push1 0x01 +swap1 +sub + +jumpdest +push0 +sstore +push0 +push1 0x01 +sstore +push1 0x74 +mul +push0 +return + +jumpdest +push0 +push0 +revert +``` + +##### Deployment + +The consolidation requests contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction: + +```json +{ + "type": "0x0", + "nonce": "0x0", + "to": null, + "gas": "0x3d090", + "gasPrice": "0xe8d4a51000", + "maxPriorityFeePerGas": null, + "maxFeePerGas": null, + "value": "0x0", + "input": "0x61049d5f5561014880600f5f395ff33373fffffffffffffffffffffffffffffffffffffffe146098573615156028575f545f5260205ff35b36606014156101445760115f54600182026001905f5b5f82111560595781019083028483029004916001019190603e565b90939004341061014457600154600101600155600354806004026004013381556001015f35815560010160203581556001016040359055600101600355005b6003546002548082038060011160ac575060015b5f5b81811460f15780607402838201600402600401805490600101805490600101805490600101549260601b84529083601401528260340152906054015260010160ae565b9101809214610103579060025561010e565b90505f6002555f6003555b5f548061049d141561011d57505f5b6001546001828201116101325750505f610138565b01600190035b5f555f6001556074025ff35b5f5ffd", + "v": "0x1b", + "r": "0x539", + "s": "0x13370066aa8fbe21ca1511", + "hash": "0x6de32a89ba4c0592fd2453f8838d6bb69d93a102723de5f4b0f046ddcf8b8fa9" +} +``` + +``` +Sender: 0xd6e25886D7B986C394156C31a48e84Ee0BA71f72 +Address: 0x00b42dbF2194e931E80326D950320f7d9Dbeac02 +``` + +#### Block processing + +At the end of processing any execution block where `block.timestamp >= FORK_TIMESTAMP` (i.e. after processing all transactions and after performing the block body requests validations) clienst software **MUST** take the following steps: + +1. Call the contract as `SYSTEM_ADDRESS` and empty input data to trigger the system subroutine execute. +2. Check that consolidation requests in the [EIP-7685](./eip-7685.md) requests list matches the list returned from `dequeue_consolidation_requests()` function of the smart contract respecting the order of the returned requests. If this condition does not hold, the block **MUST** be deemed *invalid*. ### Consensus layer @@ -73,15 +566,15 @@ The [Rationale](#rationale) section contains an explanation for each of these pr This EIP aims to reduce the total number of validators without changing anything about the economic security of the protocol. It provides a mechanism by which large node operators who control significant amounts of stake can consolidate into fewer validators. We analyze the reasoning behind each of the core features. 1. ***Increasing the `MAX_EFFECTIVE_BALANCE`, while creating a `MIN_ACTIVATION_BALANCE`.*** - - *While increasing the `MAX_EFFECTIVE_BALANCE` to allow larger-stake validators, it is important to keep the lower bound of `32 ETH` (by introducing a new constant – `MIN_ACTIVATION_BALANCE`) to encourage solo-staking.* + * *While increasing the `MAX_EFFECTIVE_BALANCE` to allow larger-stake validators, it is important to keep the lower bound of `32 ETH` (by introducing a new constant – `MIN_ACTIVATION_BALANCE`) to encourage solo-staking.* 2. ***Allowing for multiple validator indices to be combined through the protocol.*** - - *For large staking pools that already control thousands of validators, exiting and re-entering would be extremely slow and costly. The adoption of the EIP will be much higher by allowing in-protocol consolidation.* + * *For large staking pools that already control thousands of validators, exiting and re-entering would be extremely slow and costly. The adoption of the EIP will be much higher by allowing in-protocol consolidation.* 3. ***Permitting validators to set custom ceilings for their validator to indicate where the partial withdrawal sweep activates.*** - - *To get access to rewards, validators might want the flexibility to set custom ceilings for their effective balance. This gives them more optionality and is a clean way to continue supporting the partial-withdrawal sweep (a gasless way to extract rewards).* + * *To get access to rewards, validators might want the flexibility to set custom ceilings for their effective balance. This gives them more optionality and is a clean way to continue supporting the partial-withdrawal sweep (a gasless way to extract rewards).* 4. ***Adding execution layer partial withdrawals (part of [EIP-7002](./eip-7002.md)).*** - - *For validators that choose to raise their effective balance ceiling, allowing for custom partial withdrawals triggered from the execution layer increases the flexibility of the staking configurations. Validators can choose when and how much they withdraw but will have to pay gas for the EL transaction.* + * *For validators that choose to raise their effective balance ceiling, allowing for custom partial withdrawals triggered from the execution layer increases the flexibility of the staking configurations. Validators can choose when and how much they withdraw but will have to pay gas for the EL transaction.* 5. ***Removing the initial slashing penalty (still in discussion).*** - - *To encourage consolidation, we could modify the slashing penalties. The biggest hit comes from the initial penalty of `1/32` of the validator's effective balance. Since this scales linearly on the effective balance, the higher-stake validators directly incur higher risk. By changing the scaling properties, we could make consolidation more attractive.* + * *To encourage consolidation, we could modify the slashing penalties. The biggest hit comes from the initial penalty of `1/32` of the validator's effective balance. Since this scales linearly on the effective balance, the higher-stake validators directly incur higher risk. By changing the scaling properties, we could make consolidation more attractive.* ## Backwards Compatibility From 0698add05ee0c6545fd69a904258aecf1274eb61 Mon Sep 17 00:00:00 2001 From: Lion - dapplion <35266934+dapplion@users.noreply.github.com> Date: Tue, 11 Jun 2024 14:37:48 +0200 Subject: [PATCH 02/28] Update EIP-7549: Move to Review Merged by EIP-Bot. --- EIPS/eip-7549.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7549.md b/EIPS/eip-7549.md index ce574f5d9aa78e..113495ba80a5f3 100644 --- a/EIPS/eip-7549.md +++ b/EIPS/eip-7549.md @@ -4,7 +4,7 @@ title: Move committee index outside Attestation description: Move committee index outside of the signed Attestation message author: dapplion (@dapplion) discussions-to: https://ethereum-magicians.org/t/eip-7549-move-committee-index-outside-attestation/16390 -status: Draft +status: Review type: Standards Track category: Core created: 2023-11-01 From b6982795667c5f9462ca9708381e62befca3b0b0 Mon Sep 17 00:00:00 2001 From: Antonio Sanso Date: Tue, 11 Jun 2024 16:01:16 +0200 Subject: [PATCH 03/28] Add some additional tests Merged by EIP-Bot. --- assets/eip-2537/multiexp_G1_bls.json | 16 +++++++++++++++- assets/eip-2537/multiexp_G2_bls.json | 14 ++++++++++++++ assets/eip-2537/test-vectors.md | 12 ++++++------ 3 files changed, 35 insertions(+), 7 deletions(-) diff --git a/assets/eip-2537/multiexp_G1_bls.json b/assets/eip-2537/multiexp_G1_bls.json index 0a1373782f5775..536f0b91f56e27 100644 --- a/assets/eip-2537/multiexp_G1_bls.json +++ b/assets/eip-2537/multiexp_G1_bls.json @@ -75,5 +75,19 @@ "Expected": "00000000000000000000000000000000053fbdb09b6b5faa08bfe7b7069454247ad4d8bd57e90e2d2ebaa04003dcf110aa83072c07f480ab2107cca2ccff6091000000000000000000000000000000001654537b7c96fe64d13906066679c3d45808cb666452b55d1b909c230cc4b423c3f932c58754b9b762dc49fcc825522c", "Gas": 42000, "NoBenchmark": false + }, + { + "Input": "0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e19a2b64cc58f8992cb21237914262ca9ada6cb13dc7b7d3f11c278fe0462040e4", + "Name": "bls_g1multiexp_random*g1_unnormalized_scalar", + "Expected": "000000000000000000000000000000000491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a0000000000000000000000000000000017cd7061575d3e8034fcea62adaa1a3bc38dca4b50e4c5c01d04dd78037c9cee914e17944ea99e7ad84278e5d49f36c4", + "Gas": 14400, + "NoBenchmark": false + }, + { + "Input": "00000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a219a2b64cc58f8992cb21237914262ca9ada6cb13dc7b7d3f11c278fe0462040e4", + "Name": "bls_g1multiexp_random*p1_unnormalized_scalar", + "Expected": "0000000000000000000000000000000006ee9c9331228753bcb148d0ca8623447701bb0aa6eafb0340aa7f81543923474e00f2a225de65c62dd1d8303270220c0000000000000000000000000000000018dd7be47eb4e80985d7a0d2cc96c8b004250b36a5c3ec0217705d453d3ecc6d0d3d1588722da51b40728baba1e93804", + "Gas": 14400, + "NoBenchmark": false } -] \ No newline at end of file +] diff --git a/assets/eip-2537/multiexp_G2_bls.json b/assets/eip-2537/multiexp_G2_bls.json index fdf50e0fce44c7..bd16a8a8949ce6 100644 --- a/assets/eip-2537/multiexp_G2_bls.json +++ b/assets/eip-2537/multiexp_G2_bls.json @@ -82,5 +82,19 @@ "Expected": "0000000000000000000000000000000016cf5fd2c2f1b2e01cc48a6d03e8e6d7f3ad754d6c7d4000f806c18c28d8d559cf529dd159c74946a7713d1906894718000000000000000000000000000000000628d42142df8d620d1f3709ac01f382ba950eaf14c12863885af5838067deec4bb363ffda427fcbdd2b8ec6cc5784ae0000000000000000000000000000000018168dec2441ef462e9a769c782f81acdc7fa49dffebb996764ba9fa96b9200ceb5edd9e96b33c383bd042b4e6af191a000000000000000000000000000000001065aaea2c4aa1d2bee7f1e82a2138ae7016dbbade8383ad912d81eca5fb260086238f95f8cef8f2f491969d4cefa2c3", "Gas": 147690, "NoBenchmark": false + }, + { + "Input": "00000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be9a2b64cc58f8992cb21237914262ca9ada6cb13dc7b7d3f11c278fe0462040e4", + "Name": "bls_g2multiexp_random*g2_unnormalized_scalar", + "Expected": "0000000000000000000000000000000014856c22d8cdb2967c720e963eedc999e738373b14172f06fc915769d3cc5ab7ae0a1b9c38f48b5585fb09d4bd2733bb000000000000000000000000000000000c400b70f6f8cd35648f5c126cce5417f3be4d8eefbd42ceb4286a14df7e03135313fe5845e3a575faab3e8b949d248800000000000000000000000000000000149a0aacc34beba2beb2f2a19a440166e76e373194714f108e4ab1c3fd331e80f4e73e6b9ea65fe3ec96d7136de81544000000000000000000000000000000000e4622fef26bdb9b1e8ef6591a7cc99f5b73164500c1ee224b6a761e676b8799b09a3fd4fa7e242645cc1a34708285e4", + "Gas": 54000, + "NoBenchmark": false + }, + { + "Input": "00000000000000000000000000000000103121a2ceaae586d240843a398967325f8eb5a93e8fea99b62b9f88d8556c80dd726a4b30e84a36eeabaf3592937f2700000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000f9e7ba9a86a8f7624aa2b42dcc8772e1af4ae115685e60abc2c9b90242167acef3d0be4050bf935eed7c3b6fc7ba77e000000000000000000000000000000000d22c3652d0dc6f0fc9316e14268477c2049ef772e852108d269d9c38dba1d4802e8dae479818184c08f9a569d8784519a2b64cc58f8992cb21237914262ca9ada6cb13dc7b7d3f11c278fe0462040e4", + "Name": "bls_g2multiexp_random*p2_unnormalized_scalar", + "Expected": "00000000000000000000000000000000036074dcbbd0e987531bfe0e45ddfbe09fd015665990ee0c352e8e403fe6af971d8f42141970d9ab14b4dd04874409e600000000000000000000000000000000019705637f24ba2f398f32c3a3e20d6a1cd0fd63e6f8f071cf603a8334f255744927e7bfdfdb18519e019c49ff6e914500000000000000000000000000000000008e74fcff4c4278c9accfb60809ed69bbcbe3d6213ef2304e078d15ec7d6decb4f462b24b8e7cc38cc11b6f2c9e0486000000000000000000000000000000001331d40100f38c1070afd832445881b47cf4d63894666d9907c85ac66604aab5ad329980938cc3c167ccc5b6bc1b8f30", + "Gas": 54000, + "NoBenchmark": false } ] diff --git a/assets/eip-2537/test-vectors.md b/assets/eip-2537/test-vectors.md index b9f2f2bd9b102d..edc1d9a39b7c55 100644 --- a/assets/eip-2537/test-vectors.md +++ b/assets/eip-2537/test-vectors.md @@ -4,19 +4,19 @@ These test vectors are derived from [BLS 12-381 tests](https://github.com/ethere - [`BLS12_G1ADD` Machine-readable data](add_G1_bls.json) - [`BLS12_G2ADD` Machine-readable data](add_G2_bls.json) -- [`BLS12_G1MSM` Machine-readable data](mul_G1_bls.json) -- [`BLS12_G2MSM` Machine-readable data](mul_G2_bls.json) +- [`BLS12_G1MUL` Machine-readable data](mul_G1_bls.json) +- [`BLS12_G2MUL` Machine-readable data](mul_G2_bls.json) - [`BLS12_MAP_FP_TO_G1` Machine-readable data](map_fp_to_G1_bls.json) - [`BLS12_MAP_FP2_TO_G2` Machine-readable data](map_fp2_to_G2_bls.json) - [`BLS12_G1MULTIEXP` Machine-readable data](multiexp_G1_bls.json) - [`BLS12_G2MULTIEXP` Machine-readable data](multiexp_G2_bls.json) -- [`BLS12_PAIRING` Machine-readable data](pairing_check_bls.json) +- [`BLS12_PAIRING_CHECK` Machine-readable data](pairing_check_bls.json) - [Fail `BLS12_G1ADD` Machine-readable data](fail-add_G1_bls.json) - [Fail `BLS12_G2ADD` Machine-readable data](fail-add_G2_bls.json) -- [Fail `BLS12_G1MSM` Machine-readable data](fail-mul_G1_bls.json) -- [Fail `BLS12_G2MSM` Machine-readable data](fail-mul_G2_bls.json) +- [Fail `BLS12_G1MUL` Machine-readable data](fail-mul_G1_bls.json) +- [Fail `BLS12_G2MUL` Machine-readable data](fail-mul_G2_bls.json) - [Fail `BLS12_MAP_FP_TO_G1` Machine-readable data](fail-map_fp_to_G1_bls.json) - [Fail `BLS12_MAP_FP2_TO_G2` Machine-readable data](fail-map_fp2_to_G2_bls.json) - [Fail `BLS12_G1MULTIEXP` Machine-readable data](fail-multiexp_G1_bls.json) - [Fail `BLS12_G2MULTIEXP` Machine-readable data](fail-multiexp_G2_bls.json) -- [Fail `BLS12_PAIRING` Machine-readable data](fail-pairing_check_bls.json) +- [Fail `BLS12_PAIRING_CHECK` Machine-readable data](fail-pairing_check_bls.json) From f25c6c8e18e60247e7e6c2b52986f56ad3e9f1f8 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Tue, 11 Jun 2024 16:06:54 +0200 Subject: [PATCH 04/28] Add EIP: ETH transfers emit a log Merged by EIP-Bot. --- EIPS/eip-7708.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 EIPS/eip-7708.md diff --git a/EIPS/eip-7708.md b/EIPS/eip-7708.md new file mode 100644 index 00000000000000..d3f58878e19162 --- /dev/null +++ b/EIPS/eip-7708.md @@ -0,0 +1,56 @@ +--- +eip: 7708 +title: ETH transfers emit a log +description: All ETH transfers emit a log +author: Vitalik Buterin (@vbuterin), Peter Davies (@petertdavies) +discussions-to: https://ethereum-magicians.org/t/eip-7708-eth-transfers-emit-a-log/20034 +status: Draft +type: Standards Track +category: Core +created: 2024-05-17 +--- + +## Abstract + +All ETH-transfers, including transactions, `CALL` and `SELFDESTRUCT` emit a log. + +## Motivation + +Logs are often used to track when balance changes of assets on Ethereum. Logs work for [ERC-20](./eip-20.md) tokens, but they do not work for ETH. ETH transfers from EOAs can be read from the transaction list in the block, but ETH transfers from smart contract wallets are not automatically logged anywhere. This has already led to problems in the past, eg. early exchanges would often not properly support deposits from smart contract wallets, or only support them with a much longer delay. This EIP proposes that we automatically generate a log every time a value-transferring `CALL` or `SELFDESTRUCT` happens. We also add a similar log for transfers in transactions, so that all ETH transfers can be tracked using one mechanism. + +## Specification + +### Parameters + +* `MAGIC`: `TBD` + +### Functionality + +Whenever (i) a nonzero-value `CALL`, (ii) a nonzero-value-transferring `SELFDESTRUCT`, or (iii) a nonzero-value-transferring transaction takes place, issue a log, identical to a LOG3, with three topics: (i) `MAGIC`, (ii) the sender address, (iii) the recipient address. The log data is a big-endian 32-byte encoding of the transfer value. + +The `LOG` of a value-transferring transaction should be placed before any logs created by EVM execution. The other two `LOG`s are placed at the time that the value transfer executes. + +## Rationale + +This is the simplest possible implementation that ensures that all ETH transfers are implemented in some kind of record that can be easily accessed through making RPC calls into a node, or through asking for a Merkle branch that is hashed into the block root. The log type is compatible with the ERC-20 token standard, but does not introduce any overly-specific ERC-20 features (eg. ABI encodings) into the specification. + +### Open questions + +1. Should withdrawals also trigger a log? If so, what should the sender address be specified as? +2. Should fee payments trigger a log? It would ensure "completeness", in the sense that you can compute the exact current balance table by watching logs, but it would greatly increase the number of logs, perhaps to an unacceptably high amount. + +## Backwards Compatibility + +No backward compatibility issues found. + +## Test Cases + +TODO + +## Security Considerations + +ETH transfers already cost a minimum of 6700 gas, which is much more expensive than the LOG3 opcode (1500 gas). Hence, this EIP does not increase the worst-case number of logs that can be put into a block. It will somewhat increase the average number of logs. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 5af69eea91d679b6da8e3946a1ed8a43333a4fbb Mon Sep 17 00:00:00 2001 From: Lion - dapplion <35266934+dapplion@users.noreply.github.com> Date: Tue, 11 Jun 2024 16:46:25 +0200 Subject: [PATCH 05/28] Add EIP: Anti-correlation attestation penalties Merged by EIP-Bot. --- EIPS/eip-7716.md | 85 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 EIPS/eip-7716.md diff --git a/EIPS/eip-7716.md b/EIPS/eip-7716.md new file mode 100644 index 00000000000000..f95c237b53b73b --- /dev/null +++ b/EIPS/eip-7716.md @@ -0,0 +1,85 @@ +--- +eip: 7716 +title: Anti-correlation attestation penalties +description: Adjust penalties for missed attestations based on in-slot correlation of missed attestation +author: dapplion (@dapplion), Toni Wahrstätter (@nerolation), Vitalik Buterin (@vbuterin) +discussions-to: https://ethereum-magicians.org/t/eip-7716-anti-correlation-attestation-penalties/20137 +status: Draft +type: Standards Track +category: Core +created: 2024-05-25 +--- + + +## Abstract + +The decentralization of the validator set is one of the most important properties of Ethereum for credible neutrality and censorship resistance. By adjusting penalties to foster decentralization, diversification and fault-tolerance, this EIP proposes to adjust penalties in a way that more diversified entities get lower penalties while entities with high correlations in their setup face more servere ones. + + +## Motivation + +As of now, during times of usual network operation, there are no economic incentives to diversify node operations through using multiple different nodes, geographical locations, clients, ISP providers, etc., except for reducing the risk of penalties affecting all validators simultaneously, thereby limiting the impact to only a fraction of them. + +Attestation penalties are currently agnostic to other participation actions. This proposal scales attestation penalties as a function of other participants' actions. The goal is to decrease the profitability of participants that exhibit correlated behavior. + + + +## Specification + +| Parameter | Value | +| - | - | +| `PENALTY_ADJUSTMENT_FACTOR` | `4096` | +| `MAX_PENALTY_FACTOR` | `4` | + + +Add a variable `NET_EXCESS_PENALTIES` to the beacon state. + +Let `penalty_factor` be determined through + +``` +min( + (non_attesting_balance * PENALTY_ADJUSTMENT_FACTOR) // (NET_EXCESS_PENALTIES * total_active_balance + 1), + MAX_PENALTY_FACTOR +) +``` + +Let `NET_EXCESS_PENALTIES` be `max(1, NET_EXCESS_PENALTIES + penalty_factor) - 1` + + + +## Rationale + +### PENALTY_ADJUSTMENT_FACTOR + +This variable impacts the sensitivity of the `NET_EXCESS_PENALTIES`. + +Given stable participation, the `penalty_factor` is one. +If participation decreases, the `penalty_factor` will temporarily increase above one until `net_excess_penalties` catches up. +If participation increases, the `penalty_factor` will temporarily be zero until `net_excess_penalties` catches up. + +The `PENALTY_ADJUSTMENT_FACTOR` regulates how fast `net_excess_penalties` catches up. +In other words, the `PENALTY_ADJUSTMENT_FACTOR` determines the frequency that the penalty_factor is not one. + +A high `PENALTY_ADJUSTMENT_FACTOR` causes the `net_excess_penalties` to adjust slower. +A low `PENALTY_ADJUSTMENT_FACTOR` causes the `net_excess_penalties` to react more sensitive to changes in participation. + + +### `MAX_PENALTY_FACTOR` + +The `MAX_PENALTY_FACTOR` puts a ceiling onto the maximum factor with which the penalty for missed attestations is scaled to prevent overly harsh punishments. + + +## Backwards Compatibility + +This is a backwards incompatible adjustment of attestations rewards and penalties that requires a scheduled network upgrade. + + +## Security Considerations + +We acknowledge that splitting validator views can be leveraged as an attack to increase the `penalty_factor` for validators of consecutive slots with little risk for the proposer. +TBD. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). + From 12a391b1e5d5c51fe910646d47bdd21c52a34010 Mon Sep 17 00:00:00 2001 From: Marius van der Wijden Date: Tue, 11 Jun 2024 16:57:41 +0200 Subject: [PATCH 06/28] Add EIP: BLS signed transactions Merged by EIP-Bot. --- EIPS/eip-7591.md | 114 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 EIPS/eip-7591.md diff --git a/EIPS/eip-7591.md b/EIPS/eip-7591.md new file mode 100644 index 00000000000000..eba33456cf84b9 --- /dev/null +++ b/EIPS/eip-7591.md @@ -0,0 +1,114 @@ +--- +eip: 7591 +title: BLS signed transactions +description: Introduces a new transaction type signed with BLS signatures +author: Marius van der Wijden (@MariusVanDerWijden) +discussions-to: https://ethereum-magicians.org/t/eip-7591-bls-signed-transactions/19911 +status: Draft +type: Standards Track +category: Core +created: 2024-01-10 +--- + +## Abstract + +This EIP introduces a new [EIP-2718](./eip-2718.md) transaction type that is signed with BLS signatures. + +## Motivation + +The BLS signature scheme allows for easy aggregation and verification of aggregated signatures. +If a substantial number of transactions on mainnet were BLS signed transactions, we can aggregate signatures in a block and batch-verify them. +This will reduce growth of the chain history. + + +## Specification + +### Transaction Type + +The transaction type will have the following format: + +``` +[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender, signature] +``` + +with `sender` being the BLS public key of an account with address `address = [0:20](keccak256(sender))`. + +The signature value `signature` is calculated by constructing a BLS signature over the following digest: + +`tx_hash = keccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender]))`. + +### Header changes + +The block header will be amended with the `aggregated_sig` field, containing an aggregated signature of all BLS transactions in the block. + +The resulting RLP encoding of the header is therefore: + +``` +rlp([ + parent_hash, + 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash + coinbase, + state_root, + txs_root, + receipts_root, + logs_bloom, + 0, # difficulty + number, + gas_limit, + gas_used, + timestamp, + extradata, + prev_randao, + 0x0000000000000000, # nonce + base_fee_per_gas, + withdrawals_root, + blob_gas_used, + excess_blob_gas, + aggregated_sig, +]) +``` + +### Block changes + +The block building algorithm needs to be changed in order to built the aggregated signature of all BLS signed transactions in the block. +All transactions in the block will be added without the signature field set. + +Blocks with transactions containing the `signature` field MUST be rejected. + +On block verification, the `verifyAggregate` algorithm is used as follows: + +``` +valid = verifyAggregate(sender_1, ... sender_n, tx_hash_1, ... tx_hash_n, aggregated_sig) +``` + +## Rationale + +Removing the ECDSA signature from a transaction saves 65 bytes. The BLS public key is 48 bytes, the aggregated signature is 96 bytes. +Thus we save `-96 + (65-48)* #transactions` bytes per block. With ~7000 blocks per day, 1.000.000 transactions per day, the average block contains roughly 150 transactions. + +Thus we would save 2454 bytes or 2.4KB per block. This would equate to ~1.5% saving given an average block size of 160KB. + +In addition to the (admittedly meager) size savings for full nodes, the ability to add a new transaction type to utilize a different signature scheme does have some merit to it. This proposal shows that it would be possible to add for example a quantum safe signature scheme to ethereum. + +## Backwards Compatibility + +This EIP introduces backward incompatible changes to the block validation rule set on the execution layer and introduces a new transaction type and a new header field. Thus a hardfork is needed. + +## Security Considerations + +The messages signed via BLS are distinct (no hash collisions on the txhash), thus the aggregation is secure even without a proof-of-possession. +The public keys are not distinct which is not a problem in BLS. + +We assume that keccak256 and ECDSA and BLS are working as intended. +Suppose we have two addresses `address_1 = keccak256(pk_ecdsa)` and `address_2 = keccak(pk_bls)` with `address_1 == address_2`. +We know that `pk_ecdsa` must be equal to `pk_bls` (follows from keccak). +This would mean that we would either be able to find `x` with `g_bls^x = y` for a given `y` (violates the security of BLS) +or find `z` with `d_ecdsa^z = y` (violates the security of ECDSA). + +Thus it would be impossible (with greater than negligble probability) to find two private keys, one in ECDSA and one in BLS that control the same account. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). + + From 13d645f17c754bcbdd636d73022df4bce8628a75 Mon Sep 17 00:00:00 2001 From: William Morriss Date: Tue, 11 Jun 2024 10:22:39 -0500 Subject: [PATCH 07/28] Add EIP: Increase calldata cost Merged by EIP-Bot. --- EIPS/eip-7703.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 EIPS/eip-7703.md diff --git a/EIPS/eip-7703.md b/EIPS/eip-7703.md new file mode 100644 index 00000000000000..ffeb6abd5e56d6 --- /dev/null +++ b/EIPS/eip-7703.md @@ -0,0 +1,43 @@ +--- +eip: 7703 +title: Increase calldata cost +description: Increase calldata cost to decrease the maximum block size +author: William Morriss (@wjmelements) +discussions-to: https://ethereum-magicians.org/t/eip-7703-increase-calldata-cost/19933 +status: Draft +type: Standards Track +category: Core +created: 2024-05-07 +--- + +## Abstract + +An adjustment in the Ethereum calldata cost which reduces the maximum possible block size and allows a higher block gas limit. + +## Motivation + +Larger blocks take longer to propagate through the network. +In this way, the maximium potential block size is constraining the block gas limit. +Therefore, in order to safely increase the block gas limit, the calldata gas must be increased. + +## Specification + +* Increase `G_CALLDATAZERO` from 4 to 12. +* Increase `G_CALLDATANONZERO` from 16 to 48. + +## Rationale + +Tripling the gas cost of calldata reduces the maximimum possible block size by a factor of three. + +## Backwards Compatibility + +Activation can cause some transactions to revert due to the increased gas costs. +Ahead of activation, `eth_estimateGas` could be calculated using the new parameters in order to provide results viable for activation, avoiding out-of-gas reverts. + +## Security Considerations + +No security issues have been found. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 1cf8266a3872855c405bec89349c145b232c00a9 Mon Sep 17 00:00:00 2001 From: William Law Date: Tue, 11 Jun 2024 11:03:54 -0700 Subject: [PATCH 08/28] Update EIP-7591: fix eip 7591 typo Merged by EIP-Bot. --- EIPS/eip-7591.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7591.md b/EIPS/eip-7591.md index eba33456cf84b9..d688c489a8e2e0 100644 --- a/EIPS/eip-7591.md +++ b/EIPS/eip-7591.md @@ -23,6 +23,8 @@ This will reduce growth of the chain history. ## Specification +BLS_TX_TYPE = Bytes1(0x04) + ### Transaction Type The transaction type will have the following format: @@ -35,7 +37,7 @@ with `sender` being the BLS public key of an account with address `address = [0: The signature value `signature` is calculated by constructing a BLS signature over the following digest: -`tx_hash = keccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender]))`. +`tx_hash = keccak256(BLS_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender]))`. ### Header changes From a763aff6504558b38ff82b2ea619154e15a02e1f Mon Sep 17 00:00:00 2001 From: Satyajit Das Date: Wed, 12 Jun 2024 02:56:37 +0530 Subject: [PATCH 09/28] Update EIP-5806: grammar correction Merged by EIP-Bot. --- EIPS/eip-5806.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5806.md b/EIPS/eip-5806.md index 201f458b05935f..bd6fef9d8d921c 100644 --- a/EIPS/eip-5806.md +++ b/EIPS/eip-5806.md @@ -1,7 +1,7 @@ --- eip: 5806 title: Delegate transaction -description: Adds a new transaction type that allows a EOAs to execute arbitrary code through delegation +description: Adds a new transaction type that allows EOAs to execute arbitrary code through delegation author: Hadrien Croubois (@Amxx) discussions-to: https://ethereum-magicians.org/t/eip-5806-delegate-transaction/11409 status: Draft From ec89dd61af46bd590c087cc0a8a86b856e391423 Mon Sep 17 00:00:00 2001 From: Etan Kissling Date: Wed, 12 Jun 2024 14:36:22 +0200 Subject: [PATCH 10/28] Update EIP-6493: Cleanups for latest `StableContainer` specs Merged by EIP-Bot. --- EIPS/eip-6493.md | 76 ++++++++++++++++---------------- assets/eip-6493/convert.py | 16 +++---- assets/eip-6493/convert_tests.py | 16 +++++++ assets/eip-6493/ssz_types.py | 70 ++++++++++++++--------------- assets/eip-6493/tx_hashes.py | 4 +- 5 files changed, 98 insertions(+), 84 deletions(-) diff --git a/EIPS/eip-6493.md b/EIPS/eip-6493.md index e3156e2eb3ec61..466c36eba13040 100644 --- a/EIPS/eip-6493.md +++ b/EIPS/eip-6493.md @@ -117,7 +117,7 @@ class TransactionPayload(StableContainer[MAX_TRANSACTION_PAYLOAD_FIELDS]): gas: Optional[uint64] to: Optional[ExecutionAddress] value: Optional[uint256] - input_: ByteList[MAX_CALLDATA_SIZE] + input_: Optional[ByteList[MAX_CALLDATA_SIZE]] # EIP-2930 access_list: Optional[List[AccessTuple, MAX_ACCESS_LIST_SIZE]] @@ -147,6 +147,10 @@ class BlobFeesPerGas(Profile[FeesPerGas]): regular: FeePerGas blob: FeePerGas +class EcdsaTransactionSignature(Profile[TransactionSignature]): + from_: Optional[ExecutionAddress] + ecdsa_signature: Optional[ByteVector[ECDSA_SIGNATURE_SIZE]] + class ReplayableTransactionPayload(Profile[TransactionPayload]): type_: TransactionType nonce: uint64 @@ -158,7 +162,7 @@ class ReplayableTransactionPayload(Profile[TransactionPayload]): class ReplayableTransaction(Container): payload: ReplayableTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class LegacyTransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -172,7 +176,7 @@ class LegacyTransactionPayload(Profile[TransactionPayload]): class LegacyTransaction(Container): payload: LegacyTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class Eip2930TransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -187,7 +191,7 @@ class Eip2930TransactionPayload(Profile[TransactionPayload]): class Eip2930Transaction(Container): payload: Eip2930TransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class Eip1559TransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -203,7 +207,7 @@ class Eip1559TransactionPayload(Profile[TransactionPayload]): class Eip1559Transaction(Container): payload: Eip1559TransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class Eip4844TransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -220,7 +224,7 @@ class Eip4844TransactionPayload(Profile[TransactionPayload]): class Eip4844Transaction(Container): payload: Eip4844TransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class BasicTransactionPayload(Profile[TransactionPayload]): chain_id: ChainId @@ -235,7 +239,7 @@ class BasicTransactionPayload(Profile[TransactionPayload]): class BasicTransaction(Container): payload: BasicTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class BlobTransactionPayload(Profile[TransactionPayload]): chain_id: ChainId @@ -251,36 +255,33 @@ class BlobTransactionPayload(Profile[TransactionPayload]): class BlobTransaction(Container): payload: BlobTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature -class AnyTransaction(OneOf[Transaction]): - @classmethod - def select_from_base(cls, value: Transaction) -> Type[Transaction]: - if value.payload.type_ is None: - if value.payload.blob_versioned_hashes is not None: - return BlobTransaction - return BasicTransaction +def select_transaction_profile(cls, value: Transaction) -> Type[Profile]: + if value.payload.type_ is None: + if value.payload.blob_versioned_hashes is not None: + return BlobTransaction + return BasicTransaction - if value.payload.type_ == TRANSACTION_TYPE_EIP4844: - return Eip4844Transaction + if value.payload.type_ == TRANSACTION_TYPE_EIP4844: + return Eip4844Transaction - if value.payload.type_ == TRANSACTION_TYPE_EIP1559: - return Eip1559Transaction + if value.payload.type_ == TRANSACTION_TYPE_EIP1559: + return Eip1559Transaction - if value.payload.type_ == TRANSACTION_TYPE_EIP2930: - return Eip2930Transaction + if value.payload.type_ == TRANSACTION_TYPE_EIP2930: + return Eip2930Transaction - if value.payload.chain_id is not None: - return LegacyTransaction + if value.payload.chain_id is not None: + return LegacyTransaction - return ReplayableTransaction + return ReplayableTransaction ``` Future specifications MAY: - Append fields to `TransactionPayload` and `TransactionSignature` -- Convert existing fields to `Optional` -- Define new `Profile` types and update `select_from_base` logic +- Adjust `Profile` types and update `select_transaction_profile` logic Such changes [do not affect](./eip-7495.md) how existing transactions serialize or merkleize. @@ -344,7 +345,7 @@ def ecdsa_recover_from_address(signature: ByteVector[ECDSA_SIGNATURE_SIZE], uncompressed = public_key.serialize(compressed=False) return ExecutionAddress(keccak(uncompressed[1:])[12:]) -def validate_transaction(tx: AnyTransaction): +def validate_transaction(tx): ecdsa_validate_signature(tx.signature.ecdsa_signature) assert tx.signature.from_ == ecdsa_recover_from_address( tx.signature.ecdsa_signature, @@ -401,10 +402,10 @@ class Log(Container): class Receipt(StableContainer[MAX_RECEIPT_FIELDS]): root: Optional[Hash32] - gas_used: uint64 + gas_used: Optional[uint64] contract_address: Optional[ExecutionAddress] - logs_bloom: ByteVector[BYTES_PER_LOGS_BLOOM] - logs: List[Log, MAX_LOGS_PER_RECEIPT] + logs_bloom: Optional[ByteVector[BYTES_PER_LOGS_BLOOM]] + logs: Optional[List[Log, MAX_LOGS_PER_RECEIPT]] # EIP-658 status: Optional[boolean] @@ -427,20 +428,17 @@ class BasicReceipt(Profile[Receipt]): logs: List[Log, MAX_LOGS_PER_RECEIPT] status: boolean -class AnyReceipt(OneOf[Receipt]): - @classmethod - def select_from_base(cls, value: Receipt) -> Type[Receipt]: - if value.status is not None: - return BasicReceipt +def select_receipt_profile(value: Receipt) -> Type[Profile]: + if value.status is not None: + return BasicReceipt - return HomesteadReceipt + return HomesteadReceipt ``` Future specifications MAY: - Add fields to the end of `Receipt` -- Convert existing fields to `Optional` -- Define new `Profile` types and update `select_from_base` logic +- Adjust `Profile` types and update `select_receipt_profile` logic Such changes [do not affect](./eip-7495.md) how existing receipts serialize or merkleize. @@ -539,7 +537,7 @@ If other SSZ objects are being signed in the future, e.g., messages, it must be ### What about EIP-2718 transaction types? -All SSZ transactions (including future ones) share the single [EIP-2718](./eip-2718.md) transaction type `TRANSACTION_TYPE_SSZ`. Future features can introduce new optional fields as well as new allowed combination of optional fields, as determined by `select_from_base` in `AnyTransaction`. +All SSZ transactions (including future ones) share the single [EIP-2718](./eip-2718.md) transaction type `TRANSACTION_TYPE_SSZ`. Future features can introduce new optional fields as well as new allowed combination of optional fields, as determined by `select_transaction_profile`. This also reduces combinatorial explosion; for example, the `access_list` property could be made optional for all SSZ transactions without having to double the number of defined transaction types. diff --git a/assets/eip-6493/convert.py b/assets/eip-6493/convert.py index ff7c5b114174fc..8d6ed51d1eb4ec 100644 --- a/assets/eip-6493/convert.py +++ b/assets/eip-6493/convert.py @@ -3,7 +3,7 @@ from rlp_types import * from ssz_types import * -def upgrade_rlp_transaction_to_ssz(pre_bytes: bytes) -> AnyTransaction: +def upgrade_rlp_transaction_to_ssz(pre_bytes: bytes): type_ = pre_bytes[0] if type_ == 0x03: # EIP-4844 @@ -39,7 +39,7 @@ def upgrade_rlp_transaction_to_ssz(pre_bytes: bytes) -> AnyTransaction: ), blob_versioned_hashes=pre.blob_versioned_hashes, ), - signature=TransactionSignature( + signature=EcdsaTransactionSignature( from_=from_, ecdsa_signature=ecdsa_signature, ), @@ -75,7 +75,7 @@ def upgrade_rlp_transaction_to_ssz(pre_bytes: bytes) -> AnyTransaction: regular=pre.max_priority_fee_per_gas, ), ), - signature=TransactionSignature( + signature=EcdsaTransactionSignature( from_=from_, ecdsa_signature=ecdsa_signature, ), @@ -108,7 +108,7 @@ def upgrade_rlp_transaction_to_ssz(pre_bytes: bytes) -> AnyTransaction: storage_keys=access_tuple[1] ) for access_tuple in pre.accessList], ), - signature=TransactionSignature( + signature=EcdsaTransactionSignature( from_=from_, ecdsa_signature=ecdsa_signature, ), @@ -138,7 +138,7 @@ def upgrade_rlp_transaction_to_ssz(pre_bytes: bytes) -> AnyTransaction: value=pre.value, input_=pre.data, ), - signature=TransactionSignature( + signature=EcdsaTransactionSignature( from_=from_, ecdsa_signature=ecdsa_signature, ), @@ -156,7 +156,7 @@ def upgrade_rlp_transaction_to_ssz(pre_bytes: bytes) -> AnyTransaction: value=pre.value, input_=pre.data, ), - signature=TransactionSignature( + signature=EcdsaTransactionSignature( from_=from_, ecdsa_signature=ecdsa_signature, ), @@ -179,7 +179,7 @@ def compute_contract_address(from_: ExecutionAddress, def upgrade_rlp_receipt_to_ssz(pre_bytes: bytes, prev_cumulative_gas_used: uint64, - transaction: AnyTransaction) -> AnyReceipt: + transaction): type_ = pre_bytes[0] if type_ in (0x03, 0x02, 0x01): # EIP-4844, EIP-1559, EIP-2930 @@ -224,7 +224,7 @@ def upgrade_rlp_receipt_to_ssz(pre_bytes: bytes, ) def upgrade_rlp_receipts_to_ssz(pre_bytes_list: PyList[bytes], - transactions: PyList[AnyTransaction]) -> PyList[AnyReceipt]: + transactions: PyList) -> PyList: receipts = [] cumulative_gas_used = 0 for i, pre_bytes in enumerate(pre_bytes_list): diff --git a/assets/eip-6493/convert_tests.py b/assets/eip-6493/convert_tests.py index cd0d505c6c91d1..93ad463c035c16 100644 --- a/assets/eip-6493/convert_tests.py +++ b/assets/eip-6493/convert_tests.py @@ -75,3 +75,19 @@ class Test: stable_receipt = Receipt(backing=receipts[i].get_backing()) assert stable_receipt.encode_bytes() == tests[i].ssz_receipt_bytes + +transactions_stable = [Transaction(backing=transaction.get_backing()) for transaction in transactions] +assert select_transaction_profile(transactions_stable[0]) is ReplayableTransaction +assert select_transaction_profile(transactions_stable[1]) is ReplayableTransaction +assert select_transaction_profile(transactions_stable[2]) is LegacyTransaction +assert select_transaction_profile(transactions_stable[3]) is Eip2930Transaction +assert select_transaction_profile(transactions_stable[4]) is Eip1559Transaction +assert select_transaction_profile(transactions_stable[5]) is Eip1559Transaction + +receipts_stable = [Receipt(backing=receipt.get_backing()) for receipt in receipts] +assert select_receipt_profile(receipts_stable[0]) is HomesteadReceipt +assert select_receipt_profile(receipts_stable[1]) is BasicReceipt +assert select_receipt_profile(receipts_stable[2]) is BasicReceipt +assert select_receipt_profile(receipts_stable[3]) is BasicReceipt +assert select_receipt_profile(receipts_stable[4]) is BasicReceipt +assert select_receipt_profile(receipts_stable[5]) is BasicReceipt diff --git a/assets/eip-6493/ssz_types.py b/assets/eip-6493/ssz_types.py index 6c0f457024f3aa..25ac152f091855 100644 --- a/assets/eip-6493/ssz_types.py +++ b/assets/eip-6493/ssz_types.py @@ -11,7 +11,7 @@ from remerkleable.complex import Container, List from rlp_types import Hash32 from secp256k1 import ECDSA, PublicKey -from stable_container import OneOf, Profile, StableContainer +from stable_container import Profile, StableContainer class TransactionType(uint8): pass @@ -65,7 +65,7 @@ class TransactionPayload(StableContainer[MAX_TRANSACTION_PAYLOAD_FIELDS]): gas: Optional[uint64] to: Optional[ExecutionAddress] value: Optional[uint256] - input_: ByteList[MAX_CALLDATA_SIZE] + input_: Optional[ByteList[MAX_CALLDATA_SIZE]] # EIP-2930 access_list: Optional[List[AccessTuple, MAX_ACCESS_LIST_SIZE]] @@ -91,6 +91,10 @@ class BlobFeesPerGas(Profile[FeesPerGas]): regular: FeePerGas blob: FeePerGas +class EcdsaTransactionSignature(Profile[TransactionSignature]): + from_: Optional[ExecutionAddress] + ecdsa_signature: Optional[ByteVector[ECDSA_SIGNATURE_SIZE]] + class ReplayableTransactionPayload(Profile[TransactionPayload]): type_: TransactionType nonce: uint64 @@ -102,7 +106,7 @@ class ReplayableTransactionPayload(Profile[TransactionPayload]): class ReplayableTransaction(Container): payload: ReplayableTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class LegacyTransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -116,7 +120,7 @@ class LegacyTransactionPayload(Profile[TransactionPayload]): class LegacyTransaction(Container): payload: LegacyTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class Eip2930TransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -131,7 +135,7 @@ class Eip2930TransactionPayload(Profile[TransactionPayload]): class Eip2930Transaction(Container): payload: Eip2930TransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class Eip1559TransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -147,7 +151,7 @@ class Eip1559TransactionPayload(Profile[TransactionPayload]): class Eip1559Transaction(Container): payload: Eip1559TransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class Eip4844TransactionPayload(Profile[TransactionPayload]): type_: TransactionType @@ -164,7 +168,7 @@ class Eip4844TransactionPayload(Profile[TransactionPayload]): class Eip4844Transaction(Container): payload: Eip4844TransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class BasicTransactionPayload(Profile[TransactionPayload]): chain_id: ChainId @@ -179,7 +183,7 @@ class BasicTransactionPayload(Profile[TransactionPayload]): class BasicTransaction(Container): payload: BasicTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature class BlobTransactionPayload(Profile[TransactionPayload]): chain_id: ChainId @@ -195,29 +199,27 @@ class BlobTransactionPayload(Profile[TransactionPayload]): class BlobTransaction(Container): payload: BlobTransactionPayload - signature: TransactionSignature + signature: EcdsaTransactionSignature -class AnyTransaction(OneOf[Transaction]): - @classmethod - def select_from_base(cls, value: Transaction) -> Type[Transaction]: - if value.payload.type_ is None: - if value.payload.blob_versioned_hashes is not None: - return BlobTransaction - return BasicTransaction +def select_transaction_profile(value: Transaction) -> Type[Profile]: + if value.payload.type_ is None: + if value.payload.blob_versioned_hashes is not None: + return BlobTransaction + return BasicTransaction - if value.payload.type_ == TRANSACTION_TYPE_EIP4844: - return Eip4844Transaction + if value.payload.type_ == TRANSACTION_TYPE_EIP4844: + return Eip4844Transaction - if value.payload.type_ == TRANSACTION_TYPE_EIP1559: - return Eip1559Transaction + if value.payload.type_ == TRANSACTION_TYPE_EIP1559: + return Eip1559Transaction - if value.payload.type_ == TRANSACTION_TYPE_EIP2930: - return Eip2930Transaction + if value.payload.type_ == TRANSACTION_TYPE_EIP2930: + return Eip2930Transaction - if value.payload.chain_id is not None: - return LegacyTransaction + if value.payload.chain_id is not None: + return LegacyTransaction - return ReplayableTransaction + return ReplayableTransaction class Root(Bytes32): pass @@ -273,7 +275,7 @@ def ecdsa_recover_from_address(signature: ByteVector[ECDSA_SIGNATURE_SIZE], from tx_hashes import compute_sig_hash, compute_tx_hash -def validate_transaction(tx: AnyTransaction): +def validate_transaction(tx): ecdsa_validate_signature(tx.signature.ecdsa_signature) assert tx.signature.from_ == ecdsa_recover_from_address( tx.signature.ecdsa_signature, @@ -293,10 +295,10 @@ class Log(Container): class Receipt(StableContainer[MAX_RECEIPT_FIELDS]): root: Optional[Hash32] - gas_used: uint64 + gas_used: Optional[uint64] contract_address: Optional[ExecutionAddress] - logs_bloom: ByteVector[BYTES_PER_LOGS_BLOOM] - logs: List[Log, MAX_LOGS_PER_RECEIPT] + logs_bloom: Optional[ByteVector[BYTES_PER_LOGS_BLOOM]] + logs: Optional[List[Log, MAX_LOGS_PER_RECEIPT]] # EIP-658 status: Optional[boolean] @@ -315,10 +317,8 @@ class BasicReceipt(Profile[Receipt]): logs: List[Log, MAX_LOGS_PER_RECEIPT] status: boolean -class AnyReceipt(OneOf[Receipt]): - @classmethod - def select_from_base(cls, value: Receipt) -> Type[Receipt]: - if value.status is not None: - return BasicReceipt +def select_receipt_profile(value: Receipt) -> Type[Profile]: + if value.status is not None: + return BasicReceipt - return HomesteadReceipt + return HomesteadReceipt diff --git a/assets/eip-6493/tx_hashes.py b/assets/eip-6493/tx_hashes.py index 66503f9f255a6f..c71a7450f7fe38 100644 --- a/assets/eip-6493/tx_hashes.py +++ b/assets/eip-6493/tx_hashes.py @@ -102,7 +102,7 @@ def recover_eip4844_rlp_transaction(tx: Eip4844Transaction) -> Eip4844RlpTransac signature_s=s, ) -def compute_sig_hash(tx: AnyTransaction) -> Hash32: +def compute_sig_hash(tx) -> Hash32: if ( isinstance(tx, BasicTransaction) or isinstance(tx, BlobTransaction) @@ -129,7 +129,7 @@ def compute_sig_hash(tx: AnyTransaction) -> Hash32: pre = recover_replayable_rlp_transaction(tx) return compute_legacy_sig_hash(pre) -def compute_tx_hash(tx: AnyTransaction) -> Hash32: +def compute_tx_hash(tx) -> Hash32: if ( isinstance(tx, BasicTransaction) or isinstance(tx, BlobTransaction) From 83e11f01738635a400d8b6d12c16c06976492cb4 Mon Sep 17 00:00:00 2001 From: Etan Kissling Date: Thu, 13 Jun 2024 08:13:24 +0200 Subject: [PATCH 11/28] Update EIP-7495: Remove redundant `is_active_field` helper Merged by EIP-Bot. --- EIPS/eip-7495.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-7495.md b/EIPS/eip-7495.md index 9dbf2fbc58fb83..f76cf5423491f4 100644 --- a/EIPS/eip-7495.md +++ b/EIPS/eip-7495.md @@ -75,12 +75,9 @@ Serialization of `StableContainer[N]` is defined similarly to the [existing logi - If variable-length fields are serialized, their offsets are relative to the start of serialized active fields, after the `Bitvector[N]` ```python -def is_active_field(element): - return not is_optional(element) or element is not None - # Determine active fields -active_fields = Bitvector[N](([is_active_field(element) for element in value] + [False] * N)[:N]) -active_values = [element for element in value if is_active_field(element)] +active_fields = Bitvector[N](([element is not None for element in value] + [False] * N)[:N]) +active_values = [element for element in value if element is not None] # Recursively serialize fixed_parts = [serialize(element) if not is_variable_size(element) else None for element in active_values] @@ -120,7 +117,7 @@ To merkleize a `StableContainer[N]`, a `Bitvector[N]` is constructed, indicating Merkleization `hash_tree_root(value)` of an object `value` is extended with: -- `mix_in_aux(merkleize(([hash_tree_root(element) if is_active_field(element) else Bytes32() for element in value.data] + [Bytes32()] * N)[:N]), hash_tree_root(value.active_fields))` if `value` is a `StableContainer[N]`. +- `mix_in_aux(merkleize(([hash_tree_root(element) if element is not None else Bytes32() for element in value.data] + [Bytes32()] * N)[:N]), hash_tree_root(value.active_fields))` if `value` is a `StableContainer[N]`. ### `Profile[B]` From b530fb418ee58043323afa898c2f0466da7b7515 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Thu, 13 Jun 2024 08:05:44 -0700 Subject: [PATCH 12/28] Update EIP-7600: Add PeerDAS Merged by EIP-Bot. --- EIPS/eip-7600.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-7600.md b/EIPS/eip-7600.md index a099bd5b3974ac..ebd72214997d82 100644 --- a/EIPS/eip-7600.md +++ b/EIPS/eip-7600.md @@ -7,12 +7,12 @@ discussions-to: https://ethereum-magicians.org/t/eip-7600-hardfork-meta-prague-e status: Draft type: Meta created: 2024-01-18 -requires: 2537, 2935, 6110, 7002, 7251, 7549, 7685, 7692, 7702 +requires: 2537, 2935, 6110, 7002, 7251, 7549, 7594, 7685, 7692, 7702 --- ## Abstract -This Meta EIP lists the EIPs formally considered for and included in the Prague/Electra network upgrade. +This Meta EIP lists the EIPs formally considered for and included in the Prague/Electra network upgrade. ## Specification @@ -24,6 +24,7 @@ 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-7594](./eip-7594.md): PeerDAS - Peer Data Availability Sampling * [EIP-7685](./eip-7685.md): General purpose execution layer requests * [EIP-7702](./eip-7702.md): Set EOA account code for one transaction * EOF EIPs listed as part of [EIP-7692](./eip-7692.md), namely: @@ -49,7 +50,7 @@ This Meta EIP lists the EIPs formally considered for and included in the Prague/ #### Consensus Layer -EIP-6110, EIP-7002 EIP-7251 and EIP-7549 require changes to Ethereum's consensus layer. While the EIPs present an overview of these changes, the full specifications can be found in the `specs/electra` and `specs/_features` directories of the `ethereum/consensus-specs` repository. +EIP-6110, EIP-7002 EIP-7251, EIP-7549 and EIP-7594 require changes to Ethereum's consensus layer. While the EIPs present an overview of these changes, the full specifications can be found in the `specs/electra` and `specs/_features` directories of the `ethereum/consensus-specs` repository. #### Execution Layer From b27b3f1c1b8252d178c0a7d4bcf6480c8bcb2159 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 08:16:13 -0700 Subject: [PATCH 13/28] Update EIP-7685: Move to Review Merged by EIP-Bot. --- EIPS/eip-7685.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7685.md b/EIPS/eip-7685.md index 12a6e956578bf0..d2f13be207ff69 100644 --- a/EIPS/eip-7685.md +++ b/EIPS/eip-7685.md @@ -4,7 +4,7 @@ title: General purpose execution layer requests description: A general purpose bus for sharing EL triggered requests with the CL author: lightclient (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-7685-general-purpose-execution-layer-requests/19668 -status: Draft +status: Review type: Standards Track category: Core created: 2024-04-14 From f3620fabfa303fd84ee84522c744ae4a4da65cdf Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 08:33:57 -0700 Subject: [PATCH 14/28] Update EIP-7002: Move to Review (#8654) Update eip-7002.md --- EIPS/eip-7002.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7002.md b/EIPS/eip-7002.md index 47b7114a8819e3..11a709c46fe658 100644 --- a/EIPS/eip-7002.md +++ b/EIPS/eip-7002.md @@ -4,7 +4,7 @@ title: Execution layer triggerable withdrawals description: Allow validators to trigger exits and partial withdrawals via their execution layer (0x01) withdrawal credentials author: Danny Ryan (@djrtwo), Mikhail Kalinin (@mkalinin), Ansgar Dietrichs (@adietrichs), Hsiao-Wei Wang (@hwwhww), lightclient (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-7002-execution-layer-triggerable-exits/14195 -status: Draft +status: Review type: Standards Track category: Core created: 2023-05-09 From 85ed6b1056247cfe529d97caea671f104392cd75 Mon Sep 17 00:00:00 2001 From: Lion - dapplion <35266934+dapplion@users.noreply.github.com> Date: Mon, 17 Jun 2024 17:34:34 +0200 Subject: [PATCH 15/28] Update EIP-7251: Move to Review (#8647) Move EIP-7251 to Review --- EIPS/eip-7251.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7251.md b/EIPS/eip-7251.md index 1859ce2a844b46..b947bdf83501e6 100644 --- a/EIPS/eip-7251.md +++ b/EIPS/eip-7251.md @@ -4,7 +4,7 @@ title: Increase the MAX_EFFECTIVE_BALANCE description: Allow validators to have larger effective balances, while maintaining the 32 ETH lower bound. author: mike (@michaelneuder), Francesco (@fradamt), dapplion (@dapplion), Mikhail (@mkalinin), Aditya (@adiasg), Justin (@justindrake), lightclient (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-7251-increase-the-max-effective-balance/15982 -status: Draft +status: Review type: Standards Track category: Core created: 2023-06-28 From 32cdb1851f2c3262d59f4002ad0afc24c1fa5c85 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 08:38:04 -0700 Subject: [PATCH 16/28] Update EIP-7069: Move to Review Merged by EIP-Bot. --- EIPS/eip-7069.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-7069.md b/EIPS/eip-7069.md index 76ed48f905a9d8..04e1b3800d70f7 100644 --- a/EIPS/eip-7069.md +++ b/EIPS/eip-7069.md @@ -4,7 +4,7 @@ title: Revamped CALL instructions description: Introduce EXTCALL, EXTDELEGATECALL and EXTSTATICCALL with simplified semantics author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast), Danno Ferrin (@shemnon), Andrei Maiboroda (@gumb0), Charles Cooper (@charles-cooper) discussions-to: https://ethereum-magicians.org/t/eip-revamped-call-instructions/14432 -status: Draft +status: Review type: Standards Track category: Core created: 2023-05-05 @@ -97,11 +97,11 @@ In case this EIP is included as part of the greater EOF upgrade, execution seman Execution of `RETURNDATACOPY` which is not in EOF formatted code (i.e. is in legacy code) is not changed. - +**TODO:** Clarify which side (caller/callee) is gas deducted from and where an error originates from. - +**TODO:** Mention gas refunds? - +**TODO:** Consider option where non-calldata value transfer is not allowed, but there's a specific `TRANSFER`/`PAY` function for that. Would simplify the logic greatly. ## Rationale From d8b7911d0dbf148685b095066022e2ed25256150 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 08:38:12 -0700 Subject: [PATCH 17/28] Update EIP-7698: Move to Review Merged by EIP-Bot. --- EIPS/eip-7698.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7698.md b/EIPS/eip-7698.md index 095d1311a2dd83..f9cf467e3eba09 100644 --- a/EIPS/eip-7698.md +++ b/EIPS/eip-7698.md @@ -4,7 +4,7 @@ title: EOF - Creation transaction description: Deploy EOF contracts using creation transactions author: Piotr Dobaczewski (@pdobacz), Andrei Maiboroda (@gumb0), Paweł Bylica (@chfast), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-7698-eof-creation-transaction/19784 -status: Draft +status: Review type: Standards Track category: Core created: 2024-04-24 From f7a9665958369e4fe3f7fce3486e68272a13629c Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 08:38:36 -0700 Subject: [PATCH 18/28] Update EIP-7547: Move to Review Merged by EIP-Bot. --- EIPS/eip-7547.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7547.md b/EIPS/eip-7547.md index b5edb63aae070e..7550f1a9fbf791 100644 --- a/EIPS/eip-7547.md +++ b/EIPS/eip-7547.md @@ -4,7 +4,7 @@ title: Inclusion lists description: Add an inclusion list mechanism to allow forced transaction inclusion. author: mike (@michaelneuder), Vitalik (@vbuterin), Francesco (@fradamt), Terence (@terencechain), potuz (@potuz), Manav (@manav2401) discussions-to: https://ethereum-magicians.org/t/eip-7547-inclusion-lists/17474 -status: Draft +status: Review type: Standards Track category: Core created: 2023-10-24 From ad9bf2bd83c1018f0a892e03ad3b524cc441257e Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 09:01:17 -0700 Subject: [PATCH 19/28] Update EIP-7692: Move to Review (#8658) Update eip-7692.md --- EIPS/eip-7692.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7692.md b/EIPS/eip-7692.md index e9280913a538b2..f0e7661ee0d16e 100644 --- a/EIPS/eip-7692.md +++ b/EIPS/eip-7692.md @@ -4,7 +4,7 @@ title: EVM Object Format (EOFv1) Meta description: List of EIPs belonging to the EOFv1 proposal author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast), Andrei Maiboroda (@gumb0), Piotr Dobaczewski (@pdobacz), Danno Ferrin (@shemnon) discussions-to: https://ethereum-magicians.org/t/eip-7692-evm-object-format-eof-meta/19686 -status: Draft +status: Review type: Meta created: 2024-04-17 requires: 663, 3540, 3670, 4200, 4750, 5450, 6206, 7069, 7480, 7620, 7698 From 16fb0b0f194164f5a15964b7c024483a738b612a Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 09:05:36 -0700 Subject: [PATCH 20/28] Update EIP-7702: Move to Review Merged by EIP-Bot. --- EIPS/eip-7702.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 7357ff1f3f176a..b04782b4d2bfcd 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -4,7 +4,7 @@ title: Set EOA account code for one transaction description: Add a new tx type that sets the code for an EOA during one transaction execution author: Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), Matt Garnett (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923 -status: Draft +status: Review type: Standards Track category: Core created: 2024-05-07 @@ -147,7 +147,7 @@ Specifically: * Hence, it avoids the problem of "creating two separate code ecosystems", because to a large extent they would be the same ecosystem. There would be some workflows that require kludges under this solution that would be better done in some different "more native" under "endgame AA", but this is relatively a small subset. * It does not require adding any opcodes, that would become dangling and useless in a post-EOA world. * It allows EOAs to temporarily convert themselves into contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`. -* Once this is implemented, [EIP-5003](./eip-5003.md) is "only one line of code": just add a flag to not set the code back to empty at the end. +* Once this is implemented, allowing EOAs to migrate permanently is "only one line of code": just add a flag to not set the code back to empty at the end. ## Backwards Compatibility From 699cb15fc5ab7812d44266013876d9de81d05742 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 09:06:01 -0700 Subject: [PATCH 21/28] Update EIP-6110: Move to Review (#8653) Update eip-6110.md --- EIPS/eip-6110.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6110.md b/EIPS/eip-6110.md index 70a6ec21f62937..e6328d399ea94d 100644 --- a/EIPS/eip-6110.md +++ b/EIPS/eip-6110.md @@ -4,7 +4,7 @@ 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), Peter Davies (@petertdavies) discussions-to: https://ethereum-magicians.org/t/eip-6110-supply-validator-deposits-on-chain/12072 -status: Draft +status: Review type: Standards Track category: Core created: 2022-12-09 From 674813fb93adcddb6a70e2098d972ecae5676b93 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 09:06:18 -0700 Subject: [PATCH 22/28] Update EIP-2935: Move to Review (#8652) * Update eip-2935.md * 2935: rm link to 210 --------- Co-authored-by: lightclient --- EIPS/eip-2935.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-2935.md b/EIPS/eip-2935.md index 6d78850857be9b..68d54a80a4f5b9 100644 --- a/EIPS/eip-2935.md +++ b/EIPS/eip-2935.md @@ -4,7 +4,7 @@ title: Serve historical block hashes from state description: Store and serve last 8192 block hashes as storage slots of a system contract to allow for stateless execution author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer) discussions-to: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565 -status: Draft +status: Review type: Standards Track category: Core created: 2020-09-03 @@ -187,7 +187,7 @@ Since `BLOCKHASH` semantics doesn't change, this EIP has no impact on `BLOCKHASH ## Rationale -Very similar ideas were proposed before in [EIP-210](./eip-210.md) et al. This EIP is a simplification, removing two sources of needless complexity: +Very similar ideas were proposed before. This EIP is a simplification, removing two sources of needless complexity: 1. Having a tree-like structure with multiple layers as opposed to a single list 2. Writing the EIP in EVM code From 4353b530c3701b22d7d2b46f940d8b6608d7aa8a Mon Sep 17 00:00:00 2001 From: lightclient <14004106+lightclient@users.noreply.github.com> Date: Mon, 17 Jun 2024 10:19:19 -0600 Subject: [PATCH 23/28] Update EIP-7594: Move to Review (#8671) 7594: move to review --- EIPS/eip-7594.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7594.md b/EIPS/eip-7594.md index 49c8af7e2fab48..3d9747d143e688 100644 --- a/EIPS/eip-7594.md +++ b/EIPS/eip-7594.md @@ -4,7 +4,7 @@ title: PeerDAS - Peer Data Availability Sampling description: Introducing simple DAS utilizing gossip distribution and peer requests author: Danny Ryan (@djrtwo), Dankrad Feist (@dankrad), Francesco D'Amato (@fradamt), Hsiao-Wei Wang (@hwwhww) discussions-to: https://ethereum-magicians.org/t/eip-7594-peerdas-peer-data-availability-sampling/18215 -status: Draft +status: Review type: Standards Track category: Networking created: 2024-01-12 From 9ae9c9b9d55640da9a986949704beb8863097f10 Mon Sep 17 00:00:00 2001 From: lightclient <14004106+lightclient@users.noreply.github.com> Date: Mon, 17 Jun 2024 10:19:29 -0600 Subject: [PATCH 24/28] 7623: move to review (#8672) --- EIPS/eip-7623.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7623.md b/EIPS/eip-7623.md index e700747e98910e..987088182e418d 100644 --- a/EIPS/eip-7623.md +++ b/EIPS/eip-7623.md @@ -4,7 +4,7 @@ title: Increase calldata cost description: Increase calldata cost to decrease the maximum block size author: Toni Wahrstätter (@nerolation), Vitalik Buterin (@vbuterin) discussions-to: https://ethereum-magicians.org/t/eip-7623-increase-calldata-cost/18647 -status: Draft +status: Review type: Standards Track category: Core created: 2024-02-13 From 30e1d6c483758176e76c3d3b5785e38016503045 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Mon, 17 Jun 2024 09:28:45 -0700 Subject: [PATCH 25/28] Update EIP-7600: Move to Review Merged by EIP-Bot. --- EIPS/eip-7600.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7600.md b/EIPS/eip-7600.md index ebd72214997d82..9ae35add3edddb 100644 --- a/EIPS/eip-7600.md +++ b/EIPS/eip-7600.md @@ -4,7 +4,7 @@ title: Hardfork Meta - Pectra description: EIPs included in the Prague/Electra Ethereum network upgrade. author: Tim Beiko (@timbeiko) discussions-to: https://ethereum-magicians.org/t/eip-7600-hardfork-meta-prague-electra/18205 -status: Draft +status: Review type: Meta created: 2024-01-18 requires: 2537, 2935, 6110, 7002, 7251, 7549, 7594, 7685, 7692, 7702 From 0f0757cf8272107a43af2cd4c973ecbe0c3c11b8 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 18 Jun 2024 17:17:20 +0200 Subject: [PATCH 26/28] Update EIP-7716: fix typos Merged by EIP-Bot. --- EIPS/eip-7716.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7716.md b/EIPS/eip-7716.md index f95c237b53b73b..8df573d87e8d9b 100644 --- a/EIPS/eip-7716.md +++ b/EIPS/eip-7716.md @@ -13,7 +13,7 @@ created: 2024-05-25 ## Abstract -The decentralization of the validator set is one of the most important properties of Ethereum for credible neutrality and censorship resistance. By adjusting penalties to foster decentralization, diversification and fault-tolerance, this EIP proposes to adjust penalties in a way that more diversified entities get lower penalties while entities with high correlations in their setup face more servere ones. +The decentralization of the validator set is one of the most important properties of Ethereum for credible neutrality and censorship resistance. By adjusting penalties to foster decentralization, diversification and fault-tolerance, this EIP proposes to adjust penalties in a way that more diversified entities get lower penalties while entities with high correlations in their setup face more severe ones. ## Motivation @@ -61,7 +61,7 @@ The `PENALTY_ADJUSTMENT_FACTOR` regulates how fast `net_excess_penalties` catche In other words, the `PENALTY_ADJUSTMENT_FACTOR` determines the frequency that the penalty_factor is not one. A high `PENALTY_ADJUSTMENT_FACTOR` causes the `net_excess_penalties` to adjust slower. -A low `PENALTY_ADJUSTMENT_FACTOR` causes the `net_excess_penalties` to react more sensitive to changes in participation. +A low `PENALTY_ADJUSTMENT_FACTOR` causes the `net_excess_penalties` to react more sensitively to changes in participation. ### `MAX_PENALTY_FACTOR` From 43fb1e0ca950c42a09efdf9a85d8acfe260efac1 Mon Sep 17 00:00:00 2001 From: pdobacz <5735525+pdobacz@users.noreply.github.com> Date: Tue, 18 Jun 2024 18:42:13 +0200 Subject: [PATCH 27/28] Update EIP-7698: Clarify relation to 3541 Merged by EIP-Bot. --- EIPS/eip-7698.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7698.md b/EIPS/eip-7698.md index f9cf467e3eba09..7dd9e85b65f214 100644 --- a/EIPS/eip-7698.md +++ b/EIPS/eip-7698.md @@ -49,7 +49,7 @@ In case a creation transaction (transaction with empty `to`) has `data` starting - concatenate data section with `(aux_data_offset, aux_data_offset + aux_data_size)` memory segment and update data size in the header, - let `deployed_code_size` be updated deploy container size, - if `deployed_code_size > MAX_CODE_SIZE` instruction exceptionally aborts, - - set `state[new_address].code` to the updated deploy container. + - set `state[new_address].code` to the updated deploy container (rules of [EIP-3541](./eip-3541.md), prohibiting deployment of `code` starting with `EF` from creation transactions, do not apply in this case). 7. Deduct `200 * deployed_code_size` gas. ## Rationale From d9818a33e164e46c468704753b6d7f79319d67f7 Mon Sep 17 00:00:00 2001 From: GAEAlimited <69316708+GAEAlimited@users.noreply.github.com> Date: Wed, 19 Jun 2024 07:05:09 -0400 Subject: [PATCH 28/28] Update index.html (GSCxEIPs) GAEA $uperChain --- index.html | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/index.html b/index.html index a09f9ad8ad6dbb..2333c445a95e07 100644 --- a/index.html +++ b/index.html @@ -1,9 +1,9 @@ --- layout: default -title: Home +title: GSC20 Edition --- -

EIPs +

EIPs for GSC20 Discord channel for ECH eip-editer Discord channel for Eth R&D eip-editing Discord server for discussions about proposals that impact Ethereum wallets @@ -12,12 +12,12 @@

EIPs RSS RSS

-

Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the Ethereum Project Management repository.

+

GSCx Edition of Ethereum Improvement Proposals (GSCxEIPs) are standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the Ethereum Project Management repository.

Contributing

First review EIP-1. Then clone the repository and add your EIP to it. There is a template EIP here. Then submit a Pull Request to Ethereum's EIPs repository.

-

EIP status terms

+

GSCx Edition of EIP status terms for GAEA $uperChain

  • Idea - An idea that is pre-draft. This is not tracked within the EIP Repository.
  • Draft - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
    • @@ -29,23 +29,23 @@

    EIP status terms

  • Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.
-

EIP Types

+

GSCx Edition for EIP Types

EIPs are separated into a number of types, and each has its own list of EIPs.

-

Standard Track ({{site.pages|where:"type","Standards Track"|size}})

+

Introducing GAEA $uperChain ({{site.pages|where:"type","GAEA $uperChain"|size}})

Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.

-

Core ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})

+

Core ({{site.pages|where:"type","GAEA $uperChain"|where:"category","Core"|size}})

Improvements requiring a consensus fork (e.g. EIP-5, EIP-211), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in EIP-225).

-

Networking ({{site.pages|where:"type","Standards Track"|where:"category","Networking"|size}})

+

Networking ({{site.pages|where:"type","GAEA $uperChain"|where:"category","Networking"|size}})

Includes improvements around devp2p (EIP-8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.

-

Interface ({{site.pages|where:"type","Standards Track"|where:"category","Interface"|size}})

+

Interface ({{site.pages|where:"type","GAEA $uperChain"|where:"category","Interface"|size}})

Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP-6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.

-

ERC ({{site.pages|where:"type","Standards Track"|where:"category","ERC"|size}})

+

ERC ({{site.pages|where:"type","GAEA $uperChain"|where:"category","ERC"|size}})

Application-level standards and conventions, including contract standards such as token standards (EIP-20), name registries (EIP-137), URI schemes (EIP-681), library/package formats (EIP-190), and account abstraction (EIP-4337).

Meta ({{site.pages|where:"type","Meta"|size}})