Blockchain agnostic Metaverses, with the help of tokens and character DIDs.
I highly recommend that if you haven’t you check the previous article in this series. It will be relevant for the following conversation: The Universal Asset framework series.
Blockchains & the Metaverse
In order to maximize interoperability, we should design solutions for the Metaverse that are blockchain agnostic (by agnostic I mean that any blockchain can implement them, although solutions that do not employ blockchains at all are also possible, they’re not part of this article). Most popular blockchains already have the fundamental building blocks we need, and any additional tooling needed, we should be able to add them by following the improvement proposal process these blockchains tend to have (improvement proposals, or _IPs).
The blockchain component of the Metaverse could get really complicated, but the two basic primitives we’ll need to leverage are:
- Fungible (FT) and non-fungible (NFT) tokens. That will serve as a way to represent and verify the ownership of our Universal Assets (UA).
- Smart contracts, in order to handle the minting, modification, and governance of the above mentioned tokens.
These primitives cannot be replicated in an optimal way outside of a blockchain ecosystem, and therefore we should use blockchains for them.
Handling asset files and metadata
Our approach should be to minimize the amount of data that needs to be stored “on-chain”, since blockchains for the most part are not really intended to be used as databases, but public ledgers that allow for the creation, transfer, and burning of tokens — with additional logic (smart contracts) to regulate when such events should occur. The first thing we need to do is talk about how the different digital files and metadata associated to our “Universal Asset-NFTs” (UA-NFTs) should be handled.
For now, let’s assume all the off-chain files and metadata associated to our UA-NFTs will be stored in a decentralized medium, that leverages hashes and public-key cryptography, such as the Inter-Planetary File System (IPFS), or similar. Since it’s very important that the information associated to our UA-NFTs doesn’t disappear and is available for as long as possible (decades), it’s reasonable to presume that NFTs will use a decentralized system akin to IPFS, as their main source of truth. In principle, multiple copies of these files should exist in these IPFS-like systems.
This is great for redundancy and availability, however, decentralized systems tend to have higher latency than centralized systems. For this reason I believe we could see in the future parallel “hot” copies of this same information, stored in centralized servers and CDNs around the world, in order to improve how fast this information can be retrieved. These hot copies might be regularly deleted if they’re not being used in a while in order to more efficiently use space, but this shouldn’t be a problem if a “cold” series of copies always remain in a decentralized IPFS-like system.
These hot storage systems can mirror the same hashes and public keys used in their cold versions, using these as their source of truth. The cold versions would be the only ones that have to be manually updated, and these “hot storage” services should regularly and automatically check them in order to make available copies of newer versions when they appear.
The IPFS/IPNS combo
For the purposes of this article I’ll be using the IPFS system as an example, and assume you have some basic knowledge on how IPFS works. If this is not the case, it’s recommended you do some quick research before continuing.
Systems such as IPFS use immutable links constructed from the hashes of digital files (that are distributed in a decentralized manner among many nodes). This means that any digital files we upload to the IPFS network, are for all practical purposes unerasable, and the link that points to each file is unique and immutable. The unerasability is not a big issue, but the immutability of links is, since there is no way to make the same link point to a different file. In order to overcome this hurdle the Inter-Planetary Naming System (IPNS) was introduced.
The IPNS system allows us to introduce mutability to our file-pointers, and introduce the notion of versioning, as a way to change and update the files we store using IPFS. If you need a primer on how the IPNS system works I recommend you check now the following link, the first half of the page is the most relevant part: https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs
The IPNS system would allow us to upload different versions of the files and metadata we’ll attach to UA-NFTs. Each version is represented by an IPNS record, and the link that points us to all these versions is the IPNS name. The IPNS system leverages public key cryptography, so that only holders of the private key can create new versions of our UA’s files and metadata (IPNS records), and the public key can be used to let us know where we need to go to fetch these files.
The UA-NFT standard
For the purposes of this article we’ll assume that UA-NFTs are mutable, meaning their on-chain data can be modified. This will help us with the potential loss of private keys, governance, and updating the off-chain files and metadata of our UAs. Since as we’ve mentioned before, all files and metadata pertaining to the UA will be stored off-chain, We will now list some minimum information that probably needs to be stored on-chain on the NFTs themselves:
- Signatures & DIDs: In order to unequivocally link the files and metadata of a UA to its NFT, we will sign the NFT upon minting it, with the corresponding IPNS (or equivalent) private key. Additionally other cryptographic signatures could be added, such as those corresponding to various Decentralized Identifiers (DIDs), such as a public DID of who’s the creator of the UA, any co-signers (for example a brand or collaborator), or other trusted parties.
- Data pointer: The pointer to where the files and metadata of the UA need to be fetched from. In the IPFS/IPNS system, this would be the IPNS name.
- Active version: Naming the specific version/IPNS record of the files and metadata of the UA, that should be fetched and used in virtual worlds.
- Token information: The information pertaining to the NFT with its Blockchain. This is dictated by the blockchain itself. Namely, information about the collection (how many copies of the NFT exist, the minting policy, etc.).
When we discussed the UA framework previously, we introduced the concept of the Universal Asset Creator (UAC). This UAC would be the tool responsible for constructing the files and metadata (IPNS records) to be linked to the NFT, and minting the NFT. The UAC would also be used every time we wish to update these files, by creating a new IPNS record. It is likely that the UAC will sign each IPNS record (or use other means), to ensure virtual worlds that the data they’re about to import into their worlds has indeed been created using this tool, following the specifications of the UAC.
We’ve said that the on-chain data of these NFTs should be modifiable, but we haven’t specified how or when this modification should happen. This is where governance kicks-in.
Governing UAs
Many UAs will have one person create them and a different one use them, many UAs will have multiple users. If a virtual world creates a sword and gifts it to 10,000 users, or you buy a UA on the secondary market, who should get to modify the on-chain data of those NFTs?
The simple solution would be to give all the control to the creator of the NFT, but I think we can do better. I think we should build a governing system, by which token holders need to arrive at a super-majority consensus, before any changes to the on-chain data of those NFTs can occur.
In this way, the creator of the NFT cannot arbitrarily change the external files and metadata that’s used to represent the asset, nor start minting more NFTs against the wishes of token holders. The creator of the NFT will likely be who holds the IPNS private keys, and therefore can post new versions of off-chain data and metadata for that UA, but that’s why we introduced the “active version” field in the on-chain data. The “active version” is the specific version that virtual worlds should implement, CDNs cache, etc. And to change the active version, that should require a majority consensus from token holders.
I’m not sure how the actual voting process will happen, and I’m sure each blockchain could implement it in a different way. But it makes sense to use the actual tokens to give token owners their voting power. For UAs that have a closed minting policy (meaning their supply is capped and no further tokens can be minted in the future), it might make sense for example to give 1 vote per token.
It might be a bit more complicated in the case of NFTs with an open-minting policy (new tokens are created on a regular basis), since a malicious user could theoretically try and mint a very large amount of tokens in order to gain a lot of voting power.
One solution to this problem might be to structure the minting of new tokens by tiers or batches, with a fixed number of tokens being created on each batch. When a new proposal to change the on-chain data of the NFT arises, it can be specified that only the tokens minted up to a certain point in time give voting power. This is just an example, probably not the best, of a possible solution to this particular problem.
Also, in the case that some issue occurs with the private keys or the data held on IPNS, a vote to change the on-chain data can happen, invalidating the prior private key IPNS signature and IPNS name, and changing them for new ones.
Character-DIDs
An interesting question that arises when we start thinking about our avatars in the Metaverse is, how can we assign different “state” to our different avatars/characters?
For example, we might want to have one of our avatars visit many virtual worlds with the same equipment. Or perhaps we’ll have different avatars or characters inside the same virtual world, each one belonging to a different playthrough.
This might be done with a novel special type of DID (decentralized identifier), which we’ll call here—character-DIDs. These character-DIDs would hold information pertinent to your avatar, such as its current equipment and its progress or achievements accomplished in any given virtual world.
Equipping your character & saving progress
For the equipment part, we could come up with a standard of what classes of UAs are “equippable”, by defining a certain number of equipment slots for avatars. Then for each DID we would assign a certain UA to each slot. This practice of using slots for equipment is standard in many games.
Our character-DID would tell virtual worlds what UAs from all the UAs in our wallet should be the ones they need to render and use in-world. This could be expanded to things like spells also. The important thing is to use a standard for how many slots each character should have, how many spells they can equip, etc. At any given time the user can swap the item in each slot for another one.
In order to save the in-world progress and achievements of our characters we have to do things a bit differently though. It wouldn’t make much sense for users to inscribe themselves the progress of their character’s journey inside any given virtual world, it makes more sense for this job to be handled by the virtual world. This is why these character-DIDs will likely be made in collaboration with virtual worlds. It would make sense for us to create them every time we make a new character inside a virtual world.
The creation process of these DIDs would be a bit more complicated than a traditional DID. Instead of using a single pair of cryptographic keys like most typical DIDs have, we should create for them 2 pairs of keys, each pair allowing to modify a different part of the character-DID. The user would hold the private key necessary to change the current equipment assigned to that character, and the virtual world would hold the private key necessary to inscribe the progress and achievements of that particular character in the DID. Both public keys would be displayed in the DID, so that by reading any DID it’s obvious what specific character and what specific virtual world that DID belongs to. Under this particular scheme, these character-DIDs are always bound to a specific virtual world.
But what if we want to have an avatar or character that stays the same across multiple virtual worlds?
The meta-character-DID
The meta-character-DID could be our world-independent DID, representing us across multiple virtual worlds. The equipment we assign to this DID, acts like a template, being the default equipment we’ll import into any new virtual world we join, when we create a new character-DID.
This could be a more traditional DID with a single pair of cryptographic keys held by the user. This meta-character-DID could be additionally linked to a bunch of our character-DIDs, this would be a way to showcase how the same identity/avatar went through “different adventures” in different worlds.
Either of these DIDs, could optionally have an associated NFT representing their ownership, but this is not a mandatory necessity. They could also be handled by a third party in a semi-custodial, or full-custodial manner. It should be up to users to choose which option is the most convenient for them. They should be easily updatable on the fly, and changing them shouldn’t require actively interacting with a blockchain (constructing transactions), but is done instead passively. We only need to read the wallet of the user, and verify that indeed they own the UA-NFTs they’ve assigned to their avatar’s DID. The modification of the DIDs we should be able to do them off-chain.
Final remarks
As we’ve seen, this would be one way in which we could implement DIDs, NFTs, and decentralized storage, to serve the many purposes we’ll need for our UAs and avatars across the metaverse. And we should be able to do this in a way that is agnostic to the blockchains or the storage providers facilitating these services.
All of this would have to be codified in the form of new standards. A standard for Character DIDs, a standard for storing data off-chain, for the data stored on NFTs. But this can be done with the technology and practices already available to us today.
Needing to lock-in to a specific blockchain ecosystem would hurt interoperability, and therefore we should strive to find solutions that can accommodate many ecosystems, and let users decide which one they want to use for their particular needs.
