diff --git a/docs/zh-cn/tooldev/concept/consensus/consensus_algorithm.md b/docs/zh-cn/tooldev/concept/consensus/consensus_algorithm.md
index ef27673dfc..41003d5843 100644
--- a/docs/zh-cn/tooldev/concept/consensus/consensus_algorithm.md
+++ b/docs/zh-cn/tooldev/concept/consensus/consensus_algorithm.md
@@ -202,28 +202,6 @@ dBFT 2.0算法包含6种共识消息：
 
 Change View Request，Recovery Request和Recovery Message机制能够避免网络原因导致的超时，异常节点（作恶节点，故障节点等非正常共识节点）等问题带来的影响。
 
-## dBFT 2.0 的容错性
-
-共识节点个数为*N*的dBFT2.0共识系统可以最多容忍*F*个异常节点。系统的每个共识操作（Commit，Change View，出块等）需要至少*M*个节点达成共识，只要系统中的正常共识节点不少于*M*，共识进程就可以不断进行下去。比如，在一个*N* = 4 的共识系统中，只需  4 − ⌊ (4−1) / 3 ⌋ =3  个正常共识节点，就可以保证系统的正常工作。
-
-## dBFT 2.0 的终局性
-
-dBFT 2.0针对旧版本可能产生分叉的问题进行修正，从根本上杜绝了分叉的可能性。这是由于：
-
-- 出块的必需条件包括，对于该新块提案，收到至少*M*个共识节点的Commit信息；
-
-- 已经发出Commit的共识节点将不会改变视图；
-
-
-因此产生一个新块意味着：
-
-- 已经有至少*M*个共识节点对该块的提案做过签名并发出Commit信息，且这些共识节点的视图不会变化；
-
-- 其他共识节点的数量不足产生另一个不同的区块。
-
-
-因此可以保证新块的唯一性。
-
 ## 共识策略
 
 共识流程中的以下场景会使用共识策略：
@@ -234,4 +212,4 @@ dBFT 2.0针对旧版本可能产生分叉的问题进行修正，从根本上杜
 
 - 启动共识时，需要使用共识策略对共识模块中的交易进行过滤。在将未确认的交易过滤后，才能将交易添加到内存池中；
 
-- 议长在生成新的Prepare Request时，需要通过共识策略从当前内存池中筛选出可以上链的交易。
\ No newline at end of file
+- 议长在生成新的Prepare Request时，需要通过共识策略从当前内存池中筛选出可以上链的交易。