Given the demand for fair transactions in a low-trust environment, Memoriae system is designed using the core technology of decentralized blockchain. There are three system roles involved with appropriate functions, namely the User, the Keeper, and the Provider, which interact with each other to form an ecosystem. This article will elaborate on the node matching of Memoriae system, i.e. how the User finds the Provider for storage service.
Demand parameter configuration of User
The User is the end consumer of the system who initiates the desired storage service based on which the Keeper and Provider offer their services. As mentioned in the article on role design, when a User requests a storage service, the following parameters should be specified: storage size, storage time, and the number of Providers and Keepers.
Storage space and storage time are the most basic parameters. Keeper/Provider numbers are required additionally due to the object-based storage in Memoriae system, where the off-chain data maintenance depends on storage redundancy achieved through multiple copies or erasure codes. On one hand, more storage nodes bring more security and low probability of data corruption or loss in the decentralized cloud storage system, since the lost data on one storage node can be seamlessly recovered from other storage nodes. On the other hand, however, more storage nodes lead to higher service costs for Users. Therefore, the number of Providers should be included in the User’s requirements. It is up to the User to weigh the cost and data security and to determine the number of Providers of storage nodes.
In addition, the Keeper uses data validation techniques to challenge the Provider by validating its capabilities in proper storage and storage time. Multiple Keepers will then reach a consensus on the challenge results of storage space and time based on which the Provider will be paid. The number of Keepers affects the storage service for the following reasons: the higher the Keeper number, the higher the cost of falsifying the challenge results, and the lower the probability that all Keepers will be offline.
Other parameters of User: Reputation, Price
Besides the basic parameters of storage size, storage time and Keeper/Provider numbers, users may also set some other parameters depending on the specific scenarios when they propose storage requirements.
The reliability of each Provider may vary. Some Providers can guarantee proper storage every time and always be online, while others cannot, so the reputation of the Provider can also be selected as needed. The reputation is based on the Provider’s historical performance in providing the service. If they are assured to be online for a long time and to store data properly and respond positively to Keeper’s challenges, their reputation value will be higher, and the higher their reputation, the greater their chances of being matched with Users.
Likewise, the Keeper’s reputation will also be involved in addition to the Keeper number. The User can request the Keeper reputation when configuring the parameters, as each consumer wants to work with a highly reliable partner.
Moreover, the storage service price for Users should be specified in the system, for example, how much should be paid for each 1MB of data stored for a single day. The specific unit of storage price can be determined according to the actual use.
In summary, the User needs to configure parameters when looking for storage services such as storage size, storage time, unit storage price, parameter requirements for Keeper (such as Keeper number), and parameter requirements for Provider (such as Provider number).
Smart contract matching
When the User has configured demand parameters, the Keeper will reach out to connected Providers and match appropriate storage node with the User’s demands. The matching procedure is as follows: The Provider comes online and indicates its storage situation, including available storage space, storage time, and required unit storage price, then the Keeper performs bilateral matching and sends the information of successfully matched Provider to the User. AS a result, Users, along with Keepers and Providers, constitute one storage service.
Two solutions are available for the matching between Users and Providers. Solution 1: When nodes are connected, Users and Providers send their storage service-related information to Keepers; Solution 2: Using smart contracts, the storage requirements of Users and storage conditions of Providers are recorded on the chain, and, when Keepers are connected, they will check the information directly from the chain for the match. Comparing the two solutions, Solution 1 increases the system network burden and lacks reviewability for the later storage service; Solution 2 records the information in smart contracts with distributed supervision and tamper-proof features, and only the Keeper queries information from the chain, resulting in less network burden than Solution 1 and facilitating audit, but the User and Provider need to bear the cost of smart contracts.
Therefore, various storage service parameters will be recorded through the smart contract, including demand parameters of the User and service parameters of the Provider. In summary, the smart contract is implemented across the entire Memoriae system.
