AW DAY Panel recap - QuestItems: Tooling & Infra

Hosted by AW Research ARPA Network

​This informal gathering is hosted by AW Research ARPA for creators and enthusiasts of the autonomous worlds and on-chain games.

​This is an opportunity to gain firsthand insights into fully on chain games, extended AW narratives, and the creators behind them.

We have invited these incredible builders from the AW/FOCG to join our panel session on exploring Autonomous Worlds.

The recap will be divided into 4 parts, including Fireside chat, FOCG in AW, Tooling Infra and WorldBuilding.

Moderator:  Norswap  From  0xFable

Panel Guest:

yijia  from  Curio

Baz  From  Tonk

piapark.eth  From  Herodotus

Yi Sun  From  Axiom

Luke  From  Web3MQ

Panel Guest Introduction

Norswap: Let's get started. In today's panel, we will concentrate on infrastructure and the improvement of the gaming experience. Our discussion will revolve around the substantial impacts and strategies for achieving balance in gaming. I'd like to invite our panelists to introduce themselves and their projects.

Baz:Hello everyone. I believe I'm already familiar with many of you. My name is Baz, and I'm from Tonk. For the past two years, I've been involved in the decentralized space. Prior to this, I worked as a privacy infrastructure product manager at Epic Games, where I focused on building privacy features for Fortnite. Tonk specialize in integrating secrets into on-chain games and autonomous worlds, particularly through hidden information mechanics. Last year, we spent a significant amount of time experimenting in this area. Here's something not many people know yet – and I'll be discussing this more tomorrow – we've developed a system that integrates game loops into payment processes. Are you familiar with it?The next step for us is to package all of our learnings from the past year into a comprehensive framework. This will enable any studio, regardless of their expertise in blockchain technology, to incorporate sophisticated information mechanics into their games. What excites us about on-chain games is not just the opportunity to revolutionize a form of media, but also to use them as a playground for privacy. We see this as a crucial step in advancing privacy research and setting the stage for future developments in this field. This version improves the clarity and flow of the original text while maintaining its original intent and information.

Yijia: Hello everyone, my name is Yijia, and I'm the co-founder of Curio, a company specializing in on-chain gaming. At Curio, we focus on developing both games and the necessary infrastructure. Our first game is a strategy title with rich social performance elements which we're excited to launch next year. In addition to game development, we're also working on a server-side game engine. Initially, this engine was developed for our internal use to facilitate the creation of on-chain games. However, we've decided to build it in a public domain, allowing others to access and utilize it for their projects.

Pia: Hello, I'm Pia from Herodotus. Our company is deeply focused on infrastructure, primarily enabling access to data across various blockchains in a trustless manner. Personally, I have a keen interest in the concept of autonomous worlds. I'm fascinated by how these worlds, from an infrastructure perspective, can be innovated to allow seamless access to diverse data across multiple environments. This intersection of technology and accessibility is what really captivates my interest.

Yi Sun: Hello, my name is Yi Sun, and I am one of the co-founders of Axiom. Our company enables smart contracts on Ethereum, and soon, robots, to access any data that has never been on the Ethereum blockchain. Additionally, we provide verification and computation services for this data using our end-to-end solutions.

Luke: Hi everyone, I'm Luke from Web3MQ. Let me give you a straightforward overview of what we do in the gaming sector. Essentially, we're focused on building trustless applications for gaming. This involves two key elements: advanced cryptography and sophisticated decentralization. These components can be balanced in various ways, either leaning more towards cryptography or towards decentralized communication. Our company tends to be on the other end of this spectrum. Currently, we're working on tangible contributions to gaming, particularly in developing new consensus protocols for Madara. These protocols are designed to enhance the chain's speed and, looking ahead, to make it more compatible with parallelized execution schemes. At the core of our work are messaging protocols, which are crucial for achieving more efficient execution and decentralization in app transactions, particularly in gaming.

Panel Question one

Norswap: What do you think are the biggest technical challenges currently faced when building on-chain games?

