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在验算时得出不同的结果。 new code
表示在此区块执行过程中新增加(部署)的代码post state
则表示此区块执行完成后tuplespace改变后的状态如上所叙,RChain的一个区块包含了父级区块指针以及可验算的状态变化两个主要部分。通过一个一个区块的级联能够反应出Tuplespace状态变化的逻辑与次序, 如下图所示。
而在上一篇《名字空间》中介绍了RChain的名字空间就是名字(name)的集合。也就是说,一个名字空间对应一个逻辑上独立的tuplespace。因此, 每个名字空间需要一条单独的链来表示对应的tuplespace状态变迁。
例1: 有A和B两个Region, 那么它们组成的名字空间有{A, B, {A,B}, Ø}
。其中Ø
代表的grand namespace不需要validators进行监督。因此,在这个例子中会有如下三条并行的链结构。
细心的读者可能已经发现了区块结构中的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共识之估值函数》