Merge pull request Fankouzu#73 from STAJJJ/C-MF

doc:Managing Forks

docs/SolanaValidatorDocumentation/consensus/Managing-Forks.md

@@ -0,0 +1,59 @@
+# 管理分叉
+
+账本允许在插槽（slot）边界处分叉。由此形成的数据结构称为块存储（blockstore）。当验证者（validator）解析块存储时，必须为链中的每个分叉维护状态。验证者有责任权衡这些分叉，以便最终选择一个分叉。有关选择和投票这些分叉的详细信息，请参见[Tower Bft](https://docs.solanalabs.com/implemented-proposals/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
+```