Blockchains should be designed like massively multiplayer games

In my previous article I made a case about why general purpose blockchains shouldn’t use the UTXO transaction model. Now I will make the case that blockchains should not store state in transactions and I will do so by borrowing lessons learned from massively multiplayer online games.

If you think about it, every multiplayer online game is a consensus engine. All players need to reach consensus on the state of the game world. Game designers determined long ago that the game state is too large to synchronize to all players efficiently. Instead, what game developers do is generate a deterministic engine and then communicate player inputs. Assuming all players agree on the order of events, everyone knows exactly who won and who lost. With this log of events it is possible to make a complete and accurate replay of the entire game.

Imagine playing Star Craft on a blockchain. Users would generate transactions for every command they issue to their units. These transactions would get aggregated by a server which would determine the global order, then this block of actions would be distributed to all players which would then have their state synchronized.

Obviously 3 second block times would impact the game play, but in theory block times could be reduced to 20ms if there was only a single block producer.

Small Actions can create Large State Changes

A single user action that directs all units to attack an enemy base can result in endless state changes as the units move, attack, and kill each other. Assuming there are 1000’s of units, each moving 30 times per second, we are talking about tens of megabytes of state changes all triggered by a single user action requiring less than 1KB.

From a system architecture perspective, it just isn’t practical to directly synchronize state as doing so would dramatically hinder overall framerates and potentially render the game unplayable on low bandwidth connections.

Whether the game is Star Craft or a financial system, the software design patterns and architecture are largely the same. In both cases you need to prevent cheating and ensure that all players see the same state of the world. The only extra step required by blockchains is that every user action be cryptographically signed so that independent 3rd parties can audit the game and ensure the server isn’t cheating. This extra step of signature verification is completely independent of the game rules (business logic) and can also be performed in parallel.

Predictive Rendering

Games like to give users an experience that is smooth and free of latency. To do this they predict the state based upon the inputs they have received directly from other players. Eventually the client gets an official update from the server. When this happens the predicted state is replaced with the actual state plus any new predicted state.

This is exactly what happens when you view the blockchain state inclusive of unconfirmed transactions. The next time a block comes in, the unconfirmed state is reverted, the official actions are applied, and any remaining unconfirmed actions are applied on top of that.

Conclusion

The blockchain industry is largely deluded into thinking they are solving new problems, when in reality almost everything a blockchain needs to do has been known for decades by game developers. The only thing new in a blockchain is that all user actions are signed and that there are multiple servers that take turns including actions into the official log. Most of the blockchain-specific technology and consensus systems (whether POS, DPOS, POW, or something else) is completely independent of the already established designed patterns that have been proven to scale for massively multiplayer online games.

Blockchains should be designed as a log of user actions combined with deterministic logic for generating state, not a log of state changes.