add draft plan for devnet-3 #56

unnawut · 2026-01-09T07:30:06Z

No description provided.

unnawut · 2026-01-09T08:23:59Z

One thing I havn't added is the timing for publishing the aggregation.

The Four-Interval System
-------------------------
Each slot is divided into 4 intervals:

**Interval 0 (Block Proposal)**:
    - Block proposer publishes their block
    - If proposal exists, immediately accept new attestations
    - This ensures validators see the block before attesting

**Interval 1 (Validator Attesting)**:
    - Validators create and gossip attestations
    - No store action (waiting for attestations to arrive)

**Interval 2 (Safe Target Update)**:
    - Compute safe target with 2/3+ majority
    - Provides validators with a stable attestation target

**Interval 3 (Attestation Acceptance)**:
    - Accept accumulated attestations (new → known)
    - Update head based on new attestation weights
    - Prepare for next slot

jihoonsong · 2026-01-09T08:50:06Z

breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

+        - Aggregators propagate their aggregated signatures to `aggregated_attestation` gossipsub topic
+    - **Proposer role:**
+        - Proposer listens to `aggregated_attestation` gossipsub topic
+        - Proposer MAY listen to `attestation_{subnet_id}` topics and aggregate gossiped signatures if the received aggregated signatures don't cover all desired votes


aggregate gossiped signatures if the received aggregated signatures don't cover all desired votes

Could you elaborate this? Does it imply that proposer will always be an aggregator, i.e., is_aggregator(proposer) == true?

My understanding is that if the proposer sees some attestations that are not yet part of the aggregated signature(s) that it received, the proposer could choose to aggregate those new attestations itself and include it as another aggregation in the block that it's about to propose.

This part of text was from @g11tech's chat message so feel free to correct me

Ah, makes sense. Maybe we can express it something like a proposer MAY include any attestation to a block that is not aggregated (and not equivocating). I guess the equivocation handling is not part of devnet-3's concern though.

Updated in c9fcad8

breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

kamilsa · 2026-01-09T09:51:57Z

@unnawut my vision regarding timing of aggregation

Interval 1:
- Aggregators collect attestations during interval 1
- Aggregators propagate valid attestation to attestations topic corresponding to the committee of aggregator
Interval 2:
- Once >90% (should be configurable) of attestations from the committee is collected -> compute an aggregation. Otherwise wait for 90% of attestations
Interval 3:
- If >90% of attestations was not collected and no other aggregation proving >90% of attestations from the same committee was observed, create an aggregation from existing attestations
Any interval:
- Once aggregation is ready, propagate to aggregation topic

Co-authored-by: JihoonSong <jihoonsong@users.noreply.github.com>

jihoonsong · 2026-01-09T10:02:14Z

breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

+
+## Notable exclusions
+
+- Multiple aggregation subnets & committees - planned for the next devnet to derisk complexity


Suggested change

- Multiple aggregation subnets & committees - planned for the next devnet to derisk complexity

- Multiple aggregation subnets - planned for the next devnet to derisk complexity

I intentionally added this 😅 based on this chat, but I might have misunderstood @kamilsa @g11tech

Devnet 4: Single subnet with multiple aggregation committees with recursive aggregation:
* We keep single subnet for attestation propagation but we split validators into multiple aggregation committees, so that they send attestation directly to aggregator from their committee
* Aggregators assign themselves to one or multiple aggregation committees (via ENR record)

Thanks for sharing the chat. Does validator sends attestation directly to the aggregator of their designated committee AND propagates attestation to the attestation subnet?

Thanks for sharing the chat. Does validator sends attestation directly to the aggregator of their designated committee AND propagates attestation to the attestation subnet?

I think that's what @kamilsa suggested yeah. But hmm I think I havn't incorporated "attestation directly to the aggregator" yet because I'm not sure what the channel should be

It reads as there are the attestation global gossipsub topic and attestation subnets to me. Maybe the subnets are introduced for optimization, but then I'm not sure why we need the attestation topic then.

I've also found "aggregation committee" misleading as it consists of both aggregators and non-aggregators. I get that it produces aggregated signatures as a whole, but we call it a "committee" when all committee members have the same role.

As I see how we can do it:

We keep single global subnet for all attestations.

However attesters are now split into multiple committees.
We also introduce attestation_{subnet_id} subnets that are used as follows:

Non-aggregating attesters only publish (without subscribing) to the attestation subnet corresponding to their committee

Aggregators (subset of attesters from the committee) do both publishing and subscribing in the attestation subnet

That way we save traffic for attesters so that they do not receive same attestation twice (from global attestation subnet and from subnet that corresponds to committee).
(in reality though they will receive same attestation more than once due to lack of proper duplicates handling in gossipsub)

Here is how I understand:

Attestation subnets
An attester should be able to calculate which subnet they are belong to and publish their attestation to that subnet. We can maybe call a group of attesters in the same subnet an attestation committee, i.e., attestation_committee[i] has attestation_subnet[i].

A global gossip topic for aggregated signatures
Aggregators of each subnet publish their aggregated signatures to this global gossip topic.

Am I on the same page?

Am I on the same page?

I think so.

We can maybe call a group of attesters in the same subnet an attestation committee, i.e., attestation_committee[i] has attestation_subnet[i].

Yes, should be fine and sounds similar to beacon spec

Yes, it is very similar to beacon chain although it is grouped by different reasons. Great, thanks a lot!

