Notes on HyperLedger Fabric

• 笔记

• Fabric 1.4.x 环境配置及简单测试

笔记

在HyperLedger Fabric官方文档上的学习笔记，大部分是翻译自英文的官方文档（应该是1.4版本的文档），因为12月份又和兔子接了新的项目，所以持续更新中…

blockchain – 不变的交易账本，由一个分布式对等节点网络维持。Bitcoin and Ethereum – 属于公共许可证区块链技术这一类，网络对任何人开放，参与者匿名交互。企业级使用需要以下要求：参与者必须被识别？(be identified/identifiable)网络需要被认证/许可(be permissioned)高事务吞吐量性能低延迟的交易确认和商业交易有关的数据和交易的隐私与机密性

Hyperledger Fabric(maybe is 超级账本？)企业级许可的分布式账本技术平台Key point is that emmm 你是在Linux Foundation下建立的。嗯~ o(￣▽￣)o开源社区的支持和良好的生态系统Fabric高度模块化和可配置的架构，支持革新，多功能性，优化应用场景不限于：银行，金融，保险，健康，人力资源，供应链，音乐可用通用编程语言(Go,Java,Node.js)编写智能合约(smart contracts)，而非DSL拥有权限的(permissioned)，参与者互相认识(known to each other)，并非匿名尽管参与者并不一定是全信任的(网路中可能存在相互竞争的参与者)，但是可以提供一个处理争议的法律协议或框架支持可拔插的共识协议Fabric can leverage consensus protocols that do not require a native cryptocurrency to incent costly mining or to fuel smart contract execution. Avoidance of a cryptocurrency reduces some significant risk/attack vectors, and absence of cryptographic mining operations means that the platform can be deployed with roughly the same operational cost as any other distributed system.事务处理，事务确认延迟，事务的隐私和保密性，由chaincode来实现他们

模块化Fabric由以下模块组成：ordering service 就交易顺序建立共识，然后向peer节点广播(可拔插)membership service provider(MSP)将网络中的实体和加密身份相关联(可拔插)peer-to-peer gossip service(可选)smart contracts 在容器内运行，但是无法直接获取到账本的状态账本可被配置来支持各种DBMSsendorsement and validation policy enforcement 背书和验证政策执行

Smart Contracts区块链应用程序的业务逻辑order-execute architecture 应该是 排序-执行架构对事务进行验证和排序，然后传播给所有的对等节点每个对等的节点都按顺序执行事务

Fabric提出了新的架构 execute-order-validate解决上述模型面临的弹性，灵活性，可伸缩性，性能和机密性挑战

channel architecture能够在参与者的子集中建立频道，频道中的参与者对特定的一组事务或交易时可见的

什么是区块链？核心：分布式账本，记录在网络中发生的所有交易智能合约来对账本提供控制

共识在网络中保持账本交易同步，保证只有当交易是被适当的参与者所允许时才会更新账本，并且当账本更新的时候，他们以相同的顺序更新相同交易。

一个共享的、复制的交易系统，通过智能合约来完成更新，通过共识来保持一致同步

Fabric的成员是通过MSP注册的，数据可以以多种形式存储，共识可以交换，可以支持不同的MSP，可以创建频道，即允许一组参与者创建交易的一个分开的账本，这在网络中可能会存在竞争者的时候非常重要，(例如有的参与者可能不想让另一个参与者知道他们提供给别的参与者的特殊价格)

Fabric有一个子系统，子系统有两个部分组成：世界状态和交易日志。世界状态是账本的数据库，记录了账本在一个给定时间的状态。交易日志记录了导致世界状态处于现在这个状态的所有交易的记录，交易日志是世界状态的更新记录。那么账本就是世界状态和交易历史的一个组合

智能合约是用chaincode编写的，当应用需要和账本进行交互的时候，由外部的应用程序调用。大多数情况下，智能合约只会和账本中的数据库组件，世界状态交互，不会和交易日志交互。

