ethereum
Electra EIPs for discussion
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 |
If this is the Verkle fork, some form of SSZ for the other _root beside state_root.
Still have to revamp the EIPs based on the latest feedback from #typed-transactions, but tracking them here for awareness.
Upgrade was named Electra on ACDC 113 when Danny was away: https://github.com/ethereum/pm/issues/823#issuecomment-1635053770
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
Potential EIP proposal for electra inclusion
- https://ethereum-magicians.org/t/track-historicalexecutionroots-states-in-beaconstate-accumulators/18201
The complete list of the "SSZ-ification" section:
- EIP-7495: SSZ StableContainer
- EIP-6493: SSZ Transaction Signature Scheme
- EIP-6404: SSZ Transactions Root
- EIP-6466: SSZ Receipts Root
- 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.
another think which I think would greatly benefit solo stakers:
- https://ethereum-magicians.org/t/el-triggered-validator-pause/18218
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,ExecutionPayloadand 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
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.
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).