unnawut · 2026-01-09T10:31:55Z

@unnawut my vision regarding timing of aggregation

Interval 1:

Aggregators collect attestations during interval 1

Aggregators propagate valid attestation to attestations topic corresponding to the committee of aggregator

Interval 2:

Once >90% (should be configurable) of attestations from the committee is collected -> compute an aggregation. Otherwise wait for 90% of attestations

Interval 3:

If >90% of attestations was not collected and no other aggregation proving >90% of attestations from the same committee was observed, create an aggregation from existing attestations

Any interval:

Once aggregation is ready, propagate to aggregation topic

Added your suggestion to the doc. Not sure if I understood it correctly but let me know otherwise. I'll have a closer look at this later as well.

will-corcoran · 2026-01-09T13:05:28Z

breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

+- **Changes**
+    - **validator-config.yaml:**
+        - New field: `validator.attestation_subnet_id` - The subnet that the validator propagates the attestation to, assigned to all validators
+        - New field: `validator.aggregator_subnet_id` - The subnet that the validator will perform aggregator duty, assigned to a small subset of validators


should we specify a target of ~10% of subnet validators to have a measurable goal?

We want to start with just 1 aggregator in this devnet hence why I didn't put 10% even in the north star target, but could you correct me if I'm wrong @kamilsa

tcoratger

Cool, just left a very minor comment, otherwise, looks good to me.

As soon as this is merged, I can decouple this into small issues for leanspec, for people to start working on it.

breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

jihoonsong · 2026-01-09T16:08:12Z

breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

+- **Changes**
+    - **validator-config.yaml:**
+        - New field: `validator.attestation_subnet_id` - The subnet that the validator propagates the attestation to, assigned to all validators
+        - New field: `validator.aggregator_subnet_id` - The subnet that the validator will perform aggregator duty, assigned to a small subset of validators


If a validator performs an aggregator role, validator.aggregator_subnet_id equals to validator.attestation_subnet_id anyway. In other words, the information we need is whether a validator is an aggregator or not. So I think using a flag is better such as validator.is_aggregator.

Maybe we can add attestation_subnet_id field as proposed + optionally add is_aggregator: bool as ENR record.

Why ENR? because this information is something that the nodes will need to be aware of during peer discovery (when discovery is integrated). This gives flexibility for building topologies that optimize aggregation

Do we want to make a config so that non-aggregators directly connect to aggregators in their subnet, if possible?

Updated in 96669d8

I think non-aggregators from subnet with some subnet_id may simply publish their attestation to the gossipsub topic attestation_{subnet_id} (without subscribing). I believe no additional config required. At least for now

…subnet

unnawut · 2026-01-12T07:17:39Z

I’ll merge now but feel free to continue the conversations. I’ll be more than happy to follow up with new PRs

add draft plan for devnet-3

06ae944

unnawut force-pushed the devnet-3 branch from 5b44c2a to 06ae944 Compare January 9, 2026 08:12

jihoonsong reviewed Jan 9, 2026

View reviewed changes

unnawut and others added 3 commits January 9, 2026 16:52

Update breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

4b080c5

Co-authored-by: JihoonSong <jihoonsong@users.noreply.github.com>

Update breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md

4c485b6

Co-authored-by: JihoonSong <jihoonsong@users.noreply.github.com>

fix: rename aggregation committee to subnets

a574ee8

jihoonsong reviewed Jan 9, 2026

View reviewed changes

feat: add intervals table

8e5b0a2

will-corcoran reviewed Jan 9, 2026

View reviewed changes

tcoratger reviewed Jan 9, 2026

View reviewed changes

breakout-rooms/leanConsensus/pq-interop/pq-devnet-3.md Outdated Show resolved Hide resolved

jihoonsong reviewed Jan 9, 2026

View reviewed changes

unnawut added 4 commits January 12, 2026 12:26

fix: explicitly mention no recursive aggregation

28f9aa7

fix: Jihoon and Kamil's convo on aggregator config

96669d8

fix: cleaner statement for proposer's own aggregation

c9fcad8

fix: clarity that attesters do not need to listen to its attestation …

58fd023

…subnet

unnawut merged commit 1502314 into leanEthereum:main Jan 12, 2026

unnawut deleted the devnet-3 branch January 12, 2026 07:17

kamilsa mentioned this pull request Jan 14, 2026

[WIP] Committee aggregation leanEthereum/leanSpec#282

Draft

6 tasks

will-corcoran mentioned this pull request Jan 19, 2026

PQ Interop #23 | Jan 21, 2026 ethereum/pm#1880

Open


		## Notable exclusions

		- Multiple aggregation subnets & committees - planned for the next devnet to derisk complexity

	- Multiple aggregation subnets & committees - planned for the next devnet to derisk complexity
	- Multiple aggregation subnets - planned for the next devnet to derisk complexity

add draft plan for devnet-3 #56

add draft plan for devnet-3 #56

Uh oh!

Conversation

unnawut commented Jan 9, 2026

Uh oh!

unnawut commented Jan 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

kamilsa commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jihoonsong Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kamilsa Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jihoonsong Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

unnawut commented Jan 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcoratger left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

unnawut commented Jan 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

kamilsa commented Jan 9, 2026 •

edited

Loading

jihoonsong Jan 9, 2026 •

edited

Loading

kamilsa Jan 9, 2026 •

edited

Loading

jihoonsong Jan 9, 2026 •

edited

Loading