Context
Each block can include at most `MAX_ATTESTATIONS_DATA = 16` distinct `AttestationData` entries. When the store has more than 16 pending attestation data items, the block builder must select a subset using greedy selection (maximizing validator coverage).
This limit exists to bound block size and processing time. Client teams must enforce it.
No spec test filler currently tests the MAX_ATTESTATIONS_DATA boundary.
What to test
Write a fork choice filler that:
- Uses enough validators (e.g., 20+) to create many distinct attestation data entries
- Gossips attestations with more than 16 different `AttestationData` (different target slots, different target roots via forks, etc.)
- Produces a block
- Verifies the block contains exactly 16 `AttestationData` entries (not more)
Key assertions
- `StoreChecks(block_attestation_count=16)` — exactly at the limit
- No error from the block builder
- The 16 selected entries should maximize validator coverage (greedy selection)
Where to add the test
Add to: `tests/consensus/devnet/fc/test_block_production.py`
Code skeleton
def test_produce_block_enforces_max_attestations_data_limit(
fork_choice_test: ForkChoiceTestFiller,
) -> None:
"""Block production caps attestation data entries at MAX_ATTESTATIONS_DATA (16)."""
# Strategy: create a chain with many forks to generate >16 distinct
# AttestationData entries (each targeting a different root/slot combo).
#
# With 20 validators and multiple forks, we can create many distinct
# target (slot, root) pairs. Then verify the block only includes 16.
#
# TODO: design the fork/attestation topology to exceed 16 distinct entries
pass
Note: Creating 16+ distinct `AttestationData` entries requires careful fork topology. Each unique (source, target, head) triple is a distinct entry. Multiple forks at different slots is the simplest approach.
How to run
uv run fill --fork=devnet --clean -n auto -k test_produce_block_enforces_max
References
- `MAX_ATTESTATIONS_DATA = 16`: `src/lean_spec/subspecs/chain/config.py`
- `State.build_block`: `src/lean_spec/subspecs/containers/state/state.py` — enforces the limit
- `select_greedily`: `src/lean_spec/subspecs/xmss/aggregation.py` — greedy selection algorithm
Context
Each block can include at most `MAX_ATTESTATIONS_DATA = 16` distinct `AttestationData` entries. When the store has more than 16 pending attestation data items, the block builder must select a subset using greedy selection (maximizing validator coverage).
This limit exists to bound block size and processing time. Client teams must enforce it.
No spec test filler currently tests the MAX_ATTESTATIONS_DATA boundary.
What to test
Write a fork choice filler that:
Key assertions
Where to add the test
Add to: `tests/consensus/devnet/fc/test_block_production.py`
Code skeleton
How to run
References