<doc>(sdk,intro,design): fix doc bugs. (#1693)

3.x/zh_CN/docs/design/guomi.md

@@ -9,14 +9,14 @@
 
 **国密版FISCO BCOS将交易签名验签、p2p网络连接、节点连接、数据落盘加密等底层模块的密码学算法均替换为国密算法**，国密版FISCO BCOS与标准版主要特性对比如下：
 
- | | 标准版FISCO BCOS | 国密版FISCO BCOS |
- | :-: | :-: | :-: |
- | SSL链接 | Openssl TLSv1.2协议 | 国密TLSv1.1协议|
- | 签名验证 | ECDSA签名算法 | SM2签名算法 |
- | 消息摘要算法 | SHA-256 SHA-3 | SM3消息摘要算法 |
- | 落盘加密算法 | AES-256加密算法 | SM4加密算法 |
- | 证书模式 | OpenSSL证书模式 | 国密双证书模式 |
- | 合约编译器 | 以太坊solidity编译器 | 国密solidity编译器 |
+ |              |   标准版FISCO BCOS   |  国密版FISCO BCOS  |
+ |:------------:|:--------------------:|:------------------:|
+ |   SSL链接    | Openssl TLSv1.2协议  |  国密TLSv1.1协议   |
+ |   签名验证   |    ECDSA签名算法     |    SM2签名算法     |
+ | 消息摘要算法 |    SHA-256 SHA-3     |  SM3消息摘要算法   |
+ | 落盘加密算法 |   AES-256加密算法    |    SM4加密算法     |
+ |   证书模式   |   OpenSSL证书模式    |   国密双证书模式   |
+ |  合约编译器  | 以太坊solidity编译器 | 国密solidity编译器 |
 
 (注：国密算法SM2, SM3, SM4均基于[国产密码学标准](http://www.gmbz.org.cn/main/bzlb.html)开发)
 
@@ -30,21 +30,20 @@
 
 国密版FISCO BCOS节点之间的认证选用国密SSL 1.1的ECDHE_SM4_SM3密码套件进行SSL链接的建立，差异如下表所示：
 
- | | OpenSSL | 国密SSL |
- | :-: | :-: | :-: |
- | 加密套件 | 采用ECDH、RSA、SHA-256、AES256等密码算法 | 采用国密算法 |
- | PRF算法 | SHA-256 | SM3 |
- | 密钥交换方式 | 传输椭圆曲线参数以及当前报文的签名 | 当前报文的签名和加密证书 |
- | 证书模式 | OpenSSL证书模式 | 国密双证书模式，分别为加密证书和签名证书 |
-
+ |              |                 OpenSSL                  |                 国密SSL                  |
+ |:------------:|:----------------------------------------:|:----------------------------------------:|
+ |   加密套件   | 采用ECDH、RSA、SHA-256、AES256等密码算法 |               采用国密算法               |
+ |   PRF算法    |                 SHA-256                  |                   SM3                    |
+ | 密钥交换方式 |    传输椭圆曲线参数以及当前报文的签名    |         当前报文的签名和加密证书         |
+ |   证书模式   |             OpenSSL证书模式              | 国密双证书模式，分别为加密证书和签名证书 |
 
 ## 数据结构差异
 
 国密版与标准版FISCO BCOS在数据结构上的差异如下：
 
- | 算法类型 | 标准版FISCO BCOS | 国密版FISCO BCOS |
- | :-: | :-: | :-: |
- | 签名 | ECDSA (公钥长度: 512 bits, 私钥长度: 256 bits)| SM2 (公钥长度：512 bits, 私钥长度：256 bits) |
- | 哈希 | SHA3 (哈希串长度: 256 bits) | SM3 (哈希串长度: 256 bits) |
- | 对称加解密 | AES (加密秘钥长度: 256 bits) | SM4 (对称密钥长度: 128 bits) |
- | 交易长度 | 520bits(其中标识符8bits,签名长度512bits) | 1024bits(128字节，其中公钥512bits,签名长度512bits) |
+ |  算法类型  |                标准版FISCO BCOS                |                  国密版FISCO BCOS                  |
+ |:----------:|:----------------------------------------------:|:--------------------------------------------------:|
+ |    签名    | ECDSA (公钥长度: 512 bits, 私钥长度: 256 bits) |    SM2 (公钥长度：512 bits, 私钥长度：256 bits)    |
+ |    哈希    |          SHA3 (哈希串长度: 256 bits)           |             SM3 (哈希串长度: 256 bits)             |
+ | 对称加解密 |          AES (加密秘钥长度: 256 bits)          |            SM4 (对称密钥长度: 128 bits)            |
+ |  交易长度  |    520bits(其中标识符8bits,签名长度512bits)    | 1024bits(128字节，其中公钥512bits,签名长度512bits) |

3.x/zh_CN/docs/design/hsm.md

@@ -5,20 +5,25 @@
 -----
 
 ## 一、密码机与GMT0018简介
+
 ### 密码机HSM
-硬件安全模块（Hardware security module，HSM）是一种用于保障和管理强认证系统所使用的数字密钥，并同时提供相关密码学操作的计算机硬件设备。硬件安全模块一般通过扩展卡或外部设备的形式直接连接到电脑或网络服务器。[词条](https://baike.baidu.com/item/%E7%A1%AC%E4%BB%B6%E5%AE%89%E5%85%A8%E6%A8%A1%E5%9D%97)。
+
+硬件安全模块（Hardware security module，HSM）是一种用于保障和管理强认证系统所使用的数字密钥，并同时提供相关密码学操作的计算机硬件设备。硬件安全模块一般通过扩展卡或外部设备的形式直接连接到电脑或网络服务器。
 
 ### GMT0018
+
 《GMT0018-2012 密码设备应用接口规范》是由国家密码管理局发布的，符合中国密码行业标准的一个密码设备应用接口规范。它为公钥密码基础设施应用体系框架下的服务类密码设备制定统一的应用接口标准，通过该接口调用密码设备，向上层提供基础密码服务。为该类密码设备的开发、使用及检测提供标准依据和指导，有利于提高该类密码设备的产品化、标准化和系列化水平。
 
 FISCO BCOS 2.8.0和FISCO BCOS 3.3.0版本引入了密码机功能。用户可以将密码放入密码机，通过密码机进行**共识签名**、**交易验签**。FISCO BCOS支持《GMT0018-2012 密码设备应用接口规范》的密码卡/密码机，支持SDF标准，这使得FISCO BCOS拥有更快的密码计算速度，更安全的密钥保护。
 
 ## 二、调用密码机的模块
+
 FISCO BCOS的共识和交易模块调用了密码机。
 共识、交易模块在签名时，调用`bcos-crypto`模块，`bcos-crypto`再调用`hsm-crypto`模块，最终调用到密码机API接口完成签名。其中涉及到的参数还有通过配置文件传入的密码机内置密钥索引keyIndex，最终调用密码机签名接口`SDF_InternalSign_ECC`。
 交易模块在验签时，同理调用`bcos-crypto`模块，`bcos-crypto`再调用`hsm-crypto`模块，最终调用到密码机API接口完成签名。最终调用密码机验签接口`SDF_ExternalVerify_ECC`。
 
 ### hsm-crypto模块
+
 hsm-crypto是个封装密码机API接口，使用C++实现的硬件加密模块（Hardware secure module），它能协助应用调用符合《GMT0018-2012密码设备通用接口规范》的PCI密码卡或者密码机进行国密算法SM2、SM3、SM4运算。FISCO BCOS节点，以及java-sdk都通过调用该模块，调用密码机API接口。[Github项目地址](https://github.com/WeBankBlockchain/hsm-crypto)
 
 至此，硬件密码机HSM的设计文档到此结束，关于FISCO BCOS和java-sdk如何使用密码机，请参考[构建使用硬件密码模块的国密链](../tutorial/air/use_hsm.md)

3.x/zh_CN/docs/design/network_compress.md

@@ -4,8 +4,7 @@
 
 ----
 
-外网环境下，区块链系统性能受限于网络带宽，为了尽量减少网络带宽对系统性能的影响，FISCO BCOS 3.0在`relase-3.1`支持p2p网络压缩功能，该功能主要在发送端进行p2p网络数据包压缩，在接收端将解包数据，并将解包后的数据传递给上层模块。该p2p网络压缩功能默认开启，无需通过配置项控制。
-
+外网环境下，区块链系统性能受限于网络带宽，为了尽量减少网络带宽对系统性能的影响，FISCO BCOS 3.0在`v3.1.0`支持p2p网络压缩功能，该功能主要在发送端进行p2p网络数据包压缩，在接收端将解包数据，并将解包后的数据传递给上层模块。该p2p网络压缩功能默认开启，无需通过配置项控制。
 
 ## 系统框架
 
@@ -15,16 +14,14 @@
 
 网络压缩主要包括两个过程：
 
-- **发送端压缩数据包**：群组层通过P2P层发送数据时，若数据包大小超过1KB，而且接收端节点是3.1及之后的版本，则压缩数据包后，更新标记位`ext`，编码后，将其发送到目标节点；
+- **发送端压缩数据包**：群组层通过P2P层发送数据时，若数据包大小超过1KB，而且接收端节点是3.1.0及之后的版本，则压缩数据包后，更新标记位`ext`，编码后，将其发送到目标节点；
 
 - **接收端解压数据包**：节点收到数据包后，解码，根据标记位`ext`判断收到的数据包是否被压缩，若数据包是压缩后的数据包，则将其解压，重置ext标记位。
 
-
 ## 核心实现
 
 综合考虑性能、压缩效率等，我们选取了[Zstd](https://github.com/facebook/zstd)来实现数据包压缩和解压功能。本节主要介绍网络压缩的实现。
 
-
 ### 数据压缩标记位
 
 FISCO BCOS的网络数据包结构如下图：
@@ -59,14 +56,13 @@ FISCO BCOS的网络数据包结构如下图：
 - 编码模块给packet加上包头，同时更新压缩标记位`ext`。即：若packet是压缩后的数据包，将`ext |=  0x0010`；
 - P2P将编码后的数据包传送到目的节点。
 
-**接收端处理流程：**
+**接收端处理流程**
 
 - 目标机器收到数据包后，解码模块分离出包头，通过判断包头ext字段，即`m_ext & 0x0010 == 0x0010`判断网络数据是否被压缩；
 - 若网络数据包被压缩过，则调用解压接口，对payload数据进行解压；
 - reset重置ext标记位，即`m_ext &= ~0x0010`，防止同个数据包被多次解压。
 
-
 ## 兼容性说明
 
 - **数据兼容**：不涉及存储数据的变更；
-- **网络兼容rc1**：向前兼容，仅有relase-3.1及以上节点具有网络压缩功能。
+- **网络兼容rc1**：向前兼容，仅有relase-3.1及以上节点具有网络压缩功能。

3.x/zh_CN/docs/design/security_control/node_management.md

@@ -165,11 +165,10 @@ CA黑名单机制也支持**SSL单向认证**的场景，作用时机是：节
     listen_ip=0.0.0.0
     ;p2p listen port
     listen_port=30300
-    ;nodes to connect
-    node.0=127.0.0.1:30300
-    node.1=127.0.0.1:30301
-    node.2=127.0.0.1:30302
-    node.3=127.0.0.1:30303
+    ; ssl or sm ssl
+    sm_ssl=false
+    nodes_path=./
+    nodes_file=nodes.json
     
 ;certificate blacklist
 [certificate_blacklist]
@@ -194,8 +193,8 @@ CA黑名单机制也支持**SSL单向认证**的场景，作用时机是：节
     ;consensus algorithm type, now support PBFT(consensus_type=pbft) and Raft(consensus_type=raft)
     consensus_type=pbft
     ;the max number of transactions of a block
-    max_trans_num=1000
-    ;the node id of leaders
+    block_tx_count_limit=1000
+    ;the node id of consensusers
     node.0=79d3d4d78a747b1b9e59a3eb248281ee286d49614e3ca5b2ce3697be2da72cfa82dcd314c0f04e1f590da8db0b97de466bd08e27eaa13f85df9b60e54d6a1ec8
     node.1=da527a4b2aeae1d354102c6c3ffdfb54922a092cc9acbdd555858ef89032d7be1be499b6cf9a703e546462529ed9ea26f5dd847110ff3887137541bc651f1c32
     node.2=160ba08898e1e25b31e24c2c4e3c75eed996ec56bda96043aa8f27723889ab774b60e969d9bd25d70ea8bb8779b7070521d9bd775dc7636f4b2b800d2fc8c7dd

3.x/zh_CN/docs/design/sync.md

@@ -6,23 +6,17 @@
 
 同步，是区块链节点非常重要的功能。它是共识的辅助，给共识提供必需的运行条件。同步分为交易的同步和状态的同步。交易的同步，确保了每笔交易能正确的到达每个节点上。状态的同步，能确保区块落后的节点能正确的回到最新的状态。只有持有最新区块状态的节点，才能参与到共识中去。
 
-## 交易同步
+## 交易广播
 
 交易同步，是让区块链的上的交易尽可能的到达所有的节点。为共识中将交易打包成区块提供基础。
 
-![](../../../../2.x/images/sync/tx.png)
-
-一笔交易（tx1），从客户端上发往某个节点，节点在接收到交易后，会将交易放入自身的交易池（TxPool）中供共识去打包。与此同时，节点会将交易广播给其它的节点，其它节点收到交易后，也会将交易放到自身的交易池中。交易在发送的过程中，会有丢失的情况，为了能让交易尽可能的到达所有的节点，收到广播过来交易的节点，会根据一定的策略，选择其它的节点，再进行一次广播。
-
-**交易广播策略**
-
-如果每个节点都没有限制的转发/广播收到的交易，带宽将被占满，出现交易广播雪崩的问题。为了避免交易广播的雪崩，FISCO BCOS根据经验，选择了较为精巧的交易广播策略。在尽可能保证交易可达性的前提下，尽量的减少重复的交易广播。
+一笔交易（tx1），从客户端上发往某个节点，节点在接收到交易后，会将交易放入自身的交易池（TxPool）中供共识去打包。与此同时，节点会将交易广播给其它的节点，其它节点收到交易后，也会将交易放到自身的交易池中。
 
 * 对于SDK来的交易，广播给所有的节点
-* 对于其它节点广播来的交易，随机选择25%的节点再次广播
+* 对于其它节点广播来的交易，直接放入交易池
 * 一条交易在一个节点上，只广播一次，当收到了重复的交易，不会进行二次广播
 
-通过上述的策略，能够尽量的让交易到达所有的节点，但也会在极小的概率下出现某交易无法到达某节点的情况。此情况是允许的。交易尽可能到达更多的节点，是为了让此交易尽快的被打包、共识、确认，尽量的让交易能够更快的得到执行的结果。当交易未到达某个节点时，只会使得交易的执行时间变长，不会影响交易的正确性。
+会在极小的概率下出现某交易无法到达某节点的情况，此情况是允许的。交易尽可能到达更多的节点，是为了让此交易尽快的被打包、共识、确认，尽量的让交易能够更快的得到执行的结果。当交易未到达某个节点时，只会使得交易的执行时间变长，不会影响交易的正确性。在共识流程中会验证leader打包的区块交易列表，如果本地有出现交易缺少的情况，则会主动向leader请求缺的交易。
 
 ## 状态同步
 
@@ -44,46 +38,59 @@
 
 ## 同步场景举例
 
-### 交易同步
+### 交易广播场景
 
 一笔交易被广播到所有节点的过程：
 
-- 一笔交易通过RPC发送到某节点上
-- 收到交易的节点全量广播此交易给其它节点
-- 其它节点收到交易后，为了保险起见，选择25%的节点再广播一次
-- 节点收到广播过的交易，不会再次广播
+* 一笔交易通过RPC发送到某节点上
+* 收到交易的节点全量广播此交易给其它节点
+* 节点收到广播过的交易，不会再次广播
+
+### 共识验证时缺交易同步场景
+
+在共识缺交易场景的过程：
+
+* 节点收到proposal后发现proposal列表中有缺交易
+* 会主动向proposal发起的节点请求缺的交易（单播）
+* 打包节点收到请求后返回缺少的交易（单播）
+
+### 交易池为空请求其他节点交易场景
+
+当节点交易池为空时，将会触发节点主动请求交易的场景：
+
+* 主动向所有节点广播onEmptyTxs的消息包（广播）
+* 其他节点收到消息包后，将会主动返回交易给请求节点（单播）
 
 ### 状态同步
 
 节点出块时的广播逻辑
 
-- 某个节点出块
-- 此节点将自己最新的状态（最新块高，最高块哈希，创世块哈希）广播给所有的节点
-- 其它的节点收到peer的状态后，更新在本地管理的peer数据
+* 某个节点出块
+* 此节点将自己最新的状态（最新块高，最高块哈希，创世块哈希）广播给所有的节点
+* 其它的节点收到peer的状态后，更新在本地管理的peer数据
 
 **组内成员的同步**
 
 组内成员在某时刻意外关闭，但其它成员在出块，当此组员再次启动时，发现区块落后于其它组员：
 
-- 组员再次启动
-- 收到其它组员发来的状态包
-- 比较发现自己的最高块高落后于其它组员，启动下载流程
-- 将相差的区块按区间划分成多个下载请求包，发送给多个组员，负载均衡
-- 等待其它节点回复区块包
-- 其它节点接受响应，从自己的区块链上查询出区块，回复给启动的节点
-- 节点收到区块，放入下载队列
-- 节点从下载队列中将区块拿出，写到区块链上
-- 若下载未结束，则继续请求，若下载结束，则切换自身状态，开启交易同步，开启共识
+* 组员再次启动
+* 收到其它组员发来的状态包
+* 比较发现自己的最高块高落后于其它组员，启动下载流程
+* 将相差的区块按区间划分成多个下载请求包，发送给多个组员，负载均衡
+* 等待其它节点回复区块包
+* 其它节点接受响应，从自己的区块链上查询出区块，回复给启动的节点
+* 节点收到区块，放入下载队列
+* 节点从下载队列中将区块拿出，写到区块链上
+* 若下载未结束，则继续请求，若下载结束，则切换自身状态，开启交易同步，开启共识
 
 **新组员的同步**
 
 非组员作为一个新组员加入到某个组中，且此节点第一次启动，从原来的组员中同步区块：
 
-- 非组员未被注册到组中，但非组员先启动
-- 此时发现自己不在组中，不进行状态广播，也不进行交易广播，只等待其它组员发来状态消息
-- 此时组员中并没有此新组员，不会向新组员广播状态
-- 管理员将新组员加入到组中
-- 组员向新组员广播自身状态
-- 新组员收到组员状态，比较自身块高（为0），启动下载流程
-- 之后的下载流程，与组内成员区块同步流程相同
-
+* 非组员未被注册到组中，但非组员先启动
+* 此时发现自己不在组中，不进行状态广播，也不进行交易广播，只等待其它组员发来状态消息
+* 此时组员中并没有此新组员，不会向新组员广播状态
+* 管理员将新组员加入到组中
+* 组员向新组员广播自身状态
+* 新组员收到组员状态，比较自身块高（为0），启动下载流程
+* 之后的下载流程，与组内成员区块同步流程相同