Introduction

Memo is a large-scale decentralized data storage system with high security and reliability built around blockchain. It is a new-gen blockchain decentralized cloud storage protocol that organizes global edge storage nodes to provide users with safe, reliable and highly available storage services.

MEFS(MEmo File System) is the file storage system for MEMO.

MEMO is a new-gen blockchain decentralized cloud storage protocol developed by MEMO Labs. Our mission is to build a reliable infrastructure for Web3.0. To achieve high scalability and availability, MEMO has vastly innovated data tiering, verification, fault tolerance, and recovery mechanisms. MEMO has made technological breakthroughs on blockchain cloud storage with a new architecture and multiple innovations.

MEMO has designed three user roles: the User, the storage space user; the Provider, the storage space provider; and the Keeper, the coordination manager. Driven by smart contracts, three interconnected roles constrain each other.

MEMO can be divided into three functional role-based layers: settlement, verification, and storage. The settlement layer processes settlement on-chain by aggregating order information and sending the amount of each order to the storage nodes Provider. The verification layer is conducted off-chain. The Keeper nodes challenge the Provider nodes, verifie the results of the proof, and decide whether to issue the withdrawal certificate to the Provider nodes. All processes on the verification layer will go through nodes on the same layer and pass the Byzantine fault-tolerant consensus. The storage layer consists of massive scattered Provider nodes, which store genuine User data and regularly submit the proof of storage to the verification layer.

The following articles will help you learn more.

What is MEMO?

Roles：

Technology：

The user clicks on the link to obtain test tokens in the Memoriae wallet (under development), and the system will send the user a test token of 10 Memo. When the user's test balance is not less than 10 Memo, they will not be able to apply for the test token again.

send an eail to to apply for test tokens

Email subject: apply for test token

Email content: account address (format such as 0x...), role (Provider or Keeper or User)

Persons who are interested in decentralized data storage systems are welcome to join the Memo community and participate in interaction!

Our URL is:

Our is:

1. Introduction to MEMO Protocol

MEMO is a new-gen blockchain decentralized cloud storage protocol developed by MEMO Labs. Our mission is to build a reliable infrastructure for Web3.0. To achieve high scalability and availability, MEMO has vastly innovated data tiering, verification, fault tolerance, and recovery mechanisms. MEMO has made technological breakthroughs on blockchain cloud storage with a new architecture and multiple innovations.

MEMO has designed three user roles: the User, the storage space user; the Provider, the storage space provider; and the Keeper, the coordination manager. Driven by smart contracts, three interconnected roles constrain each other.

MEMO can be divided into three functional role-based layers: settlement, verification, and storage. The settlement layer processes settlement on-chain by aggregating order information and sending the amount of each order to the storage nodes Provider. The verification layer is conducted off-chain. The Keeper nodes challenge the Provider nodes, verifie the results of the proof, and decide whether to issue the withdrawal certificate to the Provider nodes. All processes on the verification layer will go through nodes on the same layer and pass the Byzantine fault-tolerant consensus. The storage layer consists of massive scattered Provider nodes, which store genuine User data and regularly submit the proof of storage to the verification layer.

2. TOKEN Design

2.1 Definition

MEMO is a MEMO-protocol token to drive operation and scale up the entire MEMO storage protocol. In this protocol, to earn income, the Keeper and the Provider will need to make pledges to MEMO, while the User uses MEMO tokens to pay for data storage and retrieval. MEMO will increase the issuance of tokens to incentivize the Keeper, the Provider, and long-term token holders based on their order volume. MEMO is not merely a token in use, but also equity. This enables MEMO token holders to benefit from a growing MEMO ecosystem by participating in our governance.

2.2 Principles

Technically speaking, MEMO aims to create a large-scale data storage pool, ensuring data security, reliability, and privacy through our public verification mechanisms, encryption algorithms, multi-level fault tolerance, and recovery mechanisms while effectively reducing on-chain load and enhancing scaling performance through our tiered storage.

On our TOKEN design, MEMO intends to create value for our users and participants in the ecosystems, improve productivity, and incentivize ecological growth. The principle of our economic model is the fairest possible participant incentive in proportion to their costs. The logic of the economic model should be governed by codes to eliminate human control. The economic model should incentivize participant behaviors beneficial to the protocols.

3. Circulation Mechanism

3.1 MEMO Economic Circulation

TOKEN will be circulated among the User, the Keeper, the storage nodes Provider, as well as developers, investors, and token holders. First of all, the User needs to purchase MEMO tokens to pay for storage service, the Keeper and the Provider need to purchase MEMO tokens as pledges before providing their service and earning incomes. MEMO tokens paid by the User for storage service will be sent to the Keeper and the Provider. Meantime, the Keeper, the Provider, and long-term holders will be given incentive awards for ecological growth by pledging MEMO tokens in the pledge pool. So the production and circulation of MEMO token is a cycle of consumption and reproduction, as storage gradually scales and token value appreciates.

3.2 MEMO Use Scenarios

There are two use scenarios of MEMO token (MetaMEMO) in the MEMO protocol: as a pledge and as payment for storage service. Pledges are often associated with the Keeper and the Provider, while payments are concerned with the User and developers.

Pledge: For better user experience, a pledge of a number of MEMO tokens is required to become the Keeper and the Provider. The purpose is to restrict and regulate behaviors of the Keeper and the Provider and advocate honest and reliable services.

Payment: The User, the end consumer or developers, use TOKEN to pay for data storage, retrieval, and download service. The TOKEN will eventually go to the Provider and the Keeper as the income for providing data storage and management services. So the User and developers need to purchase MEMO TOKEN before using the storage service and transfer it to the order pool before signing an order to use MEMO storage service.

MEMO token also represents the rights and interests of the entire protocol. Therefore, MEMO token holders can pledge MEMO tokens to the pledge pool to obtain additional incentive earnings. Meantime, MEMO token holders will be able to participate in the governance of the protocol with future governance mechanisms.

4. Ecological Development

4.1 Foundation

MEMO Foundation is mainly for ecosystem development, marketing, and community maintenance. Meantime, partial funding is invested to promote ecological development and maintain the foundation’s long-term sustainable operation.

MEMO Foundation assumes the following responsibilities:

● Organize the development team or outsource tasks to implement the MEMO protocol and its updates.

● Support and fund MEMO ecological applications.

● Persistently contribute to long-term MEMO community operations.

MEMO Foundation has the right to initiate proposals concerning system governance. The community has the decision on its final implementation.

The Foundation may initiate the following proposals, including but not limited to:

● Modify the systems’ economic parameters.

●Propose technical updates.

● Penalize the Keeper’s wrongdoing or inaction.

● Penalize the Provider’s wrongdoing or inaction.

4.2 Community Ecology

As a blockchain-based decentralized storage solution, the development of MEMO protocol is inseparable from community support. MEMO Foundation will actively organize and build various communities with different functions including ecology governance, developer community, and token holder community to encourage the healthy and stable development of protocol and ecology on many fronts.

4.3 The Keeper

Before joining our protocol, the Keeper must pledge sufficient deposits.

The Keeper must fulfill the following obligations:

● Pledges shall not be less than the specified amount of deposit.

● Ensure long-term online activities and maintain historical data on the verification layer.

● Verify the Provider's Proof of Storage and issue a withdrawal certificate to the Provider through the Byzantine fault-tolerant consensus.

● Schedule a data recovery process when the Provider loses data.

Meantime, the Keeper is entitled to the following benefits:

● Earn a certain percentage from orders under its management.

● Obtain incentive reward from the pledged deposits.

Penalty may apply for any wrongdoing or inaction, such as deductions from the deposits and no further earnings from service provisions.

4.4 The Provider

Before joining our protocol and receiving earnings from orders signed with the User, the Provider must pledge sufficient deposits.

The Provider must fulfill the following obligations:

● Pledges shall not be less than the specified amount of deposit.

● Ensure data is stored in accordance with the standards specified in the order, and the reliability and availability of the data.

● Timely submit the Proof of Storage to the verification layer.

Meantime, the Provider is entitled to the following benefits:

● Gather payment progressively from user's orders.

● Obtain incentive reward from the pledged deposits.

Any failure to fulfill obligations (e.g. data loss or overdue proof submission) may result in penalties, including deductions from the deposits and order transfers.

4.5 The User

User is the consumer of the protocol and needs to pay for the storage service. As a User, you need to fulfill the following obligations:

● Deposit enough Tokens into the contract to pay the storage fee. Meanwhile, the User has the following rights:

● Choose suitable Provider and Keeper to serve yourself;

● Rate the services of Provider and Keeper;

● Obtain incentive income from the staking pool.

4.6 Developers

