- 有了数字签名就够了为什么还需要CA证书?
因为数字签名无法确认当前访问的网站是否就是一个真实的想访问的网站。盗版网站可以浏览器的请求拦截，将自己的盗版公钥替代真实网站的正版公钥，然后与浏览器进行交互。而通过CA证书可以得到真实网站的公钥，防止盗版网站篡改，通过盗版网站无法得到真实网站的私钥，无法得出可以被真实网站公钥解密的密文。
CA证书中包含真实网站的公钥以及网站信息，通过通过CA的私钥对这些内容进行加密。浏览器通过CA的公钥对这些信息进行解密，得到真实网站的公钥，以此来防止盗版网站的冒名顶替。
2. 智能合约是用 链码 编写的，当区块链网络之外的某个应用程序需要与账本交互（更新，查询等）时，该应用程序就会调用此网络中的智能合约。智能合约用可执行的代码定义了不同组织之间的规则。应用程序调用智能合约来生成被记录到账本上的交易。
3. fabric中的排序节点不判断交易的内容，只是机械的把交易按照定义好的顺序排序后打包。但是在阶段三的过程中，等排序节点将交易分发到peer节点之后，peer节点将会对这些交易进行验证。
4. fabric中的raft排序中的领导者和跟随者的概念是相对于排序节点来说的，应用程序以及peer节点不需要知道领导者是谁。交易会由当前的排序节点路由给领导者节点。
5. 通过raft容错崩溃排序机制可以保证：①所有排序节点中的交易是一致的 ②所有排序节点按照事先预定的顺序对交易进行排序打包之后能够得到相同的结果 ③如果有排序节点崩溃也可以恢复过来 。
6. 区块链的结构是一群相互链接的区块的序列化日志，其中每个区块都包含一系列交易，各项交易代表了一个对世界状态进行的查询或更新操作。
7. 区块链中的每个区块中的用来保存交易信息的区块数据结构所包含的主要内容：
-
（Header）交易头
这部分用 H 表示，它记录了关于交易的一些重要元数据，比如，相关链码的名字以及版本。
-
（Signature）交易签名
这部分用 S 表示，它包含了一个由客户端应用程序创建的加密签名。该字段是用来检查交易细节是否未经篡改，因为交易签名的生成需要用到应用程序的私钥。
-
（Proposal）交易提案
这部分用 P 表示，它负责对应用程序供给智能合约的输入参数进行编码，随后该智能合约生成提案账本更新。在智能合约运行时，这个提案提供了一套输入参数，这些参数同当前的世界状态一起决定了新的账本世界状态。
-
（Response）交易响应
这部分用 R 表示，它是以读写集 （RW-set）的形式记录下世界状态之前和之后的值。交易响应是智能合约的输出，如果交易验证成功，那么该交易会被应用到账本上，从而更新世界状态。
-
（Endorsements）交易背书
就像 E 显示的那样，它指的是一组签名交易响应，这些签名都来自背书策略规定的相关组织，并且这些组织的数量必须满足背书策略的要求。你会注意到，虽然交易中包含了多个背书，但它却只有一个交易响应。这是因为每个背书都对组织特定的交易响应进行了有效编码，那些不完全满足背书的交易响应肯定会遭到拒绝、被视为无效，而且它们也不会更新世界状态，所以没必要放进交易中。
在交易中只包含一个交易响应，但是会有多个背书。这是因为每个背书包含了它的组织特定的交易响应，这意味着不需要包含任何没有有效的背书的交易响应，因为它会被作为无效的交易被拒绝，并且不会更新世界状态。
8. 链码与智能合约：Hyperledger Fabric 用户经常交替使用智能合约和链码。通常，智能合约定义的是控制世界状态中业务对象生命周期的交易逻辑，随后该交易逻辑被打包进链码，紧接着链码会被部署到区块链网络中。可以将智能合约看成交易的管理者，而链码则管理着如何将智能合约打包用于部署。一个智能合约定义在一个链码中，多个智能合约也可以定义在一个链码中。当一个链码部署完毕，该链码中的所有智能合约都可供应用程序使用。
9. 背书策略：背书策略非常重要，它指明了区块链网络中哪些组织必须对一个既定智能合约所生成的交易进行签名，以此来宣布该交易有效。 背书策略是 Hyperledger Fabric 与以太坊（Ethereum）或比特币（Bitcoin）等其他区块链的区别所在。在这些区块链系统中，网络上的任何节点都可以生成有效的交易。而 Hyperledger Fabric 更真实地模拟了现实世界；交易必须由 Fabric 网络中受信任的组织验证。例如，一个政府组织必须签署一个有效的 issueIdentity 交易，或者一辆车的 buyer 和 seller 都必须签署一个 car 转移交易。背书策略的设计旨在让 Hyperledger Fabric 更好地模拟这些真实发生的交互。
10. 有效交易验证：一项交易被分发给网络中的所有节点，各节点通过两个阶段对其进行验证。首先，根据背书策略检查交易，确保该交易已被足够的组织签署。其次，继续检查交易，以确保当该交易在受到背书节点签名时它的交易读集与世界状态的当前值匹配，并且中间过程中没有被更新。如果一个交易通过了这两个测试，它就被标记为有效。所有交易，不管是有效的还是无效的，都会被添加到区块链历史中，但是仅有效的交易才会更新世界状态。
11. 例如，如果 A1 想访问节点 P1 或 P2 上的智能合约链码 S5，每个节点使用其 CC1 的副本来确定 A1 可以执行的操作。例如， A1 可以根据 CC1 中定义的背书策略从账本 L1 中读取或写入数据。稍后我们将看到通道及其通道配置 CC2 中的角色的相同模式。同样，我们可以看到，虽然节点和应用程序是网络中的关键参与者，但是它们在通道中的行为更多地是由通道配置策略决定的，而不是其他因素。同理，网络的智慧包含在网络配置NC中而不是网络的参与者。
12. Peer 节点从排序服务接受交易区块，基于背书策略和并发冲突来标注区块中的交易为有效或者无效状态，并且将区块追加到 Peer 节点文件系统的哈希链中。
13. 背书：背书是指特定节点执行一个链码交易并返回一个提案响应给客户端应用的过程。提案响应包含链码执行后返回的消息，结果（读写集）和事件，同时也包含证明该节点执行链码的签名。链码应用具有相应的背书策略，其中指定了哪些节点是背书节点。
14. 背书策略：定义了在一个通道上对于某个链码应用，必须执行交易的 Peer 节点和必要的响应（背书）。一个策略要包含背书一笔交易所需节点的最少数量、最小比例、或者全部节点都需要背书。背书策略可以基于应用程序和节点对抵御不良行为（有意无意）的期望水平来组织管 理。提交的交易必须符合背书策略才会被交易为有效交易。
15. 应用程序调用链码是不是通过gRPC呀
16. 成员服务提供者（Membership Service Provider，MSP）是指为客户端和节点加入 Hyperledger Fabric 网络提供证书的抽象组件。客户端用证书来认证他们的交易；节点用证书背书交易处理结果。
17. 智能合约是由区块链网络外部的客户端应用程序调用的代码，用于管理世界状态中的键值对的访问和修改。在 Hyperledger Fabric 中，智能合约被称为链码。智能合约链码安装在节点上在一个或多个通道上实例化。
18. 系统链：一个在系统层面定义网络的配置区块。系统链存在于排序服务中，与通道类似，具有包含以下信息的初始配置：MSP 信息、策略和配置详情。网络中的任何变化（例如新的组织加入或者新的排序节点加入）将导致新的配置区块被添加到系统链中。系统链可以看作是和一个或一组通道的绑定。例如，金融机构的集合可以形成一个财团（表现为系统链），然后根据其相同或不同的业务计划创建通道。
19. channel configuration transaction artifact：这个mychannel的.tx文件将被传递给排序服务来创建对应的通道。
20. 成员的加入与退出也会通过cli以proposal的形式给channel吗？
21. 背书策略可以是链码级的也可以是键值型的（世界状态中的某些值），两种背书策略的粒度不同。
22. 每个节点上不仅有本地的MSP，还有一个通道MSP，但是逻辑上通道MSP的配置是定义在通道上的，节点之间的通道MSP通过共识机制来同步。
23. MSP 在每个管理级别都是强制性的——必须为网络、通道、Peer 节点、排序节点和用户（client）定义它们。
24. 通道的成员是组织不是节点，组合的成员是节点。
25. 要创建一个新通道，客户端 SDK 调用配置系统链码并引用属性，如“锚点节点”和成员(组织)。这个请求为通道账本创建一个“创世区块”，它存储关于通道策略、成员和锚点节点的配置信息。当将新成员添加到现有通道时，可以与新成员共享这个创世区块，如果适用，也可以共享最近的重配置区块。
26. 可能存在一个或多个用于管理方法和参数的特殊链码，称之为 系统链码。
27. 交易：交易可以分为两类：
部署交易，创建新的链码并将程序作为参数。当部署交易成功执行时，链码会被安装在区块链上。
调用交易，在部署的链码环境中执行操作。调用交易引用链码和它的方法。当成功时，链码执行指定的方法（这可能涉及修改相应的状态），并返回输出。
后边会讲到，部署交易是调用交易的特殊情况，创建新链码的部署交易是系统链码上的调用交易。
28. 节点：有三种类型的节点：
Client：客户端或提交客户端：是一个向背书节点提交实际交易调用并向排序服务广播交易提案的客户端。管理者其实也就是一个客户端。
Peer: Peer 节点：是一个提交交易并维护状态和账本（参见第1.2节）副本的节点。此外，Peer 节点可以扮演一个特殊的 背书人 角色。
Orderer: 排序服务节点 或 排序节点：是一个运行实现交付担保的通信服务节点，例如原子性或总顺序广播。
29. 配置：配置作为一个类型为 HeaderType_CONFIG 的交易，被存储在一个没有其他交易的区块中。这些区块被称为*配置区块*，其中的第一个就是*创世区块*。 区块链的最开始都是以传世区块为头的一系列配置区块。
30. 排序系统通道：排序系统通道需要定义一些排序参数，以及创建通道的联盟。一个排序服务有且只能有一个 排序系统通道，它是需要创建的第一个通道（或更准确地说是启动）。
31. 更新配置：因为配置保存在区块中，更新配置是通过一个称为“配置交易”的过程进行的（尽管这个过程和普通交易 有点不同）。更新配置是一个拉取配置、转换为人可读的格式、修改并提交审核的过程。
32. 开发应用中的例子：交易和由交易导致的票据状态是 PaperNet 中两个不同的概念。状态是世界状态，描述了票据的当前情况，交易是区块链，记录了从古至今针对该票据发生的所有交易。
33. PaperNet的网关：网关识别一个或多个提供网络访问的 Peer 节点 &&& 网关负责使用连接配置文件和连接选项将交易提案发送到网络中的正确 Peer 节点。
34. 组织的普通成员与管理员的区别：普通成员可以读写账本上的数据，而管理员不仅可以读写账本上的数据，还可以代表组织管理组织所处的通道的组织，比如在通道中添加一个新的组织。
35. 需要访问世界状态时才需要通过链码，此时需要安装智能合约。 访问账本的区块链可以不需要链码 此时可以不安装智能合约。
36. 背书策略好像是以组织为单位的，比如说一个组织中有一个代表节点进行背书就可以了，不需要该组织中所有的节点都进行背书，不过如果确实有这种需求应该也可以吧。
37. 网关最好不用包含太多的节点信息，比如一个issue交易，网关的连接配置文件需要至少包含背书组织和用于 issue 交易的 Peer 节点，以及识别将交易提交到帐本上时会通知网关的 Peer 节点。
38. 智能合约与CA也是在不同的独立的容器当中的。
39. 先生成排序节点创世区块，排序节点系统通道的创世区块是特殊的：它必须先创建并被包含在节点配置中，然后才能启动节点，同时通过其引导才可以生成排序服务系统通道，同样的道理，先生成普通通道创世区块，通过其引导才可以生成普通通道，接着再启动普通通道中的节点。
40. 在将org3的配置更新交易提交到通道之后，在org3的两个节点被加入到通道之前，为什么org3的客户端就可以直接通过peer chain fetch命令直接情况通道的创世区块？
自答：可能是客户端通过网关连接了org1或者org2的节点从而获取了需要的创世区块。
41. org3的新节点加入到mychannel之后，节点中账本的更新是通过gossip数据传播协议来同步的吗？
42. 一个账本的世界状态可以有多个，每个通过链码实现的智能合约有自己的命名空间来访问特定的世界状态。不同命名空间的智能合约不能访问对方的世界状态。在Fabric的链码命名空间部分的情景对此有详细举例说明。
43. 在Hyperledger Fabric中，智能合约通过链码的方式来实现，一个链码可以对应多个智能合约。
44. 通过不同的命名空间可以创建多个世界状态数据库，每个世界状态数据库的数据的key必须是唯一的，但是不同命名空间的世界状态数据库的数据的key可以是相同的，例如世界状态数据库A中有key1，世界状态数据库B中也可以有key1。
45. FabCar示例：当我们创建网络的时候，一个管理员用户 — 叫 admin — 被证书授权服务器（CA） 创建成了登记员 。我们第一步要使用enroll.js程序为admin生成私钥、 公钥和 x.509 证书。这个程序使用一个证书签名请求 (CSR) — 现在本地生成公钥和私钥，然后把公钥发送到 CA，CA 会发布会一个让应用程序使用的证书。这三个证书会保存在钱包中，以便于我们以管理员的身份使用 CA。
46. FabCar示例：重复运行query.js会发现有时候是从peer0上查询出的结果，有时候是从 peer1上查询出的结果。这个具体是用哪个节点的链码取决于网关。这也是网关的好处，让应用程序只关心业务逻辑而不是后台的数据。
47. 富查询与区间查询
- 富查询 ：对数据的某一个属性进行查询获取所有满足条件的数据，例如所有颜色为红色的汽车信息。
- 区间查询：对一个范围内的键值进行查询获取数据，例如获取单号在005至008之间的订单信息。
48. 提交者使用读写集中的读集来验证交易，使用写集来更新受影响的键的版本和值。在验证阶段，如果读集中键的版本和世界状态中键的版本一致就认为该交易是合法的。
49. CouchDB 是一个 JSON 文本数据存储，而不是一个纯键-值存储，并且支持数据库中文本数据的索引。网络中的所有节点必须使用相同的数据库类型。
50.
raft笔记：
Follower：普通节点 Candidate：候选节点 Leader：领导节点
选举过程：C节点向所有F节点发出投票申请，F回复自己的投票结果，获得多数选票的人当选为Leader。有Leader之后所有的数据改变都要通过Leader节点来进行。
Log Replication过程：所有的输出在L节点中首先变为一条日志，先不更新具体的值，接着讲这个日志复制给所有的F节点，当所有的F节点成功获取到该日志之后，L节点此时才可以提交日志对应的更改，通过告诉所有F节点完成此次修改。这样整个分布式系统才打到一个一致状态。
Leader Election过程：
election timeout：一个follower等待成为candidate的时延，每个follower的时延大小在一个范围内随机。超时之后，follower变为candidate同事开始一个新的election term，开始为自己拉票。
。。。。。。。