Ouroboros Peras

Implementation Progress Demo and Discussion

September 29, 2025

Disclaimer

2

• Ouroboros Peras is a protocol that enables significantly faster settlement times under optimistic conditions
• At a fixed schedule, all pools vote for a recent block.
• If sufficiently many pools vote for the same block, this block receives a boost, making it unlikely to be rolled back
• Otherwise, the system enters a cooldown period, during which no voting takes place.
• More resources: https://github.com/tweag/cardano-peras#resources-on-peras�
• In these slides, “Peras” refers to the pre-alpha version of the protocol.

See here for more information:

https://github.com/tweag/cardano-peras/blob/main/docs/pre-alpha.md

​

Agenda

3

1. Overview of the Peras workstream and roadmap

​

• Demo of weighted chain selection and related features

​

• Discussion of vote/certificate cryptography interactions with Leios/Mithril

Peras cardano-node implementation workstream

4

• Based on top of work by IO Research and the IOG Peras Innovation team
• Tweag produced a design and architecture document at the beginning of this year as part of an SoW for the Technical Steering Committee.
• Tweag implementation of Peras for caught-up nodes funded via a treasury withdrawal (proposal text) voted for by the community (together with other projects)
• Collaborating with IOR and IOG (team augmentation, third party assurer)
• Scheduled to last until the end of May 2026, with a potential continuation for syncing via Ouroboros Genesis.

​

​

​

​

Development model

5

• Repository with assorted material: https://github.com/tweag/cardano-peras
• We work on branches targeting the upstream Haskell repositories, and regularly submit our changes for review by the respective IOG team in appropriate chunks
• Everything is gated behind an explicit “Peras” feature flag (also see the discussion from the corresponding IOG strategy meeting)
• Eventually, once there is general agreement that Peras should be enabled at a specific hard fork, the feature flag will be removed

​

Roadmap

6

• “Testnet” roadmap:
1. Minimal Testnet without Voting
2. Testnet with Votes
3. Testnet supporting caught-up Peras
• Parameterization dashboard��Detailed overview of the relation between protocol parameters and settlement probabilities, cooldowns, etc.
• Extensive tests, ideally implementation-agnostic��Has overlap with our funded “Consensus Conformance Testing” proposal

Demo time

7

• Minimal testnet showcasing:
• Weighted chain selection
• Weight-based immutability criterion
• Certificate diffusion
• Three nodes, complete graph topology, 500ms latency

​

To reproduce:

nix run github:tweag/cardano-peras#demo

​

​

​

​

8

It is now possible to switch to a shorter�(but heavier) chain

9

​

​

Boosting a block�⇏ �switching to its fork

​

​

10

​

​

The length of a chain�contributes to its�total weight

​

​

11

​

​

Boosting a block�behind the immutable anchor has no effect�on chain selection

​

​

12

Chain weight affects (shortens) the current volatile suffix

Definition of immutable tip of the current selection:�Praos: most recent block buried under k blocks�Peras: most recent block buried under at least k weight

Looking ahead

13

Next milestones (~2 months):

• Testnet with Votes
• Vote diffusion and voting logic
• Certificates in block bodies (to coordinate the end of a cooldown)
• Initial parameterization dashboard
• Settlement times outside of cooldown phases
• Probability and length of cooldown phases

​

​

Votes and certificates, near term

14

• Need to certify a 75% quorum per round
• A vote contains:
• Payload: round number and block point to vote for
• Pool identifier (integer or hash)
• Signature on the payload
• Potentially: Eligibility proof (VRF)
• A certificate contains:
• Payload: round number and block point to boost
• Representation of the set of voting pools (accountability)
• Multisignature
• Potentially: Eligibility proofs
• Basic shape also works for Leios and Mithril, just with a different threshold and payload

​

More information: Appendix B in our design document

Votes and certificates, near term

15

• First ingredient: multisignature scheme
• BLS: widely deployed, but not forward secure (without frequent re-registration/big public keys)
• Pixel: not widely deployed, less efficient, but forward secure
• Use Proofs of Possession
• Second ingredient: committee selection scheme
• Fait Accompli schemes make use of the uneven distribution of stake
• Idea: Allocate committee seats deterministically to the largest stake pools
• wFA^IID:
• No eligibility proofs, so very small certificates (<1kB)
• Somewhat worse resistance against adaptive adversaries and grinding attacks (but only for non-deterministically-assigned seats)
• wFA^LS:
• Needs eligibility proofs, so larger certificates (~8-9kB) and slower to validate
• Doesn’t have the downsides of wFA^IID
• There is some ongoing research on even better schemes

More information: Appendix B in our design document and this issue

Votes and certificates, near term

16

Implementation/next steps:

• Multisignature:
• BLS signature bindings via blst already WIP
• For Pixel, there is an audited implementation, but it still needs work (eg mlocking)
• Potentially, Peras can get by without forward secrecy, but this is not yet clear/requires research input
• Committee selection:
• Product(?) question: Can we use wFA^IID instead of wFA^LS?
• Parameter selection (dynamic parameters?)
• Brian Bush wrote a benchmark implementation for wFA^LS for Leios
• Production implementation needs to be specified/benchmarked/audited
• CIP? Prior work: https://github.com/cardano-foundation/CIPs/pull/870
• Potential tweaks to simplify validating certificates on-chain? (example use case)

More information: Appendix B in our design document and this issue

Votes and certificates, mid/long term

17

Long-term, certificates could be further optimized:

• SNARKify everything
• Aggregate eligibility proofs (MUSEN, Mithril/Bulletproofs, Jackpot)
• Efficient merging of partial certificates (ethresear.ch, KZH-Fold)�(In contrast, merging multisignature-based certificates requires tracking voter multiplicities in general)�Could enable more efficient vote diffusion
• Fully deterministic committee selection using weight reduction? (A, B)

​

More information: Appendix B in our design document and this issue

THANK YOU!