jspahrsummers / norn

Embeddable blockchain library for low-latency P2P multiplayer games (proof of concept)

Norn

Norn (named after the Norns in Norse mythology) provides blockchain infrastructure for peer-to-peer multiplayer games, allowing players to coordinate game state without any central authority.

This library implements only the infrastructure and is designed to be embedded into a game—it is neither a client nor a server for an existing blockchain network! Customized, game-specific logic is meant to be added on top, making it actually come alive.

⚠️ This library is (not even) a proof of concept right now, and is not ready to be used in production games. ⚠️

Is this a cryptocurrency?

Emphatically no. This library implements a blockchain in the "distributed ledger" sense only, and is not secure enough to transact real funds.

Some aspects of the blockchain implementation will seem related to cryptocurrency, like the reference to "wallets," "balances," and "spending," but this refers to in-game currency only, with no real-world monetary value.

The library's design philosophy emphasizes gaming capabilities over true security. Funds may be lost or altered at any time, network forks may be trivially possible, etc. Do not transact real money using this library!

Why Lua?

Lua is one of the smallest, easiest-to-embed scripting languages—and very popular in gaming for exactly these reasons.

Although we miss out on the safety of static type-checking, and despite a much smaller package ecosystem than some other languages, Lua has bindings for basically every language & platform used to build games. The goal is for Norn to be trivially embeddable, and to give the game on top maximum latitude to use it as it sees fit.

Norn targets Lua 5.2, for compatibility with the MoonSharp interpreter (which, if you're building a game in Unity, you may find useful!).

Why a new blockchain implementation?

Most existing blockchains are built to transact cryptocurrencies (i.e., money), and their designs work toward this goal by prioritizing security, consistency, and correctness over everything else. In many implementations, block confirmations (when something is confirmed by the blockchain to have actually happened) can take minutes, or even hours.

These features are important for games too, but real-time gaming requires low latency above all else. Most multiplayer games are, by nature, slightly unpredictable (e.g., due to player ping differences) and have some incidence of cheating. Although neither effect is desirable, players will tolerate these consequences if it means that actions are mostly "instant."

Security- and cryptocurrency-focused blockchains have been occasionally combined with gaming, but these applications generally look like one of the following:

• Paying to run the game itself using a distributed virtual machine (like Ethereum)
• Games that use cryptocurrency for microtransactions
• Turn-based games that aren't latency-sensitive

These aren't good benchmarks for real-time multiplayer gaming. Norn is intended to implement peer-to-peer synchronization for real-time games that are mostly played client-side (e.g., on desktops, consoles, or phones).

Plus, this project is just a good learning exercise. 😁

Other alternatives

Flexible, low-latency blockchain implementations do exist, but I haven't found any that quite fit the niche that Norn is attempting to fill:

• eosio seems highly customizable and reasonably low-latency, but is not really built with embedding in mind. It appears to require users to run a daemon, and implements its own smart contract language (great for flexibility, but abstraction overkill for games). Games can't require users to be SysOps.
• Hypercore Protocol looks simple and very lightweight, and is available via Node.js libraries—while not quite as suited to games as Lua is, JavaScript is still highly embeddable and could work. Unfortunately, it doesn't include any consensus mechanisms, which distributed gaming requires (for fairness and to mitigate cheating). Hypercore may nonetheless still be useful as a network topology or storage abstraction.

Know of any others? I'd love to hear about them! Please open an issue, including a link, a little summary, and your thoughts on their applicability to multiplayer gaming.

Getting started

Install Lua

First, install Lua 5.2. As this is an older version of Lua (for compatibility reasons), you may need to build and install it from source, if your chosen package manager doesn't have it already.

Install LuaRocks

LuaRocks is used to manage dependencies and versioning. Download and install it according to their instructions.

The latest version of LuaRocks (v3.7.0 as of the time of writing) should work fine with Lua 5.2, but you may need to configure and build it from scratch to point it at your Lua 5.2 libraries and headers—or else provide the correct paths with each invocation at runtime.

Build and install the library

To build and install Norn for your user, run the following from the repository's folder:

luarocks make --local

If you want to install the library globally (note: you probably don't), just drop the --local flag.

Run the tests

Tests are written using Busted. Busted is not listed as an explicit dependency of the project (to avoid forcing end users to download it), so you must install it manually:

luarocks install --local busted

Then, you can run tests by simply invoking it from the repository root:

busted

Demos

The demos folder contains different examples of using Norn in projects. See the README for more information.

License

Norn is released under the MIT license.

norn's Issues

Checkpointing/snapshots

The entire game state (or, entire "relevant" game state?) should be periodically checkpointed into the blockchain, so new clients only need to fetch a fixed amount of blockchain history in order to be synchronized.

Related to partial transfers: #1

Automated packaging & LuaRocks upload

Nodes blindly trust the first blockchain they are sent

Nodes have to bootstrap themselves into the network somehow, so there must be some element of trust (e.g., you have to trust the addresses you initially connect to), but always taking the first blockchain that is received—and sticking with it—is too exploitable.

Nodes should probably query some amount of other nodes (or the producer quorum) for their copies of the blockchain, and have some conflict resolution rules if mutually exclusive chains are received in response.

Partial blockchain storage and transfer

Most clients shouldn't need a full copy of the blockchain.

Zero-knowledge proofs

Some aspects of player data (e.g., position in the game universe) may be sensitive (i.e., should not be snoop-able by every other player automatically), and therefore should not be publicized in the blockchain. However, they still need to be persisted and validated in order to arrive at a consensus about what the game state is.

There may be an application for zero-knowledge proofs (like zk-SNARKs) here, so producers agree that player A is located at position X, without the player having to reveal that position to all other players.

Randomize jitter per-ping

Right now, it's a constant offset from the normal ping interval, decided at startup. This looks especially bad in the demo, because the nodes all use the same seed to decide this offset.

Out-of-band blob storage

Storing large amounts of raw data in blocks directly may not be the most efficient solution, as these blocks will immediately get fanned out to all clients.

Potentially, it could make sense to build something like a distributed filesystem over the top, where large blobs can be placed for any client to access on-demand. The blobs should still be signed, and referenced in the blockchain using signed blocks, to limit cheating opportunities.