Source: https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md [x] Paris payloads MUST be processed by newPayloadV2 and forkchoiceUpdatedV2[x] case with forkchoiceUpdatedV2 and payloadAttributes == null, and Paris block data [x] case with forkchoiceUpdatedV2 and payloadAttributes == null, and Shanghai block data [x] case with forkchoiceUpdatedV2 and payloadAttributes = {data of the first Capella slot} etc [x] EL MUST return -32602: Invalid params in the following cases: [x] newPayloadV2ExecutionPayloadV1 passed with timestamp >= SHANGHAI_TIMESTAMP
2/2/2023Next steps Explore design space without pending_queue in the beacon stateTransition: process block.body.deposits and block.body.execution_payload.deposits in parallel instead of queuing the latter and waiting for the former to fill the gap (proposed by Peter Davies) WS period: confirm that a significant increase of a number of top ups per epoch is fine (pubkey, index) cache: confirm that CL client devs are fine with taking this engineering complexity in favour of complexity related to pending_queuedata complexity of two queues is higher than of one because of top ups, each top up would take a separate record in the pending_queue while all top ups for the same validator are accumulated in a single record in the validator registry sig verification complexity: limited by a size of EL block, worth re-evaluating Evaluate a number of deposits per 30M gas block that advanced attacker can induce by making multiple deposits in one transaction (reduced cost by removing base tx fee and re-using warmed up state slot reads/writes) -- Peter Davies to do the evaluation one deposit per transaction consumes 50-60k gas and results in 500-600 deposits per 30M gas block at max; this number can be doubled with the tricks
1/26/2023Kintsugi spec updated to v3 on November 30. See v3 change set for details. [toc] This document defines the version of the Merge specification that is considered to be implemented for Kintsugi🍵 -- the Merge sprint for November 2021 -- and provides additional guidance to client developers. Spec versions The following is Kintsugi Spec v3. Specification
11/30/2021[toc] This document defines the version of the Merge specification that should be implemented as a prerequisite for the Interop and provides additional guidance to client developers. Spec versions The Merge specification has a number of different sources that should be aligned with each other to avoid incompatibility issues between consensus and execution client implementations. We define the following versions for each of these documents to be used during the Interop: Specification
10/5/2021