解讀最新 Final 的 ERC-6147：極簡的半強制性 NFT 產權分離標準

現在的 SBT 設計太注重 Vitalik 提出的 “不可轉移” 特性，但是卻忽略 SBT 的潛在管理場景

作者：十四君

封面： Web3Caff

就在 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 的所有者或者获得授权者可以设置 Guardrequire(_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

【十四君-原創回顧】

• 從份賬單說起，為什麼鏈上交易值得分析？
• 解讀 Nostr：抗審查的去中心化社交協議
• 解讀 Dex 中的無常損失: 原理, 機制, 公式推導
• 解讀：OpenSea 的強製版稅執行工具
• 解讀 UniSwap NFT 市場協議不僅僅是聚合器
• 以太坊賬戶抽象萬字研報

免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。