交易必须要被按照他们发生的顺序写入到账本中去。嗯哼，这个是计算机一个彻底研究过的领域了。共识有点类似于通信？在账本之间同步交易的信息，在比特币中，同步信息用的是挖矿，Fabric中现有两种，SOLO and Kafka

身份。在网络中，活跃的外部或者内部节点，只要是能够使用服务的，都在一个X.509的证书中拥有自己的数字身份，principal有点类似于用户的ID，或者更加灵活一点，因为他也包括了如行动者(我不会翻actors)的组织，组织单元，角色，甚至特殊的身份，反正就是能够决定他们的权限的一些性质。 一个身份要是可以验证的，那么他就必须来自于一个可信任的权威机构。MSP就是。

在购物的例子中，你有合法的信用卡是没用的，因为，商店必须要认可才行。PKI提供了一系列的身份(合法的信用卡)，然后MSP定义了那些是可行的

PKI是一系列的网络技术，保证网络中的安全通信包含一个CA，应该叫做证书颁发机构，就是发证书的，被发到证书的人就可以说你看你看，我有证明嘻嘻。CA维护一个证书撤销名单，就是不再有效的证书。四个关键元素：数字证书，公私钥，CA，证书撤销名单

数字证书：包含一些重要的身份信息啥的，差不多就是这个感觉。公钥是公开的，私钥自己保管，只要别的组织认可发出证书的CA，那么你就可以用这个证书来证明自己的身份。通过密码学的机制来保证一旦被篡改，该证书就会失效

Membership MSP它标识了哪些CA是能够被信任的，能够用这些CA来定义成员。 MSP看完了，好像都忘光了