Developers can adopt MEMO protocol in their projects. More projects using MEMO storage service will bring more users and storage demands.

MEMO Foundation will screen valuable contributors towards MEMO protocol through developer events and incentivize developers with tokens to incubate their projects. Developers must fulfill the following obligations:

● Maintain their projects.

● Keep up-to-date with the latest Memo protocol.

MEMO is a new-gen blockchain decentralized cloud storage protocol that organizes global edge storage nodes to provide users with safe, reliable and highly available storage services.

MEFS(MEmo File System) is the file storage system for MEMO.

The following articles will help you learn more.

What is MEMO?

Memoriae — Next Generation of Decentralized Cloud Storage Based on Blockchain

Roles：

Technology：

❓The Overall Functions

The overall functions that have been implemented for mefs-user, mefs-keeper, and mefs-provider will also be able to get a more complete experience in the test network Phecda. Specifically, it includes:

📨 Provider's role contract setting, storage market, revenue display, etc.

📨 User's storage order matching, signing, uploading and downloading functions etc.

In addition, the optimization of the Keeper exit mechanism is also in progress and will be gradually completed.

Method 1：

Enter the product chain browser: https://scan.metamemo.one:8080/

You can check the account balance by pasting the wallet address into the search box in the upper right corner. There are two account balances:

Balance: Product chain token (ABBAS) balance, used for transaction overhead when starting a node

Tokens: Major Token (MEMO) balance, used to pay for storage services and staking.

Refer to WIKI and enter the container, and then run the command line to view all the information of the node, including account balance.

1.After the account is initialized, start the node and enter the container. Run the command line "mefs-user info" or "mefs-provider info" to check the account balance.

2.If the account has been started, and then the computer has been shutted down, Docker, or "Windows PowerShell" was been closed, you need to restart MEMO again to check the balance. Specifically, you need to open Docker first, then run the command line " docker start mefs-user" using Windows Powershell to start, and then enter the container to check it through the command line"mefs-user info" or "mefs-provider info".

The Payment of Memo System

The Payment Process of Memo System

Payment is an important link in the Memo system and the biggest motivation for Providers and Keepers to actively participate in the work of the system. It is precisely because of the existence of payment that Keepers is responsible for regularly challenging Providers, and Providers will actively cooperate with Keepers' challenges and the responses of Users.

In the Memo system, how is the fee that the User needs to pay is calculated?

The payment fee for a single Provider (MoneyProvider) is determined by the three parameters of storage unit price , storage duration , and storage space .

Keepers are responsible for verifying whether Providers store data completely. According to the challenge result, it can be concluded that how much and how long each Provider has effectively stored data for User during this period. The consensus on cost calculation is as follows:

The percentage coefficient in this formula is 90%, and the remaining 10% is allocated to the middle managers( Keepers )who participate in the challenge. This percentage is determined by the specific conditions of the system, but once determined, it applies to all nodes in the system.

The User deploys a contract for storing payment, using the contract's characteristics of saving assets and transferring funds, and realizes a payment scheme that does not depend on the trust of a specific third party.The main content is that the User determines the payment object and payment trigger conditions in the contract, and transfers a sufficient amount to the contract.Once the conditions for triggering payment are reached, the contract will automatically transfer the specified amount to the designated account to realize the storage payment. The advantage of this is that there is no need to rely on a specific institution, and the payment behavior is fully regulated and automated in advance.

Keeper can use this storage payment contract to find storage nodes that need to be challenged.The User can also use this contract to find out which nodes his data is stored on, so as to obtain the data, which is conducive to system data retrieval, and there is no load imbalance and performance bottleneck problems.

In the Memo system, the User's payment to Provider and Keeper is not paid in real time or paid in advance, but delayed.The original intention of this design is to protect the end User.Therefore, for the User, delaying payment for Keepers and Providers for a period of time can prompt Keepers and Providers to serve the User in good faith in accordance with the contract.Because if the User pays in advance, the Provider may damage the data before the storage service expires or no longer respond to the Keeper challenge, then it will bring losses to the User, so delayed payment is actually a protective measure for the User.

In addition, the fee is not paid in one time, but is paid at regular intervals.For example, the storage period is one year. Instead of paying for the entire year at a time, it is divided into many small cycles to complete. This is mainly due to the consideration of providing a better user experience for the Provider.

For example, if a Provider starts to store data for User from 10:00 on February 6, 2021, it should be stored for User for one month as required by the contract, and payment will be triggered every one day.Keeper needs to trigger the spatio-temporal payment at 10:00 on the 7th of the current month. It is necessary to record that the start time of the payment is 10:00 on April 6, 2021, and the deadline is 10:00 on April 7, 2020. It is usually one day.

The current plan is to determine a time interval cycle, as shown in the figure, record the amount that User needs to pay in each cycle, and delay 3 cycles before paying.When the storage service expires, the contract will transfer all accumulated unpaid cycle amounts to Keepers and Providers.The Provider does not need to worry about the User transferring the funds in the contract in advance, because the operation power of the contract funds is in the control of all the Keepers in the service.

As mentioned above, the role of deploying the payment contract is the User, but it is not the User that triggers the payment contract, but the Keeper.The reason why the spatiotemporal payment is triggered by the Keeper instead of the User or Provider is that:As a user of storage space, if User triggers payment, User may not trigger on time or even actively trigger;As a storage space provider, Provider may falsify data multiple times to trigger payment functions, thereby making profits.Let Keeper trigger the payment, which is also a check and balance measure of the system design.

So when the conditions are met, the Keeper will trigger the payment? Here is the verification of the following aspects:

1. Verify whether the payment object is the storage node Provider and management node Keeper in this storage service;

2. Verify whether the paid amount is consistent with the result of the Keeper challenge;

3. Verify whether the start time of the payment is equal to the cut-off time of the last payment.

Specific verification method:

Keepers regularly challenge a certain Provider. After a period of time, a merkle tree root is generated based on all the challenge results, which is recorded as merkle_Root.And record the number of times each Keeper participated in the challenge during this time in the array, which is recorded as share.

Each Keeper reached a consensus on the challenge result and obtained the amount of data and storage duration normally stored by the Provider during this period.According to this space-time value, after calculating the payment fee, each Keeper signs the Upkeeping contract address, the Provider address, the challenge result, the stStart and stLength related to the delayed payment, the share array, and the merkle_Root in turn.And select a master Keeper, and the master Keeper triggers the time-space payment method in the contract.The reason for signing this information is to ensure that the spatiotemporal payment is for the correct storage service, and the payment object is indeed the Provider node in the storage service.Secondly, this information can help to audit the time and space payment in the future.

The spatio-temporal payment function verifies the signature in turn, verifies whether the payment amount is consistent with that contained in the Keeper signature, and whether the initial time of payment is equal to the deadline of the last payment.That is, is stStartnow equal to stStartlast plus stLengthlast.If the information is consistent, then the spatio-temporal payment function can be executed. This can ensure that the payment amount, payment object, payment storage time and storage space are correct.Even if the Keeper is given the power to trigger the time and space payment, the Keeper is also subject to other Keepers, thus eliminating the possibility of a single Keeper doing evil.

User's payment to Provider, in addition to the storage fee payment mentioned above, will also involve download payment. Because the download operation will cause the Provider to consume traffic, and it will also increase the power cost and machine consumption.

However, unlike the storage service triggered by Keeper, the download payment is triggered by the Provider.

Smart contracts run through the Memo system.For downloading issues, the system designs a Channel contract.This contract can solve the characteristics of receiving value, saving value, and sending value to solve the problem of decentralized and reliable payment.The payment channel does not need to go through the intermediate manager Keeper, so the cost is lower, and the payment amount is only calculated based on the amount of data downloaded.The Channel contract records the addresses of the User and Provider, and also needs to record the start time and validity period of the contract.The Provider can trigger the payment contract accordingly, but the User can destroy the contract based on whether the contract has expired.

Unlike the delayed payment for storage services, the payment for downloads is real-time.However, the user needs to transfer funds for download payment to the Channel contract in advance, and the Provider can check whether the amount is sufficient.The initial value of the payment amount recorded by the two parties in the transaction is 0. Whenever the User downloads data from the Provider, the two parties in the transaction increase the payment amount according to the amount of data downloaded.The User signs the payment amount and sends it to the Provider. The Provider verifies whether the payment amount contained in the signature information is correct, and if it is correct, it authorizes the User to download data from this node.The Provider triggers the ReadPay function of the Channel contract with the signature information.After the function verifies that the signature information is correct, the payment amount contained in the signature information will be transferred from the contract funds to the Provider.

