# Amphora Spec changes and issues ## CL specs * [x] [NOT CONSIDERED ANYMORE] Consider specifying validators build block with empty transactions if prepare_payload fails [#2644](https://github.com/ethereum/consensus-specs/issues/2644) -- in the case when the previous payload *has been* validated * Note, this would require being able to construct an EL hash on CL side * Danny -- This seems like an example of breaking the CL and EL layers in the specs as we would ahve to specify *how* to make a valid empty-tx payload and to hash it. Although CL software can perform this optimization, keeping EL payload production behind the `Engine` in the CL specs is much cleaner and I would argue against specifying it in CL regardless of practical optimization * [x] [[#2682](https://github.com/ethereum/consensus-specs/pull/2682)] ensure fork choice does not consider TTD terminal blocks *if* TBH has been set. `validator.md` currently will only build on TBH if set, but `fork-choice.md` will allow both types of terminal * [x] [[#2685](https://github.com/ethereum/consensus-specs/pull/2684)] Clean up [transaction type representation](https://github.com/ethereum/consensus-specs/issues/2608) * [x] [[#2686](https://github.com/ethereum/consensus-specs/pull/2686)] Expand `MAX_BYTES_PER_OPAQUE_TRANSACTION` and `MAX_TRANSACTIONS_PER_PAYLOAD` the be closer to theoretical maxes and use gas-limit as ultimate bound and use sane limits on p2p for dos protections * [x] [[#2699](https://github.com/ethereum/consensus-specs/pull/2699)] consider removing gas-limit checks from CL * Danny -- Right now, this just represents logic that is specified in two places and is not even complete on CL. This seems to be very much an EL validation * [x] [[#2682](https://github.com/ethereum/consensus-specs/pull/2682)] `TERMINAL_BLOCKHASH_OVERRIDE` has a bug. It needs an trigger epoch along with it * [x] [[#2683](https://github.com/ethereum/consensus-specs/pull/2683) remove `prepare_payload` from spec in favor of unified method with forkchoiceUpdated (as in [engine API](https://github.com/ethereum/execution-apis/pull/83)) ## EL specs * EIP-3675 * [x] [[4351](https://github.com/ethereum/EIPs/pull/4351)] Enforce for PoS consensus engine that `extra_data` has max 32-byte size. Make it clear that even if the pre-transition chain's consnesus has >32 that it *MUST* truncate to 32-byte at the point of the merge * [x] [[#4411](https://github.com/ethereum/EIPs/pull/4411)] Specify `FORK_NEXT` value in the EIP (see [EIP-2124](https://eips.ethereum.org/EIPS/eip-2124)). The rough consensus is to have `FORK_NEXT = 0` (i.e. not set) as the easiest path to go * [x] [[#4397](https://github.com/ethereum/EIPs/pull/4397)] Modify to allow CL totally in charge of TBH and TTD (regardless of local values) [documented here](https://github.com/ethereum/consensus-specs/issues/2643#issuecomment-953250363) * [x] [[#4399](https://github.com/ethereum/EIPs/pull/4399)] EIP: Insert `randao_mix` into `DIFFICULTY` opcode. rename `RANDOM` * [ ] EIP: EL client software MAY NOT store data of entire chain history (headers, bodies, receipts) (assigned to: lightclient, george, etc) * [x] [[#4396](https://github.com/ethereum/EIPs/pull/4396)] EIP: empty slots must be taken into account in `baseFeePerGas` computation after the Merge (potentially rely on block timestamps and `SECONDS_PER_SLOT`) (assigned to: ansgar) ## Engine API * [x] [[#89](https://github.com/ethereum/execution-apis/pull/89)] hi-jack JSON-RPC seq number to order EL execution of calls * `consensusValidatd` * [x] [[#82](https://github.com/ethereum/EIPs/pull/4351)](https://github.com/ethereum/execution-apis/pull/82) Remove `consensusValidated` -- extraneous and even dangerous (due to many:1 beaconblock:executionpayload possibility) * [ ] related: add warning to `web3.eth.getBlockByHash` (or similar method) that blocks have not necessarily been corectly validated wtr beacon chain consensus. Point them to beacon API to do so. Probably need `web3.beacon.getBeaconBlocksByExecutionPayloadHash` to satisfy this. note that this is plural because multiple beacon blocks can include the same exact payload (i.e. sister blocks that have same exec payload contents) * [ ] consider `forkchoiceUpdated` and/or `executePayload(child_payload)` as a confirmation of block's validity wrt PoS rules; i.e. space of "unsafe" blocks could be reduced to leaf blocks that have never been in the canonical chain * `executePayload` * [ ] (UNDER CONSIDERATION. not critical for spec release -- [#91](https://github.com/ethereum/execution-apis/issues/91)) define QoS expectation on return -- e.g. 0.5s or `SLOTS_PER_SECOND / 30` * [x] [[#84](https://github.com/ethereum/execution-apis/pull/84)] Add `latest_correct_ancestor` to `INVALID` return to allow for multi-pruning of bad beacon blocks wrt EL * [ ] Add clear directives that this method MUST continue to be called optimistically to give info to EL. To [aid sync and avoid deadlocks](https://notes.ethereum.org/@djrtwo/BJxKBaqNF) * `forkChoiceUpdated` * [x] [[#93](https://github.com/ethereum/execution-apis/pull/93)] Add `safeHead` as a param. Stub as the same as `head` * [ ] Add clear directives that this method MUST continue to be called optimistically to give info to EL. To [aid sync and avoid deadlocks](https://notes.ethereum.org/@djrtwo/BJxKBaqNF) * [x] [[#83](https://github.com/ethereum/execution-apis/pull/83)] Combine `preparePayload` into this -- "fork choice is updated, and please start some work!" * `preparePayload` * [x] [[#83](https://github.com/ethereum/execution-apis/pull/83)] consider removing this method with adding the corresponding flag and required data to `forkchoiceUpdated` * [ ] Consider adding `getPayloadsByRange` to engine API for payload deduplication across CL/EL -- see [doc for discussion](https://notes.ethereum.org/3_8ELmGXTIyghe9bzmBWUA?view) * consider the option for `BeaconBlocksByRange` to replace payloads with their roots * Refine transition process in the specs * [x] [[#2676](https://github.com/ethereum/consensus-specs/pull/2676)] CL behaviour around transition block during the sync in case if EL is syncing and can't verify terminal block conditions. Sync optimistically and get back to the transition block to verify that the terminal block conditions have met unless transition block is finalized. see [aid sync and avoid deadlocks](https://notes.ethereum.org/@djrtwo/BJxKBaqNF) * [ ] When communication with EL should be started, i.e. go through each EE method call and make a note if needed * [x] [[#2681](https://github.com/ethereum/consensus-specs/pull/2681)] Zeroed hash MUST be passed as `finalized_block_hash` in `notify_forkchoice_updated` if no payload has yet been finalized * [x] [[#85](https://github.com/ethereum/execution-apis/pull/85)] EngineAPI error codes * Versioning * [x] [[#94](https://github.com/ethereum/execution-apis/pull/94)] Use `Vx` as a method suffix to specify the version, i.e. `engine_executePayloadV1`, `engine_executePayloadV2`, etc. A bit ugly but should be sufficient enough to handle updates to data structures, method parameter sets, parameter semantics, method call semantics, etc * Many-to-one * [x] [[#88](https://github.com/ethereum/execution-apis/pull/88)] Put a note to the spec that many-to-one is only supported in one writer + multiple readers set up wrt `forkchoiceUpdated` method call. Setup with multiple CLs sending `forkchoiceUpdated` messages isn't supported by the API while multiple `executePayload` senders is supported * [x] [[#88](https://github.com/ethereum/execution-apis/pull/88)] Multiple CL proposers are not supported either. It brings a ton of complexity to EL as requires supporting multiple instances of Transaction pool ## Hive * CL simulator * covers Engine API implementation by EL and EIP-3675 requirements including: * the Networking section (block gossip deprecation) * TTD hardcode, TTD and TBH (terminal block hash) overrides * fast/snap sync and processing blocks received via gossip MUST respect TTD and TBH * relies on the Engine API as a entry point, should have a predefined Engine API calls as a test vector * CL+EL fully functional nodes * covers transition process with various edge cases that may appear in it * network partitioning, involves two nodes; a terminal block is withheld by a node and after some time released to another node; it should be successfully processed * passing a terminal block point while syncing; then CL must go back and validate terminal block conditions, finalized and not yet finalized cases should be covered; similar to the case when block is withheld * covers Engine API implementation by CL * covers consensus specs * CL reads pre-loaded list of blocks, need to figure out how to emulate network partitioning * Run all tests with all possible client combinations