refactor(cli): move CliOptions into a dedicated cli module#477
Conversation
main.rs had grown to mix CLI parsing with node orchestration. Extract the CliOptions clap struct into its own bin/ethlambda/src/cli.rs so the flag surface lives in one place and main.rs reads as orchestration only.
🤖 Kimi Code ReviewThis is a clean refactoring with no issues introduced. Positive observations:
Verification:
The refactoring is safe to merge. Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt |
🤖 Codex Code ReviewNo findings. This diff is a pure refactor: Residual risk: I could not complete a local compile in this environment. Automated review by OpenAI Codex · gpt-5.4 · custom prompt |
Greptile SummaryThis PR moves the ethlambda CLI flags into a dedicated module. The main changes are:
Confidence Score: 5/5This looks safe to merge.
|
| Filename | Overview |
|---|---|
| bin/ethlambda/src/cli.rs | Adds the moved CliOptions clap parser struct with the same flags, defaults, and documentation. |
| bin/ethlambda/src/main.rs | Imports the new CLI module and removes the inline CliOptions definition. |
Reviews (1): Last reviewed commit: "refactor(cli): move CliOptions into a de..." | Re-trigger Greptile
🤖 Claude Code ReviewReview:
|
…#479) > Stacked on #477 (`refactor/cli-options-module`). Base will retarget to `main` once #477 merges. ## What Adds `--enable-proposer-aggregation` (default **off**) controlling how `build_block` collapses attestations that share the same `AttestationData`. A block may carry **at most one entry per `AttestationData`** — `on_block` rejects duplicates (`StoreError::DuplicateAttestationData`) before signature verification, so the proposer must collapse same-data proofs to one **either way**. This flag only changes *how*: | | strategy | coverage | cost | |---|---|---|---| | **enabled** | merge same-data proofs via recursive Type-1 aggregation into one union-coverage proof (leanSpec #510) | max (union of all proofs) | one leanVM aggregation per duplicated data entry | | **disabled** (default) | keep the single best-coverage proof per data, drop the rest | bounded by the best individual proof | no leanVM aggregation | Today the proposer always aggregates; the dominant cost of building blocks that carry attestations is exactly this per-data leanVM aggregation. The flag makes it opt-in. ## Threading ``` CliOptions.enable_proposer_aggregation (bin/ethlambda/src/cli.rs, default false) -> BlockChain::spawn(..) (crates/blockchain/src/lib.rs) -> BlockChainServer.enable_proposer_aggregation -> produce_block_with_signatures(.., flag) (store.rs) -> build_block(.., flag) (block_builder.rs) ├─ enabled -> compact_attestations (unchanged) └─ disabled -> keep_best_proof_per_data (new) ``` `keep_best_proof_per_data` groups selected entries by `AttestationData`, keeps the entry with the most participants (ties → first occurrence), and preserves first-occurrence order — mirroring `compact_attestations`' grouping but with no crypto. The one-entry-per-data invariant and the 1:1 attestation↔proof correspondence hold in both paths. ## Behavior change The binary default flips: proposers stop merging same-data proofs unless `--enable-proposer-aggregation` is passed. Blocks stay valid and interoperable; attestation entries just carry less voter coverage (the best single proof rather than the union). ## Scope note This gates only the in-`build_block` collapse (per the request). The separate Type-1→Type-2 merge in `propose_block` is untouched. With aggregation off there are at most `MAX_ATTESTATIONS_DATA` single-proof components feeding that merge, same as before (one per data) — so no blow-up there. Net build-time impact is worth a devnet A/B. ## Tests - New `build_block_without_proposer_aggregation_keeps_single_best_proof_per_data`: one `AttestationData` with two proofs ({0} and {1,2}); with the flag off, asserts exactly **one** entry survives, 1:1 with its signature, and the kept proof is the higher-coverage `{1,2}` (no leanVM crypto invoked). - Existing `build_block` tests pass `true` to preserve their current (aggregating) behavior. - `cargo clippy -p ethlambda-blockchain -p ethlambda --all-targets -- -D warnings` ✅ - `cargo test -p ethlambda-blockchain --lib` ✅ (39 passed) ## History First commit took the naive "leave duplicates unmerged" approach; the follow-up fix (`keep_best_proof_per_data`) corrects it after confirming `on_block` rejects duplicate `AttestationData`.
Why
bin/ethlambda/src/main.rsmixed the CLI flag surface (the ~80-lineCliOptionsclap struct) with node orchestration. Splitting them keeps each file single-purpose: the flag definitions live in one place, andmain.rsreads as orchestration only.What
bin/ethlambda/src/cli.rsholdingpub(crate) struct CliOptions(moved verbatim, docs and#[arg]/#[command]attributes intact). Fields arepub(crate)sincemainreads nearly all of them.main.rs: registersmod cli;, importsCliOptions, drops the inline definition. No behavior change.Verification
cargo build -p ethlambda✅cargo clippy -p ethlambda --all-targets -- -D warnings✅cargo fmt✅Pure code move; the parsed CLI surface is unchanged.