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.

Method 2:

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".

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：

Build an Autonomous Storage System: Role Design in Memoriae

Memoriae System Node Matching

Technology：

Multilevel Fault-tolerant Mechanism Design for MEMO Decentralized Cloud Storage System

MEMO Original Data Recovery Strategy: Risk-Aware Failure Identification (RAFI)

❓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.

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?

Memoriae — Next Generation of Decentralized Cloud Storage Based on Blockchain

Roles：

Build an Autonomous Storage System: Role Design in Memoriae

Memoriae System Node Matching

Technology：

Multilevel Fault-tolerant Mechanism Design for MEMO Decentralized Cloud Storage System

MEMO Original Data Recovery Strategy: Risk-Aware Failure Identification (RAFI)

Sign up for Auth Token

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 sup@memolabs.org 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)

Interactive Forum

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

Our GITHUB URL is:

https://github.com/memoio/testnet/issues

Our TWITTER URL is:

https://twitter.com/Memo_Labs

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.

Compared with Other Blockchain Storage Projects, What Is Special about MEMO?

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'.

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.

Time and space payment

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.

Delayed payment and partial payment

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.

Trigger payment-verification passed

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.

Download payment

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.

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.

Documentation on the use of the pledge function (example for the user, same for other nodes)

Note

The following commands are executed only if the MEFS_PATH environment variable has been set to the root directory of the node, using the user as an example:

In the linux environment, the default root directory of the node is ~/.memo-user, set the root directory with the command below

MEFS_PATH=~/.memo-user

In the windows environment, the default root directory of the node is c:\memouser, set the root directory with the command below

set MEFS_PATH=c:\memouser

MEMO unit conversions：

1 Memo= 10^9 NanoMemo = 10^18 AttoMemo

Pledge operation

First check the node info panel to confirm that the current ERC20 balance is sufficient for pledging.

When you have confirmed that the ERC20 balance is sufficient, you can proceed with the pledge operation.

Pledge 1000 NanoMemo to the pledge pool:

mefs-user settle pledgeAdd "1000 NanoMemo"

After run the command, you can see that the pledge amount has increased by 1000 NanoMemo.

Check the current pledge amount

mefs-user settle pledgeGet

Extracts MEMO from the pledge pool to the FS pool

mefs-user settle pledgeWithdraw "1000 NanoMemo"

Caution: The pleged MEMOs can not be extracts from the pledge pool before 180 days.

Move memo from Fs file system to wallet

mefs-user settle withdraw "1000 NanoMemo"

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.

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 .

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

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;

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:

export MEFS_PATH=~/memo_user

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

export MEFS_DATA=~/memo_user_data

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)

docker pull memoio/mefs-user:latest

Step 4: Initialization（Create new wallet）

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-user memoio/mefs-user:latest init --password=memoriae

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

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-user memoio/mefs-user:latest wallet default

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, https://faucet.metamemo.one/

This is the MemoChain information.

Memochain information

Chain RPC: https://chain.metamemo.one:8501/

Currency name: CMEMO

Chain ID: 985

Chain browser: https://scan.metamemo.one:8080/

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:

https://join.slack.com/t/memo-nru9073/shared_invite/zt-sruhyryo-suc689Nza3z8boa4JkaLqw

Step 7: Modify the configuration file

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-user memoio/mefs-user:latest config set --key=contract.version --value=3

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-user memoio/mefs-user:latest config set --key=contract.endPoint --value="https://chain.metamemo.one:8501"

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-user memoio/mefs-user:latest config set --key=contract.roleContract --value="0xbd16029A7126C91ED42E9157dc7BADD2B3a81189"

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-user memoio/mefs-user:latest bootstrap clear

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-user memoio/mefs-user:latest bootstrap add "/ip4/183.240.197.189/tcp/14006/p2p/12D3KooWAMpZPwfJopVnp99oqp4zhbjE1G3LFAkcjfBuiyzyCmv7"

Step 8:Start node

