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.
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.
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:
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:
Pricerun chainlet = max(BidWinning Set )Number ValidatorsSaga
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.
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.
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 Chorus One
Chorus One is one of the biggest 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.
In an eagerly anticipated milestone, Sei Network has successfully launched its mainnet, and Chorus One is honored to be a part of this journey as one of the network's genesis validators. As we step into this new phase, we're excited to explore the novel attributes that set Sei apart—specifically, its approach to solving one of the most intricate challenges in the blockchain landscape: the exchange trilemma.
The exchange trilemma is a puzzle that has long perplexed the blockchain community. It represents a delicate equilibrium where decentralization, scalability, and capital efficiency often seem to be at odds with each other. Achieving progress in one dimension often comes at the expense of the others, creating a complex balance that many blockchain platforms grapple with—especially when it comes to exchange platforms.
Sei Network: A Solution to the Exchange Trilemma
The history of blockchain has been marked by attempts to reconcile these seemingly conflicting goals. Striving to optimize one aspect can inadvertently hinder the advancement of others. This intricate interplay of decentralization, scalability, and capital efficiency has posed a formidable challenge, particularly in the context of building platforms for digital asset exchange.
This is where Sei Network enters the scene as a transformative contender poised to tackle the complexities of the exchange trilemma head-on. Through a strategic blend of innovation and architectural ingenuity, Sei aims to harmonize these seemingly divergent objectives.
Sei Network introduces a series of pioneering innovations that collectively challenge the trilemma:
In essence, Sei Network defies the constraints of the exchange trilemma by offering a comprehensive solution that enhances decentralization, scalability, and capital efficiency. Its monolithic architecture, innovative consensus mechanism, and pioneering features underscore its commitment to shaping the future of Layer 1 blockchains.
In the months leading up to its mainnet launch, Sei Network achieved significant milestones. A noteworthy accomplishment was the launch pool initiation for the Sei Network on Binance, announced on August 1, 2023. This marked the prelude to the mainnet launch, solidifying Sei's presence in the blockchain ecosystem. Furthermore, the official listing of SEI, Sei Network's proprietary token, on Binance on August 15th added to the momentum.
Notably, Sei Labs secured $30 million in strategic funding across two influential investment rounds, supported by prominent backers including Jump, Distributed Global, Multicoin Capital, and more.
Sei Network's journey continues to unfold, marked by advancements and partnerships that reinforce its standing in the blockchain landscape. As a monolithic blockchain geared towards solving the exchange trilemma, Sei Network is carving its niche by defying traditional limitations and offering a promising future for decentralized trading.
Staking $SEI with Chorus One
SEI can be delegated to the Chorus One via the Sei App
Current Staking APR: 8.33%
For any other questions, reach out to staking@chorus.one
About Chorus One
Chorus One is one of the biggest 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.
This step-by-step guide is designed to help you stake Ethereum on OPUS. Throughout this guide, we will break down the process into simple, manageable steps.
1. Connect Ledger to Metamask
💡 Tip: If you face the below error(0x650f), please follow this link to resolve the error.
💡 Tip: After this configuration, Metamask doesn’t have access to Ledger private keys. This configuration allows Ledger to leverage Metamask as a visual interface.
2. Enable Blind Signing on Ledger by following the steps shown in this link: https://support.ledger.com/hc/en-us/articles/4405481324433-Enable-blind-signing-in-the-Ethereum-ETH-app?support=true
You have now successfully connected Ledger to Metamask. Next step is to Login to OPUS Poral.
3. Our sales team must have sent you your login credentials. If not, please reach out to them here
4. Now, please enter your organisation name, and login with SSO.
5. Connect Metamask to OPUS.
6. Select Amount of ETH using the Slider
💡 Tip: OPUS Staking slider helps you stake up to 800 ETH(25 Validators) in one transaction.
💡 Tip: OPUS staking screen shows the backward looking APR, and projected rewards.
7. Confirm stake transaction on Metamask.
8. Approve transcation on Ledger
.gif)
You have now staked Ethereum on OPUS! To stake more, please follow the guide from step#6.
If you are facing any issues, please reach out to us at Chorus One support.
About Chorus One
Chorus One is one of the biggest 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.
Amidst the dynamic blockchain landscape, Archway Network stands out as a platform that has captured the attention of developers and enthusiasts alike. This blog delves into the unique features and opportunities that Archway offers, shedding light on its architecture, tokenomics, use cases, developer rewards, and recent activities that ascribe it as a prominent player in the ecosystem.
Archway’s Architecture: Where Innovation Thrives
Archway Network is a testament to visionary architecture. By leveraging the Cosmos SDK, Tendermint, and CosmWasm, the Archway team have built an infrastructure that excels in speed, scalability, and security. What truly sets Archway apart is its seamless interoperability through the Inter-Blockchain Communication (IBC) protocol, which fosters a cohesive ecosystem where data and value can flow freely between different blockchains.
Unlike L1 blockchains that primarily focus on token distribution to early participants, Archway takes a different approach. It recognizes the value and impact of developers and builders by incentivizing them based on their contributions to the network. This unique model aims to level the playing field among developers, providing equal access to capital and support, regardless of their connections or associations.
Tokenomics: Incentivizing Developer Contributions
Archway introduces a novel approach to developer rewards by exploring revenue distribution alternatives. Beyond gas fees, developers building on the network are incentivized through a meticulously designed combination of gas rebates, inflation, and premiums. This multifaceted reward system ensures that developers are recognized and rewarded for their invaluable contributions to the network.
Gas fees are not just divided up among validators and dApps, but split evenly between them, ensuring a fair distribution of rewards. But Archway doesn't stop there—it pushes the boundaries further. With the inflation rate at 10% and expected APR ranging around ±21% at launch, developers have a stake in shaping the network's future.
A quarter of the inflation is allocated to the dApps rewards pool, a vibrant ecosystem where developers are rewarded based on the gas generated by their applications within a given epoch. Additionally, developers have the freedom to set custom fees for interactions with their smart contracts, enabling them to earn 100% of the charges and fostering a direct stake in their application's success. By seamlessly embedding these fees within the network fee, Archway Network delivers a user-friendly experience, sparing users from the complexity of multiple fees.
Use Cases
Archway Network opens up a wide range of possibilities for developers and entrepreneurs. By rerouting their rewards to a shared pool, developers can subsidize gas fees for users, creating a more familiar and accessible experience akin to traditional web applications. This user-centric approach revolutionizes the way people interact with blockchain-powered applications, removing the burden of high transaction costs and propelling mainstream adoption.
Moreover, Archway Network empowers developers to swiftly launch their dApps without the need to bootstrap a standalone chain. For early-stage projects struggling to secure funding or establish a secure blockchain, Archway provides a springboard for testing product-market fit and scaling ambitions. Developers can prototype and iterate on Archway before transitioning to their own appchain or rollup, amplifying their chances of success.
Archway isn't solely focused on providing a versatile blockchain infrastructure—it also fosters a vibrant and supportive developer community. By offering a plethora of hackathons, workshops, grants, bug bounties, and developer-focused initiatives, Archway stimulates a culture of innovation and collaboration. Developers are incentivized to create new modules, tooling, and applications that enrich the ecosystem and unlock new possibilities.
Check out some of Archway’s key initiatives here:
Hackathons: https://blog.archway.io/tagged/hackathons
Workshops: Archway Workshops
Grants: https://blog.archway.io/accelerating-value-capture-the-archway-foundation-grants-program-40f3edbdf9
Governance
Archway Network implements a governance model that allows participants and token holders to actively shape the protocol's future. Through proposals and on-chain voting, Archway's decentralized community can influence the direction of the platform. Governance is facilitated by their native token, $ARCH, which ensures fair and transparent participation. Holders of the token can propose changes and vote on active proposals, with consensus being reached through a defined threshold. Engaging with the Archway community involves actively participating in governance by submitting proposals or casting votes on existing ones.
Recent Developments
In its relentless pursuit of excellence, Archway Network has achieved several milestones that highlight its potential as a catalyst for change. Notably, the launch of its incentivized testnet, the successful completion of multiple security audits, and the adoption of WebAssembly (Wasm) have garnered attention from developers and blockchain enthusiasts alike. Now with the mainnet launch, Archway is poised to reshape the blockchain landscape, offering an unprecedented level of developer empowerment and accessibility.
Deep Dive into Archway network: https://www.youtube.com/watch?v=TCoTNlzohIo
Useful resources:
Website: https://archway.io
Twitter: https://twitter.com/archwayHQ
Medium: https://medium.com/@archwayHQ
Github: https://github.com/archway-network
Docs: https://docs.archway.io
Discord: https://discord.com/invite/5FVvx3WGfa
Reddit: https://www.reddit.com/r/Archway/
Telegram: https://t.me/archway_hq
Staking $ARCH with Chorus One
Inflation rate: 10%
Staking APR: expected ±21% at launch (with 35% ARCH staked)
To start staking with Chorus One, reach out to staking@chorus.one.
About Chorus One
Chorus One is one of the biggest 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.
We take a look at expected times to participate in Ethereum staking.
Ethereum protocol times are measured in epochs, with 1 epoch being 384 seconds or around 6 and a half minutes. For ease of understanding, times based on these measurements have been translated roughly into minutes, hours and days.
88,885 / 25
Source: https://beaconcha.in/
Conclusion: Staking takes at least 8 hours, but it is very likely to take a lot longer as the demand to stake grows and more validators are added to the queue (the queue at the time of writing is 88,885 validators waiting). The waiting time right now is about a month and a half.
88,885 / 25
Source: https://beaconcha.in/
Conclusion: Unstaking takes at least 25 minutes, but can vary depending on the withdrawal queue with a similar model as staking (the queue right now is 25 validators waiting and is expected to clear quite quickly). You also have a 1 day delay to access funds. So, all in all the waiting time right now is about 1 day.
* This number corresponds to the churn rate applied to the staking and withdrawal queues. For every 65,536 additional validators that are active on the Ethereum network, the number of new validators that can be activated per epoch increases by one, and the number of validator exits that can be processed per epoch also increases by one. Right now, the churn rate is 9.
Polygon is a Layer 2 scaling solution built on Ethereum that aims to provide multiple tools to improve the speed and reduce the cost and complexities of transactions on blockchain networks.
Overview
Ensure that the browser has integrated any of the wallets supported by Polygon.
Click on ‘Chorus One’ to verify all the details. Ensure that the Validator address (shown as ‘Owner’) is 0xbbd83024be631bb6f3dd3c0363b3d43b5d91c35f.
Note: The commission rate to stake $MATIC with Chorus One is 5%.
You have now completed the process and staked your $MATIC with Chorus One!
About Chorus One
Chorus One is one of the biggest 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. We are a team of over 50 passionate individuals spread throughout the globe who believe in the transformative power of blockchain technology.
After three rounds of rigorous testnets, the Sui Network Mainnet is live, and Chorus One is proud to support the network as a genesis staking provider and validator.
What is SUI?
Sui Network is a permissionless Layer-1 blockchain and smart contract designed from the ground up to make digital assets ownership fast, secure, and accessible to the next generation of Web3 users. Its pioneering architecture is implemented to create a world-class developer experience, in addition to vastly improving performance and user experience of L1 blockchains.
Sui Move
Sui uses Rust and supports smart contracts written in Sui Move - a customized version of the Move programming language that enables the definition and management of assets with owners. These assets can be created, transferred, and mutated through custom rules defined in the smart contract, offering a flexible way to manage digital assets on the blockchain. This enables a vast range of use-cases such as tokens, virtual real estate, and more.
SUI’s unique design features
Sui has a unique system design that allows it to scale horizontally and handle a high volume of transactions at low operating costs. Unlike other blockchains that require global consensus on all transactions, Sui enables parallel agreement on independent transactions through a novel data model and Byzantine Consistent Broadcast. This approach eliminates the need for global consensus and enhances scalability without compromising safety and liveness guarantees.
The object-centric view and Move's strong ownership types enable parallel execution of transactions that affect different objects while transactions that affect shared state are ordered through Byzantine Fault Tolerant consensus and executed in parallel.
Sui’s scalability characteristic is highly innovative and distinct from existing blockchains that have bottlenecks. Currently, most blockchains have limited capacity to handle a high volume of transactions, resulting in slow processing times and expensive fees. This can lead to a poor user experience, particularly in gaming and financial applications. Sui addresses these issues by scaling horizontally to meet the demands of applications. It does this by adding more processing power through additional validators, resulting in lower fees and faster processing times even during periods of high network traffic.
Sui allows developers to store complex assets directly on the blockchain, which makes it easier to create and execute smart contracts. This results in low-cost and horizontally scalable storage that enables developers to define rich assets and implement application logic. With this capability, new applications and economies can be created based on utility without relying solely on artificial scarcity.
SUI Tokens
Sui’s native token, SUI, has a fixed supply and is used to pay for gas fees. Additionally, users can earn rewards by staking their SUI tokens with validators like Chorus One. To learn more about how you can stake SUI with Chorus One, visit: https://chorus.one/articles/how-to-stake-sui-sui-network
Sui Use Cases
Sui enables developers to define and build:
Staking $SUI with Chorus One
SUI can be delegated to Chorus One delegation pool
Current Staking APR: 8.3%
For any other questions, reach out to staking@chorus.one
Useful links, tools, and resources
Website: https://sui.io
Twitter: https://twitter.com/SuiNetwork?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor
Docs: https://docs.sui.io/learn/about-sui
Explorer: https://suiscan.xyz/mainnet/home
Discord: https://discord.com/invite/sui
GitHub: https://github.com/MystenLabs/sui
About Chorus One
Chorus One is one of the biggest 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. We are a team of over 50 passionate individuals spread throughout the globe who believe in the transformative power of blockchain technology.
At Chorus One, we have a strong conviction in the potential of a multichain future. We believe that specialized blockchains play a crucial role in discovering and nurturing new use cases, and ultimately driving mainstream adoption. Since joining Chorus One about two years ago, I've been pushing for us to do the same in the Avalanche ecosystem as these two ecosystems have similar visions of what the multichain future can, should, and will look like.
Last year, we entered the Avalanche ecosystem. Our work will only intensify in the coming years with Chorus Ventures, our ventures arm, investing in native Avalanche projects. We also use our expertise in tokenomics and infrastructure to help projects launch their permissionless subnets. We will be presenting this topic both at the online Subnet Summit mid April and the Avalanche Summit II beginning of May.
In my view gaming is key to onboarding the next wave of users and a fundamental step in the road to mass adoption. This article aims to present the exciting future of blockchain gaming and demonstrate how the Avalanche architecture, particularly the multichain subnet architecture, is the ideal substrate for this vision. Through a two-part series, I will illustrate how one can develop an unstoppable game. By unstoppable, I mean a game that not even its creators can censor or stop if one day they move on to other projects. A game in control of its users.
So let's get to it.
To make this exercise as clear as possible I will look at a game I have plenty of experience with having played around 2000h. The game in question is Path of Exile, in my personal opinion the Diablo killer. This game needs no introductions but:
A short video:
Take a look here for some more gameplay videos.
I cannot emphasize enough how deep the economics goes in this game. The reason being that its economics are fundamentally tied to the crafting system for equipment and to the simple fact that you need to craft gear yourself or buy it from someone if you want to reach the endgame. Purely random drops cannot take you there.
Every season a "league patch" is released with new contents and the economy is reset. Characters and loot from previous seasons are still available to play in the "standard" league and the standard league economics are interesting in their own right but as a driver for innovation and to give new players the ability to compete in a more level playing field, these resets are very important.
The goal is thus to envision a version of PoE that is unstoppable and in the hands of gamers. You might ask: why would developers make such a game? To which I answer: the first one to do this becomes a first mover in a technology that soon will be expected from all games. And why will this be expected? Why do gamers want this? Well, this is a game you can continue playing and you can really own it. Like how it was in the dawn of console gaming. Be it real or game money, you can trade assets and no one can censor you. If you recall the anecdote, this was the reason Vitalik started his work in crypto.
In the centralized world, an ARPG like Path of Exile consists of a client/server platform where the server infrastructure is run by the game developer, and where the client freely available or purchased in a marketplace. Next, we will look at the features and responsibilities of the server side as this will be where our decentralization efforts will mostly focus.
The ability of client-side tampering with binary can cause all types of attacks/cheating. This is an arms race but currently, it is tackled via lock-step state validation. More on this later.
Most games need randomness. For anti-cheat reasons, this is taken care of at the server level. In the case of PoE (and ARPG more broadly) this is even more important as loot, damage, map layout, and even AI are parameterized by random inputs.
Of fundamental importance for a healthy in-game economy is that the more powerful items are, the rarer they should be. That is, their drop rate should be lower. This is accomplished by drop-rate lookup tables that are set and maintained by the server. Again due to anti-cheat measures, it is the server that, when appropriate, generates a random drop.
Even in PoE which tends to be dominated by PvE (player versus environment), there are situations where players interact: regions where PvP (player versus player) are allowed and sanctuary environments also called player hubs. These interactions need to be facilitated by the game server.
Special trading windows and functionalities are implemented so that players can exchange goods in a safe way.
Looking at the above set of functionalities that the server must provide, we can identify three different types of backends that the server infrastructure needs to maintain. These are the components we will need to "permissionlessly" decentralize. The following figure gives an idea of how the server-side interacts with these backends and the client (overlap indicates communication).
There is a need for queryable databases, with loot tables clearly being one such need. But many more are present: leaderboards, player info, skill table, effect mechanics, and many more.
A key-value store that can deliver monolithic "chunks of bytes" is also a necessary backend. The game needs to ship itself and its updates with a big proportion being graphical assets. For this dedicated content-delivery networks are employed.
As mentioned before the server infrastructure needs to be able to keep clients in sync across PvE and PvP both for anti-cheat purposes and for facilitation of user interactions.
So why is Avalanche especially suited for this exercise? How will the architecture of such a game change and what technologies do we need to leverage to accomplish our goal of a decentralized, unstoppable ARPG game?
Avalanche has two genius breakthroughs in its design: its consensus being the first and the subnet architecture being the second. The latter is highly dependent on the former. Let's see why.
Avalanche consensus is without a doubt the most advanced consensus out there and is correctly categorized as a third type of byzantine fault tolerant consensus following the discovery of signature accrual and Nakamoto consensus. It is the first meta-stable type of consensus algorithm. This consensus enjoys enviable properties: it scales easily with the number of validators, it is leaderless, and single-slot final. I won't go into much detail but suffices to say it accomplishes all of these by being a consensus algorithm based on a statement about an emergent property of the system. Let me explain what I mean. You can think of the network as having the property of being consistent (all validators agree on the current state). In Avalanche this property is emergent. Like the temperature of a gas, it exists as a property derived by the local interactions of its constituents “particles”. In the case of the gas, particles bouncing of each other exchanging kinetic energy in their small neighborhood gives rise to the macroscopic property of temperature. In Avalanche, validators are the particles and contrary to other consensus mechanisms they interact only “locally”, that is, with a small number of validators that are randomly selected in each round. Somehow - and here there is a strong mathematical theorem behind it - this is enough for the network to have a well-defined sense of state history. Even in the presence of attackers.
It is the property of essentially limitless scaling in the number of validators that allows for the second genius move. You see, Cosmos is the originator of the concept of an app-chain. In this design, it is absolutely necessary that chains can "talk" to each other to really cover all the use cases one is interested in. For this reason, they developed the IBC framework. This is an elegant framework for trustless communication but it incurs a significant requirement to a prospective chain: as a destination chain you need to keep consensus information of any given source chain you want to communicate with in the form of a light client. Wouldn't it be ideal if this information would be globally available to all chains from all chains? This is impossible with a limited set of validators.
So to have an unlimited set of app chains that can trustlessly communicate without having to keep light clients of every other chain they communicate with you need an unbounded set of validators in a global chain that keeps all this information. I hope you see where this is going: this is exactly the subnet design.
In Avalanche the main network that every validator must secure contains three chains. The P-chain (Platform chain), the X-chain (eXchange-chain) and the C-chain (Contract chain). The X-chain - which us currently a DAG but will become a linear chain in the near future - is a chain made for throughput exchanges of assets much like a blazing fast Bitcoin network. The C-chain is what most users are more familiar with and is an EVM based chain. It works just like Ethereum but faster and with instant finality. Great. But the real genius comes from the P-chain. This chain tracks all validation related transactions of the mainnet and all subnets. This is what will enable the unbounded, composable network of app chains. Since all validators have the P-chain at hand, any two subnets can communicate directly provided they want to. In IBC, on the other hand, with its hub-and-spoke design you have the unaddressed issue of path dependence.[^1]
So, we will leverage an Avalanche subnet for our game. Main reasons are the excellent scaling properties of its consensus and the application-specific, isolated nature of the subnet approach. On top of that it supports cross-subnet transactions allowing for valuable assets to move around freely in the ecosystem. Finally but not least, there is also VM2VM message passing that allows the validators in a subnet to easily check the state in other connected VMs be that within the same subnet, in the mainnet, or another subnet running in the same validator (the latter has not even been explored yet).
An Avalanche subnet is essentially the following:
The set of validators is dynamic but can be either permissionless or permissioned. The specification of a blockchain is comprised of a specification of a subnet this blockchain pertains to and the specification of a VM (i.e. virtual machine) that characterizes the valid state transitions in that blockchain.
Ava Labs recently announced HyperSDK a toolkit not much unlinke the CosmosSDK to help developers easily build VMs to power their subnet. From now on, they can focus on the logic of the application and worry much less about synchronization, consensus, state storage and availability and other blockchain-heavy topics. On the other hand, if you want to, you can customize these aspects as the SDK was build with modularity in mind.
See Avalanche platform and Subnets sections in the Avalanche documentation for more information on subnets and visit the HyperSDK repository which is open for contributions.
As mentioned before, our intent is to decentralize the game. For this, we will need to decentralize the server infrastructure, mainly the three points named above: databases, content delivery, and anti-cheat logic. This will be done by defining specialized VMs and the corresponding blockchains for each of those game infrastructures. All of this is packaged in the game server binaries which will be run by the validators in the subnet.
A game client will essentially be submitting transactions to the server network. Clearly, the game client is responsible for client-side rendering which is something we do not need to bother with on the server side. In terms of execution hardware, the game server is much lighter than the client and we will exploit this.
Keep in mind that being a player does not mean you can’t be a validator as well or a delegator to a Chorus One validator ;). This is obvious but worth mentioning as this means that for the first time ever a game can actually be in the hands of the players. With governance, even the game features and roadmap can be decided, paid for, and rolled out completely in a decentralized fashion.
So the big question: what are the blockchains, VMs and technologies used for this purpose? We dive in.
The BlobVM already exists in an advanced prototype stage. It was developed by Ava Labs and is available in open-source. What it does is provide a dedicated, seamlessly integrated (at the subnet level) content addressable storage with customizable parameters regarding permissions for read/write and persistence.
We use BlobVM for storing all art, texture, and models, i.e., all game assets. Even the game client binary can be updated via this method. In a fresh install, an externally downloaded game client connects, and sends a transaction to download all necessary assets. Note that this transaction could be a way to monetize the game but this is optional of course. In other words, this transaction would give you a game license NFT.
Now as mentioned before we want to give power and value to the gamers. Path of Exile is famous for its rich economy and is a formidable laboratory for NFT tokenomics. By giving the gamers the option to mint any found loot item we give this economy real value. There is plenty of opportunity and pitfalls here to fill in another article but it is important to mention that PoE works by having multiple “leagues” which give an opportunity to always “reset” the economy and give chance for new players to “make it”. We think this is an important aspect to keep in the decentralized version of this game. As an example of how we could explore this, we can configure it so that minted NFT only work on the current and previous leagues.
For tracking a gamer’s collection we use AVM, the Avalanche VM, which is a DAG (directed acyclic graph) based on the UTXO model capable of massive throughput. In fact, this is the underlying VM of the mainet’s X-chain. Note that since the announcement of Cortina (the next dot release of the Avalanche validator client) the X-chain will move from being a DAG into a linear chain. Here we have the option of launching out own AVM chain for assets transfer or, use the X-chain directly which would make all of the game’s NFT directly available to the wider Avalanche community (NFT reuse in games is an under-explored area). The AVM supports ANTs or Avalanche Native Tokens that can easily be imported/exported across the majority of supported VMs as it defines a unified API for cross-chain atomic swaps.
PoE is a free-to-play game that monetizes itself via cosmetic-only user-purchasable content. This can be easily supported via the AVM chain as well. Simply: an NFT in the user wallet ”unlocks” these assets to be delivered via the content delivery mechanism. This is essentially a VM2VM communication as is desirable and quite probable that the X-chain will support account lookups via this mechanism.
As mentioned before, as with any modern application, the game needs to store global relational data. For example, loot tables, league-specific information, game metrics, user metrics, NFT market data, etc. The list goes on and on. For this specific use case currently, many web3 projects use The Graph: a sophisticated but complex decentralized solution. A few issues arise with this approach:
Because of these, we propose a new type of VM we dub SQLVM and this will be the topic of our next article. But in a nutshell, you should think of it as a hybrid between a app-specific indexer and a persistent relational data store.
It allows for specific types of transactions that query/write to a globally replicated ACID relational database. Here we automatically benefit from the fact that blockchain transactions are atomic at the consensus level which makes designing the underlying database much simpler. For example, a suitable design can be done for a VM where the runtime state is an instance of any query engine: row-oriented like Postgres, column-oriented like BigTable, or document-based like MongoDB. Keep in mind that even this is overkill as we don't need their replication features. What we need is their query engine and storage solution. Most of these databases have sophisticated query planners than can take the place of fee estimators. The beauty here is that Avalanche will take care of maintaining this database eventually consistent which suffices for our use case. More sophisticated designs are certainly possible. The job of the VM here is to essentially declare the types of transactions (write/reads), the fees and verify the blocks by applying the transactions in the database and updating certain database hashes (will be needed for anti-cheat below). For our game - or any other app chain using this backend - other VMs in the subnet should be able to read the database at will which can easily be done with VM2VM.
Similar to how a non-validating Avalanche node have access to the mainnet state, a game client could be a node of this chain running in non-validation mode so as to keep this database state at all times for easy synchronicity.
Now to the technologically most innovative piece of the puzzle: to run anti-cheat as a ZK verifier. This is such a breakthrough technology that it would be an improvement over existing anti-cheat technology on centralized games.
Anti-cheat works, as mentioned before, as lock-step game simulation. What this means is that the game client is essentially an input system and a rendering engine of a game that is actually run remotely on servers. This Introduces latency which is the reason why game server farms have to be deployed across internet “regions”. ZK changes the game as it allows one to codify all game state transitions in a prover which we can run on the game client (remember the gamers tend to play with machines that are quite powerful) while the server is just a verifier! This has the added benefit that it even liberates the server from having to run in lock-step, to begin with! Essentially we can use eventual consistencyto catch the cheaters. Put differently, we don’t care to verify every little state transition that happened but batches (or recursions) encoding all transitions that happened in a configurable time window: 1 second, 10 seconds, a minute, an hour…
It is obvious what a powerful idea this is: no need to simulate full-blown games on the server. For example, we now can use more sophisticated AIs in the client. The fact that you have to run the game on the server is one of the reasons no modern AI is in use in games. Why not use GPT-4 for creating procedural quests??
We will have more to say about a ZKVM in a future article but I would like to state a few things. Firstly, note that we are not even using the zero-knowledge aspect of this VM and this gives more freedom in the exact construction of the protocol. In precise terms we are interested in SNARKS not necessarily ZK-SNARKS. Nonetheless, we expect that applications that use this zero-knowledge aspect will also exist.
Secondly, we might not be at the stage yet where fast enough provers exist to prove the state transition for a game like PoE. I'm not an expert, but I expect that schemes leveraging the GPUs in the gamer's clients will be just a matter of time.
And finally, we are talking about a very specific VM - that of the game - and not a generic programmable one like the EVM. We need a prover for those exact transitions that happen in game. This is potentially another route for optimization.
We hope to have convinced you that the future of decentralized gaming and player-owned gaming is bright. When Vitalik joined the crypto movement I don't think he thought his dream would come true on another chain, but I think he will be satisfied nonetheless.
But more importantly, we hope the reader is also convinced that this is only possible in a clean, elegant, and reusable way via the subnet architecture. Sophisticated applications like this will only flourish when good reusable VMs are available much like reusable contracts are right now. Multiple VMs demands multiple chains in a subnet architecture. Although technically possible to cram all of these backends into a single block to be serialized/deserialized and verified using a single chain, this would not only hurt code reuse but is also impractical since it is clear that these backends might need different blocktimes.
Of course, there are a lot of unknowns to this as I am not a game developer. I just want this to jump-start the imagination of developers in general (not only game developers) to the reality that the future is app-specific multi-chain subnets. And so that someone develops an unstoppable ARPG like Path of Exile!!
Tune in for some follow-up articles on where we attempt to detail somewhat the SQLVM and ZKVM and come talk to us in the summit. See you there!
Chorus One is one of the biggest institutional staking providers globally, running infrastructure and validating over 40 blockchain networks. Since 2018, we have been at the forefront of the PoS industry and now offer enterprise-grade staking solutions, industry-leading research, and also invest in some of the most cutting-edge projects through Chorus Ventures. We also invest in subnets on Avalanche so if you’re building something interesting, reach out to us at ventures@chorus.one.
