可以長久保存并防止篡改,這是NFT核心價值之一,不幸的是,目前許多面向消費者的NFT由于設計上的根本性漏洞,并沒有這些屬性,常常看到一些NFT號稱“在區塊鏈上永存”,但實際上經常因為成本和區塊鏈存盤能力的限制,存盤的只有所有權記錄和關聯NFT的元資料,
很多時候,這些鏈接是脆弱的,用HTTP協議將用戶引向特定位置,而非該資產本身,這意味著鏈接指向的內容可能在以后失效或者改變,造成原資產的丟失(只剩所有權記錄是無價值的),
IPFS可以解決這個問題,使用IPFS的NFT將享有優勢,但只有遵從既有規范才能較好讓資料得以永久保存并可訪問,隨著NFT的迅速流行,現在是一個好時機,讓我們重溫下在IPFS上存盤和鏈接NFT資料的最佳實踐,在本文中,我們將探討兩個近期熱度話題:內容尋址和資料完整性,

內容尋址
IPFS內容識別符號(CID)在精準標識內容方面是極其強大和靈活的,無論該內容存于何處,以何種方式存盤,為了最大限度地利用這些優點,開發者在鏈接IPFS資料時應遵循以下建議和慣例,
鏈接概述
本文并非對CID的全面解釋(對此,已有極佳的資料https://docs.ipfs.io/how-to/address-ipfs-on-web/#dweb-addressing-in-brief),但本文旨在讓讀者了解以下幾點:
CID
CID是自描述的,是對任意內容唯一對應的標識,
例子:
bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
CID應該用在您的應用代碼中,以及其他明確是在使用IPFS的場景下,
我們建議在磁盤上將CID轉為IPFS URI存盤,特別是在元資料或者區塊鏈記錄這種寫入后不再更改的記錄中,給CID加上ipfs://的URI格式,增加了背景關系資訊,讓用戶和自動化的工具更容易找到所鏈接的內容,
IPFS URI
統一資源識別符號URI用于在協議中指定某特定內容,協議是由URI格式決定的(作為前綴附加到URI上,還加上://),IPFS的URI格式是ipfs,有時URI可以在最后附加路徑,
例子:
ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
ipfs://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
IPFS URI是指向檔案或者目錄的標準IPFS鏈接,當從智能合約鏈接到IPFS資料時,IPFS URI表明該資料應該通過IPFS系統獲取,
當在NFT的結構化元資料中對IPFS上的影像及其他媒體資源做鏈接時,也應該使用IPFS URI,
HTTP Gateway URL
HTTP gateway幫助無法原生決議IPFS URI的舊版瀏覽器進行兼容,這種鏈接只應在應用程式的界面中使用,而不應該存入區塊鏈或NFT的元資料中,
例子:
https://dweb.link/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
需注意到,HTTP gateway又將內容分發中心化,是中間人攻擊的可能載體并帶來潛在的單點失效—— 如果gateway運營方下線或者失聯,鏈接將失效,而內置IPFS支持的瀏覽器(通過IPFS Companion瀏覽器擴展,或原生支持,如Brave)可以避免這些問題,因為它們可以自動從此類鏈接中提取CID,并根據用戶設定從IPFS加載資料,
不同場景中的尋址
在不同場景下,開發者應根據具體情況使用合適的鏈接設定方式,
鏈上
NFT智能合約上對一個NFT對應的資源和元資料應該使用IPFS URI,
例子:
ipfs://bafybeibnsoufr2renqzsh347nrx54wcubt5lgkeivez63xvivplfwhtpym/metadata.json
我們建議在生成NFT之前先生成IPFS URI,并將URI完整存于鏈上,對傳入一個URI的智能合約介面,這種方式最簡單,而且 ipfs:// 的URI格式讓應用知曉此資料位于IPFS上,
元資料
在NFT的元資料中,應使用IPFS URI,這是在文本中鏈接IPFS資源最明確,且長期可靠的方式,
下面是一個鏈向NFT媒體資產的IPFS URI的例子:
ipfs://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
開發者可以用公共HTTP gateway來獲得兼容性,同時應該避免其他鏈接到內容的方式(如非IPFS HTTP gateway的URL),普通的HTTP鏈接至多只能作為內容的臨時鏡像,因為鏈接的內容很容易被改變,在區塊鏈上,資料是永久存盤而無法篡改的,所以在鏈上使用HTTP是脆弱的,有失效風險,
相比之下,IPFS URI是永久有效的,可被安全地作為資料的規范鏈接,通過使用IPFS URI作為“真理之源”鏈接,應用程式更容易使用多種不同的存盤方案,或在未來切換不同的gateway,只要生成新的gateway鏈接,這比起將特定gateway鏈接“硬編碼”到區塊鏈的永久記錄中更靈活,
應用
在面向用戶的應用程式中,開發者應通過以下兩種方式鏈接IPFS內容,
-
IPFS URI
-
HTTP gateway URL
直到更多的瀏覽器原生支持IPFS URI,請注意,這兩種鏈接都是容易從原始CID或IPFS URI生成的,
下面是一個HTTP gateway URL指向公共的dweb.link:
https://dweb.link/ipfs/bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
也可以使用CID作為子域名,而不是放在URL路徑里:
https://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta.ipfs.dweb.link/nft.mp4
這兩個例子都對應這個標準IPFS URI:
ipfs://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
資料完整性
關于NFT資產的一個重要的點在于其完整性 —— 包括資產本身和所有相關資料,IPFS使用CID來保護NFT資料的完整性,確保自鏈接創建以來沒有篡改,開發者應遵守以下建議,讓IPFS內置的資料驗證功能發揮最大效用,
鏈接資產元資料
元資料是NFT價值構成的有機部分,因此,為保全資產的價值,在IPFS上存盤資產時也應存盤元資料,并確保兩者都可獲取,
實作該目標的首選方法如下:
-
創建兩個新目錄(一個用于資產,一個用于元資料);
-
將資產添加到其目錄中;
-
將資產的目錄添加到IPFS中,記錄其CID;
-
在相應目錄創建元資料,使用步驟3中的CID創建IPFS URI,該URI應該包含目錄的CID和資產檔案名;
-
將元資料的目錄添加到IPFS中,記錄其CID;
-
使用步驟5中的CID為元資料創建IPFS URI,將該URI存盤在鏈上,加入所有權,
記錄
該流程既能讓開發者將檔案名加入鏈接中(方便用戶互動),又確保元資料和資產可被獨立應用,
元資料將在以下位置被訪問:ipfs://{元資料目錄的CID}/元資料檔案名
資產可以通過以下地址訪問:ipfs://{資產目錄的CID}/資產檔案名
下面是JSON元資料例子,包含鏈接到影像檔案的IPFS URI:
該圖片可使用IPFS URI:
ipfs://bafybeidfjqmasnpu6z7gvn7l6wthdcyzxh5uystkky3xvutddbapchbopi/no-time-to-explain.jpeg訪問,
在界面上,您的應用可以創建一個gateway URL 方便用戶使用HTTP獲取該圖片,例如:
https://dweb.link/ipfs/bafybeidfjqmasnpu6z7gvn7l6wthdcyzxh5uystkky3xvutddbapchbopi/no-time-to-explain.jpeg
一旦元資料創建完成,作為JSON檔案在IPFS上存盤后,其CID可用來創建如ipfs://bafybeibnsoufr2renqzsh347nrx54wcubt5lgkeivez63xvivplfwhtpym/metadata.json的URI,該URI可存入智能合約中,
整個程序的實戰案例,可在IPFS檔案網站上如何在IPFS上發行NFT(https://docs.ipfs.io/how-to/mint-nfts-with-ipfs/#a-short-introduction-to-nfts)查看,檔案使用javascript詳細演示了整個程序,
高可用
使用如IPFS這樣的去中心化網路來提供內容的主要原因之一是為了防范鏈接失效,這是通過讓網路中別的節點共同運營資料鏡像服務來實作的,但對資料可用性有高要求的開發者不應該依賴于別的節點的利他性,
為了確保鏈接的內容可用,開發者應該pinning內容的CID在自己的存盤節點上,并與愿意幫忙的節點一起存盤分發該內容,如果愿意的話,開發者也可以使用pinning服務(https://docs.ipfs.io/how-to/work-with-pinning-services/)來代為運營,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qukuanlian/297360.html
標籤:區塊鏈
上一篇:DAPP開發中Web3喚醒MetaMask簽名資料+Java校驗簽名實作去中心化和中心化用戶資料的鑒權
下一篇:BTC/ETH 9.3 策略分享
