区块链在供应链金融中的应用：原理、实现方式与局限

前文《区块链的原理、场景与实现方式：以供应链金融为例》发出后，收到不少同仁的反馈和建议，主要有2点：一是描述区块链相关技术本身的内容太多，对业务团队不够友好；二是原理解析部分与技术落地部分有些脱节，看完文章后依然很难理解区块链的种种特性是如何应用在供应链金融的场景中并发挥其价值的。

除了建议之外，文章也不可避免的引起了一些争议，部分友商认为该文：

“存在刻意贬低区块链的地方”，“对尚处于发展初期的区块链技术缺乏宽容”，“将区块链在供应链金融中的应用说的毫无价值，一无是处”。

贬低区块链绝非笔者本意，作为从业人员，笔者对区块链的发展充满了期待，也充满了信心。多年来，区块链相关的咨询与实施服务始终都是笔者及其团队的一块重要业务，笔者及其团队也始终在致力于“推广区块链技术，链接区块链厂商与用户，为用户提供足够前瞻又实用的技术服务”。“爱之深，责之切”，不可否认的是文章中存在不少笔者主观判断的地方，这些判断与笔者个人经历、知识结构、项目经验密切相关，虽然难免有失偏颇甚至偏激之处，但仍是笔者出于对区块链未来发展的深深期望，还望同仁海涵，及时指正，共同探讨。

《区块链不能承受的企业期望之重》共分5章，因考虑到内容较多，遂决定分5次发布。前文《区块链的原理、场景与实现方式：以供应链金融为例》是其中的第2章，仅是其中一部分，起到承上启下的作用，内容上很难自成一体，这或许也是造成文章难读费解的原因之一。

有鉴于此，笔者对前文进行了适度改编，在此基础上形成了此文。在内容上，删除了“原理与概念解析”一节，改写了“共识机制”和“数据上链流程”两部分，以期能够将区块链技术是如何与场景结合阐述的更为清晰。

再次感谢各位同仁的关注。笔者衷心感谢各位提出的批评与意见，也期望能够收到更多的反馈与建议。希望能够通过与各位的探讨和争论，形成些许共识、形成些微合力，共同推动区块链在金融行业中的落地。

「目录」

一、业务痛点与常见的解决方案

二、总体设计

2.1节点性质

2.2共识机制

2.3部署方式

2.4身份认证

2.5系统架构

三、业务设计

3.1业务流程

3.2交互过程

3.3数据共享

3.4数据加密与商业隐私保护

3.5智能合约设计

四、价值与局限 

「正文」

一、业务痛点与常见的解决方案

下面是四段关于区块链在供应链金融中价值的描述，采编自区块链厂家或已实施区块链项目的宣传文稿中，相信从业人员大都在某些场合中看到过或者有所耳闻。重点部分我用加黑加粗下划线标识了出来。

“在数据共享解决方案中，核心是通过智能合约，以交易的方式将数据上链，联盟链接入各方通过分布式账本在授权情况下共享数据。针对确权凭证，在区块链上进行管理和流转。供应链融资到期后，系统可以自动完成还款（从供应商或者核心企业的账户自动扣款）。一旦融资相关的发票被注销、融资主体征信出现问题，信息可及时同步至供应链平台。”

“通过智能合约的加入，贸易行为中交易各方即可如约履行自身义务，确保交易顺利可靠的进行下去。以物权融资为例，完成交货即可通过智能合约向银行发送支付指令，从而自动完成资金支付、清算和财务对账，提高业务运转效率，一定程度上降低人为操作带来的潜在风险与损失。”

“借助区块链智能合约技术，辅以银行内部账户管理体系，设计并实践应收账款自动结算场景。”

“基于真实贸易付款约定，通过区块链智能合约技术，实现履约条件、履约方式、履约账期、履约金额的上链和智能化设置，并对接付款方对应的金融机构，实现应收账款的逐层自动结算，解决因中间供应商延期付款而造成的全链条资金流转效率降低的问题。”

当然，这样的描述或宣传还有更多，但千言万语归纳起来，区块链的价值无非体现在以下2点：

1、确保交易背景的真实性：

① 数据上链，通过分布式账本与共识机制保证数据不被篡改；

