The UTxO model naturally supports parallel transaction processing, but Ouroboros Praos falls short of fully leveraging this advantage due to its sequential block production and the long delays between blocks. Leios changes the game. It introduces Input Blocks that are minted at a much higher frequency—potentially five times per second—enabling continuous parallel processing of transactions. This high-speed flow is coordinated through a technique called pipelining. In this article, we’ll dive into how pipelining works in Leios and examine the technical challenges that come with high throughput. Sequencing Is Slow Blockchains traditionally process blocks in a linear sequence, where each new block is appended after the previous one. This sequential structure applies to both Bitcoin and Cardano, which use the UTxO (Unspent Transaction Output) model. In this model, transactions are inherently parallelizable because they operate on distinct UTxOs. When validating transactions in a new block, a node validates whether each input UTxO exists in the current set and whether it can be spent. These validations can happen in parallel, since the transactions are independent, at least until a conflict arises. After validation, the system ensures that no UTxO is spent more than once within a block, thereby preserving consistency. However, despite the parallelism possible at the transaction level, the linear production of blocks restricts this benefit. Blocks are still created one after another, and each one must build on the finalized state of its predecessor. This serialization means that the broader system cannot fully capitalize on transaction-level parallelism. Ethereum, by contrast, follows an account-based model, where each transaction modifies a shared global state. In this setup, transactions within a block must be executed sequentially because the result of each transaction can influence the state used by the next. This adds further constraints to parallel execution and limits throughput more strictly than in the UTxO model. A major limitation in both models is the idle time between blocks. During this period, nodes are primarily waiting—allowing time for the newly created block to propagate through the network. This delay is necessary for maintaining consensus and security, ensuring that all participants see and validate the new block before the next one is created. However, it also means that for much of the time, the network is underutilized, which caps the system's throughput. Faster block production risks compromising consistency, while slower production leads to underuse of available resources. Addressing this bottleneck is one of the motivations behind innovations like Ouroboros Leios, which introduces pipelining and parallel block production to improve efficiency without compromising security. Pipelining To achieve high throughput without compromising decentralization, Leios introduces a pipelining model that breaks transaction processing into three distinct, overlapping phases: preparation, validation, and finalization. This architecture enables multiple blocks to be built and processed in parallel, significantly increasing network efficiency. In the preparation phase, validators create Input Blocks (IB), which are speculative proposals containing unconfirmed transactions gathered from the mempool. These blocks are produced concurrently by different nodes and may contain duplicates or conflicts. In the validation phase, other validators issue Endorsement Blocks (EB) to evaluate the Input Blocks, checking for correctness, UTxO validity, and filtering out any conflicts or duplicates. Finally, in the finalization phase, the network assembles a Ranking Block (RB), which includes only the valid, non-conflicting transactions and defines the new canonical ledger state. This separation of responsibilities across phases allows Leios to maintain a consistent block production rate (e.g., every ~20 seconds) while enabling the network to handle many more transactions in flight than traditional sequential blockchains like Ouroboros Praos. With pipelining, the network prepares and validates the next Ranking Block while the current one is being finalized. This eliminates the need to wait between blocks. The goal is to maintain a consistent 20-second finalization cycle, matching Ouroboros Praos, but with much higher throughput. Transactions are prepared, validated, and finalized in overlapping stages, enabling the network to process many more in parallel. As a result, Leios achieves high throughput and low latency. Pipelining in Ouroboros Leios introduces a significant shift from traditional linear block production by enabling overlapping stages of the block lifecycle to operate concurrently. In traditional blockchains, new transactions must wait for the previous block to be finalized before being considered for inclusion. This sequential dependency limits throughput and results in idle periods where the network does not make full use of its computational capacity. Leios changes this dynamic by allowing transactions to be inserted speculatively into new Input Blocks almost immediately after they are seen by the network. These IBs do not finalize state changes themselves but are part of a pipeline that feeds into Endorsement Blocks and ultimately into Ranking Blocks, where finalization occurs. In Ouroboros Leios, transactions are physically stored only in Input Blocks. These blocks are produced at a high frequency, potentially as fast as five per second. The size of blocks can be parametrized. It can range from 100 to 400 kilobytes. During the validation phase, Endorsement Blocks are constructed. Instead of including full transaction data, an EB references one or more Input Blocks and identifies the unique, non-conflicting transactions to be endorsed. This helps to eliminate duplicate or invalid transactions before finalization. The final step occurs with the creation of a Ranking Block, which references the relevant Endorsement Block(s) and commits the endorsed transactions to the canonical ledger. This pipelined structure—where IBs, EBs, and RBs operate in overlapping stages—allows Leios to scale significantly. Under optimal conditions, this design enables the system to process thousands, and potentially tens of thousands, of transactions per second (TPS), a dramatic increase over previous Ouroboros implementations. Because pipelines operate in parallel and partially overlap in time, the system can begin validation and conflict resolution sooner. This design improves responsiveness and throughput, although it also introduces challenges around data consistency, transaction duplication, and determinism that must be managed carefully. To achieve high transaction throughput (TPS) in a decentralized system like Cardano using Ouroboros Leios, it is essential to adopt strategies that reduce transaction duplication and minimize conflicts. Duplicate transactions—especially in a pipelined system where blocks are built concurrently—can waste bandwidth, computation, and storage. These inefficiencies not only reduce effective throughput but can also create openings for denial-of-service (DoS) attacks, where adversaries deliberately submit conflicting transactions to overload the system. Therefore, scaling securely requires carefully designed optimizations that both streamline transaction handling and strengthen the network’s ability to resist malicious behavior. Techniques such as tombstoning, sharding, transaction coloring, and collateralization are among the approaches under active consideration to strike this balance between performance and resilience. Determinism Softening In Praos, a single block is produced, then quickly propagated across the network. After that, the system enters an idle period, during which most nodes do very little until the next block is created. This slower pace gives the network more time to synchronize and resolve conflicts, which reduces the chance of duplicated or conflicting transactions being processed at the same time. Thanks to this, Praos can provide a high degree of determinism. Determinism refers to the guarantee that a transaction, once submitted and deemed valid (with correct fees and inputs), will be processed in a predictable, consistent, and isolated manner, producing the same result every time under the same conditions. In practical terms, for a user or developer, determinism means: If you submit a valid transaction, it will either be included in the ledger or rejected, not left in an uncertain state. Transaction outcomes are reproducible, and the system behaves consistently regardless of when or where the transaction is processed. It applies to fees as well. In contrast, Ouroboros Leios is built for high throughput, which introduces speculative execution and uncertainty in transaction inclusion. Thus, it cannot ensure the same level of determinism as Praos. Leios enables multiple blocks and transactions to be processed in parallel, which significantly increases the number of transactions the network can handle, but also increases the risk of duplication and conflict. In Leios, several blocks may be constructed nearly simultaneously, each potentially containing overlapping or conflicting transactions. This makes strict determinism—the guarantee that a valid transaction will always be included—much harder to preserve. In other words, without optimizations, a transaction is likely to be included in multiple blocks before the gossip protocol can let nodes know that the transaction has already been included in a new block. The result is transaction duplication, where the same transaction appears in different speculative blocks across the network. Example: Node A and Node B both see Transaction X in the mempool. They both independently create input blocks and include X. These blocks go through different validation pipelines or are seen by different validators. X is now being redundantly processed, possibly multiple times. In the figure, the yellow transactions are duplicates, i.e., inserted in multiple Input Blocks, and the green ones are unique, inserted in only one block. Although there are a total of 23 transactions in 4 blocks, only 17 are unique. Resolving duplicates requires unnecessary consumption of resources. This duplication is not a consensus failure, but it is an inefficiency. The system must detect and filter duplicates during later stages (validation and finalization), which adds computation and complicates reward distribution. High throughput and strict determinism are in fundamental tension: concurrency requires parallelism, while determinism demands serialized, isolated execution. You can't maximize both at once. To scale effectively, Leios needs to soften determinism. This means that many of the guarantees users and developers take for granted — like the assumption that a valid transaction will always be included once it passes local checks — become probabilistic rather than absolute. The challenge is to find the right balance between throughput and consistency, ensuring the system remains efficient without compromising security or fairness. Conflicts High throughput brings another challenge. In some cases, conflicting transactions may be included—e.g., if two transactions attempt to spend the same UTxO. These conflicts must be resolved, since only one can be finalized. In the figure, the red transactions are conflicting, i.e., inserted in multiple Input Blocks, and the green ones are unique. Although there are a total of 23 transactions in 4 blocks, only 21 are unique. Transactions 5 and 9 are conflicting. The conflicts must be resolved, as they are double-spends. Conflicts Are Rare for Ordinary Users Conflicts are unlikely to occur in typical user scenarios. If an ordinary user submits a single transaction that spends a unique UTxO, the chances of conflict are minimal. The UTxO model inherently provides transaction isolation, meaning as long as users don't reuse the same inputs in multiple transactions, conflicts won’t arise. Submitting one transaction at a time, as most wallets do, is generally safe and deterministic. Conflicts Are More Likely with Poorly Synchronized dApps Conflicts become more likely when dApps or wallets create multiple transactions simultaneously using the same UTxO as input. This issue is known today, but becomes more pronounced in Leios, which allows speculative inclusion of transactions. For example, a dApp might generate and broadcast two transactions at once, both using the same UTxO. It may not be aware that these transactions conflict. Both may be speculatively included in different Input Blocks before the conflict is detected. Later, the protocol must resolve the conflict, deciding which transaction is finalized and which is discarded. For example, suppose transactions 3A and 3B conflict with each other. When Node A sees and includes 3A, it hasn’t yet learned about 3B—so it treats 3A as valid. Meanwhile, Node B does the same with 3B, unaware of 3A. The conflict only becomes apparent after both transactions have propagated. Conflict detection can occur when nodes receive both new Input Blocks, each containing a conflicting transaction. When a node attempts to build an Endorsement Block, it must first identify and resolve such conflicts, ensuring only one of the conflicting transactions moves forward. Duplicates and Conflicts Can Be Exploited by Attackers Both duplicate transactions and conflicts can be exploited by an attacker. Let's show one of the many possible attacks. Attackers can exploit Leios’s speculative processing model by submitting many transactions that attempt to spend the same UTxO. These conflicting transactions may be accepted into multiple Input Blocks before the conflict is noticed. Conflicting transactions—whether caused by chance (the synchronization issues between batchers) or honest mistakes—can also be deliberately exploited. An attacker could intentionally mimic these conditions to create conflicting transactions at scale, amplifying the impact far beyond what might occur accidentally. This turns a natural vulnerability into a potential attack vector. The goal of such an attack is to force the network to expend resources resolving conflicts, even if only one transaction can eventually be finalized. This type of behavior can act as a denial-of-service (DoS) attack, where the attacker pays for only one valid transaction (if any), but causes validators to perform N× the normal amount of validation work due to duplication and conflict resolution. At this stage, the network must not only detect the conflict, but also decide which transaction to keep, and crucially, how to do so without sacrificing throughput or enabling abuse. The obvious first idea might be to discard any Input Block containing conflicting transactions and reintroduce the remaining valid ones into the mempool for later inclusion. However, this approach opens the door to a serious exploit. An attacker could submit a single conflicting transaction per pipeline to intentionally trigger this behavior. Because all invalid Input Blocks are discarded, the valid transactions they contained must be retried in the next round. Repeating this tactic cheaply and repeatedly could delay valid transactions indefinitely and reduce throughput to Praos-like levels—a classic denial-of-service attack, now with minimal cost to the attacker. The figure shows that the attacker has managed to invalidate all Input Blocks. All valid transactions must continue to wait in the mempools for another chance to be inserted into Input Blocks. However, if the attack were to continue, it would slow down the processing of valid transactions. Leios can address this with deduplication, and economic penalties (e.g., forfeiting fees or collateral for rejected transactions), but the threat model still requires careful protocol and incentive design. Resolving Conflicts In Pipelines Let’s walk through the stages of a pipeline cycle more clearly. It begins with the optimistic construction of Input Blocks, where transactions are added quickly without full validation. At this stage, some transactions can be duplicated or conflict with others. As the pipeline progresses, these conflicts are gradually resolved. By the end of the cycle, the system produces a new Ranking Block, which represents a clean and finalized ledger state. This block includes only valid, unique transactions, ensuring consistency and integrity across the network. This figure illustrates a full cycle of the pipeline, which includes the preparation, validation, and finalization phases. The Input Blocks in this cycle reference the latest valid state, defined by the most recent Ranking Block. During the Endorsement Block phase, any duplicates or conflicting data are resolved, making the output suitable for forming the next Ranking Block. Meanwhile—within the same slots—new Input Blocks are already being created in a parallel pipeline. The output of each pipeline cycle is a new Ranking Block, which defines the current global state of the ledger at that specific point in time. All new transactions added to the Input Blocks in the following pipeline cycle are then validated against this latest Ranking Block, ensuring consistency and correctness across the system. The figure shows three pipelines. The Input Blocks that are built in pipeline 3 reference Ranking Block 117, which has been built in pipeline 1. Dotted lines represent referencing the current global state at the time of minting Input Blocks. Solid lines represent the gradual building of a new Ranking Block from the bottom up. Conclusion Pipelining offers a key advantage over other scalability approaches like sharding: it preserves a single global ledger state. While transactions are processed in parallel through high-frequency Input Blocks, the system ultimately consolidates them into Ranking Blocks, which define a unified, globally consistent state used for validating future transactions. This design avoids the complexity of managing multiple isolated ledger segments, as seen in sharding, where cross-shard communication and conflict resolution can be challenging. However, implementing pipelining is far from trivial. While the core idea is straightforward, ensuring correctness across all edge cases—especially under adversarial conditions—requires solving complex coordination, synchronization, and security challenges. Robustness against attacks and maintaining consistency at high throughput are major engineering hurdles that the Leios team must address.
