Where Does Saga Fit in the Landscape of Web3?

Introduction

One of the new areas of research that has emerged from the growth of Web3 is Token Economics. Token Economics draws from the principles of Economics, Finance, Mechanism Design and Game Theory and is a catch-all term for all the elements that make a particular Web3 token valuable, interesting and secure. Saga’s Token Economics paper has been carefully researched and ideated on for the last 6 months and has been designed to enable a robust new economy for dedicated blockspace.

This article is the first in a series taking a deeper look at all the key aspects of Saga’s token economics.

Before diving into how the token economics is designed, it’s important to discuss Saga’s core technology and where it fits in the overall landscape of Web3. We’ll do this by first examining how innovation was impacted by the advent of cloud computing services in the Web2 space and analogizing those problems in the context of Web3 today. We hope to inform the reader on some of the fundamentals of Saga’s technological design (often referred to as Blockchain Topology), which will serve as a basis for understanding the decisions that we made for our Token Economics. Let’s dive in.

Building in Web2 before AWS

Let’s consider the history of web development in the era of Web2 (1990s-present). When the internet boom was first gaining steam in the late 90s, companies were often tasked with carving out their own part of the internet to provide services. This usually meant going in one of two directions. The first direction was to use a third-party web-hosting service like Tripod.com or Angelfire (well-known tech companies in the 1990s). Companies used third-party services relatively cheaply but only had access to a limited set of options and features. For example, Tripod customers could pay for services such as integrating a shopping cart, domain names, email or disk space but could not guarantee 100% uptime or scalability improvements for fast growing businesses via a Service Level Agreement (SLA).

The second direction was to hire multiple engineers who specialized in building servers in-house that could host a database, provide compute and access storage; for well-capitalized companies, this was a sensible direction to go in as companies had more control over uptime, scalability and flexibility over network architecture. Andy Jassy — current CEO of Amazon — noted that in the early days, it would often take new in-house teams upwards of three months just to set up a proper back-end infrastructure even before any front-facing application could be developed. In his best-seller “That Will Never Work”, Marc Randolph — co-founder of Netflix — discussed the difficulty Netflix had with managing their in-house servers in the late 90s.

“Instead of furniture, we spent money on technology. We bought dozens of Dells online and had them shipped to the office. We bought our own servers — in 1997, there was no shared cloud — and installed them in the corner. We bought miles of cable, and wired the office after-hours, ourselves. Extension cords and ethernet cables twisted through the office like orange and black snakes. Wires hung down from the ceiling like vines.”

Despite their best efforts and significant outlay, on 4/14/1998, the day of the launch of netflix.com, their servers crashed several times.

Building in Web2 after AWS

Randolph notes that current startups do not have to deal with these issues today: “Now, almost every web company runs their business in the cloud. Rather than the long, laborious and capital-intensive setup that Eric and Kho had to deal with, now companies simply write a check, buying access to somebody else’s computers, stored in air-conditioned warehouses with backup power and plenty of storage.”

What made building in Web2 much easier than the early days of Netflix was the introduction of cloud computing resources, primarily pioneered by Andy Jassy and the team that he built as Amazon Web Services (AWS) in the early 2000s. AWS was originally born out of a need for Amazon to scale their own servers for Amazon.com. AWS built key infrastructure that allows Web2 companies to rent Amazon’s servers to host their own web applications. Instead of having to build and manage their own servers, Web2 companies can now deploy their web application to AWS, and AWS can guarantee 100% uptime and scalability via a service-level agreement (SLA). One of the more popular deployments in AWS is EC2 (Elastic Cloud Compute) — a product that allows users to rent virtual computers on which to run their own applications, which would have no doubt been useful to Netflix during their early days. Many other competitors to AWS, such as Heroku, Google Cloud and Microsoft Azure offer similar services in what has now become a $1+ trillion dollar industry. Cloud computing solved one of the major pain points that plagued many upstart Web2 companies.

Building in Web3 before Saga

Similar issues exist in Web3 today: projects must either choose to deploy to a third-party blockchain (i.e. Ethereum, Polygon, Avalanche or Solana) or choose to build, manage and recruit for their own blockchain (Cosmos). Web3 projects that deploy to an existing blockchain are beholden to the design decisions made for those chains: on Solana, there are issues with congestion; Ethereum bakes in high costs for end-users; and for Avalanche and Polygon, it is difficult to build secure applications. Furthermore, because blockchains can often hold billions of dollars of value, most existing networks tend to favor security over upgrades that can make a chain faster, more efficient or more expressive — it took Ethereum over 6 years to change its consensus mechanism to reduce energy consumption. When deploying to an existing blockchain, what you get today will likely be what you will use tomorrow.

