vRAM Guide for Experts

A Technical Deep-Dive Into The DAPP Network’s Decentralized Storage Solution

LiquidApps
Mar 10 · 12 min read

EOS — Home of dApps

The EOS blockchain was launched with the aim of housing scalable applications that are fully decentralized and service a mainstream audience. In just a few months since launching its mainnet, EOS has surpassed its competitors in terms of blockchain activity. Delegated proof of stake and 500ms block times have given EOS the sheer processing capability to distinguish itself as the best-positioned protocol to support the next wave of paradigm-shifting dApps.

RAM Isn’t Being Used Properly

Despite its stellar performance, the cost and limitations of network resources on EOS are constraining dApp developers from building and scaling their applications. In particular, the requirement of having to store both dApp smart contracts and their state information, such as the balance for each user, permanently in RAM is presenting a barrier to dApp scalability. EOS RAM is a misleading term as it functions more like a hard disk drive than a random-access memory device whose role is to store data relevant to live operations.

Introducing The vRAM System

The vRAM System is an end-to-end decentralized alternative storage solution for developers building EOS dApps that is RAM-compatible. It aims to enable the storage and retrieval of potentially unlimited amounts of data affordably and efficiently.

Provisioning Layer

At the heart of the DAPP Network are the DAPP Service Providers (DSPs) which provide critical services to developers building EOS dApps. DSPs create service packages which they then offer to developers in a free market. In order to access a specific service package, a dApp smart contract needs to stake a sufficient amount of DAPP Tokens as per the Service Agreement set out by the DSP. The ‘dappservices’ smart contract is responsible for managing the staking mechanism, package provisioning and quota management. Each service request is recorded on-chain and decreases the remaining quota of actions available to the dApp smart contract.

  • Services based off-chain which are accessible from a client-side application like the history-as-a-service utilization described in this article.

DAPP Service Layer

For DSP services that require interaction with a dApp smart contract, referred to as a User Contract in our whitepaper, the DAPP Service layer contains the protocol with which a User Contract can request a specific service from the DSP. A service request is a “function-like” call to the DSP in that it has specific parameters and can trigger a response back to the contract with specific results.

IPFS Service Layer

Local IPFS cluster is a distributed data storage solution that uses content-based addressing to access files. Unlike the traditional client-server model, where each file lives on a server with a specific IP address and is retrieved by the client requesting that address, local IPFS cluster files are hashed to give a Unique Resource Identifier (URI) which serves as a pointer to the given file. The DAPP Network supports three different service requests that harness the power of the local IPFS clusters to store files on a decentralized peer-to-peer network and retrieve them securely and efficiently.

vRAM Layer

The vRAM layer provides a familiar interface for developers from within the smart contract — multi-index tables. vRAM makes it significantly more efficient to retrieve information from the local IPFS cluster and manipulate it in a way that is familiar to dApp developers. DSPs are not exposed to the vRAM layer — it exists solely within the User Contracts (using the vRAM library) — allowing for system upgrades and optimizations without altering DSP software. vRAM uses a Merkle tree to represent the entire database. Each node in the Merkle tree is represented as a file on local IPFS cluster, requested on demand only when a proof is needed. In order to locate a specific file, one needs to traverse the tree until they reach the leaf node representing the data required. Only the current root node representing the entire database needs to persist in RAM.

vRAM under the hood

To illustrate how vRAM can empower developers to create a new generation of dApps, we will walk you through a Super Mario-style runner game. Let’s call it Super DAPP (🍄). The Super DAPP smart contract has two actions: “Start game” which loads a player’s progress and current score before a new game session begins, and “Modify Score” which updates a player’s score once the game session has concluded.

  • Warm-Up
  • Load and Transact
  • Modify
  • Clear Cache

Signal

(1) A dApp smart contract that uses vRAM, referred to in our whitepaper as a ‘User Contract’, receives a transaction from a client through a DSP node’s EOSIO API.

Client’s App (eosjs instance) sends a transaction through the DSP API node. The transaction fails when run locally by the DSP. This exception is a way to signal a service request.

Warm-Up

(1) The DSP verifies that the dApp smart contract has a sufficient amount of DAPP staked for the particular service package and sufficient amount of available Quota.

The DSP fetches the requested file from local IPFS cluster and retrieves the cryptographic proof of the dataset’s integrity from EOS RAM. It then relays the file and proof to the dApp Smart Contract in what is known as a ‘Warm-Up Request”.

Load and Transact

(1) The dApp smart contract loads the necessary data into a temporary cache table residing in the RAM.

After verifying the validity of the data, the DSP loads it into EOS RAM and sends the transaction to the blockchain. This time it succeeds since all the necessary data is available in RAM.

Modify

(1) Whenever a smart contract modifies data in vRAM based multi-index tables, it dispatches a commit event with the modified data and the merkle tree nodes that were affected by the change. The data points and the merkle tree nodes are represented as local IPFS cluster files.

The dApp Smart Contract modifies data on EOS RAM by means of an inline action. DSPs listen to the modification event and write the new file on their local IPFS cluster node.

Clear Cache

(1) After the transaction has ended, the DSP dispatches a cleanup event to the dApp Smart Contract to evict the data from RAM.

The data is deleted from EOS RAM, leaving behind a cryptographic proof (Merkle root) that the action happened.

End-to-End Decentralized Storage

Whenever data is modified, the Merkle root of the dataset which is stored in RAM is updated. When that data is required from within a contract, a Merkle proof is relayed along with the required data points to the dApp smart contract by the DSP node.

DAPP to the Future

vRAM is just the first implementation of the DAPP Network harnessing the power of DSPs, developers and the DAPP Token to unlock dApp scalability.

Follow LiquidApps

Website | Twitter | Telegram | LinkedIn | Github

LiquidApps

Written by

LiquidApps aims to optimize development on the blockchain by equipping developers with a range of products for building and scaling dApps.