Demand for Dedicated Blockspace

Introduction

In Part 1 of this series, we analogized Saga’s core technology to Amazon Web Services: as AWS made hosting web applications easier for Web2 companies, Saga aspires to do the same for blockchains and Web3 projects. In Part 2, we discussed the supply side for dedicated blockspace — specifically, how validators are selected and the mechanisms implemented that put steady downward pressure on the price for dedicated blockspace.

In this post, we will turn our attention to the demand side of the Saga marketplace and discuss the journey that Web3 developers go through when building their own dedicated blockspace. The Saga protocol — our technology and token model — is designed to make it as easy as possible for developers to build in their own space. We’ll discuss the barriers that developers face from a technical and token economics perspective and how the Saga protocol systematically removes these barriers. Let’s dive in.

Barrier 1: Building a dedicated blockchain is technically difficult

In the absence of a protocol like Saga, there are many things required to launch your own blockchain: a deep understanding of blockchain consensus, engineering expertise on systems architecture, knowledge of deterministic programming and the ability to write bug-free code that may secure millions of dollars of assets. Even with an understanding of the Cosmos tech stack, which includes out-of-the-box code for consensus (Tendermint), a tool-kit to extend functionality to a blockchain (Cosmos SDK) and a deterministic programming layer (CosmWasm), it can take much effort for an experienced team to put all the lego blocks together to create a functional blockchain network. For teams that are eager to get to market in a cost-efficient manner, this is not ideal. Luckily, Saga’s technology abstracts much of this technical complexity away.

Automating the creation of a blockchain network can save at least 8–10 months of development time. By utilizing Interchain Security, developers can access Saga validators to provision a blockchain or rollup in a permissionless manner and rely on the economic security offered by the Saga mainnet. A developer can request blockspace without worrying about recruiting validators or needing to understand the nuances of consensus and the Cosmos SDK. The ease of development can be seen with Cassio, the second iteration of Saga’s core product. Cassio is the platform that hosted Saga’s first ever GamesJam, where multiple teams quickly developed and deployed Web3 applications free of congestion from other applications.

Barrier 2: Building dedicated blockspace is expensive

While Saga’s core protocol makes it logistically and technically easier to launch a blockchain, what about costs? Since no public blockchain networks are identical to each other, it is difficult to fix a price on the exact cost for launching a blockchain network but Saga’s goal is to commoditize blockspace and minimize the costs for developers. In addition, there are many optimizations we can build into the Saga protocol that make it as consistently cheap as possible to access one’s own dedicated blockspace.

Scheduler Function

One of the keys to running a profitable business is keeping costs low. Given the mechanisms described in our previous blog, the price for dedicated blockspace on the Saga platform will tend to be close to the actual costs that validators incur when offering validation services. These costs generally are related to the costs for compute and storage as validators who validate chainlets are responsible for reaching consensus on the order of transactions, executing transactions, settling transactions and making data available on the history of transactions. The price that a validator quotes for their services on the Saga platform is quoted in $SAGA tokens, and since multiple validators are required to validate a blockchain, the cost to a team of building on the Saga platform could be summarized by a simple equation:

Cost to deploy on Saga Platform = X*N

X = Price for Validation Services in current epoch,
N = number of validators for a chainlet

While the price for validation services within a particular epoch is fixed, Saga will be implementing an optimization to reduce the number of validators per chainlet by utilizing a ‘scheduler function’. To understand the scheduler function, let’s walk through an example. Let’s say the Saga network has 100 active validator slots, and there are 50 chainlets that are secured from the Saga validator set. In order for a chainlet to have similar economic security to the Saga mainnet, some minimum threshold of stake must vote to validate each block. If we set this threshold at 50%, this means that at least 50% of the combined voting power of Saga validators need to vote ‘yes’ to add a new block to a chainlet; but this does not mean that we need at least 50 Saga validators for a particular chainlet. The reason for this is that voting power across validators is not evenly distributed across all the validators; voting power is often concentrated where the top 5% of validators by voting power may control over 30% of the voting power whereas the bottom 5% of validators may control less than 1% of the voting power. This ‘power-law’ distribution can be observed for most Cosmos blockchains, including the Cosmos Hub.

