Understand the Concept of Changing Token’s On-chain Attributes
Explained via illustrations
A quick reminder — in the series, users are expected to use game items in-game world. Using them to kill monsters gives them better items attributes in both the game world (in real-time) and the on-chain world (in the on-demand manner to save gas). Let’s discuss making a reasonable and fair mechanism to allow users to change game loot attributes. Key rules should be:
- users cannot create change themselves (otherwise they will be able to boost game item params unfairly without reflection in the in-game world)
- the game owner cannot perform any change on users loot
Creating change record
So what we see here is that the concept is as follows, game owner based on players in-game achievements produces a file describing the change (which attributes values should be increased) however cannot apply it (as they do not own the loot, nor are they willing to pay for the transaction).
Applying change record
Similarly, the player can download a change record from the game and can decide whether to apply it or not, however, the player can not produce a change record themselves and apply the change as the smart-contract will check if the change is legit — if it comes from the game and smart-contract owner.
The atomic change scope
From the beginning, the concept has been to design change in such a way that it describes all params change — users can choose either to perform a change in its entirety or decline the change completely.
Conceptual change record
{ "attributes": { "Level" : NEWlevel, "Damage" : NEWdamage, "Agility": NEWagility }, "image": "ipfs://content-based-path-to-NEW-image", "signature": "some way of proving the change is legit" }The example above will be ok if all params would be stored on-chain. But the only thing stored on-chain is the URI so there is no need to describe change as those params.
The change is just assigning a new URI that itself stores all the params that are presented above. So in fact the de-facto change record would be:
{ "newURI" : "ipfs://new-uri-here", "signature" : some way of proving the change is legit }Signing the transaction with the use of EIP-712
Having stated that the player can only apply change originally created by the SC owner we need to have the possibility to let the owner create the change record and sign it — such that later on when the player applies it, it is recognized as a valid change originating from the smart contract owner/game developer.
Additionally (or as a first test it might test if the tx sender is the item owner)
The full life cycle of valid change is show below:
Manual interface for change signing
In a real-life scenario, there should be no need to do anything for a game developer. The server keeping track of player progress should sign the change and allow the player to apply it.
In our case, there will be no automatic mechanism. The game developer will be signing the change manually (kind of whenever he/she wants). It allows to better understand how the change signing works with the use of metamask :)
To know everything related to signing and verification checkout my other blog post
Originally published at https://rotynski.dev
