A Deep-Dive into Saga

Saga: A protocol that lets you create your own dedicated blockspace in minutes

Introduction

Web3 founders face a crucial decision when deciding to launch their product. If they want to avoid the layer 2 option due to concerns surrounding centralized sequencers and multisig bridges, they must choose between two main paths: developing their product as a smart contract and deploying it on an existing Layer 1 blockchain, or taking the ambitious route of creating their own blockchain from scratch. The former option comes with different advantages, notably removing the complexities of infrastructure management, ensuring a decentralized foundation, and leveraging the network effect inherent in the underlying blockchain.

Yet, opting for a smart contract deployment is not without tradeoffs. It leads to a competition for block space, resulting in a worse user experience characterized by inflated gas costs and transaction fees, coupled with an impact on transaction executions. The immutability of smart contracts can also be restrictive, offering little flexibility for the protocol in the case of critical bugs or hacks. The smart contract approach also lacks sovereignty, as the protocol will be subject to the rules of the hosting blockchain.

One solution that has gained popularity in the last two years to address the challenges of the smart contract approach is the appchain thesis, which was pioneered by Cosmos and followed by Polkadot. The idea behind this model is to build a dedicated blockchain for one application. Compared to the smart-contract solution, this model offers sovereignty and full customizability from the blockchain to the application. It also enhances performance and scalability since the application has its own blockspace. This leads to increased opportunities for the token to capture value, such as MEV, as Osmosis does, in addition to capturing other network fees.

Certainly, this solution involves several important factors to consider. It requires the management of the chain’s infrastructure, ensuring its own security, attracting validators, and designing a tokenomics model that aligns the interests of validators, stakers, and app users.

What if we could easily launch an application, similar to deploying a smart contract, and gain the benefits of an appchain, all without any initial investment or extensive effort? This is exactly what Saga’s value proposition is about.

Saga’s value proposition and architecture

The Saga protocol functions like application-specific blockchains as a service. In other words, Saga is a blockchain used to easily launch other blockchains, called “Chainlets” in the Saga ecosystem. Chainlets are secured by the Saga blockchain and its validators through a mechanism called Interchain Security, a well-known shared-security system in Cosmos.

Interchain security means that one blockchain, in this case Saga, acts as a provider of security for other blockchains, in this case the Chainlets. As a result, the Chainlets inherit the benefits of running a Cosmos SDK appchain but outsource their block validation and validator set to Saga.

Therefore, a Chainlet is a sovereign blockchain that has the same level of security and decentralization as Saga.

Saga introduces an easy, decentralized, and secure approach to deploying application-specific blockchains. This solution also grants developers the autonomy to choose their preferred Virtual Machine (VM), with initial support for the Ethereum Virtual Machine (EVM).

In the long run, Chainlets aims to be VM agnostic, which means that developers would have the flexibility to choose from a variety of virtual machines, including the EVM, CosmWasm, or the Javascript VM for example.

How to launch its own Chainlet?

The way Chainlets are created differs slightly from what we can observe on the Cosmos Hub when launching consumer chains with Replicated Security. In contrast to the Cosmos Hub, the launch of a Chainlet with Saga is entirely permissionless.

Developers only need to have SAGA tokens to pay for setting up and maintaining their Chainlet. This is similar to services offered by Amazon Web Services and other SaaS platforms, except that here the subscription fee is paid in SAGA tokens to create and maintain a Chainlet.

This means that once the fee is paid, the role of Saga validators is to set up and run the infrastructure for a Chainlet, similar to how Cosmos Hub validators also operate the infrastructure of the consumer chains.

To launch a Chainlet, a developer is required to allocate funds to an escrow account using SAGA tokens. This escrow account can be pre-funded to any desired amount and works like a prepaid service to cover the costs associated with the Chainlet. If the deposited fee is depleted, the Chainlet goes offline until the developer deposits more SAGA in the account. The fee is determined per epoch, where one epoch lasts approximately one day.

Diverse methods could be used for funding the escrow account with SAGA tokens:

1. Directly fund the account with SAGA tokens
2. Stake SAGA with the escrow account to cover the fee through staking rewards
3. Allow sponsors, communities and DAOs to pay the fee
4. Implement an IBC mechanism to seamlessly convert any crypto into SAGA and pay for the fee

This subscription fee is determined by the Saga validator set. Before the start of a new epoch, each Saga validator submits the fee they would like to receive for running a Chainlet. These bids are then locked before the start of the next epoch, and a Musical Chair Auction begins.

The Musical Chair Auction is a process that aims to establish a universal price for running a Chainlet. In this context, each validator presents their bid, and only the w validators with the lowest prices are included in the ‘Winning Set’. The remaining validators with higher bids constitute the ‘Losing Set’.

