Rename SignedAttestation.message to .data to align with leanSpec

[pablodeymo]

Motivation

The leanSpec reference implementation changed SignedAttestation to inherit from Attestation, which uses data instead of message for the AttestationData field (commit 3b9d054). This is part of the post-devnet-3 alignment work tracked in #155.

Description

Pure field rename: SignedAttestation.message → SignedAttestation.data across 4 files, 13 call sites.

No behavioral or wire-format change. SSZ encodes by field position, not field name, so the serialization is identical before and after this PR.

Changes by file

File	Change
crates/common/types/src/attestation.rs	Field declaration message → data
crates/blockchain/src/lib.rs	Construction site: message: → data:
crates/blockchain/src/store.rs	Access: signed_attestation.message → .data
crates/net/p2p/src/gossipsub/handler.rs	All .message. accesses → .data. (10 occurrences)

Why data instead of message?

In the leanSpec, SignedAttestation now inherits from Attestation:

# Before (devnet-3)
class SignedAttestation(Container):
    validator_id: ValidatorIndex
    message: AttestationData      # ← standalone field
    signature: Signature

# After (latest leanSpec)
class SignedAttestation(Attestation):   # ← inherits from Attestation
    signature: Signature

class Attestation(Container):
    validator_id: ValidatorIndex
    data: AttestationData         # ← field name is "data"

Rust doesn't have inheritance, so we keep the flat struct but align the field name.

How to test

cargo check --workspace   # Compiles clean
cargo clippy --workspace -- -D warnings   # No warnings
cargo test --workspace --release   # All 92 tests pass (5 pre-existing ignores)

Related issues

• Part of Add support for pq-devnet-4 #155 (pq-devnet-4 preparation)

[github-actions]

🤖 Kimi Code Review

Review Summary

This PR renames the message field to data in SignedAttestation for clarity. The change is consistent across all files and appears correct.

Issues Found

1. Potential breaking change in SSZ encoding (crates/common/types/src/attestation.rs:37-44)

   • The SSZ encoding/decoding will change due to the field rename. If this struct is persisted or sent over the network, this is a breaking change that could cause compatibility issues with existing nodes.
   • Recommendation: Verify if this struct has SSZ derive macros that use field names. If so, consider adding a #[ssz(rename = "message")] attribute or bumping the protocol version.

2. Missing field validation (crates/blockchain/src/store.rs:353-355)

   • When creating the Attestation from SignedAttestation, there's no validation that data is the same as what was originally signed. This could allow validators to equivocate.
   • Recommendation: Add verification that the signature matches the data field before accepting the attestation.

3. Inconsistent logging (crates/net/p2p/src/gossipsub/handler.rs:95-101, 134-140)

   • The logging statements are duplicated between the receive and publish paths. Consider extracting a helper function to avoid drift.

Security Considerations

• The field rename itself doesn't introduce security issues, but ensure that any signature verification logic correctly uses the new field name.
• Verify that XMSS signature verification properly covers the data field and not any renamed internal structure.

Performance Impact

• No performance impact - this is purely a naming change.

Code Quality

• The change is well-executed with consistent updates across all usage sites.
• The new name data is more semantically accurate than message for attestation data.

---

Automated review by Kimi (Moonshot AI) · custom prompt

[github-actions]

🤖 Codex Code Review

1. Low: Public API break for downstream crates
   Renaming SignedAttestation.message to data changes a public struct field and will break any external Rust consumer compiling against common/types without a semver-major bump or migration note.
   Ref: attestation.rs:37

No correctness, security, fork-choice, attestation-validation, state-transition, XMSS, or SSZ-layout issues were evident in this diff itself. The SSZ field order appears unchanged, so wire encoding should remain stable.

Residual risk/testing gap:

• I could not run cargo check in this environment due rustup permission/toolchain sync failure, so compile validation is not confirmed here.

---

Automated review by OpenAI Codex · custom prompt

[github-actions]

🤖 Claude Code Review

The diff is clean and complete. Here's my review:

---

Code Review: PR #183 — Rename SignedAttestation.message to .data

Summary

