DIALECTIC

Special thanks to guiltgyoza, Ryan Zurrer, and Swagtimus for the feedback on this article. Also, thanks to Sylve and the MatchboxDAO's community for the inspiration and thoughtful discussions.

The gaming industry is slowly waking up to blockchain technology. It will dramatically change the gaming landscape to the benefit of gamers.

Each node has to verify the validity of every computation the users send to the network on blockchains. One of the major bottlenecks of blockchains' scalability is how to increase computational bandwidth without increasing the verification cost, which is ultimately the decentralization guarantee of a blockchain. The higher the verification cost, the more resources are needed to run a node on the network.

Blockchains charge a monetary fee to the users proportional to the computational burden the nodes must verify. Thus, on this monolithic stack, the computation cost is quite high. Developers have been forced to write their code around such constraints, not being able to express the true potential of on-chain applications.

Since the advent of Optimistic Rollups (ORUs) and Zk-Rollups (ZRUs), the paradigm has changed.

Computation is run off-chain by high-end machines (the provers) while posting a fraud proof (on ORUs) or a validity proof (on ZRUs) on a settlement chain, which can prove the computation integrity, or in other words, that the computation has been executed according to the systems rules.

The network nodes can verify the attached proofs several orders of magnitude faster and cheaper than verifying the computation itself, thus enabling complex computation at a pretty cheap cost, such as gaming dynamics.

For example, Starknet's virtual machine, powered by Cairo, unleashes this true potentiality as their native programming language is not bounded by the EVM constraints.

Thanks to these proofs, it is possible to exponentially increase the computational complexity and throughput while maintaining the verification cost linear or even less.

This is a fundamental shift in blockchain scaling.

Running a game completely on-chain on a monolithic blockchain is economically unfeasible and will remain so for the foreseeable future. That is why most of the blockchain games that have been released in the past few years are in a hybrid form, having only a few components of their stack on-chain while running the core part of their game logics on off-chain proprietary servers. We will refer to this family of blockchain games as weakly on-chain games.

Games like Axie Infinity, Crabada, and The Sandbox belong to this category.

Through off-chain scaling, users will have access to unlimited computation at a cheap cost. Thus, games' logic could be finally deployed on-chain as smart contracts. We will refer to this family of games as strongly on-chain games.

Dope Wars, Briq, Loots, The Realms, The Ninth, and Influence, to name a few, belong to this category.

In this article, we would like to explore the strengths and weaknesses of each macro-category.

Strengths

- More straightforward to scale

- More accessible to the public audience

- Good UX

- Low latency

- Rapid bugs-fixing process

- Easy to ban cheaters

Weaknesses

- Top-down development

- Closed-source

- Trust in the game publisher involved

- Weak composability and interoperability guarantees

- Proprietary

- Non-persistent

Weakly on-chain games are much easier to scale as they retain most of their stack off-chain. The game parts on-chain are usually the in-game assets, represented by NFTs, and the in-game tokens, which can be freely traded and transferred in open and permissionless markets. So the activities happen off-chain, and then economic settlement is done on-chain.

The downsides of weakly on-chain games can be found back in the root problem of centralization, where the game publishers play the role of central authorities and will likely imply rent-seeking over time. A game publisher could unilaterally start censoring, changing the rules, or disappearing. Also, interoperability and composability are impossible because the game logic is off-chain.

On the good side, the user experience is quite similar to traditional games, and latency is not a problem given the game's client-server connection type. Any update can be rolled out smoothly. Since the game access is gated, game publishers can ban players who play against the terms of services.

Strengths

- Open-source

- Bottom-up development

- Potentially composable and interoperable

- Client abstraction

- Trust-minimized

- Permissionless

- Persistent

Weaknesses

- UX

- Information not hidden by default

- Players can be exposed to backrunning and other forms of MEV

- Latency

- Bugs-fixing might require social coordination

- Botting

With strongly on-chain games, developers can leverage any public on-chain components:

- A physics engine

- An on-chain VRF primitive to fetch randomness

- NTFs representing skill trees, portable to any mod of the game

- A quest factory contract where anyone can deploy and import their quest in the game

These are just examples of what strongly on-chain gaming can facilitate.

Every game component is potentially composable and interoperable, and infinitely duplicable.