② 上链产生“存证”价值，通过算法遍历区块链网络，验证交易网络中的各级数据来检验交易真实性，固化数据来源，实现数据登记与确权，记录数据的流向和使用情况，实现数据存证、数据固证和数据取证的功能。

2、提升融资的效率

① 简化流程：利用智能合约实现贷前审批工作和资产核实工作的自动处理与确认，简化人工流程，提升效率；

② 合约自动执行：将合同中需履行的义务开发为智能合约，确保合约与交易能够顺利可靠的进行。例如在到货保理业务中，“货物完成交货即可通过智能合约向银行发送支付指令，从而自动完成资金支付、清算和财务对账”；

③ 多机构后台实时对账：基于隐私计算技术，保证参与者在只掌握自身数据的情况下，可以检测区块链网络中其他参与者数据的一致性。

现阶段这些憧憬中的功能哪些能够实现？哪些不能够实现？如果能够实现，需要什么前提条件？实现方式是什么？接下来我们将一起来探讨回答这些疑问。

供应链金融的覆盖面很广，通常包括虚拟类的订单融资、应收应付类融资、预付账款融资，以及实物资产类的存货抵质押融资。各个业务领域都有区块链的应用场景和实际落地的案例。当然，当我们谈及价值时，通常都是从业务痛点出发，区块链也不例外。

由于涉及货物监管，在供应链金融中实物类融资业务（动产抵质押）相比虚拟类融资业务（应收应付）要更为复杂。但是在总体设计、业务设计及技术的实现逻辑上，两者并没有太大的差异，实物类的系统设计无非是增加了物联网的数据网关与仓储物流企业作为节点。物联网设备（AI摄像头、激光成像仪，地磅芯片、RFID）采集数据后，需要自动向区块链上传身份、位置、场景、重量、数量、时间等数据，从而更好地实现物流与信息流的一致性。但是现阶段由于没有数字货币作为媒介，还没法做到资金流和信息流绝对的合一，要实现真正的三流合一还有待于数字货币的发展。

所以，接下来我们以核心企业发起的“信宝单”（拆转融）模式为例，来看看表2-1中的功能具体是如何实现的，其中又有哪些地方体现了区块链的价值。

二、总体设计

联盟链被人诟病的地方之一是需要“先建立联盟，再形成链”：即各参与方需要先就参与节点权限、身份认证、业务标准和技术标准等联盟治理的事项达成共识，在线下签署一系列协议，再进行节点部署。随后，各参与方才能将自身的应用系统（如供应链金融平台、ERP、FMS、银行核心系统等）与区块链节点进行对接，形成一个基于区块链的供应链金融平台，从而在线完成合同签订、动产登记、融资放款和资金清分结算等操作。更多关于联盟链治理的实践、方法可参阅本系列文章第五部分《始于链下 终于链上》。

虽然同为联盟链，但不同底层之间差异巨大，具有代表性的底层平台有Fabric、以太坊和Corda。国内绝大部分企业都采用了Fabric，京东、华为、百度、蚂蚁金服等大厂均以Fabric为基础推出了自己的BaaS平台。Fabric在银行、证券和保险等金融行业有大量的落地项目，是现阶段最成熟、应用最广泛的联盟链，企业选择Fabric既能满足供应链业务场景的需求，也符合行业发展趋势。因此，本文中关于区块链及其应用的介绍将基于Fabric底层来展开。

1、节点性质

节点部署需要花大量时间进行开发、组网、测试及联调工作，并且这一系列工作对参与机构技术团队专业程度及硬件资源都有较高的要求。在供应链金融场景中，通常具备一定信息技术能力的企业如核心企业、商业银行等能够成为独立的区块链节点，供应商、经销商等其他参与机构则大多通过SaaS方式接入。这种模式在实现快速组网的同时，保障了区块链平台整体的稳定运行。

当然，快速组网需要区块链技术上的支持：区块链底层平台要支持公有云、私有云和混合云部署；能够实现新节点的快速安装、配置以及初始化，要在不影响节点账本数据的前提下能够实现对已有节点的升级和漏洞修复；要能够为参与机构的开发团队提供一站式的应用研发工具。在提供了以上技术支持的前提下，参与机构方可根据业务需求选择最合适的框架和部署方式，在无需深入了解底层框架的情况下即可搭建区块链底层平台，并实现上层应用的对接。

