by Dante, Jseam, and Sofia. Edited by vera
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.”
Overhead induced by blockchains 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 enables support for commonly required but highly complex and expensive operations. Examples include the KECCAK256 hash, ECDSA verify, or BN128 pairing precompiles.
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 under-explored 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 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.
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.
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 🥳.
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.
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.
To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server