The encryption and unlock game starts with the Creator, who can be anywhere between a writer, a digital artist, a single software developer, a DeFi team, a DAO or some other legal entity. The Creator (in this case PotionLabs) has developed an idea embodied into some tangible digital media, i.e. the content, for example, a software code repository, a digital art piece or a novel (in this case the Potion Protocol’s codebase and related documentation).
In this context, PotionLabs **wants to open source the Potion Protocol codebase and bring it into public domain, but wants to do so in a way that ensures a profitable business model. At the same time, PotionLabs wants to gamify such software release in a web3-native and decentralised manner using blockchain technology, in order to help forge and solidify a social community around it.
To do so, PotionLabs **promotes an open-ended cooperative game based on the encryption and posterior collective decryption of the software. Note that this is defined as a game both in the ludic and experimental sense, and specially in the economic or game-theoretical sense, i.e. as a system of decision-making agents strategically interacting under a certain incentive environment.
This document presents the fundamental ideas around such game, which we call Potion NFT Unlock game. Throughout the following sections a high-level description of the game is provided, also including a technical brief of the encryption mechanics needed, and a potential smart contract architecture that can be used to unfold the game on a compatible blockchain such as Ethereum.
PotionLabs has developed a repository of software (plaintext) that should be revealed through a decryption process by a decentralized collective of Receivers, who are counter-parties interested in accessing the plaintext repository (in this case, the acquirers of Potion NFTs interested in the Protocol’s codebase).
PotionLabs shares such repository in an encrypted form (cyphertext) using the public storage media IPFS, so that it is accessible to everyone but only the holder of the Repository Key (i.e. PotionLabs initially) can effectively read its content.
From this point onwards, PotionLabs's business model is based on auctioning off fragments of the Repository Key to the crowd of Receivers. Each of the fragments needs to be distributed secretly, in such a way that only its corresponding Receiver can read it. In addition, each fragment needs to be accompanied by an on-chain ownership certificate, such as a Non-Fungible Token (NFT). This way, Receivers can negotiate and coordinate on-chain and independently from PotionLabs*,* in order to gather the pieces of the Repository Key and gain access to the plaintext repository.
The most basic element of the Potion NFT Unlock game is the encryption of the repository files. This is done using a symmetric key with a modern and secure stream cypher algorithm. This symmetric key corresponds to the Repository Key yellow sticker in Figure 1. The resulting cyphertext (the Encrypted Code green sticker in Figure 1) can then be uploaded to IPFS, producing its corresponding Content Identifier (CID).
Note that in order to generate the Repository Key, a genesis is required (the Repository Genesis yellow sticker in Figure 1). That genesis is a string of bytes with tuneable length, from which the Repository Key is derived using a Key Derivation Function (KDF).
Since an on-chain certificate for the Repository Key needs to be produced, a new symmetrical key (the Secret Key orange sticker in Figure 1) is used to encrypt the Repository Genesis. This Encrypted Repository Genesis can be published as metadata in the NFT smart contract without compromising the security of the Repository Key.
Again, generating the Secret Key requires the existence of a Secret Genesis string of bytes of tuneable length. This Secret Genesis is what actually needs to be fragmented into pieces (the Secret Fragment orange stickers in Figure 1) and distributed to Receivers in a secure way. Note that the exact splitting mechanics of the Secret Genesis determine the rarity of each Secret Fragment, as explained in Section 4.
In order to send the Secret Fragments securely, each Receiver should provide PotionLabs with their own asymmetric Receiver Public Key. The Receiver Public Key is used to encrypt their corresponding Secret Fragment, as shown in Figure 1. Note that, since asymmetric encryption is being used, Encrypted Secret Fragments can only be decrypted by their associated Receiver, who needs to use its own Receiver Private Key. This way, the Encrypted Secret Fragments can be securely shared in a public-facing database or website hosted by PotionLabs*.*
After distribution of the Encrypted Secret Fragments, each of the Receiver has rare information on some portion of the Secret Genesis, and needs to coordinate with others in order to gather back all fragments. Once the complete Secret Genesis is revealed, the Secret Key can be derived and used to decrypt the Repository Genesis, which in turn can be used to derive the Repository Key and thus decrypt and access all repository files.
Figure 1
PotionLabs wants Receivers to provide heterogeneous roles and powers to the participants of the collective key-revealing process that unfolds after the Secret Fragments have been distributed.
One way to do this is by introducing Rarity to Secret Fragments. Rarity is determined by two parameters, namely the bytes portion of the total Secret Genesis contained in the fragment (the Fragment length parameter in Figure 2), and the number of Receivers who receive the same Secret Fragment (the Redundancy parameter **in Figure 2).