- The Leios roadmap: Cardano’s layer 1 scaling roadmap, centered on the Ouroboros Leios architecture, directly resolves the inherent tension between scalability, decentralization, and security, defined by the scalability trilemma.
- Scaling through cryptography: The roadmap tackles the trilemma by integrating cryptographic techniques, such as SNARKs, data availability sampling (DAS), and Bloom filters, allowing consumer-hardware nodes to securely participate in the protocol without processing the entire blockchain.
- UTXO sharding: To unlock true horizontal scaling, the roadmap incorporates UTXO sharding which improves scalability by distributing state maintenance and update responsibilities in an organized manner across the network while also eliminating transaction conflicts.
- The immediate foundation: Current development efforts in Linear Leios (CIP-0164) and Ouroboros Peras (CIP-0140) solve immediate throughput and latency constraints while structurally laying the groundwork to fully realize the scalability roadmap.
Introduction
The blockchain scalability trilemma has been an important guiding principle in the blockchain space. It boils down to the ability of a blockchain to satisfy three key objectives:
- Scalability: the chain can process more transactions than a consumer-level laptop can verify or download.
- Decentralization: protocol security does not rely on a trusted group of large centralized entities. Alternatively, anyone can join the trust group with a consumer-level laptop.
- Security: the chain remains secure even if a large fraction of the stake/nodes running it behaves maliciously.
Alternative protocol designs capture only two of the three properties. Bitcoin-style Nakamoto blockchains satisfy decentralization and security but not scalability. Permissioned high-throughput blockchains that rely on small committees of powerful, trusted nodes achieve scalability and security without decentralization. Finally, multiple blockchains organized in a single ecosystem may satisfy scalability and decentralization, but not security, as an attacker may focus all of its attacking power (e.g., stake or computation) on a single chain to break its security.
This post examines Cardano’s layer 1 scalability roadmap and its alignment with the scalability trilemma. Current efforts center on two protocol enhancements: Leios (CIP-0164) and Peras (CIP-0140). Leios is designed to maximize transaction throughput by decoupling transaction diffusion from transaction sequencing, while Peras aims to minimize confirmation latency through boosting the weight of widely adopted blocks. Both protocols are optimized for high performance under favorable conditions – such as robust stake participation and stable network performance – and fall back to the existing Ouroboros Praos protocol when those conditions are absent, preserving security. Notably, the two enhancements can be combined to provide high throughput and low latency simultaneously.
Figure 1. An overview of the Ouroboros Leios architecture. Transaction sequencing remains powered by Ouroboros Praos via ranking blocks (RBs). Transaction diffusion is now decoupled through independently produced input blocks (IBs) that carry the bulk of the traffic. The two layers are bridged by endorser blocks (EBs), which (i) contain references to IBs, (ii) undergo voting for correctness and data availability, and (iii) maintain context by pointing to a corresponding RB.
At first sight, the architecture proposed by Ouroboros Leios, shown in Figure 1, appears unable to reconcile all three pillars of the scalability trilemma. This perceived limitation stems from the requirement that nodes must download and verify every candidate transaction before approving it through an EB. Such a process conflicts with the scalability property, which recognizes that transaction volumes can grow so large that nodes running on consumer-grade hardware will lack the bandwidth and processing power to handle them. This asymmetry between the traffic volume and the capabilities of small nodes is at the heart of the scalability trilemma. However, as this blog outlines, the proposed architecture can effectively incorporate cutting-edge scaling techniques and meet all the objectives outlined in the trilemma.
Cryptographic scaling techniques
Cryptography has long provided tools that can seemingly do the impossible, e.g., prove something without revealing any information about what was proved, compress a large proof into a small group multiplication check, etc. In the same spirit, the set of cryptographic scaling techniques we outline next enables a node that receives transactions at a rate greater than its processing capabilities to efficiently check whether they are: (i) correct, (ii) available for download by anyone, and (iii) relevant to its interests.
Correctness. Through cryptographic techniques, such as Groth16, it is possible to create succinct non-interactive arguments of knowledge (SNARKs) about the correctness of a list of transactions extending a ledger that are small in size (a lot smaller than the list of transactions they refer to) and can be verified in a short amount of time (sublinear in the original total transaction verification time). This tool exactly matches our first goal: to verify that a set of transactions is correct with minimal resources.
Data availability. Leios already uses an asymmetric data availability technique: voting. Given an EB certificate, a wallet or light client can efficiently verify that the referenced IBs are available (and, as a matter of fact, correct, since correctness is also checked before casting a vote) without downloading them in full. However, this is not sufficient to achieve scalability, as we would like voters to be able to infer that a block is available without having to download it in full. This can be accomplished through data availability sampling (DAS). In its simplest form, DAS has the prover first use an erasure code to encode the block. Verifiers then request multiple parts of the encoded block at random. If the prover provides all requested pieces, the verifier deems the block available. This framework provides a remarkable recovery property: if the prover convinces multiple verifiers, then by combining the small pieces they receive, they can reconstruct the original block. That’s because erasure codes allow reconstructing the original block from a sufficient number of arbitrary pieces of the encoding. DAS thus provides the necessary asymmetry in data availability proofs required by the trilemma.
Relevance. Recall that our desired notion of scalability calls for transaction rates beyond the capacity of single nodes running consumer-grade hardware. Thus, we require a mechanism by which such small nodes can learn the parts of the state relevant to them. Bloom filters are the right tools for this job. A Bloom filter is a data structure built on a subset of items drawn from a larger set, allowing for quick ‘testing’ of whether an item is part of the subset encoded. The size of the filter can be much smaller than the subset of items encoded, at the cost of sometimes giving false positives, ie, claiming that an item is part of the encoded subset when this is not true. Concretely, at an error rate of 0.01%, each item encoded in the Bloom filter takes approximately 20 bits, independently of the size of the objects it encodes. Hence, by downloading a ‘small’ Bloom filter, a small node can learn whether a UTXO that is relevant to it has been consumed by the latest ‘large’ block, and only then maybe decide to download it in full.
Warm up: scaling Linear Leios
Linear Leios, shown in Figure 2, described in CIP-0164, and currently under active development, is a simplified protocol variant of Ouroboros Leios. It simplifies the architecture presented in Figure 1 by fusing IBs and EBs. EBs are now also used to carry the bulk of the traffic. An EB in Linear Leios is only included in the ledger if (i) nodes vote in favor of it being released on time and being correct, and (ii) the associated certificate produced is included in the very next RB. Unlike ‘Full’ Leios, shown in Figure 1, the decoupling of transaction diffusion from sequencing in Linear Leios is only partial, since EB delivery must happen before the next RB is generated for the EB to be recorded on the ledger. However, the size of the EB can be a lot larger than the RB, because the EB is only included in the chain if conditions are favorable for its dissemination: the network is in good condition, the next RB does not appear too early, etc. This leads to an increase in throughput over Praos, as desired.
Figure. 2. A high-level overview of Linear Leios (CIP-0164) – EBs, instead of IBs, now carry the bulk of the traffic
Voting in Linear Leios can be made scalable using SNARKs and DAS. Block producers are required to compute a SNARK about the correctness of the transactions included in their RB/EB. This enables voters to check correctness without (i) processing individual transactions or (ii) knowing the full state of the system. Secondly, voters use DAS to check the availability of an EB without fully downloading it. The check must be run against a node (the ‘prover’) that has already received the full block. By performing these two checks, a voter can then decide whether to approve the proposed EB without having to download and process each transaction individually.
Besides voting, a small node should be able to track changes of the state that are of interest to it and contribute transactions to the system. The first part can be achieved by having block producers use a Bloom filter to encode all changes introduced by the new block (e.g., encoding all input UTXOs consumed by the transactions contained in the EB). Nodes can then quickly check inclusion using the filter, and then – if they get a positive result – decide to download the full block. While false positives output by the Bloom filter may result in downloading some extra blocks, the false positive rate can be adjusted to match the target hardware requirements.
Finally, to ensure that all changes are encoded in the Bloom filter, its correct computation can be ensured through the SNARK.
Regarding block creation, small nodes are somewhat limited by the state they maintain. That is, they are only able to include in the blocks they create transactions that consume UTXOs that they actively track. The main reason being that with the information they gather, they can only compute the related SNARK for transactions that consume exactly these UTXOs (i.e., they don’t know if the UTXOs they don’t track have already been spent in a previous block, and thus cannot compute the relevant SNARK). The full protocol is shown in Figure 3.
Figure 3. The integration of DAS, Bloom filters, and SNARKs into the Linear Leios construction of Figure 2
Using cryptographic scaling techniques within Linear Leios – notably DAS and SNARKs – introduces some tension due to data diffusion being only partially separated from transaction sequencing. Specifically, while an EB must be delivered before the next RB is generated to be recorded in the ledger, the processes for EB reconstruction via DAS (if needed) and the correctness proof generation via SNARK can be time-intensive, thereby slowing both EB creation and diffusion. This tension is addressed in the full Leios architecture, shown in Figure 1, which establishes a stronger form of decoupling, allowing for the diffusion time of IBs to be independent of the RB generation rate.
Scaling Full Leios
A first attempt at integrating SNARK and DAS within the full Leios architecture, shown in Figure 4, moves SNARK creation, DAS checks, and block reconstruction to the level of IB. Given the greater freedom in choosing the diffusion time parameters of IBs, this design better accommodates these operations. Further, as the bulk of transactions is routed through IBs, EBs can be much lighter, thus removing the need to use heavy SNARKs and DAS at this level.
The above design still requires IBs to be rather infrequent and large to avoid conflicting transactions appearing in concurrently generated IBs and effectively lowering throughput. However, under such a parametrization, throughput may be wasted due to small nodes producing IBs they cannot fill with transactions, either because there is not enough traffic targeting the part of the state they know or because they lack sufficient processing power to produce the relevant SNARK.
Fig. 4. The integration of DAS and SNARKs into the Leios construction of Fig. 1.
Fortunately, the proposed architecture is well-suited to resolving conflicts through sharding of the UTXO space, shown in Figure 5, i.e., splitting the UTXO space into multiple ‘shards’ and having each IB serve transactions that consume UTXOs from a single shard. By tuning the per-shard IB rate to be sufficiently low, so that IBs containing transactions from the same shard are produced sufficiently far apart, conflicts can be mostly avoided. At the time a new IB associated with some shard is produced, the old one is already settled and part of the ledger state. Hence, the new IB cannot contain conflicting transactions, as this would make it invalid with respect to the ledger state. Further, by making the number of shards sufficiently high, the protocol can sustain a high IB rate/small IB size parametrization without degrading throughput.
UTXO sharding also allows for fine-grained management of the state tracked by each node. Nodes can choose to keep track of several shards, proportionally to their available resources, by downloading all relevant IBs. Block creation for small nodes is also much more effective now that the UTXO state is clearly separated. Nodes have full knowledge of the part of the state they are responsible for maintaining and updating when creating a new input block, which allows them to include any valid transaction targeting this part of the state. Further, by carefully tuning the IB size parameter, nodes with consumer-grade hardware will be able to produce full blocks, if needed, and compute the required SNARK proofs in time, thus most effectively using the part of the throughput they are allocated. Concluding, UTXO sharding provides an immediate means for nodes to adjust the resource obligations of participating in the protocol: for example, they may decide to keep track of none, few, or all shards by consuming an analogous amount of resources. These changes lead to a much stronger form of scalability than the one described at the beginning of this post:
- Horizontal scalability over inhomogeneous nodes: any new node that runs the protocol increases throughput proportionally to its resources.
Notably, the barrier to participation is expected to be rather low, at the consumer-grade hardware level, as explained earlier.
Figure 5. The integration of UTXO sharding into the Leios construction of Figure 4. Each IB is associated with a specific UTXO shard. Nodes are expected to keep a full track of the changes in the shards they decide to follow
Finally, we note that Peras, the latency-reduction enhancement, can be safely combined with any of the constructions outlined above without impeding scalability, as it operates solely within the transaction sequencing part of the protocol (RBs).
Is the development of Leios really necessary?
It appears that cryptographic scaling techniques (SNARKs, DAS, Bloom filters) provide a comprehensive toolkit for full scalability. Why, then, should the Cardano ecosystem spend resources developing Linear and Full Leios? The main reason is that, under the current protocol, Ouroboros Praos, data diffusion, and transaction sequencing are tightly integrated. This makes it hard to continuously use available resources at maximum capacity and make the protocol scalable. With the current parameterization, blocks processed in less than 1 second are produced once every 20 seconds. On the other hand, the Leios architecture decouples diffusion from sequencing, allowing for almost continuous use of available resources and, consequently, much higher throughput.
Moreover, the tactical investment in Leios development serves a dual purpose: it provides a substantial throughput boost in the short- to medium-term while simultaneously advancing the long-term strategic objective of incorporating cryptographic scaling techniques and sharding. The more decoupled the protocol architecture is, the easier it is to integrate time-intensive tools such as SNARKs and DAS. It should be noted that the whole blockchain community puts immense effort into improving both of these tools, and any reduction in the performance characteristics required to use them will enable their earlier integration.
A roadmap to scalability
This post outlined a roadmap to completely resolving the scalability trilemma. While the roadmap necessitates both protocol-level refinements and the integration of cutting-edge techniques currently being pioneered by the global blockchain community, the current transition to the Leios architecture stands as a pivotal advancement. It addresses immediate throughput constraints that Ouroboros Praos cannot meet, while simultaneously establishing the structural foundation required to apply future scaling methodologies.
The Leios testnet is launching soon. Timelines and product features are not final and are not guaranteed; all future developments are subject to change.
Team effort is a hallmark of IOR research and this blog post is no exception. I am grateful to Matthias Fitzi, Sandro Coretti-Drayton, Alexander Russell, and Aggelos Kiayias for various suggestions, comments, and corrections to the above text.
Giorgos Panagiotakos is a research fellow at IO Research. He is one of the authors of the original Ouroboros Leios paper and his work focuses on making blockchain protocols secure and scalable.
