區塊鏈是目前一個比較熱門的新概念，蘊含瞭技術與金融兩層概念。本文以聯盟鏈為例，簡單描述瞭實踐一個聯盟鏈的基本過程。
作者 | 陳浩，維優區塊鏈 CTO
首先要確定這個區塊鏈的類型，是公證型區塊鏈還是價值型？
公證型區塊鏈是指僅限一些關鍵數據自證、披露、防篡改等功能的區塊鏈，通常是在價值型區塊鏈中附帶的功能，也可以單獨擴展，用於公示公開等。價值型區塊鏈是指可以進行資產所有權轉移的一種記賬賬本。
如果確定是價值型區塊鏈，我們又需要確定目標區塊鏈的總體定位：到底是一個普適的價值傳輸區塊鏈，還是特定場景下的區塊鏈？如果是特定場景下的區塊鏈，我們通常推薦超級賬本作為技術原型，如果是比較通用的價值區塊鏈，我們推薦以太坊的思路。
業務場景的構建與初步分析
首先要明確的觀點是，區塊鏈不是萬能的。很多場景其實是不需要區塊鏈技術也能解決的。像跨境支付領域，區塊鏈能很好的發揮是因為存在很多點對點的跨境機構有大量的支付清算需求，而又不希望中間機構參與，區塊鏈是很好的選擇。但是在一些集團內部，大型公司內部，區塊鏈解決方案基本上遠遠不如傳統的企業資源解決方案。
A、需求痛點分析
一般需求痛點在滿足以下條件的時候，可以考慮使用區塊鏈：
存在一個不相互信任的 P2P 網絡環境；
節點之間是對等的，不存在一個絕對仲裁者；
節點之間是博弈行為。
P2P 網絡可能包含輸入和輸出，當包含輸入和輸出時，區塊鏈不再封閉。
對於某個節點一般有以下幾種行為（包括但不限於）：
不信任其他節點；
保證自己的收益最大化；
自私獲取但不貢獻資源。
針對以上情景的業務建模，需要針對具體的業務邏輯結合博弈論推導出滿足自己需求的方案。
B、非區塊鏈技術能否解決
案例 1：
通常我們有不同的機構 A、B、C，存在不對稱的信息交換需求，即 A、B、C 分別具有部分數據，但三者組合到一起具有市場的全量數據。但是作為 A，想知道 B、C 是否擁有自己數據集合中的某個點數據，根據這個結果來調整自己的購買策略。
案例 2：
有不同的機構 X、Y、Z，存在信息反饋的需求，當 Z 收到 Y 的服務時，會給 Y 一個信息反饋，這種反饋可能是信用評價，也可能隻是響應反饋。總之這種反饋需要記錄在案，X 會根據 Z 的信息反饋結果調整自己的購買策略。當 X 購買服務時，同樣會給 Y 一個反饋，Z 也會收到反饋。
以上兩個案例首先考慮使用非區塊鏈是否可以解決：
針對案例 1，敏感數據和私有數據是不會公開的，即使加密也不會被允許上傳到區塊鏈。所以產生瞭一個數據輸入輸出區塊鏈的過程，該過程是區塊鏈不可控制的。
那麼使用傳統的技術是否可以控制呢？貌似也不行，能夠滿足不暴露敏感數據的方案也隻有 HASH 計算和同態加密。但是這兩者都要求數據傳輸到指定位置。
通常我們會考慮使用零知識證明作為解決方案，然而具體的算法可能需要根據具體業務邏輯進行構建，結合簡單智能合約，根據查詢結果產生不同輸出。
針對案例 2，反饋信息容易被篡改，可刷單等問題是最大的，如何保證這種信息反饋是客觀中立不可篡改的，可以結合區塊鏈代幣的幣齡使交易具有方向性來防止作弊行為。
業務場景建模
針對第二節中的兩個案例，我們接下來要進行建模，除去核心痛點，我們必然還有記賬的需求，本質上任何案例中每個節點都既是服務方，也是客戶方，那麼怎麼衡量自己貢獻和索取瞭多少呢？
所以任何區塊鏈平臺上，必須是要有代幣系統的，否則記賬將非常困難。在業務場景建模過程中，我們主要關註如何使節點之間達成帕累托改進，而不是因為每個節點是自私行為，讓區塊鏈服務名存實亡。
開發路徑
A、區塊鏈原型選取
根據本文開頭的敘述，如果是特定場景的區塊鏈解決方案，建議 Hyperledger fabric，當然搭建以太坊私有鏈也是可以的。下面是一些以太坊和 Fabric 的比較：
以太坊與 HyperLedger 相同點：
都是提供區塊鏈業務實現的平臺，業務實現都是通過智能合約來完成，以達到最大的靈活性和對底層的不修改。
以太坊是：EVM 虛擬機，Solidity 合約語言；
HyperLedger 是 : Shim 鏈碼容器，用 GO 編寫合約。
官方版本都使用 GO 語言實現。
因為都是提供第三方可編程能力，由於難度大，內部難免存在漏洞。對外則存在惡意程序攻擊的威脅。尤其是在做為公有鏈時，威脅將會更大。上個月以太坊已有報合約 solidity 語言漏洞。
以太坊與 HyperLedger 不同點：
以太坊隻提供智能合約能力。也恰好吻合它的定位：智能合約和去中心化應用平臺。對系統安全性或準入機制無底層無核心上的支持。而 HyperLedger 在吸收以太坊智能合約特點的同時，提供 MemberShip 及身份驗證角色管理等模塊，更貼近商業應用場景。
共識機制不同。由於共識的不一樣，所以每秒可處理的交易量也不一樣，以太坊是每秒千級別的處理量，而 HyperLedger 可以達到十萬級別。
采用的技術實現思路上不一樣。以太坊更多的是靠自己實現，自己造輪子，有點開發人員炫技的感覺，如自己提供合約語言 solidity，自己實現 EVM（這個可能是實際需要）。
表 1 是筆者曾經的一個私鏈項目中對兩者的比較（私鏈考慮瞭 Hydrachain 的可行性）。
讀者可以根據自己實際的 TPS 需求，進行共識的選型。表 2 是不同共識的一些參考數據。
當然，如果考慮自行開發，建議搭建基礎比特幣網絡，做加法，更改共識算法，網絡傳送協議以及附加合約（可選）。
其實智能合約在一些場景中不是必選項，對用戶來說，可靠方便實時是第一需求，如果針對特定的應用場景，將 " 合約 " 固化在區塊鏈裡面，也是一種可行的思路。
針對以上兩種聯盟鏈實現，筆者還想強調，並不是所有服務一定得是區塊鏈的，筆者構想瞭一個通用的保護傘型結構，如比特幣的側鏈技術，主鏈提供基礎賬本服務，側鏈提供特定場景服務，側鏈上的應用可以是非區塊鏈實現的，隻需接口註冊即可。
B、交互接口設計
在交互接口設計上，推薦使用目前業界通用的 Json-RPC 接口，擴展性和友好性兼備。
一般我們將接口分為兩類：開放接口和賬戶接口。開放接口是指區塊鏈本身的描述信息，是不需要認證的，而賬戶接口是需要賬戶認證的。
C、基礎賬本設計
基礎賬本設計包含以下兩個問題：
首先是原型區塊鏈是否已經滿足需求？如果針對以太坊，基本上不需要改動基礎賬本，隻需構建智能合約即可。如果以比特幣體系為基礎，則可能有較大的改動。
不滿足需求時如何改動基礎賬本？這個其實要視賬戶模型而定，如果使用 UTXO 模式時，改動重點在如何嵌入模板交易體。如果使用 Balance 模式，那麼則沒有這個問題。
D、業務擴展層設計
業務擴展設計方面的內容比較復雜，篇幅問題這裡也隻是拋磚引玉提出兩個問題：
1. 擴展層是外接區塊鏈還是內置到區塊鏈？
2. 如果包含數據輸入，是否需要脫敏？脫敏後如何上鏈？
先想清楚這兩個問題或許能幫你更好地規劃業務擴展層的內容。
開發轉變和難點
A、開發思維的轉變
與傳統網絡服務不同的是，區塊鏈開發不再以面向服務為主要關註點，而是面向賬本和交易。
開發者面對的不再是以高可用高並發的應用程序為主要指標，而是切換到瞭面向用戶，關註用戶友好性和開發擴展性的終端程序開發。
所以高並發高性能不再是區塊鏈終端的核心指標，安全性、可擴展性、友好性成瞭主要指標。
圖 2 是一個適用於聯盟鏈 / 私有鏈項目的工作流程。
B、開發難點
目前來講，區塊鏈項目開發的難點有三個：
1. 開發人力資源儲備不足
目前比較成熟的技術體系有比特幣及衍生技術體系、以太坊、超級賬本 HyperLedger fabric、比特股 Bitshares、瑞波 Ripple 和未來幣 NXT。其中前三個是最有影響力的區塊鏈項目。比特幣以及衍生技術多以 C++ 語言進行開發；以太坊支持大部分主流語言，官方以 Go 為主，也有其他分支的項目如 Rust 語言的 Parity 錢包；超級賬本目前以 Go 為主。
從目前上海地區的區塊鏈從業人員來看，保守估計在 400~500 左右。按一半為開發人員計算，也才 200 多個，面對巨大的市場需求，人才是極度稀缺的。
由於 C++ 目前僅在金融和遊戲領域有部分需求，所以 C++ 工程師不多，尤其是高水平的 C++ 工程師就更少瞭。Go 作為新興語言，發展勢頭很猛，但是 Go 的生態也不如 Java 大。
如果從 Java 的角度看，如何把其生態利用起來，目前區塊鏈還沒有做到那個地步。
綜合來看，區塊鏈在技術方面與其他技術的結合還有待探索。
2. 區塊鏈是交叉學科，需要各方面工程實踐的經驗
在實踐方面，我們希望區塊鏈從業人員同時瞭解技術和金融業務，這個對人員的素質要求比較高，相應的符合標準的人就更少瞭。
3. 關於對各個區塊鏈技術體系理解的偏差。區塊鏈技術和概念日新月異，閉門開發可能會走到死胡同，如何保持一部分精力更新知識體系，同時保證開發進度對開發人員是有較大挑戰的。
區塊鏈作為一門新興的技術，涵蓋瞭去中心化、去信任、共享經濟、分佈式計算、分佈式存儲等多方面的內容，考驗著技術人員的學習和思考能力。在未來，區塊鏈將同人工智能一起，會影響到普通人生活的方方面面。
作者簡介：陳浩，維優區塊鏈 CTO，曾任埃森哲高級軟件工程師，擅長 C++/Python 語言，多年清算支付系統開發經驗。萬向區塊鏈實驗室 2016 上海區塊鏈黑客馬拉松比賽第三名，開源項目 Libbitcoin 開發組成員。