Pia: Today, I had a discussion with the team at Smallbrain. They're running their game on the Base chain, but this setup requires users to constantly migrate their assets from the Eager interface whenever they want to use them on the Base chain. This got me thinking: perhaps using a solution like Herodotus could address this issue.In the current gaming landscape, the primary aim is to enhance the fun factor, improve user experience, and ensure good design. Therefore, the technology or blockchain chosen shouldn't be limited to specific functionalities. My view is that we should be able to leverage different communities and technical advantages across various chains. However, the multitude of different rollouts, including various Layer 1 and Layer 2 solutions, complicates the process for game developers who need to access data across multiple chains. I believe that solutions like Herodotus, which provide speed and proof of activity in data handling, could be a game-changer. Imagine playing a game on the Base chain while being able to seamlessly verify an NFT on Optimism or Ethereum. This kind of interoperability and ease of data access is crucial, especially from a UX perspective.

Yijia: The biggest issue in on-chain gaming, as I see it, is the fundamental question: why should people play on-chain games? The root of this issue lies in the lack of compelling products in the space. We don't yet have standout on-chain games that clearly demonstrate their unique value proposition or intuitively explain their benefits to players. This is a clear indicator that the industry needs to evolve. The core problem,from my perspective, is twofold: it's about game design and technical limitations. Focusing on the technical aspect, on-chain games are often confined to highly constrained execution environments with limited scalability. Many developers in this space are still grappling with how to overcome these limitations. For instance, the reliance on the EVM, which was designed around 2013-2014 for a different purpose, poses significant challenges. It lacks features like parallelization, which are crucial for modern gaming environments. This limitation impacts the ability to support a large number of players smoothly. Even managing a few hundred players can be a challenge, not to mention the issues with transaction costs and gas fees. These are significant barriers to achieving consensus and scalability in on-chain gaming. We're addressing these challenges with Keystone, our server-side game engine, which I'll discuss in more detail later. Our focus is on enhancing scalability and flexibility, moving beyond the traditional constraints that currently hinder the development of on-chain games. In my opinion, scalability and the ability to think beyond existing limitations are the most pressing technical challenges in launching successful on-chain games. This version improves the readability and structure of your original text while maintaining its original intent and information.

Baz: I recall participating in a similar panel this summer at the Komorebi hacker house in Paris, alongside others who are also building in this space. One thing I noticed was the significant focus on scaling and the remarkable work being done in computation and tool development. However, what seemed to be missing from the discussion is a return to the basics: understanding what blockchains are fundamentally poor at. Primarily, blockchains struggle with two things: transaction fees and hiding information. When you consider the history of game design, the use of information asymmetry has been a staple tool since the beginning. The ability to create these asymmetries in your game world is crucial for sustaining engaging gameplay, ensuring fun, and maintaining balance. The most significant changes in the world of gaming often occur because players are thrust into environments with uncertain information, where they must take calculated risks. This aspect is a fundamental part of what makes gameplay intriguing. As you're all aware, we've been exploring the capabilities of ZK, which seem to solve many of our problems. However, from our experience in building at the edges of these systems over the last year, we've found that it's somewhat challenging to conceptualize what ZK can do in terms of secret information management. In the realm of video games, we're somewhat familiar with leveraging ZK for enhancing speed and scalability, and perhaps even for concealing certain transactions or creating self-addresses. But when it comes to more nuanced aspects like secret tech trees, digital physics akin to a Pokémon-type system, shuffling decks, hiding hands in poker, or implementing fog of war mechanics, it becomes less clear what's feasible. Another issue we face is that, as of now, to build systems utilizing ZK, we often end up creating highly specialized, balkanized cryptographic systems. These are built from scratch, tailored to specific systems, and lack standardization and personalization in how secrets are represented. Without a way to personalize and standardize these elements, achieving composability of in-game secrets remains a distant goal. Furthermore, while ZK is excellent for selective disclosure — allowing certain facts or information about the world to be shared selectively — it doesn't cover a broad range of use cases, especially in terms of information mechanics and in-game secrets. I'm curious to hear any differing opinions on this, but from what I can tell, we're really pushing the limits of what ZK can achieve in terms of in-game privacy. This is one of the reasons I find the intersection of gaming and cryptography so thrilling. Games are constantly pushing the boundaries of what's possible with the cryptographic systems we have today.

Specify questions to Yijia

Norswap: I've got some thoughts. Regarding your product, what does it enable that wasn't possible before? For Yijia, you've had firsthand experience in building games, and you've developed engines based on that feedback. This was something you couldn't do before, but now, with your engine, you're able to do it.

Yijia: That's actually a great question for us because we started building Keystone due to the challenges we encountered with Treaty, our previous project. Treaty was a 4X strategy game set on a map where players controlled troops, buildings, and had continuous troop movements. The objective was to capture central tiles in a battle royale style. Eventually, we had around 70 to 80 players on the same map, each with their own troops. We had several player functions like movement, and initially, we wrote everything using Solidity, deploying our own EVM instance for the game, arguably the fastest approach with EVM. However, the gas consumption was enormous, averaging tens of millions of gas for each production in our single EVM instance. With about 20 players online, it typically took around 20 seconds or more for each turn to process, and shorter times like 10 seconds for each operation. Imagine that experience – each movement represented a small pile, so if you wanted to move from point A to point B, breaking it into eight smaller movements, each taking 20 seconds, players would literally sit there questioning their life choices, like 'Why am I playing this game? Am I actually moving this thing?' It was a terrible experience for players and represented the most complex thing we had built up to that point. It really tested the limits of player patience, even among on-chain gamers, who are among the most patient gamers compared to traditional gaming. So we faced a decision: either stop building on-chain games and shift to web 2.5 games, or find a more scalable way for transactions. After January this year, we started exploring alternative execution environments and potential modifications. We realized that games require a different type of execution environment, optimized for their specific needs compared to other crypto use cases like DeFi. That's when we settled on this idea of taking the EVM and adding a game engine that processes all the state changes, like movements and army production. This system can be integrated with creative files, which we'll delve into as well. We managed to build a system that combines the best aspects of EVM – its security – with high performance. We even built a game demo using Warcraft 3 assets, moving them on-chain to create a Warcraft 3 Keystone version. It's similar to Age of Empires in some ways, an RTS where you can move tens or hundreds of troops simultaneously across the map, all within on-chain transactions. This approach doesn't sacrifice security but adds performance. This direct takeaway from our experience with our own game pushed us to think beyond the current limitations.

Specify questions to Pia

Norswap: I want to ask about how the state root functions. When I refer to state root, it involves obtaining a block hash or state root from a blockchain. Using that state root, you then prove something about the state of the blockchain. This could relate to storage data on the blockchain, or it might involve transactions or events.
Pia: Essentially, everything is stored within the blockchain. We can generate transaction receipts, block headers, and every piece of information or a state root. Then, within the secret tree, the actual values stored in the state tree can be generated as a storage proof.
Norswap: Okay, How do you get that state root? Do you have some integration with bridges or things like that?
Pia: Our infrastructure is fundamentally built on Ethereum's core structure. We recently announced a block accumulator for Ethereum blocks, covering from Genesis to 18 million blocks. Essentially, we accumulate these block headers in a data structure known as the Merkle Mountain Range. For instance, if you want to transfer Ethereum data to another destination chain, our messaging contracts will handle this. They will take your block headers to the destination chain, along with the specific block header that the user wants to retrieve. We also accumulate block headers on that destination chain.

Specify questions to Yi Sun

Norswap: So the question for the Yi. Can you talk more about the computation?
Yi Sun: We're launching our testnet this week, which will allow users to specify arbitrary computations on top of data read from Ethereum, using a JavaScript interface. Often, when people think of computational data, they imagine large-scale computations, like running a machine learning model or similar tasks.However, we've realized that for on-chain actions, smaller computations are usually more relevant. An example of such hidden computations is sampling events at specific blocks. These blocks should be spaced at certain intervals, and you'd typically want to verify that these intervals are consistent and determined by an external source. Additionally, you'd want to ensure that the addresses associated with the user in each of these events remain consistent. These kinds of computations can be executed either in ZK or in the EVM.We've found that when accessing a large amount of data.It becomes somewhat cost-prohibitive to process this immediately. This is the primary reason we've focused on adding competition in this direction.

Specify questions to Luke

Norswap: I'm interested in more concrete examples of use cases for games. For instance, a chat feature for your game – that's something that doesn't necessarily need to be on-chain. However, I think you were hinting at more on-chain examples. I would definitely like to hear an interesting example of this.
Luke:Chat is an example of what might be considered a downstream application layer feature. In an autonomous world, where communities are decentralized, growing autonomously and permissionlessly, you would ideally build such a feature on a more permissionless communication protocol. However, that's just one part of the equation. On the other end of the spectrum, our current focus is on enhancing the performance of actions. This involves working with various consensus primitives and exploring the potential of state channels, which are gaining a lot of attention. The goal here is to establish effective communication channels that can coordinate these executions efficiently. So, we're looking at these new scenarios as opportunities where we can contribute, either as a modular component or as a part of a single layer.

Norswap: We've already covered these steps and types of discussions. So, I'd like to give each of you a maximum of two minutes to share any final thoughts with the audience. You can use this time to express anything you wish. If you're unsure what to say, feel free to ask a question to another panel member or provide some feedback. Let's not just end with a simple shout-out; I encourage you to infuse some energy into your closing remarks.

Baz:Here's a thought for everyone, and it's quite open-ended for you to interpret as you wish. It might be a big idea, or perhaps a small one – you can decide.I've spoken a bit about the role of information and the importance of concealing it to make games fun. Consider the need to hide social treaties between players, secret arrangements, maybe secret weapons, bosses, and their vulnerabilities. One of the intriguing aspects of these summits is our use of terms like 'on-chain games' and 'autonomous worlds.' My intuition tells me there's something more here, something intangible that can't be fully captured by the term 'on-chain games' alone. This is, after all, a new form of media. My challenge, then, is to consider how expressive this new form of media can be if it lacks the capacity to present mysteries and selective exposure. As I approach my two-minute mark, let me bring up the concept of the 'cozy web,' as described by Venkatesh Rao. He talks about a web spectrum ranging from completely open platforms like Twitter or Wikipedia, where everything is shared with everyone, to more intimate spaces like Telegram groups or WhatsApp chats with family and friends. The cozy web's expressiveness comes from its ability to traverse spaces with selective exposure qualities, where the ability to conceal information and share it with only a select few is key.So, my challenge for the world of autonomous worlds is to ponder how this emerging media can be equally expressive, embodying the ability to selectively reveal and conceal, much like the cozy web.

Yijia: So, you can anticipate another moment. I don't have anything to show about our game yet, as we're still in the process of building it. Look forward to its release next year. Regarding Keystone, if you're tired of endless debates about terminology and their meanings without seeing actual products, and if you're frustrated by the lack of real on-chain games for autonomous worlds, then I suggest you try Keystone. It's a framework designed for those who want to build real games, offering the experience of your favorite web 2 games, but with the advantage of being fully on-chain. Everything you need should be available right out of the box. If it's not, we'll make sure to add it. So, I encourage you to give it a try. Piapark: I'd like to share my thoughts about the autonomous world in terms of infrastructure. At the end of the day, the autonomous world is a type of game that requires leveraging certain technical aspects. When you're building normal games, you typically use game frameworks that already have known performance metrics. However, I believe blockchain technology introduces some credible aspects that enable us to create a new type of game. Despite this, there are quite a few drawbacks. Personally, I strongly believe that by using tools like Herodotus or similar proof mechanisms, you can access data from any source. This, in turn, will eventually assist game developers in creating fun and creative games that can more effectively leverage these technical benefits. I think this is something that excites me, and I'm eager to see how it unfolds.

Yi Sun: Axiom is an infrastructure project, and we're relatively new to the autonomous world space. We were introduced to it by a couple of AW builders who informed us that being able to reference Ethereum's history is very beneficial for creating truly composable games. A key feature we believe Axiom offers is the ability to reference actions that occur in one game from another game, even when those games are created by different teams. When you're developing a game, you can include various elements in your states for later reference. However, if you want to reference events or achievements from someone else's game in your own game, the best approach, in my opinion, is to delve into the cryptographic history of the chain. Using ZK, you can extract that information and make it useful for your game. Realizing this, I felt that it's a pretty natural fit for Axiom, and I'm quite excited to see where it goes.

Luke:I'd like to give two shout-outs. The first is to the gaming infrastructure within the StarkNet ecosystem. I believe there are many areas for improvement, but just like the autonomous world, a lot of the infrastructure in StarkNet is highly composable today. So, definitely keep an eye out for next year, as we anticipate advancements in app chains that can better support gaming. We're active players in this ecosystem . We're not the only ones making strides, but we're certainly part of the movement.Additionally, for those developing games and looking to enhance player connectivity within their games – whether it's through groups, communities, guilds, one-on-one connections, or information notifications – we offer SDKs that can assist with this. We're excited to contribute to and serve the gaming community in these ways.