Decentralize Signer Registration - Feasibility

Start by reviewing the existing DMQ infrastructure and CIP-0137, then inspect the SignerRegistrationPublisher and SignerRegistrationRoundOpener traits in the signer and aggregator architecture. Model the proposed registration and equivocation mechanisms under the listed network and adversarial conditions. Done means a protocol specification, threat model, simulation results if applicable, feasibility verdict, and fallback assessment.

Why

The Mithril network currently relies on a centralized leader aggregator for signer registration (design 02: Centralized registration and broadcast, implemented in #2238). While the signature diffusion has been decentralized thanks to the DMQ protocol (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 (#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).
2. Local record keeping: All signers and aggregators keep track of signer registrations received and how many times each registration was received.
3. 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.
4. 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.
5. Authenticated messages: All messages on the P2P network are authenticated via KES signatures (natively supported by the Cardano DMQ protocol), enabling detection of equivocation.
6. 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?
2. Threshold calibration: How should the repetition threshold and temporal attenuation parameters be calibrated relative to network size, epoch duration, and expected network reliability?
3. Adversarial resilience: What fraction of adversarial signers can the protocol tolerate while maintaining liveness? What are the precise BFT assumptions?
4. Equivocation proof protocol: Is the equivocation proof mechanism sufficient to handle all adversarial strategies (e.g., targeted equivocation to subsets of the network)?
5. 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?
6. 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?
7. 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?
8. 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 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)