Electra EIPs for discussion

[djrtwo]

Please comment with EIPs to be discussed for inclusion in Electra upgrade
For discussion:

EIP	Title	CL specs	EL change?	Inclusion status
EIP-6110	Supply validator deposits on chain	alpha	Y	Included
EIP-6914	Reuse validator indices	alpha	N	No
EIP-7002	Execution layer triggerable exits	alpha	Y	Included
EIP-7251	Increase the MAX_EFFECTIVE_BALANCE	resource collection	N	Discussion
EIP-7547	Inclusion lists	draft, resource collection	Y	Discussion
EIP-7549	Move committee index outside attestation	alpha	N	Included
EIP-7594	PeerDAS - Peer Data Availability Sampling	draft	N	Discussion
SSZ-ification				Discussion
1. EIP-6404	SSZ Transactions Root		Y
2. EIP-6465	SSZ Withdrawals Root		Y
3. EIP-6466	SSZ Receipts Root		Y
4. EIP-6493	SSZ Transaction Signature Scheme		Y
5. EIP-7495	SSZ StableContainer		Y

[mkalinin]

• EIP-6110: Supply validator deposits on chain

[dapplion]

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

[etan-status]

If this is the Verkle fork, some form of SSZ for the other _root beside state_root.

• EIP-6404: SSZ Transactions Root
• EIP-6465: SSZ Withdrawals Root
• EIP-6466: SSZ Receipts Root

Still have to revamp the EIPs based on the latest feedback from #typed-transactions, but tracking them here for awareness.

[djrtwo]

EIP 6914: Reuse validator indices

[abcoathup]

Upgrade was named Electra on ACDC 113 when Danny was away: ethereum/pm#823 (comment)

[dapplion]

EIP-7549: Move committee index outside Attestation

[abcoathup]

Add EIP7594: PeerDAS
https://github.com/ethereum/EIPs/pull/8105/files

[g11tech]

imo:

sszification + 6110 (on chain deposits) + 7002 (el triggered exits/partial withdrawals) makes sense for EL side cleanup pre-verkle

on CL side: PeerDAS looks exciting and could be the show stopper of the next fork , 7549 + 6914 looks easy enough and EIP 7251 looks important enough to stall/slow (or even reverse) the growth of the beacon state

plus would love to see some of the containers to move to Partial/Extensible containers on the lines of the EIPs suggested by @etan-status

[g11tech]

Potential EIP proposal for electra inclusion

• https://ethereum-magicians.org/t/track-historicalexecutionroots-states-in-beaconstate-accumulators/18201

[etan-status]

The complete list of the "SSZ-ification" section:

1. EIP-7495: SSZ StableContainer
2. EIP-6493: SSZ Transaction Signature Scheme
3. EIP-6404: SSZ Transactions Root
4. EIP-6466: SSZ Receipts Root
5. EIP-6465: SSZ Withdrawals Root

The one that @g11tech mentioned above is EIP-7495: SSZ StableContainer -- I think the idea is to also transition BeaconBlockBody, ExecutionPayload and so on to a format where members retain their location in the merkle tree across forks (e.g., right now, in whisk, some gindex has to be re-assigned from Capella, changing tree shape).

Having a stable tree shape means that clients that want to validate presence of specific information can do so without continuously updating their Merkle proof validation logic, as long as the queried information retains its semantic meaning.

[g11tech]

another think which I think would greatly benefit solo stakers:

• https://ethereum-magicians.org/t/el-triggered-validator-pause/18218

[g11tech]

The complete list of the "SSZ-ification" section:

1. [EIP-7495: SSZ StableContainer](https://eips.ethereum.org/EIPS/eip-7495)

2. [EIP-6493: SSZ Transaction Signature Scheme](https://eips.ethereum.org/EIPS/eip-6493)

3. [EIP-6404: SSZ Transactions Root](https://eips.ethereum.org/EIPS/eip-6404)

4. [EIP-6466: SSZ Receipts Root](https://eips.ethereum.org/EIPS/eip-6466)

5. [EIP-6465: SSZ Withdrawals Root](https://eips.ethereum.org/EIPS/eip-6465)

The one that @g11tech mentioned above is EIP-7495: SSZ StableContainer -- I think the idea is to also transition BeaconBlockBody, ExecutionPayload and so on to a format where members retain their location in the merkle tree across forks (e.g., right now, in whisk, some gindex has to be re-assigned from Capella, changing tree shape).

Having a stable tree shape means that clients that want to validate presence of specific information can do so without continuously updating their Merkle proof validation logic, as long as the queried information retains its semantic meaning.

+1, least we can do in Electra is StableContainers for BeaconBlockBody and ExecutionPayload

[protolambda]

EIP-6466, SSZ receipts, is incredibly impactful for its small scope: it makes receipt-proving a lot more viable.

Currently EVM receipts just concatenate log events of completely different contracts, which means applications have no control over their ability to make their log event provable without the user having to prove a potentially multi-megabyte preimage (worst-case does not fit in EVM).
That said, merkleizing to separate log events, each with their contract address source as a mix-in, would also work for some use-cases.

Edit: also, apologies for posting here, there's a longer thread of SSZ related comments here. Happy to move it all into eth-magicians forum if this isn't the right place.

[etan-status]

Another interesting addition could be:

• https://gist.github.com/karalabe/e106ac58afc1d611641e543312cf41e3

This does not have to be tied to a fork specifically, but most of the work is necessary as preparation for Verkle anyway, and adding support for minority ELs to use an eth_getProof based "database" (without locally storing anything) would grant them veto power, drastically reducing the possibility of a Geth bug to issue a VALID verdict for an incorrect block. Geth is the only EL with an install base that can finalize a fake-valid block, so it would have to be the only one providing efficient eth_getProof access while processing engine_newPayload (before engine_forkchoiceUpdated).