为什么开发人员不应该害怕脱链：Revise 案例

许多人忘记了 NFT 只是区块链上记录所有权轨迹的智能合约。 开箱即用，里面没有数据。 就像没有字母的信封一样，没有代币数据的 NFT 也没有价值，只能充当信息的空容器。 代币的价值主要来源于代表 NFT 的媒体和属性，它设置在指向 NFT 合约的数据源中。 

您可以通过三种方式在 NFT 中存储数据： onchain，在您自己的私有数据库上，以及在 IPFS 等分散式文件存储层上。 在所有三种情况下，令牌 URL 都用作指向数据源的指针。 当您将 NFT 存储在自己的私有数据库中时，令牌的更新将在本地进行并反映在所有 NFT 中。

虽然这种方法更便宜，但它伴随着零治理和争议解决问题。 在 IPFS 上存储 NFT 允许您将数据指向 NFT 合约，同时保持不变性。 然而，缺点是汽油费成本、开发人员开销以及静态数据的额外限制，这限制了人们可以构建的创造性应用程序。 

与其他两种方法不同， onchain 并非设计为海量存储层。 它 能够保持只有最少的数字或字符串数​​据。 这可能适用于需要冻结数据集的静态个人资料图片项目。

然而，将代币数据存储在链上的 NFT 具有难以链接到数据流且无法自动化的局限性。

修改，一个 创新的导轨 用于开发动态 NFT，提供了一个 交易 在私有数据库和去中心化文件存储（如 IPFS）之间。 它使开发人员能够对存储在私有数据库中的 NFT 进行编程，以在不牺牲治理的情况下与应用程序和数据进行交互。

当更新发生时，程序员可以使用由 修改数据结构 团队计划开源并选择它们可以部署在 IPFS 等 web3 存储层上， Arweave 或遵循高安全标准的 Web2 层。 

动态 NFT 项目的开发人员通常更喜欢为其项目使用链下存储，这主要是因为 S3 等可扩展存储层以非常低的成本实现了低延迟和高吞吐量。 这种方法使他们能够更频繁地更新 NFT，并为最终用户和社区提供更深入的交互性。

使用 Revise，开发人员不必处理链兼容性问题或语言本地化。

底层数据模型与存储层和表示层分离。 即将开源的修订数据结构还为所有状态更改生成证明，使私有链下数据层中的条目能够独立验证。

这意味着对社区的良好治理以及链下数据在 NFT 生命周期内如何演变的完全透明。 

关注 Revise 的最新消息，随时了解所有即将发布的公告 官网, Discord及 Twitter 配置文件。 

免责声明：本文仅供参考。 不提供或不打算将其用作法律，税务，投资，财务或其他建议。