Networking designOpen sessions IV & V
Fast Finality Workshop · Cambridge · Wednesday 14 October · 17:00
Questions from the board, each with a proposal to push on. By Thursday every item is settled, or open with an owner.
From the board
Networking questions on the board
Board snapshot 14 Oct · notes.ethereum.org/yNWbJIsoROGSdT3Nq04Tpw · “parked” = parking lot · definitions on slides – and before each question · each proposal slide is followed by its talking points
Before the questions · definitions
Decoupled consensus, in this session’s words
Every question here is about one layer of DC: how the finality gadget’s votes travel.
- Decoupled consensus (DC)
- A small sampled committee runs the chain every slot; the full validator set runs finality in parallel, off the critical path.
- Available chain
- The per-slot chain and its fast confirmations. The current DC candidate for it is Goldilocks: Goldfish with locks.
- Finality gadget (FG)
- Counts the votes that blocks include, and with them justifies, then finalizes, heights. Every validator votes in it once per round.
- Round
- The time in which every validator casts one FG vote: 8 slots (96 s) in the requirements, 4 slots as a stretch goal. Board #3 proposes a 92 s round instead (slide ).
- Height
- What the FG votes on. A vote at height h names the block that brought the chain into h. Once a block counts 2/3 of stake for it, h is justified and votes move to h + 1; a second 2/3, carried by later votes, finalizes it.
- Unit
- One cohort’s vote phase followed by its aggregation phase, 4 s + 4 s: the shape of today’s attestation pipeline. A new unit starts every 4 s, so an 8-slot round holds 23.
- Cohort
- The validators that vote in one unit: 1/23 of the set, ≈ 48k of 1.1M validators.
- Committee
- A group whose votes are aggregated together. On slide and in Q18: one cohort’s share of one subnet (747 by default, 537 today). On slides – and in Q19: the whole cohort.
- Consolidation
- Validators merging their stake into fewer, larger ones (up to 2,048 ETH each, EIP-7251): fewer votes per round, smaller committees.
Q17, Q18, Q19: the dc-networking research notes on pipelined units, staggered committees and the free-running clock (drafts). Devnet-1: the 500-node DC devnet of 8 Oct (12 s slots, 8-slot rounds). Shadow: a network simulator that runs real client binaries. Sources: ethresear.ch “Unblocking faster finality with decoupled consensus”; Goldilocks spec §2–3; dc-networking design/requirements.md, Q17 (the unit), Q19 §1.
Before the questions · definitions
How a vote travels today
Mainnet’s attestation pipeline, which the FG proposals keep: one 8 s unit inside each 12 s slot.
- Subnet
- One of 64 gossip topics for single votes. A committee’s votes stay on its subnet, and each node follows only a few subnets.
- Committee, today
- The validators that vote in one slot on one subnet: each epoch’s validator set split 32 × 64 ways, ≈ 537 at 1.1M validators.
- Aggregator
- A committee member that collects the committee’s votes and merges them. About 16 per committee select themselves by a lottery on their signature.
- Aggregate
- One signature standing for many votes on the same data, plus a bitfield that says whose votes it holds.
- Aggregation bitfield
- One bit per committee member, in committee order: ⌈c/8⌉ bytes for c members. Board #2 asks which state fixes that order.
- Global topic
- The topic every node follows: all aggregates, ≈ 64 × 16 = 1,024 per slot today. In the FG designs here it is the largest per-node cost.
Validators attest when the block arrives or at 4 s, whichever is first (ATTESTATION_DUE_BPS = 3333); aggregators publish at 8 s (AGGREGATE_DUE_BPS = 6667); a block includes attestations from one slot later on. Aggregators: hash of the slot signature mod ⌊c/16⌋ = 0 (TARGET_AGGREGATORS_PER_COMMITTEE = 16). Sources: consensus-specs phase0 validator.md and p2p-interface.md (ATTESTATION_SUBNET_COUNT = 64), electra beacon-chain.md (Attestation); Q17 (the unit); Q18 analysis/network.md.
Board #5 · definitions
Two ways to split a slot’s votes, and the unit
Every validator votes once per round. Board #5 asks how to spread those votes over time.
- A · Staggered publishing (“spread”)
- One committee per subnet and slot. Its voters publish in seven 1 s groups (0 … 6 s), and a single aggregation runs at 9 s.
- B · Multiple committees (X = 3)
- Three committees per subnet and slot, voting at 0, 3 and 6 s and aggregating at 3, 6 and 9 s: smaller groups, each with its own cut.
- Pipelined units
- The proposal: B on a fixed grid. A new unit starts every Δ seconds, so one cohort votes while the one before it aggregates.
- Δ, a, d
- Δ: the time between unit starts. a: the vote phase, after which aggregation starts. d: the aggregation phase. All 4 s by default. Not Goldilocks’ Δ, its network delay bound.
- Units per round
- ⌊(R − a − d)/Δ⌋ + 1 for a round of R seconds: the units that start and finish inside it. 23 for 8 × 12 s, 11 for 4 slots.
- Committee, per subnet
- One subnet’s share of a unit: V ÷ units ÷ 64. 747 at 1.1M validators and the defaults, against 537 today.
- Bundled votes
- Votes on the same data sent together, sharing one copy of it (EIP-8334, proposed): ≈ 140 B per vote in bundles of four, against ≈ 240 B alone.
- PQ proof per subnet
- The time to prove one subnet committee’s post-quantum signatures, scaled from EIP-8292 (1,000 in 3.7 s on 8 cores). It fits if it ends 1 s before the aggregation phase does.
- p95 / p99, two clocks
- Publication → arrival: the delay from when a vote is sent. Slot start → arrival also counts spread’s deliberate 0–6 s wait, so spreading can lower the first and raise the second.
Spread and X = 3 as run on devnet-1 (12 s slots). Units per round and committee sizes: the model of slide . A bundle of k votes is (136 + 104k) B. EIP-8292 (Draft): 1,000 signatures in 11.0, 3.7 and 2.6 s on 2, 8 and 16 cores; proofs of ≈ 185–230 KiB. Sources: dc-networking benchmarking/devnet-1/SOURCE_MODEL.md; Q17 (pipelined-units); EIP-8292.
Board #5 · (sub-)round design
Staggered publishing, or multiple committees?
A · Staggered publishing (“spread”)
One committee per subnet and slot, publishing in 1 s groups; one aggregation at 9 s.
B · Multiple committees (X = 3)
Three committees per subnet and slot: votes at 0, 3, 6 s; aggregates at 3, 6, 9 s.
ProposalMultiple committees, pipelined: every Δ s a new committee votes for a s, then aggregates for d s.
Committee (per subnet)
747
Load per subnet
Global topic · aggregates from all 64 subnets
1.03 MB per slot · 7.87 MB per round
PQ proof per subnet
≈ 2.8 s
Board #5 · talking points
What pipelined units buy, and what they cost
✓a · Fairness
Every voter keeps today’s 4 s budget, wherever it sits on the globe. Offsets still differ (a +0 s unit votes before its block lands), so fairness comes from rotation (slide ).
✓b · Free of slot time
Units keep their Δ-second clock at any slot length: try the slot control on slide . Only the round and the block that includes each aggregate move.
?c · Incentives
A unit is today’s attestation slot (vote, aggregate, include) with enforceable windows. Staggered publishing’s single cut lets early groups wait. Rewards are not specified yet.
?d · Post-quantum
Proving 1,000 hash-based signatures takes 2.6–11 s (EIP-8292), so smaller committees fit their window. Every committee’s proof still has to be merged.
−Costs
More aggregates, already the dominant cost: 3,072 per slot (1.03 MB on the global topic) at Δ = 4 against 1,024 (315 kB) today. A vote phase and an aggregation phase always overlap the block.
→To decide
Δ: smaller units shrink committees and proofs, but multiply aggregates. Is there a reason to go below 4 s?
Measured so far Shadow, 100 nodes, 40k validators, one committee: spreading cut the p99 from publication to arrival from 8.6 to 5.3 s and disconnects from 32 to 2, but raised the p95 from slot start from 3.9 to 6.0 s.
Not yet a clean A versus B. Devnet-1’s X = 3 run also changed validators, subnets and nodes; a 500-node comparison (flooding, spread, multiple committees) is planned.
Slide model: committee c = V ÷ units ÷ 64 subnets; units per round = ⌊(R − a − d)/Δ⌋ + 1, R = 8 (or 4) slots; V = 1.1M ÷ consolidation; mainnet today 1.1M/32/64 ≈ 537. Bytes per subnet and unit: c × 140 B bundled votes + min(16, c) aggregates × (⌈c/8⌉ + 240 B); per second ÷ Δ. Global topic: 64 × min(16, c) aggregates of (⌈c/8⌉ + 240 B) per unit, × slot/Δ units per slot or × units per round; today ≈ 315 kB per slot in the same model. PQ: EIP-8292, 3.7 s per 1,000 signatures on 8 cores, scaled linearly; fits if done 1 s before the window closes. Sources: dc-networking research/fg/pipelined-units (Q17); benchmarking/devnet-1 SOURCE_MODEL and FINDINGS; sims/n100-v40000-s2-56k-8slots-spread.
Add-on · definitions
Push, pull, and votes that miss the cut
A vote that reaches its aggregators too late misses its unit’s aggregate. The add-on asks who sweeps it up before the next block.
- Mesh, eager push
- GossipSub keeps ≈ 8 mesh peers per topic and forwards every new message to all of them at once: fast, at the cost of duplicates.
- IHAVE / IWANT, lazy pull
- On every heartbeat (0.7 s), a node tells a few non-mesh peers the IDs of the messages it holds (IHAVE); a peer missing one asks for it (IWANT).
- Late votes
- Votes that reach the aggregators after the aggregation cut. Without a second chance they are in no aggregate, so no block counts them (Q17, problem 2).
- Superset
- An aggregate whose bits strictly contain those of an earlier one for the same data. Gossip drops an aggregate that adds no new bit.
- The sweep
- Once per slot, at +8 s: one 2 s IHAVE/IWANT round for the three units the next block carries. At +10 s a few late aggregators publish the best superset, which reaches the proposer by +12 s.
- Coverage digest
- This deck’s IHAVE for the sweep: per committee, a ⌈c/8⌉-byte bitfield of the votes a node holds, instead of one 20-byte ID per message.
- Partial messages
- A GossipSub extension that exchanges the parts of a message with have/want bitmaps; Fulu uses it for data-column cells.
- Vote window
- How long after its unit starts a vote is still accepted: until +8.5 s in Q18. The sweep needs ≈ +10.5 s, so four units’ windows overlap.
- Withholding
- Advertising a message in IHAVE and not sending it. GossipSub penalises an unanswered IWANT after 3 s, once the sweep’s window has closed.
GossipSub parameters: consensus-specs phase0 p2p-interface.md (D = 8, heartbeat 0.7 s); go-libp2p-pubsub (IWANT follow-up 3 s). Coverage digests are this deck’s term. Sources: Q19 §1 (the sweep, vote windows); Q17, problem 2; Q18 (vote windows); consensus-specs fulu p2p-interface.md (partial messages).
Add-on · aggregation
Who sweeps up the late votes before the next block?
ProposalPush only inside units. Once per slot, 4 s before it ends: one IHAVE/IWANT round, then a global aggregation.
Coverage digests · per peer
18 kB
Supersets · global topic
+64 kB
Pulled aggregates · per node
≤ 64 kB
Add-on · talking points
What the sweep buys, and what to check
What it buys
- Late votes get one more chance at the next block (Q17, problem 2).
- No IHAVE gossip while a phase runs: one pull round per slot, on a fixed grid.
- Pull instead of flood: ≈ 13.5 → 0.5 Mbit/s per node at 1.1M validators (agent model; ≈ 40 % if dedup already leaves one aggregate per committee).
What to check
- Stock IHAVE carries message IDs on the heartbeat, not coverage: the sweep needs coverage digests, close to partial messages.
- Withholding: GossipSub punishes a broken IHAVE promise only after 3 s, once the window has closed.
- Who aggregates globally: the proposer, a few selected aggregators, or every node?
- Do swept late votes earn full credit? Votes then stay valid to ≈ +10.5 s, so four vote windows are open at once.
Block s+1 carries the units whose on-time aggregates land during slot s: slot ÷ Δ of them (three at 12 s slots and 4 s units). Bandwidth: agent model estimate at Δ = 4, against worst-case eager flooding of unit aggregates. Extra load on slide : digests carry a ⌈c/8⌉-byte bitfield per committee instead of 20-byte message IDs (consensus-specs altair p2p-interface); supersets and pulls are (⌈c/8⌉ + 240 B) per committee. GossipSub IWANT follow-up: 3 s (go-libp2p-pubsub). Sources: dc-networking research/fg/free-running-committees §1 (Q19), pipelined-units problem 2 (Q17), staggered-committees/analysis/network.md.
Board #3 · definitions
Clocks, passes and heights
Board #3 asks whether a height can be justified, and voting move on, in the middle of a round.
- Slot-aligned round
- The DC draft’s round: it starts on a slot boundary and offers 8 × 3 unit starts. The last unit would end after the round, so it stays idle: 23 units.
- Free-running clock
- Units are numbered from genesis, u = ⌊t / 4 s⌋, and committee u mod 23 votes in unit u, at any slot length.
- Committee, on this board
- The whole group that votes in one unit, i.e. a cohort. On the wire it splits into 64 subnet committees.
- Pass
- 23 consecutive units, 92 s, in which everyone votes exactly once: the proposal’s round, “eight slots minus one committee”, no longer tied to slots.
- In-slot start
- Where in its slot a committee’s unit starts: +0, +4 or +8 s at 12 s slots. On the free-running clock each committee steps +0 → +8 → +4 s, one step per pass.
- Rotation
- Changing committees’ positions over time, so that no one keeps a bad one for good. Francesco’s (index + round) mod C does it on slot-aligned rounds; the free-running clock rotates by itself.
- Landing
- A unit lands 8 s after it starts, when its aggregates have spread. The block after a slot includes the units that landed during it.
- Height switch
- Voters move to the next height as soon as they see the block that justified the current one, mid-round if need be.
- Sticky voters
- Voters who keep their round’s first target until the round ends, for reward fairness. They tie heights to rounds: 224 s from block to finality instead of 174 s.
Sources: Q17 (the round, the idle unit); Q19 §2, §3, §5 (Francesco’s formula, the free-running clock, sticky voters); Q18 (the height switch, Mikhail’s).
Board #3 · heights
Can we advance heights during a round?
Proposal23 committees on their own 4 s clock (a 92 s pass); slots move independently, each holding 3 committees.
Board #3 · talking points
Rotation for fairness, heights free of rounds
Rotation → fairness
Committees and slots drift against each other (a 92 s pass is no multiple of the slot), so each committee cycles through every in-slot start: +0, +8, +4 s at 12 s slots. In-slot effects even out in ≈ 13 min instead of never.
Rotation: Francesco · (index + round) mod CHeights advance mid-round
A pass is 23 units (92 s), and the round becomes bookkeeping. A height closes once 2/3 has landed on chain. Expected block → finality: 174 s, against 224 s if voters stick to the round (+111 s at 80 % participation, +220 s at 70 %).
Height switch: MikhailCommittees per slot, and reward variance
A pass stays 23 committees at any slot length; a slot holds L/4 of them. At 12 s and 8 s every block carries 3 or 2. At 10 s and 6 s blocks alternate 2/3 and 1/2, so proposer rewards vary ±20 % and ±33 % per block, same mean. At 12 s, eight slots hold 24 units, one more than a pass.
Cost
+4.3 % FG traffic against Q17’s idle unit (12 s slots). Rounds straddle epochs (23 %) and blocks (9 %), which only affects accounting.
Committee = unit mod 23, so every validator votes every 92 s at any slot length. A unit lands 8 s after it starts; the block after slot s carries the units that land during it. On slot-aligned rounds Francesco’s formula rotates the other way and leaves a double vote 8 s apart; the free-running clock gives the same rotation with a constant gap. Latencies: expected values from the Q19 simulation, full participation unless noted. Source: dc-networking research/fg/free-running-committees §2, §3, §5 (Q19).
Add-on · definitions
Seats, eras and operators
Units fix when a committee votes. This question is about who sits in which committee.
- Position, or seat
- Who votes when: which unit a validator’s committee uses. Public and deterministic in the proposal, so anyone can compute it.
- Composition
- Who votes together: which validators share a committee and a subnet. Committees exist for load and timing, not for security.
- VRF, secret duties
- The private alternative: each validator proves its own duty in every vote. That costs a proof per vote (+96 B on a 200 B vote) and one more BLS check.
- Era and its seed
- 256 epochs ≈ 27 h, after which composition is re-drawn. The seed is the RANDAO mix of the epoch 5 before the era starts, known ≈ 4 epochs ahead.
- Contiguous, striped, era hash
- Three compositions: runs of consecutive indices (the DC draft), index mod 23 (fixed forever), or a hash of the era seed and the index (re-drawn every era).
- Operator, single-operator committee
- An operator runs many validators, and its deposits give it runs of consecutive indices. A committee it holds alone maps, through its aggregate, to the operator’s node.
- Deanonymisation
- Linking a validator to the node that runs it. Today it takes many epochs of subnet fingerprinting; a single-operator committee gives it away at one look.
- ε-fair
- A seat schedule is ε-fair once every validator’s seat-induced deviation in vote success stays within ε = 0.1 pp. Q18’s rotation gets there in 5.8 h.
- Pick your seat
- Validators choose their seat themselves, within a stake cap and a count cap per seat: the alternative to the era hash.
Sources: Q18 README §1–2, analysis/schedule.md (ε-fair), analysis/network.md (VRF cost, single-operator committees); Q19 §4 (pick your seat); Heimbach et al., USENIX Security ’25 (subnet fingerprinting).
Add-on · committee selection
How should we select committees?
ProposalPublic, deterministic seats for when you vote; an era-hashed composition, re-drawn every ≈ 27 h, for who you vote with.
Single-operator committees
1
Units carrying X’s votes
3 of 23
X’s largest committee share
100 %
Add-on · talking points
Committee selection, and what it does for anonymity
Position: who votes when
Public and deterministic: no VRF proof per vote (+96 B on a 200 B vote, and one more BLS check). Seats rotate forward, ε-fair after 5.8 h; on the free-running clock they rotate by themselves (board 3).
Composition: who votes together
Re-drawn once per era (256 epochs ≈ 27 h) from a RANDAO seed and the validator index. A fixed composition can be captured: aimed consolidations give a 10 % adversary a third of a cohort in 4–8 days.
+Anonymity
No single-operator committees, so no aggregate maps a whole committee to one node. An operator’s validators vote in nearly every unit, so no 4 s window singles out its node (or invites a DoS), and the map moves every era.
−Today’s draft
Contiguous index blocks: 6.5 % of committees single-operator, the largest operator at 18.4 % of a unit (9.4 % overall). An honest minority with share h in a mixed committee loses every aggregator with ≈ e−16h: 45 % at 5 %.
?Pick your seat
Capped choice (stake and count caps) is fine for load and liveness, but over months seats drift towards single operators, which gives the anonymity back. Keep the era hash as the default.
→To settle
The era is tied to the 256-epoch withdrawability delay with zero slack; the seed epoch; subnets within a committee; whether phase 1 stays explicitly non-private.
Slide is a toy model: 552 validators, X’s two deposit batches are runs of consecutive indices. The numbers here are Q18’s simulation at 10⁶ validators. One-look deanonymisation: a committee whose votes never appear on its subnet, but whose full aggregate comes first from one peer, maps to that node at once; subnet fingerprinting today needs many epochs (Heimbach et al., USENIX Security ’25). Sources: dc-networking research/fg/staggered-committees README §1, §4 and analysis/network.md §4, §7 (Q18); free-running-committees §4 (Q19); design/requirements.md, Privacy.
Board #2 · definitions
Layouts, anchors and who counts
An aggregate names its voters by bits. Every node has to read those bits the same way, on every branch.
- Bit layout
- Which validator each bit of an aggregation bitfield stands for. Under two different layouts, the same aggregate names different voters.
- Anchor
- The state the layout is read from: the latest finalized state, or one at least 1 hour or 1 day back.
- Voting state
- The state that processes the vote. It decides whether a set bit counts, and with what weight; the anchor only says whose bit it is.
- Activation
- A deposit becomes an active validator only once its eligibility epoch is finalized, and 5 epochs after that (churn permitting). Without finality, nobody joins.
- Exits, slashings, ejections
- The ways a validator leaves; none of them waits for finality. Masking keeps a leaver’s bit in the layout and stops counting it.
- 2/3 denominator
- The total that “2/3” is measured against: today the total active balance.
- Inactivity leak
- When finality lags by more than 4 epochs, validators that don’t vote lose stake until finality returns.
- Withdrawability delay
- 256 epochs ≈ 27 h from a validator’s exit to its withdrawal. Until then it can still be slashed.
- Weak-subjectivity period
- How old a checkpoint a syncing node may safely start from: ≈ 15.7 days at today’s stake, so a 1-day anchor stays well inside it.
Sources: consensus-specs phase0 beacon-chain.md (is_eligible_for_activation, compute_activation_exit_epoch, inactivity penalties, MIN_VALIDATOR_WITHDRAWABILITY_DELAY), electra weak-subjectivity.md; Q18 analysis/anchor.md.
Board #2 · aggregation
How are aggregation bitfields determined?
ProposalRead the bit layout from a deep finalized state, 1 hour or 1 day back; weights stay with the voting state.
Board #2 · talking points
Why a deep anchor is cheap, and what to settle
Why it is cheap
- Every branch past the anchor gets the same layout: nothing to recompute on a reorg, and gossip checks any vote against one layout.
- No finality means no new activations: the eligibility epoch must be finalized. A frozen layout misses no one.
- The draft’s current rule churns: on a single chain the layout changes in 21 of 53 rounds (Q18 sim).
To settle
- Depth: F, F − 1, 1 hour, 1 day? Past ≈ 27 h exited keys are no longer slashable, so masking must be airtight.
- Exits, slashings and ejections don’t wait for finality: mask their bits with the voting state, don’t reject the aggregate.
- New validators wait up to the depth for a bit: keep them out of the 2/3 denominator and the leak until then.
Activation needs activation_eligibility_epoch ≤ finalized_checkpoint.epoch (consensus-specs phase0, is_eligible_for_activation); exits, slashings and ejections don’t. 27 h ≈ 256 epochs = MIN_VALIDATOR_WITHDRAWABILITY_DELAY; a day stays well inside the weak-subjectivity period. Churn: the DC draft lists the registry at the including state’s finalized slot. Source: dc-networking research/fg/staggered-committees/analysis/anchor.md (Q18), which recommends Active(epoch(round)).
Board #4 and parking lot · definitions
Finality targets, post-quantum votes, stake order
Three items the session opened without a prepared proposal.
- I*
- The fork after Glamsterdam and Hegotá on the strawmap (strawmap.org), which places decoupled consensus in it.
- Round cadence
- Today every validator votes once per epoch, 32 slots. 8-slot rounds (the requirement) are 4× that cadence; 4-slot rounds (a stretch goal) 8×.
- Finality in slots
- Today a block is final 64 slots later at best, two epochs. The DC devnet targets 16.
- Post-quantum (PQ) votes
- Hash-based signatures replace BLS. They don’t add up into one signature, so an aggregator proves a batch of them valid instead (EIP-8292).
- Fast and slow PQ modes
- The board’s question, not written up yet. Nearest open items: Q8, PQ aggregation under higher load, and Q9, a back-off that slows down instead of stalling.
- Ordering by stake
- Letting the committees with the most stake vote first, so that 2/3 of stake lands sooner. Load grows with messages, not ETH, so seats need a stake cap and a count cap.
Sources: strawmap.org; dc-networking design/requirements.md (rounds), the 10-06 call (devnet target), design/properties.md and research/open_questions.md (Q8, Q9); EIP-8292; Q18 analysis/schedule.md and Q19 §4 (stake order, caps).
Board #4 · finality target
Are we aiming for 4-slot finality in I*?
Proposal
To fill in during the session
Board #4 · starting points
Where 4-slot finality starts from
- The requirements ask for 8-slot rounds (4× today’s 32-slot cadence); 4-slot rounds are a stretch goal.
- The devnet targets finality in 16 slots, 4× today’s best case of 64 (10-06 call).
- Slide with a 4-slot round: 11 units, so committees of ≈ 1,560 per subnet at 1.1M validators (2.9× today’s 537). Parity needs ≥ 2.9× consolidation.
Parking lot · post-quantum
A fast and a slow mode for PQ propagation?
Proposal
To fill in during the session
Parking lot · starting points
Where PQ propagation starts from
- Follows this afternoon’s PQ networking session (14:45).
- EIP-8292: proving 1,000 hash-based signatures takes 2.6–11 s; slide shows what that means per subnet committee.
Parking lot · voting order
Order validators by stake to shorten voting rounds?
Proposal
To fill in during the session
Parking lot · starting points
Where ordering by stake starts from
- Follows the 15:45 talk on PQ validators: validator priority, consolidation.
- Slides –: a height closes once 2/3 of stake has landed, so heavy committees first would close it earlier.
- Load counts messages, not ETH: Q19’s seat rules need a stake cap and a count cap.
Wrap-up
Settled, or open with an owner
| # | Question | Decision or next step | Owner |
|---|---|---|---|
| #5 | Staggered publishing, or multiple committees? | ||
| add-on | Global aggregation before the slot ends? | ||
| #3 | Advance heights during a round? | ||
| add-on | Committee selection, and anonymity? | ||
| #2 | How are aggregation bitfields determined? | ||
| #4 | 4-slot finality in I*? | ||
| parked | Fast / slow mode for PQ propagation? | ||
| parked | Order validators by stake? |