docker run -d -v $MEFS_PATH:/root -v $MEFS_DATA:/root/data -e PASSWORD="memoriae" -e PRICE=250000 -e MEFS_PATH=/root/.memo-user -e GROUP=3 -e SWARM_PORT=4001 -e DATA_PATH=/root/data --name mefs-user -e GATEWAY=true -e GATEWAY_USERNAME=admin -e GATEWAY_PASSWORD=memoriae -p 8080:8080 memoio/mefs-user:latest

• 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. https://discord.gg/YXQQwPhMpq

Check running status

Step 1: Enter the container

docker exec -it mefs-user bash

Step 2: Check user information

mefs-user info

----------- Information -----------        
2022-03-23 10:42:36 CST		#Current time
2.1.0-alpha+git.e759ff0+2022-03-22.15:51:16CST		#mefs-user version information
----------- Network Information -----------		#network information
ID:  12D3KooWBpPPzk9srHVVU4kkVF1RPJi9nYNgV4e6Yjjd4PGr5qrk   #network id
IP:  [/ip4/10.2.2.61/tcp/18003]  #Current node network information, 18003 is the swarm-port port, used for node communication
Type: Private
----------- Sync Information -----------		
Status: true, Slot: 322885, Time: 2022-03-23 10:42:30 CST	#Please check if your sync status is true, if it is false, please check your node network
Height Synced: 2640, Remote: 2640		#sync status
Challenge Epoch: 21 2022-03-23 09:55:30 CST		 
----------- Role Information -----------		
ID:  29		
Type:  User		
Wallet:  0xD2EC305EA80C6FCEF315029A806f52F27f3fB29a		#Wallet address
Balance: 998.25 Gwei (tx fee), 998815392.06 NanoMemo (Erc20), 148075.99 NanoMemo (in fs)		#balance
Data Stored: size 115294208 byte (109.95 MiB), price 113500000
----------- Group Information -----------		
EndPoint:  http://119.147.213.220:8191		
Contract Address:  0xCa2C4103bd5679F43eC9E277C2bAf5598f94Fe6D		 
Fs Address:  0xFB9FF16EB4093aa8fFf762F2dF4E61d3A7532Af9		
ID:  1		#group id
Security Level:  7
Size:  109.95 MiB		 
Price:  113500000		
Keepers: 10, Providers: 16, Users: 4		#The number of nodes in the current group
----------- Pledge Information ----------		
Pledge: 0 AttoMemo, 26.00 Memo (total pledge), 26.00 Memo (total in pool)		#current pledge information			
----------- Lfs Information ----------		
Status: writable
Buckets:  1
Used: 1.82 GiB
Raw Size: 109.95 MiB
Confirmed Size: 109.95 MiB
OnChain Size: 109.95 MiB
Need Pay: 987173.29 NanoMemo
Paid: 987173.29 NanoMemo

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.

mefs-user net info

Network ID 12D3KooWBpPPzk9srHVVU4kkVF1RPJi9nYNgV4e6Yjjd4PGr5qrk, IP [/ip4/10.2.2.61/tcp/18003], Type: Private

Get the network connection information of the node

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

mefs-user net peers

12D3KooWMrZTqoU8febMxxxxxxxxxCeqLQy1XCU9QcjP1YWAXVi [/ip4/10.2.2.66/tcp/8003]
12D3KooWC2PmhSrU1VexxxxxxxxxtwvQuFZj3vPfjdfebAuJQtc [/ip4/10.2.2.66/tcp/8004]
12D3KooWR74K1v6naGxxxxxxxxxVS88h4X93bMnquoRiEDdLJTx [/ip4/10.2.2.61/tcp/8003]
12D3KooWSzzwJ7es1xxxxxxxxxPaqei3TUHnNZDmWTELSA7NJXQ [/ip4/10.2.2.62/tcp/18003]
12D3KooWG8PjbbN9xxxxxxxxx2oYFtjeQ8XnqvnEqfrB4AiW7eJ [/ip4/10.2.2.65/tcp/8003]
12D3KooWRjamwQtxxxxxxxxxb44AAXLNy9CB7u1FL2eC5QZekpF [/ip4/1.182.0.0/tcp/24071]
...

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.

