Cardano’s Leios Prototype Faces Its First Network Scale Questions

Cardano’s Leios project is moving from architectural research into prototype testing, where throughput claims must meet the less forgiving requirements of propagation, storage, certificates and node coordination.

The immediate milestone is not a mainnet release. It is a sequence of experiments intended to show whether the proposed design can operate across several nodes while producing and confirming transactions at useful rates. The results will determine which parts of Leios are engineering problems, which are protocol problems and which remain assumptions in the research.

The Leios research paper describes a parallel block architecture for Cardano. Its central mechanism separates the work of processing transactions from the later production of blocks that order those transactions in the ledger. Input blocks carry transaction material, while ranking and ordering blocks provide the structure needed for ledger progression.

That separation is intended to increase throughput without discarding Cardano’s existing security model. The paper is a design argument, however. It explains why the architecture could work under its stated assumptions. It does not establish that a deployed network can move the required data quickly enough, store it reliably or expose the right information to wallets and applications.

The prototype work is meant to test those conditions in stages.

From design to executable block production

The prototype production task describes work on forging Endorser Blocks, then testing them with ThreadNet and a local testnet. It also calls for measurements of block diffusion and transaction latency, while documenting limitations in the prototype.

Those measurements matter because throughput is not only a property of how quickly one node can create data. A transaction may be generated, included in an input block, transmitted through relays, observed by other nodes and eventually treated as confirmed. Each step adds a different constraint.

A node can therefore appear productive while the network remains slow. If propagation takes too long, competing views of the ledger may persist. If storage or certificate processing falls behind, the system may create data faster than it can safely adopt it. The prototype task recognizes this by treating diffusion and latency as first class measurements rather than relying on block production alone.

ThreadNet and a local testnet also provide different kinds of evidence. A controlled local environment can isolate a protocol or implementation bottleneck. ThreadNet can reveal whether the same behavior persists when nodes communicate through a more distributed test arrangement. Neither environment reproduces every condition of a public network, but together they can expose failures that a single process benchmark would miss.

The 200 TxkB/s test

A second completed task focuses on a more demanding target. The local devnet bottleneck investigation records testing on a three node cluster, generating at least 1,000 transactions per second and measuring confirmed throughput. It also uses dashboards to identify where performance is being lost.

The conditions are important. “At least 1,000 transactions per second” describes the generated workload, not necessarily the rate at which the network confirmed those transactions. The task distinguishes the input rate from confirmed throughput, which is the more useful measure for an end user and for applications that need final ledger state.

The target named in the issue is 200 TxkB/s on the local development network. That figure should not be read as a mainnet promise. It is a test objective under specified prototype conditions. The value of the experiment is in the bottleneck analysis: whether the limiting factor is transaction generation, block construction, network diffusion, storage, certificate handling or another part of the implementation.

Dashboards are useful here because aggregate throughput can conceal the cause of failure. A node may have spare CPU capacity while waiting on network delivery. Disk writes may become the limiting step only after blocks arrive in bursts. Certificate adoption may remain healthy at moderate load and then fall behind when the system is pushed toward its target.

A failure that exposes the real work

The prototype has already encountered a performance-related failure during a demonstration. The issue documenting the March demo bug describes Endorser Block inclusion on a proto-devnet, followed by delayed block storage and a failure involving certificate adoption. The issue also records subsequent fixes.

This is the kind of result a prototype is supposed to produce. The demonstration showed that the basic inclusion path could operate, but higher performance exposed an interaction between storage delay and the adoption of certificates. That distinction matters. A feature can work in a small demonstration and still fail when the surrounding system is under pressure.

It also shows why network scale testing cannot be reduced to a throughput chart. Leios adds more objects and more ordering relationships for nodes to process. Every object creates work for production, transmission, storage and validation. The system must preserve a consistent view of which data is available and which certificates can be adopted, even when one part of the pipeline is delayed.

The fixes are evidence of progress, not proof of completion. They show that the failure was identified and addressed in the prototype. They do not show whether similar interactions will appear at larger node counts, under different network conditions or with production workloads.

What the next evidence must show

The decisive evidence will be repeatable measurements across progressively larger and less controlled environments. Those measurements need to report confirmed throughput alongside transaction latency, diffusion behavior and resource use. They also need to identify what happens when storage, bandwidth or certificate processing becomes the limiting factor.

The research establishes the intended mechanism. The prototype issues establish that the mechanism is being exercised and that it has already produced useful failures. What remains unproven is whether the complete pipeline can sustain its target without imposing unacceptable requirements on stake pools, relays or other network participants.

That answer will come from testing, not architecture diagrams. A prototype that finds its bottlenecks early is doing its job. The harder question is whether the bottlenecks can be removed without making the network expensive, fragile or difficult to operate.