Mithril based Oracle - Feasibility

Abierto
  • ¿Algo no está bien?
#2,725 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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
blockchain, rust
Área
blockchain, cryptography

Línea de trabajo

Comience con el modelo de datos de Oracle y el pipeline de certificación; después, revise las secciones sobre la participación de los signers y la verificación de proofs on-chain. Use CIP-0137 como línea base para los costes de difusión de mensajes y compare el wrapping de Groth16 BLS12-381 con la verificación directa de Halo2. Se considerará terminado cuando haya un informe de viabilidad, modelos recomendados de verificación y de signers, una arquitectura de prototipo de alto nivel y una hoja de ruta de hitos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

roadmap :compass:

Why

We plan to evaluate the feasibility of leveraging the Mithril protocol as a decentralized Oracle for Cardano. The study will assess how Mithril can deliver verifiable, trustless data, identify integration challenges as well as operational costs and incentive considerations, and outline a roadmap toward a prototype for on-chain deployment.

Mithril's STM (Stake-based Threshold Multisignature) protocol already provides a data-agnostic certification mechanism: signers register with their stake, produce single signatures via a lottery, and an aggregate multi-signature is formed once the quorum is reached. This infrastructure can in principle be extended to certify arbitrary oracle data (e.g., price feeds, external chain state, off-chain computation results).

What

The feasibility study should produce:

  • A feasibility report covering all the areas described below.
  • A recommendation on the preferred on-chain verification approach (Groth16 wrapping vs. direct Halo2 verification).
  • A recommendation on the signer participation model (full signer set, opt-in subset, or adapted STM protocol).
  • A high-level architecture proposal for the oracle prototype.
  • An initial roadmap with milestones toward a working prototype.

How

Oracle data model and certification pipeline
  • Define what kinds of data the oracle would certify (price feeds, cross-chain state, off-chain computation results, etc.).
  • Evaluate how the oracle data sources are fetched, validated, and agreed upon by signers before signing (consensus on input data).
  • Assess the frequency and latency requirements for oracle updates versus the existing Mithril certification cadence.
Signer participation model

Study whether the oracle can operate with fewer signers producing the actual signatures. The current STM protocol requires a quorum k out of m lottery indices, with eligibility proportional to stake. For oracle use cases, it may not be practical or necessary to involve the full set of registered SPOs.

This area should evaluate:

  • Whether a sub-signer-registration mechanism could be introduced, where a subset of signers explicitly opts into oracle duties while the remaining signers either:
    • Endorse the resulting signatures (e.g., by co-signing an attestation of the oracle certificate), or
    • Are simply excluded from the oracle signing round without affecting the security guarantees.
  • Whether the STM protocol itself can be adapted to natively support sub-signer-registrations for specific use cases.
  • The security implications of operating with a smaller signer set: what are the minimum stake and quorum thresholds needed to maintain acceptable security guarantees for oracle data?
On-chain proof verification

Evaluate how the proofs created by the Mithril oracle would be consumed on-chain in Plutus smart contracts. Two main approaches should be studied:

  • Groth16 BLS12-381 proofs derived from existing recursive Halo2 SNARKs: Study whether a Groth16 proof on BLS12-381 can be generated from these recursive Halo2 SNARKs, producing a succinct proof that Plutus scripts can verify .
  • Direct verification of recursive Halo2 proofs on-chain: Assess the feasibility of verifying recursive Halo2 proofs directly within Plutus smart contracts. This requires evaluating the computational cost (execution units), the availability of the required primitives on-chain, and whether the proof sizes are acceptable for transaction limits.

The comparison between both approaches should cover proof size, verification cost (CPU and memory execution units), trust assumptions, and implementation complexity.

Operational costs and incentives
  • Evaluate the cost model for SPOs, taking into account that message diffusion is costly. CIP-0137 (Decentralized Message Queue) provides a detailed cost model for message diffusion on the DMQ network used to broadcast signer signatures and that should serve as a baseline for this analysis
  • Outline potential incentive mechanisms for signers to participate in oracle data certification, ensuring that the incentives adequately compensate for the operational costs identified above.
  • Assess the economic security model: what is the cost of corrupting oracle data relative to the stake backing it?
Lenguaje dominante
Rust
Estrellas
155
Forks
52
Merge medio
2 d 17 h
PR fusionados (30 d)
37

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de IntersectMBO/mithril

Todos los issues de IntersectMBO/mithril

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.