mefs-user net connect /ip4/10.2.x.x/tcp/8004/p2p/12D3KooWAykMmqu951ziotQiAYTN6SwfvBd1dsejSSak2jdSwryF

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.

docker start mefs-user

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.

Startup time

Megrez node startup time is way shorter than Phecda node startup time.

User Experience - Command Line

● Megrez optimized the command line on the basis of Phecda, and added new commands such as querying wallet address through the command line.

●User simplified command.

●Storage order status of the specified user can be viewed.

●Token situation is increased, there can be multiple tokens.

Step 1 Download Installer

Download url：https://github.com/memoio/go-mefs-release/releases/

Step 2 Unzip Package

Unzip mefs-user-install.zip

Step 3 Install

Enter "mefs-user-install" file folder, double click install.exe for regestering user.

Step 4 Check Account Address

After successfully registered user, you can see the content of installation directory as follows:

Open “account.txt.” It will contain your wallet address and created password as shown below.

Contact the Memolabs team to recharge your wallet with some tokens before proceeding to the next stage.

Step 5 Top Up

Starting node needs both the Memo and cMemo token.

To get the cMemo token, there is one faucet, https://faucet.metamemo.one/

This is the MemoChain information.

Memochain information

Chain RPC: https://chain.metamemo.one:8501/

Currency name: CMEMO

Chain ID: 985

Chain browser: https://scan.metamemo.one:8080/

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:

https://join.slack.com/t/memo-nru9073/shared_invite/zt-sruhyryo-suc689Nza3z8boa4JkaLqw

If you want to check the account balance,Please refer to this link

How to checking the account balance

Step 6

When your installation completed, the content of installation folder is as follows:

Mmeanwhile there are 2 more icons appeared on your desktop.

The running window will show that user node is starting, and data is being synchronized. This will take about 5 hours to complete, please be patient.

Step 7 Check Running Status

Now you can see two "mefs-user.exe" in the task manager shows the user node and gateway is running.

Step 8 Using User with Webui

Open URL http://127.0.0.1:9090 in your web browser to use user WebUI

Open the account.txt in the memouser folder to view your login imformation

Create bucket

Caution: If this is the first run of your User node, you need to wait about 10~20 minutes for node to complete synchronization. If sync is not complete yet, you will get a "lfs service is read only" error.

After that you can begin create bucket.

Upload file

Caution: When a new bucket is created, it needs about 2 minutes to be confirmed. So wait a moment before you start to upload files into a new bucket.

Download file

Stop User

You can stop user node with following 2 methods. But this just closes node service, the gateway service is not closed, you have to manually close it in the task manager for now.

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

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.

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.

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.

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 MEMO testnet “Megrez” global public beta is going to launch soon

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

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.

Recommended configuration：

• 8 cores, 16G memory, 2TB storage, 20Mbps bandwidth;

• External network IP, port 4001 is usable;

• Docker environment;

• Linux System

Multiple users can share one mefs's running program.

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

Parameter explanation:

After mefs is started, other users can also be shut down by proxy.

Parameter explanation:

• Cli

• Http

The user whose address is the public key obtains the file named ObjectName from the BucketName bucket.

• Cli

• Http

Mefs commands can all be operated using HTTP.

Configuration

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

// mefs api port setting, default is 5001

api.address is set to: /ip4/0.0.0.0/tcp/5001

// cross-domain access

api.accessControlAllowOrigin is set to: ["*"]

api.accessControlAllowMethods is set to: ["PUT","GET", "POST"]

Then restart mefs-user to use HTTP to operate.

Usage

A command similar to the following:

mefs-user rootcmd subcmd <arg1> <arg2> -opname1=<op1> -opname2=<op2>