在笔者的咨询或实施服务过程中，时常会被问到关于判断区块链生态真假、好坏的问题。有些企业提出通过统计不同节点数量来进行判断：节点越多，生态越好。诚然，节点数量确实是判断一个区块链生态最直接的指标，但问题是：虽然统称为“节点”，但“节点”之间区别很大，只有根据各节点的性质和类型对这些节点的价值做出区分，再对不同价值的节点进行分层统计，才能够做出有意义的判断。笔者根据过往工程实践，将供应链金融与资产证券化业务中常见的节点类型及其参与方式做了如下总结。

其中比较特殊的是审计节点。在人民银行2020年初发布的《金融分布式账本技术安全规范》中，明确提出区块链平台需要配置监管节点，且监管节点能够查看业务数据、数据变更、访问记录、系统事件和审计行为记录等全量数据。笔者目前还未在已运营的平台上看到这样的节点，但随着数据运行标准的推行和监管制度的完善，审计节点势必将成为区块链平台的标配。

与节点及节点数量相关的另一个概念是共识机制。

2、共识机制

区块链系统需要通过共识机制来保证链上数据的一致性。共识机制是区块链概念里最抽象的技术，在联盟链里，共识机制的目的更多的是保持不同节点账本内容的一致。我们时常听到的BFT就属于此类共识机制，它的改进包括RBFT、PBFT等。市场上成熟的底层平台供应商一般会提供可插入式的共识机制供用户选择，目前绝大多数用户选择了PBFT。

Fabric一度不被认为是区块链，原因就在于其共识算法有点原始，不伦不类，遵循的还是传统分布式数据库使用的强一致性那套方法。这套方法为了保证共识机制的有效运作，构建了一套包含Peer、Orderer、CA三类节点的运作体系。

Peer节点一般称作背书节点。具体负责交易、智能合约的执行，账本数据都保存在这类节点上。单个Peer节点至少包含一个账本和一个智能合约，多个Peer节点组成一个区块链网络。Fabric将整个共识过程分为执行、排序和验证3个步骤。验证和执行相分离，非常灵活的同时也导致资源开销很大，在实际应用的过程中，这种方式被发现并不适用于生产环境。但在国内还是部署了不少这种共识算法的区块链底层平台，这也是笔者介绍上述共识算法的原因。

正是因为上述的不足，市场上陆陆续续产生了一些基于PBFT共识、对Fabric底层加以改进的区块链底层平台，并成为了主流。

在PBFT的容错模型中，网络中共识节点总数应等于或多于3f+1。其中，“f”为可容错节点的数量，例如：可容错的节点为f=1时，共识节点总数应等于或多于4个；可容错的节点为f=2时，共识节点总数应等于或多于7个；以此类推。

因此，单个机构掌握的节点数，应该小于PBFT可容错的数量。比如，区块链网络共识节点数为7个，那么单个机构掌握的共识节点不应多于2个，这样可以避免因机构私自修改参与共识数据而扰乱整个网络。看看市场上那些节点都部署在自己服务器内的区块链平台，所谓的“不可篡改”性有多大保障可见一斑。

区块链的“不可篡改”性是针对整个区块链网络的。某个或某些节点完全可以自己修改本地存储的参与共识的数据，但数据一旦被修改，区块链网络将会依靠共识机制检测出这些已被篡改的数据并拒绝其上链同步，这些节点将再也无法参与区块链网络上的共识。

3、部署方式

PBFT的共识机制决定了共识节点数量应该达到（3f+1）个以上，因此，由4个以上不同参与方共识节点组成的区块链网络才能真正实现不可篡改的特性。同时，为了保持区块链网络的稳定，共识节点通常需要部署在具有较强IT开发与维护能力的参与方中。这样的要求在供应链金融类区块链项目建设初期并不容易满足。

在供应链金融平台中，通常会在核心企业、商业银行、供应商部署共识节点，核心企业同时负责供应链金融平台开发和运维工作，并为其他参与方提供接入服务。商业保理公司既可作为共识节点独立部署，也可作为记账节点部署在核心企业的数据中心，具体要视其与核心企业的关系而定。