This prepares the ground for endless and powerful bottom-up collaborations. MatchboxDAO is a live example of such initiatives.

Another great feature unlocked by strongly on-chain games is client abstraction. Users won't be forced to use a specific platform to play their games. Everything they will need is access to a node. They also won't need to wait for game publishers to release their favorite game on their platform. Modders won't face any portability issues.

Let's now look through some of the weaknesses and future challenges of strongly on-chain gaming.

We highly recommend reading “Four challenges in blockchain gaming”, a great article by Sylve.

In strongly on-chain games, every state change of the gaming contracts requires to be registered on-chain. Hence, users need to sign a transaction for each action they are willing to execute in-game. This scheme is unfeasible for high-velocity games like RTSs.

Account abstraction (AA) is quite a compelling improvement over Ethereum's account model that rollups like Starknet and Optimism are implementing. With AA, every externally owned account is a smart contract, allowing deploying robust, secure, and highly customizable smart wallets. It would be possible to create, on a high level, something quite similar to what we have deployed with Medici, our Yield Farmer.

note that the module logic could even be implemented within the hot wallet logic

The player would generate a new account with a local keypair for any new game. This nerfed hot wallet would be restricted to I) sending any in-game assets or tokens back to the main wallet II) calling anything out of a limited set of allowed functions from a proxy contract, which would map the functions of a target game contract. Each time the user would click on a specified in-game action, the hot wallet would call the correspondent function on the module, which would modify then the underlying state of the target gaming contract on behalf of the user.

This modular architecture through secure enclaves will let the user be abstracted away from having to sign a transaction for every in-game action while retaining strong security on the main wallet. The temporary key pair would be restricted to call a limited set of harmless functions.

When players send a transaction to a public mempool, they can expose themselves to backrunning if the transaction is submitted in a readable form. Any observer of the mempool would be able to know in advance what the next flow of actions will be and act accordingly.

Consider for example a fighting game where Player1 submits a transaction associated with the action High-Kick on the mempool. Meanwhile, Player2 is monitoring the mempool for any transaction coming from Player1. As soon as the transaction is submitted, Player2 can foresee the opponent's next move and be able to backrun it by submitting the perfect counter-move.

Player1 submits the High-Kick action to the public mempool. Player2 is listening to the mempool

Player2 backruns Player1's High-Kick with their High-Parry

Backrunning could be prevented by either encrypting players' actions or sending the transactions through private mempools.

Besides the systemic backrunning exploitation, every strongly on-chain game can present forms of long-tail MEV, or gaMEV, as coined by Sylve from Briq. Arbitrages, frontrunning, and other complex forms of gaMEV opportunities will be prominent. It's impossible to define them in a generalized form as they strictly depend on the games' architectures, dynamics, and metagame.

In each case, we believe long-tail gaMEV extraction will be a pretty prominent activity in the following years.

Most competitive games rely on some degree of imperfect or incomplete information.

Unfortunately, by nature, public blockchains store all information in a clear and readable way, accessible by anyone in the world who has access to a node. It would allow any observer to exploit the other players by just reading the information stored on the smart contracts.

Consider a real-time strategy game where the players battle against each other by producing war troops with different attributes per unit type. Each user has an incomplete vision of the map, limited by their line of sight. Since troops' demography is critical to the battle's outcome, seeing what is being produced by the opponent in the fog of war is a competitive advantage. A sophisticated user who can read the smart contract storage can adjust their strategy accordingly to what their opponent is doing.

When information meant to be kept secret is public on the game contract, there is an asymmetry between those who can read the storage fields and those who can not. This exploitation process is exacerbated as blockchain games often come with monetary prizes.

Asynchronous turn-based games might implement commit-reveal schemes. Players can post their actions in a hashed form without revealing their underlying actions. Once every participant has posted their hash, they can reveal their action. The smart contract will verify if every revealed action corresponds to the attached hash.

