EOS dApps and Their RAM Expenses
A Case Study in Karma’s RAM Costs, and How Karma Can Reduce RAM Requirements by as much as 99%.
In a series of case studies, the LiquidApps team will be providing an analysis of the current RAM consumption and suggest an alternative model that utilizes the vRAM system, a decentralized complementary memory solution for EOS dApps running on the DAPP Network.
The first dApp profiled is Karma, a social media dApp currently consuming 1.4 MB of RAM per week in order to store posts and metadata. An alternative model that utilizes the vRAM system would free Karma from having to store data permanently on RAM, leading to an expected 98.7% RAM savings according to the most conservative estimates.
All the data we used is publicly available and was accessed through the EOSPark API. Throughout the analysis, assumptions will be made, detailed clearly and prefaced by the ✍️ symbol. Later on, a sensitivity analysis will show the corresponding RAM consumption amounts when these assumptions are changed.
Getting to Know Karma
Karma is a social media dApp incentivizing positivity and social impact through a tokenized reward mechanism. It consists of the traditional components of a social media site, such as user profiles and posts uploads, alongside a Karma wallet. Users can post photos and videos, share each other’s content and send Karma from within the application. Additionally, users can upvote their peers anytime they post a benevolent interaction on the platform. KARMA tokens are generated as the user interacts positively within the application, and rewards can be enhanced through a built-in staking mechanism. Tokens generated are claimed at the discretion of the user.
Karma Under the Hood
Behind the scenes, Karma is fueled by two smart contracts that control the application workflow — therealkarma and thekarmadapp — and each serves a distinct purpose.
therealkarma Smart Contract
therealkarma holds a sizable sum of Karma tokens. Populated by ‘Claim’ and ‘Transfer’ transactions, this contract is responsible for issuing Karma tokens and storing all the token balances. The amount of RAM available to this contract, 38MB, is approximately the amount required to execute an airdrop around the time of the mainnet launch.
🌟Fun fact: Since the original mainnet snapshot included 163,930 accounts, the amount of RAM required to airdrop to a single account is 0.229kb. Assuming the same amount of RAM is needed today, a dApp would need ~200 MBs to airdrop to all 857,000 accounts on the mainnet.
thekarmadapp Smart Contract
Karma’s application logic is found in thekarmadapp, which processes a wider range of transactions. The most-used actions include “Upvote”/”Downvote”, “Claim” and “Createpost”. These transactions either consume or release RAM. Karma removes posts off RAM after two weeks in order to free up the RAM space they occupy together with their metadata.
- Upvote/Downvote — Upvotes and downvotes consume 8 bytes of RAM per transaction.
- Createpost — Every time a user creates a new post, thekarmadapp contract consumes 263 bytes of RAM.
- Claim — RAM is released back to the system every time a user claims their tokenized rewards. The amount is variable and can be calculated according to the following formula:
RAM Released = 8 bytes * (upvotes that day) * (days unclaimed)✍️ For the sake of this analysis, we will assume that for each claim action, the post in question received 1 like and went unclaimed for one day, releasing 8 bytes back to the system.
The Alternative
Using the vRAM system could potentially slash the cost of RAM by storing data on chain history and having it indexed by DSPs. Posts would live on chain history, not in RAM, and would only need to be loaded into a temporary RAM table once a user interacts with it. RAM would only need to be accessed for the duration of a transaction’s lifecycle, after which the data would be removed from RAM. The time it takes for the smart contract to successfully execute a vRAM transaction depends on the Service Level Agreement of their service package.
Furthermore, by using vRAM, Karma could keep posts on-chain for much longer than two weeks, allowing them to accumulate more votes and rewards for users.
Transaction Lifecycle: Definition and Assumptions
A ‘transaction ‘lifecycle’ refers to all the actions that take place from warmup to eviction. This includes loading the data into RAM and modifying the data should changes be made.
✍️ For the sake of this exercise, we will assume a 10-second transaction lifecycle. In our experience, this complete just-in-time transaction lifecycle ranges from 1 to 10 seconds. However, we ran the analysis on longer times to evaluate the cost savings under the worst assumptions. This variable will also be considered as part of a later sensitivity analysis.
Data
Our analysis encompasses a week of transaction data, beginning at 15:00 on June 5th and ending on June 10th in the morning (“the entire period”). The 92,501 transactions pulled are broken down as follows:
‘Other’ includes transactions which do not consume any RAM, such as creating a comment.
When we ran the script 2 months ago, beginning midday on April 8th and ending on April 14th, we pulled 73,602 transactions. We then multiplied the April data by 5/7 to interpolate the corresponding figures for 5 days. The transaction growth between April and June can be broken down as follows:
While usage has dramatically increased, it is interesting to note the decrease in the number of claim actions. This suggests that users are leaving their posts unclaimed longer, in order to increase their rewards.
Analyzing the Current Situation — Without vRAM
Karma utilizes tokenized rewards to incentivize users to post their positive interactions on the application. Rewards are determined by the number of Upvotes/Downvotes received by each post. Therefore, once a post is created, it must live on RAM together with any subsequent upvotes and downvotes.
The RAM consumption was calculated according to the following formulas:
Createpost: (Total Posts) * 263 bytesUpvote/Downvote: (Total UD) * 8 bytesClaim: -(⅀ Total Claimed Posts) * 8 bytes * CM
Where:
- Total Posts = Total number of posts created during the entire period.
- Total UD = Total number of upvotes and downvotes during the entire period.
- Total Claimed Posts = Total number of claims during the entire period.
- CM = The claim multiplier used in the thekarmadapp smart contract. It equals (number of upvotes that day) times (number of days left unclaimed).
This gives us:
Total RAM consumed during the entire period =(Posts * 263 bytes) + (UD * 8 bytes) - (Claimed Posts * 8 bytes) =(3,106 * 263 bytes) + (82,012 * 8 bytes) - (2357 * 8 bytes) =1,454,118 bytes
Conclusion: Karma requires ~1.4MB of RAM to run for a single week.
Analyzing the Alternative — Using vRAM
By using the vRAM system, Karma could free up RAM by storing posts, upvotes and downvotes on chain history and having them indexed by DSPs. Only once a post is created or engaged with will the data be loaded into a temporary table in RAM, to be deleted immediately following the conclusion of the transaction. For a ‘Createpost’ or ‘Other’ action, the 263 bytes occupied by the post will be consumed temporarily, while an ‘Upvote’ or ‘Downvote’ will consume an additional 8 bytes. Initiating a ‘Claim’ action will load the post as well as the related upvotes and downvotes into the temporary RAM table.
Using vRAM, the contract would need to store posts and their metadata on RAM for the duration of a transaction lifecycle only.
A transaction lifecycle comprises the entire set of vRAM actions, including the warmup, load, transact and cleanup actions. (Not yet sure exactly how transactions work with vRAM? Visit our vRAM Guide For Experts.)
Createpost: Posts * 263 bytesUpvote/downvote: UD * (263 bytes + 8 bytes)Claim: -(⅀ Claimed Posts) * (263 bytes + 8 bytes * CM)Other: Other * 263 bytes
Where:
- Posts = Number of posts in the current transaction lifecycle.
- UD = Number of upvotes and downvotes in the current transaction lifecycle.
- Claimed Posts = Number of claims in the current transaction lifecycle.
- Other = Number of transactions that are not posts, upvotes, downvotes or claims in the current transaction lifecycle.
- CM = The claim multiplier used in the thekarmadapp smart contract. It equals the Number of upvotes that day Number of days left unclaimed.
✍️ Since the number of transactions occurring in a 10-second transaction lifecycle is highly variable, we decided to make a liberal assumption and estimate RAM costs using the maximum number of transactions occurring in any 10-second window during the entire period, which happens to be 15.
Total RAM that would have been consumed during the entire period using vRAM =(UD+Claimed Posts) * (263+8 bytes) + (Posts+Other) * 263 bytes =14 * 271 + 1 * 263 = 4,057 bytes
Conclusion: At maximum capacity over the sampled week, the Karma smart contract would only require 4kb of RAM had it made use of the vRAM system.
Sensitivity Analysis
Sensitivity analysis allows us to find out how the variation in the output of a system can be apportioned to different input parameters or set of assumptions. In this case, we can treat the claims multiplier and the length of a transaction lifecycle as variable and rerun our analysis.
Looking first at the maximum number of transactions processed by the contract for 10, 20, 40 and 60-second transaction lifecycles gives us:
In our experience, the transaction lifecycle should not exceed 10 seconds.
However, we ran a number of worst-case scenarios to demonstrate the cost savings that vRAM could provide even under the most restrictive assumptions.
So, even if we assume a 60-second transaction lifecycle — which is significantly longer than expected — and free 8 times of the actual amount of RAM that is being released in the current situation, the RAM savings achieved by transitioning to vRAM are substantial.
Free Your Memory
At its peak, Karma registered 3,800 daily active users (source: dAppRadar), an impressive feat considering the fact that the base-layer protocol on which it is built is only a few months old. Currently, the RAM costs of maintaining their operation are not too burdensome for Karma. However, as they iterate on their product and their network effect continues to grow, buying RAM for each new upvote, downvote or post will prove a significant hurdle to onboarding new users.
Karma and other user-facing applications can significantly lower their RAM requirements and costs by storing their data securely using vRAM, while utilizing LiquidAccounts to onboard new users seamlessly and for free.
