Build an Autonomous Storage System: Role Design in Memoriae Cloud PRWire by techtargeter_3i6rxd - August 20, 2021 Each user in the Memoriae decentralized cloud storage system can register a role based on its individual needs. The system comprises three parties whose roles are respectively the User, the Keeper and the Provider. A party requiring storage is registered as the User, a party providing the device as the Provider and a party providing information management services only as the Keeper. This article addresses the principles based on which each role is designed from the perspective of overall system operation. The basic positioning of the tripartite roles is as follows: 1. The User is a consumer of storage services in the system, who defines the storage requirements and uploads the data 2. The Keeper is the administrative coordinator in the system, who acts as the intermediary and manager of the information 3. The Provider is the provider of the storage devices in the system, who provides the storage space for the user Among the tripartite roles, the User is the end user in the system, and the User and the Provider form the supply and demand sides of the storage services. In a nutshell, the User uses the storage space in the MEMO, short for Memoriae, and the Keeper finds the suitable storage node for the User, and the Provider at the storage node stores the data for the User. The Keeper is more or less an intermediate information matchmaker between the User and the Provider, while the Keeper acts in the capacity of a headhunter as on a recruitment platform or an agent on a real estate trading platform. Figure1: Roles Functions Role Design 1. The User Since the end user in the system is the User who pays for the storage services, every service request is initiated by the User. The following elements should be included in the user’s proposed storage service requirements: the size and duration of the storage space needed, the number of Providers and Keepers and the unit price for the required storage. That is because only after the above parameters are set can the Keeper retrieve and match the corresponding storage node. While more storage nodes would mean greater security for the data stored in a decentralized cloud storage system, the flip side is that more storage nodes would also mean a higher cost. Therefore, it is up to the user to determine the number of storage node Providers and intermediate administrative Keepers to strike a balance between cost and data security. The User needs to pay not only for the storage services, but also for the download when the Provider is asked to download the data, as the download operation will make the Provider incur traffic and equipment consumption. Since the User is the ultimate payer, the system does not set any special restrictions for such a role, as the Provider and Keeper can refuse service if the User fails to pay. But penalty measures are set for the other two roles, the Provider and the Keeper, for which a detailed explanation will be offered as follows. Figure2: Basic User Functions 2. The Keeper a) The Basic Functions The Keeper plays an important intermediary role in the system. It assumes information intermediary and management functions, and takes an administrative commission out of the storage fees paid by the User. As an information intermediary, its basic function is to match information, that is, to act as a matchmaker between the demand and supply sides of the equation. The Keeper will identify an associated Provider based on the requirements put forward by the user, and match it with the appropriate storage node. In addition to basic information matching, the Keeper’s adminstrative function is also reflected in its participation in challenging actions. The Keeper regularly challenges the Provider to verify whether the Provider has stored the data completely, that is, to verify the authenticity and integrity of the Provider. Based on the results of such challenging, it figures out how much data each Provider has effectively stored for the User for how long during such a period of time, which will then serve as the basis for payment to be made by the User later on. In addition, another important function of the Keeper is to trigger payment for the storage fees. Neither the User, payor in the system nor the Provider, payee in the system, can trigger the payment process, which is done rather by the intermediary Keeper. Such a design is mainly for the purpose of ensuring integrity of the system to reduce the possibility of fraudulent behaviors. Figure3: Basic Keeper Functions b) The Penalty Mechanism The Keeper participates in the system operation and management in the capacity of an intermediary. Although to a certain extent, it can handle the trust issue between the supply and demand sides of data storage in the decentralized storage system, MEMO has designed penalty measures for that role because the Keeper itself may also have integrity issues, e.g., failure for timely challenging data storage, or triggering payment, etc. The penalty mechanism can to a certain extent ensure benign system operation and healthy community development. Therefore, the system stipulates that an account registered as a Keeper would need to pledge a safety deposit, which can be refunded upon request by the account, or deducted for any violation of the system regulation by the account. An insufficiently pledged deposit, or the absence of any deposit in the account would result in the absence of any integrity endorsement, which in turn would render the Keeper role of the account invalid. When and how much to deduct the penalty from the deposit amount can be determined off-chain. Usually, an account in serious violation of the system regulation will be subject to closure. The system would ban the account of a Keeper who fails to perform timely space-time challenging of the data storage, the synchronization of the result of the space-time challenges and the report of the results of the space-time challenge over a long period of time. An account once banned will never be allowed to assume a Keeper role again in the future. Any balance in the deposit by a disabled Keeper can be handled in the following methods: refunded to the account; transferred to the role manager who deploys the role contract; transferred to other accounts affected by the Keeper’s violation of the system rules, including the User, the Keeper, and the Provider. Figure4: Keeper Penalty mechanism 3. The Provider a) The Basic Functions The Provider provides the storage space in the system as a service to and gets paid by the User. After the acquisition of the storage node, a Provider needs to describe its storage situation, including the space, duration, and required unit price for the storage. Based on such a description, the Keeper will start matching the User and the Provider in accordance with their specific situations, and then will send the information about the successfully matched Provider to the User, when the User, Keeper, and Provider can establish an instance of storage service. The Provider is also capable of triggering payment just like the Keeper, but the difference between lies in the fact that the Keeper triggers the payment for the storage, while the Provider triggers the payment for the download. That is because participation by the Keeper, the intermediate manager is required for the verification of the storage fees while verification of the download fees does not require participation by the intermediate manager. Figure5: Basic Provider Functions b) The Penalty Mechanism The system also designs reward and penalty measures for the Provider, similar to those for the Keeper for the breach of the contract mentioned above, as the Provider may fail to restore corrupt data, or respond to the User’s data download request or the Keeper’s challenges, among other issues, which may result in not only the destruction of the User’s data, but also seriously adverse user experiences. Therefore, the Provider will also need to pledge a deposit when applying for that role. The system will trigger the corresponding penalty mechanism to deduct from the pledged deposit amount when a Provider acts in violation of the system rules. Figure6: Provide Penalty Mechanism MEMO’s test network is currently underway, so feel free to join. MEMO community volunteer recruitment program will be launched soon, welcome to join us and work together with the MEMO team to make human data eternal! Metastorage, a fully decentralized dual NFT storage system based on MEMO, links both the IPFS system and MEFS systems to secure like never before! For more details, please visit: Official Website, Twitter, Telegram, Facebook, Medium, Reddit, Github, Discord.