业务上所期望解决的问题——信用问题
首先从比特币说起，大家对比特币算力证明（POW）的名词应该不陌生，先不说其耗费大量的资源，从共识机制上来看，拥有超过50%的算力即可掌控整个比特币，无论从技术还是业务的角度都是一个风险极高的机制，但神奇的金融圈没有人会去触碰这样的底线，一旦有人拥有超过50%的算力，比特币可能就玩不下去了：）
那么实际的业务场景中的需求应该是怎样的呢？比如说，银行结算清算系统，传统的银行交易系统中，如果出现跨行交易，那么交易数据便需要一个清算系统进行定时对账确保双方的交易数据是同步无误的，那么就可能导致跨行转账需要T+1的时长，而主要的原因是因为双方的系统及数据相互独立，数据互不“信任”，所以需要一个清算系统去验证交易数据，而区块链可以说是为了解决这种“信任”问题而产生的技术，在双方进行交易的同时对数据进行了认证，那么便无需交易后再进行清算而达到实时转账等功能。下面来说为了解决“信用”问题，技术上需要哪些手段去满足。
技术上需要哪些特性去达到“数据可信任”
以上面提出的清算系统为例，可能有人提出，双方使用同一个分布式数据库不就可以达到实时的数据同步了嘛。确实，区块链其中一个特性便是分布式，但是和传统的分布式数据库区别在哪呢？在回归到业务中，如果双方银行进行交易的时候，使用这样一个分布式数据库，难道不担心对方偷偷地把数据改了吗？如果你说有日志可以追述得到修改记录，首先日志也是容易被修改的，且日志也无法挽回动不动可能就上百万千万甚至过亿的金额损失，所以说传统的分布式数据库对于企业之间来说是”不可信的“，那么便要求区块链需要达到数据不可篡改、用户有身份认证、交易可追述、交易有权重等一系列的特性。
剖析技术原理
存储数据结构
要达到数据不可篡改首先从数据结构上来看，也是区块链之所以称之为区块链的原因。如下图所示，每个存储单元包含上一存储单元的hash值（图中hash值的对应关系不完全精确，仅示意用）以及自身存储的交易数据块，可以从表象来看就像把所有数据块连接在一起，称之为“区块链”，形成链状可追述的交易记录。这种链状结构的数据称之为账本数据，保存着所有交易的记录，此外还有一个“世界状态”，其实质为Key-Value数据库，维护着交易数据的最终状态，便于查询等操作运算，并且每个数据都有其对应的版本号。
Fabric主要模块
总体来说，市面上各种区块链的实现方案都是基于这种数据结构，而仅靠数据结构并不能保证数据不可篡改，还有一个非常重要的因素，便是共识机制，一个好的共识机制才是保障整个业务运转的根本，相当于双方签订的合同或者协议，只有双方都遵守条约才能合作将业务展开进行。例如常见的POW，POS，PBFT等都属于共识机制，而其原理或者弊端这里不做赘述，主要来详细讲解Fabric应用的设计方案及其原理，此前先解释下一些特定名词的概念。
首先说”智能合约“的概念。在传统中心化的系统中，例如支付宝用户A给B转账100元，那么假设起始A有100元B有0元，那么在支付宝系统内调用转账的函数可能是这样的一个流程，调用transfer(A,B,100)，而函数内可能会去读取用户A和B的账户余额，那么我们可以表达成input(A,B,100),read(A:100,B:0),write(A:0,B:100)，那么这个仅是在支付宝的系统内执行了便完成了，那如何形成一个合约呢？
就如A、B在签订一份合同，双方都要对合同进行签名认可，在程序中就等于，用户A在其本地执行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)并对其签名认证，用户B在其本地执行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)并对其签名认证，然后双方将结果发给对方，然后判断对方结果是否一致并对其签名进行校验无误后便认为合约达成将结果写入本地。通俗来说就是将一段核心代码抽出来，所有参与方都去执行该代码并对其结果进行签名认证比对，便称之为执行智能合约，而其中共有的代码便是“合约"。
再说”背书策略“的概念。那么根据上面所言的共有代码在交易中是不是所有用户都要执行呢？比如说A、B用户转账，那么C、D用户显然就不需要规定其参与执行职能合约了，那么背书策略便是规定智能合约的结果需要哪些成员的签名背书才算交易成功。
在Fabric的交易流程中，主要有几个关键节点参与，包括Peer节点、Orderer节点、CA节点及client端。
Peer节点
该节点是参与交易的主体，可以说是代表每个参与到链上的成员，他负责储存完整的账本数据即区块链数据，负责共识环节中的执行智能合约，其中所有的Peer节点都维护完整的账本数据称之为Committer，而根据具体的业务划分背书策略时决定哪些Peer。
Orderer节点
该节点负责收集交易请求进行排序并打包生产新的区块，主体功能便是对交易排序从而保证各Peer节点上的数据一致性，也包含了ACL进行访问控制。
CA节点
该节点负责对加入链内的所有节点进行授权认证，包括上层的client端，每一个节点都有其颁发的证书用于交易流程中的身份识别。
client
Fabric对于client端提供了SDK让开发人员可以更容易地对接到区块链内的交易环节，交易的发起便是通过SDK进行。
供应链金融中的应用
以上简单的阐述了各模块的功能，当然实际当中包含更多服务支持的功能，那么这里在套进供应链金融来举例，更好地理解各节点的意义。
一个简单的供应链模型，一个核心企业向其供应商进行采购1000w物资，按照赊销合同在收到物资后半年进行结账，那么半年的账期供应商资金无法周转开便拿着核心企业开具的银行承兑汇票进行抵押融资，那么银行审核通过后将票据95%的金额马上转给了供应商，半年账期到后，核心企业便直接将货款转给银行，这样就形成了一次供应链的融资交易了。
在实际的业务当中大部分都是在线下进行操作的，耗费众多的人力及时间，那如何将这样的业务转成线上电子化呢？有人或许说银行提供这样的平台服务不就好了嘛，那假设这个平台不仅仅是这一家银行参与呢，若所有的银行或者企业都可以在同一个平台进行，那么交由某一个银行提供服务就显得不合适了。
参考网址：https://www.sohu.com/a/227779089_629652