IntersectMBO / IntersectMBO/mithril

Mithril based Oracle - Feasibility

Open
#2,725 0 comments 0 reactions 0 assignees View on GitHub
roadmap :compass:
Dominant language
Rust
Stars
154
Forks
51
Avg merge
1d 23h
Merged PRs (30d)
38

Description

## 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](https://cips.cardano.org/cip/CIP-0137#infrastructure-extra-operating-costs) (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?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.