Argus: Why We Are Reviving Sharding from Dark Forest.

Original Title: "Why does Argus use sharding to build a full-chain game infrastructure?"

Original translation: CaptainZ

This article is a speech given by Scott, the founder of Argus Labs, at Research Day. Scott graduated from Berkeley and was a member of eGirl. He previously participated in the creation of the well-known on-chain game, Dark Forest. In this speech, Scott not only shared his experiences and difficulties during his time at Dark Forest, but also explained why Argus chose L2+ sharding to build its game engine. The following is the full text of the speech translated by Twitter user CaptainZ (@hiCaptainZ):

Hello everyone, I am Scott (@smsunarto), the founder of Augus Labs (@ArgusLabs_). Today, I want to discuss a topic that we haven't touched on for a while. As roll-ups become mainstream, our discussions on execution sharding are not as frequent as those on data sharding. So, let's take a fresh look at this somewhat neglected topic - execution sharding.

This will be a relaxed conversation. I know you have been listening to complex concepts all day, so I will try to make this discussion as practical as possible. I have prepared appropriate slide designs for this presentation.

For those who don't know me, it's interesting that I'm known as the anime girl on Twitter. I also missed my college graduation ceremony to come here, which made my parents very unhappy. Currently, I am the founder of Argus Labs. We consider ourselves a gaming company, not an infrastructure or cryptocurrency company. One of my biggest frustrations is that everyone in the crypto gaming space wants to build tools, but no one wants to create content or applications. We need more applications that actual users can use.

Previously, my intelligent friends Brian Gu (@gubsheep) and Alan Luo (@alanluo_0) and I co-created Dark Forest (@darkforest_eth) in the encryption industry. Brian is now operating 0xPARC (@0xPARC) and he is much smarter than me.

Today's discussion will focus on the execution of sharding, but in a context where most people are unfamiliar with the discussion of executing sharding. We usually discuss executing sharding in the context of Layer1, such as Ethereum sharding or Near sharding. But today, I want to change the context. Let's think about what sharding would look like in a roll-up environment.

The basic question here is why a gaming company would build its own roll-up, and what we can learn from World of Warcraft to design roll-ups. In addition, we will explore how the design space of roll-ups far exceeds current reality.

To answer these questions, let's go back to 2020 when the idea of Dark Forest was first conceived. We asked ourselves, what if we created a game where every action was a transaction on the blockchain? At the time, this premise was absurd and still is for many today. But it was an interesting hypothesis, so we built it, and Dark Forest was born.

Dark Forest is a completely Ethereum-based full-chain space exploration MMORTS game, powered by ZK-Snarks. Back in 2020, ZK was not as popular as it is today, as there were almost no documents available. The only available documentation for Circom was Jordi Baylina's (@jbaylina) Google Docs. Despite the challenges, we learned a lot from the process, and Dark Forest is a testament to that learning.

Dark Forest is a larger experiment than we imagined. We have over 10,000 players who have spent trillions of gas, and the game is full of chaos, with people stabbing each other behind the chain. The most attractive thing about Dark Forest and on-chain games is their platform nature. By owning a full-chain game, you open the door to designing space for emerging behaviors, allowing people to build smart contracts that interact with the game, as well as alternative clients and game modes, such as Dark Forest Arena and GPU miners.

However, with great power comes great responsibility. When we launched Dark Forest on what is now known as the Gnosis Chain on xDai, we ultimately filled the entire block space of the chain with our activity. This made the chain essentially unusable for anything else, including DeFi, NFTs, or any other xDAI-related activities.

So, what do we do now? Are we stuck in a dead end? Will fully on-chain games never become a reality? Or do we go back to making games with only JPEG images on the chain and convince people that money grows on trees? The answer is, we let software do the work. Many of us have a rigid view of blockchain and roll-ups, as if there isn't much room for improvement. But I disagree. We can experiment and discover new possibilities.

We ask ourselves a question: if we were to start from scratch and design a blockchain solely for gaming, what would it look like? We would need high throughput, so we need to scale for both reading and writing. Most blockchains are designed for heavy writing. Transactions per second (TPS) is a metric that people boast about, but in reality, reading is just as important. If you can't read from the blockchain node, how do you know the player's location? This is actually the first bottleneck we discovered in building a blockchain.

Dark Forest has encountered an issue where full nodes are heavily utilized, causing I/O explosions due to the need to read data from the chain's state. This has resulted in thousands of dollars in server costs, which have been generously covered by the xDAI team. However, this is not ideal in the long term. We need high throughput not only for transactions written per second, but also for reading, such as retrieving data from the blockchain itself.

