AllCoreDevs - Testing CL Breakout #096
Transcript
- Nico Flaig
problem is deposit_requests has no limit so you can just dos using those, so having limits on ther fields doesn't buy you that much in case of an attack
- james
Kasey would know more on this but we have this pr https://github.com/OffchainLabs/prysm/pull/17412
- Daniel Knopik
I am wondering why size bounds (https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/p2p-interface.md#type-specific-ssz-bounds are not sufficient to prevent abuse. is deserialization able to inflate memory used that much?
- Nico Flaig
Replying to "I am wondering why s..." problem is the bound of beacon block is 10mib
- Potuz
Replying to "I am wondering why s..." the solution to this is to have the max size computed from gas limit and provable, so these limits are irrelevant in that case
- Daniel Knopik
Replying to "I am wondering why..." Is the 10mib limit retained from pre-gloas? does it need to be that high in gloas?
- Nico Flaig
Replying to "I am wondering why s..." deposits are only bound by gas limit which is theoretically unlimited
- Pawan Dhananjay
Replying to "I am wondering why s..." 10mb is just general limit for anything over the wire
- Daniel Knopik
Reacted to "deposits are only ..." with 🙏
- Nico Flaig
that's what I did in lodestar, we can't deserialize a block above 0 deposits anymore, it fails early
- Enrico Del Fante
Reacted to "that's what I did in lodestar, we can't deserialize a block with 0 deposits anymore, it fails early" with 👍
- Justin Traglia
Reacted to "10mb is just general limit for anything over the wire" with 👍
- Justin Traglia
Maximum allowed size of uncompressed payload in gossipsub messages and RPC chunks
- Daniel Knopik
Reacted to "Maximum allowed si..." with 🙏
- Justin Traglia
Replying to "Maximum allowed size..." Also this: https://github.com/ethereum/consensus-specs/blob/f21dac06e99743b1e98bb80297897b96520c942b/specs/phase0/p2p-interface.md?plain=1#L492-L512
- Nico Flaig
to be clear, the checks where this matters is `should_apply_proposer_boost` and `is_proposer_equivocation`, right?
- Justin Traglia
Replying to "to be clear, the che..." https://ethereum.github.io/spec-viewer/#consensus/nightly/functions-should_apply_proposer_boost-gloas https://ethereum.github.io/spec-viewer/#consensus/nightly/functions-is_proposer_equivocation-phase0
- Nico Flaig
I think prysm code is correct, easy to adapt for us
- Justin Traglia
- jxs
- jxs
we've merged it last week as arranged
- Justin Traglia
Reacted to "https://github.com/sigp/lighthouse/pull/9522" with 🔥
- Potuz
we want to get rid of yamux as well
- jxs
Reacted to "we want to get rid..." with 👍
Call summary
Targets
- •MPlex deprecated before Gloas mainnet upgrade - 00:41:55
Decisions
- •Clients should count invalid equivocations in fork choice; Prysm behavior is correct reference - 00:29:06
- •MPlex deprecation proceeds; target before Gloas mainnet, no team blocking in principle - 00:41:55
Highlights
- Mplex Deprecation:
- ·Lighthouse merged MPlex deprecation PR last week; Teku QUIC has memory leaks being fixed, not yet production-stable - 00:36:10
- ·Target: deprecate MPlex before Gloas mainnet; Teku signals no blocker in principle but needs further refinement - 00:41:18
- Fork Choice Equivocations:
- ·Prysm counts equivocating blocks in fork choice before full validation; other clients only count valid ones per spec - 00:26:27
- ·Consensus: clients should count invalid equivocations in fork choice — Prysm behavior is correct, spec should be updated - 00:29:06
- ·DOS risk: a proposer sending many differently-signed blocks could force signature verification on each; Potuz may cap at 3 - 00:33:36
- Ssz Progressive Container Deserialization:
- ·Progressive containers: consensus moving toward reinstating hard limits at SSZ layer, not state transition function - 00:00:43
- ·Proposed fix: SSZ libraries should accept optional limits natively so clients don't hard-code them manually - 00:10:47
- ·Potuz: hard-coded limits in unmarshalling risk consensus bug if limits change in spec but not in client code - 00:13:02
- ·Gloas beacon block legacy deposit field currently has no soft limit applied; needs zero-limit added - 00:15:23
Action Items
- •Justin Traglia - Discuss optional SSZ limits in progressive list library with Eitan and spec team - 00:25:32
- •Enrico Del Fante - Open PR to add zero-limit for legacy deposit field in Gloas beacon block - 00:26:00
- •Potuz - Open PR to clarify fork choice equivocation counting (invalid equivocations should count) - 00:31:40
Key decisions
Clients should count invalid equivocations in fork choice; Prysm behavior is correct reference
Consensus updated to count invalid equivocations in fork choice as per spec changeMPlex deprecation proceeds; target before Gloas mainnet, no team blocking in principle
Deprecate MPlex before Gloas mainnet upgrade; no blockers
AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.