银行系统比较复杂，如果要实现区块链与银行核心系统的对接，通常需要将区块链网络布置在银行内网，并通过前置机实现与供应链金融平台、外部节点的连接。

除了共识节点外，每个参与方都可以部署其他不同类型的节点，这些节点只负责记账，不参与共识。不同的参与方只能访问自己的交易数据，但完整的账目信息都存储在底层的区块链平台上。

 联盟链需要具备对加入节点进行权限控制的功能：只有授权的机构才能访问区块链平台的接口和数据。技术上既包括一些传统的措施，如：对接入节点做IP控制、专线和配置节点信任列表等，也包括CA机制。

4、身份认证

由于金融业务需要遵从KYC的规则，因此身份认证、权限管理等模块必不可少。每个节点都要依次经历身份认证、数据上链、智能合约配置和智能合约执行四个步骤。

身份认证技术已经非常成熟：在供应链金融平台上，核心企业使用统一CA发放符合电子签名法规定的电子签名证书作为成员标识。平台用户每次登录平台时都须通过CA的U-Key或数字证书进行实名验证，验证其真实身份，并对在线确权、资产转让等行为进行签名。区块链平台同样也通过这套数字证书和数字签名机制来验证节点、应用服务器和用户的身份。

技术相对比较复杂的地方在于平台多级签名体系的开发。多级签名技术需要实现企业在供应链金融平台的U-Key或软证书数字签名、服务器的数字签名、区块链平台的公私钥数字签名和区块链节点间的公钥数字签名之间的映射，通过这种映射可以实现：

① 形成从供应链金融平台的交易指令到区块链记账的全过程数字签名的证据链，实现端到端的身份认证与签名验证体系，确保企业通过供应链金融平台访问区块链平台的过程中身份认证和操作信息的可追溯性，并且能够满足司法取证的要求；

② 企业实名注册后，区块链平台能够创建该企业对应的企业区块链账户地址，并将该账户地址作为区块链记账、对账和智能合约清分的基础。

供应链金融平台一般使用中国金融认证中心（CFCA）作为平台的身份认证中心。CFCA具有足够的权威性，具备完善的验证体系与安全保障，已经非常广泛的应用在了金融行业。当然也有一些平台使用非CFCA的证书，甚至是自己独立研发的CA。如果这些证书能够支持国密算法，签发的证书在格式上符合国密规范，支持可插拔的密码算法模块，那么在功能上完全可以满足供应链金融平台的需求。

5、系统架构

区块链并不适合金融交易的前端处理，通常需要将区块链平台与业务平台进行对接，由业务平台完成数据录入、交易处理后调用智能合约将相关信息上传到区块链平台，再由区块链平台将交易打包成块、广播、执行智能合约来驱动相关参与方的业务系统接收信息、生成交易，最后将交易数据存入对应数据库。为了能够完整实现上述交易流程，基于区块链的供应链金融平台应包括4个大的系统模块：供应链金融平台、应用API接口、区块链管理系统和区块链底层平台。我们可以通过下面的架构图来简要说明各模块间的关系。

① 供应链金融平台：实现“信宝单”类业务的拆转融操作；

② 应用API接口：封装应用系统与区块链的通信、认证、智能合约调用等交互功能，目的是简化区块链应用的开发。联盟链参与机构可以通过应用API接口，实现业务系统与区块链系统的直接通信，实现智能合约向链下结算系统发出指令进行链下结算。

业内通常将区块链管理系统与区块链底层平台统称为区块链平台。事实上，与其称作平台，更准确的应该叫做生态。开发门槛高、成本高和复杂性高等问题是行业内区块链应用落地时的普遍痛点。区块链生态内的中间件和组件的发展可以有效的解决这一问题，降低区块链落地的难度。中间件通过将具体业务和底层逻辑解耦，屏蔽了底层区块链平台的复杂性。前端的开发团队可以直接使用中间件的服务结果，不需要了解区块链底层逻辑具体如何实现，从而能够将注意力集中在自己的业务上。中间件简化了开发难度、缩短了开发周期、减少了运行维护工作量、降低了项目总成本，而使用中间件所带来的这些优势也正是大厂与区块链创业企业之间的差距所在：大厂能够搭建一个基于底层平台的生态圈，提供丰富的SDK工具集、可视化监控以及测试相关的组件；而创业企业大多只是对开源代码的简单二次开发，生态圈相对要弱很多。因此，企业在选择区块链技术合作方时，应该尽量选择蚂蚁金服、百度、京东等互联网大厂。

