I wanted to learn more about Leios, so I vibe-coded this visualization TUI on top of Pallas.
It's not meant for operations, just a personal visual aid to understand the flow of the protocol. It was quite useful, but it also raised some new questions.
What you can see is an initiator node connected to the Musashi Dojo. The TUI is divided into two horizontal lanes:
- top lane: the Praos part, a sequence of ranking blocks (RBs)
- bottom lane: the Leios part, a sequence of endorser blocks (EBs)
The X-axis represents time, so you see blocks ordered from left to right, representing the sequence of the chain.
The interesting part to notice from the video: the heavy lifting of Leios (votes, tx processing, etc.) happens between RBs, making use of the idle time.
Being a vibe-coded PoC, the TUI uses some heuristics to work around much of the complexity and the current protocol gaps. For example:
- the link between RBs and EBs is estimated using slot proximity
- the votes are just a counter, and the denominator is the peak number of voters seen so far
One question that popped up and I'm still looking into:
the idle time doesn't seem to be enough to observe all the EB votes and download all the txs. This is probably related to data diffusion; maybe client prioritization on the responder side; maybe just bad performance on my code. π€·
New in Pallas: Leios support π
There's now a way to talk to Cardano's Leios protocol directly, with nothing but Rust π¦. Ready to run against the live Musashi Dojo.
Here's what you can do with it. π§΅