We also need a horizontally scalable blockchain to avoid the Noisy Neighbor problem. We don't want a popular game suddenly encountering issues on the blockchain and halting all operations. We also need flexibility and customizability so that we can modify the state machine to fit the game design. This includes having a game loop that allows for self-execution and more.

Last but not least, for those who are not familiar with online game architecture, this may be a bit vague, but we need a high tick rate. Ticks are the atomic time units in the game world. In the context of blockchain, we have blocks as atomic time units. In the game, we have ticks. This is almost similar when you are building a full-chain game, where the tick or block generation speed of your blockchain is equal to the tick of the game itself.

Therefore, what we need is a blockchain with high throughput, horizontal scalability, flexible customization, and a high tick rate. Only such a design can meet the requirements of the blockchain we designed from scratch for gaming.

If you have a higher tick rate or more blocks per second, the game will feel more responsive. Conversely, if your tick rate is lower, the game will feel more sluggish. One key thing to remember is that if there is a delay in block generation, you will feel noticeable latency in the game. This is a terrible experience. If you have ever dealt with angry players yelling at their computers because they lost a game, that is an absolutely terrible situation.

Currently, our rollups have one block per second, which is equivalent to one tick. If we want to have cooler games, we need a higher tick rate. For example, Minecraft, a simple pixel art game, has 26 ticks per second. We still have a long way to go to build games that are as responsive as Minecraft.

One possible solution is to deploy our own rollup. Although it may seem to solve the problem on the surface, it does not address the root cause of the problem. For example, you may have higher write throughput, but it may not fully meet the level required for the game. Of course, if your game has one hundred players, this will be sufficient. However, if you want to build a game that requires higher throughput, there will be very strict limitations due to the current I/O method used in the build.

In terms of reading, you haven't really gained any performance improvements. You still need to rely on the indexer. You don't have true horizontal scalability. If you try to launch a new rollup to horizontally scale your game, you will break your existing smart contract ecosystem. The market deployed by players will not be able to work with other chains you launch for horizontal scaling of the game. This will cause many problems.

Finally, achieving a high tick rate and a high number of blocks per second is still quite challenging. Although we can do our best to promote it, we may only be able to achieve two or three blocks per second. This is really the furthest that these blockchains can go, as there are many things like re-marshalling that are highly dependent on computational cycles.

To solve this problem, we looked back to the early 21st century and late 1990s when online games like MMOs were just emerging. They had a concept called "sharding". This is not a new concept; it has existed in the past. The word "sharding" we use in database architecture actually comes from a reference to Ultima Online. They were the first to use the word "sharding" to explain their different servers.

So, how does sharding work in games? It's not a one-size-fits-all solution. It's a tool in the toolbox, and how you adapt it to your game depends on the specifics. For example, the first sharding construct is what I like to call location-based sharding. A good mental model is to imagine a Cartesian coordinate system divided into four quadrants, each with its own game shard. Every time you want to move across a shard, you send a communication to another shard saying, "Hey, I want to move there," and then you're teleported to your shard, leaving behind your previous player body. By doing this, you distribute the server workload across multiple physical instances instead of forcing one server to do all the calculations for the entire game world. The second construct is now more popular. It's called multi-universe sharding, where you have multiple game instances mirroring each other. You can choose any shard you want to go to, and it defaults to load balancing so that no server becomes too crowded.

Now, the key question is how to incorporate this concept into rollup? This is why we created World Engine. World Engine is our flagship infrastructure, essentially a purposeful shard sorter designed for bootstrapping. Our design is different from many shard sorter designs we have seen in previous discussions, and it is more suitable for our needs. Our optimization direction is: A, throughput, B, we need to ensure that there are no locks to prevent runtime, to ensure that the tick rate and block time are as efficient as possible, so it defaults to synchronous. The way we designed the sorter is partial sorting, rather than forcing total sorting (each transaction needs to occur after another transaction).

The key components here are two main things. We have a shard based on EVM, which is like a pure EVM chain where players can deploy smart contracts, combine with games, create markets with taxes, and so on. It's like a normal chain, right? Like one block or one thing per second, just enough for you to do everything with your typical devices and markets.

The secret ingredient here is that we also use a game shard, which is essentially a mini blockchain designed as a high-performance game server. We have a bring-your-own-implementation interface so you can customize this shard to your liking. You can build your own shard and inject it into the base shard. You just need to implement a standard interface, like the ABC interface in Cosmos that you're familiar with. You can basically integrate this into a similar specification and bring your own shard into the World Engine stack.

