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

（1.江蘇理工學院 計算機工程學院，江蘇 常州 213100；2.常州正泰房產(chǎn)居間服務(wù)有限公司，江蘇 常州 213001）

2011年下半年至2015年，常州房地產(chǎn)市場經(jīng)歷了較長時間的下行調(diào)整周期。其間，常州市區(qū)部分房地產(chǎn)項目因資金鏈斷裂，發(fā)生停工爛尾、開發(fā)商跑路、交付逾期等問題，影響了各界對房地產(chǎn)市場的信心。為此，2016年起常州市在全國率先開展了商品房預(yù)售資金第三方托管工作。在常州住房和城鄉(xiāng)建設(shè)局直接指導(dǎo)下，由常州正泰房產(chǎn)居間服務(wù)有限公司（以下簡稱“正泰公司”）全權(quán)負責常州市新建商品房預(yù)售資金第三方托管工作的具體實施[1-2]。

為了提高托管信息的共享水平，正泰公司開發(fā)了“常州市商品房預(yù)售資金第三方托管系統(tǒng)”（以下簡稱“托管系統(tǒng)”），并與商品房預(yù)售系統(tǒng)、銀行信貸系統(tǒng)及開發(fā)企業(yè)的業(yè)務(wù)系統(tǒng)進行了對接，為用戶提供簡便、易用的托管資金服務(wù)平臺。雖然托管系統(tǒng)一定程度上保障了房地產(chǎn)預(yù)售資金的安全，但是，該系統(tǒng)是基于中心化數(shù)據(jù)庫設(shè)計與實現(xiàn)的，使用過程中出現(xiàn)了以下一些問題。

1 現(xiàn)有托管模式的流程及問題

系統(tǒng)托管模式的業(yè)務(wù)流程如圖1[3]所示，主要過程如下：（1）商品房預(yù)售前，開發(fā)企業(yè)與托管機構(gòu)（正泰公司）之間簽訂托管合作協(xié)議，根據(jù)商品房備案均價確定初始托管總額（即購房人最初應(yīng)在托管機構(gòu)托管的資金數(shù)額）；（2）預(yù)售開始后，購房人貸款購買預(yù)售房屋，與開發(fā)企業(yè)、托管機構(gòu)三方之間簽訂三方合作協(xié)議，約定把銀行的貸款部分直接放款至托管機構(gòu)在銀行設(shè)立的托管賬戶；（3）后續(xù)，托管賬戶中的資金將由托管機構(gòu)根據(jù)托管項目完成“正負零”（主體地下工程完成）、主體1/2、主體封頂、外立面裝飾、交付備案等多個工程節(jié)點，逐步釋放至開發(fā)企業(yè)在銀行設(shè)立的預(yù)售資金監(jiān)管賬戶。

圖1 托管業(yè)務(wù)流程

根據(jù)托管流程，簽訂托管合作協(xié)議、確定初始托管總額以及按工程節(jié)點分期付款等流程，需要在托管機構(gòu)內(nèi)部進行審核。為確保托管數(shù)據(jù)的正確性，涉及到資金審核的流程應(yīng)非常謹慎。但是，由于預(yù)售資金托管系統(tǒng)開發(fā)無成熟先例可循，而各種托管政策與流程又經(jīng)常會修訂，托管系統(tǒng)管理員為提高效率往往會采用即時升級和后臺數(shù)據(jù)直接處理的方式，來適應(yīng)政策的要求。這樣，極易引入軟件Bug，引起托管數(shù)據(jù)異常。而且，以單一中心化數(shù)據(jù)庫為業(yè)務(wù)數(shù)據(jù)存儲的托管系統(tǒng)，本質(zhì)上無法解決數(shù)據(jù)易被篡改的風險。無論是系統(tǒng)管理員和黑客，理論上都可篡改數(shù)據(jù)且不留痕跡，這些數(shù)據(jù)異常有時極難發(fā)現(xiàn)；即使被發(fā)現(xiàn)，傳統(tǒng)技術(shù)下也很難追溯異常出現(xiàn)的原因[4]。總結(jié)起來，當前托管系統(tǒng)的數(shù)據(jù)安全存在以下4個方面的問題。

1.1 異常數(shù)據(jù)檢測難

現(xiàn)有的技術(shù)手段無法錨定審批數(shù)據(jù)，而這些數(shù)據(jù)有時涉及較大的資金轉(zhuǎn)移，因此數(shù)據(jù)異常帶來的后果非常嚴重。例如，資金撥付金額經(jīng)過審批后，仍可能在撥付前被篡改，致使真實資金撥付與審批時存在較大偏差，引發(fā)托管資金安全問題。而且，由于缺乏可信的數(shù)據(jù)參照，現(xiàn)有技術(shù)手段無法及時檢測出異常數(shù)據(jù)，而涉及關(guān)鍵數(shù)據(jù)的核實往往需要人工介入，耗時費力且容易出錯。

1.2 異常業(yè)務(wù)追溯難

一次托管業(yè)務(wù)的辦理可能涉及多位操作員，由于異常不能被及時發(fā)現(xiàn)和記錄，業(yè)務(wù)辦理過程中，某位操作員即使發(fā)現(xiàn)了當下業(yè)務(wù)中的數(shù)據(jù)異常，也很難追溯異常出現(xiàn)的準確時間與原因。數(shù)據(jù)異常出現(xiàn)時，由于缺乏可信的數(shù)據(jù)參照，數(shù)據(jù)的恢復(fù)處理也非常困難。