The corresponding HTTP request is:

curl "http://<ip>:<port>/api/v0/<rootcmd>/<subcmd>?arg=<arg1>&arg=<arg2>&opname1=<op1>&opname2=<op2>"

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.

Example

Show all bucket information

curl "http://127.0.0.1:5001/api/v0/lfs/list_buckets?addr=<public key>"

The output is in standard JSON format:

  {
    "Method": "List Buckets",
    "Buckets": [
      {
        "BucketName": "<BucketName>",
        "BucketID": "<BucketID>",
        "Ctime": "<Ctime>",
        "Policy": "<Policy>",
        "DataCount": "<DataCount>",
        "ParityCount": "<ParityCount>"
      },
      {
        "BucketName": "<BucketName>",
        "BucketID": "<BucketID>",
        "Ctime": "<Ctime>",
        "Policy": "<Policy>",
        "DataCount": "<DataCount>",
        "ParityCount": "<ParityCount>"
      }
    ]
  }

Display Information about All Objects in a Bucket

curl "http://127.0.0.1:5001/api/v0/lfs/list_objects?arg=<BucketName>&addr=<public key>"

The output is in standard JSON format:

{
  "Method": "List Objects",
  "Objects": [
    {
      "ObjectName": "<ObjectName>",
      "ObjectSize": "<ObjectSize>",
      "Ctime": "<Ctime>",
      "Dir": "<Dir>",
      "LatestChalTime": "<LatestChalTime>"
    },
    {
      "ObjectName": "<ObjectName>",
      "ObjectSize": "<ObjectSize>",
      "Ctime": "<Ctime>",
      "Dir": "<Dir>",
      "LatestChalTime": "<LatestChalTime>"
    }
  ]
}

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

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

Example

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

Example

Introduction

View the bucket user list

Example

Docker:

How to install Docker in Linux(Ubuntu)：

1、Update apt package index

2、Install the following packages to enable apt to use the repository over HTTPS

3、Add the GPG key of Docker official

4、Run the following command line to set up the stable repository

5、 Update the apt package index again

6、 Install the latest version of Docker CE

7、 Verify whether the installation is successful

Check the version of docker installed

Start docker and pull hello-world to verify whether the installation is successful

Since sudo access is required to use docker, enter the password here and it will be started successfully.

Next, run the following command line

You can see the container being downloaded from the remote for testing： Pulling from library/hello-world

When you see the message： Hello from Docker! It means the docker is successfully installed.

Windows install Docker：

1、

2、Download docker for windows

Wait for the download to complete.

Double click to install.

Wait, finish.

After the installation is complete, you will be prompted to restart the computer

Double-click the icon to start docker

Install WSL 2 (a program necessary for installing docker on windows)

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

mefs-keeper -h

COMMANDS:
   init       Initialize a memoriae repo
   daemon     Run a network-connected Memoriae node.
   auth       Interact with auth
   wallet     Interact with wallet
   net        Interact with net
   config     Interact with config
   state      Interact with state manager
   role       Interact with role manager
   info       print information of this node
   register   register an account id for the wallet first, then register a role for it, at last, add it into a group.
   version    Print version
   backup     backup export or import
   bootstrap  bootstrap
   recover    recover
   log        Manage logging
   settle     Interact with settlement chain
   order      Interact with order
   restrict   Interact with restrict
   transfer   transfer eth or memo
   help, h    Shows a list of commands or help for one command

2 Start-node related commands

2.1 init

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

mefs-keeper init -h

Options

   --setPass     set password using input (default: false)
   --password value, --pwd value  set password for access secret key (default: "memoriae")
   --secretKey value, --sk value  secret key
   --keyfile value, --kf value   absolute path of keyfile
   --kpw value      password to decrypt keyfile
   --help, -h       show help (default: false)

Example

MEFS_PATH=~/.memo-keeper ./mefs-keeper init   --setPass=true

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

2.2 daemon

Introduction

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

Usage

mefs-keeper daemon start -h

