Research Overview

Resources

The IOR Peras research team and the IOG Peras Innovation team have put together a substantial amount of documentation that we encourage you to check out when getting started:

• Video on Peras by Sandro Coretti-Drayton (IOG researcher on Peras). Great overview of the abstract protocol. Also talks about pre-agreement in the “Avoiding the cooldown phase” part at the end, which is not part of pre-alpha Peras.

• Slides from the Peras workshop

• Cardano Problem Statement (CPS) on “Settlement Speed”, the objective of Peras

• Cardano Improvement Proposal (CIP) for Peras. This includes a formal Agda specification of the abstract protocol, as well as analyses of resource impact and certain adversarial scenarios.

• From the Peras R&D website

  • The FAQ
  • The simulator
  • The dashboard (preliminary settlement probabilities)
  • The technical reports (1&2)

Design document

The Peras design document is available in PDF format here.

You can also build it locally with Nix via:

nix build github:tweag/cardano-peras#design

Pre-alpha Peras

Please notice that, nless stated otherwise, this project covers “Pre-alpha Peras” as described below.

The trade-off in pre-alpha Peras

Pre-alpha Peras is characterized by a trade-off between the following two desiderata:

• Small latency until blocks can be boosted and hence benefit from faster settlement.

  Peras only enables improved settlement guarantees for a block if that block (or a descendant) is boosted due to a Peras certificate. One important Peras protocol parameter is the block selection offset L, aka perasBlockMinSlots. Honest nodes will only ever vote for blocks at the beginning of a Peras round that are least perasBlockMinSlots old. Therefore, for this purpose, a small value is desirable.

  For example, if perasBlockMinSlots = 300, then a block only even has a chance to benefit from a boost after 300 slots = 5 minutes, whereas for perasBlockMinSlots = 60, the block can already be boosted after a minute.

• Resilience against weak attackers trying to force Peras into a cooldown.

  When a Peras round is unsuccessful, i.e. did not result in a certificate, Peras enters a lengthy cooldown period (likely >1 day¹) during which honest nodes do not vote and therefore Peras is effectively disabled, returning to Praos temporarily.

  Strong attackers with at least 25% stake can trivially disable Peras for as long as they control this stake, which is by design: Peras is about improving settlement guarantees optimistically.

  However, in pre-alpha Peras, weaker adversaries (think <25% stake) can also disable Peras with a given probability, depending on their stake. This probability can be decreased by increasing the perasBlockMinSlots parameter.

Briefly: In pre-alpha Peras, small values for perasBlockMinSlots are desirable when there is no (or only an extremely weak) adversary, but they lead to higher probabilities that weak adversaries can force Peras into cooldown period, decreasing the benefits of Peras.

For a deployment of pre-alpha Peras, it is crucial to make an informed decision on the value of perasBlockMinSlots. This parameter can be subject to on-chain governance, so it is possible to change it after the fact. For example, it could be set to a relatively small value in the beginning (say 60 slots), but still be increased later given certain adversarial activity.

For preliminary calculations of concrete probabilities in this trade-off, see appendix A.1.2 in the Peras report, in particular figure A.1.

Pre-agreement

Pre-agreement is an enrichment to Peras enabling us to resolve the trade-off in the following way. In pre-alpha Peras, rounds can only either result in a boost for a block, or fail, in which case a cooldown is triggered. Pre-agreement enables a third possibility: A round does not boost a block, but it also does not trigger a cooldown. More specifically, weak adversaries (<25%) can not cause cooldowns anymore, except for a very small probability independent of perasBlockMinSlots.

Under the hood, pre-agreement consists of running an (iterated) binary Byzantine Agreement protocol, see https://www.youtube.com/watch?v=HRJzwoArqg4&t=1055s for an explanation.

The downside of pre-agreement is that it makes the protocol more complex, albeit in a confined way because it only affects what to vote for, and increases the bandwidth consumed by Peras even when there isn’t any attacker, potentially even requiring an extension of the round length (the details have not yet been analyzed, so no concrete numbers).

There is not yet any schedule for implementing pre-agreement.