From b5d84b7df4e75cd231a696a6e1c06b26124439a2 Mon Sep 17 00:00:00 2001 From: Hamza Jeljeli Date: Mon, 1 Dec 2025 11:26:39 +0900 Subject: [PATCH 1/6] Leios design: document choice of BLS minSIG variant --- docs/leios-design/README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/docs/leios-design/README.md b/docs/leios-design/README.md index b2fd81b41..3fbceeeec 100644 --- a/docs/leios-design/README.md +++ b/docs/leios-design/README.md @@ -8,6 +8,8 @@ author: - Thomas Vellekoop - Michael Karg - Martin Kourim + - Gamze Orhon Kılıç + - Hamza Jeljeli --- # Introduction @@ -702,6 +704,19 @@ The BLS voting mechanism relies on a pairing-based signature scheme defined over This approach is advantageous because it enables the aggregation of public keys and signatures, allowing large groups of participants to collectively signal approval through a single compact artifact. Beyond Leios, the BLS mechanism is also relevant to other Cardano subsystems; Mithril already employs BLS-based aggregation, and Peras is expected to adopt a similar approach in future implementations. +#### Choice of BLS Variant + +BLS12-381 signatures can be instantiated in two variants that differ only in which group is used for public keys and which is used for signatures. Both variants are equivalent in security and share the same API surface; they differ only in the size of the encoded artifacts: +- **MinPk variant**: public keys are 48 bytes, signatures are 96 bytes. +- **MinSig variant**: signatures are 48 bytes, public keys are 96 bytes. +This creates a straightforward trade-off: either public keys are smaller (MinPk) or signatures are smaller (MinSig). + +For Leios, this choice affects several components: +- **Certificate size** — Certificates contain one aggregated signature but may include multiple public keys (e.g., for non-persistent voters). MinPk yields smaller certificates. +- **Network load** — Across the protocol, significantly more signatures than public keys will be produced, propagated, and verified. MinSig reduces total bandwidth and memory usage. + +Given the expected high volume of signatures flowing through the Leios voting and certification path, the current architectural expectation is that **MinSig** will be the preferred variant. This preference remains subject to final review as part of the broader Leios integration discussions. + ### Implementation Plan To implement the linear Leios design, efficient BLS signature functionality is essential for achieving fast and compact certificate generation. From 16be43daf8c588956279164d3e7ea6503577efa7 Mon Sep 17 00:00:00 2001 From: Hamza Jeljeli <94505011+hjeljeli32@users.noreply.github.com> Date: Tue, 2 Dec 2025 12:11:31 +0900 Subject: [PATCH 2/6] Update docs/leios-design/README.md Co-authored-by: Thomas Vellekoop <107037423+perturbing@users.noreply.github.com> --- docs/leios-design/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/leios-design/README.md b/docs/leios-design/README.md index 3fbceeeec..bedb41509 100644 --- a/docs/leios-design/README.md +++ b/docs/leios-design/README.md @@ -707,7 +707,7 @@ Beyond Leios, the BLS mechanism is also relevant to other Cardano subsystems; Mi #### Choice of BLS Variant BLS12-381 signatures can be instantiated in two variants that differ only in which group is used for public keys and which is used for signatures. Both variants are equivalent in security and share the same API surface; they differ only in the size of the encoded artifacts: -- **MinPk variant**: public keys are 48 bytes, signatures are 96 bytes. +- **MinPk variant**: public keys are 48 bytes, signatures are 96 bytes, and a proof of possesion is 2 times 96 bytes. - **MinSig variant**: signatures are 48 bytes, public keys are 96 bytes. This creates a straightforward trade-off: either public keys are smaller (MinPk) or signatures are smaller (MinSig). From e28a5d3be2f1bf82caa9732daac3a778412eb792 Mon Sep 17 00:00:00 2001 From: Hamza Jeljeli <94505011+hjeljeli32@users.noreply.github.com> Date: Tue, 2 Dec 2025 12:12:11 +0900 Subject: [PATCH 3/6] Update docs/leios-design/README.md Co-authored-by: Thomas Vellekoop <107037423+perturbing@users.noreply.github.com> --- docs/leios-design/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/leios-design/README.md b/docs/leios-design/README.md index bedb41509..7513c8b40 100644 --- a/docs/leios-design/README.md +++ b/docs/leios-design/README.md @@ -708,7 +708,7 @@ Beyond Leios, the BLS mechanism is also relevant to other Cardano subsystems; Mi BLS12-381 signatures can be instantiated in two variants that differ only in which group is used for public keys and which is used for signatures. Both variants are equivalent in security and share the same API surface; they differ only in the size of the encoded artifacts: - **MinPk variant**: public keys are 48 bytes, signatures are 96 bytes, and a proof of possesion is 2 times 96 bytes. -- **MinSig variant**: signatures are 48 bytes, public keys are 96 bytes. +- **MinSig variant**: signatures are 48 bytes, public keys are 96 bytes, and a proof of possesion is 2 times 48 bytes. This creates a straightforward trade-off: either public keys are smaller (MinPk) or signatures are smaller (MinSig). For Leios, this choice affects several components: From 6ee7170b245c96455f18aad7aadee7017f315076 Mon Sep 17 00:00:00 2001 From: Hamza Jeljeli <94505011+hjeljeli32@users.noreply.github.com> Date: Tue, 2 Dec 2025 12:32:40 +0900 Subject: [PATCH 4/6] Clarify the impact of PoP size on bandwidth and and storage --- docs/leios-design/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/leios-design/README.md b/docs/leios-design/README.md index 7513c8b40..2fa615a98 100644 --- a/docs/leios-design/README.md +++ b/docs/leios-design/README.md @@ -709,7 +709,7 @@ Beyond Leios, the BLS mechanism is also relevant to other Cardano subsystems; Mi BLS12-381 signatures can be instantiated in two variants that differ only in which group is used for public keys and which is used for signatures. Both variants are equivalent in security and share the same API surface; they differ only in the size of the encoded artifacts: - **MinPk variant**: public keys are 48 bytes, signatures are 96 bytes, and a proof of possesion is 2 times 96 bytes. - **MinSig variant**: signatures are 48 bytes, public keys are 96 bytes, and a proof of possesion is 2 times 48 bytes. -This creates a straightforward trade-off: either public keys are smaller (MinPk) or signatures are smaller (MinSig). +This creates a straightforward trade-off: either public keys are smaller (MinPk) or signatures are smaller (MinSig). Note that proofs of possession are only used at key registration time (once per stake pool key), so their size has negligible impact on steady-state bandwidth, storage, or verification costs. They therefore do not weigh into the choice between the two variants. For Leios, this choice affects several components: - **Certificate size** — Certificates contain one aggregated signature but may include multiple public keys (e.g., for non-persistent voters). MinPk yields smaller certificates. From 2bf9842f8a90d2503e32c1591c3b8ab608f5ed9f Mon Sep 17 00:00:00 2001 From: Hamza Jeljeli Date: Thu, 4 Dec 2025 12:38:29 +0900 Subject: [PATCH 5/6] Leios design: quantify MinPK vs MinSig trade-off --- docs/leios-design/README.md | 56 +++++++++++++++++++++++++++++++++---- 1 file changed, 51 insertions(+), 5 deletions(-) diff --git a/docs/leios-design/README.md b/docs/leios-design/README.md index 2fa615a98..7ddc15dcf 100644 --- a/docs/leios-design/README.md +++ b/docs/leios-design/README.md @@ -709,13 +709,59 @@ Beyond Leios, the BLS mechanism is also relevant to other Cardano subsystems; Mi BLS12-381 signatures can be instantiated in two variants that differ only in which group is used for public keys and which is used for signatures. Both variants are equivalent in security and share the same API surface; they differ only in the size of the encoded artifacts: - **MinPk variant**: public keys are 48 bytes, signatures are 96 bytes, and a proof of possesion is 2 times 96 bytes. - **MinSig variant**: signatures are 48 bytes, public keys are 96 bytes, and a proof of possesion is 2 times 48 bytes. -This creates a straightforward trade-off: either public keys are smaller (MinPk) or signatures are smaller (MinSig). Note that proofs of possession are only used at key registration time (once per stake pool key), so their size has negligible impact on steady-state bandwidth, storage, or verification costs. They therefore do not weigh into the choice between the two variants. +This creates a straightforward trade-off: either public keys are smaller (MinPk) or signatures are smaller (MinSig). -For Leios, this choice affects several components: -- **Certificate size** — Certificates contain one aggregated signature but may include multiple public keys (e.g., for non-persistent voters). MinPk yields smaller certificates. -- **Network load** — Across the protocol, significantly more signatures than public keys will be produced, propagated, and verified. MinSig reduces total bandwidth and memory usage. +For Leios, this choice affects the size of voting certificates, which in turn impacts bandwidth, storage, and block propagation. Note that proofs of possession are only used at key registration time, so their size has negligible impact on steady-state bandwidth, storage, or verification costs. They therefore do not weigh into the choice between the two variants. -Given the expected high volume of signatures flowing through the Leios voting and certification path, the current architectural expectation is that **MinSig** will be the preferred variant. This preference remains subject to final review as part of the broader Leios integration discussions. +The certificate scheme we use follows the one defined in CIP-0164 together with the more detailed description in +[Specification.md](https://github.com/input-output-hk/ouroboros-leios/blob/main/crypto-benchmarks.rs/Specification.md) (section *“BLS certificate scheme”*). At a high level, a certificate records: + +- the **election identifier** (8 bytes) and **EB hash** (32 bytes), +- a **bitset of persistent voters**, of size \(m / 8\) bytes, +- for each **non-persistent voter**: + - the Pool ID (28 bytes), + - its **eligibility proof**, an individual BLS signature of size S_sig, +- one **aggregate vote signature** on the EB (a single BLS signature of size S_sig). + +A key point is that **eligibility proofs remain non-aggregated**: the block producer must be able to verify each proof individually against the Fait-Accompli sortition condition. Only the vote signatures on the EB are aggregated. + +Under these assumptions, the total certificate size (ignoring small CBOR overhead) is + +\[ +certificate_bytes = 40 + 2 * S_sig + m / 8 + (28 + S_sig) * (n - m). +\] + +Current sortition simulations tune the number of non-persistent seats to roughly 100 across the committee sizes we care about. Concretely, we assume: +- for n = 500, we have m ≈ 400 persistent voters, +- for n = 1000, we have m ≈ 900 persistent voters, + +so in both cases (n - m) ≈ 100 non-persistent voters, and the term (28 + S_sig) * (n-m) dominates. + +**Quantitative comparison** + +For a 1000-seat committee with m ≈ 900 persistent voters: + +- **MinSig**: + + \[ certificate_bytes = 40 + 2 * 48 + 113 + (28 + 48) * 100 = 136 + 113 + 7600 = 7849 bytes. + \] + +- **MinPk**: + + \[ certificate_bytes = 40 + 2 * 96 + 113 + (28 + 96) * 100 = 232 + 113 + 12400 = 12745 bytes. + \] + +So, for n = 1000 and \(n - m ≈ 100\), MinPk certificates are about 4.9 kB larger, which is roughly a **60% increase** over MinSig. + +We also evaluated the 500-seat case. The percentage increase from MinSig to MinPk is essentially the same (~60%). + +**Interpretation for Leios** + +- With MinSig, certificates stay comfortably below **8 kB** and keeps certificate propagation and storage lightweight. +- 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**. ### Implementation Plan From 1d3ea49ed534c58ffd4bf81940bb4dfd1673ed5d Mon Sep 17 00:00:00 2001 From: Hamza Jeljeli Date: Thu, 4 Dec 2025 15:23:45 +0900 Subject: [PATCH 6/6] Specification.md: clarify choice of MinSig variant for BLS --- crypto-benchmarks.rs/Specification.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/crypto-benchmarks.rs/Specification.md b/crypto-benchmarks.rs/Specification.md index 5825e220f..8b1cd17cd 100644 --- a/crypto-benchmarks.rs/Specification.md +++ b/crypto-benchmarks.rs/Specification.md @@ -19,8 +19,16 @@ Ideally, of course, the same voting and certificate infrastructure would be used ## BLS certificate scheme + Consider the following voting and certificate scheme for Leios: +### BLS instantiation for Leios + +Leios adopts the **BLS12‑381 MinSig variant**, where signatures are 48 bytes +and public keys are 96 bytes. This choice reduces certificate size because +eligibility proofs are non‑aggregatable and must be included one‑by‑one in +the certificate for non‑persistent voters. + 1. Stake pools register BLS keys for use in voting and prove possession of those keys. 2. Nodes verify the proofs of possession of the keys they receive. 3. Those keys are not replaced periodically because forward security is not needed for IBs, EBs, or votes. (If forward security were required, then the Pixel family of algorithms is a good candidate because of its succinctness.) @@ -98,7 +106,9 @@ The certificate must contain the following information: - Non-persistent voters prove eligibility with a 48 byte (compressed) BLS signature on the message, occupying $48 \cdot (n - m)$ bytes total. - Aggregate signatures - *Signed message:* This aggregate BLS signature on the message is 48 bytes (compressed). - - *Signed election proofs:* Perhaps not strictly necessary, but another 48 byte (compressed) BLS signature can attest to the proof of the eligibility, see **BLS.BSig** in [the Leios paper](https://iohk.io/en/research/library/papers/high-throughput-blockchain-consensus-under-realistic-network-assumptions/). + - *Signed election proofs:* Leios does **not** aggregate eligibility proofs. + Each non-persistent voter provides a 48-byte eligibility signature, which + must be verified independently to enforce the sortition threshold. Thus the total certificate size is