命名空间逻辑

为了实现互联网规模的区块链解决方案，必须像互联网一样拥有推理出资源“位置”的逻辑。具体来说，我们如何引用资源？我们如何确定哪些代理可以在什么条件下访问该资源？与其他地址（公钥）只有一个维度的区块链相比，RChain的虚拟地址空间将被分割成多个命名空间。 在一个非常大体的解释中，命名空间是一组命名通道。 因为通道常常被实现作为数据存储，所以命名空间相当于一个有争议资源的集合。

问答：命名空间和双花问题

问：假设Alice，Bob和Carol在相互不同的命名空间中，发生了两笔付款：Alice付给Bob和Alice付给Carol。假设我是一个只关心Alice的节点，我如何确定Alice不会双重花费？

答：命名空间只是一组名称。所有的区块链地址都是名称。一个集合可以用几种方式来描述。其中之一是在外部明确地写出集合中的每个项目。另一种方式是内在性地提供一个规则或程序，或者用于生成集合，或者识别一个物品是否在集合中。第二类命名空间更有意思。

现在，下一步是将这些与用户，合约以及节点联系起来。用户和合约都通过名称相互通信。节点验证给定的命名空间中的事务，事务是跨名字（通道）间的I/O事件。任何涉及到两个独立命名空间的事务都必须由处理这些命名空间的节点集合来处理。如果处理这些事务的结点不能组合成命名空间，则该事务将不能发生。

如果有多个节点组合这些命名空间，那么一致性算法可以保证所有节点都同意该事务。更具体地说，他们同意每次竞争的获胜者。因此，永远不会有双花发生。最大的威胁是找到有多个验证者服务的复合命名空间。幸运的是，您可以看到命名空间背后的验证者的多少，由此决定是否信任该命名空间。

我们已经明确两个进程必须共享一个指定的通道进行通信，但是如果多个进程共享相同的通道呢？事务的不确定性是在两个一般条件下引入的，导致资源有争议并容易受到竞争条件的影响：

for(ptrn <- x){P1} | x!(@Q) | for(ptrn <- x){P2}

第一种竞争条件发生在多个并行组合的客户端在命名通道上竞争 接受 数据资源时。在这种情况下， P1 和 P2 在命名通道 x 等待由另一个进程中由 x 发送的资源 @Q 。当且仅当在该位置处看到正确的值时，客户端才会执行其附加部分代码。在其他情况下，许多客户处于竞争中，可能存在许多归约，但是在这种情况下，两个中只有一个可能会成立。其中之一是 P1 首先接收 @Q ，另一个是 P2 首先接收到 @Q ，这两者在 @Q 代入到他们各自的协议中都可能会返回不同的结果。

x!(@Q1) | for(ptrn <- x){P} | x!(@Q2)

第二种竞争条件发生在当两个客户端竞争一个命名通道以发送一个数据资源时。在这种情况下，两个客户端在命名通道 x 处竞争，向客户端发送数据资源 @Q ，但是以下两个事务中的只有一个可能发生，一个是接收客户端首先接收 @Q1 ，另一个是先收到 @Q2，两者在代入到 P 的协议体重可能返回不同的结果。

对于竞争资源的协议，这种水平的不确定性是不可避免的。之后，在共识那一节，我们将描述共识算法如何通过将非确定进程中发生的多个可能的交易收敛到一个可维护复制状态。 现在来看看在第一个竞争条件下重新定义名称约束规约是多么简单的事：

for(ptrn <- x){P1} | x!(@Q) | for(ptrn <- v){P2} → P1{ @Q/ptrn } | for(ptrn <- v){P2}

—第二个竞争条件

x!(@Q1) | for(ptrn <- x){P} | u!(@Q2) → P{ @Q1/ptrn } | u!(@Q2)

在这两种情况下，通道和正在传输的数据资源都不再是有争议的，因为它们现在正在通过两个不同的命名通道中进行通信。 换句话说，它们在不同的命名空间中。 另外，名字是可证明不可猜测的，所以只有当存在一个任意的外部过程给出时，其他进程才能获得。因为一个名字是不可猜测的，所以一个资源只对知道这个名字的进程/合约才可见[5]_。 因此，在非冲突的命名通道集合上执行的一组进程（比如在分开的命名空间中执行的事务集合）可以被并行执行，如下所示：

  for(ptrn1 <- x1){P1} | x1!(@Q1) | ... | for(ptrnn <- xn){Pn} | xn!(@Qn) → P1{ @Q1/ptrn1} | ... | Pn{ @Qn/ptrnn }

| for(ptrn1 <- v1){P1} | v1!(@Q1) | ... | for(ptrnn <- vn){Pn} | vn!(@Q1) → P1{ @Q1/ptrn1} | ... | Pn{ @Qn/ptrnn }

在名称空间 x 中并行执行的一组事务，以及在名称空间 v 中执行的一组事务是双盲的; 除非由辅助过程引入，否则它们是相互匿名的。 两组事务都在传递相同的资源 @Q ，甚至要求 @Q 满足相同的 ptrn ，但是没有竞争条件，因为每个输出都有一个单独的输入副本，事务发生在不同的命名空间中。这种隔离进程/合约交互集的方法基本上将RChain的地址空间分割成许多独立的事务环境，每个环境都是内部并发的，并且可以相互并行执行。

在这种表示中，该性质仍然保持成立，资源对那些知道通道名称并且满足模式的进程/合约可见。 将地址空间划分为独立事务环境的一个多路复用后，我们如何进一步细化可以在类似环境中与资源进行交互的进程/合约的类型？以及在什么条件、在什么程度上可以这样做？ 为此，我们开始进行定义。