③ 区块链管理系统：提供区块链系统的管理功能，不同区块链厂家之间差别较大，但通常应该包括如下组件：

1. 身份管理：为新接入用户创建用户身份，自动部署Fabric节点，导入数字证书等；
2. 账户管理：封装公私钥相关功能，包括对私钥生成、存储、分发、导入、导出、使用、备份、恢复、归档与销毁等环节进行管理，以及私钥签名、验签、明文加密、密文解密四项使用功能，向上能够为业务系统提供非托管型和托管型两类接口；
3. 节点管理：维护联盟链内的参与方列表；
4. 智能合约管理：为开发团队提供合约仓库、IDE和通用模版，能够实现两类智能合约的发布、升级和撤销：

1. 标准化合约模版：针对简单场景，以数据上链存证为主，可以通过配置生成，无需二次开发；
2. 可编程合约：针对通用场景提供对应的模板，能够满足用户特定的开发需要。

除了上述四个组件，区块链管理系统还应该包括联盟链管理、密钥管理、机构管理、角色管理、文档管理和证书管理等至少6个组件，不再赘述。

④ 区块链底层平台：提供区块链基础服务，对内封装P2P、共识机制和账本数据，对外做建模适配，承接上层业务场景，提供区块链智能合约和系统信息访问接口。

当然，如果是为了满足政绩或外宣的需要，平台也可以开发一个区块链浏览器。在不涉及商业机密的情况下，区块链浏览器可以实时对外展示整个区块链底层存储交易、合约和区块信息。

三、业务设计

1、业务流程

虽然“信宝单”类业务流程比较简单，但为了文章的完整性和可阅读性，笔者仍然将其核心的业务流程做一叙述。考虑到使用泳道图反而较为复杂，所以简单的将“信宝单”类业务与区块链相结合的核心要点进行总结，以便读者更好的理解后续的技术实现方式。

① 授信：银行为核心企业核定可流转的银行保理额度，能够对授信额度做动态管理，根据运行情况可快速调整；

② 签发：根据授信，金融机构核定核心企业的签发额度，在线签订签发协议。核心企业上传供应商白名单并邀请白名单企业在平台注册，核心企业签署付款承诺函后向供应商签发凭证，凭证要详细记载付款方、收款方、付款日期和付款金额信息以及放弃抗辩权的声明。以上关键信息写入区块链，确保信息传递过程的真实性；

③ 签收：供应商上传基础交易合同、发票、结算单等证明贸易真实性的背景材料，签收核心企业签发的凭证；

④ 拆分流转：供应商签收核心企业的记账凭证后，可根据需要将凭证进行下一级拆分流转。凭证会记录签发凭证的企业信息，并且将该凭证信息记录到区块链上提供溯源信息；

⑤ 在线融资：供应商在收到凭证后，可基于自身需求，选择已入驻平台的各个资金方发起融资申请（供应商签署《保理协议》）。资金方接到各级供应商融资申请后，根据申请的凭证等信息进行审核，通过审核后可以在线实时放款（T+0）；

⑥ 中登登记：直连中登网,利用智能合约技术自动化实现每次转让的前手登记注销与后手转让登记,确保中登网权属登记信息与链上权属信息的一致；

⑦ 清分：到期后，核心企业在线付款，区块链平台和银行API结合，基于平台的银行虚拟账户体系，将资金清算与持有人信息勾稽，并借助智能合约技术，实现资金的自动流转、过程监管及到期自动清结算，提升供应链上资金流转的效率，降低风险。

2、交互过程

3、数据共享

基于区块链智能合约的应用，可以设计适用于多方参与场景下的数据分享与数据权限控制机制，从而确保数据的多方一致性与不可篡改，建立透明和安全的数据存储机制。

