Analysis of the following parameters of the Withdrawal request smart contract: MAX_WITHDRAWAL_REQUESTS_PER_BLOCK = 16 TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK = 2 TL; DR: These parameters have reasonable values. Consensus layer with TARGET=2, MAX=16 Full withdrawal requests doesn't create additional data complexity on the CL side as the changes are applied to the list of validators.

EIP-7742Desirable for Pectra as then PeerDAS rollout will not require an EL change Adding target to the EL block header doesn't make much sense without changing the fee market as the existing fee calculation would work only if TARGET = MAX / 2 Ansgar and Gajinder to come up with the fee market proposal till the end of the next week. The final decision to be made on the next ACDC (Nov 28); ship without 7742 if there is no concensus around the proposed change on the ACDC Updating TARGET/MAX to 4/6 by bumping the parameters is also considered One of the concerns is that it will delay Pectra Another concern is related to syncing the chain under non-finalityNon-finality devnets to run with TARGET/MAX = 5/10 or even more aggressive numbers CL devs to review and approve https://github.com/ethereum/consensus-specs/pull/3998

Fork Choice compliance testing methodology and report Consensus-specs PR, test generator, models Test suites Link to the suite integration in Teku

This proposal extends the EIP-7549 by introducing an on chain aggregate optimisation enabled by the EIP. This proposal comes with a notion of network and on chain aggregate. Although, both type of aggregates are represented by the same Attestation structure, their data complexity are different which is enforced by the additional gossipsub validation rule. Spec changes The changes are based on the consensus-specs#3559. Modified preset Name Value

This document describes a procedure of deprecating engine_exchangeTransitionConfiguration method and tracks the progress on it. There is a corresponding deprecation notice in the Engine API Cancun spec. Steps suggested to gracefully deprecate this method are as follows: EL clients stop logging an error message indicating that the method hasn't been called for a while. Every EL client cuts a release with this change before Cancun. After EL releases are out, CL clients stop calling the method (it can be removed entirely on their end). Every CL client includes this change into Deneb release or earlier. EL clients are free to remove the method handler after Cancun happens assuming node operators updated their CL clients to a version that is not calling this method anymore. EL Status

EIP-6110: Supply validator deposits on chain Abstract Appends validator deposits to the Execution Layer block structure. This shifts responsibility of deposit inclusion and validation to the Execution Layer and removes the need for deposit (or eth1data) voting from the Consensus Layer. Validator deposits list supplied in a block is obtained by parsing deposit contract log events emitted by each deposit transaction included in a given block. Summary This document gives a summary of an EIP-6110 prototype project. Goals of the project can be roughly outlined as follows:

Specification Execution Layer EIP-6110 Conensus Layer #3177 Engine API eip6110.md Specification work [x] Explore design space without pending_queue in the beacon state, #08c728, #23c10c. [x] Rebase spec with Deneb/Cancun [ ] Confirm that a significant increase of a number of top ups per epoch is fine wrt WS period computation. [ ] Confirm that CL client devs are fine with taking the (pubkey, index) cache complexity in favour of complexity related to pending_queue.

Call 10 Meeting Date/Time: Thursday 2023/6/29 at 15:30 UTC Meeting Duration: 45 minutes Testing :heavy_check_mark: Stage 1: Set sleep time to 1 second (about 12 deposits in 12 seconds).Sleep Time: 1 second Number of Deposits per Slot: ~12 Duration of the Test: At least 1 minute to observe sustained behavior. Total Number of Deposit Data Entries Needed: 12 * 5 + 5 = 65 (for 1 minute of testing with 5 additional deposits)

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

Next 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

Kiln spec v2.1 released on March 10. See v2.1 change set for details. [toc] This document defines the version of the Merge specification that is considered to be implemented for Kiln🔥🧱 -- the last Merge sprint before launching pre-production testnets. Kiln aims to move client implementations into the production readiness stage. Spec versions The following is Kiln Spec v2.1: Specification

Kintsugi 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

[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

The purpose of this document is to frame the design space of the Consensus API. It starts with the minimally required set of methods and gradually increases the complexity of the design by adding asynchrony, consistency checkpoints and some methods that might increase UX and aid for faster recovery after failures but are not required for the core functionality. The end goal is to come up with the solution that would not restrict future extensibility of the protocol and on the other hand would re-use as much of the existing JSON-RPC implementation over HTTP and websockets that we already have across clients. The security of this API is critical, thus we propose that implementations expose this API at an independent port from standard JSON-RPC user API and to put the new set of methods into a new namespace. With this progressive idea in mind we prefix engine_ as the namespace as a working prototype to be able to generalize API between L1 and L2 in the future, though, the name is debatable and doesn't matter that much at this stage. Previous work: Rayonism consensus JSON-RPC Some thoughts on API improvements

Beacon chain Configuration Execution Name Value MAX_BYTES_PER_TRANSACTION_PAYLOAD 2**20

Affected parts Intro Say about allowing to move execution to a shard as the main design consideration Data structures Validator State transition Data structures A bit of elaboration on each. Should be straightforward