Update appendix

appendix/companies.md

-# 相关企业和组织
+## 相关企业和组织
 
 排名不分先后，大部分信息来自互联网，不保证信息准确性，如有修改意见，欢迎联系。
 
-## 国际
+### 国际
 
-### 企业
+#### 企业
 * [IBM](https://www.ibm.com): 贡献区块链平台代码到 HyperLedger 项目，推动区块链产业发展，跟多家银行和企业进行区块链项目合作。
 * [DTCC]():贡献区块链代码到 HyperLedger 项目。
-* [Circle]()：基于区块链的支付应用公司，已获得 6000 万美元 D 轮投资，投资者包括 IDG、百度、中金甲子、广大投资等，目前年交易额超过 10 亿美金；
+* [Circle]()：基于区块链的支付应用公司，已获得 6000 万美元 D 轮投资，投资者包括 IDG、百度、中金甲子、广大投资等，目前年交易额超过 10 亿美金。
 * [Consensus]()：区块链创业团队，试图打造区块链平台技术和应用支撑，获得多家投资。
 
-### 组织
+#### 组织
 * [R3 CEV](https://r3cev.com)：创立于 2015 年 9 月，总部位于纽约的金融联盟组织，专注于研究和评估基于区块链的金融技术解决方案，由 40 多家国际金融机构组成，包括 Citi、BOA、高盛、摩根、瑞银、IBM、微软等。R3 开源技术已经 [宣布](www.newsbtc.com/2016/10/22/r3-corda-hyperledger-open-source/) 加入 HyperLedger 项目。
 * [HyperLedger 社区]（https://hyperledger.org）：创立于 2015 年 12 月的技术社区，由 Linux 基金会管理，包括 IBM、Accenture、Intel、J.P.Morgan、R3、DAH、DTCC、FUJITSU、HITACHI、SWIFT、Cisco 等多家企业参与成立，试图打造面向企业应用场景的分布式账本平台。
 * [Ethereum 社区](https://ethereum.org): 围绕以太坊区块链平台的开放社区。
 * [DAO]()： Distributed Autonomous Organization，基于以太坊平台的公募基金(众筹)组织，或去中心化的风投。众筹资金超过 1.6 亿美金。
 
 
-## 国内
+### 国内
 
-### 学术界
+#### 学术界
 
 * 清华大学
 * 中科院
 * 上海交通大学
 
-### 企业
+#### 企业
 
 * [中国电信]()：研究区块链相关技术，包括去中心化共享经济平台等。
 * [世纪互联]()：投资区块链技术团队，牵头成立“中关村区块链产业联盟”。
@@ -39,7 +39,7 @@
 * [BitSe]()：主要产品为唯链（Vechain），面向物品防伪追踪、数字版权管理相关。
 * [万向集团]()：投资多家区块链创业团队，致力于推动产业发展。
 
-### 组织
+#### 组织
 
 * 中关村区块链产业联盟：2016 年 2 月 3 日成立于北京，由世纪互联联合清华大学、北京邮电大学等高校、中国通信学会、中国联通研究院等运营商，及集佳、布比网络等公司发起；
 * ChinaLedger：2016 年 4 月成立于上海，成员包括中证机构间报价系统股份有限公司、中钞信用卡产业发展有限公司北京智能卡技术研究院、万向区块链实验室、浙江股权交易中心、深圳招银前海金融资产交易中心、厦门国际金融资产交易中心、大连飞创信息技术有限公司、通联支付网络服务股份有限公司、上海矩真金融信息服务有限公司、深圳瀚德创客金融投资有限公司、乐视金融等；

appendix/faq.md

 ## 常见问题
 
 ### 通用问题
-** 问：区块链是谁发明的，安全么？**
+** 问：区块链是谁发明的，有什么特点？**
 
 答：区块链相关的思想最早是比特币的发明者-中本聪（化名）在论文中提出（但没有明确定义）作为比特币网络的核心支持技术。自那以后，区块链技术逐渐脱离比特币网络，成为一种通用的可以支持分布式记账能力的底层技术，具有去中心化和加密安全等特点。
 
-** 问：区块链和比特币是啥关系？**
+** 问：区块链和比特币是什么关系？**
 
 答：比特币是基于区块链技术的一种数字现金（cash）应用；区块链技术最早在比特币分布式系统中得到应用和验证，确保了比特币系统在 2009 年上线后，在完全自治情况下可以正常运转。
 
-** 问：区块链和分布式数据库是啥关系？**
+** 问：区块链和分布式数据库是什么关系？**
 
-答：两者定位完全不同。分布式数据库是解决分布式场景下的数据存储问题；区块链则是在多方（无需彼此信任）之间提供一套可信的记账和合约履行机制。
+答：两者定位完全不同。分布式数据库是解决高可用和可扩展场景下的数据存储问题；区块链则是在多方（无须中心化中介角色存在）之间提供一套可信的记账和合约履行机制。
 
 ** 问：区块链有哪些种类？**
 
-答：根据参与者的不同，可以分为公开链、联盟链和私有链。从功能上看，可以分为以货币交易为主的初代区块链（如比特币网络）、支持智能合约的二代区块链（如以太坊网络）、面向复杂商业应用场景支持链上代码的新一代区块链或分布式账本（如超级账本）。
+答：根据部署场景公开程度，可以分为公有链（Public Chain）、联盟链（Consortium Chain）和私有链（Private Chain）；从功能上看，可以分为以支持数字货币为主的数字货币区块链（如比特币网络）、支持智能合约的通用区块链（如以太坊网络）、面向复杂商业应用场景支持权限管理的分布式账本平台（如超级账本）。
 
 ** 问：（公有链情况下）区块链是如何保证没有人作恶的？ **
 
 答：区块链并没有试图保障每一个人都不作恶，每个参与者都默认在最长的链上进行扩展。当某个作恶者尝试延续一个非法链的时候，实际上在跟所有的“非作恶”者进行竞争。因此，当作恶者超过一半（还要保持选择一致）时，在概率意义上才能破坏规则。而代价是一旦延续失败，所有付出的资源（例如算力）都将浪费掉。
 
-### 比特币网络
+** 问：区块链的智能合约应该怎么设计？**
+
+答：首先，智能合约类似其它应用程序，在架构上即可以采取 monolithic 的方式（一个合约针对一个具体商业应用，功能完善而复杂），也可以采取 microservice 的方式（即每个合约功能单一，多个合约一起构建应用）。 选择哪种模式根本上取决于其上商业应用的特点。从灵活性角度，推荐适当对应用代码进行切分，划分到若干个智能合约，尽量保持智能合约的可复用性。
+
+** 问：如何查看 PEM 格式证书内容？**
+
+答：可以通过如下命令转换证书内容进行输出：`openssl x509 -noout -text -in <ca_file>`；例外，还可以通过如下命令来快速从证书文件中提取所证明的公钥内容：`openssl x509 -noout -pubkey -in <ca_file>`。
+
+** 问：已知私钥，如何生成公钥？**
+
+答：对于椭圆曲线加密算法，可以通过如下命令生成公钥：`openssl ec -pubout -outform PEM -in <private_key>`。
+
+** 问：如何校验某证书是否被根证书签名？**
+
+答：已知根证书文件 <root_cafile> 和待验证证书文件 <ca_to_verify> 情况下，可以使用如下命令进行验证：`openssl verify -CAfile <root_cafile> <ca_to_verify>`。
+
+** 问：为何 Hash 函数将任意长的文本映射到定长的摘要，很少会发生冲突？**
+
+答：像 SHA-1 这样的 Hash 函数可以将任意长的文本映射到相对很短的定长摘要。从理论上讲，从一个很大的集合映射到一个小的集合上必然会出现冲突。Hash 函数之所以很少出现冲突的原因在于虽然输入的数据长度可以很大，但其实人类产生的数据并非全空间的，这些数据往往是相对有序（低熵值）的，实际上也是一个相对较小的集合。当然，这个集合自身可能比输出的结果要大，但这个冲突的概率远没有输入是全空间集合时那么夸张。
+
+### 比特币、以太坊相关
 
 ** 问：比特币区块链为何要设计为每 10 分钟才出来一个块，快一些不可以吗？**
 
-答：这个主要是从公平的角度，当某一个新块被计算出来后，需要在全球的比特币网络内公布，临近的矿工将最先拿到消息并开始计算，较远的矿工则较晚得到通知。最坏情况下，可能需要数十秒的延迟。为尽量确保矿工们都处在同一起跑线上，这个时间不能太短。但太长了又会导致每个交易的“最终”确认时间过长，目前看，10 分钟左右是一个相对合适的折中。另外，也是从存储代价的角度，让拥有不太大存储的普通节点可以参与到网络的维护。
+答：这个主要是从公平的角度，当某一个新块被计算出来后，需要在全球的比特币网络内公布。临近的矿工将最先拿到消息并开始新一轮的计算，较远的矿工则较晚得到通知。最坏情况下，可能需要数十秒的延迟。为尽量确保矿工们都处在同一起跑线上，这个时间不能太短。但太长了又会导致每个交易的“最终”确认时间过长，目前看，10 分钟左右是一个相对合适的折中。另外，也是从存储代价的角度，让拥有不太大存储的普通节点可以参与到网络的维护。
 
 ** 问：比特币区块链每个区块大小为何是 1 MB，大一些不可以吗？**
 
-答：这个也是折中的结果。区块产生的平均时间间隔是固定的 10 分钟，大一些，意味着发生交易的吞吐量可以增加，但节点进行验证的成本会提高（hash 处理约为 100 MB/s），同时存储整个区块链的成本会快速上升。1 MB，意味着每秒可以记录 $$\frac{1 MB}{10\cdot 60}=1.7 KB$$ 的交易数据，而一般的交易数据大小在 0.2 ~ 1 KB。
+答：这个也是折中的结果。区块产生的平均时间间隔是固定的 10 分钟，大一些，意味着发生交易的吞吐量可以增加，但节点进行验证的成本会提高（Hash 处理约为 100 MB/s），同时存储整个区块链的成本会快速上升。区块大小为 1 MB，意味着每秒可以记录 1 MB/(10*60)=1.7 KB 的交易数据，而一般的交易数据大小在 0.2 ~ 1 KB。
+
+实际上，之前比特币社区也曾多次讨论过改变区块大小的提案，但都未被最终接受。
 
-实际上，之前社区也曾多次讨论过改变区块大小的提案，但都未被最终接受。
+** 问：以太坊网络跟比特币网络有何关系？ **
+
+答：以太坊网络所采用的区块链结构，源于比特币网络。基于同样设计原理上，以太坊提出了许多改善设计，包括支持更灵活的智能合约、支持除了 PoW 之外的更多共识机制（尚未实现）等。
 
 ### 超级账本项目
 
@@ -39,7 +63,18 @@
 
 答：超级账本是首个面向联盟链场景的开源项目，在这种场景下，参与账本的多方存在一定的信任前提，并十分看重对接入账本各方的权限管理、审计功能、传输数据的安全可靠等特性。超级账本在考虑了商业网络的这些复杂需求后，提出了创新的架构和设计，是首个在企业应用场景中得到大规模部署和验证的开源项目。
 
-** 问：Hyperledger Fabric 啥时候能出来？**
+** 问：区块链最早是公有链形式，为何现在联盟链在很多场景下得到更多推崇？**
+
+答：区块链技术出现以前，中心化的信任机制可以实现很高的性能和便捷的监管，但一旦中心机制出现故障，则导致系统的信任前提发生破坏。区块链技术可以提供无中介化情况下的信任保障。公有链情况下，任何人都可以参与监督，可以实现信任的最大化，但随之而来带来包括性能低下、缺乏监管等问题。
+
+联盟链在两者之间取得了平衡。非中心化的联盟共识，让系统可信任度以指数形式增加；同时，联盟形成的信任前提，可以在不影响信任的情况下实现更优化的性能，并支持权限管理。这对复杂应用场景特别企业场景可以提供更好的支持。
+
+** 问：采用 BFT 类共识算法时，节点掉线后重新加入网络，出现无法同步情况？**
+
+答：这是某些算法设计导致的情况。掉线后的节点重新加入到网络中，其视图（View）会领先于其它节点。其它节点正常情况下不会发生视图的变更，发生的交易和区块内容不会同步到掉线节点。出现这种情况，可以有两种解决方案：一个是强迫其它节点出现视图变更，例如也发生掉线或者在一段时间内强制变更；另一种情况是等待再次产生足够多的区块后触发状态追赶。
+
+** 问：超级账本 Fabric 里的安全性和隐私性是如何保证的？**
 
-答：作为首个实验稳定版本的 v0.6 已经被许多场景下进行验证使用，根据得到的企业场景反馈，目前社区设计了新的 1.0 架构，在可扩展性、安全性、性能等方面做了改进。Fabric 预计在 2017 年 3 月内发布 1.0 beta 版本，修复 bug 和稳定后即推出 1.0 正式版本。
+答：首先，Fabric 1.0 及往后的版本提供了对多通道的支持，不同通道之间的链码和交易是不可见的，即交易只会发送到该通道内的 Peer 节点。此外，在进行背书阶段，客户端可以根据背书策略来选择性的发送交易到通道内的某些特定 Peer 节点。更进一步的，用户可以对交易的内容进行加密（基于证书的权限管理）或 Hash 处理，同时，只有得到授权的节点或用户才能访问到交易。另外，排序节点无须访问到交易内容，因此，可以选择不将完整交易（对交易输入数据进行隐藏，或者干脆进行加密或 Hash 处理）发送到排序节点。最后，所有数据在传输过程中可以通过 TLS 来进行安全保护。许多层级的保护需要配合使用来获得不同层级的安全性。
 
+实践过程中，也需要对节点自身进行安全保护，通过防火墙、IDS 等防护对节点自身的攻击；另外可以通过审计和分析系统对可疑行为进行探测和响应。

appendix/grpc.md

 ## ProtoBuf 与 gRPC
-[ProtoBuf](https://github.com/google/protobuf) 是一套接口描述语言（[IDL](https://en.wikipedia.org/wiki/Interface_description_language)）和相关工具集（主要是 [protoc](https://github.com/google/protobuf)，基于 C++ 实现），类似 Apache 的 [Thrift](https://thrift.apache.org/)）。用户写好 `.proto` 描述文件，之后使用 protoc 可以很容易编译成众多计算机语言（C++、Java、Python、C#、Golang 等）的接口代码。这些代码可以支持 gRPC，也可以不支持。
+[ProtoBuf](https://github.com/google/protobuf) 是一套接口描述语言（[Interface Definition Language，IDL](https://en.wikipedia.org/wiki/Interface_description_language)），类似 Apache 的 [Thrift](https://thrift.apache.org/)。
 
-[gRPC](https://github.com/grpc/grpc) 是 Google 开源的 RPC 框架和库，已支持主流计算机语言。底层通信采用 gRPC 协议，比较适合互联网场景。gRPC 在设计上考虑了跟 ProtoBuf 的配合使用。
+相关处理工具主要是 [protoc](https://github.com/google/protobuf)，基于 C++ 语言实现。
 
-两者分别解决的不同问题，可以配合使用，也可以分开。
+用户写好 `.proto` 描述文件，之后便可以使用 protoc 自动编译生成众多计算机语言（C++、Java、Python、C#、Golang 等）的接口代码。这些代码可以支持 gRPC，也可以不支持。
 
-典型的配合使用场景是，写好 `.proto` 描述文件定义 RPC 的接口，然后用 protoc（带 gRPC 插件）基于 .proto 模板自动生成客户端和服务端的接口代码。
+[gRPC](https://github.com/grpc/grpc) 是 Google 开源的 RPC 框架和库，已支持主流计算机语言。底层通信采用 HTTP2 协议，比较适合互联网场景。gRPC 在设计上考虑了跟 ProtoBuf 的配合使用。
+
+两者分别解决不同问题，可以配合使用，也可以分开单独使用。
+
+典型的配合使用场景是，写好 `.proto` 描述文件定义 RPC 的接口，然后用 protoc（带 gRPC 插件）基于 `.proto` 模板自动生成客户端和服务端的接口代码。
 
 ### ProtoBuf
 
 需要工具主要包括：
 
-* 编译器：[protoc](https://github.com/google/protobuf)，以及一些官方没有带的语言插件；
+* 编译工具：[protoc](https://github.com/google/protobuf)，以及一些官方没有带的语言插件；
 * 运行环境：各种语言的 protobuf 库，不同语言有不同的安装来源；
 
-语法类似 C++ 语言，可以参考 [语言规范](https://developers.google.com/protocol-buffers/docs/proto)。
+语法类似 C++ 语言，可以参考 ProtoBuf 语言规范：[https://developers.google.com/protocol-buffers/docs/proto](https://developers.google.com/protocol-buffers/docs/proto)。
 
 比较核心的，`message` 是代表数据结构（里面可以包括不同类型的成员变量，包括字符串、数字、数组、字典……），`service` 代表 RPC 接口。变量后面的数字是代表进行二进制编码时候的提示信息，1~15 表示热变量，会用较少的字节来编码。另外，支持导入。
 
-默认所有变量都是可选的（optional），repeated 则表示数组。主要 service rpc 接口只能接受单个 message 参数，返回单个 message；
+默认所有变量都是可选的（optional），repeated 则表示数组。主要 service rpc 接口接受单个 message 参数，返回单个 message。如下所示。
 
 ```protobuf
 syntax = "proto3";
@@ -38,9 +42,9 @@ service HelloService {
 }
 ```
 
-编译最关键参数是指定输出语言格式，例如，python 为 `--python_out=OUT_DIR`。
+编译最关键的参数是输出语言格式参数，例如，python 为 `--python_out=OUT_DIR`。
 
-一些还没有官方支持的语言，可以通过安装 protoc 对应的 plugin 来支持。例如，对于 go 语言，可以安装
+一些还没有官方支持的语言，可以通过安装 protoc 对应的 plugin 来支持。例如，对于 Go 语言，可以安装
 
 ```sh
 $ go get -u github.com/golang/protobuf/{protoc-gen-go,proto} // 前者是 plugin；后者是 go 的依赖库
@@ -52,23 +56,24 @@ ProtoBuf 提供了 `Marshal/Unmarshal` 方法来将数据结构进行序列化
 
 ### gRPC
 
-工具主要包括：
-
-* 运行时库：各种不同语言有不同的 [安装方法](https://github.com/grpc/grpc/blob/master/INSTALL.md)，主流语言的包管理器都已支持。
-* protoc，以及 grpc 插件和其它插件：采用 ProtoBuf 作为 IDL 时，对 .proto 文件进行编译处理。
+相关工具主要包括：
 
-[官方文档](http://www.grpc.io/docs/) 写的挺全面了。
+* 运行时库：各种不同语言有不同的[安装方法](https://github.com/grpc/grpc/blob/master/INSTALL.md)，主流语言的包管理器都已支持。
+* protoc，以及 gRPC 插件和其它插件：采用 ProtoBuf 作为 IDL 时，对 .proto 文件进行编译处理。
 
 类似其它 RPC 框架，gRPC 的库在服务端提供一个 gRPC Server，客户端的库是 gRPC Stub。典型的场景是客户端发送请求，同步或异步调用服务端的接口。客户端和服务端之间的通信协议是基于 HTTP2 的 [gRPC](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md) 协议，支持双工的流式保序消息，性能比较好，同时也很轻。
 
-采用 ProtoBuf 作为 IDL，则需要定义 service 类型。生成客户端和服务端代码。用户自行实现服务端代码中的调用接口，并且利用客户端代码来发起请求到服务端。一个完整的例子可以参考 [这里](https://github.com/grpc/grpc-go/blob/master/examples/helloworld/)。
+采用 ProtoBuf 作为 IDL，则需要定义 service 类型。生成客户端和服务端代码。用户自行实现服务端代码中的调用接口，并且利用客户端代码来发起请求到服务端。一个完整的例子可以参考 [https://github.com/grpc/grpc-go/blob/master/examples/helloworld](https://github.com/grpc/grpc-go/blob/master/examples/helloworld/)。
 
-以上面 proto 文件为例，需要执行时添加 grpc 的 plugin：
+以上面 proto 文件为例，需要执行时添加 gRPC 的 plugin：
 
 ```sh
 $ protoc --go_out=plugins=grpc:. hello.proto
 ```
 
+gRPC 更多原理可以参考[官方文档：http://www.grpc.io/docs](http://www.grpc.io/docs/)。
+
+
 #### 生成服务端代码
 
 服务端相关代码如下，主要定义了 HelloServiceServer 接口，用户可以自行编写实现代码。

appendix/resources.md

-## 资源链接
+## 参考资源链接
 
 ### 论文
 
-* 中本聪 / 比特币：[一种点对点的电子现金系统](https://bitcoin.org/bitcoin.pdf)；
-* 闪电网络：[The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments](https://lightning.network/lightning-network-paper.pdf)；
+* L. Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System,” Commun. ACM, vol. 21, no. 7, pp. 558–565, 1978.
+* M Pease, R Shostak, L Lamport. Reaching Agreement in the Presence of Faults. Journal of the ACM, 1980, 27(2): 228-234.
+* M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of Distributed Consensus with One Faulty Process,” J. ACM, vol. 32, no. 2, pp. 374–382, 1985.
+* L. Lamport, “The Part-Time Parliament,” ACM Trans. Comput. Sys-tems, vol. 16, no. 2, pp. 133–169, 1998.
+* M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” Proc. Symp. Oper. Syst. Des. Implement., no. February, pp. 1–14, 1999.
+* 中本聪，"Bitcoin: A Peer-to-Peer Electronic Cash System（比特币：一种点对点的电子现金系统）"，https://bitcoin.org/bitcoin.pdf，2008.
+A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille, “Enabling Blockchain Innovations with Pegged Sidechains,” pp. 1–25, 2014.
+* T. D. Joseph Poon, “The Bitcoin Lightning Network: Scalable Off-Chain Payments, http://lightning.network/lightning-network-paper.pdf,” pp. 1–59, 2016.
+* Gentry C., Halevi S.，"Implementing Gentry’s Fully-Homomorphic Encryption Scheme". In: Paterson K.G. (eds) Advances in Cryptology – EUROCRYPT 2011. EUROCRYPT 2011. Lecture Notes in Computer Science, vol 6632. Springer, Berlin, Heidelberg.
+* van Dijk M., Gentry C., Halevi S., Vaikuntanathan V., "Fully Homomorphic Encryption over the Integers". In: Gilbert H. (eds) Advances in Cryptology – EUROCRYPT 2010. EUROCRYPT 2010. Lecture Notes in Computer Science, vol 6110. Springer, Berlin, Heidelberg.
+* López-Alt, Adriana, Eran Tromer, and Vinod Vaikuntanathan. "On-the-Fly Multiparty Computation on the Cloud via Multikey Fully Homomorphic Encryption.". Proceeding STOC '12 Proceedings of the forty-fourth annual ACM symposium on Theory of computing, Pages 1219-1234.
+* I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoin: Anonymous distributed e-cash from bitcoin,” Proc. - IEEE Symp. Secur. Priv., pp. 397–411, 2013.
+* F. Reid and M. Harrigan, “An analysis of anonymity in the bitcoin system,” Secur. Priv. Soc. Networks, pp. 197–223, 2013.
+* K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier, N. Kobeissi, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. Zanella-Béguelin, “Formal Verification of Smart Contracts,” 2016.
 
-### 项目工具
+### 项目网站
 
-* [blockchain.info](https://blockchain.info)：比特币信息统计网站；
-* [bitcoin.it](https://en.bitcoin.it)：比特币 wiki，相关知识介绍；
-* 以太坊项目：https://www.ethereum.org；
-* 以太坊网络的统计：https://etherchain.org/
-* Hyperledger 项目：[https://hyperledger.org](https://hyperledger.org);
-* Hyperledger Docker 镜像：[https://hub.docker.com/r/hyperledger/](https://hub.docker.com/r/hyperledger/)；
+* 比特币项目官方网站：https://bitcoin.org/。
+* [blockchain.info](https://blockchain.info)：比特币信息统计网站。
+* [bitcoin.it](https://en.bitcoin.it)：比特币 wiki，相关知识介绍。
+* 以太坊项目官方网站：https://www.ethereum.org。
+* 以太坊网络的状态统计：https://etherchain.org/
+* 超级账本项目官方网站：[https://hyperledger.org](https://hyperledger.org);
+* 超级账本 Docker 镜像：[https://hub.docker.com/r/hyperledger/](https://hub.docker.com/r/hyperledger/)。
 
 ### 培训课程
 
-* [Bitcoin and Cryptocurrency Technologies](https://www.coursera.org/course/bitcointech), Princeton University；
+* [Bitcoin and Cryptocurrency Technologies](https://www.coursera.org/course/bitcointech), Princeton University。
 
 ### 区块链即服务
-* [Bluemix BaaS](https://console.ng.bluemix.net/catalog/services/blockchain/)
-* [SV BaaS](https://crl.ptopenlab.com:8800/bc/)
+* [IBM Bluemix BaaS](https://console.ng.bluemix.net/catalog/services/blockchain/)： https://console.ng.bluemix.net/catalog/services/blockchain/。
+* [微软 Azure BaaS](https://azure.microsoft.com/en-us/solutions/blockchain)：https://azure.microsoft.com/en-us/solutions/blockchain。

appendix/terms.md

@@ -2,54 +2,80 @@
 
 ### 通用术语
 
-* Blockchain：区块链，基于密码学的可实现信任化的信息存储和处理技术。
-* CA：Certificate Authority，负责证书的创建、颁发，在 PKI 体系中最为核心的角色。
-* Chaincode：链上代码，运行在区块链上提前约定的智能合约，支持多种语言实现。
-* Decentralization（去中心化）：无需一个第三方的中心机构存在。
+* Blockchain（区块链）：基于密码学的可实现信任化的信息存储和处理的结构和技术。
+* Byzantine Failure（拜占庭错误）：指系统中存在除了消息延迟或不可送达的故障以外的错误，包括消息被篡改、节点不按照协议进行处理等，潜在地会对系统造成针对性的破坏。
+* CDN：Content Delivery Network，内容分发网络。利用在多个地理位置预先配置的缓存服务器，自动从距离近的缓存服务器进行对请求的响应，以实现资源的快速分发。
+* Consensus（共识）：分布式系统中多个参与方对某个信息达成一致，多数情况下为对发生事件的顺序达成一致。
+* Decentralization（去中心化）：无需一个独立第三方的中心机构存在，有时候也叫多中心化。
 * Distributed（分布式）：非单体中央节点的实现，通常由多个个体通过某种组织形式联合在一起，对外呈现统一的服务形式。
-* Distributed Ledger：分布式账本，由多家联合维护的去中心化（或多中心化）的账本记录平台。
-* DLT：Distributed Ledger Technology，分布式账本技术，包括区块链、权限管理等在内的实现分布式账本的技术。
-* DTCC：Depository Trust and Clearing Corporation，存托和结算公司，全球最大的金融交易后台服务机构。
+* Distributed Ledger（分布式账本）：由多家联合维护的去中心化（或多中心化）的账本记录平台。
+* DLT：Distributed Ledger Technology，分布式账本技术。包括区块链、权限管理等在内的实现分布式账本的技术。
+* DTCC：Depository Trust and Clearing Corporation，存托和结算公司。全球最大的金融交易后台服务机构。
 * Fintech：Financial Technology，跟金融相关的（信息）技术。
-* Hash：哈希算法，任意长度的二进制值映射为较短的固定长度的二进制值的算法。
-* Lightning Network：闪电网络，通过链外的微支付通道来增大交易吞吐量的技术。
+* Gossip：一种 P2P 网络中多个节点之间进行数据同步的协议，如随机选择邻居进行转发。
+* LDAP：Lightweight Directory Access Protocol，轻量级目录访问协议，是一种为查询、搜索业务而设计的分布式数据库协议，一般具有优秀的读性能，但写性能往往较差。
 * Market Depth（市场深度）：衡量市场承受大额交易后汇率的稳定能力，例如证券交易市场出现大额交易后价格不出现大幅波动。
-* Nonce：密码学术语，表示一个临时的值，多为随机字符串。
+* MTBF：Mean Time Between Failures，平均故障间隔时间，即系统可以无故障运行的预期时间。
+* MTTR：Mean Time to Repair，平均修复时间，即发生故障后，系统可以恢复到正常运行的预期时间。
+* MVCC：Multi-Version Concurrency Control，多版本并发控制。数据库领域的技术，通过引入版本来实现并发更新请求的乐观处理，当更新处理时数据版本跟请求中注明版本不一致时则拒绝更新。发生更新成功则将数据的版本加一。
+* Non-validating Peer（非验证节点）：不参与账本维护，仅作为交易代理响应客户端的请求，并对交易进行一些基本的有效性检查，之后转发给验证节点。
 * P2P：点到点的通信网络，网络中所有节点地位均等，不存在中心化的控制机制。
-* PKI：Public key infrastructure，基于公钥体系的安全基础架构。
-* Smart Contract：智能合约，运行在区块链上提前约定的合同；
-* Sybil Attack（女巫攻击）：少数节点通过伪造或盗用身份伪装成大量节点，进而对分布式系统系统进行破坏。
+* SLA/SLI/SLO：Service Level Agreement/Indicator/Objective，分别描述服务可用性对用户的承诺，功能指标和目标值。
 * SWIFT：Society for Worldwide Interbank Financial Telecommunication，环球银行金融电信协会，运营世界金融电文网络，服务银行和金融机构。
 * Turing-complete（图灵完备）：指一个机器或装置能用来模拟图灵机（现代通用计算机的雏形）的功能，图灵完备的机器在可计算性上等价。
+* Validating Peer（验证节点）：维护账本的核心节点，参与一致性维护、对交易的验证和执行。更进一步可以划分为 Endorser、Committer 等多种角色。
 
+### 密码学与安全相关
+* ASN.1：Abstract Syntax Notation One，定义了描述数据的表示、编码、传输、解码的一套标准，被广泛应用在计算机、通信和安全领域。
+* CA：Certificate Authority，负责证书的创建、颁发，在 PKI 体系中最为核心的角色。
+* CRL：Certification Revocation List，证书吊销列表，包含所撤销的证书列表。
+* CSR：Certificate Signing Request，证书签名申请，包括通用名、名称、主机、生成私钥算法和大小、CA 配置和序列号等信息，用来发给 CA 服务以颁发签名的证书。
+* DER：Distinguished Encoding Rules，ASN.1 中定义的一种二进制编码格式，可以用来保存证书或密钥内容。
+* Genesis Block：创世区块，区块链的第一个区块，一般用于初始化，不带有交易信息。
+* Hash：哈希算法，任意长度的二进制值映射为较短的固定长度的二进制值的算法。
+* IES：Integrated Encryption Scheme，集成加密机制，一种混合加密机制，可以应对选择明文攻击（可以获知任意明文和对应密文）情况下的攻击。包括 DLIES（基于离散对数）和 ECIES（基于椭圆曲线）两种实现。
+* Nonce：密码学术语，表示一个临时的值，多为随机字符串。
+* OCSP：Online Certificate Status Protocol，在线证书状态协议，通过查询服务来在线确认证书的状态（如是否撤销）。RFC 2560 中定义。
+* PKCS：Public-Key Cryptography Standards，公钥密码标准，由 RSA 实验室提出，定义了利用 RSA 算法和相关密码学技术来实现安全的系列规范，目前包括 15 个不同领域的规范。最早的版本在 1991 年提出，目前最新版本为 2012 年提出的 2.2 版本。
+* PEM：Privacy Enhanced Mail，用来保存证书和密钥的一种编码格式，RFC 1421-1424 中定义。
+* PKI：Public Key Infrastructure，基于公钥体系的安全基础架构。
+* SM：国家商用密码算法，2010 年以来陆续由国家密码管理局发布的相关标准和规范，主要包括：SM2（基于椭圆曲线密码的公钥密码算法标准）、SM3（Hash 算法标准）、SM4（基于分组加密的对称密码算法标准）、SM9（基于身份的数字证书体系）。
 
 ### 比特币、以太坊相关术语
 
-* Bitcoin：比特币，中本聪发起的数字货币技术。
-* DAO：Decentralized Autonomous Organization，分布式自治组织，基于区块链的按照智能合约联系起来的松散众筹群体。
-* Mining（挖矿）：通过暴力尝试来找到一个字符串，使得它加上一组交易信息后的 hash 值符合特定规则（例如前缀包括若干个 0），找到的人可以宣称新区块被发现，并获得系统奖励的比特币。
+* Bitcoin（比特币）：最早由中本聪提出和实现的基于区块链思想的数字货币技术。
+* DAO：Decentralized Autonomous Organization，分布式自治组织，基于区块链的按照智能合约联系起来的松散自治群体。
+* Lightning Network（闪电网络）：通过链外的微支付通道来增大交易吞吐量的技术。
+* Mining（挖矿）：通过暴力尝试来找到一个字符串，使得它加上一组交易信息后的 Hash 值符合特定规则（例如前缀包括若干个 0），找到的人可以宣称新区块被发现，并获得系统奖励的数字货币。
 * Miner（矿工）：参与挖矿的人或组织。
-* Mining Machine（矿机）：专门为比特币挖矿而设计的设备，包括基于软件、GPU、FPGA、专用芯片等多种实现。
-* Mining Pool（矿池）：采用团队协作方式来集中算力进行挖矿，对产出的比特币进行分配。
-* PoW：Proof of Work，工作量证明，在一定难题前提下求解一个 SHA256 的 hash 问题。
-
+* Mining Machine（矿机）：专门为数字货币挖矿而设计的设备，包括基于软件、GPU、FPGA、专用芯片等多种实现。
+* Mining Pool（矿池）：采用团队协作方式来集中算力进行挖矿，对产出的数字货币进行分配。
+* PoS：Proof of Stake，股份持有证明，拥有代币或股权越多的用户，挖到矿的概率越大。
+* PoW：Proof of Work，工作量证明，在一定难题前提下求解一个 SHA256 的 Hash 问题。
+* Smart Contract（智能合约）：运行在区块链上的提前约定的合同；
+* Sybil Attack（女巫攻击）：少数节点通过伪造或盗用身份伪装成大量节点，进而对分布式系统系统进行破坏。
 
-### Hyperledger 相关术语
+### 超级账本相关术语
 
+* Anchor（锚定）：一般指作为刚启动时候的初始联络元素或与其它结构的沟通元素。如刚加入一个通道的节点，需要通过某个锚点节点来快速获取通道内的情况（如其它节点的存在信息）。
 * Auditability（审计性）：在一定权限和许可下，可以对链上的交易进行审计和检查。
 * Block（区块）：代表一批得到确认的交易信息的整体，准备被共识加入到区块链中。
-* Blockchain（区块链）：由多个区块链接而成的链表结构，除了首个区块，每个区块都包括前继区块内容的 hash 值。
-* Chaincode（链码）：区块链上的应用代码，扩展自“智能合约”概念，支持 golang、nodejs 等。
-* Committer（提交节点）：1.0 架构中一种 peer 节点角色，负责对 orderer 排序后的交易进行检查，选择合法的交易执行并写入存储。
+* Blockchain（区块链）：由多个区块链接而成的链表结构，除了初始区块，每个区块头部都包括前继区块内容的 Hash 值。
+* Chaincode（链码）：区块链上的应用代码，扩展自“智能合约”概念，支持 Golang、Nodejs 等语言，多为图灵完备。
+* Channel（通道）：Fabric 网络上的私有隔离机制。通道中的链码和交易只有加入该通道的节点可见。同一个节点可以加入多个通道，并为每个通道内容维护一个账本。
+* Committer（提交节点）：一种 Peer 节点角色，负责对 Orderer 排序后的交易进行检查，选择合法的交易执行并写入存储。
+* Commitment（提交）：提交节点完成对排序后交易的验证，将交易内容写到区块，并更新世界状态的过程。
 * Confidentiality（保密）：只有交易相关方可以看到交易内容，其它人未经授权则无法看到。
-* Endorser（推荐节点或背书节点）：1.0 架构中一种 peer 节点角色，负责检验某个交易是否合法，是否愿意为之背书、签名。
-* Ledger（账本）：包括区块链结构（带有所有的交易信息）和当前的世界观（world state）。
-* MSP（Member Service Provider，成员服务提供者）：成员服务的抽象访问接口，实现对不同成员服务的可拔插支持。
-* Non-validating Peer（非验证节点）：不参与账本维护，仅作为交易代理响应客户端的 REST 请求，并对交易进行一些基本的有效性检查，之后转发给验证节点。
-* Orderer（排序节点）：1.0 架构中的共识服务角色，负责排序看到的交易，提供全局确认的顺序。
+* Endorser（推荐节点或背书节点）：一种 Peer 节点角色，负责检验某个交易是否合法，是否愿意为之背书、签名。
+* Endorsement：背书过程。按照链码部署时候的背书策略，相关 Peer 对交易提案进行模拟和检查，决策是否为之背书。如果交易提案获得了足够多的背书，则可以构造正式交易进行进一步的共识。
+* Invoke（调用）：一种交易类型，对链码中的某个方法进行调用，一般需要包括调用方法和调用参数。
+* Ledger（账本）：包括区块链结构（带有所有的交易信息）和当前的世界状态（world state）。
+* Member（成员）：代表某个具体的实体身份，在网络中拥有自己的根证书。节点和应用都必须属于某个成员身份。同一个成员可以在同一个通道中拥有多个 Peer 节点，其中一个为 Leader 节点，代表成员与排序节点进行交互，并分发排序后的区块给属于同一成员的其它节点。
+* MSP（Member Service Provider，成员服务提供者）：抽象的实现成员服务（身份验证，证书管理等）的组件，实现对不同类型的成员服务的可拔插支持。
+* Orderer（排序节点）：共识服务角色，负责排序看到的交易，提供全局确认的顺序。
 * Permissioned Ledger（带权限的账本）：网络中所有节点必须是经过许可的，非许可过的节点则无法加入网络。
 * Privacy（隐私保护）：交易员可以隐藏交易的身份，其它成员在无特殊权限的情况下，只能对交易进行验证，而无法获知身份信息。
-* Transaction（交易）：执行账本上的某个函数调用。具体函数在 chaincode 中实现。
+* System Chain（系统链）：由对网络中配置进行变更的配置区块组成，一般可以用来作为组成网络成员们形成的联盟约定。
+* Transaction（交易）：执行账本上的某个函数调用或者部署、更新链码。调用的具体函数在链码中实现。
 * Transactor（交易者）：发起交易调用的客户端。
-* Validating Peer（验证节点）：维护账本的核心节点，参与一致性维护、对交易的验证和执行。
-* World State（世界观）：是一个键值数据库，chaincode 用它来存储交易相关的状态。
+* World State（世界状态）：即最新的全局账本状态。Fabric 用它来存储历史交易发生后产生的最新的状态，可以用键值或文档数据库实现。
\ No newline at end of file