The final cost of running a Chainlet is determined by the highest bid within the Winning Set. This implies that the validator with the highest bid in the Winning Set gets its desired price, while other validators within the Winning Set not only secure their desired price but also receive an additional margin on their bid.

The price that developers will have to pay for Saga validators to run a Chainlet is:

To prevent collusion or Sybil attacks related to the Winning and Losing Set, the count of validators within this set must be large enough to make controlling the Winning Set challenging. According to the Saga team, this number should range between 75% and 85% of the participants in the Musical Chair Auction.

However, the Musical Chair Auction is not riskless for a validator. In fact, the mechanism is designed to incentivize validators to submit bids as low as possible, rewarding validators within the Winning Set, while penalizing those in the Losing Set.

A possible way for the team to handle punishment is to treat it like validator downtime: validators who are down for a certain period get a minor slash and are jailed (removed from the active set). Validators who lose the auction too often in a given period could also be minorly slashed and jailed.

Hence, the SAGA token has multiple use cases: it is used as a subscription fee to keep the Chainlet alive and to reward the validators for running the infrastructure. In this case, there is a 1:1 relationship between costs and revenues with the auction system. We can also think about having pools of validators that share the cost, with validators only running some Chainlets and not others, to improve scalability.

Saga and its Chainlets introduce an interesting token structure, as gas fees are not explicitly collected from end users. Within a Chainlet, gas fees can be paid using Saga, the developer’s own Chainlet token, no tokens at all (gasless transactions), or even other tokens such as ETH or USDC.

It’s worth noting that gas fees generated within a specific Chainlet are directed to a wallet managed by the developer. This confers a high degree of flexibility to the Chainlet and its team in determining their preferred monetization approach.

Consequently, with Chainlets, developers benefit from predictable and low costs, an easy process for deploying their blockchains, and the capacity to horizontally scale applications. While Chainlets inherit security from Saga, there exists a method for a Chainlet to also leverage and inherit Ethereum’s security using the Saga stack. Let’s delve into this aspect in the following section.

Zoom on a specific type of Chainlets: Ethlets

Saga Ethlet is a new Ethereum scaling solution that combines the best attributes from appchains, rollups, and validiums into a single product. Launching an Ethlet will be as easy as launching a Chainlet: with one click, an Ethlet can be created and inherit Ethereum’s security.

How does this mechanism work? Ethlets work with three essential components: Data Availability, State Hash Commitment, and Fraud Proof.

At the end of each epoch (~ 1 day), blocks produced during that time frame are batched, forming the ‘batched epoch’. A new epoch referred to as the ‘challenge period’ then begins. During this challenge period, Saga’s validators can use a fraud-proof mechanism (optimistic ZK or interactive) that enables the identification of any fraudulent transactions or state transitions that might occur within the blocks from the batched epoch. If, by the end of the challenge period, no fraud-proof has been presented, the state hash of the previous batched epoch is committed to Ethereum, and therefore, this committed state inherits the security of Ethereum.

This implies that there is a one-epoch delay for a state hash to be committed to Ethereum and inherit its security. However, it’s important to note that blocks inherit Saga’s security even before being committed to Ethereum.

Finally, Saga will be used as a Data Availability layer, similar to a validium, to avoid the high Data Availability costs of Ethereum. An Ethlet thus achieves fast finality through Tendermint, facilitates rapid bridging, and leverages the advantages of IBC. This approach ensures cost-effectiveness while also inheriting Ethereum’s security.

Conclusion

Saga offers any developer the ability to easily launch their application as a Chainlet and inherit Saga’s mainnet level of security and decentralization from the start. By choosing this option, the application will benefit from its dedicated blockspace, and the team will gain more control over the blockchain and the application layers compared to launching as a smart contract. If the developer choses, they can upgrade a Chainlet into an Ethlet and gain the benefits of Ethereum Security.

Saga is initially focused on gaming and entertainment chains, as we can notice from their partnerships. Gaming applications are one of the fastest-growing sectors in web3, and a gaming project, such as a video game, needs its own dedicated scalable blockchain capable of supporting high transaction volumes — exactly what Saga is offering and what Chainlets based on the Cosmos SDK can provide. As web3 gaming and entertainment continue to grow and the demand for scalable architecture for users increases, Saga presents itself as the solution to provide the necessary architecture and is confident in onboarding the next 1000 chains in the Multiverse.

About the Author

Kam BENBRIK is Research Analyst @ Chorus One.
Twitter: https://twitter.com/KamBenbrik

About Chorus One

Chorus One is one of the largest institutional staking providers globally operating infrastructure for 40+ Proof-of-Stake networks including Ethereum, Cosmos, Solana, Avalanche, and Near amongst others. Since 2018, we have been at the forefront of the PoS industry and now offer easy enterprise-grade staking solutions, industry-leading research, and also invest in some of the most cutting-edge protocols through Chorus Ventures.