基于區塊鏈技術的房地產預售資金托管系統探究
——以正泰公司托管系統改造為例

黃永鋒，芮國榮，王嘉瑋，薛 涵，史培中

（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智 能合約。