【DAY23】 - Blind Box and Verify

14th鐵人賽盲盒驗證簽章

foodchain

2022-10-08 00:03:01

507 瀏覽

分享至

Preface

今天想要介紹的一個 NFT 常用玩法 -- 「盲盒 Blind Box」。

雖然這次寫的 ticket verifiction system 並不會包含盲盒的內容，但在許多 NFT 項目中有很多都採用了盲盒這種玩法，因此了解這些的過程也會對 NFT 有更深入的了解。

除此之外，我剛好看到啟元大大做出 ERC-721F 的概念盲盒，想透過類似簽章的方式做出公平驗證的功能。同時我的系統中也需要一些類似的概念來做驗證，因此我便寫了這篇來了解並分析一下關於這篇文中 NFT 的驗證概念。

ERC-721F 中 F 是來自 Fair，代表一個公平的驗證系統。

What is Blind Box

其實盲盒與我們之前提到的「Dynamic NFT」的概念非常類似，都是透過改動 token 的 metadata 來達到改變圖片的效果。

解盲 - consumer 視角

從消費者的角度來看，在購買之前，看到的 NFT 會是一個相同的狀態，例如遊戲王卡的背面，而在購買之後（購買會產生一個解盲的動作）它的內容與圖案才會真正的顯現出來。

解盲 - developer 視角

從 developer 的角度來看，解盲的過程是這樣的。

我之前的文章中有提到，要改變一個 NFT 的 metadata 可以透過 setTokenUri() 的方式來改變。

解盲的問題

一般解盲過程可能會產生一些問題：

解盲過程中項目方黑箱：可能存在項目方先預留一些地址（類似白單），當這些地址 mint 時可能使 metadata 指向較稀有的 NFT。
在尚未解盲前便透漏了結果：項目方在開發時可能會透過 baseUri 設定解盲的 CID 地址，或因為程式碼開源而洩漏 CID。這樣的洩漏都可以讓有心人偷偷的先去查詢這些 CID 而間接找到較特殊的 NFT。

解決方法

為了確保其 NFT 的公平性與完整性，作者透過雙方相互交換資訊的方式來解決上述的問題。

Flow

可以把驗證的過程想成兩個在玩 21 點的人，兩人各有一個底牌（seed），這張底牌在揭露前不會被對方看見的，雙方只能看到對方底牌背面（seedHash），但不能以此決定比賽結果。而使用者的底牌的背面稱為 clientSeedHash，項目方則是 serverSeedHash。

只有當雙方都揭露了自己的底牌時，才可以得到最終結果（clientSeed & serverSeed）。

整個步驟可以分成四個:

Client 傳送自己的 seedHash 給 Server（Smart Contract）
Server 會回傳一個 signature 給 Client。
Client 再回傳自己的 clientSeed、seedHash、serverHash、signature 給 server
此時 Server 便可以使用自己的 serverSeed 來計算出解盲結果。

真實情況

在真實的情況（因為作者並沒有分享程式碼，有多處為我自己猜測），前端會讓使用者輸入一段密碼（ex: "我是大帥哥"），這段密碼會被 hash 後送到智能合約儲存。

這時 Server 無法從 hash 後的 ClientSeed 推算出原本的密碼。

隨後 Server 可以透過 _mintNonce(ClientSeedHash) 找出 mint address 之 nonce（應該就是找出此 address 第幾次 mint），並使用簽章私鑰計算出 serverSeed 與 serverSeedHash，將 seedHash 回傳給 Client（同時也會透過合約檢查資料是否完整，最後將 clientSeed、clientSeedHash、serverSeedHash 存入 _mintData 中）。

最後項目方可以在 unblind() 輸入 serverSeed 與特定的 tokenId 來完成解盲的動作。