Another solution is leveraging zero-knowledge proofs. As presented at the start of this article, ZKPs are quite powerful cryptographic primitives. It is also possible to let external parties (such as the smart contracts that enforce the game's rules) verify the validness of state transitions while keeping the computation private by hiding the steps taken and their underlying inputs.

Dark Forest, a fully on-chain MMO, pioneered the use of zkSNARKs to maintain in-game information private. In DF, players discover and conquer planets in an infinite universe. However, they don't need to submit the coordinates of the planets they conquer. Otherwise, they would be exploitable. Instead, players submit the hashes of the coordinates and a locally-generated zero-knowledge proof attached. In the same way, whenever they want to move from Planet A to Planet B, they need to provide two hashes of the coordinates of the planets plus the correspondent zk-proof. Only the player knows the coordinates and the state transitions as they are stored locally. Every external user will only see the hash and the zk-proof.

Scheme from Dark Forest's blog

The biggest drawback of ZKPs is that they are pretty computationally intensive to generate. For example, generating a zkSNARK nowadays might take a few to tens of seconds on a modern device. Though, it is even possible to delegate a remote party to generate the ZKP on your behalf.

In each case, for real-time games, generating a ZKP will need to scale down to sub-seconds within the following years. Hopefully, we'll get there.

Consider thousands of users generating hundreds of thousands of smart contract reads per second through calls to the public RPC endpoints. It could quickly escalate into episodes of network overloading, hence degrading the in-game latency. Ideally, every user should be able to run their local node on their browser/device.

Furthermore, on-chain gaming can have weaker security assumptions than on-chain finance-related activities, as the economic damage from a forging attack is orders of magnitude smaller. Therefore, running a local light node could be considered good enough from a security standpoint.

Ethereum's stateless clients + Verkle trees, Mina's recursive zkSNARKs, and Polkadot's Substrate Connect are steps towards this path.

However, the RPC congestion problem is only one of the latency issues. Due to the peer-to-peer nature of the network, players might suffer high latency because of the network topology.

One solution to the latency problem we've read about is opening game channels by the Xaya team. Being state channels, players could open a direct off-chain communication channel where they would play their moves while updating the state on-chain from time to time if the contract state needs to be overridden according to the game rules.

It would allow for real-time interactions down to the minimum latency limit of the geographic distance between the involved parties.

players interact off-chain in their direct communication channel and settle on-chain only if needed

However, opening an off-chain channel between two parties might introduce two major drawbacks:

establish the order of the event without the presence of a central authority

preventing denial of services

Consider a game channel between two players for an FPS game, with some latency between the two opponents. At some point, they come in front of each other and pull the trigger simultaneously. From Player A's perspective, they shoot first. But Player B has seen the contrary. How do we establish who shot first? The above goes back to the root timing problem in a distributed system. In addition to this, when opening a direct channel, players expose their IP to each other, making them potentially vulnerable to denial-of-service attacks.

It's unclear how these drawbacks will ever be solved in a scalable and trust-minimized way.

On Bitcoin's Lightning Network, third parties can run Watchtowers to detect and prevent dishonest counterparties from stealing users' funds if they are offline or unable to respond at the time of a breach.

In an analog way, having trusted third parties acting as the timing authority within a game channel could be a satisfactory resolution to resolute disputes. Implementing an n-of-m scheme with an on-chain slashing mechanism could even be possible. A market for reputable parties offering this kind of service might emerge in each case.

Even though the above scheme would introduce a centralized component to the game, the maximum harm these third parties could do is to influence the game-round outcome by providing incorrect information but never stealing users' funds. And, if caught acting dishonestly, they could lose their reputation, their customers, and even their stake.

The above list represents just a subset of the total number of the challenges strongly on-chain games face. We have not touched reverted transactions, data storage, and a few more. Builders will have to wrap their games around the technical challenges and negative externalities of the blockchain architecture.

Still, on-chain composability and interoperability are incredibly powerful means. A whole new level of human coordination, metagames, and MEV opportunities will arise within the next few years.

At Dialectic, we have been quite enthusiastic about blockchain gaming during the last two years. We have been investing in amazing startups such as Sky Mavis, Ember Sword and Guilds of Guardians, to name a few. Monolithic blockchain constraints have forced builders to compromise by developing a hybrid stack for their games, though.

Now that blockchain scaling is slowly becoming a reality, looking towards strongly on-chain games appears to be a natural shift, especially in highly scalable environments.

We have already invested in interoperability protocols like Topology (ps, all this site's contents are pulled from on-chain contracts, on StarkNet) and a few more to pursue this vision.

We will likely continue down this path. We are thrilled about where the on-chain gaming space is headed in the following years.