The user can also trigger the CloseChannel function of the Channel contract after the transaction expires to return the remaining funds in the contract to himself.

The practice of triggering the contract function only once to realize payment management can reduce the burden on the chain and the network.

Hardware Requirements

The Keeper and the Provider should stay online for a long time

System Requirements

Ensure the security of the keystore file

Recommended configuration：

Recommended configuration: 4 cores, 8G memory, 20Mbps bandwidth;

External network ip, port 4001 is usable;

Docker environment;

Recommended configuration：

4-core processor, 8G running memory, 200GB storage space, 20Mbps network bandwidth;

Internet ip address, port 4001 is open;

Docker environment;

Recommended configuration：

4 cores, 8G memory, 1TB storage, 20Mbps bandwidth;

External network ip, port 4001 is usable;

Docker environment;

Decentralized storage. After the user uploads the source file, the Memo system can distribute the data to multiple storage nodes and provide a unified standardized interface to the outside world. When the target user initiates a download request, the nearest node downloads the fragments by the nearest node and provides them to the user completely. Multiple images or copies are provided throughout the network, which greatly improves the access speed and stability.

Shared globally.Multiple Memo devices can form a cluster effect to realize global data sharing, unified storage space management, and automatic load balancing of the cloud storage platform. Files can be distributed across regions and networks, supporting data storage and efficient use across the entire network , On-demand expansion to meet the needs of users for high-speed expansion.

Data security. Data storage function is the cornerstone of Memo, and data security and reliability are the cornerstones of data storage function. Memo's data privacy policy requires data at its source-the client-that is encrypted with a user key before it is written to the edge storage device. In addition, the access control mechanism ensures that the data can be accessed by its owner or its maintainer and the store in collaboration, while not being accessed by other users, or unrelated maintainers and storers.

System reliability. Memo's goal of ensuring reliability is to prevent data loss when user equipment, maintenance equipment, or edge storage equipment fails. Duplication, erasure coding, and other data redundancy technologies can be used to ensure the reliability of data stored on edge storage devices.

The original data recovery method--RAFI. In addition to data redundancy mechanisms, data repair methods are also an important factor in determining data reliability. Memo's original data recovery method RAFI is used to further improve the reliability of data stored in edge storage devices. RAFI technology can optimize the edge storage space, and more guarantee the security of data and the stability of the system. Through real-time query, data with high risk of loss can be quickly found, effectively shortening the total time of data repair and improving performance.

MEMO is a blockchain-based decentralized cloud storage system. It's unlike some projects aiming at producing blocks whose storage data volume is directly linked to the calculation power of blocks; it is also different from pseudo-decentralized distributed storage projects, one of whose nodes or several usually undertake the function of 'centralized nodes'.

As the first version network of MEMO project, Phecda basically realizes the main functions of MEMO, including the command line functions of MEMO's three major roles (User/Keeper/Provider), s3 interface, etc.

• If you want more details, click here

• If you are v1 user, please upgrade to the latset version. Please refer to the .

Megrez2.5 is the latest version of MEMO’s network.

The main optimizations in Megrez 2.5 are the upgrading and optimization of the smart contracts and the economic model. In terms of smart contracts, the management of contracts and the scalability of contracts have been enhanced. In the economic model, the revenue parameters of the Provider role have been optimized.

If you want more details about Megrez 2.5, click here The new version of the Web3 decentralized storage layer MEMO, Megrez 2.5, will be available soon!

If you want to be a User, please refer to this guide

If you want to be a User quickly,you can refer to this guide

If you want to be a Provider, please refer to this guide

Compared with its predecessor Phecda, Megrez has upgraded its security and availability. In terms of security, Megrez has optimized the consensus mechanism for the Keepers and enables on-chain transaction data submission. In terms of availability, Megrez not only has improved the challenge mechanism but also developed a new micro-payment layer. In terms of application, Megrez has developed new application interfaces to meet the business needs of different partners.

If you want more details, click here

If you are v1 user, please upgrade to the latset version. Please refer to the .

Introduction of Roles

The Planning and Design of Memo system

In the era of the information explosion that we are now in, tens of thousands of documents, photos, videos and other data files are generated every day in the world. However, traditional centralized storage methods have become increasingly unable to meet market demand. It is expensive, and the second reason is that the security is not high enough, so blockchain distributed storage came into being. Compared with traditional centralized storage, blockchain distributed storage is the use of idle electronic devices scattered around the world, such as idle mobile phones, computers, hard disks, etc., which can all be used as edge storage nodes. The typical characteristics of blockchain decentralized storage are decentralization , higher security, and low cost, which has attracted the attention of global capital and technology circles.

At present, the blockchain decentralized storage technology is still in the stage of continuous exploration. After continuous efforts, Memolab has developed a new generation of blockchain-based decentralized cloud storage system Memo. Compared with the traditional blockchain, Memo adopts a more concise and efficient technical processing method to protect the keeper, provider, and user information and data, thereby ensuring the cost-effectiveness of the entire storage system and enabling users to obtain better use Experience.

Since the distributed cloud storage system is deployed in a low-trust P2P network, there is no centralized third-party organization responsible for management, and the storage devices are mostly idle edge devices for users, not proprietary storage servers. Therefore, for this application scenario, the decentralized cloud storage management system first faces system management problems, which are divided into system role management, storage market management, data maintenance management, etc., and these management requirements are ultimately the use of smart contracts Therefore, the management problem of smart contracts must also be solved.

According to the needs of storage scenarios and functions, users in a distributed cloud storage system are divided into three categories. These three types of users are defined as user,provider, and keeper. Their functions in the system are as follows:

User: Use storage space, specifically: upload data, which is stored by the storage node in the system, and is a consumer of storage services in the system.

Keeper: responsible for information intermediary and management functions, specifically: collecting storage information provided by the Provider connected to it, such as a Provider providing 1T storage space; collecting the evaluation information of the Keeper connected to it, such as its integrity Degree, etc.; Find a Provider that meets the requirements according to the User’s storage requirements, and challenge the Provider.

Provider: Provides storage space, specifically: Provides storage space for User, saves User's data, and is the provider of storage services in the system.

The key application of Memo is storage service, so storage market management is essential. With the help of Keeper, User finds a suitable Provider. The Provider provides space and time for storing data. Keeper challenges the Provider that stores data on a regular basis. If a Provider challenge is found to fail, the data repair function needs to be triggered. Download from Provider when a user need data. According to this application scenario, the user needs to pay the storage fee and download the data fee to the Provider, and pay the coordination management fee to the Keeper.

If a user violates the storage rules, such as damaging data and refusing to repair, etc., a corresponding penalty mechanism is needed to maintain the normal operation of the system. How does Keeper match between User and Provider; how to pay according to the price after the storage service is established; how to solve the problem when faced with a user's request to download data. These problems are collectively referred to as the needs of storage market management, and Memo has designed a storage duration management solution for this purpose.

Distributed cloud storage systems face the need for data maintenance and management. User’s data is stored on the selected Provider in the form of object storage, and the corresponding Keeper will challenge to ensure that the Keeper saves the data completely and correctly. However, this mechanism lacks trustworthiness, and all Keepers facing the same User may act dishonestly and provide false challenge results.

In addition, the user's metadata information is stored on the corresponding Keeper and synchronized between the Keepers. This can solve the problem of unbalanced or duplicated loads of metadata information in centralized cloud storage. Meta, the correctness of the data, and the maintenance of the data may be negotiated for evil. Therefore, based on the decentralization and trustworthiness of the smart contract, important information related to the stored data can be stored in the smart contract, so as to maintain the correctness of the data.

In order to maintain data security and integrity, various mainstream cryptographic technologies, such as symmetric encryption and decryption , anti-collision hash function and digital signature technology , are applied to meet strict data privacy and integrity requirements. Cryptography technology,data redundancy and repair technology will provide the system with sufficient flexibility to tolerate various possible software and hardware failures and small-scale malicious attacks, such as attempts to invade maintenance, storage and user equipment, thereby tampering, destroying, or Disclosure of data and information. At the same time, Memo uses proven POW and more innovative POS technology, supplemented by third-party security tools to further enhance system security.

One of the key issues in building a large-scale decentralized storage system is the efficient management of system roles and their relationships. In a distributed cloud storage system, according to different roles, the functions provided are different, and role information needs to be saved to determine the identity of the user to provide corresponding functions. The traditional method is to save the user's role, address and other information in the database, which is managed by the specific company. In the decentralized scenario, according to the characteristics of the account address that uniquely identifies users, smart contracts are used to manage system role information.

As mentioned above, the system has requirements for role management, storage market management, data maintenance and management, and these requirements ultimately need to be realized by smart contracts. Therefore, smart contract management is the basis for the realization of the above three types of management requirements. Contract management will The operation of the entire system runs through.