命名空间定义

命名空间的一个定义是进程/合约在一个命名空间中运行所需的最低条件的形式化描述。 事实上，命名空间的一致性直接并唯一地依赖于该空间如何定义一个名称，根据命名空间定义所描述的合约的预期功能，这可能会有很大的不同。

命名和功能都可能满足或不满足定义。以下命名空间定义在交互中实现为“if条件”，它描述了一组进程将一组合约发送到一组命名地址，这些命名地址组成了一个命名空间：

  1. 一组合约， contract1…contractn 被发送到一组通道(命名空间)，即 address1…addressn.
  2. 一个进程并行地监听命名空间 address 中每个通道的输入。
  3. 当任一通道上收到一个合约时，它被提供给 if cond.，检查命名空间的源点、发送者的地址、合约的行为、合约的接口以及合约所携带的数据大小。
  4. 如果这些性质与命名空间 address 的定义相一致，P 将会被执行，并将 contract 作为它的参数。

命名空间定义有效地限制了命名空间中可能发生的交互类型——空间中存在的每个契约都展示出一种常见可预测的行为。也就是说，驻留在名称空间中的合同所调用的状态更改操作都必须经过授权，定义并且对该名称空间是正确的。这种设计选择使在命名空间上的目录式快速查询非常方便有效。

命名空间定义也可以控制在空间中发生的交互，比如说，通过制定

  • 接受的地址
  • 接受的命名空间
  • 接受的行为类型
  • 数据大小的最大最小值
  • I/O结构

定义可能，并且一般都会指定一组可接受的命名空间和地址，这些名称空间和地址可以与其定义的代理进行通信。

请注意上图中针对行为类型的检查。这是为了确保合约所表达的操作串与命名空间的安全规范一致。行为类型检查可以用来评估可用性，边界，有无死锁和资源同步等特性，这些特性最大程度上保证了命名空间中资源上的“安全”地改变状态。因为行为类型意味着操作排序，所以行为类型条件可以指定合约的后置条件，这又可以满足后续命名空间的先决条件。因此，名称空间架构支持事务环境的安全组合，或“链接”在一起。

可组合的命名空间 - 资源寻址

在此之前，我们已经将命名通道描述为任意宽度的扁平实体。通过命名渠道的反射和内部结构，实现深度。

一个名字空间可以被认为是一个URI（统一资源标识符），而一个资源的地址可以被认为是一个URL（统一资源定位符）。 例如，URL的路径部分 scheme://a/b/c，可以被视为等同于一个RChain地址。 也就是说，一系列嵌套通道，每个通道都可以携带消息，其中命名通道 a 是“顶部”通道。

但是请注意，URL路径并不是都可以组成的。例如 scheme://a/b/c 和 scheme://a/b/d, 在传统的URL方案中，这两者不能通过组合生成一条路径。然而，每一个平坦路径都自动是树路径，并且，作为树，这些*可以*组合产生新的树 scheme://a/b/c+d 。 因此，树为资源寻址提供了一个可组合的模型。

../_images/namespaces-as-tree-paths.png

图-可组合的树路径

以上，统一可以作为一种树匹配和分解的算法，而基于统一的匹配和分解为查询提供了基础。 为了探索这个想法，让我们用这种形式重写路径/树的语法：

scheme://a/b/c+d ↦ s: a(b(c,d))

然后将语法调整为rho演算的I/O操作：

s!( a(b(c,d)) )

for( a(b(c,d)) <- s; if cond ){ P }

最上面的表达式表示输出—将资源地址 a(b(c,d) 放在命名通道 s 。下面的表达式表示输入。对于匹配形如 a(b(c,d)) 的模式，输入信道为 s，如果满足一些前提条件，执行后续部分 P，以地址 a(b(c,d) 作为一个参数。当然，这个表达式暗示 s 是一个命名信道。所以调整的通道结构可表示为：

../_images/namespaces-as-trees.png

图：树结构中嵌套通道的URL方案

鉴于现有的地址结构和命名空间访问逻辑，客户端可以查询并发送到该地址结构中的名称。 例如，当rho-演算的I/O进程被放置在并发执行环境中时，下面的表达式表示一个将被引用的进程 (@Q,@R) 放到位置 a(b(c,d)) ：

for( a(b(c,d)) <- s; if cond ){ P } | s!( a(b(@Q,@R)) )

求值过程可以被符号化地写为:

for( a(b(c,d)) <- s; if cond ){ P } | s!( a(b(@Q,@R)) ) → P{ @Q := c, @R := d }

也就是说，P 是在某个环境下执行的，其中 c 用于代替 @Q ， d 用于替换 @R 。更新后的树结构如下所示：

../_images/tree-structure-substituted.png

图：在通道中放置进程

除了有资格成为命名空间的平面通道集合外（例如 s1…sn ），每个具有内部结构的通道本身就是一个命名空间。 因此， s ， a 和 b 可以递增地施加单独的命名空间定义，类似于由平面命名空间给出的命名空间定义。 在实践中，命名通道的内部结构是一个任意深度和复杂度的n元树，其中“顶部”通道（在本例中为 s）只是 s1...sn 中这些拥有内部结构的众多可能的名称之一。

该资源寻址框架代表了对历史上使用最广泛的互联网寻址标准的一步步适应。 RChain通过命名空间实现了私有、公共以及联盟可见性所需的组合地址空间，但显而易见的用例是解决可伸缩性。绝非偶然，也不意外，命名空间也将为RChain的分片解决方案提供了一个框架。

[5]命名空间逻辑-适用于高阶反射演算的逻辑