COMMANDS:
   start    Start a running mefs daemon
   stop     Stop a running mefs daemon
   help, h  Shows a list of commands or help for one command

Options

--password value, --pwd value Use the password when registering (default: memoriae) 
--api value Set the api address to use (default: /ip4/127.0.0.1/tcp/5001) 
--secretKey value, --sk value Use the private key to create the node, if not, please initialize the node 
--swarm-port value Set the swarm port to be used by the node (default: 4001) 
--group value Set the group the node will enter (default: 0 ) 
--price value set the price (default: 0, means not modify the price in config.json) 
--secureAPI Whether it is a secure API (default: true) 
--help, -h View more help

Example

MEFS_PATH=~/.memo-keeper nohup ./mefs-keeper daemon start --api=/ip4/127.0.0.1/tcp/5001 --swarm-port=4001 --group=1 &> keeper.log 2>&1 &

2.3 wallet

Introduction

This command implements the related functions of operating the wallet.

Usage

mefs-keeper wallet -h

COMMANDS:
   new      create a new wallet address
   list     list all addrs
   default  print default wallet address
   export   export wallet secret key
   help, h  Shows a list of commands or help for one command

Subcommands

2.3.1 wallet new

Introduction

Create a new wallet address

2.3.2 wallet list

Introduction

View all wallet addresses default Display

2.3.3 wallet default

Introduction

View the default wallet address

Example

mefs-keeper wallet default

2.3.4 wallet export

Introduction

Export the wallet's private key

Example

mefs-keeper wallet export wallet-address

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

2.4 config

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

mefs-keeper config -h

COMMANDS:
   set      Set config key
   get      Get config key
   help, h  Shows a list of commands or help for one command

Subcommands

2.4.1 config set

Introduction

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

Usage

mefs-keeper config set -h

Options

--key value The key of the config entry (eg "api.address") 
--value value The value with which to set the config entry 
--help, -h show help (default: false)

Example

Configure the value of contract.endPoint

mefs-keeper config set --key=contract.endPoint --value="https://testchain.metamemo.one:24180"

2.4.2 config get

Introduction

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

Usage

mefs-keeper config get -h

Example

Get the contract.endPoint value

mefs-keeper config get --key=contract.endPoint

2.5 bootstrap

Introduction

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

Usage

mefs-keeper bootstrap -h

COMMANDS:
   list     list bootstrap addresses
   add      add bootstrap addresses
   clear    remove all bootstrap addresses
   help, h  Shows a list of commands or help for one command

Subcommands

2.5.1 list

Introduction

View the current node bootstrap node list

2.5.2 add

Introduction

Add a bootstrap node

Example

mefs-keeper bootstrap add "/ip4/103.xx.xx.xx/tcp/44006/p2p/12D3KooWQgakkyTFzcMh8JVbNK3FtiwJZz264sStq8QKBTeHwR3D"

2.5.3 clear

Introduction

clear the bootstrap node

3 Status View Related Commands

3.1 net

Introduction

Network related commands

Usage

./mefs-keeper net -h

COMMANDS:
   info      get net info
   connect   connet a peer
   peers     print peers
   findpeer  find peers
   declare   declare public network address
   help, h   Shows a list of commands or help for one command

Subcommands

3.1.1 info

Introduction

This command checks node network information

Usage

mefs-keeper info -h

USAGE:
   mefs-keeper info command [command options] [arguments...]

COMMANDS:
   self     print node id
   help, h  Shows a list of commands or help for one command

Example

mefs-keeper net info 

Network ID 12D3K..., IP [/ip4/172.xx.xx.xx/tcp/4001 /ip4/128.xx.xx.xx/tcp/39525 /ip4/10.xx.xx.xx/tcp/39525], Type: Private

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

mefs-keeper net info self

ID:  26 keeper 2

3.1.2 peers

Introduction

Show the network information of all nodes currently connected.

Usage

mefs-keeper net peers

