This article is translated from the IOHK blog "Cardano: robust, resilient – and flexible" by Kevin Hammond, a software engineer. October 21, 2021.
Introduction: NFT projects on the Cardano blockchain are experiencing explosive growth. However, due to the large number of transactions involved in the NFT creation process within a short period of time, Cardano has encountered significant network congestion issues. This article from IOHK explains the reasons for these issues from the perspective of architecture design and parameter configuration, and briefly describes short-term and medium-term solutions.
The design goal of Cardano is to provide services to hundreds of millions of users in a globally distributed manner. Like other decentralized blockchains, this means that we need to consistently generate new blocks that meet expectations. These blocks transparently record transactions between users, and together they make the blockchain grow continuously. In order to ensure that new blocks can propagate efficiently and securely throughout the network, the entire system must achieve sufficient efficiency in terms of computational, memory, storage, and network resource consumption.
Flexibility is key, so an important feature of the Cardano protocol is that its architectural design fully considers true scalability. This is not only to achieve longer-term goals, such as making Cardano a truly global and fully decentralized operating system, but also to adopt a parameterized approach to flexibly respond to price fluctuations, network saturation, and demand growth. Cardano provides some protocol parameters that allow the system behavior to be adjusted without a hard fork. Even if a more significant upgrade is indeed required, it can be achieved using our hard fork combinator (HFC) technology. These features combined make Cardano different from other existing blockchains, making today's Cardano already very robust and reliable, and making it highly agile in terms of upgrade paths to flexibly respond to network growth and changes in usage.
The roadmap design of Cardano is divided into a series of stages, allowing us to step by step towards the ultimate goal. The goal of the Byron phase is to implement basic transaction functionality using a federated network. This allows us to start building communities and establishing partnerships while working towards the next phase. Byron reboot laid a solid foundation for further development, and the Shelley phase introduced stake pools, further expanding the community and embarking on a journey of 100% decentralization of block production.
This year, Cardano has introduced several highly anticipated new features. Since the beginning of 2021, with the arrival of the Mary era, Cardano has supported the creation of other asset tokens and non-fungible tokens (NFTs) on the ledger. Due to the low transaction fees of Cardano and the fact that token creation does not require smart contracts, we have seen explosive growth in Cardano NFTs. In September, the Alonzo upgrade enabled Cardano to support Plutus smart contracts, enabling it to run a wide range of decentralized applications (DApps). Currently, Cardano's smart contracts are still in the early stages, but there are already dozens of projects developing DApps and several projects are close to being deployable. The relevant development activities will soon accelerate further. These new features will affect the way Cardano handles new scripts and transactions on the ledger, and will also generate new demands on available resources. With the increase in transaction activity, Cardano's architecture supports agile response and adaptation to demand.
Network Capacity#
Network connectivity is at the core of Cardano's operation. The Cardano network distributes transactions and block data to decentralized nodes around the world, and these nodes play a role in generating and validating the blockchain. This process is called data diffusion, and this necessary process provides the nodes with the information they need to make consensus algorithm-based decisions. These decisions drive the evolution of the blockchain, as consensus among nodes ensures that all transactions are verified and validated and further incorporated into new blocks in a transparent manner.
Cardano's consensus protocol is the decentralized Ouroboros Praos. By making a series of modifications to the protocol parameter d, Cardano has migrated from the previous federated Ouroboros Classic protocol to the Praos protocol. The security of Ouroboros Praos is highly guaranteed, based on peer-reviewed research papers presented at top network security and cryptography conferences and journals.
Network performance affects the overall speed of the system. This includes the following indicators:
- Throughput (amount of data transmitted)
- Timeliness (time to include in a block)
These two requirements are contradictory. When we can use the generated blocks most efficiently, we can maximize throughput as much as possible. Conversely, this means that there must be sufficient buffering to cover delays, which can mitigate the inconvenience of a global distributed system.
More buffering usually means better utilization of blocks (and the network), but the cost is that when the system is overloaded, the delay (i.e., the time to include in the chain) will be longer.
Block Budget#
To understand the speed at which Cardano executes transactions and scripts, we should first define the concept of block budget. The current block size limit of Cardano is set to a maximum of 64 KB, and the design of this parameter balances good network utilization and minimal transaction latency. A single block may contain various types of transactions, including transactions using Plutus scripts (smart contracts), native tokens, metadata, and basic ADA transactions (payments). Similarly, the size limit of a single transaction is currently set to a maximum of 16 KB. This ensures that a single block always contains multiple transactions (at least 4, but usually many more), thereby improving the overall transaction throughput.
Block time budget is also an important attribute, which refers to the time available to process all transactions in a single block, and this time length is fixed. It is divided into time for executing Plutus scripts and time for executing other transactions. This attribute ensures that transactions using Plutus scripts do not monopolize all available time budgets, so the system can always process basic payments in blocks that contain Plutus scripts. The total time budget for generating each block (including network connection costs) is set to 1 second, and the available time budget for executing Plutus scripts is approximately 50 milliseconds. In practice, this parameter is quite loose—benchmark tests have shown that the execution time of many real scripts is less than 1 millisecond.
The block time budget is currently set to 1 second. For security reasons, the Praos consensus protocol selects a small portion (one-twentieth) of the blocks that could be added to the chain. Therefore, under the current protocol parameters, the maximum transaction throughput (simple transactions) is approximately 11 transactions per second (11 TPS). Obviously, different transactions have different data sizes and different payloads. For example, a single transaction can ultimately determine an entire round of Catalyst voting and transfer assets worth millions of dollars.
As discussed earlier, each block contains many transactions submitted by users through wallets or command-line tools (CLI), etc. These transactions are stored in a temporary memory pool until they can be processed and included in a block. When a block is generated, unprocessed transactions are removed from the memory pool, and new transactions are added to the memory pool. By using a fixed-size memory pool, we can avoid network overload during high demand, but this also means that wallets or applications may need to resubmit transactions. The current size of the memory pool is set to 128 KB, which is twice the current block size. This parameter is selected based on a queuing model.
Network Scalability#
The design goal of Ouroboros is to be able to handle a large amount of data, as well as transactions and scripts of different complexities and sizes. Currently, using the current parameters, the Cardano network only utilizes about 25% of its capacity on average. Of course, the most efficient situation is when Cardano's capacity is almost 100% utilized (i.e., network saturation). Although many network connection schemes may have problems in this case, the design of Ouroboros and the Cardano network enables it to respond fairly and highly flexibly to severe saturation. Benchmark test analysis shows that even at 200% saturation, Cardano's overall performance remains elastic and does not encounter network failure issues. Even under 44 times the pressure of stress testing, the overall available network capacity did not encounter problems (although some transactions may experience slight delays). This is how the Cardano network is designed to work, using backpressure mechanisms to manage the overall system load. Therefore, for example, although some users may experience longer transaction times when participating in large-scale NFT projects or may need to resubmit individual transactions in large batches (or make the NFT issuance process last longer), it does not mean that the network is "crashing". This actually indicates that the performance of the Cardano network is as expected. We call it "graceful degradation", for more details, please refer to this paper on network design.
Wallets#
The role of wallets is to submit payments and other transactions to the blockchain on behalf of end users, and they can also be used to track the state of the blockchain. One of the core services provided by wallets is to represent users in submitting transactions, confirming that transactions have been linked to the blockchain, and continuing to retry if the submission fails. In other words, wallets should take into account the impact of backpressure and other network issues (such as temporary disconnections and possible chain forks) when the network is saturated. There are two types of wallets:
- Full-node wallets (such as Daedalus), which run a node directly connected to the Cardano network using local computing and network resources.
- Light wallets: These wallets use shared computing and network resources to serve a large number of end users.
When there is high network demand (such as during NFT sales), both types of wallets may need to retry transactions. Light wallets may need to temporarily expand available computing and network resources (including replicating server endpoints) in order to meet user demands, as they share resources among many users. This on-demand expansion is similar to meeting the needs of a popular new product released by a company. On the other hand, full-node wallets may not be fundamentally affected. Transactions may be delayed, but each wallet has dedicated resources for retrying transaction submissions, including its own network connection. The same principle applies to DApp providers—they should expand system resources to meet demand when providing specific network endpoints.
Process Optimization#
We naturally welcome the innovation (and communication) happening in the NFT community. In order to improve the user experience, it is necessary to optimize the development process so that processes such as creating NFTs can operate effectively even when the system is saturated. For example, many NFT creators use batch processing to create NFTs, which is more efficient.
We also encourage NFT creators to continue optimizing their processes to minimize network congestion. We also hope that everyone will join the discussions in the creator community's Discord, where we have engineers who can help find the best matching solutions for specific cases.
In addition to the flexibility provided by parameter adjustments (which can be implemented within an epoch if necessary), in the medium to long term, we have further options. Hydra allows Cardano to execute multiple operations in parallel, achieving greater scalability. State channel solutions can increase system throughput while reducing the need for on-chain execution. However, although Hydra has multiple scalability use cases, it does not specifically address the efficiency issues of NFT creation. As Cardano continues to mature and develop, we will continue to work on optimizing the network and managing network capacity. As I mentioned recently in the mid-month update for October, as Cardano's operational capacity grows, we can adjust Cardano's parameters as needed. For example, we can reduce the block time budget, optimize the size and execution time of Plutus scripts, or reduce their execution costs, and increase throughput.