天天看點

如何使用區塊鍊技術進行項目開發

區塊鍊是目前一個比較熱門的新概念,蘊含了技術與金融兩層概念。從技術角度來看,這是一個犧牲一緻性效率且保證最終一緻性的分布式資料庫,當然這是比較片面的。從經濟學的角度來看,這種容錯能力很強的點對點網絡,恰恰滿足了共享經濟的一個必須要求——低成本的可信環境。

本文以聯盟鍊為例,描述了實踐一個聯盟鍊的基本過程。

總體思路

首先要确定這個區塊鍊的類型,是公證型區塊鍊還是價值型? 

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

如果确定是價值型區塊鍊,我們又需要确定目标區塊鍊的總體定位:到底是一個普适的價值傳輸區塊鍊,還是特定場景下的區塊鍊?如果是特定場景下的區塊鍊,我們通常推薦超級賬本作為技術原型,如果是比較通用的價值區塊鍊,我們推薦以太坊的思路。

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

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

需求痛點分析 

一般需求痛點在滿足以下條件的時候,可以考慮使用區塊鍊:

  • 存在一個不互相信任的P2P網絡環境;
  • 節點之間是對等的,不存在一個絕對仲裁者;
  • 節點之間是博弈行為。 

    P2P網絡可能包含輸入和輸出,當包含輸入和輸出時,區塊鍊不再封閉。 

    對于某個節點一般有以下幾種行為(包括但不限于):

  • 不信任其他節點;
  • 保證自己的收益最大化;
  • 自私擷取但不貢獻資源。

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

非區塊鍊技術能否解決

案例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,回報資訊容易被篡改,可刷單等問題是最大的,如何保證這種資訊回報是客觀中立不可篡改的,可以結合區塊鍊代币的币齡使交易具有方向性來防止作弊行為。

業務場景模組化

針對第二節中的兩個案例,我們接下來要進行模組化,除去核心痛點,我們必然還有記賬的需求,本質上任何案例中每個節點都既是服務方,也是客戶方,那麼怎麼衡量自己貢獻和索取了多少呢?

是以任何區塊鍊平台上,必須是要有代币系統的,否則記賬将非常困難。在業務場景模組化過程中,我們主要關注如何使節點之間達成帕累托改進,而不是因為每個節點是自私行為,讓區塊鍊服務名存實亡。

開發路徑

區塊鍊原型選取

根據本文開頭的叙述,如果是特定場景的區塊鍊解決方案,建議Hyperledger fabric,當然搭建以太坊私有鍊也是可以的。

下面是一些以太坊和Fabric的比較:

以太坊與HyperLedger相同點:

  • 都是提供區塊鍊業務實作的平台,業務實作都是通過智能合約來完成,以達到最大的靈活性和對底層的不修改。 
    • 以太坊是:EVM虛拟機,Solidity合約語言;
    • HyperLedger是: Shim鍊碼容器,用GO編寫合約。
  • 官方版本都使用GO語言實作。
  • 因為都是提供第三方可程式設計能力,由于難度大,内部難免存在漏洞。對外則存在惡意程式攻擊的威脅。尤其是在做為公有鍊時,威脅将會更大。上個月以太坊已有報合約solidity語言漏洞。

以太坊與HyperLedger不同點:

  • 以太坊隻提供智能合約能力。也恰好吻合它的定位:智能合約和去中心化應用平台。對系統安全性或準入機制無底層無核心上的支援。而HyperLedger在吸收以太坊智能合約特點的同時,提供MemberShip及身份驗證角色管理等子產品,更貼近商業應用場景。
  • 共識機制不同。由于共識的不一樣,是以每秒可處理的交易量也不一樣,以太坊是每秒千級别的處理量,而HyperLedger可以達到十萬級别。
  • 采用的技術實作思路上不一樣。以太坊更多的是靠自己實作,自己造輪子,有點開發人員炫技的感覺,如自己提供合約語言solidity,自己實作EVM(這個可能是實際需要)。

表1是筆者曾經的一個私鍊項目中對兩者的比較(私鍊考慮了Hydrachain的可行性)。

如何使用區塊鍊技術進行項目開發

表1

讀者可以根據自己實際的TPS需求,進行共識的選型。

表2是不同共識的一些參考資料。

如何使用區塊鍊技術進行項目開發

表2

當然,如果考慮自行開發,建議搭建基礎比特币網絡,做加法,更改共識算法,網絡傳送協定以及附加合約(可選)。

