Ouroboros Peras builds upon Ouroboros Praos, targeting the slow settlement times characteristic of Nakamoto-style consensus. In this consensus model, blockchain forks are common, and users can only be certain their transaction is final—permanently recorded on the blockchain—after a significant number of additional blocks have been added. Ouroboros Peras aims to cut this settlement time down to just 2 minutes.
The Nakamoto Consensus Has a Slow Settlement Time
Nakamoto consensus has probabilistic finality. This means that a transaction’s finality isn’t guaranteed when it’s first added to a new block. Instead, the likelihood of the transaction being final increases as more blocks are added on top of the block containing the transaction.
Users must wait for the network to add several blocks on top of the block with their transaction. The transaction becomes irreversible only after these additional blocks are added. Each new block added on top of the user’s transaction block signifies agreement with the ledger’s state.
Users refer to the blocks added after their transaction block as the number of confirmations. For example, a transaction included in block N+2 would have 6 confirmations by the time block N+7 is added.
In Nakamoto consensus, nodes show their agreement with the ledger’s state by appending another block to their preferred chain. The block producer can add a new block after the last valid block (at the blockchain’s tip) or after one of the previous blocks. In the event of a blockchain fork, a node can choose the branch it prefers. There may be a rule determining which of the two options a node should choose.
Due to the distributed, decentralized, and probabilistic nature of the Nakamoto consensus, it’s entirely possible for two or more chains to coexist simultaneously across the network.
If we were to proceed with the two right variants (next block producer has 2 options to append the next block) from the previous picture, the subsequent blocks (blue NEXT BLOCK) will determine whether the (previously green) NEW BLOCK will be permanently included in the blockchain or orphaned (discarded).
In the Nakamoto consensus, two (or more) competing ledger state variants are considered a valid state of the ledger. Eventually, newly added blocks will determine the winning variant. The whole history of blockchain can look like this.
Blockchain forks can occur for several reasons:
- Multiple block producers may create new blocks at roughly the same time.
- Blocks take time to propagate to all network nodes, leading to different nodes having different views of the best chain.
- Nodes may join or leave the network.
- A node isn't required to agree with the most recent block (or series of blocks) and can instead append its block after one of the earlier blocks.
Short forks, typically just a few blocks long, occur frequently and are usually non-problematic. The rolled-back blocks are often nearly identical, containing the same transactions, though they might be distributed differently among the blocks or have minor differences.
However, these forks can be harmful. For instance, if an end-user (the recipient of funds) makes a decision—such as accepting payment and selling goods to another user (the sender of the transaction)—based on a transaction that is later rolled back and never reappears because it was invalid (e.g., due to double-spending some UTxO), it opens up the possibility of fraud.
The transaction was included in block N+2, which competed with an alternative chain version. Despite receiving 2 confirmations, the transaction ultimately did not make it to the blockchain, as it wasn’t included in any subsequent blocks of the winning chain.
A common expectation among users is that every valid transaction will eventually be included in the blockchain, regardless of forks. In this case, the transaction was added to block N+3, which remained a permanent part of the blockchain. There was no fraud in this case.
From the perspective of users (whether they are the sender or the recipient of a transaction), the key question is: When can they be confident that their transaction will never be rolled back?
Settlement time can be defined as the period after which a block (or transaction) added to a node’s best chain has a negligible probability of being rolled back due to a fork.
This leads to a more specific question: How many confirmations are necessary?
This issue can be examined from both practical and theoretical perspectives.
Theoretically, users can accept a transaction once it enters the mem-pool, believing it will eventually be included in the blockchain. This is common in the Bitcoin ecosystem, where the block time is 10 minutes. If a user submits a transaction shortly after a new block is produced, they typically wait an average of 10 minutes for the next block to be mined. In practice, this wait can extend to an hour, which is impractical. Additionally, if the network is congested and the user sets a low fee, the transaction may remain in the mem-pool for an extended period. In the case of Bitcoin, it is recommended to wait for at least 3 confirmations (30 minutes on average).
Cardano, on the other hand, has a block time of 20 seconds. If the network is not congested, there is a good chance the transaction will be included in the next block. For smaller amounts, users usually wait a few blocks, around 6 (2 minutes) or 10 (3,5 minutes is considered as high number of confirmations). For higher amounts, more confirmations are advisable to ensure transaction finality. While this approach works in practice, it is somewhat vague from a rigorous theoretical standpoint.
From a theoretical perspective, it’s essential to consider adversarial nodes and their stake.
Ouroboros Praos has been proven secure up to a 50% adversarial stake. As long as adversaries do not control the majority of the stake, it ensures that all honest nodes will eventually agree on the same, honest chain. However, this robustness comes with the cost of the time nodes must wait to consider a block (and thus the chain) settled.
In Cardano, a node considers a block definitively settled, or immutable, once it is (k) blocks behind the current tip of its best chain, where (k = 2160).
Given an average interblock arrival rate of 20 seconds, this means a block is considered settled after approximately 12 hours.
After 2160 confirmations, it is certain that a significant rollback caused by a private version of the blockchain will not occur. This addresses one of the theoretical threats: an attacker building a private blockchain and waiting for the opportune moment to publish it. The published version could cause a large number of blocks to be discarded simultaneously, disrupting what would normally be considered a final chain.
Although this attack is unlikely, it remains theoretically possible. Consequently, the finality of transactions under the Nakamoto Consensus is slow. While users typically wait for only a few confirmations in practice, theoretically, Cardano users should wait 12 hours (2160 confirmations) to be absolutely certain.
For Bitcoin, constructing a private version of the blockchain is costly, resulting in only minor rollbacks. Although an attack is theoretically feasible, it is unlikely in practice.
Ouroboros Peras
Ouroboros Peras will enable the necessary number of nodes (and their respective stakes) to agree on the state of the ledger by voting. It is a faster variant than adding the next blocks. This will significantly reduce the time required for transaction finality and lower the probability of a large rollback after just a few added blocks.
The current voting process, which involves approving block N+1, occurs through the addition of subsequent blocks. Seven nodes (and their respective stake weights) can approve block N+1 within the next seven added blocks. This method of voting is quite slow. The total stake of all nodes that have expressed consent is low.
Randomly selected nodes will vote on the state of the ledger within a given period, thereby increasing the weight of blocks that a majority of Stake Pool Operators (SPOs) agree upon. This method is known as stake-based voting.
A greater number of nodes (and their stakes) can vote to approve a block, including previous blocks, much more quickly. It can happen that nodes can consent to block N+1 before block N+2 is minted.
The chain selection process, which nodes use to decide the preferred chain variant, will be based on the chain’s weight rather than its length. This means that nodes will take into account votes (and certificates) instead of the number of blocks. The heaviest chain wins over the longer chain.
Study the scenario on the picture. Another block producer encounters a fork, with block N+1A and block N+1B, followed by block N+2B. Despite option B representing a longer chain, the block producer selects the heaviest chain and adds a new block after block N+1A.
Time is divided into fixed-length rounds, each lasting several tens of slots. These rounds are longer than the block time, which is 20 slots (with the expectation of minting one block roughly every 20 slots).
At the start of each round, a randomly selected committee of SPOs votes for the block at a fixed depth from their current best chain tip. A specified number of slots must pass after a block is produced before it can become a candidate for voting. This ensures that voting on a block does not begin until it is certain that no alternative block has been minted just a few slots before the potential candidate block.
Each vote’s weight is proportional to the SPO’s stake.
These votes are broadcast to all nodes across the network. If a node observes a quorum of votes for the same block, it can issue a certificate that increases the block’s weight. Certificates are also disseminated across the network on demand to nodes that do not have equivalent votes.
If the block producer has a new certificate available, it inserts it into the block, thereby propagating the certificate throughout the network. Thus, all certificates are stored on-chain.
In the figure, yellow blocks represent those that have been approved by a sufficient number of stakes (nodes), resulting in the creation of a certificate. Blue blocks represent those that contain a certificate referring to a previously approved block.
If a node fails to receive a quorum for a round, either from votes or a certificate, it enters a cooldown period during which any vote or certificate is ignored. After a fixed number of rounds, the node exits the cooldown period and resumes voting.
Ouroboros Praos ensures that once a transaction appears in a block, users only need to wait 2 minutes (6 blocks) to be confident that it will be permanently stored in the blockchain and that the block containing the transaction will not be rolled back.
Ouroboros Praos does not alter the fundamental security guarantees of Ouroboros Praos. It reverts to these guarantees during a cooldown period. In other words, consensus does not rely on voting, so block production will continue even if there are insufficient votes or no consensus on the chain during a fork.
Conclusion
Two minutes for users to achieve absolute certainty about transaction finality can still seem lengthy. This is because the current block time is 20 seconds, and it would be inefficient if voting occurred for each block. Ouroboros Leios will introduce three types of blocks: input blocks, endorsement blocks, and ranking blocks. The current blocks will become ranking blocks, containing only references to lower-category blocks. If Ouroboros Praos were applied to input or endorsement blocks, transaction finality would also be reduced. However, it is also possible that Peras will be used only for ranking blocks, with the consensus utilizing endorsement certificates for higher transaction finality.