以汽車金融為例，當我們做區(qū)塊鏈時我們在做什么
長話短說，我們在建鏈。
區(qū)塊鏈是什么
關于區(qū)塊鏈是什么，網(wǎng)絡上的解釋多如牛毛。這里，我從通常需求的角度總結一下：在記錄保存(身份存證)時，它是分布式賬本(分布式數(shù)據(jù)庫);在交易或支付(跨境支付)時，它是信任機器。雖然這兩種分類方法并不正交，但是對于理解區(qū)塊鏈的應用領域有很大的好處。
不論是分布式賬本，還是信任機器，其底層的特性——不可篡改、透明、可追溯以及去中心化，最終導向的目的都只有一個，那就是信任。
區(qū)塊鏈的可信度來自于人類對數(shù)學邏輯嚴密性的信任，數(shù)學理論和加密學實踐可以確保鏈上數(shù)據(jù)和所有權的可靠程度。區(qū)塊的確認基于共識算法、不可變的數(shù)據(jù)結構，再通過 Merkle Tree、Hash Pointer(哈希指針) 保證前向區(qū)塊鏈的完整性，再加上經(jīng)濟、人心的博弈、理性經(jīng)濟人假設，共同構成一套完整的信任系統(tǒng)。
然而，企業(yè)間的聯(lián)盟區(qū)塊鏈有一些不同，它的信任更多地依賴于發(fā)起者品牌的背書。在這樣的大環(huán)境下，聯(lián)盟鏈的設計就變得相當靈活，比如***腰斬的就是代幣。
區(qū)塊鏈的行業(yè)應用
在工信部***發(fā)表的《2018 年中國區(qū)塊鏈產(chǎn)業(yè)白皮書》中，區(qū)塊鏈產(chǎn)業(yè)生態(tài)分成了產(chǎn)業(yè)應用(包含金融和實體領域)，基礎設施和平臺(如公有鏈和BaaS)，行業(yè)服務(如媒體)。而我們的關注點集中在產(chǎn)業(yè)應用當中。
金融領域由于本身數(shù)字化程度比較高，在證券化以及ABS交易所等方向都有落地案例。在實體產(chǎn)業(yè)當中，供應鏈溯源，身份存證等也多有應用。再加上區(qū)塊鏈本身具有“信任穿透”的神奇功效，對于構建供應鏈金融征信體系，改善小微企業(yè)的融資困境也很有幫助。
總體來說，幾乎各種產(chǎn)業(yè)場景都能應用區(qū)塊鏈技術，因為這些場景里都有提升效率，降低成本，優(yōu)化征信體系的訴求。
汽車金融區(qū)塊鏈應用
1. 汽車金融
汽車金融中的核心資產(chǎn)是汽車。汽車金融始終圍繞車的生命周期發(fā)生金融活動。從零配件的生產(chǎn)，到主機廠制造整車，然后通過各個區(qū)域的銷售公司將整車賣給各區(qū)域內(nèi)的經(jīng)銷商。實際上在中國，經(jīng)銷商還可以分為不同層級的二三級經(jīng)銷商，***才到顧客手中。而一旦新車完成銷售，就邁入了后市場的廣闊天地，以及二手車、三手車的再銷售。
從汽車零配件的生產(chǎn)運輸和組裝到車賣給經(jīng)銷商，這些環(huán)節(jié)所涉及到的金融活動叫做供應鏈金融，而顧客通過金融活動來買車，不管是新車還是二手車，都屬于消費金融的范疇。
汽車的生命周期和金融公司的參與環(huán)節(jié)：
它們的業(yè)務模式長這樣：
通過分析現(xiàn)有業(yè)內(nèi)的業(yè)務模式，我們發(fā)現(xiàn)：
財務對賬成本高昂，且效率不高。這里的財務成本并非某家公司的財務成本，而是整個系統(tǒng)內(nèi)的財務總成本。僅在中國區(qū)可能就有多家銷售公司和金融公司，以及幾百家經(jīng)銷商，即使每家公司只有兩名財務和審計人員，那么財務審計人員都超過一千，更別提全球銷售范圍內(nèi)了。
傳統(tǒng)的對賬方式是怎樣的呢?
不同類型的機構進行在對賬時，往往要從信息系統(tǒng)中導出電子表格，并用郵件發(fā)送。甚至需要打印表格、蓋章后郵寄，對方收到后再與系統(tǒng)數(shù)據(jù)進行比對。
整個業(yè)務流程并不復雜，但是消耗了很多人力物力，且中心化的服務還由于對授權機制(多主體之間不太信任或者叫做弱信任)和信息安全等方面的考慮，而導致建設成本高昂，且制約了業(yè)務運行效率和用戶體驗的提升。區(qū)塊鏈作為分布式賬本，意味著任何機構之間互相發(fā)生債務往來的信息都是數(shù)據(jù)一致的，那么就可以近實時地進行對賬。
而我們區(qū)塊鏈要做的事情，一言以蔽之，汽車資產(chǎn)上鏈以及圍繞汽車所發(fā)生的金融活動而產(chǎn)生的債務的記錄。所以不難發(fā)現(xiàn)，分布式賬本和信任機器在這個場景下都有涉及。
2. 怎么建鏈
我們把這次建鏈過程大體總結為5個步驟：識別上鏈數(shù)據(jù)，智能合約設計，API設計，部署單元和網(wǎng)絡拓撲架構。
- 識別上鏈數(shù)據(jù)指的是識別將哪些交易記在鏈上;
- 智能合約設計，指的是買賣車及其相關金融活動如何通過可編程的方式自動完成;
- API設計，考慮如何對外暴露平臺能力，同時限制控制主體;
- 部署單元和網(wǎng)絡部署架構屬于實施范圍，旨在解答分布式賬本如何真正運行在企業(yè)當中。
整體技術架構是基于Corda這個分布式賬本技術展開的，Corda準確來說不是區(qū)塊鏈，而是一種受區(qū)塊鏈啟發(fā)的DLT，即分布式賬本技術，它是由金融區(qū)塊鏈聯(lián)盟R3開發(fā)和維護的。
(1) 上鏈數(shù)據(jù)識別
要分析清楚的問題是車在什么時候轉(zhuǎn)移，車在什么參與方之間轉(zhuǎn)移，車在轉(zhuǎn)移的過程中伴隨了什么數(shù)據(jù)的變化。在分析這塊業(yè)務的時候，我們通過事件風暴，分析了在各個法律參與實體之間發(fā)生車轉(zhuǎn)移的業(yè)務事件，然后進行了事件排序，通過事件析出數(shù)據(jù)，包括交易參與方，車的詳細信息，車的所有權和占有權以及債等等。這部分數(shù)據(jù)有一定的取舍，比如訂單就不在我們的核心資產(chǎn)當中，所以不上鏈。
我們開始進行數(shù)據(jù)建模，在此之前，有必要介紹一下Corda的編程模型——State，因為它會直接影響我們后續(xù)的模型設計。Corda中核心概念之一就是State，State是分布式賬本上的事實，它代表了交易參與方達成共識的結果。以IOU這個欠條為例，State其實就是欠條關鍵屬性的集合，包含借款方，欠款方，金錢數(shù)量，還款截止日期。當欠款部分歸還時，這個欠條的內(nèi)容就會發(fā)生變化，變化的方式就是將老的欠條標記成歷史的，進而生成包含新內(nèi)容的欠條。
在我們應用場景中，核心的State就是車和債，因為Corda是運行在JVM上，開發(fā)***語言是Kotlin，所以這里我們直接拿Kotlin中data class對車和債進行建模，而且統(tǒng)一繼承了Corda內(nèi)置的LinearState，LinearState擁有全局唯一ID，在數(shù)據(jù)演化的過程中不會發(fā)生改變。如果有人了解DDD相關概念的話，應該能自動映射到實體概念上。除此之外，Corda中還有一個核心State叫做Fungiable Asset，可以類比成值對象，例如：Cash。
State建模完成之后該怎么演化呢?這就不得不提一個UTXO的概念，UTXO全稱 unspent transaction ouput，最開始是比特幣網(wǎng)絡引入的，它有很多好處，比如可以追溯到每一筆輸出的源頭，幫助驗證是否存在雙花現(xiàn)象，Corda一樣繼承了類似的好處。銷售公司把車批發(fā)給經(jīng)銷商時，就會將所有權歸屬自己的車作為交易的輸入，產(chǎn)生輸出，輸出中包含了所有權的變更以及債務的生成。而作為輸入的車就會被標記成歷史的。這筆交易本身也必須獲取到交易雙方的簽名才能成立。
(2) 智能合約設計
上面我們聊到的都是鏈上的數(shù)據(jù)以及數(shù)據(jù)演化過程，不過這些過程都不是自動執(zhí)行的。對于復雜的金融合約，往往會涉及到多種state的變化，這個時候就必須使用自動化的流程封裝這些變化，封裝這些變化的東西其實就是智能合約。還是以經(jīng)銷商批發(fā)車為例，一個可能的合約模板就是規(guī)定車轉(zhuǎn)移的同時產(chǎn)生一筆債，以及對應的還款截止日期。這個合約強制state改變時，交易雙方必須參與簽名。
在進入智能合約實現(xiàn)之前，需要先了解一下Corda中flow和contract的概念。Flow是Corda中控制參與節(jié)點如何更新State的自動化流程，它對如何獲取交易對手方的簽名進行了封裝。一個標準的flow流程包括獲取鏈上數(shù)據(jù)，創(chuàng)建一筆交易，自簽名之后發(fā)送到對手方進行交易驗證，再簽名，最終在雙方的賬本上分別提交事務。而Contract則是在交易驗證環(huán)節(jié)提供驗證所用的腳本。
在我們的應用場景中，智能合約長成這樣，在flow中，先從鏈上取出原有車的數(shù)據(jù)，拷貝得到一個新的所有權發(fā)生轉(zhuǎn)移的車以及對應一筆債;然后通過 txBuilder構建一筆交易，交易的輸入是原車，而輸出即是新車和債;***就是驗證和簽名以及事務提交的過程。你可能已經(jīng)注意到txBuilder中有個firstNotary的參數(shù)，這里提一下notary的概念，notary在corda中是一類特殊的節(jié)點，專門用于防止資產(chǎn)雙花的問題。所以理論上，每筆交易都需要notary節(jié)點參與，并對交易進行簽名。在交易驗證環(huán)節(jié)中，我們定義的contract會被執(zhí)行，這個contract非常簡單，簡單到只有一個叫做verify的純函數(shù)。它的作用就是斷言每一個state的更新是否符合要求。這種設計非常符合Trust But Verify的理念。
(3) API設計
有了智能合約之后，我們就得考慮如何暴露平臺的合約能力了。換句話說，從消費者的角度，我們該怎么利用平臺提供的能力完成自己的業(yè)務。所以這里我們利用了REST api設計的思路，抽象出平臺的能力作為資源呈現(xiàn)，定義以車為中心的URI，然后選擇合適的HTTP動詞，得出 REST api。
從數(shù)據(jù)上鏈識別，到智能合約設計，再到API設計，我們在不同層次利用Corda這個分布式賬本技術。***層的分布式賬本記錄每筆交易發(fā)生的事實，不可篡改可追溯;中間的智能合約層提供了合約抽象，甚至可以和現(xiàn)實中的合約一一對應;最上層的REST api以資源的方式呈現(xiàn)了平臺的金融活動能力。
(4) 部署單元
這樣一個汽車金融平臺是怎么跑起來的呢?借助Docker，我們把一個物理部署單元打包成了一個鏡像，底層是一個全功能的Corda節(jié)點，所有的智能合約和state都以jar包的方式部署在這個節(jié)點上;同時利用SpringBoot通過RPC的方式連接到Corda節(jié)點，調(diào)用智能合約，對外暴露REST API;而Corda節(jié)點之間則通過消息的方式互相通信。
(5) 網(wǎng)絡拓撲
打包成docker鏡像之后，就可以部署到運行環(huán)境中，形成一個分布式賬本的P2P網(wǎng)絡。這里有2個節(jié)點需要留意，最左邊的 permission service 是用于對每個入網(wǎng)節(jié)點進行證書簽發(fā)，給予每個參與實體一個身份。中間的Network map類似于微服務中的 service discovery，Corda中節(jié)點的互相發(fā)現(xiàn)并不是通過廣播的方式發(fā)生，而是通過注冊Network map獲取其它節(jié)點的信息，進而找到對方。
回顧
***，我們回顧一下上面的三層架構，用價值的視角重新評估一下整個平臺。傳統(tǒng)的平臺，通過api的方式暴露服務從而獲得價值輸入，但是區(qū)塊鏈平臺的核心資產(chǎn)其實在***層的賬本中?；谶@些交易事實和債務或者支付記錄，我們可以很方便清算各個法律實體的數(shù)字資產(chǎn)，計算實時的債務信息，進行車輛的價值溯源，而且未來結合大數(shù)據(jù)分析和AI，更有可能打造出一個完整的供應鏈生態(tài)。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