After the smart contract is deployed, the user needs to use the contract instance to be able to call the methods in the contract. The contract instance can be constructed by the contract address. For some contract functions that need to change the state on the chain, a specific user identity is required to be able to call; and for those contract functions that obtain the state information on the chain, any user can call. Therefore, the system has management problems such as storage and acquisition of contract addresses.

Figure: The interactive relationship between contract management and the system

In the Memo system, the account is first registered as a certain role, such as User. In this process, the address and User role of the account will be saved in the role smart contract. When the account is online, the role smart contract will be called. You can get your own role, and get the corresponding service according to the role. The account decides that it wants to become a certain role in the system based on its own storage requirements, conditions, etc. After the user goes online, the role information of the account is obtained from the role module.

Different roles have different functions, and role information also needs to be saved. The traditional approach is to save the user's role, address and other information in a central database, which is managed by a specific company. In the decentralized scenario of the Memo system, smart contracts will be used to manage system role information based on the characteristics of the account address that uniquely identifies users. In the initial stage of use, the Keeper of each user is randomly matched by the system. After the Keeper has accumulated certain data about the availability and reliability of the Provider, a scoring system can be built to match the Provider and the User, which can greatly reduce the transaction time.

Requirement analysis is the prerequisite for design and implementation. Based on the above management needs, Memo has designed multiple modules to solve the problems of role division, storage service implementation data maintenance, and contract invocation. These are the solid cornerstones of the Memo system.

In the Memo distributed cloud storage system, each user can register a role according to his own needs. The system roles include User, Keeper, and Provider. If it is a storage demander, it is registered as a User; if it is a device provider, it is registered as a Provider; if it only provides information management services, it is registered as a Keeper. This article will explain the design principles of each role from the perspective of overall system operation.

The basic roles of the three parties are as follows:

1、User: is the consumer of the storage service in the system, puts forward storage requirements and uploads data

2、Keeper: It is the management coordinator in the system, responsible for information intermediary and management functions.

3、Provider: is the storage device provider in the system, providing storage space for users.

Among these three roles, User and Provider are the supply and demand parties of storage services, and User is also the end user in the system. In short, User uses storage space in the Memo system, Keeper finds a suitable storage node for User, and storage node Provider stores data for User. Keeper is equivalent to an intermediate information matchmaker, providing intermediary services for users and providers. We can understand Keeper as a headhunter on a recruitment platform or an intermediary in a real estate trading platform.

Since the end user in the system is the User, it needs to pay the corresponding storage fee for the storage service, so every service request is initiated by the User.

When the User proposes a storage service demand, it should include the following elements: storage space size, storage duration; the number of Providers and Keepers; and the required storage unit price.

Because only after setting the above parameters, Keeper can retrieve and match the corresponding storage node. At the same time, in a decentralized cloud storage system, the more storage nodes, the more secure the data, but the more storage nodes, the higher the payment fee. Therefore, the Users need to determine the number of storage node Providers and intermediate managers Keepers by themselves, and need to find a balance between cost and data security.

The Users not only need to pay for storage services, but when they need to download data from the Provider, they also need to pay for the download, because the download operation will bring the Provider and the consumption of traffic and equipment.

Since the User is the ultimate payer, the system does not set special restrictions for this role, because if the User does not pay, the Provider and Keeper will stop the service. But for the other two roles, Provider and Keeper, the system has set corresponding punishment measures for them, which will be discussed below.

Keeper is an important intermediate role in the system. It assumes information intermediary and management functions, and extracts management commissions from the storage fees paid by the User.

As an information intermediary, its basic function is to match information, that is, to match information between the demand-side and demand-supply side. When the User puts forward storage requirements, Keeper will find the Provider connected to itself according to the User's requirements, and match the appropriate storage node.

In addition to basic information matching, Keeper's management functions are mainly embodied in participating in challenges and triggering payments. Keeper regularly initiates and participates in challenges to Providers. Its purpose is to verify whether Providers store data completely, that is, to verify the authenticity and honesty of Providers. According to the challenge results, we can get how much and how long data each Provider has effectively stored for the User during this period of time, which will be used as the basis for the User's later payment.

In addition, another important function of Keeper is to trigger payment for storage fees. The payment is not triggered by the payer User or the payer Provider, but the payment is triggered by the middleman Keeper. This is mainly for the consideration of increasing the fairness of the system. Triggering by the middleman Keeper can reduce the probability of fraudulent behavior.

​ Figure: Basic functions of Keeper

Keeper, as an intermediary, participates in the management of the system.Although it can solve the trust problem of the storage supply and demand of the distributed storage system to a certain extent, it is considered that Keeper itself may lack integrity, such as not challenging the storage of data on time and not on time. To trigger payment, Memo therefore designed punishment measures for the role. The existence of the punishment mechanism can ensure the good operation of the system and the healthy development of the community to a certain extent.

Therefore, the system stipulates that when the account is registered as a Keeper, a fee must be pledged. This fee can be refunded by the account, or it can be deducted when the account violates the system regulations. If the amount of the account pledge is insufficient, or there is no pledge deposit amount, then there is no good faith endorsement, the Keeper role of the account cannot be established.Regarding the amount of Keeper pledge, when to deduct the penalty and how much to deduct can be determined off-chain.

Usually, when an account severely violates the system regulations, a penalty will be given to the account. If a Keeper is unable to perform the space-time challenge of storing data on time, synchronize the result of the space-time challenge and report the result of the space-time challenge for a long time, then the system will ban the account. Once the account is banned, it will never become a Keeper again.

When Keeper is disabled, if the balance pledged by the Keeper is not 0, then the balance can be handled as follows: return to the account; transfer to the role manager who deploys the role contract; transfer to the Keeper who violates the system rules Other accounts affected include User, Keeper, and Provider.

Figure: Keeper's penalty mechanism

Provider is the party that provides storage space in the system. It provides storage services for the Users and obtains fees paid by the Users. After the Provider goes online, you need to explain your storage situation, which should include the available storage space, storage duration, and required storage unit price. After the Provider explains its own situation, Keeper can match according to the situation of both the User and the Provider, and then send the matched Provider information to the User, so that the User, Keepers, and Providers form a storage service.

Like Keeper, Provider also has the function of triggering payment, except that Keeper triggers the payment of storage fees, while Provider triggers the payment of download fees. This is because the verification of storage fees requires the participation of the intermediate manager Keeper, while the download fee is Verification does not require the participation of intermediate managers.

The penalties for breach of the Keeper mentioned above. For Provider, the system also designs rewards and punishments, because the Provider may have problems such as corrupted data but not recovering, long-term failure to respond to User download data requests or Keeper challenges.This will not only destroy the User's data, but also seriously affect the user experience.

Therefore, for the Provider role, it is also necessary to pledge a fee when applying for the role. Once the Provider violates the system rules, the system will trigger the corresponding penalty to deduct the pledge deposit amount.

From the perspective of system design, each role can gain something in the Memo system. Since User is the ultimate consumer, and the punishment measures are mainly for the collection role, that is, for Keeper and Provider, the realization of system role functions and the interaction between roles are realized through smart contracts, so the punishment is also realized by smart contracts. of.

The reason for adopting the contract-based penalty mechanism is: a decentralized system deployed in a low-credibility environment, there is no specific organizational decision, implementation of rewards and punishments, and the contract has all the terms and execution processes that are formulated in advance and are The advantage of being carried out under the absolute control of the computer. In addition, after the smart contract is compiled, it is deployed on the blockchain and executed by the virtual machine, and every node on the blockchain will run the process of the smart contract, so the execution process and execution of the smart contract can be realized that the result is distributed supervision and arbitration.

With the help of these advantages of smart contracts, the penalty mechanism for Provider and Keeper can be specified in the contract in advance. For the problem of who triggers the pledge deduction function of smart contracts, the available solutions are: triggered by User; triggered by Keeper; triggered by other Providers; or triggered by the role contract deployer.It is inappropriate for any role in the system to trigger the deduction of the pledge function of Provider and Keeper. The reason is that the three of them are related to each other in a storage service.Provider obtains revenue by storing data for User, and Keeper obtains revenue by helping User challenge verification data and collect information.Therefore, the power to trigger the deduction of pledge function should be transferred to an unrelated third party, that is, the role contract deployer, here called the contract manager Admin. The Admin deploys the penalty contract, which is also one of the checks and balances designed by the Memo system to achieve fair transactions.

