🛠️Technical Information

In our game, a valid zero knowledge proof is necessary for any merge to occur. This proof ensures that the game is updated fairly and follows the game's rules, even though these rules are not stored on the blockchain. This approach is necessary to maintain the integrity of the game and prevent other players from viewing successful merges.

Counting the items minted:

Counting items minted to embed the correct copyNum and to limit the total number of each NFT.

Rules checked in zero knowledge proof:

• Assert the preimage with the secret key matches the on-chain preimage hash

items_minted_preimage (u16[51]): an array containing the number of NFTs minted for each item ID (51 item ids).

items_minted_secret_key: a secret string of bits. This is to prevent someone from brute forcing the possible item counts and comparing it to the public hash

items_minted_hash (u32[8]): a public hash of the items_minted_preimage along with the items_minted_secret_key. This is stored on chain and is only updated according to the rules of the game (as enforced by requiring a verified zero knowledge proof to update the vale on chain)

Why don’t we subtract item count when items are deleted?

We want a way to enforce an upper bound as to how many of each item type can be minted. This rewards players for being first to mint a certain NFT type as well as forces players to interact with each other to buy and sell NFTs they can no longer make. We don’t need to keep a running tally of the items that exist.

Artifact merkle root: How NFTs are privatized

Item are made up of a cardNum, copyNum, longDescriptionHashed, privateKey

keccak hash of the item number, copy number and a merkle proof (the hash of the right side of the tree, longDescriptionHashed and privateKey)

Each NFT in the game has a unique private key that serves as a random string. This private key is essential in protecting the privacy of players' items from being discovered by others who may possess the same item. If another player has the same item, they may know the cardNum and longDescriptionHashed, but they cannot brute force every copyNum to determine other players' items due to the private key.

Checking Merges:

All possible merges are represented in a merkle tree. A leaf of the merkle tree contains a hash of [input_card_1, input_card_2, output card_1, output_card_2,output_card_3]

Where:

• input_card_1 < input_card_2

• Ouptut_card > 50 indicates an empty spot (no NFT to mint)

To ensure consistency in the merge results and prevent any manipulation, we use a specific method in which we take the lower input item number and the higher input item number to calculate a particular leaf index in the proof. This index indicates the outcome of the merge, making it the same for everyone who performs the same merge, regardless of who they are.

Minting New Item

We return a list of items to mint on chain in the ZKP

We don’t list an output item from the merge leaf if output_card#>50 or if the item count has reached the limit for the corresponding ouptut_card#.

If an output_card# is the same as input_card# then we ensure that the newly minted NFT has the same copyNum.

After a merge, the resulting NFT has a new private key, making it functionally equivalent to receiving a new NFT. Additionally, we shuffle the output items to prevent others from tracing the chain of merges even if they have access to the input NFTs. This feature enables players to mint NFTs publicly on the blockchain at the beginning of the game.