design choices and voting protocol summary

Author: curiecrypt

docs/leios-design/README.md

@@ -505,6 +505,42 @@ Non-persistent voters, on the other hand, are selected independently for each EB
 Registered voters can generate and cast votes, each including an `endorser_block_hash` field that uniquely identifies the target EB. 
 Collected votes are then aggregated into a compact certificate.
 
+#### Leios Voting in a Nutshell
+- **Key Generation**  
+  - 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.
+
+- **Key Registration**  
+  - The registration process is responsible for storing public keys and verifying proof of possession.  
+  - Each stake pool registers with the following information:  
+    - A unique identifier (Pool ID or similar)  
+    - $pk$  
+    - $PoP$  
+    - A KES signature over the Pool ID, $pk$, and $PoP$  
+  - Nodes verify the $PoP$s of all received $pk$s to confirm their validity.
+
+- **Voter Determination**  
+  - For each epoch, *persistent voters* are selected based on the stake distribution and participate in every election during that epoch.  
+  - Within the same epoch, *non-persistent voters* are chosen randomly and independently for each election.
+
+- **Voting**  
+  - Voters sign the election ID and the EB hash with their $sk$.  
+  - Each vote includes the election ID, the EB hash, and the corresponding signature.  
+  - Persistent votes additionally include an epoch-specific identifier of the stake pool.  
+  - Non-persistent votes include the Pool ID and an eligibility signature on the election ID.
+
+- **Certificate Generation**  
+  - Upon receiving votes, both voter identities and their signatures are verified.  
+  - Non-persistent votes are further validated for eligibility.  
+  - Once a quorum of valid votes is collected, a certificate can be generated.  
+  - The certificate includes:  
+    - The election ID and the message (the hash of the EB)  
+    - The identities of participating voters  
+    - Eligibility proofs for non-persistent voters  
+    - An aggregate signature combining all individual voter signatures
+
 #### Requirements
 The voting and certificate scheme in Leios must satisfy key requirements to ensure security, efficiency, and practical deployability.
 
@@ -528,12 +564,17 @@ Lastly, the cryptographic operations for eligibility verification, vote generati
 The total workload should stay well within the CPU budget for Leios stages, ensuring strong performance and scalability under real-world conditions.
 
 #### Design Choices
-- Signature scheme
-- sortition
-- key registration
-- vote layout
-- certificate layout
-- ...
+
+Several certificate schemes were evaluated for Leios, including ALBA variants, SNARK-based voting schemes, and BLS-based certificates, with the goal of identifying a design that best satisfies the security, efficiency, and deployability requirements described above. 
+After comparison, BLS certificates based on the *Fait Accompli* sortition scheme were selected as the preferred approach. 
+Although this choice requires the registration of additional keys and occasional key rotation, it provides a strong balance between efficiency and practicality, producing certificates smaller than 10 kB.
+
+Other voting mechanisms could be considered preferable if they met the following conditions: no need for new key registration (i.e., reusing existing VRF and KES keys for voting), a certificate size well below the 90,112-byte limit of a Praos block, and proof generation and verification times that remain within the CPU budget of the `cardano-node`. 
+However, among the schemes analyzed, BLS certificates offered the most favorable trade-offs across these dimensions.
+
+The BLS voting mechanism relies on a pairing-based signature scheme defined over the BLS12-381 elliptic curve. 
+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.
 
 #### Implementation Plan