Saga’s Approach to Blockchain Scalability: How is Cassiopeia this Fast?
Introduction
Blockchain scalability has been an area of research and innovation since the early days of Web3. From the Bitcoin block size wars in 2015 to monolithic vs modular blockchain design considerations of 2023, there is a huge amount of debate today on the optimal path to scaling blockchain networks.
Enter Cassio. The first testnet for Saga’s network has achieved unprecedented scalability performance.
The numbers above demonstrate the limits of the Cassio testnet as the result of extensive stress testing by our engineering team. In this post, we’ll specify some of the technical components that are important factors to consider when reasoning about the scalability of a blockchain network and how it relates to Saga’s chainlet infrastructure. We’ll also explore the secret sauce behind Saga’s scalability: horizontal scalability, which allows the network to scale in a manner that is quite novel as compared to other networks and examine the role that validators play in this horizontal scalability. Let’s dive in.
The Three Components of Scaling a Blockchain
From a numerical perspective, blockchain scalability is often measured in transactions per second (TPS) — the number of transactions that a network can handle, on average, in one second. Ethereum is anywhere from 15–20 TPS whereas Solana can support over 1,000 TPS on a live mainnet.
When measuring TPS in a testnet setting, typically the only transactions that are included are token transfers. Token transfers are used as the primary transaction type when computing TPS in a testnet for two reasons: first token transfers require the least amount of gas per transaction (21,000 gas units) and second, each token transfer requires the exact same amount of gas (exactly 21,000 gas units) so it makes it easy to compare TPS across chains or across different time periods. This is typically why TPS in testnet environments will be much greater than actual live environments where there is a greater diversity of transaction type and gas requirements. For example, an Ethereum block can theoretically hold up to 1,400 token transfer transactions in a testnet setting, with an average TPS of 120. But in production, these numbers drop down to 50–200 transactions per block and an average TPS of 15–20.
As a result, transactions that require a higher amount of compute like NFT minting or token swaps are excluded, although the latter make up a significant portion of actual transactions on a live mainnet. Saga’s technical architecture is such that there is a single platform chain that controls the deployment of chainlets — customizable app-chains built around a specific use case. For a particular chainlet (or any chain), its individual TPS is the function of three inputs — the average blocktime, total block size and size of the mempool. Specifically, TPS can be measured from the following equation:
TPS = min(Max Transactions in Block, Max Transactions in MemPool)/(Average Block Time)
Where maximum transactions in a block refers to the total block size and the maximum transactions in the mempool refers to the size of the mempool. Let’s discuss these two variables along with average block time below.
Average Block Time
Blocktime is something that is determined by protocol design and refers to the average amount of time it takes for a new block to be added to the blockchain. For instance, Bitcoin’s block time is approximately 10 minutes, whereas the blocktime for Ethereum is on average of 10-15 seconds. For networks that focus on maximizing TPS, a faster blocktime is essential; on Solana a new block can be theoretically created once every 400 milliseconds.
While the latter produces faster blocks, it comes with increased infrastructure requirements for validators. For example, in Tendermint consensus, which powers a Saga chainlet, validators must gossip transaction details and establish strong p2p connections in order to quickly commit on the order of transactions within a block. If the blocktime is relatively short and a validator does not have a strong network connection with low latency, they risk missing out on signing a block which can result in a slashing of financial collateral. In addition, as the number of validators for a network increases, an increase in blocktime may be necessary to accommodate a larger p2p gossiping network that may become increasingly global and decentralized.
Optimizations at a software level can help to decrease block times as well. For example, Sei network is making optimizations around Tendermint consensus utilizing “optimistic block production” where validators start to process transactions before consensus is reached on the expectation that the original transaction ordering will be agreed upon. Other chains like Solana can use parallelization of transactions to more quickly process blocks produced by the network.
Total Block Size
The second element that is an important consideration for TPS is the size of a block; put in other words, block size is the maximum number of transactions that can fit into a single block. The size of a block for EVM-compatible chains is measured in ‘gas’ - a unit of measurement used to calculate the computational effort required to execute specific operations, like sending tokens or executing a smart contract. Each operation with an EVM chain has a predefined gas cost. The term ‘gas per block’ refers to the maximum amount of gas that can be used to process the transactions and smart contracts within a single block. This limit is set to prevent blocks from becoming too large and unwieldy, which can lead to slower block times and increased network congestion.
On Ethereum today, the size of an individual block is 30MM gas. A simple transfer of $ETH from one account to another requires around 21,000 gas which implies that if a block is full of token transfers, more than 1400 transactions could be included in a particular block.
Size of the Mempool
A mempool (short for memory pool) is a repository for transactions that have been broadcast to the network but have not yet been added to a block in the blockchain. When a transaction is initiated, it’s first verified by the nodes in the network and then placed in the mempool. The transaction waits in the mempool until it can be included in a new block and the block is added to the blockchain. From there, the transaction is considered confirmed and is removed from the mempool.
The size of the mempool can greatly impact the end-user experience. For example, when the mempool is large relative to the size of the block (i.e. there are many unconfirmed transactions), it may take several blocks for a transaction to be confirmed. If the mempool is too small, then users may need to continually resubmit transactions as their transactions cannot be added for potential inclusion, and may also negatively impact the number of transactions that are actually confirmed by the network. The mempool plays an essential role in blockchain networks by providing a holding area for transactions, which helps maintain the continuity and reliability of the blockchain.
The three elements discussed here - average block time, total block size and size of the mempool are all interrelated with each other when it comes to network design. If the mempool is large but the block size is small, transactions may take several blocks for inclusion which may result in failed transactions. A faster block time and a large gas size per block may result in validators missing on votes which lead to a slashing of stake. When designing a protocol, it’s important to balance these three components in a way that is optimal for validators and end-users alike.
Cassio Chainlet Configurations
So what is the block time, gas per block and size of the mempool for a chainlet on Saga? On Cassio, chainlets come with pre-configured specifications. In the current iteration of Cassio, the average block time is 1.3-1.4 seconds per chainlet - roughly 1/10th the time of a block on Ethereum yet not quite as fast as a blockchain network like Solana or Sui. The size of a block is 30MM gas, the same size of an Ethereum block. Given the 21,000 gas required for standard token transfers, a Saga chainlet can also process approximately 1,400 transactions per block. The mempool for a particular chainlet can hold up to 10,000 transactions in the pool which means that for any arbitrary transaction that is added to the mempool, it should be confirmed to the chain within 7-8 blocks; given an average time of 1.3-1.4 seconds per block, most transactions added to the mempool can be confirmed within 10 seconds. Given these numbers, we can also conclude that the average TPS for a particular chainlet is between 1,000-1,100 transactions per second (1400 transactions per block at an average block time of 1.3-1.4 seconds). So how does Saga network scale to 1.1MM transactions per second?
The Secret Sauce: Horizontal Scalability
The magic of Saga’s tech design is horizontal scalability. Horizontal scalability is contrasted to vertical scalability, where the latter refers primarily to changes that one can make in protocol specifications to increase throughput. Some of the levers that blockchain networks can pull to scale vertically are the ones described earlier: increase the size of a block, decrease blocktime or increase the size of the mempool. Horizontal scalability refers to the creation of a new chain to add throughput to the whole network. All the chains within the Saga network are connected with each other via the platform chain. Cassio can currently support up to 1,000 chainlets which makes the throughput of the whole network 1000x greater than just one chain. That is how Saga scales from 1,100 TPS per chain to 1.1MM (1,100 TPS per chainlet x 1000 chainlets) for the whole network. More specifically, we can change the equation above for TPS on a horizontally scaled network to be as follows:
TPS = [min(Max Transactions in Block, Max Transactions in MemPool)/(Average Block Time)] * (number of chains)
These numbers purported for Cassio will certainly change with the launch of mainnet. In practicality, the type of transactions that actually happens on-chain will utilize more complex logic than simple token transfers that require higher gas and therefore there will be fewer transactions per block. In addition, as the number of validators increases and the validator set becomes more decentralized, it may be required to increase the time to create a block for network latency perspective which could reduce the actual number of transactions as well. That said, it may be possible that as the number of chainlet deployment increases over time, the overall network can continue to scale horizontally to accommodate all the applications built on top of the Saga ecosystem.
In future versions of the Saga’s testnet and eventual mainnet, the number of validators for the network will increase as will the ability for chainlet developers to customize their own chainlets to their individual needs. While the TPS of other networks must resort to innovations that are done with hardware or modularizing components of the blockchain tech stack, the TPS of Saga will likely depend on the ecosystem itself - specifically the number of chainlet developers and the way they choose to customize their own chainlet. Saga will likely be one of the first blockchain networks where its throughput will be an emergent property of the ecosystem, instead of something that is fixed to protocol designers. Validators must run nodes that are elastically scalable to new chainlet demand. Let’s examine how validators run their nodes in Cassio and how node architecture will change with future upgrades.
What Exactly are Validators Doing? Cassio vs Future Releases
There are four validators for Cassio that are all run by Saga Labs and each validator deploys their own AWS Cluster that is managed by Kubernetes. Kubernetes - an open source container orchestration platform - helps manage an AWS cluster by automatically handling the distribution and scheduling of containers across different nodes. It monitors the health of the nodes and containers, restarting or rescheduling them as needed. Kubernetes enables seamless scaling of applications based on demand by adding or removing containers. These features are ideally suited for validators on Saga as they will have to manage hundreds or thousands of different chains within the ecosystem.
In the current version of Saga, four validators autoscale their compute and storage capacity based on the overall chainlet requests with an implicit limit up to 1000 chainlets. Validators also run ‘a controller’ - a stateless process that listens to the platform chain for any requests for chainlet deployments. When the controller picks up that a new chainlet has been requested, it instructs the Kubernetes cluster to orchestrate the automatic deployment of a new validator node to be utilized for validating a new EVM-compatible chain. For Cassio, validators will also provision a block explorer, web socket and JSON RPC endpoints as these are valuable services that make blockchains usable. While the validators that run the platform chain on Cassio will also run all the chainlets, it’s important to note that the chains are not currently connected via IBC. The validator architecture on Cassio is shown below.
Saga’s technical roadmap is designed to eventually reduce the dependencies that validators will require from a centralized service like AWS. As the validator count increases in future upgrades of Saga, validators can choose to organize their compute on any cloud-based architecture like Microsoft Azure, Google Cloud, bare metal setups or even utilize Web3 infra solutions like Spheron. Value-add infrastructure services like block explorers, web sockets and JSON RPC endpoints, etc will be offered by companies that specialize in offering those services, in addition to what Saga Foundation will provide by default. In addition, while EVM chains will be supported on mainnet launch, eventually Saga chainlets can become VM-agnostic to support developers who are experienced in other smart-contract programming architectures like CosmWasm, Move or the Solana Virtual Machine (SVM). Eventually the Saga validator architecture will look as follows:
Conclusion
If this article piqued your interest in regards to developing on Saga or even offering some kind of service to chainlet developers, let us know! Developers interested in creating their own chain are encouraged to use the contact form here while potential validators or service providers are encouraged to join our Discord.
