Ouroboros Peras

Implementation Progress Update and Discussion

November 2, 2026

Agenda

2

1. Implementation updates
2. Testnet prototype
3. Coming next
4. Discussion

​

Disclaimer

3

• Ouroboros Peras is a protocol that enables significantly faster settlement times under optimistic conditions

​

• At a fixed schedule, all eligible 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

​

• Unless explicitly stated, in these slides we refer exclusively to pre-alpha Peras:

https://tweag.github.io/cardano-website/projects/prs/documentation/overview/#pre-alpha-peras

​

• More resources: �https://github.com/tweag/cardano-peras#resources-on-peras�
• Past demos (recordings, slides, etc.): �https://tweag.github.io/cardano-website/

​

​

​

​

​

​

​

Peras design

4

• Received the Peras Voting Analysis report from ARC:
• Researchers provided their long-term recommendations regarding crypto and committee selection schemes
• Reinforced our understanding of historical certificates being explicitly needed

​

• Solidified a couple of points after consulting with the TSC:
• Peras will be delivered with BLS crypto with quorum threshold increased to ~80%
• wFA^LS space usage is fine (if Peras ships with wFA^LS)

​

• Killswitch plan:
• Signal-based switch to turn off/on Peras voting on a live node
• Emergency flag to be used at node startup to disable Peras mini protocol/threads/active components

​

Network layer

OD: protocol control and idleness

5

• Graceful termination: a bounded server wait returns control to the client
• Explicit idleness: the server signals when no object IDs are immediately available
• New Messages:
• MsgAwaitReply: server has no new IDs; client begins waiting
• MsgServerIdle: wait expires; returns control to client

​

Implementation details:�separate protocol states before and after MsgAwaitReply enforce legal message ordering.

Network layer

Validation-aware object downloading

• Preserve outstanding FIFO order: download only the leading sequence of validatable objects.
• Wait for validatable context: pause at the first too-new certificate; resume when validation window advances.
• Skip too old certificates: acknowledge old IDs without penalizing peers (we might advance while the object is in flight).

​

Implementation details:

Classify IDs against an STM snapshot of the local validation window added to the object pool writer.

6

Network layer

Certificate progress and Genesis State Machine (GSM) integration

​

• Publish progress per peer: retain the next outstanding round through download, validation, and ChainDB processing
• Confirm the server’s front: an empty outstanding FIFO alone does not establish CaughtUp; MsgAwaitReply does
• Adapt GSM: when Peras is enabled, GSM "caught-up" requires both ChainSync and certificate diffusion to be caught up

​

Implementation details:

Await ChainDB processing before advancing.

Votes do not participate in GSM detection.

7

Historical certificates storage

8

• Historical certificate DB implementation (PerasImmutableCertDB)
• Carefully handles disk operations together with in-memory indexing
• Recovers gracefully from file corruption and unplanned shutdown
• We have written many tests to document and ensure expected behavior
• First round of benchmarks seems promising
• Reading certificates is an order of magnitude faster than required for a syncing speed of 1000 blocks/s

​

Next steps:

• Add unifying glue between volatile and historical PerasCertDB to be served uniformly by ObjectDiffusion
• Persist (part of) the volatile PerasCertDB to reduce the possibility of missing a certificate
• Investigate the feasibility of checking the completeness of the certificate database

Ledger integration

9

• Implemented Peras protocol parameters:
• These control tunable aspects of Peras, impacting both performance and liveness vs. finality tradeoff
• These form a minimal set of tunable parameters from which the complete set is derived (in combination with other static configuration such as the activeSlotCoeff and securityParam)
• We later integrated these parameters into ouroboros-consensus and expanded them with the forecasting support needed to validate objects on a per-epoch basis

​

• Started migrating definitions needed by cardano-ledger to cardano-base:
• Peras votes and certificates, including maximum size checks and constants
• Currently waiting for review (Leios is taking most of the review bandwidth)

​

Consensus and Cardano Node

10

• Improved voting rules with perasBootstrapRound for start coordination/emergency recovering

