區塊鏈是目前一個比較熱門的新概念，蘊含了技術與金融兩層概念。本文以聯盟鏈為例，簡單描述了實踐一個聯盟鏈的基本過程。

作者 |陳浩，維優區塊鏈CTO

首先要確定這個區塊鏈的型別，是公證型區塊鏈還是價值型？

公證型區塊鏈是指僅限一些關鍵資料自證、披露、防篡改等功能的區塊鏈，通常是在價值型區塊鏈中附帶的功能，也可以單獨擴充套件，用於公示公開等。價值型區塊鏈是指可以進行資產所有權轉移的一種記賬賬本。

如果確定是價值型區塊鏈，我們又需要確定目標區塊鏈的總體定位：到底是一個普適的價值傳輸區塊鏈，還是特定場景下的區塊鏈？如果是特定場景下的區塊鏈，我們通常推薦超級賬本作為技術原型，如果是比較通用的價值區塊鏈，我們推薦以太坊的思路。

業務場景的構建與初步分析

首先要明確的觀點是，區塊鏈不是萬能的。很多場景其實是不需要區塊鏈技術也能解決的。像跨境支付領域，區塊鏈能很好的發揮是因為存在很多點對點的跨境機構有大量的支付清算需求，而又不希望中間機構參與，區塊鏈是很好的選擇。但是在一些集團內部，大型公司內部，區塊鏈解決方案基本上遠遠不如傳統的企業資源解決方案。

A、需求痛點分析

一般需求痛點在滿足以下條件的時候，可以考慮使用區塊鏈：

1. 存在一個不相互信任的P2P網路環境；

2. 節點之間是對等的，不存在一個絕對仲裁者；

3. 節點之間是博弈行為。

P2P網路可能包含輸入和輸出，當包含輸入和輸出時，區塊鏈不再封閉。

對於某個節點一般有以下幾種行為（包括但不限於）：

1. 不信任其他節點；

2. 保證自己的收益最大化；

3. 自私獲取但不貢獻資源。

針對以上情景的業務建模，需要針對具體的業務邏輯結合博弈論推匯出滿足自己需求的方案。

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相同點：

1. 都是提供區塊鏈業務實現的平臺，業務實現都是通過智慧合約來完成，以達到最大的靈活性和對底層的不修改。

   以太坊是：EVM虛擬機器，Solidity合約語言；

   HyperLedger是: Shim鏈碼容器，用GO編寫合約。

2. 官方版本都使用GO語言實現。

3. 因為都是提供第三方可程式設計能力，由於難度大，內部難免存在漏洞。對外則存在惡意程式攻擊的威脅。尤其是在做為公有鏈時，威脅將會更大。上個月以太坊已有報合約solidity語言漏洞。

以太坊與HyperLedger不同點：

1. 以太坊只提供智慧合約能力。也恰好吻合它的定位：智慧合約和去中心化應用平臺。對系統安全性或准入機制無底層無核心上的支援。而HyperLedger在吸收以太坊智慧合約特點的同時，提供MemberShip及身份驗證角色管理等模組，更貼近商業應用場景。

2. 共識機制不同。由於共識的不一樣，所以每秒可處理的交易量也不一樣，以太坊是每秒千級別的處理量，而HyperLedger可以達到十萬級別。

3. 採用的技術實現思路上不一樣。以太坊更多的是靠自己實現，自己造輪子，有點開發人員炫技的感覺，如自己提供合約語言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開發組成員。

熱門文章

瞭解更多區塊鏈技術及應用內容，敬請關注：