爲什麼要上區塊鏈系統
在落地工作啓動之前，還是要費點口舌來談談這個話題。
不管對我們還是銀行來說，正常邏輯是，要考慮清楚哪些產品適合使用區塊鏈架構實現，哪些不適合。（當然，也有情況除外）這裏參考了段新星在鈦坦白的分享實錄（ http://www.tmtpost.com/2694378.html?from=timeline&isappinstalled=0 ），文章提出了應用三原則，我覺得點的非常到位，這裏我補充一些銀行緊密相關的說明。
定律一，“不要拿大炮打蚊子”，區塊鏈技術更適宜於資產網絡（Assets Over IP），針對這點，銀行本身從事的就是資產相關業務，比較匹配。
定律二，使用區塊鏈，一定是要有多方寫入數據的需求
如果把區塊鏈作爲一種數據庫而言，這裏邊非常突出的特色就是：它是一個天生去適應多方進行協作的數據庫，一個單一的寫入者寫入數據的數據庫可以搞定的，就不需要用區塊鏈。所以，在這裏一定有多方協作需求。
定律三，區塊鏈產品一定是天然的弱中心化的
區塊鏈做在國內支付基本沒有可能，因爲中心化平臺已經足夠強勢和足夠好的體驗，比如支付寶、微信、銀聯。但用區塊鏈做打通多個不同國家商家、金融機構的跨境匯款、清算結算的成功案例則不少。原因也是很簡單，後者在複雜多邊市場中，缺乏“中心協調者”，存在嚴重對手風險的交易困境。比如，信用證就是一個很好的應用場景，今年 7 月份，中信銀行已與民生銀行合作推出首個銀行業國內信用證區塊鏈應用，併爲銀行拓展國際結算、貿易融資等業務提供支撐。
另外，需要補充的是，在現階段銀行體系使用區塊鏈來解決運營效率、降低運營成本也是一個非常明顯的應用點，比如：招商銀行通過區塊鏈技術改造的跨境直聯清算業務將正式實現商用，實現了總行與海外分行各節點的資金清算，並將報文傳遞時間由 6 分鐘縮減至秒級。
典型融合架構
以下爲典型的銀行現有 IT 和區塊鏈的融合架構。部署在銀行的區塊鏈節點會在應用層、業務層、數據層和銀行現有 IT 發生交互。
應用層：銀行 IT 應用層，比較典型的，比如國際結算系統、外匯交易系統、支付系統等等，將會和區塊鏈的連接層發生交互，通過 Restful API 發起區塊鏈交易或者通過 WebSocket 機制接受區塊鏈區塊和交易結果。
業務層：通常風險控制策略、支付清算規則、AML 規則在這一層制定，區塊鏈通過智能合約（或稱：鏈上代碼 chaincode）寫入和交易關聯方相關的業務規則，比如風控規則、清算分潤等都可以通過智能合約寫入。
數據層：區塊鏈一般採用 K/V 數據庫，適合區塊鏈實現不間斷鏈式存儲和簡單信息的存儲，並不支持 SQL 語句複雜查詢，當然也無法支撐進一步數據分析、挖掘。比如，在我們在一商業銀行落地數字資產項目，基於 UTXO 的賬戶模型需要被抽取、加工，進入到行內的 AML 規則庫進行資金流向監管，實現資金的精準投放。同時，銀行數據層通常有更完善的容災備份策略。所以，架構方案配套爲關係性數據庫（Oracle/DB2/Mysql/…）提供數據導入功能，一方面作爲數據安全存儲需要，一方面爲數據再加工提供數據源頭。
對賬模式的變化
以哪裏的賬目爲準，對賬週期怎麼設定，在銀行 IT 中一直是一個很原則性問題，系統融合區塊鏈之後，這兩點需要重新理解，並使用新的規則來實現。我們在一些落地項目中，需要花費很多精力來讓銀行 IT 人員理解在區塊鏈模式下實現新的對賬模式。
我們以基於銀聯的跨行支付系統爲例，來看一下傳統對賬模式。
清分一般發生在 T 日日終（比如 23:00），銀聯完成清分後，向各個成員機構下發清分文件，各個成員銀行根據中心的清分文件來對賬，注意哦，一定要以銀聯爲準。
PS：淸分 Clearing 是指對交易日誌中記錄的成功交易，逐筆計算交易本金及交易費用（手續費、分潤等），然後按清算對象彙總軋差形成應收或應付金額。簡言之，就是搞清楚今天應該向誰要多少錢？應該給誰多少錢？
相比現有中心機構模式，基於區塊鏈模式下，每隔一段時間（一般幾秒到十幾秒之間）會生成區塊（Block）的生成，這個區塊中的交易明細已經在各個參與方節點的共識過程中形成一致性賬本，意味着對賬時時刻刻都在進行。所以，新的對賬模式應調整爲：
- 日終對賬變爲實時對賬
- 以中心機構（如：銀聯）爲準或者行內核心繫統爲準轉變爲以區塊鏈賬務爲準。
由此可以看出，顯而易見的好處是：效率提高了，配合以良好的交易機制（在下一章節提到），可以將差錯賬發生率較低到幾乎爲零。
解決事務一致性
我們在某銀行的一個數字資產項目中，探討一個場景“數字資產提現”，這個場景要求先從區塊鏈做完成數字資產提現交易，同時在銀行本地賬務系統進行賬戶相關賬務操作，這兩個動作要求實現事務一致性。
在銀行現有系統架構中，事務一致性保證有一些傳統做法，最簡單的是通過本地關係數據庫的強一致性來實現本地事務的一致性；或者是通過設計一些衝正交易模式來進行交易回滾；再者通過兩階段提交協議（2PC）來實現。
針對區塊鏈交易以上均無法支持，原因很明顯，一、區塊鏈節點是獨立應用，無法通過本地事務實現；二、區塊鏈使用的數據庫是 NoSQL 數據庫，這些非關係型數據庫無法支持 2PC；三、區塊鏈沒有交易回滾（Rollback）機制，只要區塊上的交易，無法通過沖正交易回滾。
解決思路是 從微服務架構中尋找事務一致性的解決方案。其實區塊鏈應用節點就是一個獨立微服務。
微服務的實現事務一致性的模式有三種，可靠事件模式、業務補償模式、TCC 模式。其中最適合的是可靠實現模式，某種情況下可以使用業務補償模式。原因是：TCC 模式，要求支持 Cancel 操作，區塊鏈均不適合。綜上，我們建議使用基於外部事件系統的可靠事件模式來保證交易一致性。
具體方案設計如下：
外部事件系統記錄事件消息全流程狀態，從上圖可以看出，從 1-5 是正常交易流程，其中可能發生異常情況：
- 區塊鏈交易失敗
- 區塊鏈交易成功，但沒有通知到事件系統
- 賬戶系統交易失敗（可能沒有收到，也可能處理失敗）
- 賬戶系統交易成功，沒有通知到事件系統
對賬處理進程定時從事件系統庫中找出 A）已經登記的，但沒有收到交易出塊通知的交易 B）賬戶系統未置“完成”的交易。
針對 A，對賬處理進程從區塊鏈中進行查詢（包括對比區塊，是不是已經過了超過 2 個以上區塊），如果區塊鏈沒有完成交易，則將事件置“取消”，解決第一種異常；如果區塊鏈交易成功，則更新事件狀態爲“待賬務系統處理”，並送入消息隊列，解決第二種異常；
針對 B，再次通知賬戶系統，觸發賬戶系統再次處理（本操作可以根據情況，設置多次），解決第三種和第四種異常。
PS：賬戶系統需要實現冪等性，不能因爲重複收到事件而多次重複記賬！
補充說明，賬戶系統對於記賬失敗可以反交易處理，在其他場景，我們也可以設計事務補償的模式。平臺使用服務編排的方式降低這種模式的開發複雜度。
身份實名化及密鑰管理
在公有區塊鏈最初當中，均不需要進行身份實名，密鑰管理也是交給個人自行管理。對於金融行業應用區塊鏈，顯然既不符合監管，也沒法滿足銀行商用標準，所以，針對銀行聯盟鏈來說，最重要需要實現兩個目標：
- 鏈上身份實名化
- 資產控制密鑰的可管理，包括掛失、找回這樣的異常管理
對此，我們建議的方案如下：
- 對於身份實名，基於銀行已有成熟驗證通道，我們建議藉助銀行現有的二、三類賬戶驗證模式和 KYC，比如銀行卡四要素的認證方式。
- 鑑於用戶對銀行的信任度很高，密鑰管理方案建議採用“可選託管方案”，用戶可以選擇自行生成和管理密鑰，或者在用戶許可下，由銀行爲用戶託管密鑰，並通過安全方式下發給用戶終端，這樣用戶可以通過自己實名身份進行掛失、找回等。具體如下說明。
高可用的部署架構
銀行 IT 對高可用一直有極高的要求，區塊鏈的構建需要完全支持高可用（HA）的部署架構。
我們建議使用微服務架構建立區塊鏈服務集羣，區塊鏈節點僅是一個邏輯概念，它由多個可自由伸縮的物理節點構成。
目前業界比較成熟的微服務框架有 Netflix Spring Cloud、Apache ZooKeeper 等。方案並不侷限某一框架，我們以使用 Spring Cloud 提供的 服務註冊（Eureka）、服務發現（Ribbon）框架爲例，具體的部署方案如下。
PS：每個銀行在各自 HA 方案中有各自標準，基於微服務的架構方案僅爲一種選擇，具體情況可以根據銀行 HA 總體方案調整。
以上我們將所有區塊鏈節點以服務註冊到 Eureka 集羣，讓服務調用方（銀行各類應用）能夠方便地找到區塊鏈節點，保證全程無單點。
其中區塊鏈集羣中可以設置性能比較好的物理機器作爲記賬節點，其他作爲提供服務響應作用或數據備份作用的輕節點。