Blockchain is a linear data structure. Blockchain protocols, including the Nakamoto consensus, adhere to this linearity, resulting in inefficiency. The network utilizes computing power and bandwidth sporadically, leaving them underutilized most of the time. Sequential processing hinders scalability. In contrast, Ouroboros Leios and Peras introduce parallelism to Cardano while retaining the advantages of the Nakamoto consensus. In the article, we will explain the reasons for the inefficiency of the first generation of blockchain and the solutions that the new versions of Ouroboros will bring. Leios and Peras can be seen as the second generation of the Nakamoto consensus.
Why does the first-generation blockchain work sequentially?
Blockchain operates linearly, with each newly added block building upon the previous one.
This linearity arises from the fact that data dependencies—especially transactions—are also linear during validation. Let’s illustrate this with an example:
Imagine that there are several transactions in the mem-pool. The consensus must ensure that no funds (UTxO) are spent twice.
In the picture you can see that transactions 1 and 4 want to spend the same UTxO A. Consensus puts all transactions in the block except transaction 4. Transaction 4 is discarded because it tried to spend the same UTxO as transaction 1. New block N+3 is appended to the end of the blockchain.
To prevent double-spend attacks in a decentralized manner, distributed networks rely on sequential algorithms. Each block contains multiple transactions that can be cross-validated against each other and the global state. This ensures correctness—no double-spend attacks or creation of new value out of thin air.
Nakamoto consensus adheres to this linear structure by working sequentially.
Similar to Bitcoin, Cardano cannot immediately process transactions when users submit them to the network. Instead, transactions are broadcast to all nodes and wait in the mem-pool. They are pulled from the mem-pool only when a randomly selected node has the opportunity to produce a new block. In the case of Cardano, this can take 1 to 20 seconds, while for Bitcoin, the average time is up to 10 minutes.
Many first-generation BFT protocols work similarly.
Network computing resources and bandwidth are most utilized for producing a new block. Block producer node produces a new block which is subsequently diffused into the network to be validated by other nodes. However, this is a very short moment. Between the production of blocks, these resources remain underutilized. Resources are used only for the diffusion of blocks. This may require constant but relatively low resource demands.
In the picture, you can see the production of blocks during which the use of computing resources and bandwidth temporarily increases (peaks are shown by tall red rectangles). However, most of the time the resources are underutilized (low red rectangles).
For the Nakamoto consensus, transactions are not immediately considered final upon insertion into a new block. Even a newly appended block to the blockchain lacks finality. Blockchain forks can occur, resulting in two competing chains. These chains vie for inclusion in the blockchain history or face rejection. Only after several subsequent blocks have been added does a block achieve true finality. Users refer to the number of confirmations—blocks added after their transaction block—to gauge this finality.
Nakamoto consensus therefore has a relatively long settlement time. Tens of seconds to minutes in the case of Cardano can elapse from the time a transaction is submitted to the time it can be considered finalized. In the case of Bitcoin, it is half an hour to an hour.
The time that elapses between the submission of a transaction and its insertion into the block is called transaction latency. The time that elapses from inserting a transaction into the block until the required number of confirmations is called transaction finality. Settlement time is the sum of transaction latency and transaction finality.
Users must wait for several blocks to receive confirmation that their funds are at the expected address. However, in the event of a fork, the sender’s transaction might not be included in the blockchain. Consequently, the recipient may not receive the expected funds. The recipient needs to consider the possibility of a fork when determining the required number of confirmations. If a fork occurs, the time required for transaction finality will be higher.
Note that the fork increases the demands on the use of network resources because the blocks of the alternative chain must be diffused and validated by all nodes.
The Nakamoto consensus is inherently slow when it comes to achieving agreement on the global state among nodes (their stakes/hash rate). Block finality depends on the frequency of adding new blocks. Unfortunately, the network cannot start working on consensus immediately after adding a block, even though there is available computing power and bandwidth. These resources are not effectively utilized.
In the context of Bitcoin, it’s crucial to distinguish between the computing power of nodes (pools) and that of ASIC miners. ASIC miners work continuously, operating at full capacity to solve complex cryptographic tasks and mine new blocks. Meanwhile, node resources remain underutilized shortly after a new block is added until miners successfully solve a task, allowing the addition of subsequent blocks. In other words, the computing power of ASIC miners does not contribute to increasing throughput.
To improve network throughput and settlement time, blockchain networks need to better utilize available resources. However, achieving this requires balancing the need to maintain the blockchain’s linearity with the introduction of parallelization. This challenge is addressed by protocols like Ouroboros Leios and Ouroboros Peras.
Parallelization is a Must
A sequential system performs tasks one after the other in a specific order. Each task is executed individually, following the order in which they are received or programmed. These systems are simpler to understand, design, and implement. They are deterministic and do not face synchronization issues. However, their main drawback is low performance due to single-task processing.
Blockchain is composed of many nodes. Randomly selected nodes typically produce new blocks. A new block is diffused into the network, so its validation exhibits elements of parallelization, as multiple nodes can independently validate the same block. This inefficiency arises from the lack of continuous parallel execution. Only block validation takes place in parallel, but not transaction preparation before block production.
The picture shows that every node produces a new block when elected as a slot leader. The rest of the time, resources are underutilized. The figure does not capture the validation of blocks and the diffusion of new transactions.
Parallel systems execute multiple tasks or operations simultaneously. They support concurrency, allowing several tasks to run concurrently. However, implementing synchronization mechanisms is crucial to avoid errors. Although parallel systems offer higher performance and scalability, they are more complex to design and implement due to synchronization and communication requirements.
The challenge for blockchain lies in enabling parallelization while maintaining the sequential appending of new blocks. Achieving this balance requires synchronization between processes and increased communication demands. All network nodes must maintain a uniform global state, accounting for network latency during data diffusion.
In the picture, you can see nodes that produce a new block (yellow tasks) when elected as a slot leader and simultaneously perform other computationally intensive tasks (white tasks). Resources are fully utilized. The picture does not describe which specific tasks are being processed. We will describe that later.
In the upcoming section, we’ll delve into the tasks that nodes can handle to maximize network capacity, leading to improved throughput and faster transaction settlement.
Ouroboros Leios and Peras
One of the key concepts behind Ouroboros Leios is the decoupling of transaction processing from appending blocks to the blockchain. This creates two separate processes.
One process for maintaining the blockchain that will remain sequential while the other process for processing transactions that will make the most of parallelization.
Leios defines three block types: Ranking Blocks (RB), Endorsement Blocks (EB), and Input Blocks (IB). Multiple block types allow Leios to divide the workload into multiple processes.
The transactions themselves are contained within the Input Blocks. These Input Blocks act as the transaction carriers.
Endorsement Blocks can reference multiple Input Blocks. Nodes validate blocks and vote on their readiness for inclusion in the blockchain through Ranking Blocks.
The voting result is a certificate that the blocks carry with them. These certificates are verified when inserted into the blockchain.
The processing of Input and Endorsement Blocks can take advantage of parallelization and, thanks to decoupling, is not limited by the sequentiality of the blockchain.
Ranking Blocks only contain references to transactions through Endorsement Blocks. The blockchain will consist solely of Ranking Blocks, meaning it will only include references to the transaction data.
Read our article on Ourobors Leios and Peras where the basic principles are described.
The traditional Nakamoto consensus processes a batch of transactions (a block) within a predefined interval set by the team. In the context of bandwidth and computing power, this interval is relatively long. For Cardano, this interval is 20 seconds. Consequently, during a 20-second window, individual nodes utilize their resources for less than 1 second. Each node is responsible for either creating a new block or validating a newly arrived block, which includes processing transactions.
By decoupling and introducing multiple blocks, Ouroboros Leios enables the parallel processing of multiple tasks. Network resources can be efficiently utilized throughout the entire 20-second window.
In the picture, you can see that each node processes multiple tasks continuously. Tasks that enable parallel processing across nodes are marked green and yellow. These tasks relate to Input Blocks and Endorsement Blocks. White tasks require sequential processing related to Ranking Blocks. We neglected the validation of incoming transactions and other non-resource-intensive tasks.
Ouroboros Leios introduces several essential tasks, including IB and EB minting, IB validation, EB endorsement, and the creation of a certificate for EB. These tasks collectively enhance throughput by allowing the preparation of a relatively large volume of transactions that are solely referenced by RKs. Consequently, the size of the RB is not a limiting factor.
In contrast, Ouroboros Peras introduces an additional feature: voting on Ranking Blocks. This feature facilitates faster transaction settlement and potentially quicker resolution of blockchain forks. Unlike the original Nakamoto consensus proposed by Satoshi, Ouroboros Peras incorporates this novel task.
As nodes within the network perform more tasks, which require increased communication, network computing power, and bandwidth are utilized significantly more. The average workload will be higher and the network will not show signs of a spike usage of resources as the first generation of the Nakamoto consensus.
Ouroboros Leios and Peras address the limitations of the Nakamoto consensus while preserving its strengths, particularly its emphasis on liveness. In cases where participation in RB (Ranking Block) voting is low—perhaps due to a sudden outage affecting a significant number of network nodes—the Nakamoto consensus reverts to its traditional behavior. Consequently, voting on RB is not a prerequisite for achieving consensus among nodes.
Conclusion
Many users submit transactions simultaneously, regardless of network consensus. Their primary goal is to settle transactions as quickly as possible. Consequently, the network must validate these transactions almost immediately after submission. High throughput serves as the most effective defense against network congestion. If user transactions wait in the mem-pool for an extended period or if users need to resubmit them, it represents a failure compared to traditional banking services that scale well and enable instant payments.
Sharding and Layer 2 solutions (L2s) address different challenges than Ouroboros Leios and Peras. The latter protocols focus on maximizing network capacity within a single global state. In contrast, the initial generation of L2 solutions has encountered limitations, introducing user complexity and dividing users and capital. Sharding, on the other hand, holds promise as a more viable technology.