Tweag Tests Latest Peras Code on Cardano Testnet
The team is adjusting testnet parameters, reviewing certificate storage and expanding ledger support for Cardano’s faster settlement protocol.
By SongMarketCap
Tweag has brought up an initial Cardano testnet with the latest Peras code enabled, according to its October 9 development report. The proposed consensus upgrade is designed to shorten the wait for high confidence that an ADA transaction will remain on the accepted chain.
Peras Voting Targets Faster Cardano Settlement
The first issues encountered on the testnet mainly required parameter adjustments to accommodate its faster pace. Developers also continued integrating Prometheus for operational monitoring and improving the test environment’s usability.
Ouroboros Peras adds voting to Cardano’s Praos consensus protocol. When votes for a block reach the required quorum, they form a certificate that increases the block’s weight in chain selection. This reduces the probability that the block and its predecessors will be rolled back.
For exchanges, blockchain bridges and partner chains, settlement confidence determines when a transfer can be recognized and used. Peras aims to provide that confidence sooner for transactions involving ADA and other Cardano assets. Its voting mechanism is specified in CIP-0140.
Cardano Ledger Adds Peras Support
On October 13, Cardano Ledger merged a change that supplies the consensus layer with Peras parameters needed for validation in the current epoch. The integration connects the software that maintains Cardano’s state and rules with the component responsible for selecting the accepted chain.
Developers also began work on updating protocol state at the start of each Peras voting round, independently of new block arrivals. This allows the implementation to follow the voting schedule between blocks.
The work remains part of protocol development. CIP-0140 retains its proposed status, and Tweag’s report gives no mainnet activation date.
Peras Certificate Storage Enters Review
Tweag reported that the minimum viable implementation of the historical certificate database is complete and undergoing internal review. A comprehensive test suite has been written, with updates needed to reflect recent code changes.
The proposed database preserves certificates once their referenced blocks become immutable in the node’s storage. At that point, the certificates no longer influence chain selection but remain available as historical consensus records. The associated implementation is still a draft pull request.
Its storage design includes integrity checks and quarantine handling for missing, incomplete or corrupted files. A node can identify the affected certificate records and request them from other peers, providing a recovery path when its local archive has gaps.