这一次，我们将讲述上次轻描淡写过的ERC 1155标准以及如何在DEX上实现交换协议。
有关MOLDEX概念，请参阅上一篇文章。
由ERC 721Token代表的游戏装备
从 Cryptokitties 开始，目前的以太坊 Dapps 游戏以Token为中心，符合ERC 721标准。 ERC 721Token标准定义了不FungibleToken元数据，并将其用作游戏装备或角色。
例如，在 Cryptokitties中 ，我们定义了一个连接到ERC 721TokenID的Kitty结构（struct），并在那里存储了角色的必要参数。
:kitty.sol
struct Kitty {
uint256 gene;
uint64 birthTime;
uint64 cooldownEndBlock;
uint32 matronId;
uint32 sireId;
uint32 siringWithId;
uint16 cooldownIndex;
uint16 generation;
}在Cryptokitteis中 ，此结构中包含的参数管理由ERC 721Token表示的字符的元数据。 各种 Dapps 游戏存在时，符合ERC721Token， 是由摆动到一个单一Token元数据和ID来区分的装备。
用 Dapp表达 游戏物品
由这种元数据的“游戏装备抽象化”是 Dapps 开发中非常重要的元素。 在CryptoKitties 的示例中，除了作为决定外观的因素的gene之外，元数据还包括关于交配，父母和世代的信息。 通过在元数据中包含这样的信息，它对应于拍卖功能和配对功能，但是将来可能难以添加更多功能。
因此，在 Dapp中 ，可以说在开始时定义的数据结构在此之后极大地影响了游戏的发展。
查看Etheremon 示例，以下结构被定义为表示怪物的结构。
:etheremon.sol
struct MonsterObj {
uint64 monsterId;
uint32 classId;
address trainer;
string name;
uint32 exp;
uint8[] statBases;
uint8[] skills;
uint32 createIndex;
uint32 lastClaimIndex;
uint createTime;
}例如，在这个 结构中，可以想象 statBases 表示添加了早期怪物参数，技能的技能和参数。 正如我们在 CryptoKitties 的例子中所证实的那样 ，开头定义的元数据结构在此之后改变了游戏的可扩展性。
在下文中，我们将考虑ERC 721Token是否能够正确表示游戏装备以及ERC 1155Token的有用性，以及它们的示例。
ERC 721代币可以代表游戏物品吗？
在符合 ERC 721Token的Dapps 游戏中，游戏物品被表示为Non-Fungible Token ，因此可以逐一区分它们。 当然，对于每个装备都有自己的属性或参数随用户开发而变化的装备，可以说使用Non-FungibleToken是合适的。
然而，物品如配件的参数为不变的物品及装备（如：“草药”，“剑”，“石子”等等）， 这类更准确的应该被分为FungibleToken。 为固有的虚拟代币提供单独的元数据可以减少游戏装备的流动性，这可以说是区块链游戏创新的核心以及在想要节省数据资源的区块链游戏中会产生多余的情况的一个原因。
我们来举一个具体的例子。假设存在不必逐一区分的“普通的剑”和在游戏中逐个参数不同的“稀有的剑”。 将前者表示为Fungible，将后者表示为Non FungibleToken是恰当的。 但是，当所有物品都被归类为Non Fungible时，当你想要逐一交换“10把普通剑”和“1把稀有剑”，“10把普通剑”时它需要被替换为一把单独的剑。
因此，在交易时会产生额外的交易成本。 这被认为是区块链游戏中的一大损失，其中交易费是一个大问题。
在这方面，我认为需要一个可以代替Non-FungibleToken和FungibleToken的新Token标准 ，取代ERC 721标准。 从接下来一张我们开始讲述我们计划采用的ERC1155Token。
ERC 1155标准的概述
为了管理多种Token类型的智能合约的标准接口。 单个ERC 1155Contract可以包括Fungible Token，Non Fungible Token或其他配置（例如，半替代Token）的任何组合。
此标准是一个智能合约界面，可以表示 任意数量的 Fungible和Non-FungibleToken类型。 现有标准（如ERC-20）要求为每种Token类型部署单独的Contract。 ERC-721标准中的TokenID是单个非替代索引，这些非替代组被部署为包含整个集合的设置的单个Contract。 相反，ERC-1155多Token标准允许每个TokenID 表示新的可配置Token类型 。 此Token类型具有自己的元数据，耗材和其他属性。
_id参数包含在每个函数的参数中，并指示交易中的特定标记或标记类型。
诸如ERC-20和ERC-721之类的Token标准要求您为每种类型的Token部署单独的Contract。 这会在以太坊区块链中放置大量冗余字节码，并将每个TokenContract分成其自己的授权地址，这也限制了某些功能。 随着区块链游戏和支持它们的平台的出现，游戏开发者可能已经创建了数千种Token类型，并且需要新类型的Token标准来支持它们 。 但是，ERC-1155并非特定于游戏，因此许多其他应用程序可以从这种灵活性中受益。
此设计允许新功能，例如一次传输多个Token类型，从而节省交易成本。 可以在此标准上构建多个Token交易（托管/原子交换），从而无需单独“批准”单个TokenContract。 在单个Contract中描述和混合多个可替代或不FungibleToken类型也很容易。
ERC1155的规格
以下 说明基于EIP1155的ERC1155Token所要求的特征部分。
区分Fungible和Non Fungible
Contract中使用的_id是uint256，前半部分和后半部分可以除以128位。
为方便起见，前半部分称为 TokenId ，后半部分称为IndexId 。
例如， 通过运行薄荷功能ERC1155， 产生一次FungibleToken，_id 是： 在 mintNonFungible 函数发生两次NonFungibleToken。
也就是说，它具有以下特征。
- FT的负责人总是
0 - FT的 IndexId （后半部分Id）将始终为
0000000000000000 - NFT的负责人总是
1 - 每次执行
mintNonFungible函数时， NFT的 IndexId （下半部分的Id）都会增加。
因此，在 ERC 1155中，FT和NFT之间的区别在_id的开始（0或1）处执行，并且NFT之间的区别 由后半部分中的 IndexId 执行。 当然，FT之间没有区别。
Token的移动
:erc1155Spec.sol
//移动多个Token
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;//移动Token
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
正如上面提到的，ERC1155Token， 除了safeTransferFrom， 支持功能还提供了safeBatchTransferFrom。 在这里，使用uint256 [] _ ids，uint256_value，可以指定要移动的多个标记和值的ID。
也就是说， 可以在单个交易中交换十个FungibleTokenA，一个Non FungibleTokenB和一个Non FungibleTokenC.
如何定义ERC1155Token的元数据
如开头所述，在定义游戏项时如何定义元数据结构非常重要。
虽然ERC 1155Token允许以后自由生成Token，但以后无法自由设置元数据。 因此，当使用ERC 1155Token作为游戏项时，有必要在开始时仔细设置元数据。
正如我们在前面的示例中看到的， CryptoKitties 元数据和 Etheremon 元数据是完全不同的。 这是因为 ，虽然 CryptoKitties中没有所谓游戏中战斗的概念，但 Etheremon 具有诸如战斗，技能增长和进化等参数。 如果您打算创建一个高度可扩展的游戏，例如，以NonFungibleToken示例，将需要同时拥有想要战斗的装备（角色）和与战斗无关的装备（例如：怪物和装备物品）。 此外，一些装备 （角色）将随着游戏的进展而增长， 并且一些角色将保持与其初始值不变。 另外，对于FungibleToken，有“收获”是恢复装备，并且还有诸如“剑”和“枪”之类的装备，这些也会增强装备技能。
如何设置可以表达这些差异的抽象元数据？ 当使用ERC 1155Token作为游戏物品时，这一点被认为是非常困难的一点。
作为不FungibleERC1 155Token的元数据，参考ERC 721案例，定义gene和技能等元数据，并且在具有增长和变化的Token的情况下，适当地改变这些值。有可能通过表达角色的成长
另一方面，在 FungibleToken中， 除了包括在现有ERC 20标记中的 totalSupply 和name之类的参数之外 ，我们认为还应包括关于装备特征，string和 uint 类型的，像skills和effects这样的信息参数。
在任何情况下，通过设置适当的元数据，将能够创建比现有 Dapps 游戏更具有可扩展性和流畅性的游戏。
ERC1155Token元数据设置示例
以下是 使用ERC1155的游戏道具的示例。 例如，以下的Non FungibleToken为例。
:nonFungible.sol
struct NonFungibleMetaData {
uint256 id;
uint256 genes;
uint8[] skills;
string name;
uint256 winCount;
uint256 papaId;
uint256 momId;
uint256 saleDuration;
bool isOnSale;
}在此示例中 ，设置元数据以支持Non-FungibleToken的名称，能力，外观，交配和拍卖等功能。 如果这是现有 Dapp 字符 的 图像，则上述功能可能不是必需的和充分的。
另一方面， 请将以下内容视为FungibleToken。
:fungible.sol
struct FungibleItems {
string name;
uint256 totalSupply;
uint256 itemPrice;
FungibleItemExecInterface tokenContract;
mapping(address => uint256) balances;
}在这里，我们准备了FungibleToken名称，总供应量，价格，持有量和装备执行界面。
通过设置 FungibleItemExecInterface ，可以将如草药和武器之类的Fungible物品抽象化，甚至可以执行其物品。
下面是 FungibleItemExecInterface的示例。
:fungibleItemEffect.sol
contract FungibleItemExecInterface {
function modifyGenes(uint256 _gene) external returns(uint256);
function modifySkills(uint8[] _skills) external returns(uint8[]);
}这里 定义了两个函数。 modifyGenes 是一个接收 nonFungibleItem 的gene之后并将修改的gene 返送回去的函数。
另外，ModifySkills 是接收NonFungibleItem的skills后将修改的skills返送回去的函数。
通过以这种方式定义界面，可以为更改每个装备赋予角色的效果。
如果想为每个游戏（例如战斗或抽奖系统）实现独特的功能，则需要考虑进一步考虑与线下时的合作，但通过设置如上所述的元数据，它将适用于多个装备，更有可能灵活的对应。
Dex 与ERC1155Token的兼容
Moldex α版本通过构造符合带有如上所述的ERC1155Token的 Dex 实现更具有灵活性的Token传输 。
目前的 ERC 721的 Dex 仅支持Non FungibleToken，但是通过支持包括Fungible Tokens在内的ERC 1155标准， Moldex 不仅适用于Non Fungible和角色，还适用于“购买10个草药”这样Fungible的装备。 这不仅会增加游戏间的资产转移，还会促进ERC 1155Token的传播，并有望为 Dapps Games做出进一步的发展与贡献 。
— — — — — — — — — — — — — — — -
Cosmos Gaming Hub Project(前MOLD Project)
CEO&Co-Founder
朝野 巧己
为所有游戏爱好者提供最好的娱乐