The core application of the Memo system is a decentralized blockchain. In order to achieve fair transactions in a low-credibility environment, the system has designed corresponding functions for each role, storage demander (User), storage coordinator (Keeper), storage provider（Provider） providers interact with each other to form a system ecosystem. This article will elaborate on the node matching of the Memo system, that is, how does the User find a Provider that provides storage services for himself?

User is the final consumer of the system. Every storage service is initiated by User, and then Keeper and Provider provide services for it. In the role design article, we have mentioned that when the User proposes storage service requirements, the following elements should be included: storage space size, storage duration, and the number of providers and keepers.

Storage space size and storage duration are the most basic parameters. As for why the number of Providers and Keepers should be selected, it is because the Memo system uses object storage, and the off-chain maintenance of data uses data redundancy: multiple copies or corrections. Delete codes, so the more storage nodes, the safer the data.Because once the data on a storage node is lost, other storage nodes can help restore its data. In this decentralized cloud storage system, the more storage nodes there are, the smaller the probability of data damage or loss in all storage nodes.But the more storage nodes you choose, the higher the User's payment for storage services. Therefore, the User's requirements for storage services should also include the number of Providers. The User measures the cost and data security issues, and determines the number of storage node Providers.

Similarly, because Keeper needs to challenge the Provider in time and space, that is, through data verification technology, to check how much data the Provider correctly stores and the storage duration, multiple Keepers agree on the challenge result, and the consensus result serves as the basis for paying for the Provider's stored data.The number of Keepers will affect this storage service. The reason is: the more Keepers, the higher the cost of falsifying the challenge results, and the lower the probability that all Keepers are offline.

When the User proposes storage requirements, in addition to the basic parameters of storage space, storage duration, and the number of Providers and Keepers, some other parameters may also be set according to specific usage scenarios.

Because the integrity of each Provider may be different, some Providers can guarantee the normal storage of data every time and can be online for a long time, while some Providers cannot.Therefore, the reputation value of the Provider can also be selected according to the needs, which is derived from the performance of the Provider’s historical service.When Provide guarantees long-term online and normally stores data for User and actively responds to the challenge of Keeper, its reputation value will be higher. The higher the reputation, the greater the chance of matching with User in the future.

Similarly, for Keeper, in addition to the quantity requirements, the reputation value will also be involved. The User can also request the Keeper's reputation value when setting the parameters, because every consumer wants to cooperate with a partner with a high reputation.

In addition, the system should provide the Users with the function of specifying the price of storage services, such as how much money needs to be paid for each day of storage of 1MB of data. The specific storage unit price can be determined according to the actual use of the system.

In summary, the parameters that Users need to specify when seeking storage services include storage space size, storage duration, storage unit price, Keeper parameter requirements (such as the number of Keepers), and Provider parameter requirements (such as the number of Providers).

Figure: User's demand parameters

After the User sets the required parameters, Keeper will find the Provider connected to it according to the User's storage service requirements, and match the appropriate storage node.The specific situation of the matching operation is: after the Provider goes online, explain your own storage situation,which should include: available storage space, storage duration, and required storage unit price.Therefore, Keeper matches according to the situation of both parties, and then sends the matched Provider information to the User. Thus, User, Keepers, and Providers form a storage service.

For the problem of how Keeper matches according to the storage conditions of User and Provider, the first solution is:when the node is connected, User and Provider actively send their own storage service related information to Keeper; the second solution is: use smart contracts to record User’s storage requirements and Provider’s storage conditions on the chain. When connected to Keeper, Keeper directly receives View on the chain to match.Compared with the two solution, the first solution will increase the burden on the system network and lack of reviewability for subsequent storage services.The second solution records information in a smart contract, which has the characteristics of distributed supervision and non-tampering, and only Keeper querying information from the chain will not cause a network burden greater than that of the first solution, and it is also convenient for auditing, but the user and the provider need to bear the deployment of intelligence the cost of the contract.

Figure: Smart contract matching

Therefore, various parameter information related to the storage service will be recorded through the smart contract, including the User's demand parameters for the storage service and the storage service related parameters that the Provider can provide.It can be said that smart contracts run through the Memo system.

User puts forward storage requirements and pays for storage services; Keeper matches information between User and Provider, challenges Provider to verify its normal work, and obtains commission from User; Provider provides storage space, participates in the challenge, and obtains storage fee from User.

Step by step

Step 1: Environment Deployment

View Docker Installation section to install docker.

Step 2: Set up the node directory

Node home directory: ~/memo_user as an example:

Node data storage directory: ~/memo_user_data as an example.

The node home directory is the user directory and the node storage directory is the user node data storage directory.

Step 3: Pull image(User)

Step 4: Initialization（Create new wallet）

Explanation of parameters:

--password: Enter your user node password, the default is memoriae.

init: Execute the initialization command, which will generate your wallet address and generate a configuration file.

Step 5: Get wallet address

Explanation of parameters:

wallet default: Get the default wallet address

Step 6: Top up

Starting node needs both the Memo and cMemo token.

To get the cMemo token, there is one faucet,

This is the MemoChain information.

Memochain information

Chain RPC:

Currency name: CMEMO

Chain ID: 985

Chain browser:

To get Memo Tokens for your wallet, you can transfer some Memo Tokens from other wallet address which has enough Memo Tokens. The user needs minimum 1 Memo Tokens.

Join our discussing with Slack Link:

Step 7: Modify the configuration file

Step 8:Start node

• Default in web, account: admin; password: memoriae.

• Please make sure your user home directory and password are the same as in the previous step.

If you have any technical problems, please join our Discord server for help.

Check running status

Step 1: Enter the container

Step 2: Check user information

Check net status

Get local node network information

Command description: Enter command net info to view the network id (cid), ip address and port of the current node.

Get the network connection information of the node

Command description: Enter command net peers to view the network connection information of the current node.

Connect to any node

Command description: Enter command net connect to connect to any node; if there is any problem with your node network, please enter command net connect to connect to our public node.

Restart after poweroff

If the account has been started, and then the computer has been shutted down, Docker, or "Windows PowerShell" was been closed, if you need to restart MEMO again, you need to open Docker first, then run the command line " docker start mefs-user" to start.

Upload file

Command description: Entering putObject to upload an object named ObjectName into BucketName; if the bucket does not exist, it will display that the bucket does not exist; if the object already exists, it will display that the object already exists.

echo "hello MEMO" >~/test.file
mefs-user lfs putObject --bn=test2 --on=obj1 --path=~/test.file

Check file information

Command description: Enter listObjects to list all objects in BucketName, including object size, creation time, MD5 value, and the most recent challenge time.

Download file

Command description: Enter getObject to download an object named ObjectName from BucketName; if the bucket does not exist, it displays that the bucket does not exist; if the object does not exist, it displays that the object does not exist.

Create bucket

Command description: Enter createBucket to create a bucket according to the BucketName. Each bucket can be set with a different redundancy policy. The redundancy policy is multi-replica or erasure code. The redundancy level can be determined by adjusting the number of the data block and parity block. 3 data blocks and erasure code of 2 parity blocks are used by default, the loss of two blocks is tolerable.

mefs provides dedicated encrypted storage space (LFS) for each user, each storage space contains multiple buckets, buckets are containers that users use to store objects, and each bucket contains multiple objects. We can think of objects as files. The redundancy policy of a bucket can be specified at creation time (all objects stored in the bucket use this redundancy policy).

When creating a bucket policy, the value of dc+pc should be less than the number of providers in the group where the current user belongs. Users can modify the number of dc and pc according to their own needs.

Check bucket list

Command description: Enter listBuckets to display all buckets created by this user, including the name of each bucket, creation time, redundancy policy and redundancy parameters (DataCount, ParityCount).

Check bucket information

Command description: If BucketName exists, entering headBucket displays its creation time, redundancy policy and redundancy parameters. If BucketName does not exist, it displays that bucket does not exist.

Multiple users can share one mefs's running program.

After mefs is started, other users can also be started as a proxy.

Parameter explanation:

Mefs commands can all be operated using HTTP.

Configuration

Before mefs-user starts, confirm the following configuration is set in the config.json:

Then restart mefs-user to use HTTP to operate.

Usage

A command similar to the following:

The corresponding HTTP request is:

IP is the network address of the machine where mefs-user is started. The port defaults to 5001. If cross-domain access is configured before running, you can use the external network IP to access, otherwise you can only access it through 127.0.0.1.

This document is detailed about how to use user node, the installation guide is in another document. Use LFS command to operate upload and download functions.

Introduction

This command creates, uploads, downloads, and views a collection of containers and files for the user.

Usage

Step 1: Environment Deployment

View Docker Installation section to install docker.

Windows install Docker：

1、

2、Download docker for windows

Docker:

How to install Docker in Linux(Ubuntu)：

