This time, I will explain the standard of ERC 1155 which I touched lightly last time and how to implement the exchange protocol on DEX.
Please refer to the previous article for the MOLDEX concept.
Game item represented by ERC 721 token
Beginning with Cryptokitties , the current Ethereum Dapps game centers on tokens in line with the ERC 721 standard. The ERC 721 token standard defines non-fungible token metadata and uses it as a game item or character.
For example, in Cryptokitties , we define a Kitty structure (struct) linked to the ID of the ERC 721 token, and store the necessary parameters for the character there.
:kitty.sol
struct Kitty {
uint256 gene;
uint64 birthTime;
uint64 cooldownEndBlock;
uint32 matronId;
uint32 sireId;
uint32 siringWithId;
uint16 cooldownIndex;
uint16 generation;
}In Cryptokitteis , parameters contained in this structure manage metadata of characters represented by ERC 721 tokens. Various Dapps Game is present, the token that conforms to ERC721, are distinguished item by the metadata and id that is swung into one single token.
Expressing game items with Dapp
“Abstraction of game items” by such metadata is a very important element in Dapps development. In the example of CryptoKitties , metadata includes information on mating, parents, and generations, in addition to genes that are factors that determine appearance. By including such information in the metadata, it corresponds to the auction function and the mating function, but it may be difficult to add more functions in the future.
Thus, in Dapp , it can be said that the data structure defined at the beginning greatly affects the development of the game after that.
Looking at the Etheremon example, the following structure is defined as a structure representing a monster.
:etheremon.sol
struct MonsterObj {
uint64 monsterId;
uint32 classId;
address trainer;
string name;
uint32 exp;
uint8[] statBases;
uint8[] skills;
uint32 createIndex;
uint32 lastClaimIndex;
uint createTime;
}For example, in this struct, it can be imagined that statBases represents skills and parameters to which the early monster parameters, skills are added. As we confirmed in the example of CryptoKitties , the meta data structure defined at the beginning changes the extensibility of the game after that.
In the following, we will consider whether ERC 721 tokens can properly represent game items and the usefulness of ERC 1155 tokens, and a sample implementation of them.
Can ERC 721 tokens represent game items?
In Dapps games conforming to the ERC 721 token , game items are expressed as non-fungible tokens so that they can be distinguished one by one. Certainly, for items in which each item has its own attribute or the parameter changes as the user develops it, it can be said that the expression with Non-Fungible Token is appropriate.
However, items such as accessories the parameter does not change for each item: are you about the (for example, such as “herb”, “sword”, “pebble”), it is better to be expressed as a Fungible token. Providing separate metadata for inherently Fungible tokens reduces the liquidity of the game items, which can be said to be the core of block chain game innovation as well as waste in block chain games that want to save data resources It is also a cause.
I will consider an example . It is assumed that there is an “ordinary sword” which does not have to be distinguished one by one and a “rare sword” whose parameters are different one by one in a game. It is appropriate to express the former as Fungible and the latter as Non-Fungible tokens. However, when all items have been classified as Non-Fungible items, when you want to exchange “10 ordinary swords” and “1 rare sword”, “10 ordinary swords” one by one It needs to be replaced as a separate sword.
Therefore, extra transaction costs are incurred at the time of replacement. This is a big loss in the block chain game where transaction fee is one of the big problems.
In this respect, I believe that there is a need for a new token standard that can represent both Non-Fungible tokens and Fungible tokens, which will be converted to the ERC 721 standard. From now on, I would like to explain ERC1155Token that we are planning to adopt.
Overview of the ERC 1155 Standard
Standard interface for smart contracts that manage multiple token types. A single ERC 1155 contract can include any combination of Fungible tokens, Non-Fungible tokens, or other configurations (eg, semi-substitute tokens).
This standard is a smart contract interface that can represent any number of Fungible and Non-Fungible token types. Existing standards, such as ERC-20, require you to deploy separate contracts for each token type. The token ID in the ERC-721 standard is a single non-substitutional index, and these non-substitutional groups are deployed as a single contract that contains the settings for the entire collection. In contrast, the ERC-1155 multi-token standard allows each token ID to represent a new configurable token type . This token type has its own metadata, supplies, and other attributes.
The _idparameter is included in each function’s parameter and indicates the token or token type in the transaction.
Token standards such as ERC-20 and ERC-721 require that you deploy a separate contract for each type of token. These places a lot of redundant bytecodes in the Ethereum blockchain and separates each token contract into its own authorized address, which limits certain functions. With the advent of blockchain games and platforms that support them, game developers may have created thousands of token types, and new types of token standards are needed to support them . However, ERC-1155 is not game specific, so many other applications can benefit from this flexibility.
This design allows for new features such as transferring multiple token types at one time, saving on transaction costs. Multiple token transactions (escrow / atomic swap) can be built on this standard, which removes the need to “approve” individual token contracts separately. It is also easy to describe and mix multiple substitutable or non-substitutable token types in a single contract.
Spec of ERC1155
The following explains the characteristic parts of the requirements of ERC1155Token based on EIP1155.
Distinguishing between Fungible and Non-Fungible
The _idused in the contract is uint256, and the first half and the second half can be divided by 128 bits.
For convenience, the first half is called TokenId, and the second half is called IndexId.
For example, by running the mint function ERC1155, produces once FungibleToken, _id is: Generating twice NonFungibleToken in mintNonFungible function.
That is, it has the following features.
- The head of FT is always
0 - FT’s IndexId (latter half Id) will always be
0000000000000000 - The head of NFT is always
1 - NFT’s IndexId (Id in the second half) increases each time the
mintNonFungiblefunction is executed.
Therefore, in the ERC 1155, the distinction between FT and NFT is performed at the beginning (0 or 1) of _id, and the distinction between NFT is performed by IndexId in the latter half . Of course, there is no distinction between FTs.
Token Transfer
:erc1155Spec.sol
// transfer multiple tokens
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;// transfer a token
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
As mentioned above, the ERC1155Token, in addition to the safeTransferFrom, support function is also provided that safeBatchTransferFrom. Here, with uint256 [] _ ids, uint256_value, it is possible to specify Ids of multiple tokens and a value to be moved.
That is, it is possible to exchange ten Fungible tokens A, one non-Fungible token B, and one non-Fungible token C in a single transaction.
How to define the metadata of ERC1155Token
As mentioned at the beginning, it is very important how to define the structure of metadata when defining game items.
While the ERC 1155 token allows for free generation of tokens later, metadata cannot be freely set later. Therefore, when using ERC 1155 tokens as game items, it is necessary to set metadata carefully in the beginning.
As we saw in the previous example, the CryptoKitties metadata and the Etheremon metadata are quite different. This is because , while there is no concept of battle in CryptoKitties , Etheremon has parameters such as battle, growth of skills, and evolution. If you intend to create a highly extensible game, for example, given the non-fungible token example, you will need to have both the item you want to battle (the character) and the item that has nothing to do with the battle. (Example: Monsters and Equipment Items). Also, some items (characters) will grow with the progress of the game, and some characters will remain unchanged from their initial values. In addition, for Fungible tokens, there are “harvest” which is a recovery item, and there are also items such as “sword” and “gun” which strengthens skills.
How do you set up abstracted metadata that can express such differences? This point is a very difficult point when using ERC 1155 tokens as game items.
As metadata of non-fungible ERC1 155 tokens, referring to ERC 721 case, define metadata such as gene and skill, and in the case of tokens with growth and change, change these values appropriately. It may be possible to express the growth of the character by
On the other hand, in Fungible tokens, in addition to parameters such as totalSupply and name that are also included in the existing ERC 20 tokens, as parameters including information on the characteristics of the item, string and uint types, array type meta such as skills and effects Isn’t it possible to give data etc.?
In any case, by setting appropriate metadata, you will be able to create a game that is more scalable and fluid than existing Dapps games.
Example of ERC1155Token metadata setting
Below are examples of game items using the ERC1155. For example, consider the following as an example of Non-Fungible token.
:nonFungible.sol
struct NonFungibleMetaData {
uint256 id;
uint256 genes;
uint8[] skills;
string name;
uint256 winCount;
uint256 papaId;
uint256 momId;
uint256 saleDuration;
bool isOnSale;
}In this example , metadata was set up to support functions such as name, ability, appearance, mating, and auction of Non-Fungible tokens. If this is an image of an existing Dapp character, the above-mentioned functions may not be necessary and enough.
On the other hand, consider the following as Fungible tokens.
:fungible.sol
struct FungibleItems {
string name;
uint256 totalSupply;
uint256 itemPrice;
FungibleItemExecInterface tokenContract;
mapping(address => uint256) balances;
}Here, we have prepared Fungible token name, total supply amount, price, holding amount, and item execution interface.
By setting FungibleItemExecInterfacewell, you can abstract Fungible items such as herbs and weapons and even execute items.
Below is an example of FungibleItemExecInterface .
:fungibleItemEffect.sol
contract FungibleItemExecInterface {
function modifyGenes(uint256 _gene) external returns(uint256);
function modifySkills(uint8[] _skills) external returns(uint8[]);
}Here, two functions are defined. modifyGenes is a function that receives the nonFungibleItem ‘s gene and returns the modified gene.
Meanwhile, ModifySkills receives skills of NonFungibleItem, Ru function der returning the skills that have changed.
By defining the interface in this way, it is possible to change the effect given to the character for each item.
If you want to implement unique functions for each game like battle or gacha, there is a problem to consider further including cooperation with off-chain, but by setting metadata like the above, it will be for multiple items. It may be possible to cope flexibly.
Dex compatible with ERC1155Token
Moldex α version realizes more flexible token transfer by constructing ERC1155 Token compliant Dex with explanation as described above .
The current ERC 721 Dex supports only Non-Fungible tokens, but by supporting the ERC 1155 standard including Fungible Tokens, Moldex not only works with Non-Fungible items and characters but also can “purchase 10 herbs” which the item is fungible. This will not only increase inter-game asset transfer, but also contribute to the spread of ERC 1155 tokens, and hopefully contribute to the further development of the Dapps Game.
— — — — — — — — — — — — — — — -
Cosmos Gaming Hub Project(Former MOLD project)
CEO & Co-Founder
Takumi Asano
For all game enthusiasts
