Lecturer: Scott Sunarto (@smsunarto) on Modular Summit
Article edited by Justin Zhao (@hiCaptainZ)
Greetings everyone, and thank you for attending today's summit. I am here to discuss a project that has consumed the better part of our last year. However, as you will soon discover, the narrative extends far beyond this timeframe.
Before co-founding Argus, I was one of the creators of Dark Forest, the first fully on-chain game on Ethereum, utilizing ZK snarks. The inception of Dark Forest was driven by a simple question: Could we create a game where every action is an on-chain transaction? In 2020, this was a radical proposition. Many questioned the feasibility of a fully on-chain game, given the slow nature of blockchain technology. Despite the skepticism, our curiosity led us to develop Dark Forest.
Dark Forest, a space exploration game, saw thousands of players battling on-chain to expand their empires. Within the first week of launch, we had over 10,000 players and trillions of gas spent on the Ethereum testnets. This high level of activity eventually forced us to move from the testnets to a sidechain. However, even the sidechain, touted for its scalability, proved insufficient. We quickly filled up the entire block space, driving up gas costs and rendering the sidechain practically unusable.
Despite these limitations, the enthusiasm for on-chain games remained high. Post Dark Forest, we saw a surge of investors, founders, builders, and hackers building upon the legacy of Dark Forest. Companies like Lattice and Primordium developed frameworks for easier on-chain game development and fully on-chain games, respectively. We also saw developments in other ecosystems beyond the EVM, like Dojo on Starknet.
The limitations of existing blockchain technology stem from the fact that we are sharing a chain with everyone else. If another game like Dark Forest were to exist on the same chain, it would be impossible for the chain to function effectively. This led us to question whether we should abandon the concept of on-chain games. However, we decided to explore how we could build better on-chain games.
We embarked on a journey, starting with a key realization: we had taken blockchain architecture for granted. Despite the variety of L1s and L2s, they all seemed similar. They all claimed superior consensus mechanisms, faster VMs, better fraud provers, and faster ZK provers. However, these claims often lacked substantiating benchmarks. All these efforts were aimed at creating another DEX or minting another NFT, which could be deployed on any other chain.
We decided to approach blockchain architecture from a different perspective. We questioned the classical blockchain architecture, which seemed to mimic Bitcoin or Ethereum. We realized that other blockchains, whether L1 or L2, were trying to build a blockchain for everyone, without considering specific use cases or user personas.
We chose a different path. We decided to build the best blockchain for a specific user in mind: game developers and players. We understood that games are vastly different from typical applications. For instance, social media platforms like Twitter operate in an event-driven runtime, similar to blockchains. A user triggers an event, like posting a tweet, which causes a state transition.
Games, on the other hand, operate on a loop-driven runtime. Even without user input, state transitions continue to occur. Fires continue to burn, water continues to flow, crops continue to grow, and the cycle of day and night continues. This fundamental difference led us to rethink how we could build a better blockchain for games.
The key point to understand here is that state transitions in web applications, such as smart contracts, do not require user input. For instance, in Uniswap, if a user wants to trade Token A for Token B, they submit a transaction, and the trade is executed. This process is event-driven.
However, we quickly realized that the event-driven nature of traditional blockchains is not compatible with running a game state machine. Therefore, we explored the loop-driven runtime that games use. Game engines are specifically built to support this loop-driven runtime.
In loop-driven runtimes, game progressions are referred to as "ticks," which are the atomic units of time. Each game loop is executed in a single tick. The higher the tick rate, the more responsive the game feels. For example, modern games like Counter-Strike or Valorant have high tick rates, making them feel more responsive. In contrast, older games with lower tick rates often feel sluggish.
In the context of blockchain, these ticks can be compared to blocks, which are single units of time where state transitions happen. If a tick or block feels slow, it can negatively impact the gaming experience.
We believe that games are loop-driven in nature because many game state transitions are not triggered by external input. For example, gravity in a game doesn't rely on the user pressing a button; it continues to exist regardless of user input.
Deterministic transaction ordering is also crucial. For instance, if you want to inflict damage on a user, should the game apply a health regeneration to the user first or inflict damage first? With traditional ordering, you can't predict or control which state transitions are applied first, leading to issues in the game loop.
With a loop-driven blockchain for games, we maintain composability, which is why we want to use blockchain as a runtime for games in the first place. This approach allows for real-time gameplay, blurring the line between a blockchain and a traditional game server. It also enables the development of more complex games than before.
However, to build a scalable game server blockchain, we need horizontal scalability. Games are not played on a single server; they are spread across many servers. A roll-up runs on a computer and is bound by physical computation limitations. Therefore, we need a new strategy to control transactions.
Traditional game servers, especially those with intensive performance like massively multiplayer online games (MMOs), use the concept of sharding. Sharding is a tool, not a prescription for how to build your game. For example, in location-based sharding, a Cartesian coordinate can be split into four diagrams. When a player moves from one shard to another, a message is sent to the other shard, and the player is teleported there.
The second approach involves the use of a concept known as multiple sharding, a familiar concept to those who have played MMO games. In such games, upon logging in, players are presented with multiple servers to choose from. This is a similar construction where distinct states or game worlds exist, and players can choose which to join.
With the loop-driven runtime and horizontal scalability, we also aim for excellent composability. However, achieving this in a roll-up may seem beyond reality. This is why we created the World Engine. We realized that a standard roll-up wouldn't function as we desired, so we took it upon ourselves to build the solution we needed. This is akin to the 1990s when 3D game engines weren't readily available, and developers had to build them themselves.
The World Engine is divided into two key parts. The first is the core, which consists of two key elements: the EVM Bayshore, a hybrid execution layer and sequencer with sharding support, and the Game Shard, a high-performance game engine plus execution layer. In addition to these, there are peripheral components like the transaction relay and net code for client-server communication, and the ZK Cloud prover for ZK games like Dark Forest.
The World Engine core is designed around our sequencer. While other sequencers like shared sequence reconstruction optimize for atomic composability, we believe atomic composability is overrated, especially in the context of games. Hence, we went fully asynchronous, eliminating the need for locks under runtime in EVM Base Shard.
We have a global EVM chain where players can deploy smart contracts to compose with games, create marketplaces, and DEXes. We built this on top of Polaris, a Cosmos SDK compatible EVM module, allowing us to customize the EVM to a much greater extent than what we could achieve with other solutions.
Running on top of the EVM Base Shard sequencers is the Game Shard, a high-performance mini blockchain designed to serve as a high-performance game server. The Game Shard is designed to be state machine and VM agnostic. We built an abstraction layer similar to the Cosmos SDK EBCI, allowing you to customize the shard to your liking or build your own by implementing a standard set of interfaces.
We've also built the first game shard implementation to provide an example. We use an entity component system, a common feature in game engines, with a construction that prioritizes the entity component system as a first-class citizen. This means every single object or primitive on the state machine itself is treated like an entity. The system also has a configurable tick rate, allowing you to customize your game's speed.
The best part is that you don't need to rely on indexers. You can have fast reads on a blockchain without having to deal with the lack of eventual consistency in indexers. Furthermore, you can write your code in Go, eliminating the need to wrestle with limiting smart contract languages.
Shards are agnostic in nature due to our abstraction layer, so you can build other shard constructions like a solid game shard to complement your cardinal game shard. You can also build an NFT minting shard with custom rules, a game identity shard to use NFT to represent your game identity, and allow trading of game identities. We don't use locks, so we don't have to block the main thread, making the game shard runtime as reliable as possible and avoiding any lags. We don't have to rely on crypto-economic constructions anymore.
Each shard can have different DA batching compression strategies. You can geolocate shards to reduce gameplay latency. You can also run game shards as an independent game server on its own, so you don't have to worry about roll-up deployments on day zero.
We've built various games on top of the game shards, like an Agar.io clone, which was traditionally not possible. We've also worked with a hybrid model where you would use existing game engine frameworks on solidity and combine that with the World Engine. The future is for you to decide. You can use our cardinal stack, do a hybrid, or build your own game shard. It's like Kubernetes for on-chain games, a mix and match Lego for your games.
The World Engine is now open source on our GitHub, and we welcome new contributors. If you're interested in building your first World Engine game, we are hosting a workshop later today. Tomorrow, we're also going to host the gaming track, a panel, and a talk about on-chain games.
In conclusion, let's build cooler roll-ups. We're currently in the roll-up renaissance. Roll-ups allow us to scale blockchain and tap into the security of the underlying L1. However, we're still living in a very EVM-centric conception of roll-up architecture. This is just the starting line, not the end. We aim for a user and application-centric roll-up construction. Thank you for listening.