EIP-5006步入最后审核_AIN:oceanchain

内容概要

随NFT租赁场景的EIP-4907被纳入以太坊标准,NFT该如何应用的问题,正在从协议底层得到认可和解答。近期同样由NFT租赁市场DoubleProtocol提案的针对1155型的NFT租赁标准EIP-5006?,也已经步入最后审核阶段,如无意外将在2022-08-01结束审核。

虽然两份提案出自同一团队,但实现与用户使用方式截然不同!这是为什么呢?

特别说明!!此标准有风险,鉴权不完全,如需使用注意需重写权限管理部分

通过本文你将理解

为什么需要丰富的NFT标准

三大主流资产标准的核心差异

5006将如何实现1155型NFT的租赁逻辑

新标准能为”大型游戏链改”提供怎样动能

1、背景

为什么需要丰富的NFT标准呢?

721标准的NFT为什么不够用?

说句玩笑话,如今的gamefi可谓好玩的不赚钱,赚钱的不好玩。

常见的gamefi项目中,721标准的NFT协议只是起到确权和属性功能的作用。如下列4中游戏内的NFT道具,犹如只为少数高氪玩家所用的屠龙刀或者深渊通行证。

但是要游戏好玩,就不能只有屠龙刀这类高净值的资产。如今大型游戏丰富的玩法要做好链上改造,更是依赖千奇百怪的场景。gamefi中要玩法升级,构建完善世界观离不开各类道具属性、功能、组合、升级、损耗、多种类数量等等特性,才能避免走向类似axie一般的玩法单一逐步枯竭的终局。

因此即使eip-4907为NFT除了所有者确权之外,带来了用户租赁的概念,这是个应用层很好的开始,见前文以太坊新标准EIP-4907是怎样实现NFT租赁的?

zkSync:EIP-4337为避免硬分叉做出妥协:金色财经报道,zkSync在社交媒体发文解释了EIP-4337和zkSync Era对原生账户抽象之间的区别,zkSync表示为了避免硬分叉,EIP-4337做出一些妥协,比如外部拥有账户 (EOA)和账户抽象 (AA)单独的交易流、单独的内存池、单独的验证器/捆绑器角色、外部拥有账户不能使用Paymasters,而zkSync通过在协议级别集成账户抽象对EIP-4337进行了改进,上述功能均可实现。[2023/3/30 13:33:53]

但也依旧不能打破721标准下的NFT太过于精简,无法在足够宏伟的gamefi场景中得到很好应用的痛点。

而一款活得久的游戏最小经济模型,也往往需要3种玩法角色的互相作用达成一种稳定供给平衡。例如EmberSword土地项目中的三种角色

基础生产者PvE:采集资源,打怪升级

挑战爱好者PvP:赢得高净值NFT和代币奖励

进阶创造者UGC:提供艺术创作,做基础物资与高级资产的连接人。

所以丰富协议基础,是Gamefi乃至NFT走向应用价值的必经之路?,而1155标准则是较早(2018-06-17)确定主打应用场景的NFT标准。

那咱们深入来聊聊最适合游戏里的NFT标准ERC1155,以及为他设计的提供租赁功能的EIP5006。

2、三大主流资产标准的核心差异

业界常说ERC1155等于ERC721+ERC20,要理解标准协议的差异,只需要看他核心存储的数据是什么

其实我们可以这么理解,区块链作为全球的底层账本,确保了智能合约这种codeisLaw的能力,即是将规则代码化,通过固定暴露的接口限定了任何人对他的使用方式,而智能合约里定义的存储数据,则是全球共享的数据库。

Double Protocol提出的EIP-4906得到Opensea支持:3月12日消息,NFT 租赁平台 Double Protocol?提出的 EIP-4906 现得到 Opensea 支持。据悉,该标准在 ERC-721 中添加了元数据事件,允许第三方及时更新其动态 NFT 的元数据。[2023/3/12 12:57:39]

2.1概念普及:20和721是如何定义资产关系的?

其实标准ERC20协议,核心是管理了两个对应关系,资产和授权关系,这里只看资产关系

_balances??:每个地址有多少Token余额数量

下方则是代码对数据存储的定义,犹如一个Excel表格的行与列,Key与value

同样的ERC721则是管理了两个资产上对应关系

_balances?:每个地址有多少个NFT

_owners?:每个NFT的ID对应的所有人地址

所以常说NFT是一个ID走天下,实现了具有唯一资产的确权性,确实毕竟他也只有一个ID。

详细了解721协议及功能细节

见前文:你买的NFT到底是什么?

下图为3大资产标准中合约的方法,都是围绕资产关系与授权关系的管理

2.2ERC1155多重代币标准-MultiTokenStandard

1155即多重代币标准,则是管理了1个“嵌套的”资产对应关系

