Consensus-layer Call 99
djrtwo opened this issue Β· 8 comments
Consensus-layer Call 99 Agenda
Meeting Date/Time: Thursday 2022/12/1 at 14:00 UTC
Meeting Duration: 1.5 hours
livestream
- Capella
- testnets / progress updates
- bound withdrawals sweep ethereum/consensus-specs#3095
- 4844
- any updates worth percolating up to the larger call
- KZG ceremony update
- Research, spec, etc
- (networking) attnets revamp #667 (comment)
- (networking) ipv6 dual-stack support #667 (comment)
- (Beacon API) checkpoint sync api status ethereum/beacon-APIs#226 (comment)
- (Beacon API) Attestation and sync committee aggregation selection ethereum/beacon-APIs#224
- (engine api) engine api spec improvement proposal #667 (comment)
- Open Discussion/Closing Remarks
If there's time, can we discuss potentially releasing some backwards compatible changes:
- Reduction in nodes per long-lived subnet: ethereum/consensus-specs#2749
This can be released entirely in a backwards compatible way, but the net result will be less nodes on long-lived subnets. There is a constant (SUBNETS_PER_NODE) that we can set to minimize the impact on the transition. - Ipv6 dual-stack support. We've been working towards enabling this throughout all our protocols. First step is enabling ipv6 on our bootnodes which gives an entry-point for ipv6 compatible nodes to connect and advertise ipv6 support. This is also backwards compatible.
Not to be released, but discuss some ideas/work towards automatic NAT hole punching, which may also help finding extra nodes on long-lived subnets.
As a follow up to my recent comment ethereum/beacon-APIs#226 (comment), I would like to give an overview on Checkpoint Sync API status.
Hi all,
I'd like a few minutes to introduce this proposal ethereum/beacon-APIs#224 to the teams if possible :)
I would like to go over Engine API spec improvement proposal, discussion points:
engine_getCapsvs optimistic try and fallback on error, more context ethereum/execution-apis#321 (comment)- main question: will CL client devs utilise
engine_getCapsor everyone is fine with try and fallback approach
- main question: will CL client devs utilise
- functional vs by-fork decomposition, examples:
I'd like to revisit this PR: ethereum/consensus-specs#3095
that adds a bound to the sweep over the validator set per block
This is the last open question on the spec so I'd like to reach agreement on merging or not; if you want to track general progress, you can check out this document: https://notes.ethereum.org/LqHDfmQdS96KWgs3UzGeyA
I'd like to mention the KZG Ceremony briefly just to build awareness as we wrap up the second audit and move towards the public contribution period!