12D3KooWHXmKSneyGqE8fPrTmNTBs2rR9pWTdNcgVG3Tt5htJef7 [/ip4/121.37.158.192/tcp/23456]
12D3KooWB5yMrUL6NG6wHrdR9V114mUDkpJ5Mp3c1sLPHwiFi6DN [/ip4/192.168.1.46/tcp/4201]

3.1.3 connect

Introduction

This command connects to a specified node manually.

Usage

mefs-keeper net connect -h

USAGE:
   mefs-keeper net connect [command options] [peer multiaddr (/ip4/1.2.3.4/tcp/5678/p2p/12D...)]

Note

About how to construction the multiaddr for a node.

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

./mefs-keeper net info
Network ID 12D3K..., IP [/ip4/1.2.3.4/tcp/5678/], Type: Private

And the multiaddr of this node is:

/ip4/1.2.3.4/tcp/5678/p2p/12D3K...

3.1.4 findpeer

Introduction

View node information according to peerID, command usage:

Usage

mefs-keeper net findpeer -h

USAGE:
   mefs-keeper net findpeer [command options] [peerID (12D...)]

Example

mefs-keeper net findpeer 12D3KooW...

3.1.5 declare

Introduction

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

Usage

./mefs-keeper net declare -h

NAME:
   mefs-keeper net declare - declare public network address

USAGE:
   mefs-keeper net declare [command options] [net address (/ip4/1.2.3.4/tcp/5678)]

3.2 state

Introduction

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

Usage

mefs-provider state -h

COMMANDS:
   post      list post
   pay       list pay
   withdraw  provider income of storing data
   help, h   Shows a list of commands or help for one command

Subcommands

3.2.1 post

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

3.2.2 pay

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

3.2.3 withdraw

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

3.3 role

Introduction

View commands for connected nodes

3.3.1 list

Introduction

This command is used to list connected roles

Usage

mefs-keeper role list

3.4 info

Introduction

This command checks the basic information of this node

Usage

mefs-keeper info -h

Options

​--update (default: false) 
--all value, -a value Display all info information of the node (default: "false") 
--help, -h View more help

Example

mefs-keeper info

or

mefs-keeper info -all true

3.5 settle

Introduction

Node pledge, withdrawal and other operations.

Usage

mefs-keeper settle -h

COMMANDS:
   setDesc               Set description for a node. Especially for keepers, if desc is set to 'cloud', they will be selected as dc in buckets preferentially.
   withdraw              withdraw memo from fs
   pledgeAdd             add pledge value
   pledgeGet             get pledge information
   pledgeWithdraw        move pledge value to fs, then call settle withdraw
   pledgeRewardWithdraw  move pledge reward value to fs, then call settle withdraw
   quitRole              change its state to inactive, this op is invocatable and daemon will fail at next start
   alterPayee            alter current payee to a new one, need to be comfirmed by new payee to finish.
   help, h               Shows a list of commands or help for one command

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

3.5.1 setDesc

Introduction

Used to set the description for a node.

3.5.2 pledgeAdd

Introduction

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

Usage

USAGE:
   mefs-keeper settle pledgeAdd [command options] [amount (Memo / NanoMemo / AttoMemo) required]

Example

To pledge 1 Memo for this node.

mefs-keeper settle pledgeAdd "1 Memo"

3.5.3 pledgeGet

Introduction

View the current pledge amount.

Example

mefs-keeper settle pledgeGet

3.5.4 pledgeWithdraw

Introducton

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

Example

Withdraw the pledge of 0.5 Memo to the Fs account

mefs-keeper settle pledgeWithdraw "0.5 Memo"

3.5.5 pledgeRewardWithdraw

Introduction

pledgeRewardWithdraw Withdraw the pledge income to the FS file system.

Example

Withdraw 0.5Memo of pledge reward to Fs account

mefs-keeper settle pledgeRewardWithdraw "0.5 Memo"

3.5.6 withdraw

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

mefs-keeper settle withdraw "0.5 Memo"

