Consensus-layer Call 134

[ralexstokes]

Consensus-layer Call 134

prev: call 133

Meeting Date/Time: Thursday 2024/5/30 at 14:00 UTC Meeting Duration: 1.5 hours stream

0. Electra
   • devnet-0, interop recap
     • EIP-7549: keep attestation behavior as-is at fork boundary
     • EIP-7251: EL-triggered consolidations? drop consolidations for electra?
     • EIP-6110: https://github.com/ethereum/consensus-specs/pull/3689#issuecomment-2112987260
   • https://github.com/ethereum/consensus-specs/pull/3768
   • https://github.com/ethereum/execution-apis/pull/551
   • https://eips.ethereum.org/EIPS/eip-7688: use in EIP-7549 Attestations, and other data structures
   • PeerDAS status
   • Fork scoping reflecting learnings from devnet-0: include PeerDAS?
1. Research, spec, etc
   • F-star naming
2. Open discussion/Closing remarks

[dapplion]

We should summarize interop remarks re peerdas

[wemeetagain]

Would like to discuss EIP-7688: Forward compatible consensus data structures for inclusion in Electra

• EIP-7688: Forward compatible consensus data structures fixes issues with EIP-4788: Beacon block root in the EVM based smart contracts breaking on forks.
  • Pectra changes the Merkleization layout of Consensus data structures due to EIP-6110 Deposits, EIP-7549 Attestation changes, and EIP-7251 MaxEB.
  • Smart contract verifiers such as Slashing proofoor or RocketPool's contracts need upgrades despite no change in validator slashing status functionality.
  • Ethereum should have a stable ABI, allowing smart contracts to work across forks. EIP-7688 involves a one-time breakage (already present in Pectra!) and resolves the problem for future forks.
  • Android/iOS adoption of a system service for secure Ethereum wallets is hampered if they need to align OS releases with Ethereum's forks.
• As shown at the interop, the level of effort for implementation is fairly low.
  • No EL code change
  • CL implements a subset of EIP-7495: SSZ StableContainer (No StableContainer, just Profile functionality)
  • I was able to implement this (ssz library + integration into lodestar) in 2 days
• Several CLs have reviewed this EIP and informally agreed that this EIP may be added with minimal effort.

[hwwhww]

If we have time left, we can talk about the F-star naming. ⭐

[jorem321]

Hello! On behalf of Nethermind Research, I would like to signal our interest in presenting the results of the research report "Allowing validators to provide client information privately". This work was sponsored by a grant from the Ethereum Foundation, and its presentation to the community is an important milestone for its completion.

This research discusses methods that can be used (with some changes to the Ethereum protocol) to gather client diversity data from validators in an anonymous fashion. We would greatly appreciate your feedback on this.

PS: If possible, we would prefer to present this work during the next CL call, in mid-June.

[mkalinin]

I would like to discuss an alternative to EIP-7685. The draft of the proposal is outlined in the Engine API PR with additional discussion points in the description:

• https://github.com/ethereum/execution-apis/pull/551

The proposed change affects both layers and is potential simplification for EL and IMHO is cleaner from the CL perspective. It would be great to discuss the engineering complexity and potential security issues that might be caused by this change.

[etan-status]

I'd like to add:

• Electra
  • EIP-7549 Attestations, some naming / field order comments:
  • https://github.com/ethereum/consensus-specs/pull/3768
  • EIP-7688 Forward compatible consensus data structures:
  • https://stabilitynow.box tracks implementation and provides devnet
  • Any upside from not including it into Pectra?
    • EIP-4788 based verifiers are breaking regardless, not doing this now when they break anyway would introduce additional avoidable breakage in subsequent forks.
    • Verkle needs some support for optionals on CL, for which EIP-7688 provides a technical basis.
  • Separate from EIP-6493, or should both be done at the same time?
    • Argument for doing both now: Electra MPT (7685) / transaction type (7702) would have to be replaced only few months after introduction
    • Argument for splitting: If EIP-6493 is in a separate fork, its scope may be extended to also cover the EL block header. That way, execution_payload could be replaced with execution_block and match it 1:1, allowing further optimizations down the road such as SSZ based engine / builder APIs which are > 2x more efficient than text based JSON.
    • Note that EL block header could also be done later on even if EIP-6493 / 6404/6466/6465 are already done now, with Pectra

[ralexstokes]

Hello! On behalf of Nethermind Research, I would like to signal our interest in presenting the results of the research report "Allowing validators to provide client information privately". This work was sponsored by a grant from the Ethereum Foundation, and its presentation to the community is an important milestone for its completion.

This research discusses methods that can be used (with some changes to the Ethereum protocol) to gather client diversity data from validators in an anonymous fashion. We would greatly appreciate your feedback on this.

PS: If possible, we would prefer to present this work during the next CL call, in mid-June.

@jorem321 that works! please just post on the agenda when you are ready

[ralexstokes]

closing in lieu of #1069