本文作者：李世敬、吳琛、胡麥芳
近日，央行釋出《金融分散式賬本技術安全規範》，在業內被視為區塊鏈在金融行業內應用的重要標準。該標準規定了金融分散式賬本技術的安全體系架構，在基礎硬體、基礎軟體、密碼演算法、節點通訊、賬本資料、共識協議、智慧合約、身份管理、隱私保護、監管支撐、運維要求、治理機制等多方面的規範，對區塊鏈技術在金融行業的應用提出了更高的要求。
趣鏈科技始終堅持自主、可控的區塊鏈技術研發，並於2016年推出了全自研趣鏈區塊鏈平臺，經過持續的迭代升級，在效能最佳化、功能升級、隱私保護、監管支援等方面不斷完善和加強，取得了豐富的效果。平臺在工信部、銀聯、票交所等多家權威機構評測中均名列第一，也是目前行業內落地金融相關場景最多的區塊鏈平臺。
隨著《安全規範》的釋出，我們以自研區塊鏈平臺產品作為參照，在第一時間進行了深度分析，趣鏈區塊鏈平臺在重點領域均滿足相關規範與要求，企業客戶使用趣鏈區塊鏈平臺開展金融類業務，無需做大幅度的改造。
與此同時，以Hyperledger Fabric為代表的其他區塊鏈平臺，其在硬體加密、節點容錯、身份管理、隱私保護、監管審計等層面尚未完全符合規範要求，在實際落地金融業務過程中存在底層平臺重新改造的風險。
本文就趣鏈區塊鏈平臺和Hyperledger Fabric v2.0（下稱Fabric）在《安全規範》中的符合情況與程度進行分析和對比，並提出需要重點關注的條例和要求。
符合國密的硬體級別高安全防護
在基礎硬體層面，標準強調：“加密機裝置應符合國家密碼管理部門頒佈的GM/T 0045-2016的要求。使用的個人硬體密碼裝置，應符合行業主管部門和國家密碼管理部門相關要求。”
針對使用者金鑰和鏈上資訊的安全性需求，趣鏈區塊鏈平臺構建軟硬體相結合的安全基礎設施，適配符合國密GM/T 0045-2016以及商用密碼檢測中心標準的硬體密碼卡（PCIE密碼卡，型號SJK1862-G）和智慧密碼鑰匙（型號SJK1905）等加密機裝置，同時支援金鑰備份和匯出等一系列服務，有效保證了金鑰不可篡改，為使用者敏感資訊保駕護航。
Fabric原生架構中沒有進行安全硬體適配，暫不符合商用密碼中心標準，如需符合標準則需要相關金融機構自行投入人力、硬體成本以滿足要求。
看得見的審計記錄
在賬本資料層面，標準要求：“賬本資料應具有一致性和保密性，對其訪問和使用應具有安全審計功能，審計記錄包括訪問日期、時間、使用者標識、資料內容等審計相關資訊，資料變更（包括失敗的變更）、節點一致性校驗失敗也應提供審計記錄。”
趣鏈區塊鏈平臺透過賬本容錯機制和賬本加密功能保證了賬本資料的一致性和保密性。而標準中賬本資料可審計的規定給分散式賬本系統提出了更高的要求。平臺提供日誌結構化、合約資料視覺化功能，結合趣鏈飛洛BaaS平臺，提供賬戶資訊視覺化、日誌資料視覺化、賬本資料視覺化等服務，可以很好地滿足賬本審計相關需求。
Fabric提供了類似SQL查詢賬本的功能，可進行有效審計，網路參與者見證的交易都可以被授權的監管機構和審計人員檢測和跟蹤。然而針對標準中關於審計記錄的可驗可查，Fabric並不能滿足，基於Fabric的區塊鏈金融專案，需要投入一定的二次開發成本才能滿足相關賬本審計的需求。
健壯的共識演算法
在共識協議層面，標準強調：“協議應具備抗DDoS攻擊、處理惡意報文、識別惡意節點的能力,且應採取不轉發、拒絕連線、黑名單等措施縮小影響。單次共識過程和系統執行的整個共識歷史都應可審計、可監管, 該歷史應不可被纂改。”
趣鏈區塊鏈平臺針對共識協議節點惡意攻擊的問題，採用RBFT高魯棒性拜占庭容錯共識演算法，並自研Recovery機制，能夠保證動態資料的失效恢復。同時透過多層級的日誌系統進行共識過程的記錄，做到對故障/欺詐節點的感知、確認、處理、記錄等全流程管控。
而Fabric在v1.0以後採用Kafka進行交易的定序，在v1.4.1後支援RAFT共識演算法，這兩種實現方式可以容忍半數節點失效，但不支援拜占庭容錯，即不能容忍節點作惡，需適配拜占庭容錯共識演算法才能滿足規範要求。
支援全國密的密碼安全模組
在密碼演算法層面，標準強調：“在儲存敏感的業務資料、身份鑑別資料和金鑰資料之前，應使用符合國家標準的加密演算法、訊息鑑別碼演算法、數字簽名等技術提供通訊中資料的完整性保護和校驗。使用隨機數應按照國家密碼管理部門相關要求生成隨機序列，並符合GB/T 32915-2016要求。使用數字簽名等技術保證實體行為的不可否認性，其應用場景包括實體行為的確認、背書方對實體行為進行的背書。”
針對敏感業務資料、身份鑑別資料和金鑰資料的儲存問題，趣鏈區塊鏈平臺早在2016年就已支援國密標準，使用SM2、SM3、SM4、SM9等國密演算法對以上資料進行安全加密，全方位地保證資料在儲存、傳輸、使用過程中的安全性。與此同時，平臺對接了第三方證書機構CFCA，可提供真實可信的證書服務。
原生Fabric暫不支援國密標準，主要透過密碼套件介面BCCSP支援國際標準的各類加密雜湊演算法，並應用於相關簽名、驗籤、資料加密等處理流程中，處理過程中存在著大量不可控因素，同時透過自身的安全成員服務MSP而不是第三方可信證書機構提供證書服務。基於Fabric架構的金融專案需要適配新的密碼模組，以符合標準要求。
智慧合約管理新機制
在智慧合約層面，標準強調：“應在部署或升級操作時定義版本號，交易資訊中應明確呼叫的智慧合約版本。具有前向相容能力，舊版本合約應及時停用並存檔，新版本合約能呼叫歷史資料。支援智慧合約之間相互訪問的條件下，限制錯誤智慧合約的感染。控制智慧合約對外部環境的訪問。系統有程式碼漏洞稽覈機制，智慧合約釋出應引入相關方聯合稽覈機制，稽覈流程高效、嚴謹。滿足智慧合約從部署到廢止的生命週期相關要求。”
趣鏈區塊鏈平臺針對智慧合約版本、訪問、審計、生命週期管理等一系列問題，採用“縱橫”管理策略，縱向支援合約版本無縫升級、向前相容、呼叫歷史資料等相容效能力；橫向提供完備的合約生命週期管理，包括合約的建立部署、呼叫銷燬、凍結存檔等。趣鏈區塊鏈平臺作為首個支援Java語言編寫智慧合約的底層區塊鏈平臺，提供完備的合約部署、升級、凍結、解凍、銷燬、存檔全流程管理機制。另外平臺針對智慧合約相關標準還支援以下特性：
針對外部資料訪問，平臺實現Oracle預言機機制保證合約能夠安全可控的訪問外部可信資料。
針對合約安全審計，平臺提供了合約安全審計服務MeshSec，為開發者提供完善的合約漏洞分析、形式驗證以及合約安全評級等安全檢測服務。
針對合約的聯合稽覈，平臺透過聯盟自治機制CAF（Consortium Autonomous Framework），不僅可以支援合約版本控制，還可提供成員管理、系統升級層面的聯合稽覈治理機制，對合約及系統進行高效管理，以避免中心化稽覈的集權問題。
Fabric在v2.0採用了新的鏈碼（chaincode）生命週期管理，包含鏈碼名稱和版本號管理，同時，新引入了分散式的智慧合約治理方式，對鏈碼升級、背書策略更新等方面進行了最佳化和支援。但其在鏈碼生命週期管理過程中暫不支援合約凍結/解凍，該功能在實際業務場景中是必要的，另外Fabric當前還不支援訪問可信外部資料來源，這限制了合約的部分可擴充套件性。
告別匿名性，擁抱“真實”的身份管理
在身份管理層面，標準要求：“相應主體應實現有效的使用者身份管理，主要功能包括身份註冊、身份核實、安全審計、賬戶管理憑證生命週期管理、身份鑑別、節點標識管理、身份更新和撤銷、身份資訊保安性管理等，並對身份進行監管審計。支援還原匿名標識中的使用者真實身份以及相關交易資訊，配合交易審查，加強KYC管理。”
在標準的細則中，可以發現當前身份管理主要矛盾在於當前大多數區塊鏈沒有將使用者真實身份與區塊鏈賬戶核實對應，隨之引發使用者身份註冊、使用者憑證生命週期管理、賬戶管理、身份鑑別等資訊無法管理審計的問題，這源於區塊鏈的特性之一：匿名性。
趣鏈區塊鏈平臺採用了一站式身份管理解決方案，配合飛洛BaaS平臺採用使用者身份先識別後上鏈的聯合管理機制，可以很好地解決身份資訊記錄、管理、審計以及還原匿名標識中使用者真實身份等問題，使鏈上身份可查可證，滿足KYC要求。另外，平臺內建的國密SM9演算法，也能有效地滿足“前端匿名，後端可控”的身份管理需求。
同樣由於匿名性，Fabric對於身份管理資訊如數字身份證明、使用者職業居住地工作等無法獲取，所以暫不支援部分身份管理規範標準，需要進行業務層面的二次改造。
混合式多層級隱私保護機制
在隱私保護層面，標準強調：“業務相關方應將隱私資料按照敏感度進行分級，並根據具體場景制定相關的隱私保護策略，以使系統的資訊保密性和隱私保護程度與執行效率達到平衡，並在隱私資料的採集、儲存、使用、流轉過程中滿足隱私保護技術要求，方便隱私資料的監管和審計。”
趣鏈區塊鏈平臺根據不同場景下業務相關方隱私保護問題，提出基於名稱空間（namespace）的分割槽共識機制、可驗證隱私交易的隱私保護機制、基於TEE的賬本加密等特性。
分割槽共識機制透過分割槽策略和規則將不同的業務交易劃分為不同分割槽粒度的子網路，實現了節點協同過程的最佳化和物理級的安全隔離。
隱私保護機制針對不同級別的敏感隱私資料需求，基於零知識證明、同態加密和環簽名等技術，透過交易相關方動態指定策略實現了交易粒度層面的使用者隱私許可權控制。
基於TEE賬本加密解決資料儲存安全問題，使用者可透過密碼學演算法如雜湊校驗等進行有效性和正確性驗證，方便監管和審計。
在隱私保護層面，Fabric透過通道策略達到了訪問隔離的目的，如果想在呼叫鏈碼前對資料進行加密操作，需要自己提供金鑰獲取方式，這種形式雖然可以達到資料加密的要求，但相比之下，趣鏈區塊鏈平臺提供的一站式安全解決方案更為高效便捷。另外，關於隱私交易，Fabric在2.0版本中更新了原有的隱私保護策略，成員組織可選擇與其直接網路的特定成員私下共享資料。除此之外，關於隱私交易的資料審計問題如細則中隱私資料的採集、流轉、使用的相關審查策略，Fabric不能很好的滿足，需要相應改造鏈碼以及業務系統等。
“一鍵上報”式監管
在監管支撐層面，標準要求：“支援監管機構的接入，以滿足資訊審計和披露的要求，應支援監管機構訪問最底層資料，實現穿透式監管。當系統或交易出現問題時，應能主動報警，採取適當糾正措施，並向監管機構、管理機構報送事件資訊。
趣鏈區塊鏈平臺支援監管節點的接入，並支援訊息訂閱異常推送功能，在系統交易出現問題時主動上報並採取適當安全措施。另外針對監管主動干預交易等問題，平臺提供了不同層級的許可權管理體系，可以對系統級、節點級、合約交易級多層級進行不同粒度的干預許可權和限制。
而在監管支撐方面，原生Fabric在系統和交易出現問題時，可以對問題進行定位和處理。但沒有一套完善的上報糾錯機制來滿足監管需求。需要對原生的架構進行二次開發，存在一定的改造成本。
分散式、高安全的運維手段
在運維要求層面，標準要求：“節點的版本升級應支援向下相容，應記錄升級過程中相關操作日誌，做到可審計、可追溯。應制定版本升級失敗的應急預案，在升級失敗的情況下啟動應急預案進行回滾，在規定時間內恢復節點的可用性。
趣鏈區塊鏈平臺針對於節點升級問題，採用基於CAF聯盟自治的系統升級方案，透過多中心化投票的方式對整個升級過程進行記錄，以便於審計追溯。對於升級失敗情況採用事前預防、事中處理、事後記錄的預案策略，以應對一些升級失敗等突發狀況。針對系統的可用性，平臺新增熱備節點CVP（Candidate VP），實現動態替換失效的VP節點。
Fabric v1.X版本與v0.X版本不能夠很好的相容，不滿足規範中對相容性的要求。同時由於引入了Docker、Kafka、Zookeeper等第三方軟體，對需要版本升級的業務系統提出了更高的運維需求。另外，Fabric在系統異常情況下進行資料恢復回滾操作時，節點必須是離線的，在回滾成功之後重啟才可恢復正常，這大大降低了系統可用性。
寫在最後
趣鏈區塊鏈平臺長期堅持合規、監管友好、支援企業級服務的良好理念，透過在金融領域的深耕積累，已經符合了相關規範要求，具備了金融分散式賬本安全服務能力。而Hyperledger Fabric目前在硬體加密、身份管理、監管審計等功能上存在一定的缺失，導致其在金融行業的應用存在一定的侷限性，如需在金融場景中使用，需要相應技術改造和適配以滿足相關的標準規範，進而帶來相關成本與研發週期的增加。
趣鏈區塊鏈平臺將繼續結合新標準和實際應用場景，在業內發揮重要領跑力量，助力實現更好的分佈協作，打造更好的金融形態、更好的信任社會。
參考文獻：
[1] 中國人民銀行.金融分散式賬本技術安全規範.
