feat(consensus): BLS endorsement sender + wire format (IIP-52)

[envestcc]

Depends on #4841 — stacked on top of the BLS key plumbing PR. Once #4841 merges, this PR's diff will collapse to just the new changes.

Sender + wire-format half of the BLS signature aggregation work tracked in IIP-52. Receiver verification + endorsement-manager quorum integration land in a follow-up PR; with the feature gate parked at `IsToBeEnabled` this PR is dead code in production.

What's in (new vs. #4841)

• `endorsement.BLSEndorsement` — new Go type holding (timestamp, endorser iotex address, BLS signature). Endorser is the delegate's iotex address, not the BLS pubkey; receivers look up the registered pubkey from candidate state, mirroring the BlockFooter aggregate verification model.
• `EndorsedConsensusMessage` — polymorphic over `*Endorsement` and `*BLSEndorsement`, round-trips through `ConsensusMessage.endorsement` and `ConsensusMessage.bls_endorsement`. At most one is set per message.
• `ProofOfLock` — internal struct that carries either `[]*Endorsement` or `[]*BLSEndorsement` so the proof-of-lock cascade doesn't sprout if/else branches at every callsite. `blockProposal`, `roundCtx.proofOfLock`, and the `BlockProposal` proto Serialize / LoadProto all flow through it.
• `ConsensusConfig.BLSAggregationEnabled(height)` — feature gate wired off `Genesis.ToBeEnabledBlockHeight`. Will be re-pointed at a named hardfork height once the full Phase-2 stack lands.
• Sender side:
  • `rollDPoSCtx.newEndorsement` now signs PROPOSAL, LOCK and COMMIT votes with BLS post-fork (skipping delegates without a configured BLS key).
  • `rollDPoSCtx.endorseBlockProposal` signs the proposer's wrapping endorsement with BLS post-fork. Block header signing remains on the ECDSA producer key — that signature ties the block to a chain identity and is unrelated to the consensus vote layer.
  • The proposer's `producerKey` (ECDSA + BLS + address) is threaded through `Proposal / mintNewBlock / endorseBlockProposal` so the branch can pick the right key without a separate lookup.
• iotex-proto bump to `envestcc/iotex-proto@03a99cc` (PR #169): `BlockProposal.bls_endorsements` added so post-fork proof-of-lock can ride the wire.

What's deferred to the follow-up PR

• Endorsement manager BLS collection + DB persistence
• `roundCtx.AddBLSVoteEndorsement`
• `RollDPoS.HandleConsensusMsg` BLS dispatch + signature verification (`CheckBlockProposer` / `CheckVoteEndorser` BLS path)
• BLS pubkey lookup mechanism (from candidate state at round start)
• Proof-of-lock BLS replay in `CheckBlockProposer` (a TODO marker is in place where BLS endorsements are decoded but not yet counted toward majority)
• End-to-end tests for the BLS COMMIT / relock path

Why all three topics, not just COMMIT

The original IIP-52 motivation (compress the on-chain footer) only requires aggregating COMMIT votes. Implementation-wise though, keeping PROPOSAL/LOCK on ECDSA while COMMIT runs on BLS creates a mixed-mode coupling at the lock check: a delegate that emitted COMMIT (BLS) but not PROPOSAL still counts toward locking, but the proof-of-lock would then need to carry mixed-type entries on the wire. Switching all three topics to BLS post-fork keeps the lock check / proof-of-lock paths uniform and leaves room for future LOCK aggregation in BlockProposal relay (`bls_endorsements` field would then aggregate). The CPU cost (extra ~36 ms verify per 5-second round) is negligible.

Test plan

• `go build ./...`
• `go vet ./...`
• Targeted tests pass: `TestNewRollDPoSCtx`, `TestCheckVoteEndorser`, `TestCheckBlockProposer`, etc. (13 tests)
• Full BLS COMMIT path tests land with the receiver PR

🤖 Generated with Claude Code

[envestcc]

I think there is no need to add a new BLSEndorsement; we can simply continue using Endorsement. The length of the signature should be sufficient to distinguish whether it is a BLS or an ECDSA signature. This way, many parts of the code would not need to be modified.

[envestcc]

Refactored per the review suggestion — force-pushed 73e2d57.

Endorsement is now reused as-is for BLS post-fork; signature length (65B secp256k1 vs 96B BLS) is the discriminator. The endorser field keeps its existing semantics (secp256k1 producer pubkey), so Endorser().Address() still resolves the iotex address; receivers will look up the registered BLS verifying key from candidate state by that address.

Dropped:

• endorsement.BLSEndorsement Go type
• EndorsedConsensusMessage polymorphism (back to single endorsement field)
• ProofOfLock internal struct (back to []*Endorsement)
• blockProposal proto serialize/deserialize branching

Also amended iotex-proto PR #169 to drop the standalone BLSEndorsement message and the bls_endorsement / bls_endorsements fields on ConsensusMessage / BlockProposal. The proto changes there are now just the BlockFooter aggregate fields plus a comment clarifying Endorsement.signature semantics. New SHA: e4439ef.

Diff size: 12 files / +396 → 6 files / +147. Build and 15 targeted tests still green.

(I tried to update the PR body to reflect this too, but GitHub's GraphQL keeps 5xx'ing on edits — sorry for the stale description until that clears.)

[envestcc]

Is it necessary to separate a new BLSEndorsements method, or can we directly modify the existing newEndorsement method?

[envestcc]

Done in ef3235d — merged newBLSEndorsements back into newEndorsement with a single signVote helper that branches internally on useBLS. Also tightened endorseBlockProposal to use the same helper, dropping its duplicated ECDSA/BLS branch. The rolldposctx.go portion of the diff drops from +80 to +51 lines.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud