This was also published by the Lattice team here.

The Autonomous Worlds Thesis

Autonomous worlds are digital ecosystems governed by their own set of rules and entities. These worlds, much like physical or conceptual spaces we inhabit, operate under a unique “diegesis” or the set of conditions that define what exists within their boundaries. Examples range from elaborate fictional universes like Lord of the Rings to real-world economic systems like the US dollar. Three core concepts critical to Autonomous Worlds are:

A Blockchain state root. The definition and compression of all diegetic entities, which compose our world’s state.

A Blockchain state transition function. The definition and execution of rules, which govern how we introduce and change diegetic entities.

A Blockchain consensus mechanism. The agreement between a world’s stakeholders that a state transition is valid. This makes everyone a participant and a decision maker.

With these mechanisms, there exists a potential for worlds governed by unambiguous, diegetic boundaries, enforced through state and consensus, and designed to function autonomously. Enforcement does not cannibalize objectivity. “Nobody can unplug Autonomous worlds.”

Solvable Challenges

The Autonomous Worlds vision is novel — but blockchain introduces overhead that can be difficult to justify with idealized worlds alone. A more tangible argument lies in user-driven growth and long term sustainability. While quite rich and vibrant, the current game development landscape experiences many limitations to value creation:

• Orchestrated User Feedback: The need for game studios to tightly control user feedback and modifications creates a bottleneck. Open modification, while beneficial, is challenging to regulate effectively. This leads to a reliance on private betas and iterative development, slowing down the process despite yielding high-quality games.
• Risk of Confirmation Bias: Relying on feedback from a limited group of users raises the risk of confirmation bias, potentially alienating a wider audience. This scenario is common, as evidenced by the number of programmers who began their careers by reconstructing their favorite games from scratch.
• Uncoordinated Supply and Demand: The gaming industry is marked by uncoordinated supply and demand, necessitating short-term development cycles. Some studios invest months or years in a single project, risking failure, while others release new titles weekly, risking sustainability. Neither approach fully exploits the potential value of user-driven modifications, which could reduce risk by providing more frequent, publicly available updates.
• High Barrier to Entry for New Developers: The dispersed gaming ecosystem presents challenges for new developers, who struggle to bootstrap an audience and compete with large studios on quality.
• Lack of Interoperability in Hardware and Platforms: The diversity of gaming hardware (PlayStation, Nintendo, Xbox, PC, Mobile) and platforms (Steam, App Stores) makes games widely accessible but often not interoperable. Developers face the challenge of creating multiple versions of a game, potentially compromising quality on some platforms, and maintaining game state across systems is difficult.
• Non-Interoperable Game Universes: Many games are built using custom stacks and engines, making it hard to transfer items or features from one game to another. This limits the possibilities for collaborations and universe building across different studios, hindering the expansion of a more interconnected gaming realm.

Blockchain infrastructure introduces smoother coordination between game users and developers, opening possibilities in sustainable engagement and expansion. And amid a broader, uncoordinated game development community, we observe a dedicated sub-community of blockchain game enthusiasts and creators driven by curiosity (among other things). We omit discussion of economic mechanisms and incentives in favor of discussion around infrastructure.

Usable Infrastructure with ZK

Overhead induced by blockchain largely boils down to performance and cost. In fullstack environments, both users and developers are subject to high, often compounded gas costs and consensus-driven delays. The existing paradigm is often binary between on-chain and off-chain games.

We believe the compromise between these paradigms is verifiable off-chain computations with on-chain state management. In practice, this is made possible by specialized blockchain solutions like ZK, and more specifically ZKML — infrastructure that optimizes for the complex operations required by high quality gaming experiences.

ZK leverages a neat feature of many blockchain implementations (notably the EVM): precompiles. Precompiles are gas-efficient functions encoded into an underlying VM, which enable support for commonly required but highly complex and expensive operations. Examples include the KECCAK256 hash, ECDSA verify, or BN128 pairing precompiles.

A typical ZK application flow. For the shape rotators out there — this is an easily digestible example. A user computes a ZK-proof that they have calculated a valid rotation of a world. They submit this proof to a verifier contract which governs an on-chain world, along with a new set of coordinates, and the world rotation updates. Observe that it’s possible for one player to initiate a global change. We have an example on how to do this here.

There are various working demonstrations of generalized ZK applied to gaming. Dark Forest and ZK Hunt have been pioneers in using the privacy affordances of zero-knowledge proofs to create games with fog-of-war or hidden information mechanics. The verifiability of computation is an underexplored set of tools for on-chain game developers, and we’ve seen an increasing amount of developer and player energy invested in this vision. Beyond generalized ZK gaming applications, we also believe there are emergent designs around strategy and agents facilitated specifically by ML. We explore three principal methods for ZKML game-design that have inklings of popularity with both game designers and players: (1) the model is the game, (2) ZKML as digital physics, and (3) ZKML for narrative and lore.

The Model is the Game

The earliest explorations that we’ve seen in the merger of on-chain games and ZKML are ones where the ZKML model IS the game. Here, players interact directly with the ZKML model, and this interaction constitutes the entirety of the game dynamics. A representative example of this is the cryptoidol game that we developed internally. Here players vie to be canonized as the best singer in an eternally running singing contest. They sing into the browser and generate a proof that they were correctly judged by a public judging model. They can then submit their score and associated proof on-chain to be inserted into a running leaderboard.

Here the model is the game and all interactions the player has are directly with the ZKML model. Most interactions will be single player.

Sing. Be judged. Be ranked on-chain forever.

ZKML as Digital Physics

We’ve also designed a simple onchain-tictactoe library, where a neural network is trained on tictactoe telemetry data to recognize valid or invalid game patterns, such that games can be played off-chain and then submitted and settled on-chain in their final state. We have two tutorials that showcase how to do this here and here. This pattern, of a neural network encoding the “rules” of the game, bridges into the next design paradigm where ZKML helps create “on-chain physics” for a world. Though the tictactoe model leverages a neural network, this design pattern requires a slight shift in thinking about what ZKML enables. In some sense, when ZKML is focused on neural network “inference” (i.e post training predictions), there is nothing that constrains the computations that are “ZK’ed” to be exclusive to ML.

Matrix multiplication can be used to model state transitions for an AW’s state, like say a world’s weather. A game that exemplified this idea was BabyGaya (sadly no longer online), where the entire world state was altered at each block using ZK’ed matrix multiplication that anyone could run.

Here the player interacts with the world the ZKML model creates. Many players can interact with this shared state.

ZKML for Narrative and Lore

The third pattern, and perhaps the most ambitious, is one where ZKML is leveraged to build a world’s lore and narrative. ML models can be used to create sophisticated agents / NPCs and concurrent storylines that are nuanced elements of a larger whole.

This could for instance be an a language model writing a world’s narrative as the game progresses, or writing storylines for individual NPCs. As a first exploration in this we created our own on-chain NPC (fully fleshed out demo pending), which we call the “worm”. We implemented a generative model, described here, which models the voltage activations (given sensory inputs) of the C. Elegans nervous system. We could generate sensory inputs for the worm using an on-chain game engine such as MUD, and then generate proofs that update the worm’s brain activity given the on-chain sensory environment. Anyone can run these proofs and keep the worm “alive” on-chain, effectively creating an autonomous agent that other games and interfaces can leverage within their own games. Reusable and permisionless NPCs that are shared across games and worlds then become possible 🥳.

Here the world’s lore such as its narratives and the characters the player encounters are generated by a ZKML model. As before, many players can participate in this lore and experience this narrative.

The Gaming Stack

Though still in its infancy, on-chain game development, offers game users and designers unprecedented new affordances. We credit various on-chain game development frameworks, particularly those developed by our friends at Lattice and 0xPARC, with lowering the barrier to entry for the creation of autonomous worlds. Recognizing the challenges in traditional smart contract development — such as the coupling of state and logic, and synchrony issues between the chain and client — frameworks like MUD streamline the game development process. Observing the limitations of underlying blockchain implementations — particularly around L1 data fees and data availability — rollups like Redstone (built on an OP stack) serve as game-optimized state.

The missing piece, we believe, is a general purpose compute engine. As we’ve discussed previously, the stack inherits both the security and the computational limitations of the underlying blockchain (whether EVM or any other system). Consequentially, it is important to pre-process heavy compute features (anything from ML agents to strategy models to embedded graphics) in a verifiable manner. This allows for the bundling of compute to pass more succinctly through gaming engines and blockchain layers.

The underlying hardware behind the general purpose compute engine is left to discretion of the user. Via the EZKL backend, it’s possible to use our private cluster (achieving economies of scale from contained jobs) or ZK accelerated hardware. There’s more to come on the hardware integration front. This flexibility implies that the proving engine can run on both clients (WASM for example) and servers — and both systems are capable of deploying a verifier to the blockchain stack.

The gaming stack. The blue functionalities are enabled by the EZKL engine. We exclude mention of some additional tools / frameworks for simplicity — but the stack is generalizable.

We’ve designed EZKL with this vision in mind, and believe these simple ZKML libraries may neatly complement MUD, Redstone, and beyond — a gaming stack that materializes innovative dynamics with performant infrastructure and supports brilliant autonomous worlds.