CIP-???? | Ouroboros Peras - Faster Settlement #872
Conversation
CIP-0PRS/CIP-0PRS.lagda.md
Outdated
| * [CIP-001](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) guidelines | ||
|
|
||
| ## Abstract | ||
| <!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. --> |
There was a problem hiding this comment.
| <!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. --> | |
| <!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. --> |
Now that the content is in place here you can (and should, before editing really begins) remove the comment scaffolding from the template: both here & in other places in the document.
CIP-0PRS/CIP-0PRS.lagda.md
Outdated
| --- | ||
| Title: Peras - Faster Settlement on Cardano | ||
| CIP: ? | ||
| Category: Consensus |
There was a problem hiding this comment.
We don't have a Consensus category, but are there stakeholders & representatives that could give us one? It would be forward-looking to add it, and especially useful if there are more CIPs coming from your team... but first this category would need to be "enlisted" through dedicated industry contacts as described for the currently enlisted categories here {Ledger, Plutus, Catalyst}:
- https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#categories
- https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#project-enlisting
If you think Consensus meets the criteria for enlistment (based on commitment to reviews & projects following the CIP process) then I would be happy to have it. We haven't enlisted any new categories since @KtorZ was an active editor but if you're interested we'll reciprocate as best we can (cc @Ryun1 @Crypto2099).
There was a problem hiding this comment.
@rphair, My understanding is that a separate CIP will create a "Consensus" category. We discussed this at a recent Consensus Working Group meeting.
There was a problem hiding this comment.
@bwbush it's good to hear that as a criteria, since then likewise the first authors of Consensus CIPs would be the "enlisters" and effectively volunteering for document review and assessments of acceptance & implementation plans. cc @abailly-iohk
This is the best strategy I can think of to keep the CIP process decentralised with respect to supporting companies. As this CIP moves forward through initial review I'll add Consensus to the official categories in CIP-0001. cc @Ryun1 @Crypto2099
There was a problem hiding this comment.
We're working on a CIP to enrol Consensus in the CIP mechanism. Our goal is to complete it during this quarter. See this issue.
CIP-0PRS/CIP-0PRS.lagda.md
Outdated
| ### Specification of certificates | ||
|
|
||
| > [!CAUTION] | ||
| > We need to commit solely to ALBA or to Mirthril, and edit this section accordingly. | ||
|
|
||
| #### Mithril certificates |
There was a problem hiding this comment.
I noticed text here is currently duplicated with #870 (cc @abailly-iohk - we understand they're both only Draft & this is only to assure we have properly distinct documents when ready for review: https://github.com/cardano-scaling/CIPs/blob/alba/CIP-0XXX/README.md#certificates
Co-authored-by: Robert Phair <rphair@cosd.com>
Co-authored-by: Robert Phair <rphair@cosd.com>
CIP-0PRS/CIP-0PRS.lagda.md
Outdated
|
|
||
| #### Network costs | ||
|
|
||
|  |
There was a problem hiding this comment.
The link returns 401 Authorization Required
There was a problem hiding this comment.
Thanks. We're in the process of migrating the diagrams directly into the folder for this CIP.
There was a problem hiding this comment.
@bwbush we can't keep a code repository within a CIP or use it as a build source, according to precedent and pending an explicit statement that will be added to CIP-0001 soon (last time it was confirmed: recently with #848 (review)). The convention would be for the .agda files & folder to be kept in an external repository which is linked from this CIP. 🙏
Thanks for the information. I'll consult with my colleagues and get back to you regarding this. |
CIP-0PRS/README.lagda.md
Outdated
|
|
||
| #### CPU | ||
|
|
||
| The [Peras Technical Report #2](https://peras.cardano-scaling.org/docs/reports/tech-report-2#votes--certificates) provides some models and benchmarks for votes generation, votes verification, certificates proving and certificates verification, and votes diffusion. Those benchmarks are based on efficient sortition-based voting and ALBAs certificate, and demonstrate the impact of Peras on computational resources for a node will be minimal. Moreover, the most recent version of the algorithm detailed in this report is designed in such a way the voting process runs in parallel with block production and diffusion and therefore is not on this critical path. For ALBA certificates, assuming 1000 votes, a honest to faulty ratio of 80/20, and security parameter $λ=128$, one has the following typical measurements. |
There was a problem hiding this comment.
Could we clarify a bit more the details of the parameters of Alba (as described in the original paper) in order to obtain the certificate size of 47Kb. After reading the report above, I am having some difficulty mapping the parameters from the report to the parameters of the paper?
Additionally, the estimated size of 47Kb is a bit unclear to me - we talk about honest / faulty ratio of 80/20 and (what seems to be assumed) is that
There was a problem hiding this comment.
The 47kB value might have come from an earlier version of ALBA prototype in Haskell, the latest value I computed (git hash 08cb09accf47093f53cf55e9b344f15cc9a3a408) gives me
% cabal run alba -- prove --len 710
Generating random items
Generating proof Options {size = 100, len = 710, params = Params {λ_sec = 128, λ_rel = 128, n_p = 80, n_f = 20}, input = Nothing, output = "proof.alba"}
Written proof to 'proof.alba' (50278 bytes, 0 retries)
The parameters 80/20 used the computation came from my misunderstanding of what's actually guaranteed by ALBA certificates as outlined in this discussion and as noted in one of the comments, this needs to be fixed to account for more serious assessment of security implication of ALBA parameters on Peras.
This is the purpose of cardano-scaling/alba#22 and the discussion we've had on Friday. This CIP and the report will be corrected to tone down the enthusiasm and expectations around ALBA as it's perfectly possible we realise these are not suitable for Peras after all.
Peras formal spec update
rphair
added
State: Unconfirmed
|
@bwbush @abailly-iohk - applying freshly created label
Category: Consensus
I've marked this |
There was a problem hiding this comment.
Compliments on how well this CIP is written, it dissects a complex design into readable sections and the motivation of the CIP sets the perfect stage to understand the context of it all. It was a long read, but I learned a ton about Peras, thank you 👍
In general, I think this CIP would benefit from more structure due to its size, as is done in CIP-1694. Perhaps the addition of a table of contents for faster navigation and an occasional collapsed section (for example the Agda spec section), would be good.
| , transaction_witness_sets : [* transaction_witness_set] | ||
| , auxiliary_data_set : {* transaction_index => auxiliary_data } | ||
| , invalid_transactions : [* transaction_index ] | ||
| + , ? peras_cert : alba_certificate |
There was a problem hiding this comment.
The occasional addition of a Peras certificate with size of the order of the max block size will impact the diffusion of these blocks. The section on resource requirements focuses on localized factors, what about the emergent global impact?
I can imagine that slot leaders that produce these blocks, might diffuse them worse, will this create slot battles?
Also, some Dapps would like to see the max block size increase, the addition of Peras might limit this. Not sure what statement can be made about this fact, but it might be worth adding a section on this balance for completeness?
There was a problem hiding this comment.
The idea was that the peras certificate would be significantly smaller than the block size so that block producers would fill in the remaining bytes and just propagate the block normally, so there should not be an impact on block diffusion, only on tx inclusion in case this happens while the mempools are congested.
Note that inclusion of certificates in blocks will be an extremely rare event. In the worst case, assuming nodes immediately enter cooldown when they are back from it, this means 1 Peras certificate roughly every 3000 blocks. In normal operations, this could be much rarer as we expect quorum will be reached on every round.
| In no way does Peras weaken any of the security guarantees provided by Praos or Genesis. Under strongly adversarial conditions, where an adversary can trigger a Peras voting cool-down period, the protocol in essence reverts to the Praos (or Genesis) protocol, but for a duration somewhat longer than the Praos security parameter. Otherwise, settlement occurs at the blocks that Peras voting has boosted. The Peras protocol parameters can be tuned to adjust the settlement time or the non-settlement probabilities. Some stakeholder use cases might prefer shorter settlement times but with a higher probability of retries, or vice versa. | ||
|
|
||
|
|
||
| ### Resource Requirements |
There was a problem hiding this comment.
What is the risk of stake not participating in this protocol? I can imagine that the below additional cost might not be welcome to all SPO's, especially as there is no incentive to run this.
So, if it is the case that SPO's can opt out for running this protocol (not sure how this will work), how will the security analysis move? Is this to be considered non-voting and thus adversarial stake? If so, how do we prevent this?
There was a problem hiding this comment.
Regarding incentives, can block producers use Alba to get a probability on whether a certain KES key (and thus SPO) contributed to the Peras protocol in past rounds by viewing their local votes? If so, can we use this measure in the reward calculation at the end of each epoch?
There was a problem hiding this comment.
It does not seem to us the resources requirements for Peras would incur significant additional costs to SPOs, but of course this should be assessed more carefully. We could imagine some specific incentive scheme to reward participation to Peras but the situation here is different than with Mithril: Peras changes the consensus and therefore has to be part of the core node operations.
That said, it's possible to start rolling out Peras as a sidecar and make blocks certificates informational, e.g something anyone connected to the network would observe and decide whether or not it's relevant. If you observe that 75% of nodes running Peras endorsed a specific block, even though this is not baked in the consensus you can already assume this block has a much stronger likelihood of not being rolledback.
ALBA certificates sample the votes' set so we could not use that to assess whether or not a particular SPO participated in Peras.
There was a problem hiding this comment.
To reply specifically to one of your questions: if consensus switches to weight-based chain selection, there's not opt-out from Peras and it must be rolled out to every node.
There was a problem hiding this comment.
To reply specifically to one of your questions: if consensus switches to weight-based chain selection, there's not opt-out from Peras and it must be rolled out to every node.
Hmmm, but the pessimistic case of Peras is Praos, so to opt out one “simply” forces the node in the pessimistic case? For example, by filtering messages the node receives?
There was a problem hiding this comment.
I don't understand what you mean, but if you're saying a node can refuse to "play the game" honestly then sure, that's a possibility and the reason why there's a quorum and we need security proofs to understand the impact of such behaviour on the system. Or are you saying something else?
|
A high level description published recently that may be of help in review: https://iohk.io/en/blog/posts/2024/10/14/ouroboros-peras-the-next-step-in-the-journey-of-cardano-s-protocol-1/ |
We propose Peras, an enhancement to the Ouroboros Praos protocol that introduces a voting layer for optimistic fast settlement.
Peras, or more precisely Ouroboros Peras, is an extension of Ouroboros Praos that addresses one of the known issues of blockchains based on Nakamoto-style consensus, namely settlement time. Peras achieves that goal while being self-healing, preserving the security of Praos, and being light on resources.
(rendered proposal)