refactor(types): rename TypeOneMultiSignature to SingleMessageAggregate

[MegaRedHand]

Summary

Mirrors leanSpec PR #799, which renamed the multi-signature container types to express what they bind rather than the lean-multisig prover convention (type-1 / type-2).

ethlambda had already renamed TypeTwoMultiSignature → MultiMessageAggregate in an earlier change, so this completes the pair:

Old	New
TypeOneMultiSignature	SingleMessageAggregate

What changed

• Renamed the struct TypeOneMultiSignature → SingleMessageAggregate and all ~90 references across the workspace.
• Followed the rename into local variables (type_one_proofs → single_message_aggregates, block_t1 → block_single_message_aggregate), the SSZ round-trip test name, log messages, and doc/prose mentions of the container.
• Added doc notes on both SingleMessageAggregate and MultiMessageAggregate that they are also known as type-1 / type-2 proofs, so the older lean-multisig terminology stays discoverable.

What was intentionally left unchanged

Paralleling #799's decision to keep the prover binding names, the ethlambda-crypto wrapper functions and their docs keep the type_1/type_2 terminology, since they wrap the lean-multisig primitives directly:

• merge_type_1s_into_type_2, verify_type_2_signature, split_type_2_by_message
• decompress_type1, compress_type1_to_byte_list, compress_type2_to_byte_list
• the LMType1 / LMType2 aliases and the Type2ComponentCountMismatch error variant

Notes

• No wire-format or behavior change. SingleMessageAggregate is the same { participants, proof } SSZ container under a new name; hash_tree_root and on-wire encoding are unaffected.

Test plan

• make fmt
• make lint (clippy -D warnings) clean
• cargo test --workspace --release — all green (30 suites, 0 failures)
• forkchoice_spectests — 116 passed

[github-actions]

🤖 Kimi Code Review

This is a straightforward, high-quality refactoring PR that improves readability by replacing the opaque "Type-1 / Type-2" nomenclature with descriptive SingleMessageAggregate / MultiMessageAggregate terminology. No logic changes; purely naming and documentation.

Summary of changes:

• Renames TypeOneMultiSignature → SingleMessageAggregate across the codebase
• Updates comments to explain the distinction between single-message (one attestation data, many validators) and multi-message (many attestation data + proposer signature) aggregates
• Variable names updated (e.g., type_one_proofs → single_message_aggregates) for clarity

Verification:

• SSZ compatibility: Struct fields unchanged (participants, proof); encoding remains compatible with leanSpec PR #717
• No serde changes: No #[serde(rename)] attributes affected; wire format unchanged
• Consensus safety: No behavioral changes to justification/finalization, fork choice, or XMSS verification logic

Minor note:
In crates/blockchain/src/lib.rs:571, the loop variable sma (single-message aggregate) is much clearer than the previous t1 abbreviation.

LGTM – No blockers.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

[github-actions]

🤖 Codex Code Review

No functional findings.

I traced the rename through the consensus-critical paths (block_builder, block signature verification, reaggregation, payload buffering, fork-choice fixtures) and the patch does not alter proof semantics or SSZ field layout. The SingleMessageAggregate struct in crates/common/types/src/block.rs is a straight rename of the old TypeOneMultiSignature shape, so attestation processing, proposer proof wrapping, and merged block-proof verification remain behaviorally unchanged.

Residual risk is limited to build/test validation rather than logic: I could not run cargo tests in this environment because Cargo/Rustup wants a writable dependency cache and the git dependency fetch path is blocked by the sandboxed filesystem. The targeted commands failed before compilation for that reason. If this crate has out-of-tree consumers, one thing to double-check is whether the public type rename at crates/common/types/src/block.rs needs a compatibility alias or release-note callout.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

[greptile-apps]

Greptile Summary

This PR renames the single-message aggregate proof type across the workspace. The main changes are:

• TypeOneMultiSignature becomes SingleMessageAggregate.
• Runtime aggregation, block building, reaggregation, storage, RPC test-driver, and fork-choice test paths use the new name.
• Docs and test names now describe single-message and multi-message aggregate terminology.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.
• The renamed type keeps the same fields, derives, constructors, and participant helper behavior.
• The updated runtime paths still pass the same participant bitfields and proof bytes.

Important Files Changed

Filename	Overview
crates/common/types/src/block.rs	Renamed the proof container while keeping the same field layout, derives, and helper methods.
crates/common/types/src/attestation.rs	Updated aggregated attestations to use the renamed proof type.
crates/blockchain/src/aggregation.rs	Updated aggregation job and proof-selection types to the new name.
crates/blockchain/src/block_builder.rs	Updated block-building proof selection, compaction, and tests to the renamed type.
crates/blockchain/src/lib.rs	Updated block prebuild and merge-input naming around single-message aggregates.
crates/blockchain/src/reaggregate.rs	Updated split-and-merge reaggregation flow to use the renamed proof container.
crates/blockchain/src/store.rs	Updated block production signatures and verification prose for the new aggregate terminology.
crates/storage/src/store.rs	Updated payload buffer storage APIs to carry the renamed aggregate type.
crates/blockchain/tests/forkchoice_spectests.rs	Updated fork-choice spectest helper proof construction to the new type name.
crates/net/rpc/src/test_driver.rs	Updated RPC fork-choice test-driver aggregated attestation construction.

_{Reviews (1): Last reviewed commit: "refactor(types): rename TypeOneMultiSign..." | Re-trigger Greptile}

[github-actions]

🤖 Claude Code Review

All eight angles returned clean, and the single in-scope conventions candidate was REFUTED. Here is the review:

---

Review: refactor(types): rename TypeOneMultiSignature to SingleMessageAggregate

This PR completes the lean-multisig naming migration by renaming TypeOneMultiSignature → SingleMessageAggregate across 15 files (~362 lines), mirroring leanSpec PR #799. It is a pure mechanical rename — no logic, wire format, or behavior changes. The companion rename (TypeTwoMultiSignature → MultiMessageAggregate) was already done in a prior commit.

No actionable findings. All eight review angles came back clean:

• Completeness: Zero remaining TypeOneMultiSignature occurrences in the workspace. All 15 files updated consistently, including imports, type annotations, function signatures, struct constructions, test helpers, and local variables (type_one_proofs → single_message_aggregates, block_t1 → block_single_message_aggregate, t1 → sma).
• Wire format: SSZ encoding is field-order-based; the struct fields (participants: AggregationBits, proof: ByteList512KiB) are unchanged, so hash tree roots and on-wire bytes are identical.
• Crypto boundary: The intentional non-rename of merge_type_1s_into_type_2, verify_type_2_signature, split_type_2_by_message, LMType1, LMType2, etc. is correct — those names belong to the lean-multisig prover convention layer and operate on ByteList512KiB directly, creating no type mismatch.
• No guards dropped, no validations narrowed, no tests removed.

The added doc notes (Also known as a *type-1* proof) on both SingleMessageAggregate and MultiMessageAggregate are a nice touch that keeps the historical lean-multisig terminology discoverable without reintroducing the old Rust names.

LGTM.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt