基于区块链技术的房地产预售资金托管系统探究——以正泰公司托管系统改造为例

黄永锋，芮国荣，王嘉玮，薛 涵，史培中

（1.江苏理工学院 计算机工程学院，江苏 常州 213100；2.常州正泰房产居间服务有限公司，江苏 常州 213001）

2011年下半年至2015年，常州房地产市场经历了较长时间的下行调整周期。其间，常州市区部分房地产项目因资金链断裂，发生停工烂尾、开发商跑路、交付逾期等问题，影响了各界对房地产市场的信心。为此，2016年起常州市在全国率先开展了商品房预售资金第三方托管工作。在常州住房和城乡建设局直接指导下，由常州正泰房产居间服务有限公司（以下简称“正泰公司”）全权负责常州市新建商品房预售资金第三方托管工作的具体实施[1-2]。

为了提高托管信息的共享水平，正泰公司开发了“常州市商品房预售资金第三方托管系统”（以下简称“托管系统”），并与商品房预售系统、银行信贷系统及开发企业的业务系统进行了对接，为用户提供简便、易用的托管资金服务平台。虽然托管系统一定程度上保障了房地产预售资金的安全，但是，该系统是基于中心化数据库设计与实现的，使用过程中出现了以下一些问题。

1 现有托管模式的流程及问题

系统托管模式的业务流程如图1[3]所示，主要过程如下：（1）商品房预售前，开发企业与托管机构（正泰公司）之间签订托管合作协议，根据商品房备案均价确定初始托管总额（即购房人最初应在托管机构托管的资金数额）；（2）预售开始后，购房人贷款购买预售房屋，与开发企业、托管机构三方之间签订三方合作协议，约定把银行的贷款部分直接放款至托管机构在银行设立的托管账户；（3）后续，托管账户中的资金将由托管机构根据托管项目完成“正负零”（主体地下工程完成）、主体1/2、主体封顶、外立面装饰、交付备案等多个工程节点，逐步释放至开发企业在银行设立的预售资金监管账户。

图1 托管业务流程

根据托管流程，签订托管合作协议、确定初始托管总额以及按工程节点分期付款等流程，需要在托管机构内部进行审核。为确保托管数据的正确性，涉及到资金审核的流程应非常谨慎。但是，由于预售资金托管系统开发无成熟先例可循，而各种托管政策与流程又经常会修订，托管系统管理员为提高效率往往会采用即时升级和后台数据直接处理的方式，来适应政策的要求。这样，极易引入软件Bug，引起托管数据异常。而且，以单一中心化数据库为业务数据存储的托管系统，本质上无法解决数据易被篡改的风险。无论是系统管理员和黑客，理论上都可篡改数据且不留痕迹，这些数据异常有时极难发现；即使被发现，传统技术下也很难追溯异常出现的原因[4]。总结起来，当前托管系统的数据安全存在以下4个方面的问题。

1.1 异常数据检测难

现有的技术手段无法锚定审批数据，而这些数据有时涉及较大的资金转移，因此数据异常带来的后果非常严重。例如，资金拨付金额经过审批后，仍可能在拨付前被篡改，致使真实资金拨付与审批时存在较大偏差，引发托管资金安全问题。而且，由于缺乏可信的数据参照，现有技术手段无法及时检测出异常数据，而涉及关键数据的核实往往需要人工介入，耗时费力且容易出错。

1.2 异常业务追溯难

一次托管业务的办理可能涉及多位操作员，由于异常不能被及时发现和记录，业务办理过程中，某位操作员即使发现了当下业务中的数据异常，也很难追溯异常出现的准确时间与原因。数据异常出现时，由于缺乏可信的数据参照，数据的恢复处理也非常困难。

1.3 审计真实性低、实时性弱

商品房预售资金托管系统管理着房地产预售相关的大量资金，通常是重点审计对象。传统审计一般是事后或现场审计，这种审计方式存在时间滞后，实时性弱的问题。传统中心化数据库的特点也给审计数据的非法篡改留下了足够空间，容易导致审计数据的真实性缺失。

1.4 对账繁琐易出错

首先，现有托管业务中的很多数据是基于其他基础数据计算得来的，由于部分计算逻辑复杂，现有的基础数据本身并不可信，因此托管系统的计算逻辑可能会存在错误；于是，业务审批时不得不对大量关键数据进行手工核实，以确保数据的准确性。其次，由于缺乏可信的数据参照，托管系统经常要定期人工核对各类数据，以确保数据的正确性与一致性，这些对账操作繁琐且容易出错。

2 区块链技术及应用

作为近年来的新兴技术，区块链在企业信息化可信安全应用上有着传统技术无法比拟的优势[5]：由于技术上难以篡改，上链的业务状态数据可作为后续的数据参照以解决异常数据检测的问题，上链的业务流数据可以辅助业务追溯；实时同步的可信分布式账本技术，可以解决传统审计真实性低及实时性弱的问题；智能合约可从另一套程序逻辑自动核实关键业务数据计算的准确性。通过引入区块链技术，有望解决托管系统现有的问题与缺陷。

2.1 区块链核心技术

区块链是一种由多方共同维护的分布式账本技术[6]，其核心技术源自比特币（Bitcoin）[7]，本质是一种去中心化、不可篡改、可追溯、多方共同维护的分布式数据库[5]，可在互不了解的多方间建立信任。基于节点间信任关系与开放对象的区别，区块链主要分为公有链、私有链和联盟链[8]。作为一种在不可信环境中低成本建立信任的新型计算范式，区块链正在改变诸多行业的运行规则，有望成为未来数字社会构建新型信任体系的关键技术。

区块链并非是一种单项技术，而是一种由原本存在的多种技术汇聚融合形成的创新；其核心技术包括默克尔树[9]、数字签名、共识机制[10-12]，这些技术巧妙地结合起来形成了多方共同维护、环环相扣的区块链结构，实现了数据的不可篡改和可追溯。区块链上的另一核心技术是智能合约[13]，是用程序语言编写的商业合约。区块链环境使得智能合约在没有中心管理者的情况下，可自动同时运行在全网所有节点上。与传统合约相比，智能合约解决了“信用”问题，即：合约缔结前无需信用调查，缔结后也不用第三方担保履行，交易成本大幅降低，交易效率则大幅提高，简化了多方协作流程，支撑起自动化协作和价值互联应用的实现。

2.2 区块链行业典型应用

当前区块链技术的发展主要以行业应用为驱动。2019年以来，我国政府高层为区块链发展进一步指明了方向，重点发展服务于实体经济的产业区块链[14]。目前，国内企业重点聚焦于服务实体经济，改善政府民生相关的区块链行业应用，主要包括供应链金融[15]、产品溯源[16]、司法存证[16]、政务数据共享[16]、资金管理[15]与房地产交易[17-19]。

3 “微改造”方案

3.1 系统业务场景分析

托管系统的主要业务是管理托管资金。当前，资金主要围绕托管楼栋（如常州**房地产开发有限公司**花园项目*区*幢）进行管理。托管楼栋的核心数据包括：当前托管余额、初始受限额度（或初始托管总额）、有效受限额度及当前受限比例。其中，有效受限额度可以理解为针对某楼栋由托管机构托管，且暂时不可提取的资金，即有效受限额度=初始受限额度×当前受限比例。不同的工程节点形象进度对应不同的受限比例，一般初始为100%，最终（房屋交付备案时）为0。当前托管余额与有效受限额度的差值就是该托管楼栋可被释放的资金，即针对该楼栋开发商可提取的资金。随着工程的进展，有效受限额度将越来越小，意味着被托管的资金越来越少。

根据托管模式，托管系统关键业务的数据变更主要发生在托管楼栋的有效受限额度发生变化（如工程取得阶段性进展）或者与楼栋相关的托管资金数据发生变化（如购房人按揭贷款到账）的时候，这些数据变更可能引起托管楼栋可释放资金的变化，具体场景主要包括：（1）降节点支付，形象进度节点和支付比例发生更新，引起有效受限额度变更；（2）支付保函，企业经营及信誉良好，可开具支付保函，引起有效受限额度变更；（3）贷款发放，购房人贷款的发放导致楼栋的当前托管余额发生变化；（4）退房退款，购房人退房退款的行为引起楼栋当前托管余额发生变化；（5）特殊支付，特殊支付引起楼栋当前托管余额等发生变化。

为捕获关键数据的异常变化，需要在这些场景的业务流程中引入关键数据安全校验，即针对托管系统的每一个业务流程，在相关人员进行关键业务操作前（如资金拨付前），对业务中涉及的关键数据进行安全校验，以确保数据准确性，只有校验通过才可进行下一步业务操作。业务操作完成后，涉及业务的变更数据将进行上链锚定，为后续安全校验提供可信的数据参照。

3.2 总体技术架构

根据上述背景，考虑引入区块链技术以解决托管系统的问题。鉴于业务系统底层为关系型数据库，托管业务需要支持丰富的SQL查询，如果对现有托管系统进行全新的基于区块链的设计，不可避免要做链上数据与数据库数据的融合，整个业务逻辑的实现需要重构，会对现有运行的托管系统改动大，因此安全风险也高。另外，在对托管系统业务审批操作过程中，审批人员要对一些关键业务数据进行审核，这些数据仅由托管系统计算，因某些计算逻辑比较复杂，存在无法避错的问题，为此，审批人员不得不进行人工校验，以核实关键数据计算的准确性。

基于以上两点，本文提出如下设计方案：独立于原托管系统之外，利用区块链技术构建独立的数据安全应用，以提供关键数据的校验服务；该服务一方面比对托管系统中的基础数据是否与链上参照一致，同时还对托管系统计算得到的数据提供独立的逻辑校验，只有当托管系统本身的计算逻辑与数据安全应用的计算逻辑吻合时，数据校验才能通过。方案总体技术架构如图2所示。总体架构中，数据安全应用是方案的核心，设计独立的数据安全应用，可以实现下列目标：

图2 “微改造”方案总体技术架构

（1）托管系统在可能发生关键数据变更的业务操作前调用数据安全应用完成数据校验，确保每一次关键业务操作的安全；

（2）提供业务追溯与纠错功能；

（3）托管系统开发人员可在不了解区块链技术的情况下，通过调用数据安全应用相关接口来完成链上数据存取；

（4）数据安全应用成为访问区块链的唯一入口，可统一在数据安全应用中加入对区块链的访问控制，规避对链上数据的非法访问。

这种采用独立数据安全应用的方案，仅需对原托管系统进行代价极小的“微改造”。下面将从链上数据组织、数据安全应用详细设计、区块链平台选型等几个方面对“微改造”方案进行阐述。

3.3 链上数据组织

区块链上的核心数据结构围绕托管楼栋信息进行设计，托管楼栋信息维护的总体流程如图3所示。楼栋信息具有一定的生命周期，起于托管合作协议的签订（实际，一份协议可能涉及多个托管楼栋，协议签订后，相关楼栋的预售资金正式启动托管），止于楼栋交付备案（楼栋交付后，针对该楼栋的托管工作结束）。托管楼栋信息主要由楼栋的状态数据以及引起状态数据变更的各种流数据（如审批流、结算流、资金流）组成，详细的状态和流数据参见表1。

图3 托管楼栋信息维护流程

表1 托管楼栋链上数据组织

托管协议审批后，相关托管楼栋状态数据上链。随着楼栋工程形象节点的推进和资金出入，链上楼栋的状态数据也发生相应变更。任何一次状态数据的变更由某个流（如审批流）引起。所有引起状态数据变更的详细流信息都及时上链，以方便业务追溯。

3.4 数据安全应用的具体设计

数据安全应用分成Restful API、独立应用服务及区块链SDK三部分，见图2。Restful API向托管系统提供服务接口，包括数据校验接口、数据上链接口以及数据感应接口；独立应用服务以Web方式提供自动对账、校验查询及数据校正服务；区块链SDK提供区块链底层操作封装，为Restful API与独立应用服务提供区块链操作的接口。

3.4.1 Restful API

（1）数据校验接口。数据校验接口一般由托管系统在关键业务审批操作前调用。只有校验通过后，托管系统操作员才可进行审批，否则托管系统将提示操作员需要进行校验异常处理。为了校验逻辑更清晰，提高校验的效率和准确性，一般情况下，审批操作前需要完成下列三种校验：

a.规范性校验。主要核实数据的完整性，即核实数据的必填项是否有缺失，数据类型是否正确。

b.比对校验。比对托管系统中当前的基础数据是否与链上参照数据一致，以确保托管系统中当前数据在上次业务操作后没有被篡改过。

c.逻辑校验。比较托管系统中的计算数据逻辑是否正确。计算数据由基础数据计算后得到（如托管楼栋的初始托管总额），是业务操作关注的重点。由于涉及金额较大，仅依赖托管系统的计算难免出错，因此需要另外独立的实现，来交叉验证托管系统计算的正确性。正是由逻辑校验承担这种独立交叉校验的功能，它可采用智能合约来实现。

（2）数据上链接口。数据上链接口由托管系统调用，上链的可能是托管楼栋的状态数据，也可能是引起状态数据变化的详细审批流信息（见表1）。如果审批分为初审、会审及终审等多个阶段（这些阶段属于同一个审批流），一般初审时需要对数据进行全面的规范性校验、比对校验和逻辑校验。校验通过后，上链该审批流的初审信息。其它审批操作前，仅需与上链的初审信息进行比对，无需再重复规范性和逻辑校验，以防止审批过程中的数据篡改。终审后，可以直接借助已校验过的审批流信息来更新链上托管楼栋的状态数据。为方便业务追溯，需要在楼栋状态数据中写入引起状态数据更新的相关审批流ID。

由于区块链底层的上链过程需经过节点共识，交易确认较耗时。考虑区块链SDK操作失败的可能性（如网络中断）及托管系统的用户体验，把数据上链接口设计为异步调用。整个接口分为预上链接口、预上链队列及上链守护程序三个部分：

a.预上链接口，负责接收托管系统提交的上链数据；接收后，直接插入预上链队列；然后给托管系统返回预上链成功信号。这样，托管系统上链操作无须等待真正上链交易的完成。

b.预上链队列，负责暂存准备上链但还未被写入区块链的交易数据。

c.上链守护程序，负责不断移出预上链队列中的数据，并通过区块链SDK向区块链服务提交交易。上链失败的数据会被重新插回预上链队列等待重新上链，直至达到某个预设的最大预上链次数为止。

（3）数据感应接口。区块链数据成功上链后，可通过数据感应接口（可为区块链上链事件注册服务回调处理机制）感知到上链的数据状态，托管系统也可以向数据感应接口发送指令，查询上链结果。

综上所述，以托管系统的初审为例，数据上链及感应过程中各系统间的数据流交互如图4所示。

图4 初审时数据上链及感应过程中系统数据流交互图

3.4.2 独立应用服务

（1）自动对账。该服务一方面向托管系统查询指定的托管楼栋涉及的状态数据和审批流数据，另一方面向区块链查询指定的托管楼栋涉及的状态数据和审批流数据，并提供两边数据的自动核对。

（2）数据校正服务。为了适应新的托管政策，可能需要对托管系统中的数据进行修正。这种合理的数据变更会引起托管系统与链上数据的不一致，导致托管业务无法继续进行。此时，可利用数据校正服务对托管楼栋的链上状态数据进行校正，以解决托管系统与链上状态数据的不一致问题。考虑到业务的可追溯性，数据校正服务也采用审批机制，即需要走“校正申请、校正审批”的流程，该审批流同样需要上链。

（3）日志查询服务。各接口中涉及的校验过程、上链过程均须写入数据安全应用的本地数据库，以便当托管系统中的数据与链上数据不一致时，可利用日志查询服务丰富的SQL查询功能，辅助分析数据不一致的原因。

3.4.3 区块链SDK

Restful API与独立应用服务通过区块链SDK来操作区块链，这样做的好处是：（1）托管系统开发者在不了解区块链技术的情况下也可进行链上数据的存取，减少了托管系统改造的代价；（2）访问区块链的身份密钥仅内置在数据安全应用中，数据安全应用封装了区块链的所有底层操作，方便对区块链存取实施统一控制，托管系统不可直接操作区块链，避免了托管系统控制校验与上链的过程。

3.5 区块链平台选型

“微改造”初期，区块链底层平台主要定位为私有链。考虑到托管系统后期要与房地产交易其它部门的平台进行对接，因此采用联盟链来实现“微改造”。主要调研了下列几种方案：（1）开源Fabric技术。Fabric源于IBM开源可插拔联盟链技术[20]，目前已成为事实上的联盟链标准。（2）基于Fabric技术的区块链云服务。各个互联网头部公司（华为、腾讯、阿里）都提供了基于增强版Fabric技术的区块链云服务。（3）头部公司自研区块链云服务：如阿里系的蚂蚁链①、腾讯系的TrustSQL②、华为的自研链③等。（4）区块链专业公司自研云平台。如荣泽区块链④、复杂美区块链⑤、趣链⑥等。

方案（1）完全开源，无需底层平台费用，但支撑的交易吞吐量较低[21]。其它方案需要较为昂贵的底层平台费用，但能够支撑更高的交易吞吐量，也更易于使用扩展。相比方案（2）与（3），方案（4）虽然前期费用高，但如果长期使用，总的费用则更便宜，且用户可以更好地控制自己的数据。由于方案（1）支撑的交易吞吐量在项目初期能够满足现有业务吞吐量需求，综合评估后，初期就采用方案（1），后期拟根据业务扩展需要采用方案（4）构建底层区块链平台。

4 “微改造”案例

为了测试改造效果，开发了“微改造”原型系统，下面以图3中的“托管协议审批”业务为例进行阐述。该业务审批过程如图5所示，其中，左侧为改造前的审批流程，右侧为改造后注入的校验和上链环节。从图5可以看出，安全校验并不更改原业务流程，而是采用增量式改造，代价较小。

图5 托管协议审批过程中的校验与上链

4.1 基础设置

托管系统采用SpringBoot+Vue.js实现；数据安全应用基于SpringBoot构建Restful API；底层区块链平台采用Fabric 2.2，基于docker配置。区块链网络[22]如图6所示：包含2个peer节点（各带1个couchdb节点作为peer节点的状态数据库）、1个order节点及1个cli节点（用来执行Fabric命令）。

图6 正泰区块链网络配置

为了测试改造效果，在改造后的托管系统中设置了8个测试用户；其中，1个为管理员，另外7个分别对应图5中的相关角色，如表2所示。

表2 测试用户列表

4.2 安全校验测试

严格按照图5设计的流程进行安全校验测试。最初，开发企业申请托管。此时，托管系统生成托管合作协议的审批流ID（用“AgreementList：协议ID”表示）；然后，由托管机构相关人员对托管协议进行逐层审批，以业务部门员工ztywyg2审批为例（初审）。审批时，托管系统调用数据安全应用的校验接口进行规范性校验和逻辑校验（与其它审批初审不同的是，托管协议初审时楼栋的状态数据还未上链，无需进行比对校验）。由于规范性校验较简单，此处仅测试逻辑校验效果。为此，特意在托管系统初始托管总额计算逻辑的实现中引入Bug，即初始托管总额=楼栋单价×楼栋面积×托管比例+10，见图7（a），而原本正确的初始托管总额=楼栋单价×楼栋面积×托管比例。托管协议初审时，逻辑校验比较托管系统和链上智能合约的计算结果，见图7（b）。由于初始托管总额在智能合约的计算中使用了正确逻辑，而在托管系统中使用了错误逻辑，校验发现两者计算结果不一致，显示校验错误，见图7（c），这个测试结果符合预期。

图7 逻辑校验测试

交叉校验的思路来源于文献[23]。针对托管系统中的计算数据，由独立的开发者使用与托管系统不同的开发语言来实现该数据的计算和校验。不同开发人员使用不同语言实现的计算逻辑中，出现相同错误的概率非常小，加上交叉校验采用智能合约的方式实现，部署后难以篡改，从而保证能够及时安全地发现托管系统中计算逻辑的错误，也可以对托管系统中计算逻辑的恶意篡改起到预防作用。

测试后，恢复了托管系统中“初始托管总额”正常的计算逻辑。此时，安全校验成功，“审核通过”按钮被激活。审核通过后，初审信息上链，区块链中写入初审流数据（Key，Value）对。其中，Key为审批流ID，即“AgreementList：34”，后续可籍此Key值来追溯协议的整个审批流程；Value为托管协议的初审信息，见图8。初审通过后，使用业务部门经理ztywyg1账户继续进行审批。此时，托管系统调用数据安全校验接口进行比对校验。为了测试比对效果，故意篡改了托管系统中的楼栋面积，从10 000 m2改为8 000 m2。在业务部门经理审批时的比对校验过程中，立即发现了托管系统当前的数据与该审批流链上最新数据（Value值）不一致，因此审批无法进行，见图9。可见，针对托管系统基础数据的任何篡改都能够在审批过程中被及时发现。

图8 初审后通过区块链浏览器[24]查看的上链数据

图9 比对校验异常

恢复篡改的楼栋面积为正常值后，审批可继续进行。根据图5，当托管协议完成了所有审批后，托管楼栋状态数据（Key，Value）初次形成并上链。为区别于托管协议审批流数据，此处托管楼栋状态数据的Key值设为“HostBuilding：34”，为可全局唯一标识该楼栋，代表该楼栋状态数据产生自ID=34的托管协议；Value字段内容见前文表1，其中引起状态变化的流ID字段为“AgreementList：34”，代表ID=“AgreementList：34”的托管协议审批流引起了该状态数据的更新。以上信息是托管楼栋状态数据在链上的初次锚定，可为后续该托管楼栋其它审批流（如资金入账）的初审提供比对校验的数据参照。

