管理分叉

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

分叉

分叉是从某个根（root）开始的一系列插槽。例如：

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

以下是分叉序列：

- {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。修剪后的本地分叉视图如下：

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

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

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

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

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