maidsafe_vault

主要维护者： Ma Qi ([email protected])

次要维护者： Chandra Prakash ([email protected])

包	Linux	Windows	OSX	覆盖率	问题

#概述

一个能够进行数据存储/发布/共享以及计算、价值转移（支持加密货币）等功能的自主网络。请参阅下面对数据存储涉及操作的更详细描述。

#待办事项

[0.1.2] - 代码清理

• MAID 1185 使用unwrap 不安全

[0.1.3] - 与具有 churn 事件的客户端的集成测试

• MAID-1017 churn（节点加入或离开时的账户转移）

[0.1.4] - 更新 persona

• MAID-1186 统一结构化数据的处理
  • MAID-1187 更新版本处理器
  • MAID-1188 如有必要更新其他 persona
• MAID-1189 正确初始化 PmidNode（最大磁盘空间）

[0.1.5] - 账户创建

• MAID-1190 正确创建 MaidManager 账户条目（所有权限）
• MAID-1191 正确创建 PmidManager 账户条目（pmidnode 磁盘空间信息）

[0.2.0] - 消息传递

• MAID-1192 消息传递
  • MAID-1193 文档
  • MAID-1195 消息账户管理
  • MAID-1198 发送消息
  • MAID-1199 检索消息
  • MAID-1200 提款消息

[0.3.0] - 初始 safe coin 实现

• MAID-1201 初始 safe coin 实现
  • MAID-1202 文档
  • MAID-1203 钱包管理
  • MAID-1204 农业
  • MAID-1205 空间消耗
  • MAID-1206 转账

详细文档

概述

MaidSafe 网络由软件进程（节点）组成，被称为保险库。这些保险库在网络上执行许多功能，这些功能组件被称为角色。底层网络在连接到 路由 时，是一个异或网络，因此一个节点可以表达对网络上任何其他节点或元素的接近程度或责任，如果该节点相对于目标较为接近。在这个摘要中，短语 NAE（网络可寻址元素）用于指代任何具有网络地址的元素，包括数据。

保险库依赖于 路由 通过相关的 API 调用 来计算 NAE 的责任。

这些调用使我们能够从任何我们可能负责的 NAE 的角度来看待网络。强调这一点的重要性不足以强调，确定 NAE 责任的唯一方法是查看 NAE 的视角。如果我们对所知的节点及其紧密节点（称为组矩阵）进行排序，并且我们不在前 K（复制次数）节点中，那么我们就不负责该 NAE。这是一个基本问题，其重要性不容忽视。

由于网络在 churn 和保险库功能方面非常灵活，保险库网络必须衡量和报告单个保险库，并且更重要的是确保任何保险库的所有角色都为其负责的 NAE 执行其任务。在任何给定网络段周围的 churn 事件中，路由会创建一个矩阵更改对象并将其传递给保险库。该对象包含旧节点和新节点的列表。基于此信息，它提供辅助函数以推导有关任何给定 NAE 的相关信息：如果收到 churn 事件的节点是提供的 NAE 最近的 K 个节点之一。如果是，则哪些新节点需要有关提供 NAE 的信息。如果不是，则删除有关给定 NAE 存储的任何信息。

churn、数据重复和确保组内所有成员达成一致是通过同步、累加器和组消息的组合来处理的。这是一组复杂的规则，需要特别注意边缘情况。

网络的安全语言

一般考虑因素

节点和数据都生活在同一个 XOR 空间中，该空间由一个 512 位密钥（2^512 个可能地址）进行寻址；一个网络可寻址元素（NAE）。消息从 NAE 流向 NAE。操作可以通过管理组在消息流上执行。

从开始到结束的消息流可以表示为

< NAE_1 | manager | NAE_2 >

其中 NAE 可以是一个节点（即保险库或客户端 - 直接 NAE）或数据元素（间接 NAE）。在正常/成功的情况下，操作组将执行 manager | NAE_2 >。当发生错误时，操作组将执行 < NAE_1 | manager。

如果不需要对消息流进行操作，则此特殊情况表示为

< NAE | NAE >

对于给定的消息类型 ACTION，函数的名称应为

< A::ACTION | B::ActOnACTION | C::PerformACTION >

函数 HandleACTION 是为 VaultFacade 保留的。目前这些消息类型包括 Connect*、ConnectResponse*、FindGroup*、FindGroupResponse*、GetData、GetDataResponse、PutData、PostMessage，其中带有 * 的消息类型已在路由中完成，并免除此命名规范。

为了清晰起见，消息根据以下抽象通过 RoutingNode 和 VaultFacade 传递到 Persona：

RoutingNode::MessageReceived {
  Parse; Filter; Cache; SendOn; Relay; Drop; Sentinel;
  Switch RoutingNode::HandleMessage(MessageType /* */) {
    Completed in routing or
    VaultFacade::HandleACTION {
      Switch on Authority & template on DataType {
        Persona::ActOnACTION or  // Currently both named HandleACTION
        Persona::PerformACTION
      }
    }
  }
}

三元组结构 < A | B | C > 描述了每个消息流的通用特征。该结构是事件驱动的，并且消息 ID 在结构中保持不变。

< . 对应于新消息流的创建。单个节点或客户端可以发起路由调用，其中路由生成一个随机的消息 ID。需要注意的是，如果组启动新的消息流，路由需要确定性地实例化消息 ID。

. | . 表示在上述中间 XOR 空间上的完整路由操作

Parse; Filter; Cache; SendOn; Relay; Drop; Sentinel;

A::ACTION()
B::ActOnACTION()
B::ACTIONFailure()
C::PerformACTION()

< A | B | C > < C | D | E >

< MaidClient | DataManager > < DataManager | MaidNode >
< MaidClient | DataManager > < DataManager | PmidNode > < PmidNode | MaidNode >

< MaidClient | DataManager > < DataManager | PmidNode > (< PmidNode | MaidNode > & < PmidNode | DataManager >)

< MaidClient | MaidManager | DataManager > < DataManager | PmidManager | PmidNode >

< MPN_A | MPM_A > < MPM_A | MPM_B > < MPM_B | MPN_B >

< MPN_B | MPM_B > < MPM_B | MPM_A > < MPM_A | MPN_B > < MPN_B | MPM_B >

D      data
H()    Hash512
H^n()  n-th Hash512
Manager{Address};
       {Address} omitted where evident,
       e.g. MaidManagers{MaidNode}