​

• Currently working on the installation of Peras vote-forging credentials (joint responsibility between cardano-node and ouroboros-consensus)

​

• Fixed a couple of initialization bugs discovered during early testnet runs

​

• Added size limit computation to limit the number of transactions in a block when a certificate needs to be included

​

• Integration of Peras into Genesis:
• Adapted the GSM caught-up criterion w.r.t certificate diffusion
• Adapted the Genesis Density Disconnection (GDD) to account for Peras certificates

Testnet

11

• Bootstrapped a monorepository of Cardano packages to simplify building and testing feature integration
• Automated the validation of Peras properties based on traces
• Early versions of visualization tools

integrate

build

run

validate

Testnet: integrate

Repository: github.com/tweag/cardano-kosmos

​

Combines Cardano packages’ repositories using git subrepo

​

Integrates feature-branches from multiple cardano repositories:

​

• cardano-api
• cardano-cli
• cardano-ledger
• cardano-node
• ouroboros-consensus
• ouroboros-network

​

More can be added later if needed.

​

All checkouts are accessible from a single place.

Does not override Cardano poly-repository approach.

​

​

​

​

12

Testnet: build

1. Single top level cabal.project to control dependencies and packages
2. Usual cabal workflow
3. We are exploring the integration of Buck2 to reduce build times

​

13

buck2 build root//packages/cardano-node/cardano-node:cardano-node-exe

Build ID: 76a3bb50-7979-4e4e-b915-5dd92f886c7e

Phase Remaining

Analyzing targets 0/ 10

Executing actions 0/ 50

​

Details

11.4s exec time total

Finished 13 local

​

Command build elapsed 10.4s

Build ID: 76a3bb50-7979-4e4e-b915-5dd92f886c7e

BUILD SUCCEEDED

cabal build cardano-node�...�Preprocessing executable 'cardano-node' for cardano-node-11.1.1..

Building executable 'cardano-node' for cardano-node-11.1.1..

[3 of 3] Linking /home/evgenii/Code/tweag/cardano-kosmos/dist-newstyle/build/aarch64-linux/ghc-9.6.7/cardano-node-11.1.1/x/cardano-node/build/cardano-node/cardano-node [Library changed]

​

Executed in 22.48 secs

Testnet: run

1. ./scripts/run-peras-testnet.sh - script that wraps cardano-testnet, and handles initialization, key generation, stake redistribution, and running side tools
2. A simplified version of cardano-ignite suitable for fast local development:
1. gathers logs (victoria-logs)
2. provides metrics (victoria-metrics+grafana)
3. uses toxiproxy for network experiments.
3. Supports multiple test scenarios�

Next steps: looking forward to start using Envoy-proxy instead for more control.

​

14

Testnet: validate

15

We integrated dashboards from

cardano-ignite to validate the state of the testnet.

​

Next steps: planning to add Peras-specific visualizations.

Testnet: validate

16

• Simple validation script that perform high level check of the main Peras properties based on traces - fast way to validate and debug�

Next steps: use Agda model for conformance testing

Testnet: validate

Protocol visualisation tool

​

Shows Peras miniprotocols and components state:

• Voting rules
• Vote diffusion
• Certificate diffusion
• Timing information

17

Testnet: validate

​

18

Testnet: validate

​

19

Testnet: validate

Protocol visualisation tool

​

Shows Vote diffusion

20

Coming next

21

• Complete the syncing support for Peras, for nodes that are catching up with Genesis:
• Continue the changes to GDD/GSM
• Adapt the Limit on Eagerness (LoE) computation to Peras constraints
• Adapt the Limit of Patience (LoP) as well

​

• Finalize Ledger integration:
• Ledger will be able to refer to production types when extracting and validating Peras certificates stored in block bodies
• However, there are still some unresolved design choices regarding the updated validation interface

​

• Improve PerasEpochContextResolver with forecasting so that we can always validate all relevant certificates for both caught-up nodes and syncing nodes (c.f. Genesis window)

THANK YOU!