Peers Peers hold账本和智能合约 Peers能被创建，开始，停止，重新配置，甚至删除(好像还没说动态添加一个喔) Fabric实现智能合约通过chaincode，只是一段可以访问账本的代码 准确的说，peers hold账本和智能合约的实例，故意的冗余，以防止单点故障 在同一个peer上可以拥有多个账本和多个智能合约 peers总是有特殊的系统链码 当应用需要和账本与链码交互的时候他们就会连接上peers，Fabric SDK提供API让应用可以连接上peers，调用链码生成事务(交易)，提交事务(会被排序，并且提交到账本上去)，在过程结束的时候收到一个事件 对peer的请求查询可以在瞬间完成，因为信息都在本地的账本副本中，peer不会查询别的peer的，但是应用是可以连接一个或者多个peer去做查询 查询是三步，更新多了额外的两步 更新不能够被立即执行是因为需要得到其他所有的peer节点的同意，这是一个共识的过程。 更合适将channel看作是一个逻辑结构 至关重要的一点是：peer提供了可以访问和管理channel的控制点 区块链网络是由这个一组组织的集合来共同管理的，而不是单一的组织。 组织拥有peer 在例子中，一个网络会有很多的组织，一个频道连接的应该还是说是peer，或者说是组织里的peer还没有连接到频道里面去。(但是也至少是会加入到一个频道里面去)，然后一个组织里里面会有其开发的应用，该应用会连接到自己组织的peer上面 原则：如果没有组织将其个人资源贡献给这个网络，那这个网络就不存在了，那网络会随着这些合作的组织提供的资源而增长和缩小 如果组织不贡献peer的话，网络就么的存在了，(那这么说peer是组织自己提供上去了嘛 不同组织的应用也是不同的，因为它取决于它的应用是怎么处理他们的peer上的账本的副本的。这意味着应用程序和表示逻辑可能因为组织而异，尽管他们各自对等的托管完全相同的账本数据 应用也可以连接别的组织的peer，取决于账本交互的性质。 查询连接自己家的peer就行了，更新的话需要连接到，应该是所有要同意这个更新的peer上(但是为什么不是order去做这件事呢？不是委托order去办的吗，这个事务，还是我前面没读懂，理解错了？)

peers是如何被管理者分配到组织里面去的 每个peer是由本组织的一个管理者发证书的，peer的物理存储位置于其归属的组织无关。

应用(或peer？ 相互交互，保证peer上的账本同步的机制依赖于order节点 单节点无法自己更新，因为更新账本总是需要其他相关的节点同意

3-phase process P1：Proposal 提议 (why是一些peers呢)，他说是emmm这个应用要去问不同的组织的endorsing peer，是不是同意。事务提案会被每个endorsing peer单独执行，返回一个(maybe 态度)，收到足够多的回应之后，第一步就结束了。 哪些节点可以被选取来做背书？这取决于背书策略，(书上好像有写这个的喔… 接受到的回应可能是不一致的，当然导致这个问题严重的一方面是因为链码的不确定(不确定前面记得看过了，但是忘记在哪里了… P2：order应该还是排序的意思叭，因为orderer会收到很多的应用的一组背书，应该是先排序，然后再操作嘛？(打包，喔喔喔，我好呆喔，他区块链更新是每次链接一个块嘛，所以要打成包鸭 不是所有的peer都要连到orderer上面的嗷，嗯哼，你说八卦协议就八卦协议叭 cascade blocks to other peers using the gossip protocol 看起来，一个block里面，应该有很多个那个T喔，那…(P2里面应该会说 P3是从orderer节点分发块开始的，在该过程中，peer节点仍然会做验证，和P1不同的是，P1中是应用接受endorsing节点的回应然后做出发送提议事务的决定，但是如果应用自己违背背书策略发送错误的事务的话，peer节点在P3中仍然有能力拒绝，唔就算是事务被充分的允许(应该是这么翻译？事务也不一定会被成功地更新到账本上面去。当一个peer成功地验证了事务时，就会更新账本。失败的事务仍然会被保留以留审计的作用，和成功的一样。就是说peer上的block和orderer上的是差不多的，区别就是peer上的会多一个是否是有效的的指示符。注意到的是P3里面没有链码的执行，这只在P1中会做。这也就是说，链码是只需要在endorsing nodes上面是可获得的就行，而不是贯穿整个区块链的网络。相比之下，链码的结果是被频道里面的每个peer共享的，无论他们是否endorsed the transaction 每次有块提交到peer上的时候，peer会生成不同类型的event，应用可以事先注册这些事件类型，这样他们就能在这些事件出现的时候收到通知以确认第三和最后一步已经完成啦 整个过程就叫做 共识 peers就结束啦，嘤嘤嘤(最后他也没说能不能动态的添加嘻嘻

Ordering Service (对Raft有特别的关注喔，为什么嘛) 像以太坊和比特币，因为他们是not permissioned，所以任何的节点都可以参加共识过程，所以他们使用的是概率共识算法，最终保证账本在高概率下是一致的(后面有一句没读懂，大概是说对于分歧的账本仍然有点无能为力？ Fabric works differently. Fabric的设计依赖于确定的共识算法。(账本是无法分叉的，别的很多分布式的区块链能吗？我布吉岛喔，这里将链码的背书执行和排序是分开的，给Fabric带来了优势，在性能和规模方面

除了排序的角色，orderer同样会维持允许创建频道的组织的列表(频道的创建权是在组织里的嘛？ orderer也执行一些对频道的基本的访问控制

P2：ordering service节点可能有很多嗷，然后会同时的收到很多的事务，从很多不同的应用中，service的工作就是将这些批量提交的事务安排到一个明确定义好的序列里面，然后打包成块，这些块就是区块链中的块，一个块中的最大事务数量在channel的配置文件中定义。重要的是，排序节点把事务排成一个严格的序列，这和别的区块链有所不同，在Fabric中，由order服务生成的区块是final的，验证的事务绝对不会被恢复或丢弃，对于order节点来说，除了一种事务，就是和频道配置有关的，其他他都不会对事务的内容做出任何的评价。

实现排序服务(或者说共识)的几种机制(你还别说，Raft是讲的真的多 Solo：就和名字一样，就一个ordering节点，这也就是说，它是无法容忍错误的，所以solo是没法用于实际生产的啦，但是是一个做测试的好方法，当然你硬要做产品的话，那你可start with a single node Raft cluster，然后可重配置增加额外的节点，当然Solo开销小。

Raft：划重点，new as of v1.4.1 是一个CFT奔溃容错服务，遵循”领导和小兵”模型，比Kafaka简单和容易配置

Kafka：和Raft差不多，利用ZooKeeper集合进行管理。从1.0开始支持，emmmKafka集群的额外管理开销令人生畏或不受欢迎

Raft vs Kafka 如果你是一个应用开发者，智能合约开发者，或是peer管理员，那你不会觉得有功能上的差异。当然，你在管理排序服务的时候，仍然有需要注意的区别： 1.Raft更容易启动，当然，Kafka有很多的崇拜者，这些人认为Kafka集群使用和ZooKeeper有点tricky(炫技？ 然后需要有较高水平的基础知识，Kafka相比Raft有many more组件需要配置，Kafka有自己的版本，需要和自己的order协调。 2.Kafka并非是为大型网络所设计，Kafka需要一个组织来跑集群，但是Raft每个组织都可以有自己的排序节点，能够导致一个更加分散的系统 3.兼容和支持。Kafka归Apache管，Raft自己(Fabric)管 4.Kafka采用服务池，order组织的管理员来决定给每个channel分配多少个nodes，Raft是用户自己来确定的。 5.对BFT感兴趣那么可以尝试Raft

Raft的基本概念(这个共识应该是不归我管，但是还是康一康叭 Log entry primary unit of work in a Raft ordering service Consenter set：同意者的集合？ 有限状态机 法定人数：例如一个五个节点的服务，至少3个要有效才行 领导者：该身份并非是一个特殊的节点类型，而是代表一种特定事件段你拥有的这项角色，摄取并且复制log给他的followers Follower：有一点，会不停的接受心跳，没心跳了会启动新的leader选举 (leader如何共工作和快照没看嗷，我偷懒啦) Kafka：你就知道很烦就行了。哈哈哈哈

智能合约(让我去死叭 行，上来第一步先告诉我现在lifecycle变了，(暗示学两份 对于应用的开发者来说，智能合约和账本构成了Fabric的核心，账本记录的是一组商业物品的现在和历史状态的这样一组事实，智能合约则定义了执行的逻辑并且能够产生出可以加入到账本中的新的事实。 智能合约在可执行代码中定义了不同组织之间的规则。应用调用智能合约来生成交易，这些交易可以被记录在账本上。 在Fabric中，智能合约和链码的概念通常会进行互换，智能合约定义了交易逻辑，该逻辑控制一个商品在世界状态中的生命周期，然后(应该是合约)被打包进链码里面，链码会被部署到区块链网络里去(应该是被部署到peer节点上面)可以认为合约管理交易，链码管理合约如何被打包并被部署，当链码被部署的时候，里面所有的合约都会生效 合约的话主要是三个操作，put get and delete put 创建一个新的物品或在账本世界状态里修改现有的 get 查询当前某物品的世界状态 delete 从当前世界状态移除某物品，并非他的历史(因为Fabric一旦确认写进账本里应该是改不了的？话说不是本应该这样的嘛 智能合约的核心在于一组交易或事务(transaction)的定义 well 应该是：对于每一个链码，都有与之对应的背书政策，该政策当然应用于里面所有的合约啦 emmm 每个合约都有一个附在他身上的背书政策。 背书政策规定了由这个智能合约所生成出来的事务，交易(transaction)必须被哪些组织所同意。(可是在共识的第一步里面，他这个是应用要发送给endorsing peers的鸭，这里背书里面应该是要写到具体的节点嘛 生成的事务不管是不是被验证都会被记录的，但是只有验证通过的会被写到账本里面去来修改世界状态 在共识的第一步里面，是所有的背书节点都需要来执行合约才行。(这和那个应用发送请求应该是一个意思，就是看怎么说嘛 这里再一次强调了和以太坊以及比特币不同的地方，前者如果想要验证，理论上来将是任何节点都可以的(对于比特币来说应该就是看谁挖的快，但是Fabric更加具有一种现实世界的特性，他需要信任的组织来验证交易 这里面提到的有别的不同的policy可以来添加和移除参与者，那么对于Fabric来说，最基本的单元就是peer了，是否是指添加和移除peer呢？我怎么总是对这个问题耿耿于怀 一个智能合约能够根据不同的背书政策被部署到不同的频道上 合约有能力在同频道或跨频道调用(call？别的合约。主要在链码的命名空间部分有详解

系统级别的链码(和那些用于业务流程的链码是无关的 有五种不同类型的系统链码 修改系统级别的链码需要特别的小心

账本(so many!!! 啊，看一天都看不完啊啊啊 账本中有：当前的状态，和导致这个状态的历史的集合 取你银行账户的例子，可以看到现在有多少钱，也可以看到你当前的这个钱是为什么到了这个田地的(我觉得这就和我的手机里银行发给你的短信差不多意思 all right business object：业务对象(这么翻我也觉得好像好一些喔 账本并不会真正的存储业务对象，相反，它存储这些对象的一些事实(facts)，唔对于一个数字化的对象来说，它更像是在一个外部的数据库里面存储，而我们存在账本里面的事实和别的一些关键信息可以让我们识别他的位置 当前状态的事实可变，但是历史却是不可变的 ledger – world state and blockchain 世界状态时一个当前值的数据库，它可以方便程序进行查询，通常以键值对的形式出现。该状态是会频繁的变更的。 块链 – 一个日志，记录了导致当前状态的所有交易，事务，transaction是被封装在块里面的，块的数据结构和世界专改的不同，因为块的数据是不能被修改哒 more detail now！ World State 记录一个业务对象的当前属性值，作为一个特殊的账本状态，因为程序经常要查询当前状态，所以这很有用。因为通过整个日志来算出当前状态太笨重啦。以键值对的形式出现，可嵌套。 世界状态被实现为一个数据库。当然Fabric可以被配置为使用多个不同的世界状态数据库来解决不同类型的状态值的需要以及在复杂的应用中，需要的查询模式

Blockchain 每个块的头都包含了这个块的交易的hash，和前一个块的hash blockchain是被实现为一个文件，不同于世界状态(他是个数据库 这是一个明智的选择，因为块链的数据结构是非常偏向于非常简单的操作集合的，主要的操作是加到一个链的尾巴上，查询是一个相对不常见的操作。

Blocks

Blockchain network 这个部分还是看，但是这也，兄弟，太多了叭，我明天想代码走起了鸭，那么多这个我实在是不想看了鸭，可以一点一点的看。嘿嘿，我觉得我后面的那么多部分看掉了之后，这个部分应该是不会有特别大的问题。

Chaincode for Developers 链码在一个安全的Docker容器里面运行(什么是Docker容器我到现在都不知道)。链码通过由应用提交的事务来初始化和管理账本的状态。

给定合适的权限，链码可以调用或不同频道的别的链码。注意：不同频道的被调用的链码只有查询功能。

Token Long time no use this book FabToken是一个token管理系统允许你发行，转让，赎回token。tokens在频道的账本中被记录，可被频道里的任何成员拥有。 用户不需要使用智能合约来创建或者管理token

Token交易流程 无需多方组织来验证 交易由叫做prover peers的节点来发起，服务器产生token交易之后，将交易发送至ordering服务，ordering服务将交易送至committing peer验证然后写入账本。 –2019/01/12 这是2019.5.13那段时间做的笔记。

Fabric 1.4.x 环境配置及简单测试

后面这里交付出去了，不合并了（主要是懒