For Web3 projects that attempt to build their own blockchain, there are another set of issues. Consider the Cosmos ecosystem. Over the last eight years, the core Cosmos community has shipped an amazing set of open-source software to enable anyone to build their own blockchain. This software includes: Tendermint Core — a first class Proof of Stake consensus algorithm, Cosmos SDK — a software development kit to add functionality to a blockchain, CosmWasm — a secure smart-contract platform based in Rust, and Inter Blockchain Communication (IBC) — the crown jewel of the Cosmos tech stack that allows for blockchains to talk with one another. Despite all these technologies being completely open-source, Jin Kwon — co-founder of Saga and Cosmos OG — speculates it can still take a new team anywhere from 8–10 months to actually launch a blockchain with the Cosmos tech stack. Engineers who are experienced in Golang are needed to fully take advantage of the Cosmos SDK; engineers with experience in Rust may be required to extend smart-contract functionality to a blockchain; researchers experienced in distributed consensus and light-client architectures may also be needed to fully leverage the benefits of Tendermint Core and IBC. Beyond the engineering requirements, there is also significant Business Development needed to recruit validators to run independent nodes to support a blockchain.

Even in situations where quality engineering talent is found, and validators can be successfully recruited, success is not guaranteed. Similar to Netflix’s servers crashing on launch day, blockchains can also halt due to technical issues. Evmos — a blockchain network built on top of the Cosmos tech stack — crashed within a few days of launch due to a “critical security vulnerability”. Osmosis — another Cosmos-based blockchain that is at the center of IBC — halted for a few days because of a critical bug in their liquidity pools.

Building and upgrading a blockchain outside of the Cosmos ecosystem, where there is no set standard for building an interoperable network, is even more difficult. Take Helium for instance, a protocol that is building a decentralized Wi-Fi network that could one day compete with the coverage provided by the top Telecom giants today. In September 2022, the Helium community chose to migrate their protocol to Solana. Scott Sigel, COO of Helium Foundation noted that, “Moving to the Solana blockchain allows us to focus our efforts on scaling the network as opposed to managing the blockchain itself.” It’s interesting to note that nearly a decade after launching in 2013, Helium chose to delegate blockchain management to Solana. Building a blockchain ain’t easy.

Building in Web3 after Saga

So what do building blockchains, AWS and Saga have to do with each other? The analogy is simple: as AWS made hosting web applications easier for Web2 companies, Saga aspires to do the same for blockchains and Web3 projects. Saga’s technology is a ‘chain to launch chains’ and is a key piece of infrastructure to automate the launch of a new blockchain. The mechanism to understand how chains are launched from Saga can be seen below.

Source

A Saga chainlet is an application-specific blockchain secured using Cosmos Interchain Security (ICS), with the Saga Mainnet validators providing economic security and validation services. The validators for each chainlet are the same as those for Saga’s Mainnet, and they produce blocks according to a predetermined SLA. The provisions of this SLA include uptime requirements, running services and properly validating new blocks. Developers can request changes to the SLA to increase the throughput of their chain to the needs of their end-users. As a result, developers do not need to consider the nuances of consensus, application interfaces, validator recruitment, security design or scalability — important factors to consider when building a blockchain from scratch.

The ability to abstract away the difficulties of launching and managing a blockchain can enable much faster development of blockchain applications with fewer engineering resources. The introduction of cloud computing greatly accelerated the growth of Web2. Will the automatic provisioning of blockchains do the same for Web3? Time will tell.

Saga Token Economics vs AWS Business Model

Given the analogy to AWS, one might jump to the conclusion that Saga’s business model must be similar to AWS. This is where the analogy ends. AWS’ business model is similar to most Web2 businesses: grow top-line revenue while making your business more efficient so as to deliver bottom-line profits. To find a price for their services, AWS must balance important inputs such as competitors’ pricing, leverage over end-users, revenue targets for Amazon.com and user-stickiness to name just a few.

Saga is not a traditional business like AWS. Rather, we are a Web3 protocol that is creating a new marketplace for dedicated blockspace. Saga does not attempt to set a price for blockspace to ensure bottom line profits. Instead, our Token Economics are designed to allow for validators and Web3 projects to determine the price of dedicated blockspace. We do this via a novel auction mechanism called “Musical Chairs,” fee deposits, equilibrium price discovery, slashing, unique validator groupings, a scheduler, token inflation, token burn, and proof-of-stake security delegations. What do these terms mean and how do they create a new internet-native economy? Read our Token Mechanism and Incentives Paper or wait till Part 2 of this series.