1.3 審計真實性低、實時性弱

商品房預(yù)售資金托管系統(tǒng)管理著房地產(chǎn)預(yù)售相關(guān)的大量資金，通常是重點審計對象。傳統(tǒng)審計一般是事后或現(xiàn)場審計，這種審計方式存在時間滯后，實時性弱的問題。傳統(tǒng)中心化數(shù)據(jù)庫的特點也給審計數(shù)據(jù)的非法篡改留下了足夠空間，容易導(dǎo)致審計數(shù)據(jù)的真實性缺失。

1.4 對賬繁瑣易出錯

首先，現(xiàn)有托管業(yè)務(wù)中的很多數(shù)據(jù)是基于其他基礎(chǔ)數(shù)據(jù)計算得來的，由于部分計算邏輯復(fù)雜，現(xiàn)有的基礎(chǔ)數(shù)據(jù)本身并不可信，因此托管系統(tǒng)的計算邏輯可能會存在錯誤；于是，業(yè)務(wù)審批時不得不對大量關(guān)鍵數(shù)據(jù)進行手工核實，以確保數(shù)據(jù)的準確性。其次，由于缺乏可信的數(shù)據(jù)參照，托管系統(tǒng)經(jīng)常要定期人工核對各類數(shù)據(jù)，以確保數(shù)據(jù)的正確性與一致性，這些對賬操作繁瑣且容易出錯。

2 區(qū)塊鏈技術(shù)及應(yīng)用

作為近年來的新興技術(shù)，區(qū)塊鏈在企業(yè)信息化可信安全應(yīng)用上有著傳統(tǒng)技術(shù)無法比擬的優(yōu)勢[5]：由于技術(shù)上難以篡改，上鏈的業(yè)務(wù)狀態(tài)數(shù)據(jù)可作為后續(xù)的數(shù)據(jù)參照以解決異常數(shù)據(jù)檢測的問題，上鏈的業(yè)務(wù)流數(shù)據(jù)可以輔助業(yè)務(wù)追溯；實時同步的可信分布式賬本技術(shù)，可以解決傳統(tǒng)審計真實性低及實時性弱的問題；智能合約可從另一套程序邏輯自動核實關(guān)鍵業(yè)務(wù)數(shù)據(jù)計算的準確性。通過引入?yún)^(qū)塊鏈技術(shù)，有望解決托管系統(tǒng)現(xiàn)有的問題與缺陷。

2.1 區(qū)塊鏈核心技術(shù)

區(qū)塊鏈是一種由多方共同維護的分布式賬本技術(shù)[6]，其核心技術(shù)源自比特幣（Bitcoin）[7]，本質(zhì)是一種去中心化、不可篡改、可追溯、多方共同維護的分布式數(shù)據(jù)庫[5]，可在互不了解的多方間建立信任。基于節(jié)點間信任關(guān)系與開放對象的區(qū)別，區(qū)塊鏈主要分為公有鏈、私有鏈和聯(lián)盟鏈[8]。作為一種在不可信環(huán)境中低成本建立信任的新型計算范式，區(qū)塊鏈正在改變諸多行業(yè)的運行規(guī)則，有望成為未來數(shù)字社會構(gòu)建新型信任體系的關(guān)鍵技術(shù)。

區(qū)塊鏈并非是一種單項技術(shù)，而是一種由原本存在的多種技術(shù)匯聚融合形成的創(chuàng)新；其核心技術(shù)包括默克爾樹[9]、數(shù)字簽名、共識機制[10-12]，這些技術(shù)巧妙地結(jié)合起來形成了多方共同維護、環(huán)環(huán)相扣的區(qū)塊鏈結(jié)構(gòu)，實現(xiàn)了數(shù)據(jù)的不可篡改和可追溯。區(qū)塊鏈上的另一核心技術(shù)是智能合約[13]，是用程序語言編寫的商業(yè)合約。區(qū)塊鏈環(huán)境使得智能合約在沒有中心管理者的情況下，可自動同時運行在全網(wǎng)所有節(jié)點上。與傳統(tǒng)合約相比，智能合約解決了“信用”問題，即：合約締結(jié)前無需信用調(diào)查，締結(jié)后也不用第三方擔保履行，交易成本大幅降低，交易效率則大幅提高，簡化了多方協(xié)作流程，支撐起自動化協(xié)作和價值互聯(lián)應(yīng)用的實現(xiàn)。

2.2 區(qū)塊鏈行業(yè)典型應(yīng)用

當前區(qū)塊鏈技術(shù)的發(fā)展主要以行業(yè)應(yīng)用為驅(qū)動。2019年以來，我國政府高層為區(qū)塊鏈發(fā)展進一步指明了方向，重點發(fā)展服務(wù)于實體經(jīng)濟的產(chǎn)業(yè)區(qū)塊鏈[14]。目前，國內(nèi)企業(yè)重點聚焦于服務(wù)實體經(jīng)濟，改善政府民生相關(guān)的區(qū)塊鏈行業(yè)應(yīng)用，主要包括供應(yīng)鏈金融[15]、產(chǎn)品溯源[16]、司法存證[16]、政務(wù)數(shù)據(jù)共享[16]、資金管理[15]與房地產(chǎn)交易[17-19]。

3 “微改造”方案

3.1 系統(tǒng)業(yè)務(wù)場景分析

托管系統(tǒng)的主要業(yè)務(wù)是管理托管資金。當前，資金主要圍繞托管樓棟（如常州**房地產(chǎn)開發(fā)有限公司**花園項目*區(qū)*幢）進行管理。托管樓棟的核心數(shù)據(jù)包括：當前托管余額、初始受限額度（或初始托管總額）、有效受限額度及當前受限比例。其中，有效受限額度可以理解為針對某樓棟由托管機構(gòu)托管，且暫時不可提取的資金，即有效受限額度=初始受限額度×當前受限比例。不同的工程節(jié)點形象進度對應(yīng)不同的受限比例，一般初始為100%，最終（房屋交付備案時）為0。當前托管余額與有效受限額度的差值就是該托管樓棟可被釋放的資金，即針對該樓棟開發(fā)商可提取的資金。隨著工程的進展，有效受限額度將越來越小，意味著被托管的資金越來越少。

根據(jù)托管模式，托管系統(tǒng)關(guān)鍵業(yè)務(wù)的數(shù)據(jù)變更主要發(fā)生在托管樓棟的有效受限額度發(fā)生變化（如工程取得階段性進展）或者與樓棟相關(guān)的托管資金數(shù)據(jù)發(fā)生變化（如購房人按揭貸款到賬）的時候，這些數(shù)據(jù)變更可能引起托管樓棟可釋放資金的變化，具體場景主要包括：（1）降節(jié)點支付，形象進度節(jié)點和支付比例發(fā)生更新，引起有效受限額度變更；（2）支付保函，企業(yè)經(jīng)營及信譽良好，可開具支付保函，引起有效受限額度變更；（3）貸款發(fā)放，購房人貸款的發(fā)放導(dǎo)致樓棟的當前托管余額發(fā)生變化；（4）退房退款，購房人退房退款的行為引起樓棟當前托管余額發(fā)生變化；（5）特殊支付，特殊支付引起樓棟當前托管余額等發(fā)生變化。

為捕獲關(guān)鍵數(shù)據(jù)的異常變化，需要在這些場景的業(yè)務(wù)流程中引入關(guān)鍵數(shù)據(jù)安全校驗，即針對托管系統(tǒng)的每一個業(yè)務(wù)流程，在相關(guān)人員進行關(guān)鍵業(yè)務(wù)操作前（如資金撥付前），對業(yè)務(wù)中涉及的關(guān)鍵數(shù)據(jù)進行安全校驗，以確保數(shù)據(jù)準確性，只有校驗通過才可進行下一步業(yè)務(wù)操作。業(yè)務(wù)操作完成后，涉及業(yè)務(wù)的變更數(shù)據(jù)將進行上鏈錨定，為后續(xù)安全校驗提供可信的數(shù)據(jù)參照。

3.2 總體技術(shù)架構(gòu)

根據(jù)上述背景，考慮引入?yún)^(qū)塊鏈技術(shù)以解決托管系統(tǒng)的問題。鑒于業(yè)務(wù)系統(tǒng)底層為關(guān)系型數(shù)據(jù)庫，托管業(yè)務(wù)需要支持豐富的SQL查詢，如果對現(xiàn)有托管系統(tǒng)進行全新的基于區(qū)塊鏈的設(shè)計，不可避免要做鏈上數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)的融合，整個業(yè)務(wù)邏輯的實現(xiàn)需要重構(gòu)，會對現(xiàn)有運行的托管系統(tǒng)改動大，因此安全風險也高。另外，在對托管系統(tǒng)業(yè)務(wù)審批操作過程中，審批人員要對一些關(guān)鍵業(yè)務(wù)數(shù)據(jù)進行審核，這些數(shù)據(jù)僅由托管系統(tǒng)計算，因某些計算邏輯比較復(fù)雜，存在無法避錯的問題，為此，審批人員不得不進行人工校驗，以核實關(guān)鍵數(shù)據(jù)計算的準確性。

基于以上兩點，本文提出如下設(shè)計方案：獨立于原托管系統(tǒng)之外，利用區(qū)塊鏈技術(shù)構(gòu)建獨立的數(shù)據(jù)安全應(yīng)用，以提供關(guān)鍵數(shù)據(jù)的校驗服務(wù)；該服務(wù)一方面比對托管系統(tǒng)中的基礎(chǔ)數(shù)據(jù)是否與鏈上參照一致，同時還對托管系統(tǒng)計算得到的數(shù)據(jù)提供獨立的邏輯校驗，只有當托管系統(tǒng)本身的計算邏輯與數(shù)據(jù)安全應(yīng)用的計算邏輯吻合時，數(shù)據(jù)校驗才能通過。方案總體技術(shù)架構(gòu)如圖2所示?？傮w架構(gòu)中，數(shù)據(jù)安全應(yīng)用是方案的核心，設(shè)計獨立的數(shù)據(jù)安全應(yīng)用，可以實現(xiàn)下列目標：

圖2 “微改造”方案總體技術(shù)架構(gòu)

（1）托管系統(tǒng)在可能發(fā)生關(guān)鍵數(shù)據(jù)變更的業(yè)務(wù)操作前調(diào)用數(shù)據(jù)安全應(yīng)用完成數(shù)據(jù)校驗，確保每一次關(guān)鍵業(yè)務(wù)操作的安全；

（2）提供業(yè)務(wù)追溯與糾錯功能；

（3）托管系統(tǒng)開發(fā)人員可在不了解區(qū)塊鏈技術(shù)的情況下，通過調(diào)用數(shù)據(jù)安全應(yīng)用相關(guān)接口來完成鏈上數(shù)據(jù)存取；

（4）數(shù)據(jù)安全應(yīng)用成為訪問區(qū)塊鏈的唯一入口，可統(tǒng)一在數(shù)據(jù)安全應(yīng)用中加入對區(qū)塊鏈的訪問控制，規(guī)避對鏈上數(shù)據(jù)的非法訪問。

這種采用獨立數(shù)據(jù)安全應(yīng)用的方案，僅需對原托管系統(tǒng)進行代價極小的“微改造”。下面將從鏈上數(shù)據(jù)組織、數(shù)據(jù)安全應(yīng)用詳細設(shè)計、區(qū)塊鏈平臺選型等幾個方面對“微改造”方案進行闡述。

3.3 鏈上數(shù)據(jù)組織

區(qū)塊鏈上的核心數(shù)據(jù)結(jié)構(gòu)圍繞托管樓棟信息進行設(shè)計，托管樓棟信息維護的總體流程如圖3所示。樓棟信息具有一定的生命周期，起于托管合作協(xié)議的簽訂（實際，一份協(xié)議可能涉及多個托管樓棟，協(xié)議簽訂后，相關(guān)樓棟的預(yù)售資金正式啟動托管），止于樓棟交付備案（樓棟交付后，針對該樓棟的托管工作結(jié)束）。托管樓棟信息主要由樓棟的狀態(tài)數(shù)據(jù)以及引起狀態(tài)數(shù)據(jù)變更的各種流數(shù)據(jù)（如審批流、結(jié)算流、資金流）組成，詳細的狀態(tài)和流數(shù)據(jù)參見表1。

圖3 托管樓棟信息維護流程

表1 托管樓棟鏈上數(shù)據(jù)組織

托管協(xié)議審批后，相關(guān)托管樓棟狀態(tài)數(shù)據(jù)上鏈。隨著樓棟工程形象節(jié)點的推進和資金出入，鏈上樓棟的狀態(tài)數(shù)據(jù)也發(fā)生相應(yīng)變更。任何一次狀態(tài)數(shù)據(jù)的變更由某個流（如審批流）引起。所有引起狀態(tài)數(shù)據(jù)變更的詳細流信息都及時上鏈，以方便業(yè)務(wù)追溯。

3.4 數(shù)據(jù)安全應(yīng)用的具體設(shè)計

數(shù)據(jù)安全應(yīng)用分成Restful API、獨立應(yīng)用服務(wù)及區(qū)塊鏈SDK三部分，見圖2。Restful API向托管系統(tǒng)提供服務(wù)接口，包括數(shù)據(jù)校驗接口、數(shù)據(jù)上鏈接口以及數(shù)據(jù)感應(yīng)接口；獨立應(yīng)用服務(wù)以Web方式提供自動對賬、校驗查詢及數(shù)據(jù)校正服務(wù)；區(qū)塊鏈SDK提供區(qū)塊鏈底層操作封裝，為Restful API與獨立應(yīng)用服務(wù)提供區(qū)塊鏈操作的接口。

3.4.1 Restful API

（1）數(shù)據(jù)校驗接口。數(shù)據(jù)校驗接口一般由托管系統(tǒng)在關(guān)鍵業(yè)務(wù)審批操作前調(diào)用。只有校驗通過后，托管系統(tǒng)操作員才可進行審批，否則托管系統(tǒng)將提示操作員需要進行校驗異常處理。為了校驗邏輯更清晰，提高校驗的效率和準確性，一般情況下，審批操作前需要完成下列三種校驗：

a.規(guī)范性校驗。主要核實數(shù)據(jù)的完整性，即核實數(shù)據(jù)的必填項是否有缺失，數(shù)據(jù)類型是否正確。

b.比對校驗。比對托管系統(tǒng)中當前的基礎(chǔ)數(shù)據(jù)是否與鏈上參照數(shù)據(jù)一致，以確保托管系統(tǒng)中當前數(shù)據(jù)在上次業(yè)務(wù)操作后沒有被篡改過。

c.邏輯校驗。比較托管系統(tǒng)中的計算數(shù)據(jù)邏輯是否正確。計算數(shù)據(jù)由基礎(chǔ)數(shù)據(jù)計算后得到（如托管樓棟的初始托管總額），是業(yè)務(wù)操作關(guān)注的重點。由于涉及金額較大，僅依賴托管系統(tǒng)的計算難免出錯，因此需要另外獨立的實現(xiàn)，來交叉驗證托管系統(tǒng)計算的正確性。正是由邏輯校驗承擔這種獨立交叉校驗的功能，它可采用智能合約來實現(xiàn)。