但区块链在数据存储方面还非常原始和简陋，底层以key-value键值对模型存储数据，无法记录如合同、单据、物流、资金清结算等交易背景和底层资产的详细信息，只能提供基于key的精确搜索，对于更广泛的基于业务数据的检索，存在效率低下的问题。

针对以上问题，在供应链金融与资产证券化业务场景中，系统需要对账本结构和分布式底层技术架构做扩展，将结构化数据直接存储在区块链账本上。因此在数据上链时需要通过对数据结构的设计，确保关键的、有价值的数据能存储于链上。这要求设计人员具有非常丰富的业务处理经验，熟悉整个供应链金融产品的交易流程。而基础合同、收发货凭证、物流单据、增值税专票和计量结算单据等文件数据则存储在IPFS上，并通过分级数据结构的链接关系（URL），使存储在IPFS的数据完整纳入区块链账本：

① 区块链账本上只保存相关协议文件块的Hash值、协议文件块的URL地址和协议文件块副本的URL地址（通常要搭建一个ODS数据库），保证协议信息在存储和流转的过程中只有拥有访问权限的用户才可以查阅，而协议本身存储在云服务器里；

② 部分单据涉及到图片上链，可通过OCR将图片信息抓取出来，实现自动化核对。图片信息全文Hash上链存储在区块链账本中，图片本身存储在云服务器里。

数据共享的前提是数据要上链。当前，市场上很多区块链平台上链只是上传数据的Hash值，不上传数据原文，需要通过链外的方式来传输原文并用Hash值对数据的完整性进行校验。采用这种方法的原因是担心数据隐私遭到泄露或被窃取，但这种数据上链的意义非常有限。在原始数据上链的项目中，为了保证计算效率，平台会结合对称加密的效率和非对称加密的安全性优点，实现数据的共享。

① 用Json格式将业务数据封装起来，并做序列化的处理；

② 生成AES密钥，用AES对业务数据进行加密，并得到加密后的数据；

③ 从区块链平台中查询各个接收方的公钥，将AES密钥用各个接收方的公钥加密（RSA加密）；

④ 将AES加密后的业务数据、经接收方的公钥加密后的AES密钥和接收方的通知队列数据写入智能合约中；

⑤ 区块链平台打包成区块，全网共识；

⑥ 接收方收到队列通知后，获取业务编号；

⑦ 通过业务编号获取到用AES加密后的业务数据，并用自己的私钥对AES解密；

⑧ 用解密后的AES密码解密业务数据；

⑨ 取得发送方上链的业务数据。

数据生命周期结束后，可将历史数据从区块链应用中迁移至其它存储位置进行归档，并支持单独查看归档数据。

4、数据加密与商业隐私保护

Fabric的优点在于数据同步传输，但在设计上对隐私问题缺乏足够的重视。Fabric中的数据隔离是通过账本实现的，平台在设计之初就需要将不关联的交易数据存储在不同的账本中。但在实际业务当中，往往存在在单个账本内进行数据隔离的需求，工程上只能通过在业务逻辑中对数据进行加密隔离的方式进行处理。但这也带来了问题：跨账本调用数据、或分属两个不同账本的数据进行交互的场景很难实现，只能在设计业务模型的时候做复杂的抽象，效率低下且难度很大。因此如果采用Fabric底层，平台需要在数据隔离和数据共享的设计上做进一步的优化和提升。

数据共享会牵涉到泄密的问题，尤其是商业数据。区块链的安全性与开放性始终是被企业质疑的隐患之一，也催生了仅Hash值上链这种“半残品”：数据Hash上链模式，无法做到在不披露数据明文的前提下实现链上数据的关联验证，在保障数据隐私性的过程中，牺牲了数据的流通性，限制了数据的效用。

为了有效促进区块链平台数据共享，帮助企业保护隐私，打消顾虑，在同态加密、零知识证明、联邦计算等技术尚未商用的情况下，区块链上生长出了一系列通过数据加密、数据权限控制来实现数据共享的方法和技术。

最简单粗暴的方式是链下控制，即通过上链SDK或代理节点进行访问控制。链下控制权限的方式略显粗糙，也存在漏洞。更精准的权限控制是对智能合约进行控制：联盟链底层平台能够支持合约权限管理，但颗粒度只能细化到以合约作为最小单位，通过智能合约本身管控合约权限可以进一步为合约中的每个函数单独设置权限，同一个合约中的不同函数可被设置为不同的权限。

