本篇文章深入探讨了 ERC404 这一新兴的半同质代币标准,包括其基本概念、实现逻辑、特性与潜在风险,并与传统的 ERC20、ERC721、ERC1155 标准进行了比较。此外,文章介绍了社区对 ERC404 的反应及后来衍生出的新标准 DN404 的发展。整体上,该文章为读者提供了关于 ERC404 的全面理解,是当前区块链领域的重要内容。
EIP - 以太坊改进提案是规定以太坊潜在新特性或流程的标准。EIP 包含拟议变更的技术规范,并在社区中发挥“真实来源”的作用。网络升级和以太坊的应用标准通过 EIP 过程进行讨论和开发。EIP 在以太坊上如何进行更改及其记录中发挥着核心作用。它们是人们提议、辩论和采用变更的方式。
EIP 有三种类型:
具体而言,以太坊请求评论(ERC)是一种标准跟踪 EIP 类型,本质上是一组技术文档,包含关于开发智能合约的指南。它们定义每种代币类型的一组特定功能,并促进应用程序与智能合约之间的交互。任何人都可以创建 ERC。不过,这需要经过以太坊改进提案(EIP)的过程。
一旦开发者提交他们的提案,就会被以太坊的核心开发者评估和审查。如果社区认为这是对区块链生态系统的重要补充,提案将被接受、完成并实施。
一旦这一过程完成,初始文档将成为其他开发者可以用作创建自己代币指南的 ERC 标准。
如果你有兴趣了解更多关于以太坊及其可扩展性解决方案的信息,请阅读我们的文章:Fuel Network, Ethereum Rollups & Blockchain Scalability。
在深入讨论 ERC404 的细节之前,有必要检查现有的代币标准:ERC20, ERC721, 和 ERC1155。
在2024年2月初,一个名为 ERC404 的新实验性代币标准被引入。尽管它不是官方标准,但由于其将 ERC20 代币的可替代性与 ERC721 代币的独特性合并为半可替代代币的主要理念,它在短期内获得了巨大人气,尽管这些标准并不打算结合。
在其 当前实施方式 中,ERC404 有效地隔离了 ERC20 和 ERC721 标准逻辑或在可能的情况下引入路径。路径可以最好地描述为一种有损编码方案,其中代币数量数据和 ID 占据共享空间,假设占用 ID 空间的微不足道的代币转账并不会发生或无需发生。
重要的是要注意,初始实施 并没有接受正式审计。尽管经过测试,重叠标准的集成意味着协议可能无法完全理解它们的组合功能。
考虑一个涉及 ERC721 NFT 合同的场景,这个合同代表一块巧克力。
在传统设置中,创建一个单独的巧克力 NFT 会使拥有人余额从 0 增加到 1。如果拥有者转移他们的 NFT,他们的余额将重新回到 0。系统只允许交易完整的 NFT。
然而,设想这块巧克力用 ERC404 代币表示。
使用这个合同,存在一个基础单位类似于 ERC20 代币中找到的。对于这个场景,可以使用 100 作为基础单位(尽管通常它可能是 10^18)。
在这个系统下创建一块巧克力 NFT 意味着拥有者的余额为 100,而不是只有 1。起初,这可能看起来和传统的方法类似。然而,系统在这一点上显著不同,因为这种行为允许交易部分 NFT。
例如,拥有者可以将他们的巧克力 NFT 中的 20 个份额转移给另一方。随后,他们的余额会减少到 80。在余额低于 100 的情况下,拥有者不再拥有完整的 NFT。保持至少 1 个基础单位(在这个场景中为 100)的份额对于 NFT 的拥有权是必需的。
某个地址所拥有的 NFT 数量由其余额与基础单位相除并取整值决定。
拥有 169 个份额相当于 1 个 NFT。拥有 199 个份额仍然意味着 1 个 NFT。然而,拥有 200 个份额则意味着 2 个 NFT。
ERC404 利用铸造和销毁机制来促进每次在所有者之间交易份额时的代币部分拥有权。
在检查 ERC404 代币的实现时,可以明显看出几个状态变量映射负责管理代币会计:
所有 ERC404 函数的高级概述
以下是所有 ERC404 函数及其用途的高级概述:
所有权管理函数
transferOwnership(address _owner)
:允许当前拥有者将合同的所有权转移到一个新地址。成功后会触发 OwnershipTransferred
事件。revokeOwnership()
:使当前所有者能撤销所有权,从而使合同没有所有者。此操作会触发 OwnershipTransferred
事件,指示所有者地址现在为 address(0)
。代币管理函数
setWhitelist(address target, bool state)
:允许合同所有者将地址添加到白名单或从白名单中删除。ownerOf(uint256 id)
:返回特定代币 ID 的拥有者,通常用于 ERC721 代币标准跟踪单个代币的拥有权。approve(address spender, uint256 amountOrId)
:设置或更新 spender
以代表调用者管理特定数量的代币或特定代币 ID 的权限。setApprovalForAll(address operator, bool approved)
:授予或撤销 operator
管理调用者所有代币的权限。transferFrom(address from, address to, uint256 amountOrId)
:使支出者能够在所有权和权限检查的前提下,从一个地址转移部分或整个代币到另一个地址。transfer(address to, uint256 amount)
:允许代币持有者将代币的部分转移到另一个地址。safeTransferFrom(address from, address to, uint256 id)
和 safeTransferFrom(address from, address to, uint256 id, bytes calldata data)
:这些函数扩展了 ERC721 代币的 transferFrom
,增加了检查以确保接收者能够正确处理代币(遵循 ERC721Receiver
接口)。内部辅助函数
_transfer(address from, address to, uint256 amount)
:一个内部函数,促进代币部分的转移,包括根据发送者和接收者的白名单状态铸造或销毁代币(如有必要)。_getUnit()
:根据 decimals
状态变量返回代币单位,帮助计算转移、铸造和销毁时的值。_mint(address to)
:铸造一枚新的代币到指定地址,增加 minted
计数并更新所有权映射。_burn(address from)
:从指定地址销毁一枚代币,减少 minted
计数并清除相关的所有权和批准映射。虽然所有函数与 ERC20 和 ERC721 的函数不同,但在 transferFrom()
和 _transfer()
函数中看到了最显著的差异,值得指出。
transferFrom()
函数分为两部分 - “可替代” 和 “非可替代” 代币转账。该函数通过比较 amountOrId
参数与 minted
计数来区分二者。如果 amountOrId
小于或等于 minted
,则该操作被视为 NFT 转移。合同会调整跟踪 from
和 to
地址所拥有代币的数组。这涉及到从 from
地址的数组中移除代币 ID,并将其添加到 to
地址的数组中。
否则,对于大于 minted
变量的 amountOrId
,将调用代币的部分转移,这涉及到使用 _transfer()
方法。然而,考虑一下在 Uniswap 上进行小额代币交换的场景。例如,假设调用者已经给予路由器权限以支出 ERC721 代币,交换使用指定金额。然而,由于第 232 行 balanceOf[from] -= _getUnit();
和第 235 行 balanceOf[to] += _getUnit();
,该对会接收到一个完整的基础单位(代币)。这意味着差额 _getUnit() - amount
实质上是作为费用分配给流动性提供者。
从不同的角度来看,这种设计可能容易受到另一种类型攻击的影响。
考虑 Alice 将她的 ERC404 NFT ID 为 12 的、最后铸造的 NFT 存入一个接受此类代币的金库的场景。该存款会激活 transferFrom()
函数的 “非可替代” 方面。然后,Bob 存入 100 个 ERC404 代币,这个数量超过了总铸造的 NFT,导致 “可替代” 转移。随后 Bob 尝试提取数量较少的代币,特别是 12 个,这触发了该函数的第一个 if 语句,结果导致 Bob 偷走了 Alice 的代币。
显然,用新的和不明显的机制重载现有功能签名带来了挑战,许多支持 ERC404 代币的系统可能容易受到此类攻击。
transferFrom 代码片段
_transfer()
函数处理代币的部分转移,即通常的 ERC20 转移。然而,它独特的运作是:如果接收者的余额(to
)在转移后足以构成新的 NFT,则会根据新形成的基础单位(代币)铸造相应的 NFT。相反,对于发送者的地址(from
),如果余额不足以构成基础单位,则会销毁它的最后 NFT。
这一“标准”的这一方面是最有争议的,因为其含义在社区中引发了广泛讨论。例如,如果所持的最后一个 NFT 稀有且有价值,转移哪怕是其中一小部分都可能导致其损失。
再次考虑巧克力 NFT 的例子:如果拥有者持有 100 个单位,相当于一个基础代币,并向另一方转移 50 个单位,他们的 NFT 将被销毁,直到有一方的地址累计足够以达到或超过基础单位,两方都不再拥有完整的 NFT。
从另一个角度看,可以人工减少 “ERC721 供应” 到零。考虑将这种代币化模型应用于重要资产,如房屋的影响。
此外,值得一提的是,对于不在白名单上的地址,存在一部分跳过铸造和销毁,仅实际转移份额,这种行为也可以被视为奇怪。
_transfer 代码片段
大量讨论和不同观点的激增突显了转移中的异常行为,以及管理所有权的多个映射和余额导致的高 Gas 成本——简单转移大约需要 125k gas,是 ERC721 转移的两倍,可以清楚地看出 ERC404 引发了社区中诸多讨论。
其中第一个指出这种“标准”中异常的是 CharlesWang:
我认为 ERC404 的主要问题实际上在于,如果你执行正常的 ERC20 转移,你的唯一 ID 是不可逆转地被销毁的。想象一下拥有 ID = 1 的代币。一旦你执行正常的 ERC20 转移,添加 lp,无论如何,ID 1 就会被永久性销毁,接收者将只能获得下一个当前铸造的 ID。
同时,Simon Tian 引入了 ERC404A,该提案解决了转移时最后一个 NFT 被烧掉的问题,通过添加一个 _swapPosition()
函数。该函数允许重新排列所有者收藏中的 NFTs,并确保该操作仅对同一实体拥有的 NFTs 是允许的。
接着, Pop Punk 在第二天表示他正在开发一个改进版 ERC404,但不再在前面加上奇怪的“ERC”:
好吧,这正在发生。我召集了gas优化的复仇者,我们正在构建一个更好的 404... 现在。我们不会把 ERC 添加到这个名字中。不再如此。
我们看到一个合同破坏了以太坊的体验,导致每个人的Gas激增。在几个小时内,我们聚集了一些领域里最聪明的开发人员,来构建一个更好的解决方案并纠正这一点。
大约在第一次推文后 48 小时内,新标准 DN404 完成:
DN404 的开发已经完成。我们正在获取开发者的反馈,并审计智能合约。顺便提一下,DN 代表可分割 NFT。
重要的是要注意,DN404 的 代码 尚未经过正式审计,用户应自行承担风险。然而,新标准通过引入一个基础的 ERC20 合同和一个镜像的 ERC721 合同来解决了原有的问题,而不是单一的合同。大多数交易将通过完全合规的基础合同进行,该合同跟踪用户余额。当代币被转移时,镜像的 NFT 将在 ERC721 合同上铸造/销毁,后者也是完全遵循其标准的。更多信息可在 这里 找到。
自 0 到 375M 市场市值一周时间,这些是贡献于该结果的一些首个项目:
Pandora 是 ERC404 的早期采用者,拥有 10,000 个 PANDORA ERC404 代币和相同数量的 “Replicant” NFTs。购买 PANDORA 代币将自动在购买者的钱包中铸造一个 Replicant NFT。
DeFrogs 提供了一个以 Pepe the Frog 为主题的 10,000 个 NFT 集合,标志着第一个根据 ERC404 标准的 PFP 集合。
其他使用该标准的项目包括 Monkees (MONKEES)、Punks404 (PUNK) 和 EtherRock404 (ROCK)。
- 原文链接: threesigma.xyz/blog/erc4...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!