Decentralize Signer Registration - Feasibility
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- rust
Línea de trabajo
Comienza revisando la infraestructura DMQ existente y CIP-0137; después, inspecciona los traits SignerRegistrationPublisher y SignerRegistrationRoundOpener en la arquitectura de signer y aggregator. Modela los mecanismos propuestos de registro y equivocación bajo las condiciones de red y adversariales indicadas. Se considerará terminado cuando haya una especificación del protocolo, un modelo de amenazas, resultados de simulación si corresponde, un veredicto de viabilidad y una evaluación de la alternativa de fallback.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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:
- 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).
- Local record keeping: All signers and aggregators keep track of signer registrations received and how many times each registration was received.
- 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.
- 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.
- Authenticated messages: All messages on the P2P network are authenticated via KES signatures (natively supported by the Cardano DMQ protocol), enabling detection of equivocation.
- 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:
- 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?
- Threshold calibration: How should the repetition threshold and temporal attenuation parameters be calibrated relative to network size, epoch duration, and expected network reliability?
- Adversarial resilience: What fraction of adversarial signers can the protocol tolerate while maintaining liveness? What are the precise BFT assumptions?
- Equivocation proof protocol: Is the equivocation proof mechanism sufficient to handle all adversarial strategies (e.g., targeted equivocation to subsets of the network)?
- 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?
- 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?
- 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?
- 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/SignerRegistrationRoundOpenertraits) - Produce the feasibility verdict and, if applicable, the fallback assessment for design 07 (Cardano chain registration)
- Lenguaje dominante
- Rust
- Estrellas
- 155
- Forks
- 52
- Merge medio
- 2 d 17 h
- PR fusionados (30 d)
- 37
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de IntersectMBO/mithril
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
IntersectMBO/mithril#1605 · 2 comentarios ·
Los mantenedores suelen responder en 2 días
-
spike :satellite:
Dificultad 5/5 Más de una semana Aptitud para principiantes 10/100
IntersectMBO/mithril#3701 ·
Los mantenedores suelen responder en 2 días
-
Publish a DNSLink record of the immutable archives IPNS name in the Mithril networks DNS zonesPosiblemente ocupada @jpraynaud la tomó hace 2 días. Abiertofeature :rocket:
IntersectMBO/mithril#3700 · 1 asignado ·
Los mantenedores suelen responder en 2 días
-
feature :rocket:
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
IntersectMBO/mithril#3699 ·
Los mantenedores suelen responder en 2 días
-
feature :rocket:
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
IntersectMBO/mithril#3698 ·
Los mantenedores suelen responder en 2 días
Todos los issues de IntersectMBO/mithril
Issues similares
-
[Bug]: opencode_go chat route drops reasoning_effort (even 'none'), while the same endpoint honors it via custom_llm_provider=openaiPosiblemente ocupada @arvindkumar-ship-it la tomó hoy. Abiertollm translation
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
BerriAI/litellm#51871 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
comp-formats
Dificultad 2/5 Medio día Aptitud para principiantes 64/100
ClickHouse/ClickHouse#131694 ·
Los mantenedores suelen responder en 1 día
-
cli: `execCargoMetadata` decodes stdout per chunk, corrupting non-ASCII paths across pipe boundariesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
C-Bug S-Needs-Triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
bevyengine/bevy#26558 ·
Los mantenedores suelen responder en 2 días