Pure field rename across 4 files, 15 changed lines (15 additions, 15 deletions). No logic changes.

Correctness

• All access sites updated consistently: struct declaration, construction in lib.rs, field access in store.rs, and all 10 occurrences in gossipsub/handler.rs.
• Grep confirms zero remaining .message accesses on SignedAttestation in the codebase.
• The other .message usages remaining in the codebase (signed_block.message, BlockWithAttestation, etc.) are unrelated structs — correctly left unchanged.

SSZ Wire-Format Claim

The PR states "SSZ encodes by field position, not field name, so the serialization is identical." This is correct. SSZ serialization order is determined by field declaration order. The renamed field remains in the same position (index 1, between validator_id and signature), so there is no wire-format change. Cross-client compatibility is preserved.

Comment Update

The doc comment update in attestation.rs:39 is accurate: "The attestation message signed by the validator" → "The attestation data signed by the validator." Matches the field rename and the leanSpec terminology.

No Issues Found

This is a clean mechanical rename with no behavioral changes. The implementation is correct and complete.

---

Automated review by Claude (Anthropic) · custom prompt

[greptile-apps]

Greptile Summary

This PR is a pure, mechanical field rename — SignedAttestation.message → SignedAttestation.data — across 4 files and 13 call sites, aligning the Rust codebase with the updated leanSpec reference implementation as part of post-devnet-3 / pq-devnet-4 preparation.

• crates/common/types/src/attestation.rs: Field declaration and its doc-comment updated. SignedAttestation field order is unchanged (validator_id, data, signature), so SSZ wire format is identical before and after.
• crates/blockchain/src/lib.rs: Single struct-literal construction site updated.
• crates/blockchain/src/store.rs: Single field-access site updated; the surrounding Attestation { validator_id, data: … } assignment was already using data, so there is no naming confusion post-rename.
• crates/net/p2p/src/gossipsub/handler.rs: Ten logging/tracing expressions updated across handle_gossipsub_message and publish_attestation. All remaining .message accesses in this file refer to SignedBlockWithAttestation.message, which is a different, unrelated field and is correctly untouched.

No logic, behaviour, or wire-format changes are introduced. The rename is complete and consistent across the workspace.

Confidence Score: 5/5

• This PR is safe to merge — it is a mechanical field rename with no behavioural or wire-format impact.
• All 13 call sites are updated, no SignedAttestation.message references remain anywhere in the workspace, and SSZ field ordering is preserved. The change is entirely cosmetic at the protocol level.
• No files require special attention.

Important Files Changed

Filename	Overview
crates/common/types/src/attestation.rs	Field renamed from message: AttestationData to data: AttestationData in SignedAttestation; doc-comment updated to match. No behavioral change.
crates/blockchain/src/lib.rs	Single struct construction site updated from message: to data: when building a SignedAttestation. Trivially correct.
crates/blockchain/src/store.rs	One field access updated from signed_attestation.message to signed_attestation.data; the existing variable data on the Attestation struct is retained, so logic is unchanged.
crates/net/p2p/src/gossipsub/handler.rs	Ten .message. → .data. access sites updated across handle_gossipsub_message and publish_attestation; all are logging/tracing expressions with no side effects on logic.

Sequence Diagram

sequenceDiagram
    participant V as Validator (lib.rs)
    participant G as Gossipsub Handler (handler.rs)
    participant S as Store (store.rs)

    V->>V: Build SignedAttestation { validator_id, data, signature }
    V->>G: P2PMessage::PublishAttestation(signed_attestation)
    G->>G: Read attestation.data.slot / .target / .source (logging)
    G->>G: Encode to SSZ & publish to attestation subnet topic

    Note over G,S: Peer receives gossip
    G->>G: Decode SignedAttestation from SSZ
    G->>G: Read signed_attestation.data.slot / .head / .target / .source (logging)
    G->>S: notify_new_attestation(signed_attestation)
    S->>S: signed_attestation.data → Attestation { validator_id, data }
    S->>S: validate_attestation_data(&attestation.data)

Loading

_{Last reviewed commit: d182326}