今天想要介紹的一個 NFT 常用玩法 -- 「盲盒 Blind Box」。
雖然這次寫的 ticket verifiction system 並不會包含盲盒的內容，但在許多 NFT 項目中有很多都採用了盲盒這種玩法，因此了解這些的過程也會對 NFT 有更深入的了解。
除此之外，我剛好看到啟元大大做出 ERC-721F 的概念盲盒，想透過類似簽章的方式做出公平驗證的功能。同時我的系統中也需要一些類似的概念來做驗證，因此我便寫了這篇來了解並分析一下關於這篇文中 NFT 的驗證概念。
ERC-721F 中 F 是來自 Fair，代表一個公平的驗證系統。
其實盲盒與我們之前提到的「Dynamic NFT」的概念非常類似，都是透過改動 token 的 metadata 來達到改變圖片的效果。
從消費者的角度來看，在購買之前，看到的 NFT 會是一個相同的狀態，例如遊戲王卡的背面，而在購買之後（購買會產生一個解盲的動作）它的內容與圖案才會真正的顯現出來。
從 developer 的角度來看，解盲的過程是這樣的。
我之前的文章中有提到，要改變一個 NFT 的 metadata 可以透過 setTokenUri() 的方式來改變。
一般解盲過程可能會產生一些問題：
baseUri 設定解盲的 CID 地址，或因為程式碼開源而洩漏 CID。這樣的洩漏都可以讓有心人偷偷的先去查詢這些 CID 而間接找到較特殊的 NFT。為了確保其 NFT 的公平性與完整性，作者透過雙方相互交換資訊的方式來解決上述的問題。
可以把驗證的過程想成兩個在玩 21 點的人，兩人各有一個底牌（seed），這張底牌在揭露前不會被對方看見的，雙方只能看到對方底牌背面（seedHash），但不能以此決定比賽結果。而使用者的底牌的背面稱為 clientSeedHash，項目方則是 serverSeedHash。
只有當雙方都揭露了自己的底牌時，才可以得到最終結果（clientSeed & 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 來完成解盲的動作。
在原文中有提到，他們的系統會透過預言機來獲得 serverSeed 與其 Hash 值，這邊我不太確定作者真正做法為何，因此只能做猜測。
我推測每一個 tokenId 在收到 clientSeedHash 時都會產生一組 serverSeed，而這個 ServerSeed 應該是及時利用 Oracle 產生的隨機數字/ 文字進行 hash 後的結果。
雖然今天的內容多參考了這篇文章，但是也讓我了解了一個完整的簽章、驗證流程應該是如何使用的，也讓我在現在的專案有了更多驗證的想法，在未來幾天便可以看到了！
iThome鐵人賽
看影片追技術