Nightmarket is a Dark Forest plugin that allows players to buy and sell planet coordinates. Players can now use this zero knowledge & trustless feature to gain an upper-hand or simply to turn a profit.

Demo

You can directly download and play with the plugin here, while the team works on submitting it as an official in game plugin. There is no commission or fees to use the plugin, other than trx gas.

Please note: Nightmarket circuits and contracts are experimental. It is not audited and only involved a minimal trusted setup ceremony.

Motivation

Dark Forest is been an endlessly innovative game, where every iteration has introduced world building paradigms from its creative fanbase. From a UX perspective, Nightmarket extends the game with more market dynamics. Players were always incentivized to dox their enemy locations, and now there is profit to it.

From a technical perspective, Nightmarket is a productionalized example of a zero-knowledge marketplace built on top of a zero-knowledge game.

Important foundational work like 0xPARC’s Circom ECDSA circuits and iden3’s efficient poseidon hashes made it possible to build this proof of concept. Also, previous projects like PrivacyScaling’s MACI and Nulven’s EthDataMarketplace showed that it is possible to exchange private data on-chain using zero knowledge proofs and ECDH key exchanges, with any, even untrusted, counter parties.

How it Works

Each game has a Nightmarket escrow smart contract to oversee sales and payments.

Step 1: Listing

To make a listing, the Seller attests to knowing the location of a planet and its biome. Since Dark Forest contracts do publish the hashes of planet coordinates and biomebase attributes, it is possible for buyers to verify listing details on-chain.

Within the List circuit, the Seller proves knowledges of a planet’s address (its XY coordinates) and commits to a KEY used to symmetrically encrypt the coordinates (which will be sold to a buyer).

Key constraints are as follows:

In detail, we ensure:

• hash(PLANET_X, PLANET_Y, PLANETHASH_KEY): Seller proves that they know a planet coordinate, which buyers can later verify on-chain.
• poseidon_encode_check(CIPHERTEXT, PLANET_X, PLANET_Y, KEY): Seller commits to having correctly encrypted a CIPHERTEXT, using a symmetric KEY on the planet coordinates. The seller does publish the cipher on-chain for later decryption. For the Poseidon encryption check itself, we adapted @weijie’s Poseidon circuits to constrain correct encoding.
• hash(KEY): Seller separately commits to the secret KEY that was used for the above step. Notably, the actual item being sold isn’t the raw planet coordinate, but this secret KEY used to symmetrically encrypt the coordinates. Possession of the KEY means that anyone can subsequently decrypt the ciphertext and retrieve the original planet coordinates.

Step 2:

On-chain, the escrow smart contract verifies the seller’s proof and creates a new planet listing.

Then multiple buyers can make purchase orders on a single listing, as follows:

In detail, Buyers signal their interest by depositing some amount into the escrow contract, along with an expectation of a SHARED_KEY that the seller later uses to symmetrically encrypt the KEY being sold. The Buyer constructs this SHARED_KEY offline, through an ECDH key exchange scheme. She publishes a hash of this SHARED_KEY on-chain, along with her deposit. More on this in step 3.

Step 3:

Finally, the Seller fulfills Buyer’s purchase orders with a Sale circuit, proving the following:

Specifically, the Seller also performs an ECDH key exchange offline, generating the same SHARED_KEY as Buyer. Seller uses the SHARED_KEY to encrypt the original KEY and broadcasts the encrypted SALE_CIPHER on-chain.

Later, the Buyer can privately decrypt this SALE_CIPHER with the SHARED_KEY, to obtain KEY. Then, the Buyer can decrypt CIPHERTEXT with the KEY, and retrieve the original planet coordinates.

Alternative Constructions

There are multiple alternative ways to build a zkMarketplace, not limited to:

• Sellers don’t have to commit to a KEY in Step 1. In a bounty based marketplace, Buyers can first put out location requests, and Sellers simply perform a single encryption step using the SHARED_KEY. We decided that this would be slightly more complicated, implementation-wise.
• Buyers don’t have to preemptively declare the expected SHARED_KEY. This way, the Seller would then have to prove within the Sale circuit that: (1) ECDH was done correctly to generate the SHARED_KEY and (2) the ECDSAPrivToPub checks pass, i.e. the Seller used the corresponding private key (that the buyer has the public key of), s.t. both parties can independently reconstruct the SAME SHARED_KEY offline. This would be a larger circuit.

Our design is meant to strike a balance between circuit size and complexity of implementation; other ZK marketplaces may find it worth experimenting with other patterns!

Plugin Development

The Dark Forest ecosystem has an extensive API and SDK that encompasses a lot of what we needed to deploy the marketplace within actual games. Plugin developers can easily access DarkForest Game UI and Backend through two global ui and df objects. In our case, the df object was particularly useful for accessing game state.

A challenging aspect of deploying NightMarket has been the circuits’ integration workflow. A few shims (noted here) were needed to make SNARKs possible purely in browser, without any server side computations. Also, to avoid using local storage, we download proof generation artifacts directly from our Github repo. Though in all, the world building potential on this SDK seems quite boundless.

Although experimental and largely nonrigorous, our trusted setup MPC was a fun process, birthing the first usable keys for Nightmarket. Because the ceremony’s participants were not determined ahead of time and didn’t precommit their secrets, we wanted to prevent adaptive attacks by applying a random beacon after each contribution. Though, we later learned this wasn’t strictly necessary.

Conclusion

There are much more unsolved, interesting dynamics with data marketplaces. For example, buyers can recoup costs by simply relisting the data. There are challenges around selling more complex forms of data. For example, proving an EVM stacktrace enabling more interesting use cases like selling smart contract exploits.

Note, Nightmarket is far from perfect and secure. Future improvements include a smart contract and circuit audit, UX/UI improvements, and iterating on various product decisions made around buyer and seller dynamics like the choice to include escrow lockups and more.

Acknowledgements

Support from 0xPARC, Factor, @GnosisChain, @phated, @weijie, @nibnalin, @kobigurk, and many reference projects including: Maci, EthMarketPlace, Poseidon Circom, Darksea Market, Artifact Market, Play to earn, Poseidon Paper.

Questions? Contact builders 0xSage and xyz_pierre.