从技术方面深入了解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代码库。