现在的 SBT 设计太注重 Vitalik 提出的「不可转移」特性，但是却忽略 SBT 的潜在管理场景。

撰文：十四君

就在 2023.3.7 日，由 10K Universe 提出的以太坊改进提议 EIP-6147 已移至最终版本（Final）！

该标准是 ERC-721 的扩展，分离了 NFT 和 SBT 的持有权和转让权，并定义了一个新的可设置到期时间的「守卫者」角色 Guard，可使得 NFT 防盗、借贷、租赁、SBT 等更具灵活。

本文将系统讲述 ERC-6147 的实现机制，并对比往期 NFT 租赁协议专案 ERC-4907、ERC-5055，来综合分析点评此协议以及适合的应用场景！

1、背景

NFT 已经可谓是个老生常谈的话题了，借‍助链上的‍不可篡改特性以及合约本身的自动化运作，实现了链上资产的确权与管理，笔者也从标准协议，租赁拓展协议，乃至于 NFT 交易市场的几种主流模式来撰写过多篇文章长文。

如果要论证 NFT 的优势可能可以罗列上几页纸，但要论证 NFT 的劣势，则千言万语汇聚成一个词：流动性！

当然各位可能要质疑的是，流动性不足的困境与实现产权分离标准有什么关系呢？

在笔者看来，事实上 NFT 流动性的困境更多不是源于 NFT 协议本身，对 ID 的非同质化机制和限定 ID 区间导致的，哪怕是近乎无穷的 ERC20token 难道就不缺乏流动性了吗？更重要的是，流动性本身是出于对金融产品的定价诉求而产生的话题，如何让 NFT 本身具有使用价值，便成了让价值有所依归而不是只依赖于市场操作的协议。

影响使用价值 NFT 使用价值的，也正是 NFT 协议本身

1.1、产权耦合，高价值 NFT 会倾向于安全避险

目前 NFT 被盗的案例很多，然而现有的 NFT 防盗方案，比如将 NFT 转入冷钱包等都会使得 NFT 的使用不便。

并且在目前的 NFT 借贷中，NFT 所有者需要将 NFT 转移到 NFT 借贷合约中，NFT 所有者在获得借贷期间不再拥有 NFT 的使用权，这边是产权耦合的问题，这其实和我们现实中购买房产再房产抵押换取流动性资金时，再非风险条件下是不用被占用房屋使用权的情况很不同。

记忆尤新的是，猴子 APE 空投时被攻击者用闪电贷结合 NFTX 进行攻击。

原事件分析可拓展阅读：EIP-5058 能否防止 NFT 项目方提桶跑路？

整件事情里，唯一受损的则是质押了猴子的用户，本来是赚取微不足道的时间利差却痛失了 ape 的海量空投。

同样的，产权耦合的还有 SBT 的问题。

对于 SBT，目前主流观点认为 SBT 是不可转让的，这使得 SBT 与以太地址绑定。但是，当用户地址的私钥泄露或丢失时，找回 SBT 将成为一项复杂的工作，并且没有相应的标准。SBT 本质上实现了 NFT 持有权和转让权的分离。当 SBT 所在的钱包被盗或不可用时，SBT 应该是可以恢复的。

例如，如果一所大学向其毕业生颁发基于文凭的 SBT，如果大学后来发现毕业生有学术不端行为或损害大学声誉，它应该有能力收回此文凭的 SBT。

1.2、产权分离分案，强制性维度难以把控

过往十四也解读过若干尝试产权分离的方案，例如 ERC-4907 和 ERC-5058，不可避免的最大的难题在于强制性程度的衡量，这并不是方案本身的问题，而是方案本身的哲学理念问题。

1.2.1、简单哲学 ERC-4907，定义愿景剩下交给共识

在 2022-07 月，NFT 租赁市场 Double Protocol 提交的可租赁 NFT 标准「EIP-4907」通过了以太坊开发团队的最终审核，成为第 30 个 ERC 标准「Final」的状态。

代码极为简单仅有 72 行，使用这个标准，就是在原来的 ERC721 之上新增