下面是笔者看到的比较前沿又能实用化的方法：

① 精准授权加密：原理上其实就是非对称加密的改进，即数据参与方自己进行数据加密，加密之后可以在任何时间段决定谁能解读这个数据。数据全部是密码，查阅者需要向加密方申请后方可开放。数据所有方可以设定把数据开放给谁、开放多久以及何时停止开放。

② 交易权限控制：交易数据拆分成交易对手可读的共享区域和交易对手不可读的隐私信息区域，并通过点对点相互确认的方式来实现共享。为了确保“不可读的区域数据”在没有全网共识的情况下仍然能够实现不可篡改的目标，系统会将这部分数据Hash值上链，从而实现数据“可被验证但不可见”的目标。

5、智能合约设计

智能合约是区块链应用中最具误导性的概念。现实中，大多数企业/银行上区块链项目都是奔着智能合约去的，结果却发现智能合约既不智能也没合约。

简单来说，智能合约可以理解为一种计算机算法，能够智能化的执行一个协议，如约定好的契约、承诺、协议等。区块链的可编程性主要就体现在智能合约上，参与共识的节点可以通过共识约定当哪些事件被触发时，自动的执行智能合约。

供应链金融中能够适用智能合约的场景非常多，但因智能合约的需要操作对象大多为数字资产，受限于智能合约的局限性与业务的敏感性，真正投入生产的智能合约往往徒有其名，绝大多数取着“业务逻辑控制”的名称，实际实现的仅是资产信息、业务要素等的上链存证。

智能合约的设计总体来说有两种方法：

① 第一种是面向对象的设计方法：对于项目中的每一个对象都对应设计一份智能合约，比如商业银行是一个合约，供应商是一个合约，核心企业是另一个合约，通过第三个合约使之关联在一起，有点像E-RD的设计方法；

② 另一种是面向事件的设计方法：不同的对象表现为合约中的结构体，并且使用映射的方式存储。

目前市场上这两种方法都有，具体采用哪种方法依据场景的交互方式而定。对于后者而言，重点是要降低合约之间的耦合度。但无论采用哪一种设计方法，智能合约相关逻辑首先需要在所有参与者中达成共识。并且智能合约的执行应具有原子性，执行中如果出现异常，所有执行应被回滚，以保证数据一致性。

具体的合约设计因平台而异，差异较大。下表是笔者根据以往的项目经验，罗列的一些供应链金融平台中比较常见的智能合约。

四、价值与局限

“信宝单”是一种承载信用价值传递的工具，高度依赖于核心企业的信用。区块链在该类业务中的价值体现在确保核心企业信用在流转过程中不可篡改且可以溯源，亦即降低数据共享过程中可追溯与不被篡改的风险，而不是确保源头数据的真实性，因此自然无法验证贸易背景的真实性，亦无法降低欺诈风险。

现阶段就区块链的成熟度与接受度而言，区块链对融资效率的提升更多的体现在低成本、高效率的实现了多个参与方信息系统之间的链接，确保了数据在多个主体之间传输共享时的可追溯性与不可篡改性。

区块链强调多中心或去中心特性，而“信宝单”则是一个以核心企业为主导的非常中心化的价值体系。造成这种矛盾的原因在于区块链的应用有其特定的场景与条件。区块链需要与产业链进行深度融合，在尚未生成应收应付账款之前介入供应链，通过集成ERP系统，将发标、投标、开标、评标、中标、合同签订、发货、物流、订单履约、账款首付等重要流程上链，结合WMS、TMS和其他业务节点业务系统的数据验证，对供应链过程进行全生命周期的跟踪，从源头上确保贸易背景的真实性，杜绝欺诈风险。只有资产要素实时上链，才能真正发挥区块链的价值。

区块链不能承受的企业期望之重（1/5） – 分水岭

区块链不能承受的企业期望之重（3/5） – 更复杂的场景：资产证券化

若要了解更多区块链产品设计知识，或有区块链项目开发的合作需求，请联系我