今天想要介紹的一個 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 後的結果。
雖然今天的內容多參考了這篇文章,但是也讓我了解了一個完整的簽章、驗證流程應該是如何使用的,也讓我在現在的專案有了更多驗證的想法,在未來幾天便可以看到了!