Due to this uneven distribution of stake, we implement a scheduler algorithm that randomly selects validators for a particular chainlet until a certain minimum threshold of voting power has been attained; validators with more voting power have a higher likelihood of being selected than validators with less voting power. The following graph shows that the number of validators required depending on the minimum threshold assuming a stake distribution is identical to other popular Cosmos chains.

As a result, if there are 100 validators that validate the Saga mainnet, it may end up being the case that only about 25–35 validators are required for each chainlet. It is expected that for chainlet developers, there will be a small amount of variability in the number of validators per chain and as developers utilize multiple chainlets, this can add some extra variability as well. That said, the optimization from the Scheduler function can drastically reduce the costs of deployment.

Rollup Deployment

With the newly announced collaboration between Saga and Celestia, Saga’s chainlet infrastructure can also be used to deploy decentralized sequencers on Celestia. Celestia is building a modular blockchain where the underlying blockchain is responsible for settlement and data availability via a novel technology called data availability sampling. Rollups — which are the home of crypto applications — still require sequencers to execute and order transactions. Saga’s chainlet infrastructure can be utilized whereby Saga validators take turns to act as a sequencer for a Celestia rollups. Since validators are only responsible for executing and ordering transactions, and are not responsible for data availability or settlement, the cost for sequencing a rollup would be less than validating a fully provisioned chainlet. Using the equation above, the cost for sequencing a rollup should be less than the cost for full validation services on a chainlet for a particular epoch.

Rollups come with tradeoffs; while they may be cheaper to deploy, rollups are currently not able to communicate with other rollups or blockchains as effectively as fully provisioned blockchains. As a result, rollups are ideal for siloed applications that are either not composing on top of other applications or interacting with any other applications across the Saga ecosystem.

Barrier 3: Web3 Token Models Suck

So far, we’ve discussed how Saga reduces the technical barriers to building dedicated blockspace in a manner that is both cheap and predictable. But how can developers make money from their Saga deployments? This is where Saga’s flexible token design comes into play. Unlike other blockchain networks that require end users to pay for transactions in a native network token like $ETH or $SOL, end users of chainlets or rollups do not need to pay for transactions on a chainlet using $SAGA tokens. Chainlet developers are free to charge end-users in whatever fee token they choose, or they may even choose to not charge end users at all. This results in developers being able to generate revenue in whatever way they like. A few monetization schemes could be:

• Create their own fee token or utilize another token and require end users to pay for transactions utilizing that fee token. A chainlet developer’s profits would then be the collected fees minus the cost for chainlet deployment. In order to create liquidity for these fee tokens, developers can also create liquidity pools and collect revenue trading fees.
• Charge end users transaction fees denominated in $SAGA token. A chainlet developer can then pocket the difference between fees collected and the cost to deploy on Saga.
• Utilize a subscription model where end users prepay for any transactions on a monthly basis.
• Make transactions free, which creates a better user experience, and utilize freemium models where developers can generate revenue from ads or other services rendered from their product.
• If the chainlets are utilized to support a game economy, in-game economics can generate revenue that can easily offset chainlet deployment costs. For examples of game economies, read this excellent piece by Rex, our Head of Developer Relations.

When it comes to revenue streams, the possibilities are endless.

Conclusion

As we can see, there are many barriers that make it difficult, time-consuming and expensive to build dedicated blockspace in Web3 today. Saga’s core mission is to alleviate these barriers and make it as easy and cost-effective as possible to build dedicated blockspace from scratch. These barriers start at a technical level, where the Saga protocol abstracts away the technical nuances of consensus and makes it easy to build your own dedicated blockspace. At a token economics level, Saga’s core protocol is designed to drive down the price of validator services over time. In addition, our token model imposes no restrictions on developers, which opens up the design space to create novel business models in Web3.

While Saga can support developers looking to build on their own blockspace, the protocol can also extend to supporting other ecosystems as well. In fact, Saga recently announced a partnership with Polygon to support Supernets — their take on application specific blockchains. But how does that work? To understand more, we’ll delve into that in Part 4 of this series.