RChain运行原理[4] - 区块结构与DAG

区块结构

RChain的区块结构如下图。

如上图所示，RChain的一个Block由下面这些项组成:

• Header 头部
  
  • parents hash ordered list 指向父级区块的列表
  • post state hash - Body中post state的哈希
  • new code hash - Body中new code的哈希
  • reductions/receipt hash - Body中reductions/receipt的哈希
• Body 主体
  
  • post state 采用Merkle Patricia Trie数据结构来表示tuplespace在此block执行完成后变化后的状态。
  • new code 在本区块中新增加(部署)的代码
  • reductions/receipts 本区块执行时采用的化简规则
• singnature 生成此块的矿工(validator)签名
• justifications 理据，在下一篇Casper中再介绍

在前面《消息机制》一文中已经解释了，rholang代码在RChain上的执行本质上是tuplespace状态的变化。
而一个矿工(validator)打包完区块后需要被其它矿工验证，因此区块中主体主要记录了此区块执行的相关信息以便验证。

• 其中reductions/receipts记录了此区块执行了哪些rholang term。因为Rholang可以编写出非确定性(non-deterministic)逻辑代码，比如for(x <- y)的无序性可能导致不同的validator在验算时得出不同的结果。
  因此，产生此块的矿工(validator)需要将它执行的rholang term的化简规则附带在此，以使其它矿工验算时能够得到确定性的结果。
• new code表示在此区块执行过程中新增加(部署)的代码
• post state则表示此区块执行完成后tuplespace改变后的状态

区块链

如上所叙，RChain的一个区块包含了父级区块指针以及可验算的状态变化两个主要部分。通过一个一个区块的级联能够反应出Tuplespace状态变化的逻辑与次序, 如下图所示。

而在上一篇《名字空间》中介绍了RChain的名字空间就是名字(name)的集合。也就是说，一个名字空间对应一个逻辑上独立的tuplespace。因此, 每个名字空间需要一条单独的链来表示对应的tuplespace状态变迁。

例1: 有A和B两个Region, 那么它们组成的名字空间有{A, B, {A,B}, Ø}。其中Ø代表的grand namespace不需要validators进行监督。因此，在这个例子中会有如下三条并行的链结构。

• 一个block中只会包含来自于一个namespace的状态变迁。
• 其中名字空间 A 和 AUB 的链由来自Region A的validators负责维护。
• 而名字空间 B 和 AUB 的链由来自Region B的validators负责维护。

DAG结构

细心的读者可能已经发现了区块结构中的parents hash ordered list是一个列表。
那么这就表示，一个区块是可以指向多个父级区块的，唯一要满足的条件是：一个区块的多个父级区块必须是来自于同一个名字空间的区块(但可以和当前区块的名字空间不同）。

例2：名字空间A中所有的矿工(validators)都有相同一份tuplespace，在执行rholang term时，一部分节点选择执行了引起b2->b3状态变化的代码；而另一部分节点选择执行了引起a2->a3状态变化的代码。
由于RhoCalculus的组合性(Composationality)原理，只要这些状态变化的集合不相交，就不会有任何冲突。因此那条单链也就成了下图中的有向无环图(Directed Acyclic Graph)结构。

综上，RChain每个namespace的tuplesace状态变迁由一条DAG链结构表示。
这不仅表示可无限增长的namespace带来的可扩展性，即使在一个namespace内部，RChain也是能够扩展并获得更高的吞吐率与并行度。而这一切都来源于RhoCalculus无与伦比的并行计算优势！

本文地址： https://blog.csdn.net/wangjia184/article/details/80687526
转载须注明出处

下一篇 《Casper共识之估值函数》