依旧是使用_balances?作为名字,但他的结构则是NFT-ID对应地址再对应token数量

比如爱死机NFT项目中

EthHub联合创始人:以太坊改进提案EIP-1559即将实施:EthHub联合创始人Eric?Conner刚刚发推表示,以太坊改进提案EIP-1559即将实施。然后我们会焚毁很多ETH。我们将有0到负数的发行,这样有安全保障。据悉,EIP-1559试图通过引入固定费用和销毁机制来降低交易费用。EIP 1559由V神于2018年首次提出,预计使以太坊区块链的收费市场更加可预测并缓解拥堵。[2020/12/21 15:57:00]

见前文:当奈飞的NFT忘记了web2的业务安全

有9个NFT-ID,我mint得到了4号1个,那数据中会存储,4号NFT中我的地址持有1个。

这么一看,其实1155简直是天然适合应用型的NFT标准,因为一个ID可以被多人持有若干份

好比公司的股票发行1W份,分别给1k人持有,虽然持有量影响权益,但都可以叫股东。

好比mirror上铸造的文章NFT,可以被多人mint走,其收益成为作者的创作收益。

2.3小结

结合了上述的三种主流资产标准,目前大量游戏都在将生态内的道具做了资产化。

并且现在越来越多的游戏内出现了1155类型的NFT,应用在游戏内UGC创作场景

并且OpenSea的为了降低UGC创造新NFT的成本,特地设计基于1155标准的懒惰铸造特性的共享商店合约,让创作的NFT只在确定有交易之后才在链上形成真正的铸造,从而大幅度降低使用者成本

虽然笔者并不认同这种改变过多原始标准的设计

见前文:OpenSea免费创造的NFT都没上链竟能出现在我的钱包里?

V神:在eth2和EIP 1559实施前,“满足健全货币信仰”是不可能发生的:V神今晨发推特称,关于“供应门”为何重要的问题,我听过的最好的论据是,如果ETH社区没有努力建立便利函数来计算总供应量,那意味着我们不太在乎“健全的货币信仰(the sound money religion)”,而您想要一种货币。我认为在eth2和EIP 1559发行时间表实施并证明其可持续性之前,“满足健全货币信仰”是不可能发生的。因此无论如何我们都必须耐心等待几年。您会发现,许多以太坊人已经完全融入eth2之后的经济体系,尽管与此同时一些其他出色的团队已经制作出供应量计算脚本。此前消息,比特币咨询公司Bitcoin Advisory创始人Pierre Rochard表示,将发布赏金计划、寻求更多供应脚本计算ETH总供应量。[2020/8/11]

但是毫无疑问,从2年来每日交易次数来看,确实打开了低成本创作的想象空间。想必未来围绕Dapp和链层之间润滑剂的中间件相关产业会越来越丰富

虽然已经有场景在涌现,但如果从交易规模和总市值维度出发,参考研报数据如下,可以说应用型NFT相对于PFP依旧处于萌芽阶段。

3、EIP-5006将如何实现1155型NFT的角色租赁?

3.1简述721极简的租赁实现

回溯之前对721标准下角色租赁实现的解读,

见前文:以太坊新标准EIP-4907是怎样实现NFT租赁的?

可以发现,之所以如此迅速通过以太坊基金会的审核,来自于简约而不简单的实现方式

核心原理是在前文提及的721标准的核心数据之外,额外增加了一个关联属性,即指定ID的用户和过期时间,其他的代码则是提供了三个接口:

V神:EIP1559可帮助解决交易费收入过高问题:金色财经报道,V神刚刚发推文称,目前交易费收入已接近区块奖励的一半,这使得以太坊链冒着更不安全的风险。针对费用市场的提案(例如EIP1559)就是为了解决这个问题,这也说明了该EIP为何如此重要。[2020/7/22]

设置承租人?User的地址与到期时间

查询NFT-ID当前的User

查询NFT-ID当前的租赁到期时间

必须强调的是,毫无任何强制性手段来限制这个user该怎么用,即不涉及租赁收益计算,也不为nft定价做价值衡量,甚至是这个user可以理解为被租用户还是借贷抵押品,都不做标准上定义。

唯一的强制性只在防止BUG上,当我卖掉自己的NFT那么之前的授权将失效。

都不定义,所以剩下的问题就交给共识,代码里只存放最底层规则,即user是他

3.21155的租赁实现却大不相同!

租赁功能面对721标准:一个ID对应一个user和expires到期时间很合理,但1155标准:他这个ID的所有者可不只一个,所以EIP-5006仿照1155的数据结构,额外增加了3种数据来表示嵌套的资产角色租赁关系。

最终呈现出来的特点是:

1:不再考虑被租赁的时间!等于是无限期,也完全由owner来控制时间

