区块链技术被认为是轮子、铁轨、电力、互联网之后，又一个具备颠覆性的核心技术。区块链改变的将是价值传递的方式。将解决人类社会诞生以来一直在思考的问题--如何获取未知的信任。
随着业界对比特币系统技术架构的深入了解，人们发现这些技术除了应用在比特币上面之外，还能应用在其他领域。于是相关技术社区将这些技术抽象之后给它们起了一个统一的名字：区块链。从此区块链脱离比特币成为一门单独的技术。区块链不是一个单独的技术，而是由多种技术组成的技术栈，在学习区块链技术的时候一定要注意区块链技术的这个特性。所以如果想学会区块链技术首先需要对组成区块链技术栈的各个单项技术有所了解，然后再开始学习相关的区块链技术框架，这一点在基于区块链技术的项目实施中尤其重要。
传统的关系型数据库都必须满足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、cryptogen
cryptogen模块主要用来生成组织结构和账号相关的文件，任何fabric系统的开发通常都是从cryptogen模块开始的。
2、configtxgen
configtxgen模块用来生成orderer的初始化文件和channel的初始化文件。
3、configtxlator
configtxlator模块可以把区块链的二进制文件转化成json格式的文件，便于我们阅读和理解。
4、orderer
orderer模块负责对交易进行排序，并将排好序的交易打包成区块。
5、peer
peer模块是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模块的配置文件core.yaml进行配置的。
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、启动第一个peer
4、通道的创建加入
5、启动fabric-ca
6、cc的开发和部署
7、客户端的开发
8、本组其余peer的加入
9、其它组织的加入
10、背书交易的测试
11、非初始化组织加入
12、删除已有的组织
第13章 数据溯源系统
数据溯源的痛点：数据共享太少、信息存储中心化、信息存储孤岛化。
区块链解决的优势：可以方便地接入更多参与方、客服中心化系统的弊端、所有数据共同维护打破信息孤岛。
扫一扫
2337
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