Do you want to earn income from unused storage space and bandwidth?

If you have spare storage space and bandwidth and want to make some profit from it, you can participate in Memo as a provider.

Disconnection problems

Performance after disconnection

1. When the keeper challenges the provider, it is found that the provider cannot be connected. The challenge is over and continues to the next one. The provider initiates a challenge and the cycle repeats. Therefore, the avail time value of the data on the provider will not be updated.

2. Keeper will regularly check the online status of other keepers and providers every 5min. If the network is disconnected for more than 1h, set it. The online status is false, and its credit value is reduced by 1, and the initial value of the credit is 0.

3. If the credit value of the provider is less than 0, it cannot be matched to the user again to form the storage service. Providers with credit less than 0 can. To choose to perform well in this storage service, to improve the credit value, to continue to participate in the storage service next time.

4. Keeper will make repair statistics every 7min. If the difference between the avail time and now time of the data block exceeds a certain time, The data block will be listed as the data block to be repaired.

5. Before repairing, if the credit value of the provider to which the data block to be repaired belongs is less than -50, or the provider cannot be connected, look for it. A new provider to replace the fixtures. Therefore, the disconnected provider has no corresponding challenge results and cannot get the storage revenue during the disconnection. If the network is disconnected too many times, Then for this provider, the data challenged during network disconnection will be repaired to other providers, and the provider will never be used. Will get the benefits of this part of the data again.

No real data is stored, and the performance after a network disconnection

The keeper will challenge every 5min and trigger spatiotemporal payment every 5min. The spatiotemporal payment interval is 2h, but the contract will be delayed payment by 3 days to pay.

• No bucket created: no challenge, no gain, no punishment, and the credit remains unchanged.

• If a bucket is created but no data is stored in it: no challenge will be initiated, as above.

If the user stores data in the bucket during the disconnection of the provider, if there are not enough online providers, it will keep searching circularly online provider.

Stored real data, performance after a network disconnection

After the network is disconnected, when the keeper challenges the provider, it finds that the provider cannot be connected. The challenge ends and continues to the next provider.

The provider initiates a challenge and the cycle repeats.

Therefore, the disconnected provider has no corresponding challenge results and cannot get the storage revenue during the disconnection.

Payment and punishment

(1) When the keeper and provider are in normal service, can the keeper and provider get the information relative to the storage time and space, Storage service fee payable;

(2) When the provider is in normal service if the user downloads data, can the provider get the pending payment corresponding to the amount of downloaded data, Fee signature;

(3) In case of problems with the keeper or provider, test whether the system can reduce the credit value and storage contribution, Penalty for deducting the pledged amount;

Provider revenue

1. Ensure that users in mefs-provider info users have signed up for the provider.

2. User has uploaded data to the provider, which can be downloaded from /root/.mefs/data to see if there is a file named by the node ID, Pieces with data.

The provider started without the user signing

View by mefs-provider info users

1. Provider has mapped IP + port.

2. User signing up with provider randomly.

3. No user-added when the provider started.

1 Preface

This article will introduce in detail the use of the command line function of the keeper-Node of the MEMO system; the keeper needs to download the binary and execute the program 'mefs-keeper' to start a Memo keeper-Node.

Usage

Use the following command to view all commands

Introduction

Used to create a wallet in the specified path. If the wallet information already exists in this path, the existing wallet will be used directly without recreating the wallet. Assign the MEFS_PATH environment virable to specify a path for this node.

Usage

Options

Example

The example sets the root directory of the node to: ~/.memo-keeper

Introduction

The command is used to start and stop an keeper-Node

Usage

Options

Example

Introduction

This command implements the related functions of operating the wallet.

Usage

Subcommands

Introduction

Create a new wallet address

Introduction

View all wallet addresses default Display

Introduction

View the default wallet address

Example

Introduction

Export the wallet's private key

Example

Parameter wallet-address is the wallet address of the node.

Introduction

This command is used to modify the configuration file, which takes effect only when the node is not started; if the config is modified while the node is running, the node needs to be restarted to make it take effect;

The path where the configuration file is located: config.json in the root directory of the node which is specified when init the node.

Usage

Subcommands

Introduction

The set subcommand is used to set the value of the specified option in the configuration file

Usage

Options

Example

Configure the value of contract.endPoint

Introduction

This command is used to get the value of the specified configuration item

Usage

Example

Get the contract.endPoint value

Introduction

This command is used to set the bootstrap node in the configuration file, multiple bootstrap nodes can be added.

Usage

Subcommands

Introduction

View the current node bootstrap node list

Introduction

Add a bootstrap node

Example

Introduction

clear the bootstrap node

Introduction

Network related commands

Usage

Subcommands

Introduction

This command checks node network information

Usage

Example

'12D3K...' here is the peerID of this node.

Introduction

Show the network information of all nodes currently connected.

Usage

Introduction

This command connects to a specified node manually.

Usage

Note

About how to construction the multiaddr for a node.

First use the net info command to view the network information of the node.

And the multiaddr of this node is:

Introduction

View node information according to peerID, command usage:

Usage

Example

Introduction

Used for the keeper node to declare its own public network ip address; (only the keeper node needs to use this command)

Usage

Introduction

This command interacts with state db to obtain pay and penalty information about this node, or settle current income of this node.

Usage

Subcommands

This command is used to read from state db to get the payment and penalty information of storage orders between user and provider nodes.

This command is used to read from state db to show the current balance in fs and in memo token.

This command is used for provider nodes to settle the current storage income.

Introduction

View commands for connected nodes

Introduction

This command is used to list connected roles

Usage

Introduction

This command checks the basic information of this node

Usage

Options

Example

or

Introduction

Node pledge, withdrawal and other operations.

Usage

Subcommands

Note

About parameter 'amount' in subcommands

Quotes should be used for the amount parameter, and there must be a space between the amount and the unit. The unit is not case-sensitive. It can be Memo, NanoMemo, AttoMemo. The relationship between them is: 1 Memo=10^9 NanoMemo=10 ^ 18 AttoMemo

Introduction

Used to set the description for a node.

Introduction

Used to pledge some Memo for this node. Efficiant amount of Memo in wallet is required.

Usage

Example

To pledge 1 Memo for this node.

Introduction

View the current pledge amount.

Example

Introducton

Take out some pledged Memo from pledge balance to fs balance.

Example

Withdraw the pledge of 0.5 Memo to the Fs account

Introduction

pledgeRewardWithdraw Withdraw the pledge income to the FS file system.

Example

Withdraw 0.5Memo of pledge reward to Fs account

Introduction

withdraw Take out the token of the file system to the (Erc20) wallet

Example

Take out 0.5memo of the Fs file system to the (Erc20) wallet

Introduction

This command makes the node exit the current role. Wallet address and the balance in it is not effected.

Caution

Role-related functions will no longer be available at this time. However, the wallet balance will not be affected. For keepers and keepers, the role pledge amount provided when registering the role can be withdrawn after run quitRole.

Example

Introduction

alterPayee used to change the current payee.

Introduction

View current node version

Usage

Introduction

It is used to repair the db as much as possible when the node starts abnormally. Warning: Do not exit the node abnormally. When you want to exit the node, you should use the daemon stop command to exit normally. Failure to do so may result in db corruption beyond repair

Usage

Example

Repair state database

Introduction

Used when the node is down. Import/export state (or meta) database.

Subcommands

Introduction

Export the state database to a file, using the following method:

Usage

Example

Export the state database to the current directory

Introduciton

To import a database from a file, use the following method:

Usage

Example

import state database

Introduction

The keeper node sets the whitelist function. When creating a bucket, the nodes in the whitelist are given priority.

Usage

Subcommands

Introduction

View whitelist node

Example

View the nodes in the whitelist

Introduction

Add whitelist node

Example

Add keeper node to whitelist

The parameter PID is the keeper node ID to be added to the whitelist

Introduction

delete whitelist node

Example

Delete whitelist nodes

The parameter PID is the keeper node ID to be added to the whitelist

Introduction

Check whether the node is in the whitelist

Example

Check whether the node is in the current whitelist

mefs-keeper restrict has PID The parameter PID is the keeper node ID to be added to the whitelist

Introduction

Set whitelist status

Example

Enable the whitelist function

Turn off the whitelist function

Introduction

Check whitelist status

Example

Check whitelist status

Introduction

Query the value of the token file of the node. The token file is located in the root directory of the node. Ordinary keepers do not need to pay attention to this value.

Usage

Introduction

This command is used to set the log level. Different levels display log information of different alarm levels. The default is info level, which only displays normal status information. Ordinary keepers should use info log level. The debug/warn/error level is used by developers to view detailed error logs. This level will generate a large number of logs and cannot be in debug mode for a long time, otherwise it will take up a lot of disk space. It is not recommended for ordinary keepers to use.

