MEMO系统节点匹配

MEMO系统核心应用是分散式区块链，为了在低可信度的环境中实现公平交易，系统为每个角色都设计了相应功能，存储需求者（User）、存储协调者（Keeper）、存储提供者（Provider）三者之间交互共同组成系统生态。本文将对MEMO系统的节点匹配做详细阐述，即User是如何寻找到为自己提供存储服务的Provider的。

1.User的需求参数设置

User是系统的最终消费者，每一次存储服务皆由User发起，而后才是Keeper和Provider为其提供服务。在角色设计文章中，我们已提到，当User提出存储服务需求时，应当包含以下要素：存储空间大小、存储时长、Provider和Keeper的数量。

存储空间大小、存储时长是最基本的参数，至于为什么要选择Provider和Keeper的数量，那是因为MEMO系统采用对象存储形式，并且数据的链下维护采用的是数据冗余方式：多副本或者纠删码，所以存储节点越多，数据就越安全。

因为一旦某个存储节点上的数据有损失，那么就可以通过其他存储节点帮助恢复其数据。在这个分散式云存储系统中，存储节点越多，全部存储节点出现数据损坏或丢失情况的概率就越小。但是存储节点选择的越多，User对存储服务的支付费用就越高。因此，User对存储服务的要求还应包括Provider的数量。由User衡量费用问题和数据安全问题，自行确定存储节点Provider的数量。

同样，因为Keeper需要对provide进行时空挑战，即通过数据验证技术，检查Provider正确存储多少数据量以及存储时长，多个Keeper对挑战结果进行共识，共识结果作为对Provider存储数据付费的依据。Keeper的数量会对此次存储服务造成影响，原因在于：Keeper数量越多，对挑战结果造假的成本就越高，所有Keeper都不在线的概率也越低。

2.User的其它参数设置：信誉值、价格

User在提出存储需求时，除了存储空间大小、存储时长、Provider和Keeper的数量这些基本参数外，根据具体的使用场景，可能也会设置一些其他的参数。

因为各个Provider 的诚信度可能有所不同，有些 Provider能够保证每次正常存储数据并且能够长期在线，而有些 Provider并不能如此，所以也可以根据需要选择Provider的信誉值，该信誉值根据Provider历史提供服务的表现得出，当 Provide保证长期在线并正常为User存储数据、积极响应Keeper的挑战，则其信誉值会更高，信誉越高，其后期与User匹配的机会就越大。

同样，对于Keeper，除数量要求外一样也会涉及到信誉值问题，User在进行参数设置时也可对keeper的信誉值提出要求，因为每个消费者都希望与信誉高的伙伴合作。

此外，系统应该为User提供指定存储服务价位的功能，比如每存储1MB数据，存储一天需要支付多少金额，具体存储单价的单位可以根据系统的实际使用情况来确定。

综上所述，User寻求存储服务时需要指定的参数有存储空间大小、存储时长、存储单价、Keeper的参数要求（比如Keeper数量）、Provider的参数要求（比如Provider数量）。

3.智能合约匹配

当User设置好需求参数后，Keeper将根据User的存储服务要求，查找与自己相连的Provider，匹配出合适的存储节点。匹配操作的具体情况为：Provider上线之后，说明自己的存储情况，具体应包括：可提供的存储空间、存储时长、要求的存储单价，因此Keeper根据双方的情况进行匹配，之后将匹配成功的Provider信息发给User。从而User与Keepers、Providers组成一次存储服务。

对于Keeper如何根据User、Provider的存储情况进行匹配这一问题，解决方案一是：节点连接时，User和Provider主动向Keeper发送自己的存储服务相关信息；解决方案二是：利用智能合约，将User的存储要求和Provider的存储条件记录在链上，与Keeper相连时，Keeper直接从链上查看，从而进行匹配。两种方案相比，方案一会增大系统网络负担，并且对于后面存储服务的进行缺少可审查性；方案二将信息记录在智能合约中，具有分布式监督和不可篡改的特性，而且仅Keeper从链上查询信息不会造成大于方案一的网络负担，也便于审计，只是User和Provider需要承担部署智能合约的花销。

因此，将通过智能合约记录与存储服务相关的各种参数信息，具体包括User对于存储服务的需求参数以及Provider能够提供的存储服务相关参数。可以说，智能合约贯穿着MEMO系统的始终。

—-

编译者/作者：Memolabs

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。