CPS-???? | Quantum secure Cardano settlement layer

[perturbing]

This CPS discusses the technical details of making the Cardano layer one settlement layer quantum secure. The scope of this work is limited by the consensus side of the PQC discussion.

Rendered version

[hjeljeli32]

Thanks @perturbing for kicking this off 🙏

I added a couple of comments on the Problem and Goals sections to try to structure the discussion around threat model and priorities.

For the next steps, I think it could be interesting to expand on:

• Use cases (especially from a consensus / protocol perspective)
• You and Gamze have a very strong view on the use cases and system aspects.

Of course, very open to feedback on my suggestions above 👍

[hjeljeli32]

We can structure the Problem section in two parts:

1. Context (why this matters now)
2. Threat model / priority analysis (what breaks first in Cardano)

Context (proposal)

• Quantum hardware continues to progress
• More importantly, resource estimates for attacks are dropping (e.g. recent ECC estimates)
  → This suggests that the threshold for practical attacks may arrive earlier than previously expected

Threat Model / Priority Analysis (proposal)

• Signature schemes (root of trust)
  • Used for transactions, stake pool cold keys, block production
  • If broken → adversary can forge transactions and blocks
  • Public keys are exposed on-chain, making long-lived keys potential targets
    → highest priority
• Verifiable Random Function (VRF)
  • Used for leader election / randomness
  • If broken → adversary can bias or control slot leadership
    → critical for consensus security
• Delegation / stake authority
  • Governs who is allowed to produce blocks (stake pools, delegation certificates)
  • If broken → adversary can assign stake or control block producers
    → system-wide failure

Do you think this makes sense?

[hjeljeli32]

Goals (proposal)

Following the threat model above, we could define the following high-level goals:

• Ensure post-quantum security of the root of trust

  • Cover signature schemes, VRF, and delegation mechanisms
  • Favor mature, well-studied, and standardized constructions (e.g. NIST PQC)

• Optimize for practical constraints (latency, bandwidth, storage)

  • Carefully evaluate trade-offs between signature size, public key size, and verification cost
  • Prefer schemes that minimize impact on block size, propagation, and validation

• Maintain acceptable network performance

  • Ensure block production, propagation, and validation remain within acceptable limits
  • Allow for potential adaptation of protocol parameters if needed

• Support crypto-agility

  • Enable smooth and incremental migration of cryptographic primitives
  • Minimize disruption to existing infrastructure and avoid costly future migrations

Do you think it makes sense?