vRAM 专家指南

[LiquidApps]

从技术方面深入了解 DAPP 网络去中心化存储解决方案

EOS  —  dApp 的来源地 EOS 区块链的推出旨在为完全去中心化的可扩展的应用程序，并为主流受众提供服务。在推出其主网后的短短几个月内，EOS 在区块链活动方面已超越其竞争对手。DPOS 和 500 毫秒的区块时间赋予了 EOS 超强的处理能力，使其成为支持下一波范式转换 dApp 的最佳定位协议。

RAM 目前没有被正确使用 尽管其性能非常出色，但 EOS 的成本及其网络资源的有限正在限制 dApp 开发人员搭建和扩展其应用程序。特别是，必须将 dApp 智能合约及其状态信息（例如每个用户的余额）永久地存储在 RAM 中的要求阻碍了 dApp 的扩展性。EOS RAM 带有误导性，因为它的功能更像是硬盘驱动器而不是内存设备，其作用是存储与实时操作相关的数据。

EOS 主网以往推出时 RAM 的上限只有 64GB，区块生成者投票表示每年要额外增加 64GB 的 RAM 总量。然而，现在构建的 dApp 需要存储用户配置文件，帐户余额和更新状态信息，这通常可能要求要有几 GB 的 RAM，这使它们与当前的 RAM 模型基本上是不兼容。

vRAM 系统的介绍 vRAM 系统是一个终端到终端的分布式替代存储解决方案，为构建与 RAM 兼容的 EOS dApp 的开发人员服务。它旨在以经济高效的方式存储和检索可能无限量的数据。

vRAM 系统使 EOS RAM 能成为它原本想要做到的效果 — 一个仅用于存储使用中的 dApp 数据的轻量级缓存层。它将永久数据存储功能从 EOS RAM 中去除，让它只用作存储正在使用的数据。

由于现有技术堆栈的系统性限制，vRAM 是第一款利用 DAPP 网络基础设施为以前无法想象的 dApp 赋能的产品。DAPP 网络由配置层和 DAPP 服务层组成，它们共同构成了构建服务的基础，为 dApp 开发人员提供额外的存储容量，安全沟通和其它关键的实用功能。 在这个 DAPP 基础之上的是 IPFS 服务层和独特的 vRAM 库，它让开发人员可以使用多个索引表，是一种为人熟知的为高效数据检索而优化的数据结构。

供应层 DAPP 网络的核心是 DAPP 服务提供商（ DSP ），它为开发人员构建 EOS dApp 提供关键服务。DSP 创建服务包，然后在自由市场中提供给开发人员。 为了获得特定的服务包，dApp 智能合约需要根据 DSP 规定的服务协议投入足够数量的 DAPP 通知。 ‘ dapp 服务’智能合约负责管理持有机制，服务包配置和配额管理。每个服务请求都记录在链上，并减少在 dApp 智能合约可用的剩余操作配额。

DSP 可以提供：

基于链上的服务，以下章节有详细阐述。

基于链下的服务，即可从客户端应用程序访问如服务历史实用功能，在该文章中叙述。

在链下服务的情况下，DSP 使用配置层来报告使用情况和管理配额。

DAPP 服务层 对于需要与 dApp 智能合约交互的 DSP 服务（在本白皮书中称为用户合约），DAPP 服务层包含用户合约可以从 DSP 请求特定服务的协议。服务请求是对 DSP 的“类似功能”调用，因为它具有特定参数，并且可以触发返回到合约的响应得到特定结果。

这里会有两种服务请求：同步和异步。

同步请求（阻止）：同步请求会阻止用户合约执行交易并在点对点网络上传播它，直到请求接收到合约的回应。

在 vRAM 系统中，DSP 节点首先接收交易并在本地运行它。这会导致抛出异常，因为交易引用的 RAM 表中的必需数据不可用。

该异常是向 DSP 发信号通知该交易尚未就绪的方式，从而请求它提供服务（例如，返回本地 IPFS 集群文件，处理网页 oracle 请求或生成随机数）。一旦 DSP 将必要的数据加载到 RAM 中，就可以将交易中继到区块生成节点。

如果用户将需要请求服务的交易直接发送到非 DSP API 节点，那么它会交易失败，因为只有唯一的 DSP 节点能够作为服务请求将异常解析。

异步请求：合约调度请求服务的事件，并继续执行交易从而让它不会交易失败。

异步请求在 vRAM 系统的 DAPP 服务层中的运行方式如下：DSP 通过监听链上事件流并执行这些请求来检测合约是否已请求服务（例如，IPFS 服务清理和提交，日志事件 ，安排交易请求）。

由于异步请求不依赖于接收请求响应，因此不需要将它们直接发送到 DSP API 节点。相反，该请求可以从任何 EOSIO 节点发送，并且将由正在监听区块链上的事件的 DSP 节点解析。

IPFS 服务层 本地 IPFS 群集是一种分布式数据存储解决方案，它使用基于内容的寻址来访问文件。与传统的客户端-服务器模型不同（每个文件位于具有特定 IP 地址的服务器上并由请求该地址的客户端检索），本地 IPFS 群集文件被赋予唯一资源标识符（ URI ） 到指定的文件。DAPP 网络支持三种不同的服务请求，这些请求利用本地 IPFS 集群的强大功能将文件存储在去中心化的点对点网络中，并安全有效地检索它们。

在其 IPFS 服务层中，vRAM 系统使用三种服务请求：预热请求，清理请求和提交请求。

预热请求：用户合约使用其 URI 发送服务请求以从本地 IPFS 集群检索文件。解析服务请求后，DSP 将包含该文件的有效负载返回给合约。 由于 URI 也是文件的哈希，因此合约可以通过哈希数据并将其与标识符进行比较来轻松验证文件的完整性。预热请求是同步的，并阻止合约的执行，直到响应返回到合约。

清理请求：清理请求向 DSP 发送请求以从缓存中清理文件。这是一个异步请求。

提交请求：提交请求指示 DSP 将新数据写入其本地 IPFS 群集节点。在调度由 DSP 节点捕获的提交请求之前，开发人员可以利用其智能合约中的 setData 函数首先有新数据哈希以返回 URI。以类似的方式，可以使用 getData 函数来获取智能合约的数据，或者在缺少的情况下请求预热。

vRAM 层 vRAM 层为智能合约中的开发人员提供了一个熟悉的界面 — 多索引表。vRAM 使得从本地 IPFS 集群检索信息的效率显著提高，并以 dApp 开发人员熟悉的方式对其进行操作。DSP 不会暴露在 vRAM 层 — — 它仅存在于用户合约中（使用 vRAM 库） — — 让系统升级和优化而无需改变 DSP 软件。vRAM 使用 Merkle 树来表示整个数据库。Merkle 树中的每个节点都表示为本地 IPFS 集群上的文件，仅在需要证明时才按需请求。 为了定位特定文件，需要遍历树，直到它们到达表示所需数据的叶节点。 只有代表整个数据库的当前根节点需要在 RAM 中保留。

基于 Merkle 树的结构在 vRAM 层中起双重作用，既作为能够实现更快的数据库查询的索引，又作为可以验证数据有效性的完整性证明。

vRAM 底下的运作 为了说明 vRAM 如何使开发人员能够创建新一代 dApp，我们将引用类似超级马里奥的游戏。我们称之为 Super DAPP （🍄）。Super DAPP 智能合约有两个动作：“开始游戏”，它在新游戏开始之前加载玩家的进度和当前得分，以及“修改得分”，一旦游戏结束，它就会更新玩家的得分。

我们示例中的交易顺序分为 5 个步骤：

发出信号

热身

加载并进行交易

修改

清除缓存

发出信号 （ 1 ）使用 vRAM 的 dApp 智能合约（在我们的白皮书中称为“用户合约”）通过 DSP 节点的 EOSIO API 从客户端接收交易。

（ 2 ）由于在 RAM 上找不到执行交易所需的数据，而是存储在 vRAM 上，因此 dApp 智能合约继续运行引发异常的交易。这个故障是向 DSP 发信号通知需要其服务的手段。

（ 3 ） DSP 解析服务请求，检测 RAM 中未找到的但存储在 vRAM 中的所有必要数据。

客户端的应用程序（ eosjs 实例）通过 DSP API 节点发送交易。当 DSP 在本地运行时，交易失败。此异常是一种发出服务请求信号的方法。

🍄在我们的插图中，Alice 准备开始新一轮的“ Super DAPP ”，向 Super DAPP 合约发送“开始游戏”交易。但是，当交易由 DSP 节点在本地运行时，RAM 中缺少她的最后一个检查点和当前分数。 由于这些数据点是加载新游戏会话所必需的，因此该交易会引发处理失败。运行交易的 DSP 接收信号并解析服务请求。

热身 （ 1 ） DSP 验证 dApp 智能合约是否有足够数量的 DAPP 用于特定服务包以及足够数量的可用配额。

（ 2 ） DSP 节点中继的本地 IPFS 集群文件显示丢失数据点。 由于仅表示整个数据集的当前状态的 Merkle 根永久地存在于 RAM 中，因此通过回溯表示数据集的 Merkle 树来验证数据的完整性，直到到达表示数据的叶节点。

（ 3 ）使用加密证明，dApp 智能合约验证所请求的数据是否未被篡改。然后这就结束了“预热请求”阶段。

DSP 从本地 IPFS 集群中获取所请求的文件，并从 EOS RAM 中检索数据集完整性的加密证明。然后，它将文件和证据中继到 dApp 智能合约，即所谓的“预热请求”。

🍄回到我们的插图，一旦 DSP 解析了服务请求，它就会继续从本地 IPFS 集群中获取 Alice 的数据。 它将她的最后一个检查点和当前得分以及加密证明转发给 Super DAPP 合约，该证明让合约验证数据的完整性。

