diff --git a/EIPS/eip-5450.md b/EIPS/eip-5450.md index 9c7c91bf7b9b7a..e546311640b6c8 100644 --- a/EIPS/eip-5450.md +++ b/EIPS/eip-5450.md @@ -36,7 +36,7 @@ It also has some disadvantages: - adds constraints to the code structure (similar to JVM, CPython bytecode, WebAssembly and others); however, these constraints can be lifted in a backward-compatible manner if they are shown to be user-unfriendly, - it is natural to implement stack validation as a second validation pass; however, it is not strictly required and validation's computational and space complexity remains linear in any implementation variant. -The guarantees created by these validation rules also improve the feasabiliy of Ahead-Of-Time and Just-In-Time compilation of EVM code. Single pass transpilation passes can be safely executed with the code validation and advanced stack/register handling can be applied with the stack height validaitons. While not as impactful to a mainnet validator node that is bound mostly by storage state sizes, these can significantly speed up witness validation and other non-mainnet use cases. +The guarantees created by these validation rules also improve the feasibility of Ahead-Of-Time and Just-In-Time compilation of EVM code. Single pass transpilation passes can be safely executed with the code validation and advanced stack/register handling can be applied with the stack height validations. While not as impactful to a mainnet validator node that is bound mostly by storage state sizes, these can significantly speed up witness validation and other non-mainnet use cases. ## Specification @@ -59,13 +59,12 @@ In the second validation phase control-flow analysis is performed on the code. *Terminating instructions* refers to the instructions either: - ending function execution: `RETF`, `JUMPF`, or -- ending whole EVM execution: `STOP`, `RETURN`, `RETURNCONTRACT`, `REVERT`, `INVALID`. +- ending call frame execution: `STOP`, `RETURN`, `RETURNCONTRACT`, `REVERT`, `INVALID`. *note: `JUMPF` and `RETURNCONTRACT` are introduced in separate EIPs.* *Forward jump* refers to any of `RJUMP`/`RJUMPI`/`RJUMPV` instruction with relative offset greater than or equal to 0. *Backwards jump* refers to any of `RJUMP`/`RJUMPI`/`RJUMPV` instruction with relative offset less than 0, including jumps to the same jump instruction. - Instructions in the code are scanned in a single linear pass over the code. For each instruction the operand stack height bounds are recorded as `stack_height_min` and `stack_height_max`. The first instruction's recorded stack height bounds are initialized to be equal to the number of inputs to the function type matching the code (`stack_height_min = stack_height_max = type[code_section_index].inputs`). @@ -80,7 +79,7 @@ For each instruction: - for `RETF` instruction both the recorded lower and upper bound must be equal and must be exactly the number of outputs of the function matching the code, - for `JUMPF` into returning function both the recorded lower and upper bound must equal exactly `type[current_section_index].outputs + type[target_section_index].inputs - type[target_section_index].outputs`, - for `JUMPF` into non-returning function the recorded stack height lower bound must be at least the number of inputs of the target function according to its type defined in the type section, - - for any other instruction the recodrded stack height lower bound must be at least the number of inputs required by instruction, + - for any other instruction the recorded stack height lower bound must be at least the number of inputs required by instruction, - there is no additional check for terminating instructions other than `RETF` and `JUMPF`, this implies that extra items left on stack at instruction ending EVM execution are allowed. 2. For `CALLF` and `JUMPF` **check** for possible stack overflow: if recorded stack height upper bound is greater than `1024 - types[target_section_index].max_stack_height + types[target_section_index].inputs`, validation fails. 3. Compute new stack height bounds after the instruction execution. Upper and lower bound are updated by the same value: @@ -154,7 +153,7 @@ This is required to make it possible to examine each instruction in one linear p ## Backwards Compatibility -This change requires a "network upgrade", since it modifies consensus rules. +This change requires a "network upgrade," since it modifies consensus rules. It poses no risk to backwards compatibility, as it is introduced only for EOF1 contracts, for which deploying undefined instructions is not allowed, therefore there are no existing contracts using these instructions. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted). diff --git a/EIPS/eip-6916.md b/EIPS/eip-6916.md index 38716d37eab114..a55fbb198bf28a 100644 --- a/EIPS/eip-6916.md +++ b/EIPS/eip-6916.md @@ -4,7 +4,8 @@ title: Automatically Reset Testnet description: A testnet network that periodically rolls back to genesis author: Mário Havel (@taxmeifyoucan), pk910 (@pk910), Rémy Roy (@remyroy), Holly Atkinson (@atkinsonholly), Tereza Burianova (@T-ess) discussions-to: https://ethereum-magicians.org/t/automatically-reset-testnet/15825 -status: Review +status: Last Call +last-call-deadline: 2025-01-15 type: Standards Track category: Core created: 2023-04-10 diff --git a/EIPS/eip-7002.md b/EIPS/eip-7002.md index b93b429d67261c..25cca6506df837 100644 --- a/EIPS/eip-7002.md +++ b/EIPS/eip-7002.md @@ -39,7 +39,7 @@ Note, 0x00 withdrawal credentials can be changed into 0x01 withdrawal credential | Name | Value | Comment | | - | - | - | -| `WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS` | `0x09Fc772D0857550724b07B850a4323f39112aAaA` | Where to call and store relevant details about exit / partial withdrawal mechanism | +| `WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS` | `0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA` | Where to call and store relevant details about exit / partial withdrawal mechanism | | `WITHDRAWAL_REQUEST_TYPE` | `0x01` | The [EIP-7685](./eip-7685.md) type prefix for withdrawal request | | `SYSTEM_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe` | Address used to invoke system operation on contract | `EXCESS_WITHDRAWAL_REQUESTS_STORAGE_SLOT` | 0 | | diff --git a/EIPS/eip-7251.md b/EIPS/eip-7251.md index d3c400ae8a049e..1a7629c50462dd 100644 --- a/EIPS/eip-7251.md +++ b/EIPS/eip-7251.md @@ -29,14 +29,14 @@ With the security model of the protocol no longer dependent on a low value for ` | Name | Value | Comment | | - | - | - | | `CONSOLIDATION_REQUEST_TYPE` | `0x02` | The [EIP-7685](./eip-7685.md) type prefix for consolidation request | -| `CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS` | `0x01aBEa29659e5e97C95107F20bb753cD3e09bBBb` | Where to call and store relevant details about consolidation request mechanism | +| `CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS` | `0x00431F263cE400f4455c2dCf564e53007Ca4bbBb` | Where to call and store relevant details about consolidation request 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 the 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 | +| `MAX_CONSOLIDATION_REQUESTS_PER_BLOCK` | `2` | 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` | | @@ -80,7 +80,7 @@ The contract has three different code paths, which can be summarized at a high l 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()`) +1. Ensure enough ETH was sent to cover the current consolidation request fee (`msg.value >= get_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()`) @@ -367,13 +367,13 @@ dup1 dup3 sub dup1 -push1 0x01 +push1 0x02 gt push1 0xe7 jumpi pop -push1 0x01 +push1 0x02 jumpdest push0 @@ -522,17 +522,17 @@ The consolidation requests contract is deployed like any other smart contract. A "maxPriorityFeePerGas": null, "maxFeePerGas": null, "value": "0x0", - "input": "0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f5561019e80602d5f395ff33373fffffffffffffffffffffffffffffffffffffffe1460d35760115f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff1461019a57600182026001905f5b5f82111560685781019083028483029004916001019190604d565b9093900492505050366060146088573661019a573461019a575f5260205ff35b341061019a57600154600101600155600354806004026004013381556001015f358155600101602035815560010160403590553360601b5f5260605f60143760745fa0600101600355005b6003546002548082038060011160e7575060015b5f5b8181146101295782810160040260040181607402815460601b815260140181600101548152602001816002015481526020019060030154905260010160e9565b910180921461013b5790600255610146565b90505f6002555f6003555b5f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff141561017357505f5b6001546001828201116101885750505f61018e565b01600190035b5f555f6001556074025ff35b5f5ffd", + "input": "0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f5561019e80602d5f395ff33373fffffffffffffffffffffffffffffffffffffffe1460d35760115f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff1461019a57600182026001905f5b5f82111560685781019083028483029004916001019190604d565b9093900492505050366060146088573661019a573461019a575f5260205ff35b341061019a57600154600101600155600354806004026004013381556001015f358155600101602035815560010160403590553360601b5f5260605f60143760745fa0600101600355005b6003546002548082038060021160e7575060025b5f5b8181146101295782810160040260040181607402815460601b815260140181600101548152602001816002015481526020019060030154905260010160e9565b910180921461013b5790600255610146565b90505f6002555f6003555b5f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff141561017357505f5b6001546001828201116101885750505f61018e565b01600190035b5f555f6001556074025ff35b5f5ffd", "v": "0x1b", "r": "0x539", - "s": "0x4b026bde3de3d21a", - "hash": "0x5c86483822c8978690fd23fec89ba75e205c734020315827c50e2def49f924d4" + "s": "0x332601ef36aa2ce9", + "hash": "0xc7d223eb06267248bcd21f7af0223c8d467ef7e95ff51cef84c616973692169f" } ``` ``` -Sender: 0xB64F31e716F43404Fc452Ad957e37B45B2A9AC86 -Address: 0x0046BB33B9eA028AE30BAd20702e36Ea8099BBbb +Sender: 0xe24B968aB4319a580d9FFc7Ac29466894FeEb361 +Address: 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb ``` #### Block processing diff --git a/EIPS/eip-7542.md b/EIPS/eip-7542.md index f5b82e9654a861..62b3d1721a4f57 100644 --- a/EIPS/eip-7542.md +++ b/EIPS/eip-7542.md @@ -4,7 +4,7 @@ title: eth/70 - available-blocks-extended protocol description: Adds more info in the handshake about available block range and adds message types to request block ranges and the send them author: Ahmad Bitar (@smartprogrammer93) discussions-to: https://ethereum-magicians.org/t/eip-eth-70-available-blocks-extended-protocol-handshake/16188 -status: Stagnant +status: Withdrawn type: Standards Track category: Networking created: 2023-10-21 diff --git a/EIPS/eip-7623.md b/EIPS/eip-7623.md index e07d43cb6ac459..748a50110c8c95 100644 --- a/EIPS/eip-7623.md +++ b/EIPS/eip-7623.md @@ -1,7 +1,7 @@ --- eip: 7623 title: Increase calldata cost -description: Increase calldata cost to decrease the maximum block size +description: Increase calldata cost to reduce 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: Review @@ -10,22 +10,18 @@ category: Core created: 2024-02-13 --- - - ## Abstract -The current calldata pricing allows for significantly large blocks of up to 2.8 MB while the average block size is much smaller at 125 KB. -This EIP proposes an adjustment in the Ethereum calldata cost to reduce the maximum possible block size and its variance without impacting regular users. -This is achieved by increasing the calldata cost for transactions primarily using Ethereum for data availability. - +The current calldata pricing permits EL payloads of up to 7.15 MB, while the average size is much smaller at around 100 KB. +This EIP proposes adjusting the calldata cost to reduce the maximum possible block size and its variance without negatively impacting regular users. +This is achieved by increasing calldata costs for transactions that predominantly post data. ## Motivation -The block gas limit has not been increased since [EIP-1559](./eip-1559.md), while the average size of blocks has continuously increased due to the growing number of rollups posting data to Ethereum. Furthermore, the cost for calldata hasn't been adjusted since [EIP-2028](./eip-2028). +The block gas limit has not been increased since [EIP-1559](./eip-1559.md), while the average size of blocks has continuously increased due to the growing number of rollups posting data to Ethereum. Moreover, calldata costs have remained unchanged since [EIP-2028](./eip-2028). [EIP-4844](./eip-4844.md) introduces blobs as a preferred method for data availability (DA). -This transition demands a reevaluation of calldata pricing, especially with regards to mitigating the inefficiency between the average block size and the maximum one possible. -By introducing a floor cost dependent on calldata for transactions that are mainly using Ethereum for DA, this proposal aims to reduce the maximum block size to make room for adding more blobs. - +This transition demands a reevaluation of calldata pricing, especially in order to address the disparity between average and maximum block sizes. +By introducing a floor cost dependent on the ratio of gas spent on EVM operations to calldata, this proposal aims to reduce the maximum block size to make room for additional blobs or potential block gas limit increases. ## Specification @@ -42,10 +38,10 @@ Let `isContractCreation` be a boolean indicating the respective event. The current formula for determining the gas used per transaction, typically described as `nonzero_bytes_in_calldata * 16 + zero_bytes_in_calldata * 4`, is equivalent to: ```python -tx.gasused = ( - 21000 \ - + STANDARD_TOKEN_COST * tokens_in_calldata \ - + evm_gas_used \ +tx.gasUsed = ( + 21000 + + STANDARD_TOKEN_COST * tokens_in_calldata + + evm_gas_used + isContractCreation * (32000 + InitCodeWordGas * words(calldata)) ) ``` @@ -54,51 +50,48 @@ The formula for determining the gas used per transaction changes to: ```python tx.gasUsed = { - 21000 \ + 21000 + max ( - STANDARD_TOKEN_COST * tokens_in_calldata \ - + evm_gas_used \ + STANDARD_TOKEN_COST * tokens_in_calldata + + evm_gas_used + isContractCreation * (32000 + InitCodeWordGas * words(calldata)), TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata ) ``` -Any transaction with a gas limit less than `21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata` is invalid. This limitation exists because transactions must be able to pay for the floor price of their call data without relying the execution of the transaction. There are valid cases where `gasUsed` will be below this floor price, but the floor price needs to be reserved in the transaction gas limit. +Any transaction with a gas limit below `21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata` or below it's intrinsic gas cost (take the maximum of these two calculations) is considered invalid. This limitation exists because transactions must cover the floor price of their calldata without relying on the execution of the transaction. There are valid cases where `gasUsed` will be below this floor price, but the floor price needs to be reserved in the transaction gas limit. ## Rationale -The current maximum block size is approximately 1.79 MB (`30_000_000/16`). One can create blocks full of zero bytes that go up to 7.5 MB, but it is now standard to wrap blocks with snappy compression at the p2p layer and so such zero-byte-heavy blocks would end up smaller than 1.79 MB in practice. With the implementation of [EIP-4844](./eip-4844.md) this increased to ~2.54 MB. Furthermore, the cost for calldata bytes hasn't been adjusted since [EIP-2028](./eip-2028). - -This proposal aims to increase the cost of calldata to 10/40 gas for transactions that do not exceed a certain threshold of gas spent on EVM operations. This change will significantly reduce the maximum block size by limiting the number and size of pure-data transactions that can fit into a single block. Specifically, by adjusting the cost of calldata bytes to from 4/16 to 10/40 gas for DA transactions, the goal is to lower the maximum possible block size to roughly 0.72 MB without impacting the vast majority of users. - +The current maximum EL payload size is approximately 1.79 MB (`30_000_000/16`). It is possible to create payloads filled with zero bytes that expand to 7.15 MB. However, since blocks are typically compressed with Snappy at the P2P layer, zero-byte-heavy EL payloads generally compress to under 1.79 MB. The implementation of [EIP-4844](./eip-4844.md) increased the maximum possible compressed block size to approximately 2.54 MB. -This reduction makes room for increasing the block gas limit or the number of blobs, while ensuring network security and efficiency. -Importantly, regular users (sending ETH/Tokens/NFTs, engaging in DeFi, social media, restaking, bridging, etc.) who do not use Ethereum almost exclusively for DA, may remain unaffected. -The calldata cost for transactions involving significant EVM computation remains at 4/16 gas per byte, ensuring those transactions experience no change. +This proposal aims to increase the cost of calldata to 10/40 gas for transactions that do not exceed a certain threshold of gas spent on EVM operations relative to gas spent on calldata. This change will significantly reduce the maximum block size by limiting the size of data-heavy transactions that can fit into a single block. By increasing calldata costs from 4/16 to 10/40 gas per byte for data-heavy transactions, this EIP aims to reduce the maximum possible EL payload size to approximately 0.72 MB (`30_000_000/40`) without affecting the majority of users. +Notably, regular users (e.g. sending ETH/Tokens/NFTs, engaging in DeFi, social media, restaking, bridging, etc.), who do not use calldata predominantly for DA, may remain unaffected. +The calldata cost for transactions involving significant EVM computation remains at 4/16 gas per byte, so those transactions are unaffected. ## Backwards Compatibility This is a backwards incompatible gas repricing that requires a scheduled network upgrade. -Wallet developers and node operators MUST update their handling of gas estimation to accommodate the new calldata cost rules. Specifically: +Wallet developers and node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically: -1. **Wallets**: Wallets using `eth_estimateGas` to calculate the gas limit for transactions MUST be updated to ensure that they correctly account for the `TOTAL_COST_FLOOR_PER_TOKEN` parameter. Failure to do so could result in underestimating gas, leading to failed transactions. +1. **Wallets**: Wallets using `eth_estimateGas` MUST be updated to ensure that they correctly account for the `TOTAL_COST_FLOOR_PER_TOKEN` parameter. Failure to do so could result in underestimating gas, leading to failed transactions. -2. **Node Software**: RPC methods like `eth_estimateGas` must incorporate the revised formula for gas calculation to ensure accurate responses to client requests. Node developers MUST ensure compatibility with the updated calldata pricing logic. +2. **Node Software**: RPC methods such as `eth_estimateGas` MUST incorporate the updated formula for gas calculation. Node developers MUST ensure compatibility with the updated calldata pricing logic. -Users will be able to continue operating with no changes to their workflows, but underlying wallet and RPC implementations must be updated to ensure smooth functioning. +Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes. ## Security Considerations -As the maximum possible block size is reduced, no security concerns were raised. +As the maximum possible block size is reduced, no security concerns have been raised. -In some cases, it might seem advantageous to combine two transactions into one to reduce costs—for example, bundling a transaction that uses a lot of calldata but minimal EVM resources with another that heavily uses EVM resources. However, this is not a significant concern for several reasons: +In some cases, it might seem advantageous to combine two transactions into one to reduce costs. For example, bundling a transaction that relies heavily on calldata but minimally on EVM resources with another that does the opposite. However, this is not a significant concern for several reasons: -1. This type of bundling is already possible today. Combining multiple transactions into one can save the 21,000 gas cost for each additional transaction beyond the first, a feature explicitly supported in [ERC-4337](./eip-4337.md). -2. Such bundling does not bypass the block size reduction goals achieved by this EIP. -3. In practice, transaction bundling faces challenges such as the need for trust and coordination, which often make it impractical to implement. +1. This type of bundling is already possible today. Merging multiple transactions can save the 21,000 gas cost for each additional transaction beyond the first, a feature explicitly supported in [ERC-4337](./eip-4337.md). +2. Such bundling does not compromise the block size reduction objectives of this EIP. +3. In practice, transaction bundling is often impractical due to challenges such as trust and coordination requirements. These factors ensure that transaction bundling does not pose a significant issue. diff --git a/EIPS/eip-7639.md b/EIPS/eip-7639.md index a5f6c4d4f5678e..38d6c54d161d6f 100644 --- a/EIPS/eip-7639.md +++ b/EIPS/eip-7639.md @@ -1,6 +1,6 @@ --- eip: 7639 -title: eth/71 - Cease serving history before PoS +title: eth/70 - Cease serving history before PoS description: Execution layer clients will no longer serve block data before Paris over p2p. author: lightclient (@lightclient) discussions-to: https://ethereum-magicians.org/t/cease-serving-history-before-pos/18991 @@ -24,7 +24,7 @@ proposes the first steps to achieve such goal. ## Specification -Add a new `eth` protocol capability with version `71`. +Add a new `eth` protocol capability with version `70`. Clients connected on this version must not make or respond to p2p queries about block bodies or receipts before block 15537393. diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index b2cbf9fe1fb5ce..76cb945cde48f1 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -86,7 +86,7 @@ If transaction execution results in failure (any exceptional condition or code r ##### Delegation Designation -The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541.md) to designate the code has a special purpose. This designator requires all code executing operations to follow the address pointer to get the account's executable code, and requires all other code reading operations to act only on the first 2 bytes of the designator (`0xef01`). The following instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`, as well as transactions with `destination` targeting the code with delegation designation. +The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541.md) to designate the code has a special purpose. This designator requires all code executing operations to follow the address pointer to get the account's executable code, and requires all other code reading operations to act only on the first 2 bytes of the designator (`0xef01`). The following reading instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, and the following executing instructions are impacted: `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`, as well as transactions with `destination` targeting the code with delegation designation. For example, `EXTCODESIZE` would return `2` (the size of `0xef01`) instead of `23` which would represent the delegation designation, `EXTCODEHASH` would return `0xeadcdba66a79ab5dce91622d1d75c8cff5cff0b96944c3bf1072cd08ce018329` (`keccak256(0xef01)`), and `CALL` would load the code from `address` and execute it in the context of `authority`. @@ -252,6 +252,14 @@ While there are a few mitigations for this, the authors recommend that clients d A related issue is that an EOA's nonce maybe incremented more than once per transaction. Because clients already need to be robust in a worse scenario (described above), it isn't a major security concern. However, clients should be aware this behavior is possible and design their transaction propagation accordingly. +### Storage management + +Changing an account's delegation is a security-critical operation that should not be done lightly, especially if the newly delegated code is not purposely designed and tested as an upgrade to the old one. + +In particular, in order to ensure a safe migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [ERC-7201](./eip-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To simplify this, smart contract languages may provide a way of re-rooting the entire storage layout of existing contract source code. + +If all contracts previously delegated to by the account used the approach described above, a migration should not cause any issues. However, if there is any doubt, it is recommended to first clear all account storage, an operation that is not natively offered by the protocol but that a special-purpose delegate contract can be designed to implement. + ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/EIPS/eip-7742.md b/EIPS/eip-7742.md index 54820d0d83b236..bba972f7a512bb 100644 --- a/EIPS/eip-7742.md +++ b/EIPS/eip-7742.md @@ -81,7 +81,17 @@ target blob count given by that genesis block's protocol rule set. Upon activating this EIP (i.e. before processing any transactions), the verification of the blob maximum as given in EIP-4844 can be skipped. Concretely, this means any logic relating to `MAX_BLOB_GAS_PER_BLOCK` as given in EIP-4844 can be deprecated. -Additionally, any reference to `TARGET_BLOB_GAS_PER_BLOCK` from EIP-4844 can be derived by taking the `target_blobs_per_block` from the CL and multiplying by `GAS_PER_BLOB` as given in EIP-4844. + +Additionally, `calc_excess_blob_gas` is updated as follows: + +```python +def calc_excess_blob_gas(parent: Header) -> int: + target_blob_gas = parent.target_blobs_per_block * GAS_PER_BLOB + if parent.excess_blob_gas + parent.blob_gas_used < target_blob_gas: + return 0 + else: + return parent.excess_blob_gas + parent.blob_gas_used - target_blob_gas +``` Otherwise, the specification of EIP-4844 is not changed. For example, blob base fee accounting and excess blob gas tracking occur in the exact same way. diff --git a/EIPS/eip-7756.md b/EIPS/eip-7756.md index e99e48d1e6b9ca..71acefd998ed0c 100644 --- a/EIPS/eip-7756.md +++ b/EIPS/eip-7756.md @@ -17,19 +17,29 @@ Updates the [EIP-3155](./eip-3155.md) JSON tracing specification to support EOF ## Motivation -EIP-3155 defined a tracing standard for Legacy EVM operations. However, the EVM Object Format ([EIP-7692](./eip-7692.md)) adds a number of features that need to be reflected in debugging traces. +EIP-3155 defined a tracing standard for Legacy EVM operations. However, the EVM Object +Format ([EIP-7692](./eip-7692.md)) adds a number of features that need to be reflected in debugging +traces. -The use of these traces has also moved out from state testing, including live block tracing and differential fuzzing, increasing the need to keep tracing up to date. +The use of these traces has also moved out from state testing, including live block tracing and +differential fuzzing, increasing the need to keep tracing up to date. This EIP has multiple goals: - Add members to the trace object to support new EOF features. -- Support tracing contracts contained in an EOF container as well as uncontained "legacy" contracts in the same trace. +- Support tracing contracts contained in an EOF container as well as uncontained "legacy" contracts + in the same trace. - Clarify any previous ambiguities in the EIP-3155 specification. ## Specification -To promote clarity and provide a cohesive specification, the entire tracing specification will be presented with alterations in-line rather than as a set of diffs on top of EIP-3155. Differences will be highlighted in the Backwards Compatibility section. +To promote clarity and provide a cohesive specification, the entire tracing specification will be +presented with alterations in-line rather than as a set of diffs on top of EIP-3155. Differences +will be highlighted in the Backwards Compatibility section. + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", " +RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as +described in RFC 2119 and RFC 8174. ### Datatypes @@ -43,50 +53,97 @@ To promote clarity and provide a cohesive specification, the entire tracing spec | Key-Value | Key-Value structure with key and values encoded as hex strings | `"storage":{"0x0":"0x1", "0x1":"0x1"}` | | Boolean | Json bool can either be true or false | `"pass": true` | +- Clients may OPTIONALLY output Number where a Hex-Number is expected and vice-versa. Clients that + do this SHOULD provide a CLI option to strictly observe the correct output type. +- Numbers larger than 2^53 - 1 must be represented as Hex-Numbers. This is a limitation of JSON. +- Consumers of EIP-7756 traces SHOULD be written in a way that members of type Hex-Number and + Number may be provided a Number or Hex-Number instead, respectively. +- Note that there is no string formatted decimal number alternative. Decimal representations are + always JSON numbers, and hex representations are always strings encoding hex numbers. + ### Output - The client outputs one JSON object per EVM operation executed. - The client MUST NOT output multiple lines for the same operation execution. -- The client MUST NOT output a line for the `STOP` operation if an error occurred, or if the contract runs out of instructions. - -Each object contains the following members. - -| Name | Type | Required | Explanation | -|------------------|------------|-----------------|-----------------------------------------------------------| -| `pc` | Number | Yes | Program Counter | -| `section` | Number | Yes if EOF | EOF Code Section | -| `op` | Number | Yes | Opcode | -| `immediate` | Hex-String | *see below* | Immediate argument of the Opcode | -| `gas` | Hex-Number | Yes | Gas left before executing this operation | -| `gasCost` | Hex-Number | Yes | Gas cost of this operation | -| `memory` | Array | No | Array of all allocated values | -| `memSize` | Number | Yes | Size of memory array | -| `stack` | Array | Yes | Array of all values on the stack | -| `depth` | Number | Yes | Depth of the contract call stack (non-CALLF) | -| `functionDepth` | Number | Yes if not zero | Depth of the [EIP-4750](./eip-4750.md) CALLF return stack | -| `returnData` | Hex-String | No | Data returned by contract calls | -| `refund` | Hex-Number | Yes | Amount of **global** gas refunded | -| `opName` | String | No | Name of the operation | -| `error` | Hex-String | No | Description of an error or revert data | -| `storage` | Map | No | Array of all stored values | - - -- The `pc` value is zero indexed either from the beginning of the contract when the contract is not in an EOF container, or from the beginning of the code section when it is a contract contained in an EOF container. -- The `section` member must only be present when tracing a contract that is contained in an EOF container. - In cases where legacy and EOF contracts are in the same call trace the presence and absence of the `section` member indicates if the contract at that step is EOF or legacy. -- The `immediate` member is optional for PUSH series instructions, and mandatory for all other operations that have immediate arguments. - - For RJUMPV this would include the table length and the entire table. Clients MAY instead store just the table length. -- The `gas`, `stack`, `memory` and `memSize`, `depth`, and `functionDepth` members are the values *before* execution of the op. -- The `gasCost` is the sum of all gas costs, including dynamic costs such as memory expansion, call stipend, and account warming costs. -- All array attributes (`stack`, `memory`) MUST be initialized to empty arrays ("stack":[]` NOT `"stack":null`). -- The `memory` or `storage` members may be omitted if they are empty or the client does not produce them. -- The `memSize` member MUST be present regardless of `memory` support. Even when `memSize` is zero. -- The `functionDepth` member may be omitted when zero. It must be omitted if the contract is legacy EVM. -- The `error` and `returnData` members can be omitted if they are empty. -- If the prior operation failed with an exceptional halt, `error` should identify the halt. Otherwise, if the prior operation was a `REVERT` operation `error` should contain the hex-encoded revert data. -- The `storage` member should only include items read or written via `SSTORE` or `SLOAD`, and not the account's entire storage. -- Clients SHOULD implement a way to disable recording the storage as the stateroot includes all storage updates. -- Clients SHOULD output the members in the same order as listed in this EIP. +- The client MUST NOT output a line for the `STOP` operation if an error occurred, or if the + contract runs out of instructions. + +#### Required Fields + +Each trace line MUST have these fields. + +| Name | Type | Explanation | +|----------|----------------------|---------------------------------------------------------------------| +| `pc` | Number | Program Counter | +| `op` | Hex-Number | OpCode | +| `opName` | String | Name of the operation | +| `gas` | Number | Gas left before executing this operation | +| `stack` | Array of Hex-Numbers | Array of all values on the stack | +| `depth` | Number | Depth of the call stack | +| `error` | Hex-String | Description of an error (SHOULD contain revert reason if supported) | + +- The `pc` value is zero indexed from the beginning of the contract when the contract is not in an + EOF container, or from the beginning of the container EOF container. For legacy contracts the + first execution line is for `"pc":0`. For EOF contracts the zero byte corresponds to the `0xEF` + magic byte. The first line of execution will not be at `"pc":0` but at the first byte of the first + code section executed. +- `opName` SHOULD be the most current name of the operation, in cases where operations have multiple + specification names (`SELFDESTRUCT` and `PREVRANDAO`) + +- If `stack` is empty an empty array (`[]`) is used instead of `null`. +- `depth` starts at 1. +- `error` SHOULD be omitted if a prior CALL series or CREATE series operation within the current + frame has not returned a revert reason and the current operation did not trigger an exceptional + halt. + + + +#### Recommended Fields + +Each trace line SHOULD have these fields in the conditions they are indicated for. + +| Name | Type | Explanation | +|--------------|------------|-----------------------------------| +| `gasCost` | Number | Gas cost of this operation | +| `memSize` | Number | Size of memory array | +| `returnData` | Hex-String | Data returned by function call | +| `refund` | Hex-Number | Amount of **global** gas refunded | + +- `gasCost` is the sum of all gas costs, including dynamic costs such as memory expansion, call + stipend, and account warming costs. +- `memSize` is counted in 8-bit bytes, not 256-bit words. +- `returnData` SHOULD NOT be present if a CALL series operation has not completed within the current +frame. + +#### Optional Fields + +Each trace line MAY have these fields in the conditions they are indicated for. +If a field is to be omitted within a trace, it MUST always be omitted within the same trace. + +| Name | Type | Explanation | +|-----------------|----------------------|-----------------------------------------------------------| +| `section` | Number | Current EOF section being executed | +| `immediate` | Hex-String | Immediate argument of the Opcode | +| `functionDepth` | Number | Depth of the [EIP-4750](./eip-4750.md) CALLF return stack | +| `memory` | Array of Hex-Strings | Array of all allocated values | +| `storage` | Key-Value | Array of all stored values | + +- The `section` member must only be present when tracing a contract contained in an EOF container. +- The `immediate` field MUST NOT be present for operations without immediate data. + - For PUSH series operations, this field is OPTIONAL as the immediate data is pushed onto the + stack + - For RJUMPV this would include the table length and the entire table. Clients MAY instead store + just the table length. + - For all other operations with immediate data the entire immediate data, including leading + zeros, SHOULD be present. +- `functionDepth` starts at 1, and MAY be omitted if it is 1. +- `functionDepth` MUST NOT be present for trace lines of code not in an EOF container. +- If `memory` is empty an empty array (`[]`) is used instead of `null`. +- The `storage` member SHOULD only include items read or written via `SSTORE` or `SLOAD`, and not + the account's entire storage. *Example:* @@ -96,18 +153,21 @@ Each object contains the following members. ### Summary Line -At the end of execution, the client should print summary info. This summary MUST be a single JSON object. +At the end of execution, the client SHOULD print summary info. This summary MUST be a single JSON +object. This info SHOULD have the following members. -| Name | Type | Required | Explanation | -|-------------|------------|----------|--------------------------------------------------------| -| `stateRoot` | Hex-String | Yes | Root of the state trie after executing the transaction | -| `output` | Hex-String | Yes | Return values of the function | -| `gasUsed` | Hex-Number | Yes | All gas used by the transaction | -| `pass` | Boolean | Yes | If the tx was successful, or if the test passed | -| `time` | Number | No | Time in nanoseconds needed to execute the transaction | -| `fork` | String | No | Name of the fork rules used for execution | +| Name | Type | Explanation | +|-------------|------------|--------------------------------------------------------| +| `stateRoot` | Hex-String | Root of the state trie after executing the transaction | +| `output` | Hex-String | Return values of the function | +| `gasUsed` | Number | All gas used by the transaction | +| `pass` | Boolean | If the tx was successful, or if the test passed | +| `time` | Number | Time in nanoseconds needed to execute the transaction | +| `fork` | String | Name of the fork rules used for execution | + +- `time` and `fork` fields MAY be provided. *Example*: @@ -117,61 +177,81 @@ This info SHOULD have the following members. ## Rationale -This EIP is an extension of the EIP-3155 tracing features that has been in use for years. Rather than dramatically re-boot the feature, the information was added to the existing traces. +This EIP is an extension of the EIP-3155 tracing features that has been in use for years. Rather +than dramatically re-boot the feature, the information was added to the existing traces. -A "mini" trace was contemplated to allow for tracing to be included in tools such as `t8n` and to allow for more efficient RPC tracing calls, but that seemed sufficiently different that it would be a stand-alone EIP rather than an EIP that adds features to the existing tracing capabilities. +A "mini" trace was contemplated to allow for tracing to be included in tools such as +`t8n` and to allow for more efficient RPC tracing calls, but that seemed sufficiently different that +it would be a stand-alone EIP rather than an EIP that adds features to the existing tracing +capabilities. -The idea of moving to a JSON Schema was rejected to ensure maximum compatibility with existing clients. +The idea of moving to a JSON Schema was rejected to ensure maximum compatibility with existing +clients. ## Backwards Compatibility -Clients emitting tracing JSON for uncontained "legacy" contracts will produce a compatible trace, except as outlined below +Clients emitting tracing JSON for uncontained "legacy" contracts will produce a compatible trace, +except as outlined below ### Changes from EIP-3155 - The term Client Under Test or CUT has been replaced simply with "client." +- `gas`, `gasCost`, and `gasUsed` are now Number types. +- `opcode` is now a Hex-Number type. ### Additions to EIP-3155 -- The `immediate` member was added to support the large number of instructions that contain immediate operations. - Without this change, users would need bytes of the contracts being executed to rationalize the traces. -- The `section` and `functionDepth` members were added to support [EIP-4750](./eip-4750) EOF Functions. +- The `immediate` member was added to support the large number of instructions that contain + immediate operations. Without this change, users would need bytes of the contracts being executed + to rationalize the traces. +- The `section` and `functionDepth` members were added to support [EIP-4750](./eip-4750) EOF + Functions. - Added clarification around where `pc` indexes when run in an EOF container. +- Added Hex-Number/Number interchangeability expectations. Clients MAY provide either types when + one is specified and consumers SHOULD be prepared to accept either type. Clients SHOULD provide a + flag to output members with the specified number type only. ### Clients -Besu, evmone, EthereumJS, Geth, Nethermind, and Reth already produce these standard traces in various tools. Adding the new fields will align with work needed to support the EOF EIPs enumerated in EIP-7692. +Besu, evmone, EthereumJS, Geth, Nethermind, and Reth already produce these standard traces in +various tools. Adding the new fields will align with work needed to support the EOF EIPs enumerated +in EIP-7692. ## Test Cases -This is the trace output from the Ethereum Execution Specification Test from one of the parameterized executions of [test_eof_functions_contract_call_succeed](https://github.com/ethereum/execution-spec-tests/blob/632d151ea8a71d09a3a0acbdb85d97fa18c8456b/tests/prague/eip7692_eof_v1/eip3540_eof_v1/test_execution_function.py#L304-L335). +This is the trace output from the Ethereum Execution Specification Test from one of the +parameterized executions of [test_eof_functions_contract_call_succeed](https://github.com/ethereum/execution-spec-tests/blob/632d151ea8a71d09a3a0acbdb85d97fa18c8456b/tests/prague/eip7692_eof_v1/eip3540_eof_v1/test_execution_function.py#L304-L335). Memory and return data is disabled. ```json lines -{"pc":0,"op":96,"gas":"0x2fa9e78","gasCost":"0x3","memSize":0,"stack":[],"depth":1,"refund":0,"opName":"PUSH1"} -{"pc":2,"op":96,"gas":"0x2fa9e75","gasCost":"0x3","memSize":0,"stack":["0x0"],"depth":1,"refund":0,"opName":"PUSH1"} -{"pc":4,"op":96,"gas":"0x2fa9e72","gasCost":"0x3","memSize":0,"stack":["0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} -{"pc":6,"op":96,"gas":"0x2fa9e6f","gasCost":"0x3","memSize":0,"stack":["0x0","0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} -{"pc":8,"op":96,"gas":"0x2fa9e6c","gasCost":"0x3","memSize":0,"stack":["0x0","0x0","0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} -{"pc":10,"op":97,"gas":"0x2fa9e69","gasCost":"0x3","memSize":0,"stack":["0x0","0x0","0x0","0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH2"} -{"pc":13,"op":90,"gas":"0x2fa9e66","gasCost":"0x2","memSize":0,"stack":["0x0","0x0","0x0","0x0","0x0","0x1000"],"depth":1,"refund":0,"opName":"GAS"} -{"pc":14,"op":241,"gas":"0x2fa9e64","gasCost":"0x2eeb414","memSize":0,"stack":["0x0","0x0","0x0","0x0","0x0","0x1000","0x2fa9e64"],"depth":1,"refund":0,"opName":"CALL"} -{"pc":0,"section":0,"op":227,"immediate":"0x0001","gas":"0x2eea9ec","gasCost":"0x5","memSize":0,"stack":[],"depth":2,"refund":0,"opName":"CALLF"} -{"pc":0,"section":1,"op":228,"gas":"0x2eea9e7","gasCost":"0x3","memSize":0,"stack":[],"depth":2,"functionDepth":1,"refund":0,"opName":"RETF"} -{"pc":3,"section":0,"op":0,"gas":"0x2eea9e4","gasCost":"0x0","memSize":0,"stack":[],"depth":2,"refund":0,"opName":"STOP"} -{"pc":15,"op":96,"gas":"0x2fa9434","gasCost":"0x3","memSize":0,"stack":["0x1"],"depth":1,"refund":0,"opName":"PUSH1"} -{"pc":17,"op":85,"gas":"0x2fa9431","gasCost":"0x5654","memSize":0,"stack":["0x1","0x0"],"depth":1,"refund":0,"opName":"SSTORE"} -{"pc":18,"op":0,"gas":"0x2fa3ddd","gasCost":"0x0","memSize":0,"stack":[],"depth":1,"refund":0,"opName":"STOP"} +{"pc":0,"op":"0x60","gas":49979000,"gasCost":3,"memSize":0,"stack":[],"depth":1,"refund":0,"opName":"PUSH1"} +{"pc":2,"op":"0x60","gas":49978997,"gasCost":3,"memSize":0,"stack":["0x0"],"depth":1,"refund":0,"opName":"PUSH1"} +{"pc":4,"op":"0x60","gas":49978994,"gasCost":3,"memSize":0,"stack":["0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} +{"pc":6,"op":"0x60","gas":49978991,"gasCost":3,"memSize":0,"stack":["0x0","0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} +{"pc":8,"op":"0x60","gas":49978988,"gasCost":3,"memSize":0,"stack":["0x0","0x0","0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} +{"pc":10,"op":"0x61","gas":49978985,"gasCost":3,"memSize":0,"stack":["0x0","0x0","0x0","0x0","0x0"],"depth":1,"refund":0,"opName":"PUSH2"} +{"pc":13,"op":"0x5a","gas":49978982,"gasCost":2,"memSize":0,"stack":["0x0","0x0","0x0","0x0","0x0","0x1000"],"depth":1,"refund":0,"opName":"GAS"} +{"pc":14,"op":"0xf1","gas":49978980,"gasCost":49198100,"memSize":0,"stack":["0x0","0x0","0x0","0x0","0x0","0x1000","0x2fa9e64"],"depth":1,"refund":0,"opName":"CALL"} +{"pc":25,"section":0,"op":"0xe3","immediate":"0x0001","gas":49195500,"gasCost":5,"memSize":0,"stack":[],"depth":2,"refund":0,"opName":"CALLF"} +{"pc":29,"section":1,"op":"0xe4","gas":49195495,"gasCost":3,"memSize":0,"stack":[],"depth":2,"functionDepth":2,"refund":0,"opName":"RETF"} +{"pc":28,"section":0,"op":"0x00","gas":49195492,"gasCost":0,"memSize":0,"stack":[],"depth":2,"refund":0,"opName":"STOP"} +{"pc":15,"op":"0x60","gas":49976372,"gasCost":3,"memSize":0,"stack":["0x1"],"depth":1,"refund":0,"opName":"PUSH1"} +{"pc":17,"op":"0x55","gas":49976369,"gasCost":22100,"memSize":0,"stack":["0x1","0x0"],"depth":1,"refund":0,"opName":"SSTORE"} +{"pc":18,"op":"0x00","gas":49954269,"gasCost":0,"memSize":0,"stack":[],"depth":1,"refund":0,"opName":"STOP"} +{"output":"","gasUsed":45731,"fork":"Osaka","postHash":"0x2c47b4070c1eef501d9548959c3abde2d8dc78ed1d819697c61d2b0861cc78cf","pass":true} ``` ## Security Considerations -Clients should be aware that tracing can be expensive both in terms of CPU overhead and network bandwidth. -Tracing endpoints should not be enabled by default, and when they are enabled should have access restrictions on the network level. -Failure to do so could result in a client being overwhelmed with requests and, if operating as a validator, cause the client to fail to provide execution attestations in a timely manner. +Clients should be aware that tracing can be expensive both in terms of CPU overhead and network +bandwidth. Tracing endpoints should not be enabled by default, and when they are enabled should have +access restrictions on the network level. Failure to do so could result in a client being +overwhelmed with requests and, if operating as a validator, cause the client to fail to provide +execution attestations in a timely manner. -Differential fuzzing is also a double-edged sword. -While it allows client teams the ability to identify consensus splits, the client teams need to be prompt in fixing any issues that are discovered. +Differential fuzzing is also a double-edged sword. While it allows client teams the ability to +identify consensus splits, the client teams need to be prompt in fixing any issues that are +discovered. ## Copyright diff --git a/EIPS/eip-7784.md b/EIPS/eip-7784.md index f5f280b3d45e16..43d33a8d699529 100644 --- a/EIPS/eip-7784.md +++ b/EIPS/eip-7784.md @@ -1,10 +1,10 @@ --- eip: 7784 title: GETCONTRACT opcode -description: Global byte code accessing by it's hash +description: Global byte code accessing by its hash author: Tim Pechersky (@peersky) discussions-to: https://ethereum-magicians.org/t/eip-7784-getcontract-code/21325 -status: Draft +status: Review type: Standards Track category: Core created: 2024-10-07 @@ -12,13 +12,11 @@ created: 2024-10-07 ## Abstract -Initially proposed in erc track, this EIP is now moved to core track, discussion kept in the same thread as they are related and can be seen as exclusive. - -This is a proposal to add a new opcode, `GETCONTRACT`. The `GETCONTRACT` opcode would return the address containing the bytecode by it's hash. +This is a proposal to add a new opcode, `GETCONTRACT`. The `GETCONTRACT` opcode would return the address containing the bytecode by its hash. ## Motivation -Content addressing by it's hash is a common pattern in database design. It allows to store and retrieve data by it's unique footprint in the storage. This pattern is widely used in the industry and it allows to abstract from actual storage location and allows to reuse the same bytecode in multiple contracts. +Content addressing by hash is a common pattern in database design. It allows to store and retrieve data by its unique footprint in the storage. This pattern is widely used in the industry and it allows abstracting the actual storage location and allows reusing the same bytecode in multiple contracts. Today, existing contract discovery relies on addresses, which are non-deterministic and can be obfuscated through proxies. Indexing by bytecode hash provides a deterministic and tamper-proof way to identify and verify contract code, enhancing security and trust in the Ethereum ecosystem. @@ -30,7 +28,7 @@ For developers relying on extensive code reuse, bytecode referencing protects ag For decentralized application (dApp) developers, a code index can save gas costs by allowing them to reference existing codebase instead of redeploying them, optimizing resource usage. This can be useful for dApps that rely on extensive re-use of same codebase as own dependencies. -This also allows to build new core standards more conveniently, for example, [EIP-7702](./eip-7702) can use it as dependency, to allow users who want to set up one-time code on their EOAs by referring to `GETCONTRACT` instead of uploading the code itself or having to figure out where was the required code deployed. +This also allows to build new core standards more conveniently, for example, [EIP-7702](./eip-7702) can use it as dependency, to allow users who want to set up one-time code on their EOAs by referring to `GETCONTRACT` instead of specifying potentially mutable address based functionality. ## Specification @@ -42,11 +40,15 @@ This also allows to build new core standards more conveniently, for example, [EI * `codehash`: A single 32-byte code hash from the stack. * **Output:** * `address`: If the `codehash` exists in the state, pushes the corresponding contract address onto the stack. Otherwise, pushes 0. -* **Gas Cost:** ?? (TBD) +* **Gas Cost:** 150 * **Stack Effects:** Pops 1 item, pushes 1 item. * **Error Handling:** If the `codehash` is invalid or the bytecode retrieval encounters an error, the instruction will revert. -Every contract stored in EVM MUST be added to the state trie with the key being the keccak256 hash of the contract's bytecode, provided it is not already present and the contract did not invoke the `SELFDESTRUCT` opcode. +Every contract stored in EVM MUST be added to the state trie with the key being the keccak256 hash of the contract's bytecode, provided it is: + +* not already present +* The contract did not invoke the `SELFDESTRUCT` opcode. +* The `EXTCODEHASH` return value IS NOT `0xeadcdba66a79ab5dce91622d1d75c8cff5cff0b96944c3bf1072cd08ce018329` (`keccak256(0xef01)`) ### Example Usage @@ -65,16 +67,20 @@ function getContractAddress(bytes32 codehash) public view returns (address) { **Bytecode over Addresses**: Bytecode is deterministic and can be verified on-chain, while addresses are opaque and mutable. -**EIP not ERC**: This EIP is proposed as a core standard, as it enables global index by default, abstracts developers from need to maintain the index, and can be used as a dependency for other EIPs. - **Do not re-index**: There is small, yet non-zero probability of hash collision attack. Disallowing updates to indexed location of bytecode coupes with this. +**Gas cost**: This operation is more complex than simple data retrieval, however lookup in the database by hash generally is simpler in complexity. + ## Security Considerations **Malicious Code**: The index does NOT guarantee the safety or functionality of indexed contracts. Users MUST exercise caution and perform their own due diligence before interacting with indexed contracts. **Storage contents of registered contracts**: The index only refers to the bytecode of the contract, not the storage contents. This means that the contract state is not indexed and may change over time. +**[EIP-7702](./eip-7702) delegation:** Temporary code delegation is disallowed to prevent case of registering a code hash that becomes unavailable. Standard explicitly disallows contracts with bytecode delegated via [EIP-7702](./eip-7702) from being indexed. + +**SELFDESTRUCT**: Contracts that `selfdestruct` are not indexed, as they will not have a codehash in the state trie. + ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/EIPS/eip-7801.md b/EIPS/eip-7801.md index f8492c8a501bb5..c8ec1a708843a7 100644 --- a/EIPS/eip-7801.md +++ b/EIPS/eip-7801.md @@ -1,9 +1,9 @@ --- eip: 7801 -title: eth/70 - Sharded Blocks Protocol -description: Replaces block range with a bitmask representing 100,000-block spans in the handshake, committing to future block ranges +title: etha - Sharded Blocks Subprotocol +description: Introduces the etha subprotocol for serving historical blocks data. author: Ahmad Bitar (@smartprogrammer93) , Giulio Rebuffo (@Giulio2002), Gary Schulte (@garyschulte) -discussions-to: https://ethereum-magicians.org/t/eip-7801-eth-70-sharded-blocks-protocol/21507 +discussions-to: https://ethereum-magicians.org/t/eip-7801-etha-sharded-blocks-subprotocol/21507 status: Draft type: Standards Track category: Networking @@ -13,41 +13,50 @@ requires: 7642 ## Abstract -This EIP introduces a method enabling an Ethereum node to communicate its available block spans via a bitmask, where each bit represents a 100_000-block span within each 1_000_000 block range of chain history. Nodes use this bitmask to signal which spans of historical data they store and commit to storing future spans as they are created. This enables peers to make informed decisions about data availability without first connecting and querying for availability. The bitmask repeats every 1 million blocks, making for a somewhat simple to reason about probability of data availability. +This EIP proposes the creation of a new subprotocol, `etha`, enabling Ethereum nodes to communicate available block spans via a bitmask. Each bit represents a 100_000-block span within each 1_000_000 block range of chain history. Nodes use this bitmask to signal stored spans and commit to storing future spans as they are created. This allows peers to make informed decisions about data availability without first connecting and querying for it. The bitmask repeats every 1 million blocks for straightforward reasoning about data availability probabilities. -The proposal extends the Ethereum wire protocol (`eth`) with version `eth/70`, introducing a `blockBitmask` field in the handshake. +The `etha` subprotocol has the same functionality to serve historical data using message types copied from the `eth` protocol, enabling efficient data retrieval. ## Motivation -With [EIP-4444](./eip-4444.md), nodes may begin pruning historical data while others continue to serve it. The current approach of connecting and requesting specific blocks to determine data availability is inefficient, consuming unnecessary bandwidth. This EIP addresses this by sharding chain history into 100_000 block segments, and allows nodes to signal which shards they store via a bitmask. +With [EIP-4444](./eip-4444.md), nodes may prune historical data while others continue serving it. Determining data availability by connecting and requesting blocks is inefficient consuming unnexessary bandwidth. This EIP addresses this inefficiency by enabling nodes to shard chain history into 100_000 block segments and signal availability via a bitmask. -By using a bitmask in place of a range, nodes provide a snapshot of data locality and future storage commitments, supporting efficient data requests. +By introducing a separate subprotocol, `etha`, nodes can exchange this information seamlessly and retain the ability to serve historical data without impacting existing `eth` protocol versions. ## Specification -- Advertise a new `eth` protocol capability (version) at `eth/70`. - - The existing `eth/69` protocol will continue alongside `eth/70` until sufficient adoption. -- Modify the `Status (0x00)` message for `eth/70` to add a `blockBitmask` field after the `forkid`: - - Current packet for `eth/69`: `[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid]` - - New packet for `eth/70`: `[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid, blockBitmask]`, - where `blockBitmask` is a 10-bit bitmask, with each bit representing a 100_000-block range per 1_000_000 blocks of history. +### Subprotocol Handshake -- Define node behavior based on the bitmask as follows: - - **Bitmask Initialization**: Upon startup, nodes **MAY** set at least one bit in the `blockBitmask` to `on` and backfill that 100_000-block span to ensure data availability for that shard. - - **Shard Retention Probability**: Nodes **SHOULD** retain new block spans according to their bitmask, with participating nodes providing at least 10% of the chain history. - - **Additional Shard Retention Buffer**: Retained shard ranges should also include 1_000 blocks prior to and after the shard boundary. This will prevent edge effects where a typical range request size of 200 blocks which crosses a 100k shard boundary cannot be satisfied by any single node. - - **Commitment to Future Ranges**: Participating nodes **MUST** retain 100_000 block spans which correspond to their advertised bitmask as blocks are added to the chain - - **Bitmask Space**: The 100_000 range `blockBitmask` repeats every 1 million blocks, enabling efficient representation of historical data locality across epochs. +- Introduce a new subprotocol named `etha`. +- Define the handshake message for the `etha` subprotocol as follows: + - Handshake packet: `[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid, blockBitmask]` + - `blockBitmask` is a 10-bit bitmask, with each bit representing a 100_000-block range per 1_000_000 blocks of history. + - the rest of the elements are as defined in eth/69 -Upon connecting using `eth/70`, nodes exchange the `Status` message, including the `blockBitmask`. This single handshake message, which includes the bitmask, eliminates the need for additional message types. +### Supported Messages -Nodes should maintain connections regardless of a peer’s bitmask state, except when peer slots are full. In this case, nodes may prioritize connections with peers that serve more relevant shards. +The `etha` subprotocol **MUST** include support for the following messages from the `eth/69` protocol to facilitate historical data serving: -If a node is interested in querying a specific block span, it can use the bitmask to determine which peers are more likely to have the data. If the peer they are connected to does not have the data, they can disconnect and connect to another peer, until they find what they have been looking for. +- **GetBlockBodies (0x05):** Request block bodies. +- **BlockBodies (0x06):** Response to `GetBlockBodies`. +- **GetReceipts (0x0f):** Request receipts. +- **Receipts (0x10):** Response to `GetReceipts`. -### ENR variation +The semantics and payload structures for these messages are identical to their counterparts in the `eth/69` protocol, ensuring compatibility for historical data serving. -This EIP could be implemented without a new protocol version by adding a new field to the Ethereum Node Record (ENR) to advertise the bitmask. This would allow nodes to advertise their available block spans without requiring a handshake. However, this approach would not provide the same level of assurance as the handshake, as the ENR is not authenticated. Also, it would make the discovery process much simpler, as nodes would only need to check the ENR to determine if a peer has the data they need. +### Node Behavior + +- **Bitmask Initialization**: Nodes **MAY** set at least one bit in the `blockBitmask` to `on` upon startup and backfill the corresponding 100_000-block span. +- **Shard Retention Probability**: Nodes **MUST** retain new block spans according to their bitmask, aiming to cover at least 10% of chain history. +- **Additional Shard Retention Buffer**: Nodes **SHOULD** retain 1_000 blocks before and after shard boundaries to accommodate edge cases. +- **Commitment to Future Ranges**: Nodes **MUST** retain spans corresponding to their advertised bitmask as new blocks are added. +- **Bitmask Space**: The 100_000 range `blockBitmask` repeats every 1 million blocks, enabling efficient representation of historical data locality across epochs. + +Upon connection using `etha`, nodes exchange the handshake message with the `blockBitmask`. This single handshake eliminates the need for additional message types. + +### ENR Extension + +Alternatively, the `blockBitmask` could be derived or encoded into the Ethereum Node Record (ENR), enabling nodes to advertise block spans without a handshake. As an example, the `blockBitmask` can be derived from the `secp256k1` field of the ENR. However, this method lacks the authentication and reliability of the handshake approach. Additionally, there is not guarantee that the node you are connecting to supports the `etha` subprotocol. ## Rationale @@ -55,9 +64,11 @@ The bitmask approach provides a flexible means to represent and retain block dat A similar bitlist approach is already used in the Consensus Layer for attestation subnets, making it a familiar and efficient method for representing data spans. Additionally, committing to future spans ensures better predictability and stability for data locality. +The `etha` subprotocol separates this functionality from `eth` ensuring nodes dont hammer other nodes with requests on historical ranges that they do not posses on the eth protocol. + ## Backwards Compatibility -This EIP introduces `eth/70`, extending the handshake in a backward-incompatible manner. However, `devp2p` allows concurrent versions of the same protocol, so nodes can continue using older protocol versions (e.g., `eth/69`, `eth/68`, `eth/67`) if they lack support for `eth/70`. +The `etha` subprotocol is independent of the `eth` protocol. This EIP does not affect the consensus engine or require a hard fork. diff --git a/EIPS/eip-7805.md b/EIPS/eip-7805.md index a43045236777dc..980b307e23d947 100644 --- a/EIPS/eip-7805.md +++ b/EIPS/eip-7805.md @@ -40,7 +40,7 @@ This section outlines the workflow of FOCIL, detailing the roles and responsibil - **`Slot N`, `t=0 to 8s`**: IL committee members construct their ILs by including transactions pending in the public mempool, and broadcast them over the P2P network after processing the block for `slot N` and confirming it as the head. If no block is received by `t=7s`, they should run `get_head` and build and release their ILs based on the node’s local head. - By default, ILs are built by selecting raw transactions from the public mempool, ordered by priority fees, up to the IL’s maximum size in bits of 8 KB per IL. Additional rules can be optionally applied to maximize censorship resistance, such as prioritizing valid transactions that have been pending in the mempool the longest. + By default, ILs are built by selecting raw transactions from the public mempool, ordered by priority fees, up to the IL’s maximum size in bits of `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB` per IL. Additional rules can be optionally applied to maximize censorship resistance, such as prioritizing valid transactions that have been pending in the mempool the longest. #### Validators @@ -79,7 +79,7 @@ When validators receive ILs from the P2P network, they perform a series of valid 3. Received two or fewer ILs from this IL committee member (see IL equivocation section below). 4. The IL is correctly signed by the validator. 5. The validator is part of the IL committee. -6. The size of a IL does not exceed the maximum size allowed (e.g., 8 KB). +6. The size of a IL does not exceed the maximum size allowed (e.g., `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB`). ## Specification diff --git a/EIPS/eip-7833.md b/EIPS/eip-7833.md new file mode 100644 index 00000000000000..02cea578e9d305 --- /dev/null +++ b/EIPS/eip-7833.md @@ -0,0 +1,79 @@ +--- +eip: 7833 +title: Scheduled function calls +description: Giving life to smart contracts by enabling their functions to be automatically invoked by block producers. +author: Keyvan Kambakhsh (@keyvank), Nobitex Labs +discussions-to: https://ethereum-magicians.org/t/eip-7833-scheduled-function-calls/21975 +status: Draft +type: Standards Track +category: Core +created: 2024-12-06 +--- + +## Abstract + +Ethereum's smart contracts enable users to delegate control of their funds to code, but these contracts require an external trigger to execute. Timing is often critical, and issues such as network delays or malicious behavior by block producers—like MEV attacks—can prevent timely execution. To address these challenges, this Ethereum Improvement Proposal (EIP) introduces a new opcode, OFFERCALL, which allows contracts to schedule function calls. When functions self-schedule, they exhibit bot-like behavior. These scheduled calls would offer ETH to block producers as an incentive to prioritize their execution over manually submitted transactions. If the offer is not fulfilled, the bot is deactivated until manually re-ignited by the owner. The EIP proposes enforcing the execution of scheduled calls as a requirement for block validity. This could help mitigate MEV attacks, as block producers would be compelled to execute bots that neutralize market manipulation within the blockchain. + +## Specification + +Adding bot-like behavior to an EVM function is achieved by recursively scheduling a call to the same function in the next block. We propose introducing a new EVM opcode, OFFERCALL, which, as the name implies, offers ETH to be burnt to the block producer of the next block in exchange for invoking a function. These offers are aggregated and ranked by the Ethereum node, with only the top N offers being retained; all others are discarded. Scheduled calls must be executed before any user transactions, with execution order determined by their rank in the sorted list. The offered ETH is burnt to prevent block producers from exploiting the system by scheduling calls that pay the offered amounts back to themselves. + +Here is a solidity example of how the usage of OFFERCALL would look like: + +```solidity= +contract Bot { + uint256 offerPerCall; + + constructor(uint256 _offer) { + offerPerCall = _offer; + + // Ignite the bot with an initial invocation offer + offercall(update, offerPerCall); + } + + function setOffer(uint256 _offer) external { + offerPerCall = _offer; + } + + function update() external { + // Do scheduled work + + // The callee may reschedule itself in order to + // introduce a bot-like behavior. + // The callee has to be careful about its offer + // otherwise it may die. + offercall(update, offerPerCall); + + // Once an offercall fails, the contract owner + // may have to set a new offer by calling `setOffer` + // and then invoking the `update()` function again. + } +} +``` + +An OFFERCALL fails in two situations: + +- The contract does not hold at least the offered amount of ETH. +- The offered amount is not large enough to rank within the top N offers. + +In the case of a self-scheduling function, once an OFFERCALL fails, the bot is deactivated. The only way to revive it is for the contract owner to manually call the function again, likely with a higher offer. + +## Rationale + +The rationale behind this Ethereum Improvement Proposal (EIP) stems from the need to enhance the reliability and fairness of smart contract execution on the Ethereum network. While Ethereum’s smart contracts allow for a high degree of programmability and automation, the execution of these contracts often depends on external triggers, such as user transactions or network conditions. This dependency introduces significant challenges, particularly in situations where timing is critical or when malicious actors, like block producers, can exploit the system for profit. + +## Backwards Compatibility + +The introduction of the new OFFERCALL opcode in this EIP requires a network upgrade, as it adds new functionality that is not currently supported by the Ethereum Virtual Machine (EVM). This change will affect how smart contracts can schedule and incentivize the execution of specific function calls, introducing a new mechanism that block producers must accommodate. + +## Reference Implementation + +N/A + +## Security Considerations + +The main concern with this EIP is whether it could lead to centralization, as wealthier users might dominate execution priorities. Burning unfulfilled offers partly addresses this by preventing endless offers. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/EIPS/eip-7834.md b/EIPS/eip-7834.md new file mode 100644 index 00000000000000..0b4376bdbdaebf --- /dev/null +++ b/EIPS/eip-7834.md @@ -0,0 +1,92 @@ +--- +eip: 7834 +title: Separate Metadata Section for EOF +description: Introduce a new separate metadata section to the EOF +author: Kaan Uzdogan (@kuzdogan), Marco Castignoli (@marcocastignoli), Manuel Wedler (@manuelwedler) +discussions-to: https://ethereum-magicians.org/t/eip-7834-separate-metadata-section-for-eof/22138 +status: Draft +type: Standards Track +category: Core +created: 2024-12-06 +requires: 3540 +--- + +## Abstract + +Introduce a new separate metadata section to the Ethereum Object Format (EOF) that is unreachable by the code, and any changes to which does not affect the code. + +## Motivation + +It is desirable to include metadata in contract's bytecode for various reasons. For instance, both the Solidity and Vyper compilers by default include the language and compiler version used to compile. Vyper (with 0.4.1) appends an integrity hash to the initcode in CBOR encoding. Solidity additionally includes the IPFS or the Swarm hash of the Solidity contract metadata.json file, and the experimental Solidity flag. The current (pre-EOF) practice is to append this CBOR encoded metadata section in the contract's runtime bytecode, followed by the 2 bytes length of the CBOR encoded bytes. + +``` + Solidity ┌──────────────────────────────────────────0x0033 bytes──────────────────────────────────────────────┐ +...7265206c656e677468a2646970667358221220dceca8706b29e917dacf25fceef95acac8d90d765ac926663ce4096195952b6164736f6c634300060b0033 +``` + +This poses a problem for source code verification where the onchain bytecode is compared to the compiled bytecode of the given source code. During a contract verification, metadata sections, in particular the IPFS hash, need to be ignored and only the executional bytecode should be compared. Since pre-EOF bytecode is not structured, it is not possible to distinguish the metadata section from the executional bytecode easily. This gets even trickier in the case of factory contracts with multiple nested bytecodes, each having their own metadata sections. Verifiers need to implement their own heuristics and workarounds to find the metadata sections and ignore it. + +The EOF brings structure to the bytecode by separating the code from the data, and placing the code of each contract in their respective containers. In its current form, this makes it possible to find the data easier than the pre-EOF bytecode. However, the current spec also does not describe a metadata section. Compilers currently need to place the contract metadata inside the data section which poses several problems: + +1. It is not straightforward to distinguish the metadata part in the `data_section`, which poses the same problem as the pre-EOF bytecode. +2. Any change to the metadata's size within the data section will change the executional bytecode, e.g. through shifting `DATALOADN` offsets. With that, two identical contracts with different metadata sizes will not match during source code, since the code will be different. +3. The metadata can theoretically be reached by the code, e.g. via manipulating the `DATALOADN` instructions. + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +Extending the format introduced in [EIP-3540](./eip-3540.md), this EIP proposes to add a new OPTIONAL section in the body called `metadata_section` before the `data_section`, and to add two new OPTIONAL fields `kind_metadata` (value: `0x05`) and `metadata_size` to the header before the `kind_data` and `data_size` fields. + +``` +container := header, body +header := + magic, version, + kind_type, type_size, + kind_code, num_code_sections, code_size+, + [kind_container, num_container_sections, container_size+,] + [kind_metadata, metadata_size,] + kind_data, data_size, + terminator +body := types_section, code_section+, container_section*, [metadata_section], data_section +types_section := (inputs, outputs, max_stack_height)+ +``` + +### Header + +| name | length | value | description | +| ------------- | ------- | ------------- | --------------------------------------------------------------------------------------- | +| ... | ... | ... | ... | +| kind_metadata | 1 byte | 0x05 | kind marker for metadata size section | +| metadata_size | 2 bytes | 0x0001-0xFFFF | 16-bit unsigned big-endian integer denoting the length of the metadata section content | +| kind_data | 1 byte | 0x04 | kind marker for data size section | +| data_size | 2 bytes | 0x0000-0xFFFF | 16-bit unsigned big-endian integer denoting the length of the data section content (\*) | +| terminator | 1 byte | 0x00 | marks the end of the header | + +### Body + +| name | length | value | description | +| ---------------- | -------- | ----- | --------------------------- | +| ... | ... | ... | ... | +| metadata_section | variable | n/a | arbitrary sequence of bytes | +| data_section | variable | n/a | arbitrary sequence of bytes | + +The strucure and the encoding of the `metadata_section` is not defined by this EIP. It is left to the compilers, tooling, or the contract developers to define the encoding and the content. The current practice by the Solidity and Vyper compilers is to use CBOR encoding. + +## Rationale + +The `metadata_section` in the `body`, as well as the `kind_metadata` and `metadata_size` fields in the `header`, are OPTIONAL. This way, the compilers can avoid additional bytes in the container if they don't want to write any metadata. The `data_section` can change in its size and content during deployment, therefore it needs to be REQUIRED, even if the data is empty. The `metadata_section` is not expected to change during the deployment. + +The reason for placing the `metadata_section` before the `data_section`, and assigning `kind_metadata` the value `0x05` (and not `0x04`) is to make it easier for the existing EOF tooling adapt the changes. Additionally, if the `metadata_section` was placed after the `data_section`, changes to the `data_section` in deploy time would cause the `metadata_section` to shift. By placing the `metadata_section` before, this could be mitigated. + +## Backwards Compatibility + +No backward compatibility issues are expected since [EIP-3540](./eip-3540.md) is not implemented yet. + +## Security Considerations + +No security considerations as this section is meant not to be executed. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md).