2023年7月10日发(作者：)

《区块链开发实战：HyperledgerFabric关键技术与案例分析》读书笔记区块链技术被认为是轮⼦、铁轨、电⼒、互联⽹之后，⼜⼀个具备颠覆性的核⼼技术。区块链改变的将是价值传递的⽅式。将解决⼈类社会诞⽣以来⼀直在思考的问题--如何获取未知的信任。随着业界对⽐特币系统技术架构的深⼊了解，⼈们发现这些技术除了应⽤在⽐特币上⾯之外，还能应⽤在其他领域。于是相关技术社区将这些技术抽象之后给它们起了⼀个统⼀的名字：区块链。从此区块链脱离⽐特币成为⼀门单独的技术。区块链不是⼀个单独的技术，⽽是由多种技术组成的技术栈，在学习区块链技术的时候⼀定要注意区块链技术的这个特性。所以如果想学会区块链技术⾸先需要对组成区块链技术栈的各个单项技术有所了解，然后再开始学习相关的区块链技术框架，这⼀点在基于区块链技术的项⽬实施中尤其重要。传统的关系型数据库都必须满⾜ACID原则，ACID原则本质上是对事务⽽⾔的。事务必须具备以下四个特性：原⼦性（Atomicity）、⼀致性（consistency）、隔离性（isolation）、持久性（durability）。分布式数据库的特点，我们称之为BASE。基本上可⽤（basically available）、软状态（soft state）、最终⼀致性（eventually consistent）区块链的密码学特性:主要使⽤的算法有哈希算法、merkle树、⾮对称加密算法。区块链的共识机制：⽬前常⽤的共识算法有POW、POS、DPOS、PBFT。智能合约：智能合约本质上就是⼀段⽤某种计算编程语⾔编写的程序，这段程序可以运⾏在区块链系统提供的容器中，同时这段程序也可以在某种外在、内在条件的激活下⾃动运⾏。区块链的三⼤缺点：性能问题、数据的弹性扩展问题、易⽤性问题。fabric的多账本特性：通道（channel）本质是⼀个账本的逻辑概念。fabric账本有以下特点：使⽤基于key的查询、范围查询、复合键查询来查询或更新账本。只读查询⽀持丰富的查询语句（CouchDB）。只读的历史查询--实现数据追溯场景。交易包含读取链码键值对（读集），以及写⼊链码键值对（写集）的版本。交易包含所有背书节点提交到排序服务的签名。交易被打包排序成区块，并通过通道从共识节点传⾄对等节点。对等节点通过背书政策标准来验证交易。在增加区块前，需要执⾏版本检查以确保数据在链码执⾏时间段没有被篡改。当交易被验证并承诺后，并不可改变。每个通道的账本都包含配置区块链，它定义了政策标准、访问控制列表与其他相关信息。通道包含了会员服务提供商实例，因此加密证书能传递到不同的证书颁发机构。Hyperledger中除了Fabric项⽬外，⼀共有13个模块与Fabric相关，如下所⽰：Blockchain-explorer、fabric-sdk-node、fabric-sdk-java、fabric-sdk-py、fabric-sdk-go、fabric-samples、fabric-ca、fabric-baseimage、fabric-chaincode-node、fabric-docs、homebrew-fabric、fabric-sdk-rest、fabric-chaincode-java。三种配置⽅式的优先级：环境变量>配置⽂件>命令选项。五个模块详解:1、cryptogencryptogen模块主要⽤来⽣成组织结构和账号相关的⽂件，任何fabric系统的开发通常都是从cryptogen模块开始的。2、configtxgenconfigtxgen模块⽤来⽣成orderer的初始化⽂件和channel的初始化⽂件。3、configtxlatorconfigtxlator模块可以把区块链的⼆进制⽂件转化成json格式的⽂件，便于我们阅读和理解。4、ordererorderer模块负责对交易进⾏排序，并将排好序的交易打包成区块。5、peerpeer模块是fabric中最重要的模块，也是在fabric系统使⽤最多的模块。peer模块在fabric中被称为主节点模块，主要负责存储区块链数据、运⾏维护链码、提供对外服务接⼝等作⽤。在⼀个组织内有4个peer服务器节点，这4个peer服务器节点并不是4个peer进程，⽽是表⽰⼀个组织中的四个⾓⾊，是逻辑概念，有Commit peer、Leader Peer、Endorse peer、Anchor Peer。commit peer和endorse peer可以有多个，但是leader 和anchor 只能存在⼀个。commit peer：Committer节点主要负责维护区块链的账本结构，该节点会定期从Orderer节点获取包含交易的区块，在对这些区块链进⾏合法发⾏校验之后，会把这些区块链加⼊到区块链中。endorse peer：Endorse节点主要负责对交易进⾏校验。当Endorse节点接收到客户端发送的交易请求之后会对交易的合法性进⾏校验，校验成功之后会将结果反馈给客户端。leader peer：Leader节点是负责代表组织从Orderer节点中获取区块信息。Leader节点在整个组织中只有⼀个。Endorse节点的产⽣⽅式是通过peer模块的配置⽂件进⾏配置的。anchor peer：锚节点主要负责代表组织和其他组织进⾏信息交换。每个组织都有⼀个锚节点，锚对于组织来说⾮常重要，如果锚节点出现问题，那么组织和其他组织会失去联系。锚节点也是通过配置的⽅式指定。第6章 fabric的账号体系fabric是基于证书⽽不是传统的⽤户名和密码形式的⾝份和⾓⾊认证的。fabric的账号实际上是根据PKI规范⽣成的⼀组证书和秘钥⽂件。传统的账号系统中账号密码只是获取操作权限的⼯具，⼀旦验证成功，后⾯的操作基本上就和账号密码没有什么关系了。但区块链系统的每条交易都会带上发起者的标签（签名证书）。PKI账号体系⽐传统系统的账号密码认证体系复杂得多，证书存放在msp和tls⽂件夹中。msp中包含以下5个部分：admincerts：管理员证书。cacerts：根CA服务器的证书。keystore：节点或者账号的私钥。signcerts：符合X.509的节点或者⽤户证书⽂件。tlscacerts：TLS根CA的证书。tls⽂件夹中的内容：tls⽂件夹中存放加密通信相关的证书⽂件。官⽅⽂档把证书称为Membership Service Providers，简称MSP。第9章 Fabric系统架构设计我们认为在Fabric架构中的组织规划⼯作实际上需要完成两件事：确认组织和指定组织之间的管理⽅式。如何确定系统的参与者是否可以成为⼀个组织的条件：是否对区块链中的数据具有有效性检查的权⼒。是否具有独⽴发展下属成员的权⼒和资格。是否对系统的核⼼业务不可或缺。组织的管理⽅式：如果新的组织想要加⼊区块链中，需要所有组织的⼀致同意才可以加⼊。证书的管理⽅式可以有两种模式：联盟式管理和集权式管理。1、联盟式管理联盟式管理是Fabric设计的初衷，如果对组织的证书采⽤联盟式管理的⽅式，那么系统初始化完成之后需要将⽣成的各个组织的相关证书（包括组织的证书、组织⽤户的证书、组织中所有节点的证书）全部提供给相关组织（或者这些证书由相关的组织⾃⾏⽣成，以后这些证书由所属组织独⽴维护。组织的证书采⽤联盟式管理的好处是所有参与的组织之间是对等的，可以共同参与整个联盟链的管理。但是坏处也是明显的，整个联盟链中没有⼀个统⼀的管理机构，如果有组织之间发⽣冲突，那么只能通过协商的⽅式处理，整个系统没有仲裁结构。举个例⼦，如果需要删除区块链中的某个组织，必须获取包括被删除组织在内的所有组织的同意才能完成删除操作。这个时候如果被删除组织不同意，那么⽆法完成删除操作。由此可见采⽤联盟式管理必须建⽴在组织之间互相熟悉的基础之上。2、集权式管理在集权式管理中，整个区块链中存在⼀个中⼼组织，该中⼼组织统⼀管理区块链中的所有组织。区块链中所组织的管理员账号的证书将被收回，由中⼼组织统⼀管理。如果需要增加新的组织或者删除已经存在的组织，只有中⼼组织同意即可完成相关的操作。Channel的设计每⼀个账本在Fabric中被称为Channel，加⼊Channel中的每个Peer节点都是对等的，也就是说同⼀个Channel中的所有Peer节点都保存⼀份相同的数据。但是Fabric⽬前并没有提供分布式存储的解决⽅案，这导致了加⼊了同⼀Channel的Peer节点服务器中都会重复存储相同的数据。这种存储结构在数据量⾮常⼤的时候会影响Peer节点读取数据的性能。基于Fabric这样的存储特性，在设计Fabric系统的时候需要对Channel存储⽅式进⾏相关的设计。Fabric对Channel的存储⽅式进⾏设计的内容主要是：⾸先对Channel的⼤⼩进⾏评估，如果单个Channel的数据量或者数据的存储空间都⾮常⼤，那么可以将⼀个⾮常⼤的Channel拆分成若⼲个相对⽐较⼩的Channel。channel分割假设有10亿条数据，⼀共有500g，这会对peer造成较⼤的压⼒，如果把每个channel的数据限制在2000万条，分成50个channel，每个peer只需要保存10g的数据。这样做如果数据继续增长只需要增加新的channel即可，理论上可以应对数据的⽆限增长。chaincode设计需要关注以下⼏个问题：（1）chaincode只作为数据的加⼯者存在，不要存储中间状态。（2）在chaincode中避免进⾏CPU和内存密集型运算。sdk访问数据如果需要在业务系统中通过代码的⽅式同Fabric进⾏交互，只能通过Fabric提供的相关语⾔的SDK编写相应的代码和Fabric进⾏交换。在设计这些访问代码的时候通常会采取两种⽅式：嵌⼊式和中间件式。建议采⽤中间件式设计。好处有：（1）解决fabric记录状态返回不实时的问题如果采⽤将Fabric相关的操作集成在⼀个中间件中，遇到类似场景的时候可以数据处理完成之后，通过中间件将处理结果推送给业务系统进⾏后续处理。这样可以有效解决业务系统的等待问题，同时还可以降低业务系统的开发难度。（2）有利于系统进⾏负载均衡Fabric并不是⼀个可以承载⼤并发读写的数据系统，当系统请求的并发⽐较多的时候Fabric会产⽣阻塞，遇到这种情况通常可以采⽤增加Peer节点的⽅式来减轻单个节点的负载。（3）隔离客户端系统采⽤的开发语⾔Fabric提供了基于Grpc的接⼝描述⽂件，理论上任何语⾔只要能够⽀持Grpc协议都能够很好地和Fabric进⾏通信。但是从头开始实现Fabric的Grpc协议的⼯作量⾮常⼤，⽽且要进⾏很多测试⼯作。⽬前Hyperledger项⽬已经实现了Nodejs、Go、Java、Python这个四个语⾔的SDK，应⽤这四种语⾔开发的系统可以⾮常容易的和Fabric进⾏通信。但是常⽤的编程语⾔远不⽌这些，开发业务系统的编程也不会局限于这四种语⾔。⽐如，业务系统采⽤的开发语⾔是PHP，这就需要从头开始⽤PHP根据Fabric提供的Grpc的描述⽂件⽣成相关的代码，这个过程⽐较繁琐⽽且容易出错。这时候如果采⽤Nodejs、Go、Java、Python这四种语⾔中的⼀种开发⼀个通⽤的中间件，然后通过⼀些常⽤的协议（⽐如JSON-RPC）暴露接⼝，这样能够屏蔽由于业务系统的编程语⾔多样性带来的问题。9.6历史遗留系统的兼容1、账号同步（1）账号体系中的账号是固定不变的如果账号的数量较少，可以通过Fabric的cryptogen模块⽣成相应数量的账号信息，然后将⽣成的账号⽂件和历史遗留系统的账号进⾏绑定。如果账号的数量较多，那么可以借助fabric-ca-server来对这些账号进⾏管理，通过fabric-ca-server提供的restapi导⼊数据时，每次调⽤成功都会返回当前创建账号的证书等信息，通过这些信息可以完全与历史遗留账号体系的绑定。（2）历史遗留系统的账号会持续增加如果是这种情况，那么只能采取fabric-ca-server来管理账号，通过fabric-ca-server提供的RESTAPI接⼝将历史遗留系统的现有账号导⼊到fabric-ca-server中完成绑定，对于新增的账号，每次创建账号后，调⽤fabric-ca-server的接⼝⽣成新的账号并完成绑定。2、数据融合关于历史遗留系统的已有数据如何保存到区块链中是⼀个⽐较⿇烦的问题。在处理这个问题的时候会有⼀个⽭盾。由于历史遗留数据是发⽣在过去的，但是区块链中每条交易都会在系统级别记录⼀条数据的时间戳。这个时间是客户端⽆法修改的并将永远保存。这个时候如果进⾏数据初始化就会发⽣数据存储时间不⼀致的问题，即历史数据的系统时间戳和业务时间戳是不⼀致。这可能会导致数据有效性受到质疑。这个时候区块链技术已经⽆法解决这个问题了，只有联盟链的所有参与⽅达成共识，统⼀接受这样的事实才可以。针对这种问题我们推荐两种解决⽅案供⼤家参考，这两种⽅案分别是：时间戳截取法和Channel截取法。（1）时间戳截取法时间戳截取法是通过设定某个特定的时间点，在该时间点之前的数据为历史数据，时间点之后的数据为新数据。当系统需要⽤数据的时间戳的时候，对于时间节点之前的数据以存在交易记录中的历史时间为准，对于时间点之后的数据以系统时间戳为准（2）channel截取法在使⽤channel截取法的时候，将历史数据存储在特定的同道中⼈。当需要使⽤历史数据的时候从特定的通道中获取相关的数据，如果需要使⽤新⽣成的数据则从新创建的channel中获取数据。9.7 fabric系统的维护和管理区块链系统和传统的以数据库为核⼼的系统有很多不⼀样的地⽅。维护时需要着重注意以下三个问题：1、数据备份可以通过增加节点的⽅式进⾏备份。⽐如设置专门的数据备份peer节点，该节点在加⼊相关的channel之后不接受任何外部程序的访问请求，专门作为备份节点使⽤。2、系统升级升级要注意数据格式的兼容性。3、orderer节点的多机备份orderer节点应该避免单个节点。可以部署⼏个拥有相同创始块的orderer节点，然后把这些节点指向同⼀个kafka集群。第⼗章 开发实战Fabric项⽬开发流程：1、系统初始化2、orderer初始化启动3、启动第⼀个peer4、通道的创建加⼊5、启动fabric-ca6、cc的开发和部署7、客户端的开发8、本组其余peer的加⼊9、其它组织的加⼊10、背书交易的测试11、⾮初始化组织加⼊12、删除已有的组织第13章 数据溯源系统数据溯源的痛点：数据共享太少、信息存储中⼼化、信息存储孤岛化。区块链解决的优势：可以⽅便地接⼊更多参与⽅、客服中⼼化系统的弊端、所有数据共同维护打破信息孤岛。