加载和交易 （ 1 ） dApp 智能合约将必要的数据加载到驻留在 RAM 中的临时缓存表中。

（ 2 ）交易现在可以在传播到区块链上的区块生成节点之前成功处理，因为现在在 RAM 上找到了所有必需的数据。

（ 3 ）如果由于任何其他原因导致交易失败，则执行清理过程以清除未使用的缓存。

在验证数据的有效性后，DSP 将其加载到 EOS RAM 中并将交易发送到区块链。这次交易会成功处理，因为所有必要的数据都可以在 RAM 中使用。

🍄在我们的图示中，在验证了数据后，DSP 通过向 BP 的 P2P 端点发送交易，将 Alice 的分数和检查点加载到 RAM 上的临时缓存表中。现在 RAM 中可以获得所有必需的数据，交易可以发送到区块生成者节点。

修改 （ 1 ）每当智能合约修改基于 vRAM 的多索引表中的数据时，它就会发送一个提交事件，其中包含已修改的数据和受更改影响的 merkle 树节点。数据点和 merkle 树节点表示为本地 IPFS 集群文件。

还在继续阅读吗？ 很棒，因为接下来就是最酷的部分了！🍩

（ 2 ）由于本地 IPFS 集群 URI 和数据的哈希是相同的（ Merkle 树的双重角色，还记得吗？），在 DSP 实际提交数据到本地 IPFS 集群之前合约就已经知道了预期的 URI。通过相同的逻辑，两个不同的 DSP 独立地缓存相同的数据或重放历史记录将数据固定到同一本地 IPFS 集群 URI 下的本地 IPFS 集群。

（ 3 ）合约将新数据和新 Merkle 树节点保存在 RAM 缓存表中。

（ 4 ）合约将新的 Merkle 根永久保存在 RAM 中。

（ 5 ）与区块链上的任何事件一样，带有数据的提交事件成为链历史的一部分。这确保了任何 DSP 都可以通过重放历史来恢复数据。

（ 6 ） DSP 通过使用 demux 服务收听来自链的事件流从而捕抓事件。检测到事件时，DSP 会对本地 IPFS 集群中的文件进行高速缓存和索引，以便快速检索。

（ 7 ） DSP 向合同发送确认回复。

在此过程结束时，在 EOS RAM 上修改 Merkle 根，并将新数据点缓存在 DSP 的分布式文件存储系统上。

dApp 智能合约通过内联操作修改 EOS RAM 上的数据。DSP 监听修改事件并在其本地 IPFS 集群节点上写入新文件。

🍄继续我们的类比，爱丽丝完成一个层级并保存她的进度。她现在已经取得了得分和她的检查点进度方面的进展。Super DAPP 合约使用新数据发送事件，该数据修改 EOS RAM 中的数据。同时，DSP 监听事件并修改本地 IPFS 集群上的数据，以根据 RAM 上的数据反映 Alice 的最新得分和检查点。

清除缓存 （ 1 ）交易结束后，DSP 向 dApp 智能合约发送清理事件，以从 RAM 中清除数据。

（ 2 ） DSP 向 dApp 智能合约发送清理操作，然后从 RAM 中删除数据。

（ 3 ） dApp 智能合约将加密签名（ merkle root ）留在 RAM 中。 在验证下一个预热请求的完整性时会需要用到。

数据从 EOS RAM 中删除，留下了操作时的加密证明（ Merkle root ）。

🍄游戏结束后，Super DAPP 合约将删除 RAM 中的数据，留下验证下一个预热请求所需的加密证明。

终端到终端的去中心化存储

每当数据被修改时，都会更新存储在 RAM 中的数据集的 Merkle 根。当合约中需要该数据时，DSP 节点将 Merkle 证据与所需数据点一起中继到 dApp 智能合约。

表示整个数据库的单个 Merkle 根允许 dApp 智能合约在称为“预热请求”的过程中验证与当前操作相关的数据集的任何特定部分的有效性。通过这种方式，智能合约可以使用数 TB 的数据“预热”来自大型数据库的单个条目，而无需下载整个数据集或引入任何其他信任要求。此外，每当智能合约使用 vRAM 提交或修改数据时，数据就会成为链历史的一部分，并且如果由于不可预见的情况导致数据不可用，则可以通过重播所述历史来重新创建数据。

DAPP 通往未来

vRAM 是 DAPP 网络实现的第一个成果，它利用 DSP，开发人员和 DAPP 通证的强大功能来解锁 dApp 可扩展性。

随着 DAPP 网络的采用不断增长，我们期望 DAPP 开发者社区通过为 vRAM 系统设计新的使用案例来扩展 DAPP 服务的功能。

LiquidApps 邀请 dApp 开发者们加入专门的开发者电报渠道，提供反馈并对正在进行的讨论发挥积极作用。如需深入了解 vRAM 系统技术方面的内容，请查看我们的 GitHub 代码库。

加入我们的中文电报群，电报搜索 @LiquidApps_community_China，可以随时与我们交流。