feat(vara.eth): add --batch-commitment-period node knob

[grishasobol]

What

Adds a coordinator-local knob batch_commitment_period: NonZeroU32 (CLI flag
--batch-commitment-period, default 1). When a node is the elected
coordinator it only builds a BatchCommitment on Ethereum blocks whose
height % batch_commitment_period == 0. With the default 1 the behavior is
unchanged (commit every block); larger values commit every Nth block (every
2nd, 5th, 10th, 100th, ...).

How

• DEFAULT_BATCH_COMMITMENT_PERIOD (= 1) in ethexe-common.
• Threaded CLI NodeParams → service::config::NodeConfig →
  ethexe_consensus::ValidatorConfig → ValidatorCore.
• Gate added in Idle::maybe_advance_to_role (ethexe/consensus/.../idle.rs),
  inside the coordinator branch only: the elected coordinator drops back to
  Idle on a non-multiple height. Participants are unaffected — they always
  enter the role and validate whatever the coordinator commits. This keeps the
  knob purely coordinator-local (like commitment_delay_limit): different nodes
  may run different values without losing quorum.

Tests

• Defaults to period = 1 everywhere (no behavior change in existing tests).
• ethexe-consensus:
  • batch_commitment_period_gates_coordinator_by_block_height (period 2 — as
    coordinator: odd height stays Idle, even height → CoordinatorBoot).
  • participant_enters_regardless_of_batch_commitment_period (huge period —
    a non-coordinator still enters Participant on a non-multiple height).
• ethexe-service: batch_commitment_period_commits_only_on_multiples
  (period 2, single validator/coordinator — a ping still round-trips and every
  committed batch lands on a multiple-of-period height).

Local: cargo fmt --all, cargo clippy --all-targets (clean), new tests +
ethexe-consensus/ethexe-common/ethexe-cli suites pass; full
cargo nextest run -p "ethexe-*" passed on the prior revision.

Operational note

The period is coordinator-local, so divergent values across nodes are safe.
Keep it small enough that every era's election window still contains several
multiple-of-period blocks (validator-set rotation has an election-window
deadline), and prefer period <= uncommitted-chain-len-threshold so the
idle-chain checkpoint still fires close to its threshold. Default 1 avoids
all of this.

🤖 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 adds a new node-local configuration knob that allows the elected coordinator to throttle batch commitments to every Nth block. This change is designed to be purely local to the coordinator, ensuring that different nodes can operate with different commitment cadences without impacting consensus or requiring cross-node agreement. The implementation updates the configuration propagation path and adds logic in the consensus layer to conditionally skip the coordinator boot process based on block height.

Highlights

• New CLI Knob: Introduced a coordinator-local configuration flag --batch-commitment-period (default 1) to control the cadence of batch commitments based on Ethereum block height.
• Coordinator Logic: Updated the consensus coordinator role to skip block commitment if the current block height is not a multiple of the configured period, while maintaining standard participant behavior.
• Testing: Added comprehensive unit and integration tests to verify that the coordinator correctly gates commitments while participants remain unaffected.

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 coordinator-local configuration parameter, batch_commitment_period, allowing coordinators to build batch commitments only on blocks whose height is a multiple of the configured period. Feedback on the changes suggests explicitly casting the period to u64 when calling is_multiple_of to ensure type correctness and compilation, and dynamically finding even and odd blocks in the unit tests to avoid relying on brittle hardcoded indices.

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.