（2）數(shù)據(jù)上鏈接口。數(shù)據(jù)上鏈接口由托管系統(tǒng)調(diào)用，上鏈的可能是托管樓棟的狀態(tài)數(shù)據(jù)，也可能是引起狀態(tài)數(shù)據(jù)變化的詳細審批流信息（見表1）。如果審批分為初審、會審及終審等多個階段（這些階段屬于同一個審批流），一般初審時需要對數(shù)據(jù)進行全面的規(guī)范性校驗、比對校驗和邏輯校驗。校驗通過后，上鏈該審批流的初審信息。其它審批操作前，僅需與上鏈的初審信息進行比對，無需再重復(fù)規(guī)范性和邏輯校驗，以防止審批過程中的數(shù)據(jù)篡改。終審后，可以直接借助已校驗過的審批流信息來更新鏈上托管樓棟的狀態(tài)數(shù)據(jù)。為方便業(yè)務(wù)追溯，需要在樓棟狀態(tài)數(shù)據(jù)中寫入引起狀態(tài)數(shù)據(jù)更新的相關(guān)審批流ID。

由于區(qū)塊鏈底層的上鏈過程需經(jīng)過節(jié)點共識，交易確認較耗時?？紤]區(qū)塊鏈SDK操作失敗的可能性（如網(wǎng)絡(luò)中斷）及托管系統(tǒng)的用戶體驗，把數(shù)據(jù)上鏈接口設(shè)計為異步調(diào)用。整個接口分為預(yù)上鏈接口、預(yù)上鏈隊列及上鏈守護程序三個部分：

a.預(yù)上鏈接口，負責接收托管系統(tǒng)提交的上鏈數(shù)據(jù)；接收后，直接插入預(yù)上鏈隊列；然后給托管系統(tǒng)返回預(yù)上鏈成功信號。這樣，托管系統(tǒng)上鏈操作無須等待真正上鏈交易的完成。

b.預(yù)上鏈隊列，負責暫存準備上鏈但還未被寫入?yún)^(qū)塊鏈的交易數(shù)據(jù)。

c.上鏈守護程序，負責不斷移出預(yù)上鏈隊列中的數(shù)據(jù)，并通過區(qū)塊鏈SDK向區(qū)塊鏈服務(wù)提交交易。上鏈失敗的數(shù)據(jù)會被重新插回預(yù)上鏈隊列等待重新上鏈，直至達到某個預(yù)設(shè)的最大預(yù)上鏈次數(shù)為止。

（3）數(shù)據(jù)感應(yīng)接口。區(qū)塊鏈數(shù)據(jù)成功上鏈后，可通過數(shù)據(jù)感應(yīng)接口（可為區(qū)塊鏈上鏈事件注冊服務(wù)回調(diào)處理機制）感知到上鏈的數(shù)據(jù)狀態(tài)，托管系統(tǒng)也可以向數(shù)據(jù)感應(yīng)接口發(fā)送指令，查詢上鏈結(jié)果。

綜上所述，以托管系統(tǒng)的初審為例，數(shù)據(jù)上鏈及感應(yīng)過程中各系統(tǒng)間的數(shù)據(jù)流交互如圖4所示。

圖4 初審時數(shù)據(jù)上鏈及感應(yīng)過程中系統(tǒng)數(shù)據(jù)流交互圖

3.4.2 獨立應(yīng)用服務(wù)

（1）自動對賬。該服務(wù)一方面向托管系統(tǒng)查詢指定的托管樓棟涉及的狀態(tài)數(shù)據(jù)和審批流數(shù)據(jù)，另一方面向區(qū)塊鏈查詢指定的托管樓棟涉及的狀態(tài)數(shù)據(jù)和審批流數(shù)據(jù)，并提供兩邊數(shù)據(jù)的自動核對。

（2）數(shù)據(jù)校正服務(wù)。為了適應(yīng)新的托管政策，可能需要對托管系統(tǒng)中的數(shù)據(jù)進行修正。這種合理的數(shù)據(jù)變更會引起托管系統(tǒng)與鏈上數(shù)據(jù)的不一致，導(dǎo)致托管業(yè)務(wù)無法繼續(xù)進行。此時，可利用數(shù)據(jù)校正服務(wù)對托管樓棟的鏈上狀態(tài)數(shù)據(jù)進行校正，以解決托管系統(tǒng)與鏈上狀態(tài)數(shù)據(jù)的不一致問題?？紤]到業(yè)務(wù)的可追溯性，數(shù)據(jù)校正服務(wù)也采用審批機制，即需要走“校正申請、校正審批”的流程，該審批流同樣需要上鏈。

（3）日志查詢服務(wù)。各接口中涉及的校驗過程、上鏈過程均須寫入數(shù)據(jù)安全應(yīng)用的本地數(shù)據(jù)庫，以便當托管系統(tǒng)中的數(shù)據(jù)與鏈上數(shù)據(jù)不一致時，可利用日志查詢服務(wù)豐富的SQL查詢功能，輔助分析數(shù)據(jù)不一致的原因。

3.4.3 區(qū)塊鏈SDK