3.5.7 quitRole

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

mefs-keeper settle quitRole --really-do-it

3.5.8 alterPayee

Introduction

alterPayee used to change the current payee.

3.6 version

Introduction

View current node version

Usage

mefs-keeper version

4 keeper daily used commands

4.1 recover

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

mefs-keeper recover db -h
--path specifies the database path to repair --deType the type of repair data (meta or state)

Example

Repair state database

mefs-keeper recover db --path=/root/.memo-keeper/state --dbType=state

4.2 backup

Introduction

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

Subcommands

4.2.1 export

Introduction

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

Usage

mefs-keeper backup export -h

USAGE:
   mefs-keeper backup export [command options] [arguments...]

OPTIONS:
   --path value    path to store
   --dbType value  export dbtype: meta or state (default: "state")
   --help, -h      show help (default: false)

Example

Export the state database to the current directory

mefs-keeper backup export --path=./ --dbType=state

4.2.2 import

Introduciton

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

Usage

mefs-keeper backup import -h

USAGE:
   mefs-keeper backup import [command options] [arguments...]

OPTIONS:
   --path value    path of file import from
   --dbType value  export dbtype: meta or state (default: "state")
   --help, -h      show help (default: false)

Example

import state database

mefs-keeper backup import --path=./state-xxxxxxxxx.db --dbType=state

4.3 restrict

Introduction

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

Usage

mefs-keeper restrict -h

USAGE:
   mefs-keeper restrict command [command options] [arguments...]

COMMANDS:
   list     list all accepted keepers/keepers
   add      add node(s) to restrict list
   delete   remove node(s) from restrict list
   has      test whether node(s) in restrict list
   set      enable/disable restrict
   stat     restrict stat(enable/disable)
   help, h  Shows a list of commands or help for one command

Subcommands

4.3.1 list

Introduction

View whitelist node

Example

View the nodes in the whitelist

mefs-keeper restrict list

4.3.2 add

Introduction

Add whitelist node

Example

Add keeper node to whitelist

mefs-keeper restrict add PID

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

4.3.3 delete

Introduction

delete whitelist node

Example

Delete whitelist nodes

mefs-keeper restrict delete PID

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

4.3.4 has

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

4.3.5 set

Introduction

Set whitelist status

Example

Enable the whitelist function

mefs-keeper restrict set --enable

Turn off the whitelist function

mefs-keeper restrict set disable

4.3.6 stat

Introduction

Check whitelist status

Example

Check whitelist status

mefs-keeper restrict stat

5 Other commands

5.1 auth

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

mefs-keeper auth info -h

USAGE:
   mefs-keeper restrict command [command options] [arguments...]

COMMANDS:
   list     list all accepted keepers/keepers
   add      add node(s) to restrict list
   delete   remove node(s) from restrict list
   has      test whether node(s) in restrict list
   set      enable/disable restrict
   stat     restrict stat(enable/disable)
   help, h  Shows a list of commands or help for one command

5.2 log command

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

5.2.1 setLevel

Usage

mefs-keeper log setLevel -h

NAME:
   mefs-keeper log setLevel - Set log level

USAGE:
   mefs-keeper log setLevel [command options] [level (debug/info/warn/error)]

Example

mefs-keeper log setLevel debug

Step 1: Environment Deployment

View Docker Installation section to install docker.

Step 2: Set up the node directory

Node home directory:

Using "~/memo_provider" as an example:

export MEFS_PATH=~/memo_provider

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

export MEFS_DATA=~/memo_provider_data

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

Step 3: Pull image(provider)

docker pull memoio/mefs-provider:latest

Step 4: Initialization（Create new wallet）

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest init --password=memoriae

Explanation of parameters:

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

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

Step 5: Get wallet address

ddocker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest wallet default

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, https://faucet.metamemo.one/

This is the MemoChain information.

Memochain information

Chain RPC: https://chain.metamemo.one:8501/

Currency name: CMEMO

Chain ID: 985

Chain browser: https://scan.metamemo.one:8080/

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

Join our discussing with Slack Link:

https://join.slack.com/t/memo-nru9073/shared_invite/zt-sruhyryo-suc689Nza3z8boa4JkaLqw

Step 7: Modify the configuration file

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest config set --key=contract.version --value=3

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest config set --key=contract.endPoint --value="https://chain.metamemo.one:8501"

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest config set --key=contract.roleContract --value="0xbd16029A7126C91ED42E9157dc7BADD2B3a81189"

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest bootstrap clear

docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest bootstrap add "/ip4/183.240.197.189/tcp/14006/p2p/12D3KooWAMpZPwfJopVnp99oqp4zhbjE1G3LFAkcjfBuiyzyCmv7"

Step 8:Start node

docker run -d -p 4001:4001 -v $MEFS_PATH:/root -v $MEFS_DATA:/root/data -e PASSWORD="memoriae" -e PRICE=250000 -e GROUP=3 -e SWARM_PORT=4001 -e DATA_PATH=/root/data --name mefs-provider memoio/mefs-provider:latest

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

If there is any deploy issue. Please join the deploy-node discussing with Slack Link:

https://join.slack.com/t/memo-nru9073/shared_invite/zt-sruhyryo-suc689Nza3z8boa4JkaLqw

Checking the running status

Step 1: Enter the container

docker exec -it mefs-provider bash

Step 2: Check provider information

mefs-provider info -a

----------- Version Information -----------
2023-05-16 09:35:49 UTC
2.7.0+api.2+git.c405cb1+2023-03-15.16:15:54CST
----------- Network Information -----------
Network ID:  12D3KooWSLvBa9QB5Qy9SPnrhuNJhCAPzVmyri9gacaUAgfpQ72q
IP:  [/ip4/172.xx.xx.xx/tcp/4001]
Type: Private
Declared Address:  {12D3KooWSLvBa9QB5Qy9SPnrhuNJhCAPzVmyri9gacaUAgfpQ72q: [/ip4/103.xx.xx.xx/tcp/24001]}
----------- Sync Information -----------
Status: true, Slot: 1530431, Time: 2023-05-16 09:35:30 UTC
Height Synced: 346322, Remote: 346322
Challenge Epoch: 81 2023-05-10 03:31:30 UTC
----------- Role and Account Information -----------
Role ID:  421
Type:  Provider
Location: Personal
Wallet:  0xDd8F2bE3C11b1b1A74404141BA8216a5010B1746
Owner:  0xDd8F2bE3C11b1b1A74404141BA8216a5010B1746

Memo Balance: 1.00 Memo
cMemo Balance: 999.90 Gwei
Storage Balance: 0 AttoMemo, Income: 0 AttoMemo
Current Pledge: 30.00 Memo, Reward: 4.05 Memo
Pledge Time: 2023-05-16 02:08:04 UTC
Historical Pledge: 30.00 Memo, Reward: 4.05 Memo
Withdraw Pledge: 0 AttoMemo, Reward: 0 AttoMemo
Pool Pledge: 416.00 Memo, Reward: 7481.01 Memo

Storage Size: 0 byte (0 B), Price: 0 (AttoMemo/Second)
Storage Deposit: 0 AttoMemo
----------- Group Information -----------
EndPoint:  https://chain.metamemo.one:8501
Contract Address:  0xbd16029A7126C91ED42E9157dc7BADD2B3a81189
Group ID:  3
Security Level:  3
Size:  2.00 GiB
Price: 2114500000 (AttoMemo/Second)
Keepers: 4, Providers: 4
----------- Store Information ----------
Service Ready:  true
Received Size:  0 B
Confirmed Size: 0 B
OnChain Size:  0 B
----------- Local Information -----------
Meta Usage: path /root/.memo-provider, used 781.37 MiB, free 277.71 GiB
Data Usage: path /root/data, used 0 B, free 277.71 GiB