blockblaz / blockblaz/zeam

architecture: align aggregation with leanSpec store.tick_interval atomic boundary

Open
#852 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.