Ouroboros Peras

Implementation Progress Update and Discussion

May 25, 2026

Agenda

2

1. Differentiated BlockSupportsPeras instances (mocked and real)
2. Peras Testnet
3. Other implementation updates
4. Discussion

​

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/

​

​

​

​

​

​

​

Differentiated BlockSupportsPeras instance per blk

Goals

• Proper separation between mocked and real implementations
• Cover the ground needed for future evolutions (Cardano eras indexed by block type, same as BlockSupportsPeras)
• Ensure alignment with existing guidelines and best practices according to the Consensus team

​

What we have today

• Multiple separate implementations for all relevant block types in de codebase (mocked ones for tests, empty ones for older eras)
• Interface extended with the voting committee context needed to operate on votes and certificates in the real implementation (WIP)

​

​

​

In ouroboros-consensus we use the block type (blk) as a discriminator to allow multiple versions/implementations of components to cohabit in the codebase. The HFC may be used on top to allow transitioning and dispatching between these implementations at runtime.

​

​

​

4

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

nix run github:tweag/cardano-peras#testnet

​

5

Peras Testnet

​

Simulating Network Activity:

• Ensure a primary node in our network.
• Primary node injects unique votes into its vote database.

​

Evidence of Object Diffusion:

• We can verify the votes travel the network.
• Outbound activity on the primary node of sending object identifiers and the objects.
• Inbound activity of requesting objects from the neighbours .

​

Synthesis of Certificates:

• Every node independently creates certificates.
• Specific blocks are boosted because of these certificates.

​

nix run github:tweag/cardano-peras#testnet

​

6

Peras Testnet

​

Current Status

• Framework set up to create votes on demand.
• Observe behaviour of the node via the logs.
• Verified object diffusion via the logs.

​

Next steps

• Simulate real world network with latencies and partitions.
• Verify object diffusion and behaviour of Peras in the network simulations.
• Verify weighted chain selection.

​

nix run github:tweag/cardano-peras#testnet

​

7

Other implementation updates

8

• Addressed reviews and merged all the remaining PRs regarding generic voting committees (Peras 22.5, 23, 24, 25)
• Concrete vote and certificate implementation is under review (Peras 25.5 and 26)
• Currently working on the integration/plumbing between:
• Generic components (forall blk):
• PerasVoteDB
• PerasCertDB
• PerasVoting rules (and eventually Voting thread)
• Concrete components:
• PerasBLSCrypto, EveryoneVotes & WFALS committees
• PerasVote and PerasCert (version 1, tied to BLS)
• Extended stake distribution (derived from PraosState)
• We found an obscure discrepancy between the model and real implementation of the ChainDB regarding GC of Peras components (fix is currently under review #2029)

​

​

​

Updated

roadmap

(link)

9

THANK YOU!