2:由于租赁无限期,因此所有者需要再次合约交互才能来消除掉租赁状态。

3:卖出NFT之前,如果超过租出去导致冻结的数量,则需要先消除租赁的部分

通过源代码可见,他最核心数据是_allowances:

代表着每个NFT-id的每个所有者,分别有哪些租赁用户分别租了多少。

基本等于是在原始的1155核心数据上,再嵌套一层补充上租赁者和出租量的数据。

为了使用,提供了4个接口来管理1155的租赁关系

setUser:设置某个NFT-id下的某个所有者,设置多少个token数量给某个用户

balanceOfUser:查询哪个NFT-ID的哪个用户租赁到多少

balanceOfUserFromOwner:查询某个NFT-ID的某所有者下的某个用户租赁到多少个

frozenAmountOfOwner:查询某个NFT-ID的所有者其持有的token,已经被租出去多少个了

整体来说,不失优雅

虽然使用上和4907差异有所差异影响了使用成本,也导致所有者更高的应用成本,但依旧是收敛最小的强制性,仅通过对owner的frozen数据的管理来防超额出租的BUG。

3.3风险点特别说明

此标准目前的实现是有风险的,因为在标准中,对setUser函数定义为公开且为虚函数但函数内并未明确限制,”谁“有权可以去修改”谁的“租赁关系,导致任意用户可修改任意租赁关系,因此如有项目想使用5006,需要注意继承后重写此setUser设置租赁用户函数。

4、能为大型游戏的链改提供怎样动能?

当然如果排除他权限上的风险,那可以想象EIP-5006一旦定为标准,将再次掀起NFT走向应用上的热潮,为何这么判断呢?

ERC-4907的核心价值是为链上”原生租赁“提供了技术支撑,实现了NFT的所有权和使用权的分离,是解决NFT流动性短缺问题的重要基础设施。

EIP-5006的核心价值则是将进一步强化围绕”用户创作应用场景上“所有权和使用权的分离,明确NFT扩大应用价值的方向,将会涌现更多丰富的玩法、应用场景和衍生品。

正如本文背景部分所述,好的生态内不能只有官方一级发售屠龙刀,好的生态里,必须引导创作者UGC经济在整体生态内形成”生产>加工>消费“的循环。

721型NFT的定义往往只来自于官方,极致的稀有度让所有权的作用远超过使用权。

而1155型的NFT再结合原生租赁5006的推出,将会让GameFi生态里重资产的资金周转率会大幅提升。因为真正能够贡献在线时长的这些海量基础玩家们,可以用一种比较低信任的方式去租到游戏里的装备或资源等。

这将带来游戏的DAU和用户体验的上升。

目前看Land类型的游戏,top5中4家已经支持UGC创作,部分使用1155做资产标准。

同时,各类围绕游戏内置可视化编辑器辅助UGC的gamefi项目也在井喷而出。

实用性NFT协议的丰满,有了更多用铲子的人,自然就会有更多卖铲子做铲子的人。而市场的痛点和需求点倒逼各类NFT应用层的协议丰富起来。

最后,对比采用强制性限制的租赁标准,参见前文:EIP-5058能否防止NFT项目方提桶跑路?这种4907和5006的依赖于社会共识的标准将最终占领市场

codeisLaw?代码即是法律,法律威严神圣不可侵犯,在区块链的世界,也应该坚持如此,一旦确定规则就原则上不允许反悔。

总之做好定义,剩余的放心交给社会共识吧

再次强调

当前合约代码有风险,笔者向项目方提Issues,项目方回复已确认此风险,提交了新修复提案,如使用项目方使用请务必注意权限问题。

引用:

https://eips.ethereum.org/EIPS/eip-1155

https://eips.ethereum.org/EIPS/eip-4907

https://eips.ethereum.org/EIPS/eip-5006

https://etherscan.io/nft/0xfd43d1da000558473822302e1d44d81da2e4cc0d/4

对话:和ERC-4907项目方早期建设者Winkrypto一起探讨NFT市场新逻辑--?BuidlerDAO

https://mp.weixin.qq.com/s/9ncBsGH7Q1ygJHcU6U9UTQ

文中提及BUG讨论过程

https://github.com/ethereum/EIPs/pull/5204

写在最后:

前文回顾

Harmony链桥被盗一亿美金分析?

新标准4907是怎样实现NFT租赁的?

OpenSea免费创造的NFT都没上链竟能出现在我的钱包里?

你买的NFT到底是什么?

EIP-5058能否防止NFT项目方提桶跑路?

当我们在看Etherscan的时候,到底在看什么?

当奈飞的NFT忘记了web2的业务安全

欢迎你从后台提交技术问题

关注十四,用技术视角带给你价值

来源:金色财经

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:0ms0-3:856ms