Showcase voting and certification primitives

[hjeljeli32]

Why

We would like to share with our community how Leois's voting is performed in memory-efficient manner.

What

Goal: Have a visually pleasing showcase of the voting for a monthly meeting (perhaps the next one?)

Subgoals:

• Get an intuition of the inner workings of the fait-accompli protocol
• Get an intuition on the relations between persistent and non-persistent voters
• Get an intuition on what is in a registration cert/vote/eb-certificated etc
• Get an intuition on the eb-certificate size related to the (non)-persistend voters

Nongoals:

• Showcase the networking stack
• What RB or EB blocks look like
• How the registration workflow happens

How

@bwbush made the wonderful leios_crypto_benchmarks cli tool that can generate signatures and showcase the voting end-to-end.
Using that tool and some Bash scripting, create a fake stake distribution and cadence of RB's plus an occasional EB announcement. This EB is just represented as a dummy hash; it does not contain any data (the cli tool allows for this). Using the CLI tool, make votes across the stake distribution and visualize the threshold and reaching it or not (resulting in a valid EB cert and adopting the EB or not).

[hjeljeli32]

@ch1bo
Completed a 1st iteration of the demo that visualizes the voting/aggregation mechanism in Leios.

The demo highlights two core optimizations:
• Persistent voters can omit the proof of eligibility, reducing vote size.
• BLS aggregation compresses all votes into a much smaller certificate.

1. Set of SPOs (Universe)
This first screenshot shows the full set of 499 SPOs, with a total stake of 99,997 ADA.
Each circle represents a stake pool.
• Hovering over a node displays its Pool ID and stake amount.
• The grid gives an overall view of all participants eligible for committee selection.

2. Committee Selection
This section shows the committee selected for a given epoch.
• Persistent seats (green) are filled via the Fait Accompli mechanism.
• Non-persistent seats (blue) are empty placeholders to be filled later by local sortition for the specific EB.
Hovering over a seat reveals:
→ Seat ID
→ Pool ID (filling that seat)
→ Stake amount

3. Election Identifiers
For each election, we display:
• The Election ID (EID)
• The EB hash associated with that election

4. Voting Stage
In this part, each seat (persistent or non-persistent) may cast one vote.
• Persistent voters are identified by their seat number — their votes are 134 bytes (small rectangles), since the eligibility proof is omitted.
• Non-persistent voters are identified by their Pool ID — their votes are 247 bytes (large rectangles) as they include the eligibility proof.
Hovering over each vote shows:
→ Voter identifier (Seat ID or Pool ID)
→ Vote size (bytes)
→ Eligibility proof (for non-persistent)
(Note: I applied a small workaround here — since CLI produced more non-persistent votes than available seats, I temporarily show the first 75% of them.)

5. Aggregation
Finally, we visualize the vote aggregation process.
• Persistent and non-persistent votes are combined into a single certificate.
• The total vote payload here is 11.4 KB, while the resulting certificate is 4.9 KB, giving a compression gain of 2.26×.
Hovering over the certificate shows:
→ Election ID
→ EB hash
→ Certificate size
The area of the rectangle representing the Certificate is proportional to the size of the Certificate.
This demonstrates how BLS aggregation yields compact, verifiable outcomes for Leios elections.

[hjeljeli32]

@ch1bo
Following feedback received from the Leios team, I’ve incorporated several improvements and suggestions into the demo.

• Added a certificate verification step in the UI to illustrate the end-to-end flow.
• Added timing information for each operation (committee selection, voting, aggregation, and verification).
• I also display the CPU specifications used for benchmarking to clarify the hardware environment.
• The demo now starts by showing the related GitHub issue and the UI code location, to give better context on where the implementation lives.

The demo will be presented to the Cardano community during the Leios Monthly Demo and Review on October 29 2025.

@ch1bo Since the demo now fulfills the goal of this issue and is ready for public presentation, would it be okay to close this issue?