Restful API與獨立應(yīng)用服務(wù)通過區(qū)塊鏈SDK來操作區(qū)塊鏈，這樣做的好處是：（1）托管系統(tǒng)開發(fā)者在不了解區(qū)塊鏈技術(shù)的情況下也可進行鏈上數(shù)據(jù)的存取，減少了托管系統(tǒng)改造的代價；（2）訪問區(qū)塊鏈的身份密鑰僅內(nèi)置在數(shù)據(jù)安全應(yīng)用中，數(shù)據(jù)安全應(yīng)用封裝了區(qū)塊鏈的所有底層操作，方便對區(qū)塊鏈存取實施統(tǒng)一控制，托管系統(tǒng)不可直接操作區(qū)塊鏈，避免了托管系統(tǒng)控制校驗與上鏈的過程。

3.5 區(qū)塊鏈平臺選型

“微改造”初期，區(qū)塊鏈底層平臺主要定位為私有鏈?？紤]到托管系統(tǒng)后期要與房地產(chǎn)交易其它部門的平臺進行對接，因此采用聯(lián)盟鏈來實現(xiàn)“微改造”。主要調(diào)研了下列幾種方案：（1）開源Fabric技術(shù)。Fabric源于IBM開源可插拔聯(lián)盟鏈技術(shù)[20]，目前已成為事實上的聯(lián)盟鏈標準。（2）基于Fabric技術(shù)的區(qū)塊鏈云服務(wù)。各個互聯(lián)網(wǎng)頭部公司（華為、騰訊、阿里）都提供了基于增強版Fabric技術(shù)的區(qū)塊鏈云服務(wù)。（3）頭部公司自研區(qū)塊鏈云服務(wù)：如阿里系的螞蟻鏈①、騰訊系的TrustSQL②、華為的自研鏈③等。（4）區(qū)塊鏈專業(yè)公司自研云平臺。如榮澤區(qū)塊鏈④、復(fù)雜美區(qū)塊鏈⑤、趣鏈⑥等。

方案（1）完全開源，無需底層平臺費用，但支撐的交易吞吐量較低[21]。其它方案需要較為昂貴的底層平臺費用，但能夠支撐更高的交易吞吐量，也更易于使用擴展。相比方案（2）與（3），方案（4）雖然前期費用高，但如果長期使用，總的費用則更便宜，且用戶可以更好地控制自己的數(shù)據(jù)。由于方案（1）支撐的交易吞吐量在項目初期能夠滿足現(xiàn)有業(yè)務(wù)吞吐量需求，綜合評估后，初期就采用方案（1），后期擬根據(jù)業(yè)務(wù)擴展需要采用方案（4）構(gòu)建底層區(qū)塊鏈平臺。

4 “微改造”案例

為了測試改造效果，開發(fā)了“微改造”原型系統(tǒng)，下面以圖3中的“托管協(xié)議審批”業(yè)務(wù)為例進行闡述。該業(yè)務(wù)審批過程如圖5所示，其中，左側(cè)為改造前的審批流程，右側(cè)為改造后注入的校驗和上鏈環(huán)節(jié)。從圖5可以看出，安全校驗并不更改原業(yè)務(wù)流程，而是采用增量式改造，代價較小。

圖5 托管協(xié)議審批過程中的校驗與上鏈

4.1 基礎(chǔ)設(shè)置

托管系統(tǒng)采用SpringBoot+Vue.js實現(xiàn)；數(shù)據(jù)安全應(yīng)用基于SpringBoot構(gòu)建Restful API；底層區(qū)塊鏈平臺采用Fabric 2.2，基于docker配置。區(qū)塊鏈網(wǎng)絡(luò)[22]如圖6所示：包含2個peer節(jié)點（各帶1個couchdb節(jié)點作為peer節(jié)點的狀態(tài)數(shù)據(jù)庫）、1個order節(jié)點及1個cli節(jié)點（用來執(zhí)行Fabric命令）。

圖6 正泰區(qū)塊鏈網(wǎng)絡(luò)配置

為了測試改造效果，在改造后的托管系統(tǒng)中設(shè)置了8個測試用戶；其中，1個為管理員，另外7個分別對應(yīng)圖5中的相關(guān)角色，如表2所示。

表2 測試用戶列表

4.2 安全校驗測試

嚴格按照圖5設(shè)計的流程進行安全校驗測試。最初，開發(fā)企業(yè)申請托管。此時，托管系統(tǒng)生成托管合作協(xié)議的審批流ID（用“AgreementList：協(xié)議ID”表示）；然后，由托管機構(gòu)相關(guān)人員對托管協(xié)議進行逐層審批，以業(yè)務(wù)部門員工ztywyg2審批為例（初審）。審批時，托管系統(tǒng)調(diào)用數(shù)據(jù)安全應(yīng)用的校驗接口進行規(guī)范性校驗和邏輯校驗（與其它審批初審不同的是，托管協(xié)議初審時樓棟的狀態(tài)數(shù)據(jù)還未上鏈，無需進行比對校驗）。由于規(guī)范性校驗較簡單，此處僅測試邏輯校驗效果。為此，特意在托管系統(tǒng)初始托管總額計算邏輯的實現(xiàn)中引入Bug，即初始托管總額=樓棟單價×樓棟面積×托管比例+10，見圖7（a），而原本正確的初始托管總額=樓棟單價×樓棟面積×托管比例。托管協(xié)議初審時，邏輯校驗比較托管系統(tǒng)和鏈上智能合約的計算結(jié)果，見圖7（b）。由于初始托管總額在智能合約的計算中使用了正確邏輯，而在托管系統(tǒng)中使用了錯誤邏輯，校驗發(fā)現(xiàn)兩者計算結(jié)果不一致，顯示校驗錯誤，見圖7（c），這個測試結(jié)果符合預(yù)期。

