如何使用區塊鏈開發一個落地項目？這位實戰大牛手把手教會你

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

作者 |陳浩，維優區塊鏈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模式，那麼則沒有這個問題。