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 blockchain-based decentralized cloud storage system 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 distributed cloud storage system: User the storage requester, Keeper the manager, and Provider as a storage provider. The involves role management, storage market management, and data maintenance. Smart contracts exist throughout the whole operation of the system, enabling the interaction between roles and the realization of the system roles.
Based on the three modules of role management, storage market management, and data maintenance management, the smart contract in the MEMO distributed 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
I. Role-based contract
- Keeper contract — recording the conditions of establishing the Keeper role
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.
2. Provider contract — recording conditions of establishing the Provider role
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.
II. 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” unit price 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.
2. 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.
The User assigns info variables when the contract is created and stores it in “storage” which is kept in the blockchain. “complete” indicates whether the contract has been completed, specifically whether the User’s storage service has been matched to suitable Keepers and Providers. If it is completed, there is no need to perform matching queries. The other state variables in the Query contract have the same meaning as the Offer contract.
3. 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, which are the addition of Provider, spatio-temporal 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 in 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. When the spatio-temporal payment is 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 spatio-temporal 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 spatio-temporal 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.
4. 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.
III. 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 distributed cloud storage system, smart contracts can minimize the need for trust in intermediaries. 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.