architecture: align aggregation with leanSpec store.tick_interval atomic boundary
- Dominant language
- Zig
- Stars
- 97
- Forks
- 39
- PR merge metrics
- No merged PRs in 30d
Description
## Context
leanSpec (`src/lean_spec/__main__.py:store.tick_interval`) treats the chain-clock tick + per-slot store updates + aggregation as a single atomic operation: either the whole tick advances or none of it does. zeam #848 (closes #837) decouples them deliberately so a validator/aggregator failure cannot wedge the chain clock, but that decoupling means **aggregation in zeam runs OUTSIDE the chain.onInterval atomic boundary**: post-#848 we commit the cursor before any sub-step, then run `chain.onInterval` (clock tick) then `validator.onInterval` then aggregation, each independently log-and-continue.
## What this means in practice
- An aggregation failure no longer rolls back the chain-clock tick (good — that was the wedge fix).
- But it also means an aggregation produced against a *partially* updated store can't be detected as inconsistent: aggregation reads the post-tick view of the chain, and if the tick succeeded but produces a degenerate aggregation, we publish it and the rest of the network catches the inconsistency (or doesn't — depends on what guards `aggregate()` has).
- leanSpec D2 deviation flagged in the #848 review: zeam's tick+aggregation are not atomic.
## Question
Is this the right design for zeam, or should we re-couple aggregation+tick under a try/rollback such that an aggregation failure rolls back the post-tick view? Three sub-questions:
1. Is the leanSpec atomic boundary load-bearing for the consensus-correctness argument, or is it a Python-implementation convenience?
2. If load-bearing: does zeam need a different mechanism (a per-slot "checkpoint" the aggregator can rewind to without rolling back the chain clock)?
3. If NOT load-bearing: document the deviation in the spec-deviations file with a one-line rationale (`#848 wedge fix > leanSpec atomicity, idempotency-safe`) and close.
## Path forward
- [ ] Read leanSpec rationale comment block on `store.tick_interval`
- [ ] Survey other lean clients (lighthouse, prysm, …) for how they handle this boundary
- [ ] Decision: align (rework #848), document deviation, or drop entirely if not consensus-relevant
- [ ] Update spec-deviations docs with the chosen path
## Refs
- Spawned from #848 review (https://github.com/blockblaz/zeam/pull/848#issuecomment-4401538140 leanSpec deviation D2)
- Refs #837, #848
Contributor guide
No contributing guide indexed for this repository
Research direction
Read the leanSpec rationale at src/lean_spec/__main__.py:store.tick_interval, then inspect the changes and discussion in #848 and #837. Compare the boundary with other lean clients as requested. Done means choosing whether to rework the atomic boundary or document the deviation in the spec-deviations documentation with its rationale.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, zig
- Domain
- blockchain, distributed-systems
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100