Skip to content

管理分叉

账本允许在插槽(slot)边界处分叉。由此形成的数据结构称为块存储(blockstore)。当验证者(validator)解析块存储时,必须为链中的每个分叉维护状态。验证者有责任权衡这些分叉,以便最终选择一个分叉。有关选择和投票这些分叉的详细信息,请参见Tower Bft

分叉

分叉是从某个根(root)开始的一系列插槽。例如:

text
      2 - 4 - 6 - 8
     /
0 - 1       12 - 13
     \     /
      3 - 5
           \
            7 - 9 - 10 - 11

以下是分叉序列:

text
- {0, 1, 2, 4, 6, 8}
- {0, 1, 3, 5, 12, 13}
- {0, 1, 3, 5, 7, 9, 10, 11}

修剪和压缩

随着链的增长,存储本地分叉视图会对性能产生不利影响。幸运的是,我们可以利用塔BFT根(tower root)的属性来修剪此数据结构。回想一下,根是已达到最大锁定深度的插槽。假设该槽已经积累了足够的锁定,以至于不可能将其回滚。

因此,验证器会修剪不从其本地根起源的分叉,然后通过将任何可合并的节点压缩到根中来减少内存使用。虽然这对于共识不是必需的,但为了支持某些RPC用例,验证器选择保留其本地根的祖先节点,直到由集群绝大多数根植的最后一个槽。我们称之为超多数根(super majority root,SMR)。

从上面的示例开始,假设最大锁定深度为3。我们的验证器对槽0、1、3、5、7、9进行投票。在最终投票9之后,我们的本地根是3。假设最新的超多数根是0。修剪后的本地分叉视图如下:

text
SMR
 0 - 1       12 - 13
      \     /
       3 - 5
     ROOT   \
             7 - 9 - 10 - 11

现在假设我们对10进行投票,并且5成为根。同时,集群赶上了最新的超多数根,现在是3。修剪后的本地分叉视图如下:

text
             12 - 13
            /
       3 - 5 ROOT
      SMR   \
             7 - 9 - 10 - 11

最后,对11进行投票,7成为根,从而修剪掉最后一个分叉:

text
       3 - 5 - 7 - 9 - 10 - 11
      SMR     ROOT