基于區(qū)塊鏈技術(shù)的房地產(chǎn)預(yù)售資金托管系統(tǒng)探究
——以正泰公司托管系統(tǒng)改造為例

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

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

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

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

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

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

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

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

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

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

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

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

1.3 審計(jì)真實(shí)性低、實(shí)時(shí)性弱

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

1.4 對(duì)賬繁瑣易出錯(cuò)

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

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

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

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

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

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

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

當(dāng)前區(qū)塊鏈技術(shù)的發(fā)展主要以行業(yè)應(yīng)用為驅(qū)動(dòng)。2019年以來，我國政府高層為區(qū)塊鏈發(fā)展進(jìn)一步指明了方向，重點(diǎn)發(fā)展服務(wù)于實(shí)體經(jīng)濟(jì)的產(chǎn)業(yè)區(qū)塊鏈[14]。目前，國內(nèi)企業(yè)重點(diǎn)聚焦于服務(wù)實(shí)體經(jīng)濟(jì)，改善政府民生相關(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ù)是管理托管資金。當(dāng)前，資金主要圍繞托管樓棟（如常州**房地產(chǎn)開發(fā)有限公司**花園項(xiàng)目*區(qū)*幢）進(jìn)行管理。托管樓棟的核心數(shù)據(jù)包括：當(dāng)前托管余額、初始受限額度（或初始托管總額）、有效受限額度及當(dāng)前受限比例。其中，有效受限額度可以理解為針對(duì)某樓棟由托管機(jī)構(gòu)托管，且暫時(shí)不可提取的資金，即有效受限額度=初始受限額度×當(dāng)前受限比例。不同的工程節(jié)點(diǎn)形象進(jìn)度對(duì)應(yīng)不同的受限比例，一般初始為100%，最終（房屋交付備案時(shí)）為0。當(dāng)前托管余額與有效受限額度的差值就是該托管樓棟可被釋放的資金，即針對(duì)該樓棟開發(fā)商可提取的資金。隨著工程的進(jìn)展，有效受限額度將越來越小，意味著被托管的資金越來越少。

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

為捕獲關(guān)鍵數(shù)據(jù)的異常變化，需要在這些場景的業(yè)務(wù)流程中引入關(guān)鍵數(shù)據(jù)安全校驗(yàn)，即針對(duì)托管系統(tǒng)的每一個(gè)業(yè)務(wù)流程，在相關(guān)人員進(jìn)行關(guān)鍵業(yè)務(wù)操作前（如資金撥付前），對(duì)業(yè)務(wù)中涉及的關(guān)鍵數(shù)據(jù)進(jìn)行安全校驗(yàn)，以確保數(shù)據(jù)準(zhǔn)確性，只有校驗(yàn)通過才可進(jìn)行下一步業(yè)務(wù)操作。業(yè)務(wù)操作完成后，涉及業(yè)務(wù)的變更數(shù)據(jù)將進(jìn)行上鏈錨定，為后續(xù)安全校驗(yàn)提供可信的數(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查詢，如果對(duì)現(xiàn)有托管系統(tǒng)進(jìn)行全新的基于區(qū)塊鏈的設(shè)計(jì)，不可避免要做鏈上數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)的融合，整個(gè)業(yè)務(wù)邏輯的實(shí)現(xiàn)需要重構(gòu)，會(huì)對(duì)現(xiàn)有運(yùn)行的托管系統(tǒng)改動(dòng)大，因此安全風(fēng)險(xiǎn)也高。另外，在對(duì)托管系統(tǒng)業(yè)務(wù)審批操作過程中，審批人員要對(duì)一些關(guān)鍵業(yè)務(wù)數(shù)據(jù)進(jìn)行審核，這些數(shù)據(jù)僅由托管系統(tǒng)計(jì)算，因某些計(jì)算邏輯比較復(fù)雜，存在無法避錯(cuò)的問題，為此，審批人員不得不進(jìn)行人工校驗(yàn)，以核實(shí)關(guān)鍵數(shù)據(jù)計(jì)算的準(zhǔn)確性。

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

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

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

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

（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)用中加入對(duì)區(qū)塊鏈的訪問控制，規(guī)避對(duì)鏈上數(shù)據(jù)的非法訪問。

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

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

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

圖3 托管樓棟信息維護(hù)流程

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

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

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

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

3.4.1 Restful API

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

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

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

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

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

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

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

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

c.上鏈?zhǔn)刈o(hù)程序，負(fù)責(zé)不斷移出預(yù)上鏈隊(duì)列中的數(shù)據(jù)，并通過區(qū)塊鏈SDK向區(qū)塊鏈服務(wù)提交交易。上鏈?zhǔn)〉臄?shù)據(jù)會(huì)被重新插回預(yù)上鏈隊(duì)列等待重新上鏈，直至達(dá)到某個(gè)預(yù)設(shè)的最大預(yù)上鏈次數(shù)為止。

（3）數(shù)據(jù)感應(yīng)接口。區(qū)塊鏈數(shù)據(jù)成功上鏈后，可通過數(shù)據(jù)感應(yīng)接口（可為區(qū)塊鏈上鏈?zhǔn)录?cè)服務(wù)回調(diào)處理機(jī)制）感知到上鏈的數(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í)數(shù)據(jù)上鏈及感應(yīng)過程中系統(tǒng)數(shù)據(jù)流交互圖

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

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

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

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

3.4.3 區(qū)塊鏈SDK

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

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

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

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

4 “微改造”案例

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

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

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

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

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

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

表2 測(cè)試用戶列表

4.2 安全校驗(yàn)測(cè)試

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

圖7 邏輯校驗(yàn)測(cè)試

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

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

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

圖9 比對(duì)校驗(yàn)異常

恢復(fù)篡改的樓棟面積為正常值后，審批可繼續(xù)進(jìn)行。根據(jù)圖5，當(dāng)托管協(xié)議完成了所有審批后，托管樓棟狀態(tài)數(shù)據(jù)（Key，Value）初次形成并上鏈。為區(qū)別于托管協(xié)議審批流數(shù)據(jù)，此處托管樓棟狀態(tài)數(shù)據(jù)的Key值設(shè)為“HostBuilding：34”，為可全局唯一標(biāo)識(shí)該樓棟，代表該樓棟狀態(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ù)該托管樓棟其它審批流（如資金入賬）的初審提供比對(duì)校驗(yàn)的數(shù)據(jù)參照。

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

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

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

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

5 結(jié)語

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

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

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

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

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

總之，本文設(shè)計(jì)的基于區(qū)塊鏈技術(shù)的“微改造”方案，以較小的代價(jià)、較高的安全性，完美地解決了現(xiàn)有托管系統(tǒng)遭遇的痛點(diǎn)，對(duì)類似的基于中心數(shù)據(jù)庫的信息管理系統(tǒng)改造，也有較強(qiá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智 能合約。