feat: add modular block authentication together with MAC-vector and ML-DSA block signatures

[NaitsabesMue]

Summary

This PR separates block identity from block authentication and adds modular authentication schemes for Starfish, Starfish Speed, and Sparse Starfish Speed.

Block references now depend only on block content, while authentication is stored and transmitted separately.

Authentication schemes

• Ed25519
• ML-DSA-44 and ML-DSA-65
• Committee-sized MAC vectors

The design keeps the schemes interchangeable so additional signature or MAC implementations can be evaluated later.

MAC-vector behavior

• MAC vectors use a flat byte-string encoding.
• Direct author block streaming sends the full MAC vector.
• Relay, push, pull, and synchronization paths send only the recipient’s MAC tag.
• A recipient verifies its own tag before accepting the block.
• Full vectors are accepted as proof of authorship only when received directly from the block author.
• Relayed nodes cannot claim or distribute unverified tags belonging to other validators.

Protocol variants

The new authentication variants are available for:

• Starfish
• Starfish Speed
• Sparse Starfish Speed

Sparse refers to Sparse Starfish Speed, not Bluestreak.

Validation

Focused authentication, serialization, relay, synchronization, and live consensus tests pass.

The full parallel core test suite reaches 222/224. Two lifecycle resource-release/teardown assertions remain unstable; the authentication and protocol correctness tests themselves pass.

Benchmarks

Local geographic emulation was run for all nine combinations with:

• 40 validators
• 1,000 tx/s aggregate offered load
• 60-second runs
• AWS latency-table emulation

Authentication choice had no material throughput impact. MAC increased outbound bandwidth by approximately 6.6% for plain Starfish and Starfish Speed. Its relative overhead was larger for Sparse Starfish Speed because sparse dissemination removes most other protocol traffic, although its absolute bandwidth remained substantially lower.

The benchmark reports and validator-scaling observations are included under benchmark-results/.

[github-actions]

Package	Line Rate	Health
crates/starfish-core/src/core_thread	23%	❌
crates/starfish/src	3%	❌
crates/starfish-core/src/consensus	67%	➖
crates/starfish-core/src	44%	❌
crates/starfish-core/src/runtime	23%	❌
crates/orchestrator/src	17%	❌
crates/orchestrator/src/client	7%	❌
crates/orchestrator/src/protocol	14%	❌
Summary	36% (5388 / 15169)	❌

[polinikita]

I don't understand why many unrelated parts were modified

[NaitsabesMue]

Thanks, made changes, now hopefully removed all unnecessary changes.

[NaitsabesMue]

Also

• Removed the committed benchmark-result reports; results can instead be shown as a graph or short summary in the PR.
• Decoupled digital-signature selection from the consensus protocol. block_authentication now selects Ed25519 (default), ML-DSA-44, or ML-DSA-65 for every protocol.
• Removed the separate *-ml-dsa-* protocol variants.
• Kept the MAC variants separate and clearly marked them as experimental lower-bound benchmarks. MAC vectors are not a drop-in signature replacement and currently provide no protocol safety/liveness guarantee without an additional quorum-authentication/RBC mechanism.
• Removed unrelated changes and kept the modular block-authentication plumbing needed for these experiments.

[polinikita]

I would not add the experiment results as they will need to be reevaluated after every small modification of a protocol, which sometimes happens (e.g. starfish-speed is very sensitive to the soft_timeout constant). In addition, I would not make standalone protocols with just different identification fields. So, my recommendation:

• remove benchmark results as a text - a graph or short summary inside PR would fit better
• add a configurable parameter for selecting an authentication method that works with every protocol in the repo. By default, the current Ed25519 scheme. This allows for more consistent changes across the protocol.
• make the pr more focused without touching too many components where it is not necessary.