Decentralize Signer Registration - Feasibility

## Why

The Mithril network currently relies on a **centralized leader aggregator** for signer registration (design [02: Centralized registration and broadcast](https://docs.google.com/presentation/d/1ij9wkjYZ_nlNcP5aZ2Oc_IfW_mlh-WdPHBr4EzJg_eg/edit?slide=id.g31624b89d63_0_0#slide=id.g31624b89d63_0_0), implemented in #2238). While the signature diffusion has been decentralized thanks to the DMQ protocol ([CIP-0137](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0137)), the signer registration remains a centralized process where:
- The **leader aggregator** is the single point responsible for collecting and broadcasting signer registrations.
- **Follower aggregators** synchronize their signer registrations from the leader and always reject direct registrations.
- The leader aggregator is a **Single Point of Failure (SPOF)** for the registration process.

As concluded in the [signer registration exploration](https://docs.google.com/presentation/d/1ij9wkjYZ_nlNcP5aZ2Oc_IfW_mlh-WdPHBr4EzJg_eg/edit?slide=id.g31624b89d63_0_0#slide=id.g31624b89d63_0_0) (#2029), the recommended path forward is to investigate **design 12: Decentralized DMQ BFT registration** as the primary solution for achieving fully decentralized signer registration. This design scored the highest across all evaluation dimensions (Decentralization: 5, Trustless Assumptions: 5, Network Resilience: 5, Protocol Liveness: 5, Easy Implementation: 4, SPO Experience: 5) while requiring no extra cost or operational burden for SPOs and no impact on Cardano chain load.
However, this design is currently a **draft that requires further investigation and modeling by researchers** before it can be validated. This feasibility study aims to determine whether this approach is viable and, if so, to produce a concrete protocol specification that can be implemented.

**Design 07: Decentralized registration and broadcast with Cardano chain** serves as the **fallback option** should the DMQ BFT registration approach prove infeasible. While it achieves full decentralization (all scores at 5 except Easy Implementation: 3 and SPO Experience: 2), it comes at the cost of on-chain transactions for SPOs every epoch and potential Cardano chain load.

## What
Conduct a feasibility study for the **Decentralized DMQ BFT registration** protocol (design 12) to determine whether it can reliably achieve probabilistic quasi-consensus on signer registrations across all signers and aggregators in a Mithril network.

### Protocol overview
The core idea of the DMQ BFT registration is:
1. **Gossip-based registration diffusion**: During the registration epoch (2 epochs before the signing epoch), signers **repeatedly broadcast** their signer registration at regular intervals on a P2P network (leveraging the Cardano DMQ protocol).
1. **Local record keeping**: All signers and aggregators keep track of signer registrations received and **how many times** each registration was received.
1. **Threshold-based filtering**: Each participant independently filters out signer registrations that have not reached a **minimum repetition threshold**, ensuring that only well-propagated registrations are included in the local key registration computation.
1. **Temporal attenuation**: The impact of repetitions is **exponentially attenuated by the distance to the end of the epoch** to prevent late adversary behavior from exploiting the closing window.
1. **Authenticated messages**: All messages on the P2P network are **authenticated via KES signatures** (natively supported by the Cardano DMQ protocol), enabling detection of equivocation.
1. **Equivocation detection and proof**: When a peer detects that an adversary signer has broadcast **multiple conflicting versions** of its signer registration, it creates an **Equivocation Proof** message that is diffused to the rest of the network (also with a repetition mechanism). Upon reception of a valid Equivocation Proof, all participants filter out the adversary signer from their records.

The protocol exploits two key properties:
- The quasi-consensus on signer registrations needs only to be achieved **once every epoch (5 days)**, which is ~20,000 times slower than the Cardano chain consensus (every 20 seconds), motivating the use of less efficient but simpler networking with repetitions.
- The data on which the quasi-consensus needs to be achieved is **indexed by the pool id** of the signer, which is directly extractable from the authenticated message itself.

### Key research questions
The feasibility study should address the following questions:
1. **Convergence guarantees**: Under what network conditions (latency, partitioning, churn) can the repetition-based mechanism guarantee that all honest participants converge to the same set of signer registrations?
1. **Threshold calibration**: How should the repetition threshold and temporal attenuation parameters be calibrated relative to network size, epoch duration, and expected network reliability?
1. **Adversarial resilience**: What fraction of adversarial signers can the protocol tolerate while maintaining liveness? What are the precise BFT assumptions?
1. **Equivocation proof protocol**: Is the equivocation proof mechanism sufficient to handle all adversarial strategies (e.g., targeted equivocation to subsets of the network)?
1. **Liveness under network partitioning**: How does the protocol behave under large-scale network partitions? What are the failure modes and their impact on certificate production?
1. **Node availability requirement**: All nodes need to be alive during the registration epoch. What is the impact of temporary node unavailability on the resulting key registration?
1. **Signer/aggregator asymmetry**: If the number of aggregators and signers is not balanced, does the two-phase mechanism (registration broadcast followed by key registration broadcast at the next epoch) work reliably?
1. **Message overhead**: What is the expected message volume on the P2P network given the repetition mechanism, and is it sustainable for the DMQ network?

### Deliverables
- **Protocol specification**: A formal or semi-formal specification of the DMQ BFT registration protocol, including message formats, state machine, threshold parameters, and equivocation proof mechanism.
- **Threat model and security analysis**: A document detailing the adversarial model, the BFT assumptions, and the security guarantees (or lack thereof) of the protocol.
- **Simulation results** (if applicable): Simulation of the protocol under various network conditions to validate convergence, measure message overhead, and calibrate parameters.
- **Feasibility verdict**: A clear go/no-go recommendation with justification. If no-go, identify the specific blockers and whether they can be overcome.
- **Fallback assessment**: If the verdict is no-go or conditional, provide an assessment of the effort required to implement design 07 (Cardano chain registration) as the fallback and the associated risks.

## How
- [ ] Review the existing DMQ infrastructure and [CIP-0137](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0137) specification to assess its suitability for signer registration messages
- [ ] Design the detailed protocol specification for DMQ BFT signer registration (message formats, state machine, repetition parameters, threshold rules, temporal attenuation function)
- [ ] Design the equivocation detection and proof mechanism
- [ ] Model the adversarial scenarios and establish the BFT assumptions and security bounds
- [ ] Simulate the protocol under various network conditions (nominal, degraded, adversarial)
- [ ] Calibrate the protocol parameters (repetition interval, threshold, attenuation curve) based on simulation results
- [ ] Assess the integration path with the existing Mithril signer and aggregator architecture (current leader/follower model, `SignerRegistrationPublisher`/`SignerRegistrationRoundOpener` traits)
- [ ] Produce the feasibility verdict and, if applicable, the fallback assessment for design 07 (Cardano chain registration)