The Design of Smart Contracts in MEMO Decentralized Cloud Storage

In a blockchain-based decentralized cloud storage system, there is often a many-to-many relationship between storage users and storage service providers. At the same time, as the system is deployed in a point-to-point and low-trust environment where there is no centralized management, it is essential to address the crucial issues of various management tasks and payment for storage services. As a computer program that can be automatically executed on the blockchain, smart contracts are the key to solving this problem.

Types of MEMO Smart Contracts

Memoriae (referred to as MEMO) is a decentralized cloud storage system based on Blockchain-Enabled Storage Technology (B.E.S.T) that leverages edge storage devices to achieve physical decentralization. Meanwhile, blockchain and smart contracts connect massive edge storage devices to form one decentralized self-run system.

There are three roles in the MEMO decentralized cloud storage system: User the storage requester, Keeper the manager, and Provider as storage provider. The involves role management, storage market management, and data maintenance. Smart contracts run throughout the whole operation of the system, enabling the interaction between roles and the realization of system role.

Based on the three modules of role management, storage market management, and data maintenance management, the smart contract in the MEMO decentralized cloud system can be divided as follows:

• Role-based contacts: Keeper contract, Provider contract
• Storage market management contracts: Offer contract, Query contract, Upkeeping contract, Channel contract
• Data maintenance contract: Root contract

Role-based Contract

Keeper Contract: Recording the Keeper Establishment Conditions

The Keeper contract is a contract that records the establishment conditions of the keeper role. This contract needs to record the account address, whether it is a Keeper, the amount of pledge, time, and whether the account is disabled, etc.

To decipher this, “addr” represents the account address; “status” shows whether the account is activated, that is, whether the account is in the Keeper role; “banned” represents whether the address is disabled – if disabled, no role operations on the account are allowed; “money” represents the pledge of the account – the account becomes a Keeper only when the money is no less than the Keeper registration pledge amount specified by the system; “time” represents the time the account is pledged. The amount of pledge required is specified by the constructor function set by the Admin account of the Keeper contract, and can be changed later according to market conditions.

Provider Contract: Recording the Provider Establishment

A Provider contract is almost the same as a Keeper contract, except for the small difference in the pledge function that is set to take into consideration the storage space used by the pledge of the Provider. Unlike the Keeper, the Provider needs to pledge funds based on the pledged storage space. “Price” in the contract represents the unit price of pledge storage. The storage space pledged by the account can be traced via looking into the amount pledged by the Provider.

Storage Market Management Contracts

Offer Contract: Recording the Storage Conditions of the Provider

The Provider uses the Offer contract to show the storage services it can provide. The structure of the contract and the data structure of the state variables are shown in the following figure.

“Info” is used to record the storage information of the Provider, where “capacity” represents the storage capacity provided by the Provider; “duration” shows the storage duration provided by the Provider; “price” represents the unit rice of storage proposed by the Provider; “createDate” records the time when the Offer contract is created for later auditing. The Provider assigned values for “info” when creating the contract.

Query Contract: Recording the Storage Requirements of the User

The User deploys the Query contract to indicate the specifications of the required storage service. The data structure of the state variables in the contract is shown in the figure below.

Upkeeping Contract: Recording the Workload and Duration of Storage Services

The Upkeeping contract represents a storage service established by the User, Keepers, and Providers, and is the most complicated one in all the contracts. This contract needs to record the account information of the Keepers and Providers and enable payment for the storage.

The contract defines 3 events that constitute the addition of Provider, space-time payment, and extension of storage service duration. When events are called, their parameters will be stored in the transaction log (a special data structure in the blockchain). The log is associated with the contract address – as long as there is an accessible block, the log will always be kept on the blockchain. By defining these three events, the Upkeeping contract allows system users to obtain proof of payment and other operations by querying the events. If a space-time payment s triggered, the storage service start time of this payment should be the same as the end time of the previous one, and the payment time should not exceed the service validity period.

Verify the signature of Keepers for the current space-time payment. The payment can only continue when the number of valid signatures is no less than 2/3 of the number of Keepers.

The amount of funds to be paid is aggregated and stored in the “KPInfo.money” array for the target Provider. Each value in “money” represents the number of funds aggregated in a single “cycle”. “stValue” represents the amount paid in the current space-time payment. First aggregate the funds, and then delay 3 “cycle” of payment. “payIndex” indicates the index of the next payment. If the time has exceeded 3 “cycle”, the funds will be transferred to the Provider and a “Pay” event will be called to record the originating address, target address, and payment amount; if the time is equal to or exceeds the validity period of the storage service at this moment, then all the to-be-paid funds will be settled.

Channel Contract: Recording Payment

The Channel contract is a contract that records payments. The state variables which need to be saved are: “channelSender” (payee), “channelRecipient” (payer), “startDate” (contract creation time), “timeOut” (contract validity period). The account address needs to be modified through “payable” to be able to receive transfers.

Data Maintenance Contract: Root Contract

The Root contract records the data-related information of the storage service in the system. The contract is deployed by the User. The User deploys one Root contract for a storage service to record file information to prevent the data from being arbitrarily changed by other accounts. The data structure of the state variables for this contract is shown in the figure.

Summary

In a decentralized cloud storage system, smart contracts can minimize the need for intermediary trust. The MEMO decentralized cloud storage system has developed the above functional contracts for role deployment, role interaction, workload certification, and payment requirements in the role market, storage market, and data maintenance market, so that the roles in the system can trust each other and fulfill the contracts in a decentralized environment. Blockchain and smart contracts are the basis for the system to achieve security, reliability, and availability.

MEMO’s test network is currently underway, so feel free to join.

MEMO community volunteer recruitment program will be launched soon, welcome to join us and work together with the MEMO team to make human data eternal!

Metastorage, a fully decentralized dual NFT storage system based on MEMO, links both the IPFS system and MEFS systems to secure like never before!

For more details, please visit: Official Website, Twitter, Telegram, Facebook, Medium, Reddit, Github, Discord.