4.3 业务追溯

托管系统业务追溯的核心是跟踪楼栋状态数据（见表1）的变化，这种追溯本质上可以视为一个二维过程。首先，楼栋状态数据的变化由各种审批流引起，其状态值Value的所有变化历史可从链上获取，只需通过“getHistoryFor-Key（key）⑦”接口调用，即可得到协议ID为34的楼栋状态值链上的变化历史，从而得到引起变化的所有审批流ID。其中，“AgreementList：34”为引起状态数据变化的第一个审批流ID。其次，审批流的详细审批过程也可以根据接口调用“getHistoryForKey（key）”得到。图10展示了通过该接口调用得到的链上托管协议审批流（审批流ID=“AgreementList：34”）的详细审批信息。因此，托管楼栋的状态变化可实现全程追溯。因为校验与上链交替进行、环环相扣，一旦校验异常，审批就无法继续，所以，审批流程中的所有校验异常都能及时被发现和上链锚定，业务办理中出现过的异常就很容易溯源。

图10 托管协议审批流链上历史追溯

通过以上校验用例，可以进一步体会本文基于区块链技术系统设计的两个核心理念：（1）业务系统的流程中仅增加了校验与上链接口调用，实际的校验和上链操作与业务系统隔离，被统一封装在独立的数据安全应用里；如此，不仅减小了业务系统改造的代价，也增强了区块链操作的安全性。（2）业务流程中的所有关键操作都要进行数据校验，校验的参照数据来自上一流程，或者本流程上一个环节在区块链上锚定的数据；校验和上链交替进行、环环相扣，能够及时检测出系统中的数据异常。

5 结语

本文详细分析了正泰公司现有的托管业务流程及托管系统存在的问题，针对房地产预售资金托管过程中存在的数据安全隐患，基于区块链技术设计了保障托管系统关键业务数据安全的技术方案。在不改变原有托管业务系统核心流程与数据库设计的基础上，用最小的代价达成了下列目标：

（1）异常数据检测。托管系统改造后，所有楼栋的状态数据除了存储在原系统中，在区块链上也进行了存储；关键业务数据都要经过规范性校验、比对校验和逻辑校验方可进行变更。其中，规范性校验杜绝了关键数据项的缺失；比对校验核实业务系统中的基础数据是否正确，在审批通过后，托管系统中的数据一旦被篡改，系统具有及时发现并纠正的机制；逻辑校验实现了计算数据的交叉验证，防止原业务系统单方面计算可能出现的错误。链上数据提供的参照，以及上链与校验交替进行的过程，使得数据异常检测变得容易，有效规避了提交错误数据的可能，确保了关键业务的数据安全。

（2）异常业务追溯。因为上链与校验环环相扣，异常数据及当时的状态信息能够被及时侦测和上链。经过“微改造”，业务办理做到了事事留痕，托管楼栋状态变化的全流程可按时间顺序进行追溯，任何一个办理环节曾出现过的问题及相关信息，都能够方便地进行溯源。

（3）审计实时性高，审计数据可信。经过“微改造”，审计机构只要接入区块链网络，任何一笔业务办理数据都可以实时地被推送到审计机构（审计机构中具备权限的人员可随时访问）；由于区块链的特性，审计机构人员无须进入审计企业就可获得实时可信的审计数据。

（4）对账便捷自动化。对账便捷自动化主要体现在两方面：首先，在原先的业务审批操作中，操作员在审批前必须对许多关键数据进行手工计算，以核实数据的准确性，改造后，这种繁琐且易出错的手工核实操作，由数据安全应用的比对校验和逻辑校验自动完成。其次，数据安全应用提供自动对账服务，该服务同时从托管系统和区块链获取指定楼栋的状态数据和审批流数据，对两边数据进行自动核对，避免了为确保系统数据正确性与一致性而进行的日常人工对账。

总之，本文设计的基于区块链技术的“微改造”方案，以较小的代价、较高的安全性，完美地解决了现有托管系统遭遇的痛点，对类似的基于中心数据库的信息管理系统改造，也有较强的参考意义。

注释：

①https：//antchain.antgroup.com/products/baas。

②https：//trustsql.qq.com/index.html。

③https：//www.huaweicloud.com/product/bcs.html。

④http：//www.rongzer.com/index.aspx。

⑤https：//www.fuzamei.com/home。

⑥https：//www.hyperchain.cn/。

⑦Fabric chaincode API中 的 函 数，chaincode即Fabric智 能合约。