The key here is that we have a high tick rate, which we currently cannot achieve with our current sharding implementation. This is where I want to introduce Cardinal. Cardinal is the first game sharding implementation of World Engine. It uses an entity-component-system (ECS) with a data-oriented architecture. This allows us to parallelize the game and increase the throughput of game calculations. It has a configurable tick rate, with a maximum of 20 ticks per second. For those in the blockchain industry, that's 20 blocks per second.

We can also geolocate it to reduce latency. For example, you may have a sorter in the United States, and Asians have to wait for a 300 millisecond delay to get the transaction to the sorter. This is a huge problem in games because 300 milliseconds is a long time. If you try to play an FPS game with a 200 millisecond delay, you're basically dead.

Another key point that is important to us is that it is self-indexing. We no longer need external indexers. We don't need these frameworks to cache game states. This also allows us to build more real-time games without delay issues caused by indexers still trying to catch up with sorter blocks.

We also have a plugin system that allows for parallelization of ZK verification, among other things. The best part, at least for me, is that you can write your code in Go. No longer do you need to use Solidity to make your game work. If you've ever tried to build a blockchain game with Solidity, it's been a nightmare.

However, the key point of our sharding construction is that you can build anything as a shard. They are essentially an infinite design space, like what a shard can be.

Assuming you don't like to write your game code in Go, you can choose other ways. However, we are developing a Solidity game shard that allows you to implement games using Solidity. This approach preserves many of Cardinal's advantages while also providing the possibility of code writing. You can also create an NFT casting shard with a unique memory pool and sorting structure to solve Noisy Neighbor problems similar to basic casting. You can even create a game identity shard, using NFT to represent your game identity, so you can easily trade game identities through NFT instead of sharing private keys.

This is an advanced architecture, and due to time constraints today, I won't go into too much detail. The key is that we allow EVM smart contracts to be combined with game shards using custom pick and pass. We created a wrapper around Geth that allows communication between them, opening up a lot of design space in both directions. We are synchronous by default and can seamlessly interoperate between shards without locking.

Our shared sorter is different from others because it does not use the shared sequence construction of atomic beams that prioritize global sorting. This requires a locking mechanism and leads to issues such as blocking the main thread, resulting in an unstable tick rate and block time, which causes delays in the game. It also limits the block time for each shard and requires various cryptographic economics and constructions to prevent service denial. There is also a major issue that I have not seen mentioned in many VCR sorter constructions: how do you solve the problem if you have different shards that depend on each other and cause deadlocks? This is not a problem with asynchronous design because everyone is doing what they want to do and then leaving it alone.

In fact, cross-shard atomic beams and roll-ups are often unnecessary. For our use case, we don't need anything that requires atomic beams, and we don't think this is something we should design our Roll-Ups around in terms of use case purity. This also brings many other interesting features. For example, each game shard can have a separate DA layer for the base chain. For example, you can use the base shard to push data to Ethereum, and the game shard can push data to Celestia (similar to a data availability committee). You can also reduce the hardware requirements for running full nodes, as you can run the base shard Geth full node separately without running the game shard node, making it easier to integrate with things like Alchemy.

To sum up, I want to be honest here and say that many people hope that their constructions can solve all problems, but it's not the case. We believe that our construction is useful for us, but it may not be suitable for your use case. Assuming that our construction can be applied to everyone is unrealistic. For us, it meets our needs by providing high throughput, horizontal scalability, flexibility, and high tick rate, but it cannot cure cancer. If you need a DeFi protocol that requires synchronous composability, then this construction may not be suitable for you.

Overall, I truly believe in the concept of human-centric blockchain architecture. By designing around specific user roles and use cases, you can make better trade-offs instead of trying to solve everyone's problems. The Renaissance is here and everyone can design their own Roll-Ups to meet their specific needs instead of relying on generic solutions. I think we should embrace the Cambrian explosion. Don't build roll-ups like one-size-fits-all layer one because it's not meant to solve the same problems. Personally, I'm looking forward to seeing more people explore more Roll-Up design space that is tailored to use cases. For example, what would a Roll-Up designed specifically for asset exchange look like? Would it be based on intent? What would a Roll-Up designed specifically for on-chain CLOBs (Central Limit Order Books) look like? Here, I'll hand the microphone over to MJ. Thank you for the invitation.

Original Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia