【硬核分析】EOS dApp及其RAM成本

Karma的RAM开销的案例研究，以及Karma可以如何降低高达99%的RAM需求

在一系列案例研究中，LiquidApps 团队会分析相应项目的 RAM 消耗情形，并给出使用 vRAM 系统的替代模型。vRAM 系统是去中心化的补充性存储方案，为使用 DAPP Network 的 EOS dApp 提供解决方案。

首个分析的项目为 Karma。Karma 是一款社交应用，目前大约每周需要消耗 1.4 MB 的RAM存储空间，用于存储帖子和元数据。使用 vRAM 的替代性方案，可以让 Karma无需在 RAM 上永久存储数据，根据最保守的估计，预计可以节省 98.7% 的 RAM 开销。

本文中所有的数据均可以通过 EOSPark API 公开获得。在分析报告中，会用 ✍️ 符号对假设的详细信息进行明确标示。文中后半部分也会提供敏感度报告，列出来在假设条件变更时，相应的 RAM 消耗情况的变化。

了解 Karma

Karma 是一个社交媒体 dApp 应用，通过通证奖励机制，促进用户分享善举，产生社交影响力。该应用包含了传统的社交媒体网站的元素，比如用户信息部分，上传帖子功能，以及 Karma 钱包。用户可以张贴图片或视频，分享彼此的内容，也可以在应用内进行 Karma 代币转账。另外，用户可以为其他用户的帖子点赞支持。随着用户在应用中活跃参与而产生 KARMA 代币，可以通过内置的抵押机制提高奖励。用户可以申领所产生的代币。

Karma 幕后机制

在 Karma 程序中，包含两个控制工作流的智能合约 —therealkarma 和 thekarmadapp，两个合约有各自的用途。

therealkarma 智能合约

therealkarma 该合约中存放着相当数量的 Karma 代币。借助 claim（申领）和Transfer（转账）两个操作，该合约负责代币发行，并存储所有账号的代币余额信息。该合约可用的 RAM 大小为 38 MB，大约是在主网上 dApp 上线启动时进行空投所需的 RAM 数量。

🌟一个有趣的事实：由于初始的主网快照包含 163,930 账号，单个账号空投时所需要的 RAM 数量大约为 0.229kb。假设如今每个账号仍需相同数量的 RAM，一个 dApp 现在若为主网全部的857,000 个账号空投，则需要大约 200 MB的 RAM。

thekarmadapp 智能合约

Karma 的应用逻辑位于 thekarmadapp 合约中，处理更广泛的事务类型。最常用的操作包含“Upvote”/”Downvote”（赞或踩）,“Claim”（申领代币）和 “Createpost”(创建帖子)。这些事务操作会消耗或释放 RAM。Karma 会在帖子发布两周后将其从 RAM 中删除，以便释放这些帖子所占用的 RAM 及其元数据。

*Upvote/Downvote（赞/踩）— 赞或踩的操作，每笔事务会消耗8字节的 RAM。

*Createpost(创建帖子)— 每次用户创建新的帖子，thekarmadapp 合约会消耗 263 字节的 RAM。

*Claim(申领)— 每次用户申领所获得的代币奖励后，系统的 RAM 会释放。该数字是变量，可通过如下公式计算：

释放的 RAM 数量 = 8 字节 * (该日的赞数) * (未申领的天数)

✍️ 为了本分析的目的，我们假设对于每次申领操作，所涉及的帖子得到了 1 个赞，未申领时长为1天，用户申领后，会将 8 字节的 RAM 存储量释放给系统。

替代方案

使用 vRAM 系统可以大幅降低 RAM 成本，可以将数据存储在区块链历史中，并通过 DSP 进行索引。帖子数据会在区块链历史中存储，而非在 RAM 之中，只需要在用户需要访问帖子时才将其加载到临时的 RAM 数据表中。只需要在事务的生命周期持续期间使用 RAM，之后可以将数据从 RAM 中移除。智能合约成功执行一笔 vRAM 事务所需要的时间，取决于 DSP 所提供的服务包的服务级别协议(Service Level Agreement)的设定。

另外，使用 vRAM， Karma 可以将帖子在链上存储时长扩展至远超过两周的时间，可以为发帖的用户积累更多的投票和奖励。

事务的生命周期：定义和假设

一笔事务的生命周期，是指事务中所有的操作指令从预热到完成(eviction)的这一过程。包含了将数据加载到 RAM 之中，以及所需要进行的数据修改等部分。

✍️ 出于本分析的目的, 我们假设一笔事务的生命周期耗时 10s。根据经验，即时事务的生命周期耗时往往从1秒到10秒不等。然而，我们对更长的时间周期进行分析，以评估在最坏的假设下所节省的成本。这个变量也将作为稍后的敏感性分析的一部分。

数据

我们的分析中包括一个星期的事务数据，从6月5日15:00开始，到6月10日上午结束(“整个分析期”)。所获取的 92,501 笔事务可以细分为多个类别，如下图所示:

在 Other 这一分类下，包含了不消耗 RAM 的各类事务，比如创建评论的操作。

我们 2 个月前运行脚本时，选定的期限为从4月8日中午开始到4月14日结束，得到了 73,602 个事务。

然后，我们将4月份的数据乘以5/7，将相应的数据插值计算，获得 5 天的数据以便进行对比。4–6月的交易增长情况可以细分如下:

尽管使用量显著增加，但注意 claim (申领)操作数量的减少这一现象是很有趣的。这表明，用户为了增加奖励数额，会在更长的时间内不去对帖子进行申领奖励的操作。

分析当前情形 — 不使用 vRAM

Karma 使用通证奖励机制，激励用户发帖分享他们的善举。奖励由每个帖子获得的支持/反对票(Upvote/Downvote)数决定。因此，一旦帖子创建，它就必须与任何后续的赞成票和反对票一起存储在 RAM 中。

可根据如下公式计算 RAM 的消耗量：

Createpost(创建帖子): (帖子总量) * 263 bytes

Upvote/Downvote(赞/踩): (Total UD) * 8 bytes

Claim(申领): -(⅀ 所有的申领奖励的帖子总量) * 8 bytes * CM

其中:

*帖子总量 = 在该期限内创建的帖子总量

*Total UD = 在该期限内的赞和踩的总量

*所有的申领奖励的帖子总量 = 在该期限内，申领奖励的总量。

*CM = themarmadapp 合约中所使用的申领乘数。等于(该日的赞数) 乘以 (未申领奖励的日期数).

由此可得：

该期限内消耗的 RAM 总量为 =

(帖子数 * 263 bytes) + (赞/踩数 * 8 bytes) - (申领奖励的帖子数 * 8 bytes) =

(3,106 * 263 bytes) + (82,012 * 8 bytes) - (2357 * 8 bytes) =

1,454,118 bytes

计算得到: Karma 每周大约需要 1.4MB 的 RAM。

对替代性方案的分析 — 使用 vRAM的情形

使用 vRAM 系统，Karma 可以释放所用的 RAM，将帖子、赞和踩的数据存放至区块链历史之中，并通过 DSP 进行索引。只有在创建帖子或者与帖子交互时，才会将数据加载到 RAM 的临时数据表之中，在事务结束后，将数据删除。对于 ‘Createpost(创建帖子)’ 或 ‘Other’(其他)的操作而言，帖子所占用的 263 字节的数据只是临时消耗，Upvote（赞）或 Downvote(踩)的操作，会额外消耗 8 字节数据。发起 Claim（申领）操作，会将帖子及其相关的赞/踩数据加载到临时的 RAM 数据表中。

使用 vRAM，智能合约只需要在事务的生命周期存续期内将帖子及其元数据加载至 RAM 之中。

事务生命周期包括整个 vRAM 操作集，包括预热、加载、事务和清理操作。(还不确定事务是如何与vRAM一起工作的? 请阅读我们的 vRAM专家指南。)

Createpost(创建帖子): (帖子数量) * 263 bytes

Upvote/Downvote(赞/踩): (UD) * (263 bytes + 8 bytes)

Claim(申领): -(⅀ 申领奖励的帖子量)* (263 bytes + 8 bytes * CM)

Other(其他): 其他 * 263 bytes

其中:

*帖子数量 = 当前事务生命周期中的帖子数量。

*UD = 当前事务生命周期内的赞踩数量。

*申领奖励的帖子量 = 当前事务的生命周期内的申领奖励的帖子数量。

*其他 = 当前生命周期中，除发帖、赞/踩或申领奖励之外的其他事务的数量。

*CM = themarmadapp 合约中所使用的申领乘数。等于(该日的赞数) 乘以 (未申领奖励的日期数).

✍️ 由于在10s 的事务生命周期中的事务数量多少不一，所以我们决定设定相对宽松的假设，并使用在整个时间段内任何 10 秒的时间窗口中发生的最大事务数量(恰好是15个)来估计RAM成本。

若使用 vRAM 系统，在整个采样周期内使用的 RAM 量 =

(UD + 申领奖励的帖子 ) * (263 + 8字节) + (帖子+其他类别) * 263字节 =

14 * 271 + 1 * 263 = 4,057字节

结论: 在采样的这一周时间的最大处理能力的情况下，如果使用 vRAM 系统，则 Karma 智能合约只需要消耗 4Kb的 RAM 数据量。

敏感性分析报告

敏感性分析使我们能够发现，如果改变输入数据或者假设，系统的输出会如何随之变化。在这种情况下，我们可以将申领乘数(CM)和事务的生命周期长度视为变量，并重新运行我们的分析。

首先看看智能合约在10秒、20秒、40秒和 60秒的事务生命周期内处理的最大事务数，我们可以得到如下结果:

根据我们的经验，事务的生命周期不应超过10秒。

然而，我们运行了一些最坏的场景来演示：即使在最严格的假设下，vRAM系统也可以用于节约成本。

因此，即使我们假设一笔事务的生命周期为 60 s — — 这远比预期的时间要长得多 — — 并且所释放的存储量 8 倍于当前情况下实际释放的RAM，通过切换到 vRAM 系统，所节省的 RAM 量也是很可观的。

释放内存

峰值时，Karma dApp的日活跃用户大约为 3800个(来源: dAppRadar)，这一数据令人印象深刻，因为 Karma 所建立的底层协议仅有几个月的历史。

目前，维护程序运行所需要的 RAM 成本对 Karma 而言不是太大的负担。然而，随着团队对产品的迭代， Karma 的网络效应继续增长，为每一个新的赞、踩，或者每一篇帖子所购的 RAM，将会成为对新用户引导的一个重大限制。

Karma 和其他面向用户的应用程序可以通过使用 vRAM 安全地存储数据，以此显著降低对 RAM 的需求和成本，同时利用 LiquidAccounts为新用户提供免费账号，使得新用户的使用体验可以顺畅无碍。

在本系列的后续文章中，我们会继续对其他 EOS dApps 的 RAM 消耗情况进行介绍分析，期待关注。

您可以从现在开始加入：

加入我们的中文电报群，您可以在那里提出问题，提供反馈，并帮助社区了解DAPP网络

dApp开发者？请查看我们的Github代码库并加入英文开发者电报频道

在我们的中文Medium页面上阅读有关DAPP网络及其组成部分的更多信息

在微博上关注我们，了解最新最好的内容