圖7 邏輯校驗測試

交叉校驗的思路來源于文獻[23]。針對托管系統(tǒng)中的計算數(shù)據(jù)，由獨立的開發(fā)者使用與托管系統(tǒng)不同的開發(fā)語言來實現(xiàn)該數(shù)據(jù)的計算和校驗。不同開發(fā)人員使用不同語言實現(xiàn)的計算邏輯中，出現(xiàn)相同錯誤的概率非常小，加上交叉校驗采用智能合約的方式實現(xiàn)，部署后難以篡改，從而保證能夠及時安全地發(fā)現(xiàn)托管系統(tǒng)中計算邏輯的錯誤，也可以對托管系統(tǒng)中計算邏輯的惡意篡改起到預(yù)防作用。

測試后，恢復(fù)了托管系統(tǒng)中“初始托管總額”正常的計算邏輯。此時，安全校驗成功，“審核通過”按鈕被激活。審核通過后，初審信息上鏈，區(qū)塊鏈中寫入初審流數(shù)據(jù)（Key，Value）對。其中，Key為審批流ID，即“AgreementList：34”，后續(xù)可籍此Key值來追溯協(xié)議的整個審批流程；Value為托管協(xié)議的初審信息，見圖8。初審?fù)ㄟ^后，使用業(yè)務(wù)部門經(jīng)理ztywyg1賬戶繼續(xù)進行審批。此時，托管系統(tǒng)調(diào)用數(shù)據(jù)安全校驗接口進行比對校驗。為了測試比對效果，故意篡改了托管系統(tǒng)中的樓棟面積，從10 000 m2改為8 000 m2。在業(yè)務(wù)部門經(jīng)理審批時的比對校驗過程中，立即發(fā)現(xiàn)了托管系統(tǒng)當前的數(shù)據(jù)與該審批流鏈上最新數(shù)據(jù)（Value值）不一致，因此審批無法進行，見圖9?？梢?，針對托管系統(tǒng)基礎(chǔ)數(shù)據(jù)的任何篡改都能夠在審批過程中被及時發(fā)現(xiàn)。

圖8 初審后通過區(qū)塊鏈瀏覽器[24]查看的上鏈數(shù)據(jù)

圖9 比對校驗異常

恢復(fù)篡改的樓棟面積為正常值后，審批可繼續(xù)進行。根據(jù)圖5，當托管協(xié)議完成了所有審批后，托管樓棟狀態(tài)數(shù)據(jù)（Key，Value）初次形成并上鏈。為區(qū)別于托管協(xié)議審批流數(shù)據(jù)，此處托管樓棟狀態(tài)數(shù)據(jù)的Key值設(shè)為“HostBuilding：34”，為可全局唯一標識該樓棟，代表該樓棟狀態(tài)數(shù)據(jù)產(chǎn)生自ID=34的托管協(xié)議；Value字段內(nèi)容見前文表1，其中引起狀態(tài)變化的流ID字段為“AgreementList：34”，代表ID=“AgreementList：34”的托管協(xié)議審批流引起了該狀態(tài)數(shù)據(jù)的更新。以上信息是托管樓棟狀態(tài)數(shù)據(jù)在鏈上的初次錨定，可為后續(xù)該托管樓棟其它審批流（如資金入賬）的初審提供比對校驗的數(shù)據(jù)參照。

4.3 業(yè)務(wù)追溯

托管系統(tǒng)業(yè)務(wù)追溯的核心是跟蹤樓棟狀態(tài)數(shù)據(jù)（見表1）的變化，這種追溯本質(zhì)上可以視為一個二維過程。首先，樓棟狀態(tài)數(shù)據(jù)的變化由各種審批流引起，其狀態(tài)值Value的所有變化歷史可從鏈上獲取，只需通過“getHistoryFor-Key（key）⑦”接口調(diào)用，即可得到協(xié)議ID為34的樓棟狀態(tài)值鏈上的變化歷史，從而得到引起變化的所有審批流ID。其中，“AgreementList：34”為引起狀態(tài)數(shù)據(jù)變化的第一個審批流ID。其次，審批流的詳細審批過程也可以根據(jù)接口調(diào)用“getHistoryForKey（key）”得到。圖10展示了通過該接口調(diào)用得到的鏈上托管協(xié)議審批流（審批流ID=“AgreementList：34”）的詳細審批信息。因此，托管樓棟的狀態(tài)變化可實現(xiàn)全程追溯。因為校驗與上鏈交替進行、環(huán)環(huán)相扣，一旦校驗異常，審批就無法繼續(xù)，所以，審批流程中的所有校驗異常都能及時被發(fā)現(xiàn)和上鏈錨定，業(yè)務(wù)辦理中出現(xiàn)過的異常就很容易溯源。

圖10 托管協(xié)議審批流鏈上歷史追溯

