Pegasus Overview
Last updated
Last updated
Standing up your own blockchain is hard. Developers need to become experts at blockchain infrastructure and balance security, decentralization and scalability of their infrastructure themselves. In modular systems, it becomes even more complicated. The developer needs to manually piece together data availability, consensus, execution and settlement and manage the blockchain trilemma (security, decentralization and scalability) for each component separately.
We need to unblock developers with an entirely different approach.
Saga makes launching a dedicated blockchain, or Chainlets, as easy as deploying a smart contract. We accomplish this by offering an integrated stack of all the necessary components needed to launch a chain into a single product experience for Chainlets.
We are now in the first phase of launching Pegasus, our next release. Pegasus builds on top of the work already put into our first release, maintaining a focus on security. Pegasus introduces security into the Saga system in multiple ways.
Security is at the heart of the Pegasus Release
First, Pegasus introduces staking to Saga. With the release of Pegasus, assets with value can be staked to secure the Saga Mainnet.
Second, Pegasus introduces shared security with Chainlets using Cross Chain Validation (CCV). Security from the Saga security chain will be shared with all of our Chainlets, allowing our developers to never worry about securing their infrastructure.
Third, Pegasus decentralizes the validator set running Chainlets. With Pegasus, all infrastructure in Saga was run by a set of four validators run by the foundation. With Pegasus, we introduce key innovations in our stack to enable external validators with different infrastructure to support running Chainlets.
First revealed at the Saga Multiverse Summit in August, Pegasus has undergone accelerated development from its original roadmap to support both Saga’s Innovators and partners.
The Saga Protocol offers an integrated stack of automated, high performance, gasless, interoperable and customizable chains, called Chainlets. The Saga Chainlet Realm will be the main Realm on the protocol. Earlier this year, Saga unveiled Realms, the technical manifestation of the Saga Multiverse - Saga’s platform that allows disparate tech stacks and IPs to deploy on the protocol and interact with each other through parallelized and interoperable dedicated chains.
Saga Realms enables developers to launch customizable chains on Saga with different features and services such as technology stack, security source and various obligations for those sources. Under the framework of Realms, the standard Saga Chainlet became one Realm of many that will be supported in the near future, including those for our partners at Ethereum (Ethlets), Polygon, Avalanche, Celestia, XPLA and many others.
To support configurable Realms out of the gate, Pegasus will be divided into three components: security chain, platform chain and Chainlet.
The security chain is the first security source for the Saga protocol. This is where the $SAGA token is minted, staked and ultimately slashed if there is validator misbehavior. Saga’s security chain is built using the Cosmos-SDK.
The platform chain is where the developer launches and maintains their Chainlets. The platform chain aggregates security from multiple security chains and forwards that security to the launched Chainlets. Aggregation and forwarding of security is done through Cross-chain Validation (CCV). CCV is an innovation pioneered by Cosmos, and Saga uses a modified version of Cosmos CCV. Any misbehaviors relayed by Chainlets are ultimately forwarded back to the security chain, where slashing will ultimately occur. The first security chain that the platform chain will aggregate security from will be the Saga security chain. However, in the future, the Saga platform chain will derive security from other sources such as our partners at Ethereum, Polygon, Avalanche and other stakers and validators. The platform chain is built using the Cosmos-SDK.
The Chainlet is where all computation actually happens. The end user interacts with one or more Chainlets. The platform chain forwards security from the security chain to the Chainlets. Any misbehavior in Chainlets are first relayed back to the platform chain. The first supported chainlets are built using the Cosmos-SDK but there will be other types including Avalanche Subnets and Polygon Supernets.
Pegasus is the release that will be used for Saga protocol V1 launch. For further details check out here.
To ensure a successful launch of the full Saga protocol V1, the launch will be divided into six progressive phases. Each phase builds on top of the previous, and the full-featured Saga protocol V1 will have completed launch at the end of phase six. The full progressive launch schedule is shown below.
The most significant effort in Phase 1 is the launch of the security chain. During this phase, the platform chain and Chainlets launched from the platform chain will be operated by foundation validators (not the security chain validators). The security chain validators will be external and decentralized, and will almost inevitably have participated in our Incentivized Testnet. Cross-chain validation (CCV) will not be supported from the security chain to the platform chain and to the Chainlets.
Developers can begin launching Chainlets that will persist through all the phases. In other words, their applications and smart contracts will be live in a production environment that users can interact with. Upgrading to successive Mainnet phases will be done automatically on the backend, so developers will not need to worry about manually upgrading.
Developers will still need to request test tokens from the foundation to launch Chainlets (Controlled Permissioned Access). Our Innovators will be provisioned with keys to have test tokens automatically fauceted to their wallets for funding their Chainlets.
Stakers can start staking assets to secure the network and earn inflation rewards.
Validators need to launch and maintain the security chain only. External validators will not be running the platform chain and Chainlets.
End Users can begin using launched Chainlets.
Phase 2 introduces basic CCV from the security chain to the platform chain. The platform chain will be secured using CCV with a hardcoded foundation key. This is the first step in converting the platform chain into a security aggregator. This phase will also test drive whether validators are able to successfully upgrade the security chain.
Developers (No Changes)
Stakers (No Changes)
Validators need to upgrade the security chain.
End Users (No Changes)
Phase 3 then shares the aggregated platform chain security to the individual Chainlets. In other words, each Chainlet will now inherit the security of the platform chain. In this instance, the relayed security is still only a hardcorded foundation key. However, the subsequent phases will introduce more and more security into the platform chain. This phase will also test drive upgrading a production Chainlet and platform chain.
Developers (No Changes)
Stakers (No Changes)
Validators need to upgrade the security chain.
End Users (No Changes)
Up until now, the platform chain and Chainlets were not operated by external validators. Phase 4 is where we begin onboarding validators in the security chain to start operating the platform chain. Running the platform chain means these validators will also need to run every chainlet launched by the platform chain. A proof of authority set of validators from our security chain will start operating the additional infrastructure. The platform chain will now be secured using CCV with the PoA validator keys.
Developers (No Changes)
Stakers (No Changes)
Validators: External validators will need to start running the platform chain and all Chainlets.
End Users (No Changes)
Once the PoA platform chains and Chainlets are stable, we can onboard the entire set of security chain validators to run the platform chain and Chainlet infrastructure. At this point, the full security chain security is aggregated on the platform chain, which gets forwarded automatically to all Chainlets.
Developers (No Changes)
Stakers (No Changes)
Validators (all) will need to start running the platform chain and all Chainlets
End Users (No Changes)
Finally, we can enable slashing on the security chain. Any misbehavior on any Chainlet is forwarded back to the platform chain, which relays it to the security chain. This is the point where audits will be finalized, and the $SAGA token will begin to be used for provisioning Chainlets. The developer portal will now be permissionless and no longer be controlled access.
This will complete the progressive launch of the Saga protocol V1.
Developers will need to begin paying for Chainlets using $SAGA tokens instead of Testnet tokens. The developer UX will now be permissionless and no longer be controlled access. Up to this point, the incremental changes between the phases have been largely on the backend, and there would have been little to no noticeable change for the developers or their end users.
Now, however, there will be fast interoperability between the Chainlets and bridging out to other ecosystems, which will enable any assets to be transferred in and out of Chainlets at the speed of settlement allowed on the chain receiving the assets. This also means Chainlets are now fully elastically scalable and can have the same level of flexibility as typical cloud instances.
Stakers (No Changes)
Validators (No changes)
End Users (No Changes)
The progressive nature of this launch means that we can incrementally test out each major component to isolate issues along the way. This kind of agile launch ultimately means a faster and more secure path to achieving the full launch status. Carefully planning each step means that every stakeholder can experience a much smoother ramp up to the complete Saga protocol launch.
The onboarding experience for validators is progressive. Phase 1 requires the validators to test out the launch of a singular chain. Then, a few upgrade cycles later, certain validators will need to launch a second chain (platform chain) and make sure their infrastructure is ready to spin multiple Chainlets on demand. Finally, the whole validator set will be running the platform chain.
Keep in mind that the launch process for a decentralized proof-of-stake chain on Saga is entirely permissionless and automated. We are taking a process that was previously painful and cumbersome for even one chain and allowing developers to access a completely streamlined version as many times as they want. Our engineering team has spent most of their time making sure we have the validator tooling to make this a manageable burden on our validator sets, but we are doing something entirely new. The best way to guide the validators through launch is through a phased approach.
The Saga progressive launch is designed such that Chainlets are fully production ready at Phase 1. This is the earliest possible point at which we can deliver a secure chain-to-launch-chains to developers so that their applications can go live and welcome user activity. Additional features will be added throughout the launch phases to enhance functionality, and these features will be clearly communicated to developers so they can in turn let their communities know.
However, any Chainlet launched during the progressive launch process will have security automatically migrated between phases. The goal is to have minimal to no disruption to the developers’ Chainlets as the launch phases are completed.
The stakers and hodlers have access to the $SAGA tokens immediately at Phase 1. Saganauts can begin securing Saga before the platform chain is fully decentralized. The progressive launch significantly de-risks the stakers’ and hodlers’ assets.
The end users of Saga can start using and interacting with their favorite Chainlet applications as soon as Phase 1 is complete.
Here are some of the main features of Pegasus (Phase I) Mainnet:
Saga Security Chain to mint the $SAGA token, allow staking and slashing, which is completely decentralized
Saga Platform Chain, used to launch chainlets, which comes with a geographically distributed set of Saga Foundation validators
A Saga Web App for managing chainlets
A CLI based wallet compatible with many types of key stores, including Ledger
Community managed escrow accounts for funding chainlet uptimes and operations
On-chain billing history for each chainlet
Ability to perform live chainlet updates for security updates or enhanced features
Dedicated RPC infrastructure for each chainlet, supporting both JsonRPC and Websockets
Dedicated Blockchain Explorers for full visibility into blocks, transactions and on-chain assets