• 1 个事件（用于通知链下应用称为事件）
• 3 个方法（用于实现链上数据管理功能）

struct UserInfo {

address user;// 用户地址

uint64 expires;// 用户到期时间

}

归咎原理，其实 4907 只是新增了一个数据对象 UserInfo 在所有权的概念之外增加「用户」的维度，但是毕竟其强制性有限，只要转移就能强行终止出租授权。

详情可拓展阅读：

• 721 租赁协议解读：以太坊新标准 EIP-4907 是怎样实现 NFT 租赁的？
• 1155 租赁协议解读：NFT 租赁提案 EIP-5006 步入最后审核！

1.2.2、0 信任哲学的 ERC-5058，代码即法律

他本质上是对 NFT 的锁定状态进行管理，让项目方在继承 5058 实现的 NFT 项目中，提供锁定即转移的功能，也可以在继承中实现更多功能比如版税等。

他封装提供了若干提供方法：只有用户许可以及项目方执行之后才会完全锁定。

用户可调用

• lockApprove（许可锁定单个 NFT）
• setLockApprovalForAll（许可锁定该地址下全部 NFT）

项目方合约调用：

• lockFrom（锁定用户的 NFT）
• unlockFrom（解锁用户的 NFT）

锁定期的定义也极具强制性，近乎只依据设定之初的时间点。

项目方（第三方）锁定 NFT 时，需要指定锁定过期的区块高度，该高度必须大于当前区块高度。锁到期后，NFT 自动释放，才可以进行转移。

项目目前还是处于草稿阶段，或许强制性过高以及用户项目方双向操作的较高成本所致。

详情可拓展阅读：EIP-5058 能否防止 NFT 项目方提桶跑路？

讲述完上述完全不强制 4907，以及完全强制的 5058，便到了本文主题：最新通过以太坊基金会审查，确定为 Final 的 ERC-6147，虽然他原生的标题是：《Guard of NFT/SBT, an Extension of ERC-721 》，但十四君从系列的租赁研究经验来看，他更应该称是《半强制的 NFT 产权分离标准》

2、ERC-6147 的运作机制

此协议整体代码也非常精简且高度复用，属于对 ERC721 的拓展标准，但是要注意，如果使用了他，则转移的操作可能与常规的 721 的逻辑不同，操作不当可能容易被钓鱼，具体如何咱们展开说说。

建议拓展阅读：【源码解读】你买的 NFT 到底是什么？

2.1、Guard 是什么？谁能控制？

首先 ERC-6147 定义了一个名为 Guard（守卫者）的角色，和 4907 的 UserInfo 很相似，

struct GuardInfo{

address guard; // 守卫者地址，

uint64 expires; // 到期时间，

}

而 Guard 只有该 NFT 的当前所有者地址以及有代扣权限的地址，可以通过 changeGuard 设置，

通过源码可以看到，在设置 Guard 的时候若干的细节 // 防止误锁定，所以 Guard 不能设置为 0 地址

require(newGuard != address(0), "ERC6147: new guard can not be null");

// 只有 Guard 可以修改自己

require(guard == _msgSender(), "ERC6147: only guard can change it self");

// 只有 nft 的所有者或者获得授权者可以设置 Guard

require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC6147: caller is not owner nor approved");

设置成功后，任何人都可以通过 guardInfo 方法来查询某个 NFTID，当前的 Guard 信息，同时这里也沿用了和 4907 一样的基于时间戳的设计，所以是到期无需二次上链交易，就可以自动失效。

那 Guard 的身份，谁可以去除掉呢？只有 Guard 自己以及时间（到期）可以。

2.2、Guard 能做什么？

首先具有了强制转移权，对于设置了 Guard 的 NFT 而言，在进行transferFrom的时候，会查询交易发起方是否是守卫地址，是才能转移。

 💡 请特别注意 1：

对于设置了 Guard 的 NFT 而而言，原持有者将只有持有权，并没有转移权（即使用权），其他 Dapp 依旧可以查询到此 NFT 的所有者是原用户，但原用户无法驱动其进行转移。

