玩转vRAM之实践篇：vRAM如何为开发者赋能？

来源 | LiquidApps

翻译 | Starteos

在上一篇《 玩转vRAM之介绍篇：好好学习，坐等牛市！ 》文章里面，我们为大家介绍了有关vRAM的一些概念，为了帮助EOS开发者更好地理解vRAM系统和DApp网络，接下来，我们将一起通过一个超级马里奥风格的游戏，解释vRAM如何为开发者赋能，帮助他们创建新一代的DApp，我们将这个游戏称之为 Super DApp(?)。

Super DApp智能合约包含两个指令:

• “开始游戏” 在新游戏回合开始之前，加载玩家进度和当前得分；

• “修改分数”的指令用来在游戏回合结束之后，修改玩家的分数。

在我们的例子中，一笔事务分为如下 5 步完成:

• 发起信号

• 预热

• 加载数据，执行事务

• 修改数据

• 清除缓存

发起信号

1. 使用vRAM的一个DApp智能合约，在白皮书中我们称之为 “用户合约”，会通过DSP节点的EOSIO API接收来自客户端的事务。

2. 由于执行事务所需要的数据并未存储在 RAM 而是在 vRAM 中，因此DApp智能合约继续运行事务会触发异常。 这一报错会向DSP发送信号，使得DSP知晓需要提供服务。

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

( 客户端 App (eosjs) 通过 DSP 的 API 节点发送事务请求. DSP 本地执行事务失败。 异常信息用于服务请求的信号)

?在我们的例子中，玩家 Alice 准备开始“Super DApp” 游戏的新回合，将“开始游戏”的事务发送给Super DApp智能合约。

但是，在DSP节点中本地执行该指令时，却发现Alice的进度和当前的分数在RAM中不存在。 由于加载新的游戏回合需要用到这些数据，该事务会抛出断言错误(Assertion Failure)。 运行该事务的DSP会捕获该信号，并解析服务请求。

预热

1. DSP检测确认，该智能合约为使用对应的服务包抵押了足额的DApp代币，并且仍有足够的剩余使用额度。

2. DSP节点会转发至本地的IPFS集群，查找表示所缺失数据的文件。 由于只有Merkle根(表示整个数据集的当前状态)永久驻留在RAM中，所以通过跟踪表示数据集的Merkle树，直到到达表示数据的叶子节点，才能验证数据的完整性。

3. 使用加密证明，DApp智能合约可以验证所请求的数据没有被篡改。 “预热请求”阶段结束。

(DSP会从本地IPFS集群中查找所请求的文件，并从EOS RAM中获取用于数据完整性证明的加密证明。 然后，会将文件及证明发送至DApp智能合约，这一过程称之为 预热请求。 )

? 在我们的例子中，DSP解析了服务请求后，会继续从本地IPFS集群中获取Alice的数据。 将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与数据的hash值相同(还记得Merkle树的双重作用吗? )，所以，在DSP将数据实际提交到本地IPFS集群之前，智能合约就知道了预期的URI。 根据相同的逻辑，两个独立缓存相同数据或重放历史的不同DSP会把数据pin在本地IPFS集群下，有着相同的本地IPFS集群URI。

3. 合约会将新的数据和新的Merkles树节点，存储在RAM缓存表中。

4. 合约会将新的Merkle树根的值永久存储在RAM中。

5. 与区块链上的任何事件一样，带有数据的提交事件将成为区块链历史数据的一部分。 这确保了任何DSP都通过回放历史的方式来恢复数据。

6. DSP通过使用demux服务侦听来自链上的事件流来捕获事件。 当检测到事件时，DSP将文件缓存并索引到本地IPFS集群中，以便快速检索。

7. DSP将提交请求发送至合约。

最后，在EOS RAM上的Merkle根节点会修改，新的数据点会缓存至DSP的分布式文件存储系统中。

(DApp智能合约会通过内联操作(Inline Action) 的方式修改EOS RAM 中的数据。DSP会监听修改事件，将新的文件存储在本地IPFS集群节点中)

? 继续我们的比喻，Alice完成了一关后，保存游戏进度。 现在，她分数更高，进度也更快了。 Super DAPP合约会提交一个包含新数据的事件，修改存在EOS RAM中的数据。 同时，DSP会侦听到事件，并修改本地IPFS集群上的数据，用RAM中的数据来表示Alice最新的分数和进度。

清理缓存

1. 事务执行结束后，DSP会向DApp智能合约发起清理事件，将数据从RAM中移除。

2. DSP向DApp智能合约发起清理指令，合约会将数据从RAM中删除。

3. DApp合约会将加密证据(Merkle 根数据)留在RAM中。 在下一次预热请求验证数据完整性时需要使用。

（数据从EOS RAM中删除，但保留了加密证据(Merkle 根节点)在RAM中）

? 游戏结束后，Super DApp合约会将数据从RAM中删除，将加密证据留在RAM中，供下一此数据预热请求时验证数据使用。

端对端去中心化存储

任何时候数据修改之后，存储在RAM中的数据集的Merkle 根会进行更新。 在合约中需要使用数据时，Merkle证明连同所需要的数据点会由DSP节点发送至DApp合约。

一个代表整个数据库的单一Merkle根，可以让DApp智能合约验证数据集内与当前操作相关的任何特定部分数据的有效性，这个过程称为“预热请求”。 通过这种方式，智能合约可以对有着数TB数据的大型数据库中的单个条目进行“预热”，而不需要下载整个数据集或引入任何额外的信任要求。

此外，当智能合约使用vRAM提交或修改数据时，数据将成为链历史的一部分，如果由于不可预见的情况导致数据不可用，则可以通过对链上历史进行重放(Replay)来重新创建数据。

DApp的未来

vRAM只是DApp Network的首个实现，展示了DSP的能力， DApp Network借助于了DSP、开发人员和 DApp代币的力量，释放DApp可扩展性的潜力，vRAM只是DApp网络所实现的首款产品。

随着DApp Network得到更多人的采纳，我们期待DApp开发者社区为vRAM系统创造出崭新的使用场景，扩展 DApp服务的功能