1 of 12

Ouroboros Peras

Implementation Progress Update and Discussion

April 27, 2026

2 of 12

Agenda

2

  1. Generic voting committees + Peras instance
  2. ObjectDiffusion reintroduction + PerasCertDB rework
  3. Peras Testnet
  4. Consensus ↔ Ledger
  5. Discussion

3 of 12

Disclaimer

3

  • 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 and caught-up version of the protocol.

See here for more information:

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

  • Past demos (recordings, slides, etc.): https://tweag.github.io/cardano-website/

4 of 12

Generic voting committees +

Peras instance

Goals

  • Select a subset of voters from the SPOs
  • Allow Peras and Leios to reuse as much code as possible
  • Easily compare across different committee selection schemes

What we have so far

  • Generic voting committee API 🚀
  • wFA^LS and EveryoneVotes implementations ✅🔎
  • Initial BLS crypto backend for voting committees ✅
  • Concrete Peras instance ✅
    • BLS crypto
    • Concrete votes and certificates with serialization
    • Supports both wFA^LS and EveryoneVotes
  • Comprehensive test suite for all the components ✅

4

5 of 12

ObjectDiffusion reintroduction +

PerasCertDB rework

5

  • ObjectDiffusion is the common protocol used to diffuse certs and votes across the network�(based on a modified version of TxSubmission).�It spans both ouroboros-network and ouroboros-consensus codebases�
  • Initially merged in December 2025, but reverted because of a yet-unmerged dependency on ouroboros-network
  • The needed PR has been merged recently in ouroboros-network, so we were able to resume the efforts to update, review and merge the ObjectDiffusion code in ouroboros-consensus
  • This update effort also included a reworked PerasCertDB interface with a clearer STM vs IO interface (easier to understand which operation has in-memory effects VS on-disk effects)
  • The newly merged version in ouroboros-consensus instantiates ObjectDiffusion for both Cert Diffusion (plugged on PerasCertDB) and Vote Diffusion (plugged on PerasVoteDB)

(the december version only included a Cert diffusion instance)

We should be able to deploy ObjectDiffusion on the testnet very soon!

6 of 12

Peras Testnet

Goals

  • Environment to simulate real-world network
  • Generic enough tooling to be used across developing other cardano projects
  • Developer friendly - Low cognitive overhead for building and running

Testing Workflow

  • Spin up multiple nodes locally
  • Simulate controlled partition or latency in the network
  • Verify the results

6

7 of 12

Peras Testnet

What we have so far

  • Simulation of a network with induced latency
  • A clean UI to visualise and verify

Next steps: Visualising Peras

  • We want to partition the network to allow nodes to vote for different blocks.
  • We want to verify that all participants still follow the correct chain that is boosted.
  • The nodes may sometimes roll back to a shorter chain that is boosted

7

8 of 12

Peras Testnet

Try it out:

nix run github:tweag/cardano-peras#testnet

8

9 of 12

Consensus ↔ Ledger

9

  • We had a joint Consensus↔Ledger (and Leios!) meeting to understand where certain parts of the Peras implementation should live in (i.e. cardano-base, cardano-ledger, or ouroboros-consensus).

  • Our take: it’s much faster to develop as much as possible within Consensus and move things later (when preparing Peras for mainnet)

  • Consensus* is that this is OK for pre-alpha Peras, but for mainnet:
    • Expensive computations happening at epoch boundaries need to be done incrementally (Ledger has support for this)
    • Block body serialization/validation should ideally be handled by Ledger

[*] pun intended

10 of 12

Consensus ↔ Ledger

10

Peras certificates in blocks 🚧

    • We have extended Dijkstra block bodies with a placeholder for Peras certificates
    • We are extending these placeholders with opaque (bytestring) blobs (thanks Aleks!)
    • Ledger can fully encode/decode them, leaving (semantic) validation to Consensus

Stateful voting committee handles 🚧

    • Keep track of multiple voting committee compositions (last two epochs)
    • Dispatch operations to the correct one (depending on the election ID of the resource)
    • Recompute the current stake distribution “summary” at the beginning of each epoch
    • Provide a “realized” API for forging/verifying votes and certificates
      • No need to handle private keys manually when forging votes (similar to BlockForging)
      • No manual error handling (most errors should trigger disconnection or crashing)

11 of 12

Updated

roadmap

(link)

11

12 of 12

THANK YOU!