Specify MinSig variant and clarify non-aggregation of eligibility proofs in specification.md #648
Conversation
Co-authored-by: Thomas Vellekoop <107037423+perturbing@users.noreply.github.com>
Co-authored-by: Thomas Vellekoop <107037423+perturbing@users.noreply.github.com>
ch1bo
left a comment
ch1bo
left a comment
There was a problem hiding this comment.
I love the level of detail in the design decisions and implementation subsections! This is exactly what I thought would be great to cover in this document.
Some higher-level / introductory content could be potentially dropped or moved to the CIP (e.g. leios voting in a nutshell) - see my comment there. Similarly, making plans and identifying steps to realize this is commendable, but IMO not the right place here. I'd suggest to use Github issues and the roadmap project for that?
All-in-all the cryptography section is coming together nicely and you are setting a great example. Good job!
| - A secret key ($sk$) is created to generate signatures for the corresponding signature scheme. | ||
| - The public key ($pk$) is securely derived from $sk$ and used to verify the corresponding signatures. | ||
| - A proof of possession ($PoP$) is generated for $sk$ to ensure key ownership. | ||
| > Note that keys are not rotated periodically, as forward security is not required for IBs, EBs, or votes. |
There was a problem hiding this comment.
There are no IBs in the current design.
This is also a very generic section and if you feel this level of detail is missing from the CIP, we should rather expand on it there. The Design document then should not need to re-hash the workflows over and over, but only provide further detail and rationale.
Should: be able to drop the "Leios voting in a nutshell" overview?
| - With MinPk, certificates grow to around **12.7 kB**, still within Praos limits but significantly heavier for bandwidth, storage, and diffusion—especially given the number of certificates the system will handle over time. | ||
| - Since Leios produces far more **signatures** (votes and eligibility proofs) than public keys, the overall cost is driven by signature size rather than key size. | ||
| In summary, the Leios cryptography design therefore **fixes MinSig as the BLS12-381 variant**. |
There was a problem hiding this comment.
FYI I had a comment about this section in the other PR
| In summary, the Leios cryptography design therefore **fixes MinSig as the BLS12-381 variant**. | ||
| ### Implementation Plan |
There was a problem hiding this comment.
| ### Implementation Plan | |
| ### Implementation |
It's not really a plan but how the concrete functionality is to be implemented in cardano-base (as the intro of the section says nicely)
| > | ||
| > TODO: Contribution from crypto team. | ||
| ### Roadmap |
There was a problem hiding this comment.
I'd rather not have this in the design document, but instead on the Github project. Delivery cycles are not really defined here either. Please create issues as you see fit to cover further steps.
Do you think differently?
This PR updates crypto-benchmarks.rs/Specification.md to align it with:
Summary of changes
This matches the performance rationale (smaller signature size, significantly smaller certificates)
@bwbush I’d appreciate your confirmation that:
Thank you!