通過以上校驗用例，可以進一步體會本文基于區(qū)塊鏈技術(shù)系統(tǒng)設(shè)計的兩個核心理念：（1）業(yè)務(wù)系統(tǒng)的流程中僅增加了校驗與上鏈接口調(diào)用，實際的校驗和上鏈操作與業(yè)務(wù)系統(tǒng)隔離，被統(tǒng)一封裝在獨立的數(shù)據(jù)安全應(yīng)用里；如此，不僅減小了業(yè)務(wù)系統(tǒng)改造的代價，也增強了區(qū)塊鏈操作的安全性。（2）業(yè)務(wù)流程中的所有關(guān)鍵操作都要進行數(shù)據(jù)校驗，校驗的參照數(shù)據(jù)來自上一流程，或者本流程上一個環(huán)節(jié)在區(qū)塊鏈上錨定的數(shù)據(jù)；校驗和上鏈交替進行、環(huán)環(huán)相扣，能夠及時檢測出系統(tǒng)中的數(shù)據(jù)異常。

5 結(jié)語

本文詳細分析了正泰公司現(xiàn)有的托管業(yè)務(wù)流程及托管系統(tǒng)存在的問題，針對房地產(chǎn)預(yù)售資金托管過程中存在的數(shù)據(jù)安全隱患，基于區(qū)塊鏈技術(shù)設(shè)計了保障托管系統(tǒng)關(guān)鍵業(yè)務(wù)數(shù)據(jù)安全的技術(shù)方案。在不改變原有托管業(yè)務(wù)系統(tǒng)核心流程與數(shù)據(jù)庫設(shè)計的基礎(chǔ)上，用最小的代價達成了下列目標：

（1）異常數(shù)據(jù)檢測。托管系統(tǒng)改造后，所有樓棟的狀態(tài)數(shù)據(jù)除了存儲在原系統(tǒng)中，在區(qū)塊鏈上也進行了存儲；關(guān)鍵業(yè)務(wù)數(shù)據(jù)都要經(jīng)過規(guī)范性校驗、比對校驗和邏輯校驗方可進行變更。其中，規(guī)范性校驗杜絕了關(guān)鍵數(shù)據(jù)項的缺失；比對校驗核實業(yè)務(wù)系統(tǒng)中的基礎(chǔ)數(shù)據(jù)是否正確，在審批通過后，托管系統(tǒng)中的數(shù)據(jù)一旦被篡改，系統(tǒng)具有及時發(fā)現(xiàn)并糾正的機制；邏輯校驗實現(xiàn)了計算數(shù)據(jù)的交叉驗證，防止原業(yè)務(wù)系統(tǒng)單方面計算可能出現(xiàn)的錯誤。鏈上數(shù)據(jù)提供的參照，以及上鏈與校驗交替進行的過程，使得數(shù)據(jù)異常檢測變得容易，有效規(guī)避了提交錯誤數(shù)據(jù)的可能，確保了關(guān)鍵業(yè)務(wù)的數(shù)據(jù)安全。

（2）異常業(yè)務(wù)追溯。因為上鏈與校驗環(huán)環(huán)相扣，異常數(shù)據(jù)及當時的狀態(tài)信息能夠被及時偵測和上鏈。經(jīng)過“微改造”，業(yè)務(wù)辦理做到了事事留痕，托管樓棟狀態(tài)變化的全流程可按時間順序進行追溯，任何一個辦理環(huán)節(jié)曾出現(xiàn)過的問題及相關(guān)信息，都能夠方便地進行溯源。

（3）審計實時性高，審計數(shù)據(jù)可信。經(jīng)過“微改造”，審計機構(gòu)只要接入?yún)^(qū)塊鏈網(wǎng)絡(luò)，任何一筆業(yè)務(wù)辦理數(shù)據(jù)都可以實時地被推送到審計機構(gòu)（審計機構(gòu)中具備權(quán)限的人員可隨時訪問）；由于區(qū)塊鏈的特性，審計機構(gòu)人員無須進入審計企業(yè)就可獲得實時可信的審計數(shù)據(jù)。

（4）對賬便捷自動化。對賬便捷自動化主要體現(xiàn)在兩方面：首先，在原先的業(yè)務(wù)審批操作中，操作員在審批前必須對許多關(guān)鍵數(shù)據(jù)進行手工計算，以核實數(shù)據(jù)的準確性，改造后，這種繁瑣且易出錯的手工核實操作，由數(shù)據(jù)安全應(yīng)用的比對校驗和邏輯校驗自動完成。其次，數(shù)據(jù)安全應(yīng)用提供自動對賬服務(wù)，該服務(wù)同時從托管系統(tǒng)和區(qū)塊鏈獲取指定樓棟的狀態(tài)數(shù)據(jù)和審批流數(shù)據(jù)，對兩邊數(shù)據(jù)進行自動核對，避免了為確保系統(tǒng)數(shù)據(jù)正確性與一致性而進行的日常人工對賬。

總之，本文設(shè)計的基于區(qū)塊鏈技術(shù)的“微改造”方案，以較小的代價、較高的安全性，完美地解決了現(xiàn)有托管系統(tǒng)遭遇的痛點，對類似的基于中心數(shù)據(jù)庫的信息管理系統(tǒng)改造，也有較強的參考意義。

注釋：

①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中 的 函 數(shù)，chaincode即Fabric智 能合約。