為什麼開發人員不應該害怕脫鏈:Revise 案例


許多人忘記了NFT 只是區塊鏈上記錄所有權軌蹟的智能合約。開箱即用,裡面沒有數據。就像沒有字母的信封一樣,沒有代幣數據的NFT 也沒有價值,只能充當信息的空容器。代幣的價值主要來源於代表NFT 的媒體和屬性,它設置在指向NFT 合約的數據源中。

你可以通過三種方式在NFT 中存儲數據:鏈上、你自己的私有數據庫以及IPFS 等去中心化文件存儲層。在所有三種情況下,令牌URL 都用作指向數據源的指針。當你將NFT 存儲在自己的私有數據庫中時,對令牌的更新將在本地進行並反映在所有NFT 中。

雖然這種方法更便宜,但它伴隨著零治理和爭議解決問題。在IPFS 上存儲NFT 允許你將數據指向NFT 合約,同時保持不變性。然而,缺點是汽油費成本、開發人員開銷以及靜態數據的額外限制,這限制了人們可以構建的創造性應用程序。

與其他兩種方法不同,onchain 並非旨在成為海量存儲層。它能夠只保留最少的數字或字符串數​​據。這可能適用於需要凍結數據集的靜態個人資料圖片項目。

然而,將代幣數據存儲在鏈上的NFT 具有難以鏈接到數據流且無法自動化的局限性。

Revise 是一種用於開發動態NFT 的創新方法,它提供了私有數據庫和去中心化文件存儲(如IPFS)之間的權衡。它使開發人員能夠對存儲在私有數據庫中的NFT 進行編程,以在不犧牲治理的情況下與應用程序和數據進行交互。

當更新發生時,程序員可以使用由Revise Data Structure 啟用的Merkle Proofs 安全地驗證鏈下數據,該團隊計劃開源並選擇他們可以部署在web3 存儲層(如IPFS、Arweave 或Web2 層)上安全標準。

動態NFT項目的開發人員通常更喜歡為其項目使用鏈下存儲,這主要是因為S3 等可擴展存儲層以非常低的成本實現了低延遲和高吞吐量。這種方法使他們能夠更頻繁地更新NFT,並為最終用戶和社區提供更深入的交互性。

使用Revise,開發人員不必處理鏈兼容性問題或語言本地化。

底層數據模型與存儲層和表示層分離。即將開源的修訂數據結構還為所有狀態更改生成證明,使私有鏈下數據層中的條目能夠獨立驗證。

這意味著對社區的良好治理以及鏈下數據在NFT 生命週期中如何演變的完全透明。

關注Revise 的網站、Discord 和Twitter 個人資料,隨時了解所有即將發布的公告。

免責聲明:本文僅供參考。它不是提供或打算用作法律、稅務、投資、財務或其他建議。

資訊來源:由0x資訊編譯自CRYPTODAILY。版權歸作者所有,未經許可,不得轉載

Total
0
Shares
Related Posts