Subcommands

Usage

Example

1 Preface

This article will introduce in detail the use of the command line function of the provider-Node of the MEMO system; the provider needs to download the binary and execute the program 'mefs-provider' to start a Memo provider-Node.

Usage

Use the following command to view all commands

Introduction

Used to create a wallet in the specified path. If the wallet information already exists in this path, the existing wallet will be used directly without recreating the wallet. Assign the MEFS_PATH environment virable to specify a path for this node.

Usage

Options

Example

The example sets the root directory of the node to: ~/.memo-provider

Introduction

The command is used to start and stop an provider-Node

Usage

Options

Example

Introduction

This command implements the related functions of operating the wallet.

Usage

Subcommands

Introduction

Create a new wallet address

Introduction

View all wallet addresses default Display

Introduction

View the default wallet address

Example

Introduction

Export the wallet's private key

Example

Parameter wallet-address is the wallet address of the node.

Introduction

This command is used to modify the configuration file, which takes effect only when the node is not started; if the config is modified while the node is running, the node needs to be restarted to make it take effect;

The path where the configuration file is located: config.json in the root directory of the node which is specified when init the node.

Usage

Subcommands

Introduction

The set subcommand is used to set the value of the specified option in the configuration file

Usage

Options

Example

Configure the value of contract.endPoint

Introduction

This command is used to get the value of the specified configuration item

Usage

Example

Get the contract.endPoint value

Introduction

This command is used to set the bootstrap node in the configuration file, multiple bootstrap nodes can be added.

Usage

Subcommands

Introduction

View the current node bootstrap node list

Introduction

Add a bootstrap node

Example

Introduction

clear the bootstrap node

Introduction

Network related commands

Usage

Subcommands

Introduction

This command checks node network information

Usage

Example

'12D3K...' here is the peerID of this node.

Introduction

Show the network information of all nodes currently connected.

Usage

Introduction

This command connects to a specified node manually.

Usage

Note

About how to construction the multiaddr for a node.

First use the net info command to view the network information of the node.

And the multiaddr of this node is:

Introduction

View node information according to peerID, command usage:

Usage

Example

Introduction

Used for the provider node to declare its own public network ip address; (only the provider node needs to use this command)

Usage

Introduction

This command interacts with state db to obtain pay and penalty information about this node, or settle current income of this node.

Usage

Subcommands

This command is used to read from state db to show the payment and penalty information of storage orders between user and provider nodes.

This command is used to read from state db to show the current balance in fs and in memo token.

This command is used for provider nodes to settle the current storage income.

Introduction

View commands for connected nodes

Introduction

This command is used to list connected roles

Usage

Introduction

This command checks the basic information of this node

Usage

Options

Example

or

Introduction

Node pledge, withdrawal and other operations.

Usage

Subcommands

Note

About parameter 'amount' in subcommands

Quotes should be used for the amount parameter, and there must be a space between the amount and the unit. The unit is not case-sensitive. It can be Memo, NanoMemo, AttoMemo. The relationship between them is: 1 Memo=10^9 NanoMemo=10 ^ 18 AttoMemo

Introduction

Used to set the description for a node.

Introduction

Used to pledge some Memo for this node. Efficiant amount of Memo in wallet is required.

Usage

Example

To pledge 1 Memo for this node.

Introduction

View the current pledge amount.

Example

Introducton

Take out some pledged Memo from pledge balance to fs balance.

Example

Withdraw the pledge of 0.5 Memo to the Fs account

Introduction

pledgeRewardWithdraw Withdraw the pledge income to the FS file system.

Example

Withdraw 0.5Memo of pledge reward to Fs account

Introduction

withdraw Take out the token of the file system to the (Erc20) wallet

Example

Take out 0.5memo of the Fs file system to the (Erc20) wallet

Introduction

This command makes the node exit the current role. Wallet address and the balance in it is not effected.

Caution

Role-related functions will no longer be available at this time. However, the wallet balance will not be affected. For providers and keepers, the role pledge amount provided when registering the role can be withdrawn after run quitRole.

Example

Introduction

alterPayee used to change the current payee.

Introduction

View current node version

Usage

Introduction

View order related information

Usage

Subcommands

Introductoion

List all users who has data stored in this provider.

Usage

Introductoion

List all order status with provider nodes

Usage

Introduction

It is used to repair the db as much as possible when the node starts abnormally. Warning: Do not exit the node abnormally. When you want to exit the node, you should use the daemon stop command to exit normally. Failure to do so may result in db corruption beyond repair

Usage

Example

Repair state database

Introduction

Used when the node is down. Import/export state (or meta) database.

Subcommands

Introduction

Export the state database to a file, using the following method:

Usage

Example

Export the state database to the current directory

Introduciton

To import a database from a file, use the following method:

Usage

Example

import state database

Introduction

The provider node sets the whitelist function. When creating a bucket, the nodes in the whitelist are given priority.

Usage

Subcommands

Introduction

View whitelist node

Example

View the nodes in the whitelist

Introduction

Add whitelist node

Example

Add provider node to whitelist

The parameter PID is the provider node ID to be added to the whitelist

Introduction

delete whitelist node

Example

Delete whitelist nodes

The parameter PID is the provider node ID to be added to the whitelist

Introduction

Check whether the node is in the whitelist

Example

Check whether the node is in the current whitelist

mefs-provider restrict has PID The parameter PID is the provider node ID to be added to the whitelist

Introduction

Set whitelist status

Example

Enable the whitelist function

Turn off the whitelist function

Introduction

Check whitelist status

Example

Check whitelist status

Introduction

Query the value of the token file of the node. The token file is located in the root directory of the node. Ordinary providers do not need to pay attention to this value.

Usage

Introduction

This command is used to set the log level. Different levels display log information of different alarm levels. The default is info level, which only displays normal status information. Ordinary providers should use info log level. The debug/warn/error level is used by developers to view detailed error logs. This level will generate a large number of logs and cannot be in debug mode for a long time, otherwise it will take up a lot of disk space. It is not recommended for ordinary providers to use.

Subcommands

Usage

Example

1 Preface

This article will introduce in detail the use of the command line function of the User-Node of the MEMO system; the user needs to download the binary and execute the program 'mefs-user' to start a Memo User-Node.

Usage

Use the following command to view all commands

Introduction

Used to create a wallet in the specified path. If the wallet information already exists in this path, the existing wallet will be used directly without recreating the wallet. Assign the MEFS_PATH environment virable to specify a path for this node.

Usage

Options

Example

The example sets the root directory of the node to: ~/.memo-user

Introduction

The command is used to start and stop an User-Node

Usage

Options

Example

Introduction

This command implements the related functions of operating the wallet.

Usage

Subcommands

Introduction

Create a new wallet address

Introduction

View all wallet addresses default Display

Introduction

View the default wallet address

Example

Introduction

Export the wallet's private key

Example

Parameter wallet-address is the wallet address of the node.

Introduction

View the bucket/object password for uploading. The enc mode is set when upload object. If enc mode is set to aes1, then bucket password is selected for uploading, on the other hand, if enc mode is set to aes2, then object password is selected for uploading. Right password should be used for downloading encrypted objects.

--enc: encrypt mode, aes1 for using bucket password, aes2 for using object password.

Note: If the password is set for a bucket, the objectID and StripeID should be set to 0. If the passwrod is set for an object, the stripeID should be set to 0.

Example

Check the aes1 mode uploading password.

Introduction

This command is used to modify the configuration file, which takes effect only when the node is not started; if the config is modified while the node is running, the node needs to be restarted to make it take effect;

The path where the configuration file is located: config.json in the root directory of the node which is specified when init the node.

Usage

Subcommands

Introduction

The set subcommand is used to set the value of the specified option in the configuration file

Usage

Options

Example

Configure the value of contract.endPoint

Introduction

This command is used to get the value of the specified configuration item

Usage

Example

Get the contract.endPoint value

Introduction

This command is used to set the bootstrap node in the configuration file, multiple bootstrap nodes can be added.

Usage

Subcommands

Introduction

View the current node bootstrap node list

Introduction

Add a bootstrap node

Example

Introduction

clear the bootstrap node

Introduction

This command is used to start the gateway for an user node, and it can only be successfully accessed after the node synchronization is completed.

Usage

Subcommands

Introduction

starts the gateway

Usage

Options

Example

Introduction

stops the Gateway

Introduction

This command first registers a MEMO system account ID for the wallet address, then registers the wallet account as a specified role (User, Keeper, user), and finally adds the role to the specified group;