所以对于设置了守卫的 NFT，在 opensea、x2y2 等交易平台上的签名是有效的（但是无法进行实际转移，因为 Seaport 等协议执行转移的时候，是由 Seaport 协议通过代扣授权来执行）

对于交易市场的运作机制可拓展阅读：

• X2Y2 十万 NFT 订单，分析版税可以不收后多少用户真这么做了？
• 一文讲清 -NFT 市场新秀 SudoSwap 的 AMM 机制 - 创新挑战与局限
• 【合约解读】CryptoPunk 世界上最早的去中心化 NFT 交易市场

 💡 请特别注意 2：

如果守卫直接进行了转移该 NFT，如果是使用原生的 transferFrom 或者 safeTransferFrom 方法，其实守卫的设置是不会自动清除的，当然如果是守卫将 NFT 转给自己自然无妨，但是如果转给某用户，然后再借助守卫者的设置是可以再次进行转移的。

因此如果后续使用 Guard，则更多是需要检验是否使用的是 transferAndRemove 方法，此方法会在转移后直接清除守卫者信息。

并且，守卫者本质上也是一种较高的控制权力，雷同于房屋租赁，抵押的那一刻，其实本质已经属于银行，只是只有银行在满足某些社会条款的情况下（如违约）才会执行拍卖等操作，既然是某种金融抵押品的属性，则自然也可以二次转移此守卫权使用 changeGuard 方法即可。

对于 transferRemove 的设计原则是为了适应不同场景。

比如防盗中，如果 NFT 在热钱包，而热钱包被盗了，冷钱包依然安全，其实只要 transferFrom 到其他安全地址就好了。

或者租赁的时候，guard 调用 transferFrom 转到新的租赁地址，就实现了租赁。

还有 SBT 的社交恢复，将 SBT 转移到新地址，依然不影响 SBT 的不可转移特性。

2.3、Guard 不能做什么？

从源码可以看到 Guard 相关的只有在授予时，是持有者和 Approve 授权者可以设置，但 Guard 是不能设置代扣的。

一方面是出于已经不需要考虑代扣授权者了，因为本质上该 NFT 的转移权被限制到了 Guard 上，另一方面是 Guard 也不能设置Approve，是防止在守卫者归还了转移权后，反而用 approve 转移走了 NFT，这样违背原本意愿，用户又难以发现的场景。

3、总结

用一张充满金融属性，稍有世俗的统计来呈现如今以太坊上 NFT 类型的资产概览吧。

每天 30 多万笔 NFT 交易，20 余万各类 NFT 合约，这样的总数都呈现出的是围绕资产确权带来的金融属性价值。

但是任何时候金融属性都需要逐渐依归，我们可以看到用 NFT 来确认社交关系的 Lens，可以看到用 NFT 来做游戏资产的各种 Gamefi，也可以看到围绕内容创作借助分拆众筹的 Mirror 等，

在以太坊问世区区 8 年多的时间来，围绕 EIP 的提案总数已经达到 6500+ ，

对比于同样重磅的 4907 而言，6147 更多是强在兼容性的优化。

比如 4907 做租赁，user 这个角色需要项目的主动认可，如果一个游戏没考虑 user 这个角色，只考虑 owner，4907 是不适用的。而 6147 只要认可 owner 就够了，并不用在意游戏项目和 NFT 本身是否支持租赁，现在大部分应用协议仍然是只认 owner 的，这也是 4907 问世后，还无法大幅度改变现状的原因，只有先适应时代潮流之中能逐渐发光发热。

另外 6147 也提出了「可管理的 SBT」和「有效的 SBT」概念，现在的 SBT 提案设计太注重 Vitalik 提出的「不可转移」特性了，但是却忽略 NFT 的潜在管理场景，比如社交恢复、收回 SBT（比如学术不端，需要收回学位，或者一个 DAO 成员在社区作恶，需要收回它的 SBT 权限）。

参考链接：

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6147.md

https://ethereum-magicians.org/t/final-eip-6147-guard-of-nft-sbt-an-extension-of-erc-721/12052