其實智能合約在一些場景中不是必選項,對使用者來說,可靠友善實時是第一需求,如果針對特定的應用場景,将“合約”固化在區塊鍊裡面,也是一種可行的思路。

針對以上兩種聯盟鍊實作,筆者還想強調,并不是所有服務一定得是區塊鍊的,筆者構想了一個通用的保護傘型結構,如比特币的側鍊技術,主鍊提供基礎賬本服務,側鍊提供特定場景服務,側鍊上的應用可以是非區塊鍊實作的,隻需接口注冊即可。

如何使用區塊鍊技術進行項目開發

圖1

互動接口設計 

在互動接口設計上,推薦使用目前業界通用的Json-RPC接口,擴充性和友好性兼備。 

一般我們将接口分為兩類:開放接口和賬戶接口。開放接口是指區塊鍊本身的描述資訊,是不需要認證的,而賬戶接口是需要賬戶認證的。

基礎賬本設計 

基礎賬本設計包含以下兩個問題:

首先是原型區塊鍊是否已經滿足需求?如果針對以太坊,基本上不需要改動基礎賬本,隻需建構智能合約即可。如果以比特币體系為基礎,則可能有較大的改動。

不滿足需求時如何改動基礎賬本?這個其實要視賬戶模型而定,如果使用UTXO模式時,改動重點在如何嵌入模闆交易體。如果使用Balance模式,那麼則沒有這個問題。

業務擴充層設計 

業務擴充設計方面的内容比較複雜,篇幅問題這裡也隻是抛磚引玉提出兩個問題:

  • 擴充層是外接區塊鍊還是内置到區塊鍊?
  • 如果包含資料輸入,是否需要脫敏?脫敏後如何上鍊?

先想清楚這兩個問題或許能幫你更好地規劃業務擴充層的内容。

開發轉變和難點

開發思維的轉變

與傳統網絡服務不同的是,區塊鍊開發不再以面向服務為主要關注點,而是面向賬本和交易。

開發者面對的不再是以高可用高并發的應用程式為主要名額,而是切換到了面向使用者,關注使用者友好性和開發擴充性的終端程式開發。

是以高并發高性能不再是區塊鍊終端的核心名額,安全性、可擴充性、友好性成了主要名額。

圖2是一個适用于聯盟鍊/私有鍊項目的工作流程。

如何使用區塊鍊技術進行項目開發

圖2 适用于聯盟鍊/私有鍊項目的工作流程

開發難點 

目前來講,區塊鍊項目開發的難點有三個:

  • 開發人力資源儲備不足

    目前比較成熟的技術體系有比特币及衍生技術體系、以太坊、超級賬本HyperLedger fabric、比特股Bitshares、瑞波Ripple和未來币NXT。其中前三個是最有影響力的區塊鍊項目。比特币以及衍生技術多以C++語言進行開發;以太坊支援大部分主流語言,官方以Go為主,也有其他分支的項目如Rust語言的Parity錢包;超級賬本目前以Go為主。

    從目前上海地區的區塊鍊從業人員來看,保守估計在400~500左右。按一半為開發人員計算,也才200多個,面對巨大的市場需求,人才是極度稀缺的。

    由于C++目前僅在金融和遊戲領域有部分需求,是以C++工程師不多,尤其是高水準的C++工程師就更少了。Go作為新興語言,發展勢頭很猛,但是Go的生态也不如Java大。

如果從Java的角度看,如何把其生态利用起來,目前區塊鍊還沒有做到那個地步。

綜合來看,區塊鍊在技術方面與其他技術的結合還有待探索。

  • 區塊鍊是交叉學科,需要各方面工程實踐的經驗。在實踐方面,我們希望區塊鍊從業人員同時了解技術和金融業務,這個對人員的素質要求比較高,相應的符合标準的人就更少了。
  • 關于對各個區塊鍊技術體系了解的偏差,區塊鍊技術和概念日新月異,閉門開發可能會走到死胡同,如何保持一部分精力更新知識體系,同時保證開發進度對開發人員是有較大挑戰的。

區塊鍊作為一門新興的技術,涵蓋了去中心化、去信任、共享經濟、分布式計算、分布式存儲等多方面的内容,考驗着技術人員的學習和思考能力。在未來,區塊鍊将同人工智能一起,會影響到普通人生活的方方面面。

原文釋出時間為:2017年09月01日

本文作者:區塊鍊大學營

本文來源:

CSDN區塊鍊大學營

,如需轉載請聯系原作者。

繼續閱讀