fix(vara.eth): batch-commitment refactor; correct validators rotation in malachite

[grishasobol]

Finalizes the ethexe consensus batch-commitment refactor and fixes validator rotation across eras in the malachite layer. Compiles, clippy-clean, ethexe unit/integration tests pass.

1. Batch commitment

A batch is what validators agree on and submit to the Router. It bundles a few optional parts plus the chain progress:

flowchart TB
  B["BatchCommitment<br/>(block_hash, timestamp, expiry, previous_batch)"]
  B --> C["chain_commitment?"]
  B --> CO["code_commitments[]"]
  B --> V["validators_commitment?"]
  B --> R["rewards_commitment?"]
  C --> H["head MB"]
  C --> T["state transitions"]
  C --> E["last_advanced_eth_block"]

Loading

Normal (non-empty) chain commitments already worked. This PR fixes the edge cases where building the chain commitment could stall or loop:

• After a validator-set handover, a freshly joined validator may not have the compact block of the already-committed anchor MB. The walk now stops at the anchor's hash instead of dereferencing it.
• When the finalized chain doesn't descend from the committed anchor, the genesis zero-MB self-parent caused an infinite walk — it now stops at genesis.
• Empty checkpoint chain commitments are only emitted once the uncommitted gap passes a threshold, instead of riding along with other commitments.
• is_strict_descendant_eth_block — genesis-anchor equality fix.

2. Validator rotation across eras

Time is split into eras, and each era has its own on-chain validator set. A batch is verified against the set of the era its block falls into. A node must therefore hold the validator set for every era it touches, not just the current one.

flowchart LR
  subgraph "era N"
    VN["validators(N)"]
  end
  subgraph "era N+1"
    VN1["validators(N+1)"]
  end
  subgraph "era N+2"
    VN2["validators(N+2)"]
  end
  VN --> VN1 --> VN2

Loading

Fixed here:

• Malachite only allows the first block of a new era when advancing into it, so rotation happens at a clean boundary.
• On sync, the observer walks the freshly loaded chain and backfills the validator set for each era it spans (stops early once an era is already known), so a node that joined mid-chain can verify historical certificates.

3. MbMeta + DB migration (v1 → v2)

MbMeta gained a finalized flag and last_advanced_eb became optional:

v1:  { computed, last_advanced_eb: H256 }
v2:  { computed, finalized, last_advanced_eb: Option<H256> }

A v1 → v2 migration re-encodes every record: last_advanced_eb is wrapped in Some(..), and finalized is backfilled true for every MB reachable from the latest finalized MB.

Deliberately out of scope

Full cross-era membership — where a node that joined after several rotations can resolve and observe any historical era from a complete pubkey table (vote/propose only in elected eras, observe otherwise) — is a consensus feature, not a bug fix, and is left as a follow-up. The current resolver uses the node's own per-era set with a live-set fallback, which is enough because a node only runs consensus for eras it is elected to.

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request finalizes the consensus batch-commitment refactor, ensuring robust propagation of metadata and finalized status across the system. It introduces necessary database schema updates, fixes critical logic in batch commitment creation, and enhances validator set resolution to support historical era validation. These changes improve system reliability and prepare the codebase for future cross-era membership handling.

Highlights

• Data Structure Updates: Updated the MbMeta struct to include a finalized flag and changed last_advanced_eb from H256 to Option<H256> to better represent state transitions.
• Consensus Logic Refinement: Fixed create_batch_commitment and try_include_chain_commitment to ensure correct propagation of chain commitments and Ethereum-anchor advances.
• Database Migration: Introduced a v1 to v2 database migration to backfill the new finalized flag and re-encode existing MbMeta records.
• Validator Set Resolution: Implemented era-aware validator set resolution in the consensus engine to support historical era validation during sync.
• Test Suite Cleanup: Removed the disable-tests gate and updated existing tests to reflect the new consensus logic and data structures.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a database migration (v1 to v2) where MbMeta gains a finalized flag and its last_advanced_eb field is changed to an Option<H256>. It refactors the batch commitment manager and filler to support appending multiple chain commitments, resolving potential validator-set handover stalls and sync issues. Additionally, it updates the consensus and sync layers to ensure era-correct validator sets are used for historical certificate verification. The review feedback highlights two critical issues: a compilation error in filler.rs due to calling checked_add directly on a NonZero type, and a potential panic in compute.rs where .expect() is used instead of gracefully returning the pre-defined ParentMbLastAdvancedEbMissing error.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.