Note: daemon startDuring the start-up process of the User node call, the account id, registration role, and joining the group will be automatically generated according to the parameters specified;

Usage

Options

Example

Introduction

Network related commands

Usage

Subcommands

Introduction

This command checks node network information

Usage

Example

'12D3K...' here is the peerID of this node.

Introduction

Show the network information of all nodes currently connected.

Usage

Introduction

This command connects to a specified node manually.

Usage

Note

About how to construction the multiaddr for a node.

First use the net info command to view the network information of the node.

And the multiaddr of this node is:

Introduction

View node information according to peerID, command usage:

Usage

Example

Introduction

Used for the user node to declare its own public network ip address; (only the user node needs to use this command)

Usage

Introduction

This command interacts with state db to obtain pay and penalty information about this node, or settle current income of this node.

Usage

Subcommands

This command is used to read from state db to get the payment and penalty information of storage orders between user and provider nodes.

This command is used to read from state db to show the current balance in fs and in memo token.

This command is used for provider nodes to settle the current storage income.

Introduction

View commands for connected nodes

Introduction

This command is used to list connected roles

Usage

Introduction

This command checks the basic information of this node

Usage

Options

Example

or

Introduction

Node pledge, withdrawal and other operations.

Usage

Subcommands

Note

About parameter 'amount' in subcommands

Quotes should be used for the amount parameter, and there must be a space between the amount and the unit. The unit is not case-sensitive. It can be Memo, NanoMemo, AttoMemo. The relationship between them is: 1 Memo=10^9 NanoMemo=10 ^ 18 AttoMemo

Introduction

Used to set the description for a node.

Introduction

Used to pledge some Memo for this node. Efficiant amount of Memo in wallet is required.

Usage

Example

To pledge 1 Memo for this node.

Introduction

View the current pledge amount.

Example

Introducton

Take out some pledged Memo from pledge balance to fs balance.

Example

Withdraw the pledge of 0.5 Memo to the Fs account

Introduction

pledgeRewardWithdraw Withdraw the pledge income to the FS file system.

Example

Withdraw 0.5Memo of pledge reward to Fs account

Introduction

withdraw Take out the token of the file system to the (Erc20) wallet

Example

Take out 0.5memo of the Fs file system to the (Erc20) wallet

Introduction

This command makes the node exit the current role. Wallet address and the balance in it is not effected.

Caution

Role-related functions will no longer be available at this time. However, the wallet balance will not be affected. For providers and keepers, the role pledge amount provided when registering the role can be withdrawn after run quitRole.

Example

Introduction

alterPayee used to change the current payee.

Introduction

View current node version

Usage

Introduction

View order related information

Usage

Subcommands

Introduction

List all task information

Usage

Introductoion

List all order statuses with provider nodes

Usage

Introduction

List all provider status information

Usage

Introduction

View the order information of the specified provider

Usage

Example

Introduction

View order details

Usage

Introduction

This command creates, uploads, downloads, and views a collection of containers and files for the user.

Usage

Subcommands

Introduction

This command creates buckets

Usage

Options

Example

Bucket name: test, storage policy: erasure code, number of data blocks: 10, number of check blocks 5

Introduction

This command is used to view the status of all buckets

Usage

Introduction

This command is used to view all the information of the specified bucket, the following is an example (test is the bucket name)

Usage

Introduction

This command specifies the file for upload

Usage

USAGE: mefs-user lfs putObject [command options] [arguments...]

OPTIONS: --bucket value, --bn value use bucket name --object value, --on value file name after upload --path value upload file path --etag value select verification method (default: md5) --enc value Select encryption method (default: aes) --help, -h View help

Introduction

This command is used to view the specified file status

Usage

Example

Introduction

Download the file to the specified path

Usage

Note

--etag option here can be substituted by cid or md5, all of them has the same meaning. If bucket password is used(aes1 is set when putObject), the value of --objectID is ommited.

--decrypt option is the bucket/object password set when putObject.

Example 1

Download an object without etag.

Example 2

Download an object with etag and password.

./mefs-user lfs getObject --md5 f1c9645dbc14efddc7d8a322685f26eb --userID 36 --bucketID 0 --objectID 1 --decrypt 09a74f0cd7ff9d098f1753a83ed523d0c16b79ca2ce9ca5b5459ffada7e2376c --path aa

Introduction

View all file information of a specified bucket

Usage

Example

Introductioin

delete specified file

Usage

Example

Introduction

Download objects using rpc

Usage

Example

Introduction

Display the storage information of the node

Introduction

View the bucket user list

Introduction

It is used to repair the db as much as possible when the node starts abnormally. Warning: Do not exit the node abnormally. When you want to exit the node, you should use the daemon stop command to exit normally. Failure to do so may result in db corruption beyond repair

Usage

Example

Repair state database

Introduction

Used when the node is down. Import/export state (or meta) database.

Subcommands

Introduction

Export the state database to a file, using the following method:

Usage

Example

Export the state database to the current directory

Introduciton

To import a database from a file, use the following method:

Usage

Example

import state database

Introduction

The user node sets the whitelist function. When creating a bucket, the nodes in the whitelist are given priority.

Usage

Subcommands

Introduction

View whitelist node

Example

View the nodes in the whitelist

Introduction

Add whitelist node

Example

Add user node to whitelist

The parameter PID is the user node ID to be added to the whitelist

Introduction

delete whitelist node

Example

Delete whitelist nodes

The parameter PID is the user node ID to be added to the whitelist

Introduction

Check whether the node is in the whitelist

Example

Check whether the node is in the current whitelist

mefs-user restrict has PID The parameter PID is the user node ID to be added to the whitelist

Introduction

Set whitelist status

Example

Enable the whitelist function

Turn off the whitelist function

Introduction

Check whitelist status

Example

Check whitelist status

Introduction

Query the value of the token file of the node. The token file is located in the root directory of the node. Ordinary users do not need to pay attention to this value.

Usage

Introduction

This command is used to set the log level. Different levels display log information of different alarm levels. The default is info level, which only displays normal status information. Ordinary users should use info log level. The debug/warn/error level is used by developers to view detailed error logs. This level will generate a large number of logs and cannot be in debug mode for a long time, otherwise it will take up a lot of disk space. It is not recommended for ordinary users to use.

Subcommands

Usage

Example

In the < storage dir >/.mefs directory, there are startup log daemon.stdout.xx and the running log in the logs directory;

Through the running log, you can view the running status of the node; when an error occurs, you can view the startup log;

Step 1 Download Installer

Download url：

Error when starting the new user image

Error:strconv.ParseInt: parsing "": invalid syntax

The -e FS = 0 parameter needs to be added during startup.

Performance after disconnection

1. When the keeper challenges the provider, it is found that the provider cannot be connected. The challenge is over and continues to the next one. The provider initiates a challenge and the cycle repeats. Therefore, the avail time value of the data on the provider will not be updated.

2. Keeper will regularly check the online status of other keepers and providers every 5min. If the network is disconnected for more than 1h, set it. The online status is false, and its credit value is reduced by 1, and the initial value of the credit is 0.

For users, there are following differences in use experience of Phecda and Megrez.

Node deployment

Phecda: Connect directly in all started nodes after node startup.

Megrez: The group function is added to each role. Users can choose which group to join when they start the user and provider nodes.

What are the account and private key?

The private key and account address used by mefs is the same as the Ethereum, and the format is 0x...;

What is the role?

Mefs contains 3 roles: user, keeper, and provider; currently each account address corresponds to a role; During startup, different services are started according to the role type in the contract.

Account address and network address

After starting mefs, there will be two addresses: account address and network address; the account address format is 0x..., the network address format is 8M...; These two addresses are actually equivalent, one for interacting with the chain, and one for network connection.

How to check my balance?

Run mefs-user/keeper/provider test showBalance in the command line to view the balance of the running account, the unit is wei;

Where is the mefs directory? What's included?

`mefs-user/keeper/provider init will create config, data, datastore, keystore and other directories and files in the corresponding directories according to the MEFS_PATH variable; For the directory that has been initialized, if you run mefs-user/keeper/provider init again, an error message will prompt you; If you want to modify the directory, set MEFS_PATH before running mefs-user/keeper/provider init; The Keystore uses a password to store the private key; Data directory stores the content of the data block, and the user's data is finally stored in the Data directory in the form of data blocks;

How to check the local account address?

Run mefs-user/keeper/provider id to see the local account address 0x...

How to check the version of mefs?

Run `mefs-user/keeper/provider version to see the version number of mefs.

How can I check my role?

During the startup process of mefs daemon, you can view the output prompt information; You can also run mefs-user/keeper/provider test localinfo to view your own role during operation.