一、在業務應用區塊鏈技術之前，我們需要做什麼？
在主題介紹之前，一起來看一張圖：
上圖是Gartner提供的一份2018年關於企業對區塊鏈技術規劃的調研結果，結果表明在受訪的企業中（包含高科技、IT、互聯網企業）大概有66%的企業表示對區塊鏈技術感興趣，但是真實投入研發並且在正式環境部署過的企業大概只有1%。
區塊鏈技術還未發展到或者人們還沒有認識到其所帶來的價值和意義，這是現狀。其中一個原因是——這個技術的易用性現在是很低的。
易用性有以下三個方面：
-
開發、部署、運維成本高；
-
公有鏈、私有鏈、聯盟鏈框架衆多，且技術標準還未形成統一共識；
-
各個企業缺乏工程落地經驗，各個行業更是缺乏應用落地範本。
現在區塊鏈技術所處的階段，個人理解像是web技術發展的早期，還未形成統一的web技術核心標準（如http協議等），所以也就沒有太多的web應用創造出來。
攜程在技術研究重發現，即使是最成熟的如Fabric、以太坊這樣的開源技術框架，也遠遠沒有達到生產環境對於穩定性、高可用性、高併發支持等這些基本要素的要求，而這些框架的學習成本、使用成本、運維成本也非常高，讓現有的業務部門技術同事兼職來現學現用，是一件非常困難的事情。
因此，需要做一個支撐業務應用的區塊鏈服務平臺，去屏蔽掉最底層區塊鏈系統的網絡架構、框架搭建、應用集成、運維監控的複雜性，並且需要做各種源碼、環境、使用方式的優化，以讓上層業務應用能最高效的應用區塊鏈技術。
平臺的目標是各個業務部門的技術同事在充分了解區塊鏈技術理念、基本概念以及如何解決業務痛點的前提下，能夠不深入學習以太坊、Fabric等底層區塊鏈技術框架，就能快速將當前業務與區塊鏈技術結合。包含快速開發、快速部署、快速上線、有效運維以及能夠滿足對於應用上線的基本要求。
二、攜程區塊鏈技術服務平臺（CBaas）介紹
下圖爲CBaas平臺的技術棧：
因爲區塊鏈的部署（尤其是fabric）對於容器技術是重度依賴的，所以需要一個可應用於生產環境的swarm/k8s集羣服務。
這樣的區塊鏈平臺，與獨立的業務系統是完全不同的，而更像是集開發、發佈、測試、運行、運維於一體的完整的應用操作系統。對於我們現有的應用發佈、運維體系有較大沖突，需要paas層服務團隊提供更爲靈活的支持。
上面一層是區塊鏈的底層框架，首選支持的是目前最爲成熟的聯盟鏈框架-HyperLedger Fabric，Fabric目前在國內外是落地最多的框架了。其次是以太坊，以太坊是區塊鏈2.0即智能合約平臺最重要的框架，其影響力和社會熟知度是比較高的，以太坊更適合做激勵型社區類應用。最後是我們正在做的自己的底層區塊鏈框架CtripChain。
在應用Fabric的時候，我們改了一些或者說是擴展了一些框架的源代碼。Fabric是一個在技術、代碼設計上非常靈活的框架，因此我們將改動抽象出了代碼上的一個插件層，如國密算法、PBFT共識等。
服務層是CBaas平臺的主要邏輯所在，我們將Fabric等這些框架在更上層抽象出了網絡、聯盟、通道、節點等概念。
可以通過CBaas console頁面，你靈活的根據自己的需求搭建區塊鏈技術架構，進行動態節點擴容、動態對鏈進行治理等。
值得一提的是，我們改變了傳統的baas平臺集中式、上帝式的區塊鏈治理模式。
我們認爲，聯盟鏈不應該是由一個組織、一個用戶來進行治理，引入了多企業租戶共同治理的模式。比如一個既有通道、既有聯盟增加新的企業成員，應該由通道/聯盟中的組織一起進行簽名審批，並且將簽名審批結果提交到鏈上，與鏈上策略模塊提前在線上協商制定好的背書策略簽名一致纔可以通過。
整個過程中，所有企業在平臺上都是一個獨立的企業租戶，甚至可以將企業租戶對應的節點，部署到自己的內網中。只要保證與企業聯合建立的聯盟網絡能夠進行rpc通信就可以。
服務層其他方面，一個是公鏈的錨定，這與業務有一定關係。在做區塊鏈創新的過程中，我們也跟業內有名的區塊鏈公司合作，將聯盟鏈上的一些東西，跟公鏈做hash錨定，來進一步增強聯盟鏈的公信力。
另一塊是api service，進一步對fabric、以太坊等區塊鏈的客戶端SDK進行了封裝，業務開發人員可以直接調用CBaas平臺上的restful接口來進行合約的調用，甚至是聯盟、通道等動態治理。
最後是我們定義的區塊鏈的“前端”展現端，這塊包括portal工作臺、外部節點安裝包、OpenAPI，區塊鏈瀏覽器（可以用於彙報展示用），以及內部的一個智能合約集市，一些比較好的智能合約可以共享在集市上。
三、聯盟鏈框架的選擇——HyperLedger Fabric的架構與設計理念
在做CBaas平臺選擇支持的底層框架時，我們對於Hyperledger Fabric的代碼研究的一些經驗，希望可以給大家在做聯盟鏈底層技術選擇時一些參考。
下面是Hyperledger Fabric的整體組成，也是當前主流區塊鏈2.0技術框架的通用型架構，包含client SDK、p2p網絡、共識引擎、智能合約執行引擎、底層數據賬本，以及聯盟鏈獨有的權限體系。
我們首選Fabric框架，除了其社區活躍、落地應用案例較多外，另一個比較重要的因素是它的模塊設計非常靈活，體現在技術設計、代碼模塊設計上。
- fabric模塊化設計之合約執行引擎的解耦
首先看一下fabric在合約執行引擎層的解耦，我們做一個fabric與以太坊的對比。
以太坊的evm定義了一個適合在公鏈網絡中可以在以太坊節點上運行的簡單、確定、輕量、安全並且能夠計算合約運行成本的智能合約虛擬機。是首個在區塊鏈網絡上支持智能合約運行並取得成就，且到目前爲止，沒有因爲evm的bug導致重大事故發生（目前出現的事故都是合約代碼的bug）。
當然，evm的設計並非沒有缺陷，evm存在的問題：
1）賬本數據結構與evm代碼綁定較深，修改會互相影響。
現在很多機構自研的公鏈/聯盟鏈，選用的智能合約執行引擎大多都是evm，如果不加以較爲大量的源代碼修改、測試，基本意味着底層賬本的數據格式、結構都是以太坊的了。當然這個問題在未來也有可能不是問題，前提是evm能作爲智能合約引擎以及底層賬本的技術標準。
2）採用256位整數運算，致使32位/64位x86處理器相對低效。
這其實是爲了適應更大的內存尋址和複雜的密碼學運算以實現安全的gas模型而設計的，但是當evm被用於聯盟鏈時，這種低效的處理是完全沒有必要的，因爲聯盟鏈無需消耗gas。
3）evm是一個基於棧的虛擬機，大多數操作都使用棧。
棧都是有棧深度的，意味着當使用超過棧深的時候就會報錯棧溢出。
4）evm的標準庫太少。
這個一方面跟solidity的語言生態有關，另一方面是因爲如果引入大量的第三方庫，可能會意味着引入不必要的代碼和gas消耗。
關於evm的問題，這裏不深入探討，網上很多技術大牛對evm缺陷有更深入的分析。再來看一下fabric，fabric有兩塊設計來做智能合約執行引擎解耦：
1）在代碼層面，定義了container接口層，該接口目前有3個實現：DockerVM（執行用戶合約）、InproVM（執行系統合約）、MockVM（UnitTest的mock環境）。
目前fabric的智能合約引擎可以理解爲是基於docker容器的，當節點主應用部署一個智能合約時，會socket連接節點宿主機的docker，動態生成一個可以執行智能合約語言的docker容器。這是fabric自帶的一個實現，因爲fabric在這塊是代碼解耦的，意味着可以實現該接口來實現自己的智能合約執行引擎，如jvm等。
2）DockerVM的實現中，docker容器與區塊鏈節點的通信方式爲grpc，意味着通過協議的模式進行了代碼層的解耦。這與以太坊中evm代碼與節點代碼難以解耦不同。
我們總結了fabric以下優缺點：
優點：
1）代碼層面上實現了對VM和節點進行脫耦，並且易於擴展新的VM方式。
2）dockerVM的原理，理論可支持衆多開發語言開發智能合約。
缺點：
依賴docker運行環境，嚴重限制fabric節點的部署可能性；docker作爲沙箱環境相對複雜，安全性、穩定性都面臨較大的挑戰，難以適用於公鏈環境，但是可以應用在一個確定運行環境的聯盟鏈上。
- fabric模塊化設計之鏈上代碼邏輯的解耦
這一點我覺得是fabric明顯優於現在的區塊鏈2.0衆多聯盟鏈框架的地方，也是很多區塊鏈3.0，如EOS等正在做的東西，那就是——將更多主鏈上的邏輯（非用戶開發的智能合約）作爲鏈上的事務，或者是作爲鏈上的智能合約來設計。
這就意味着，首先鏈上的邏輯可以更靈活的被修改甚至可以在不需要在有可能引起分叉的代碼升級的前提下進行運行時修改；再就是鏈上邏輯的修改可以像智能合約一樣，被共識。
Fabric將節點代碼中的部分邏輯，如背書過程、交易驗證過程、智能合約生命週期管理、配置管理（對應escc、vscc、cscc、lscc系統鏈碼）都作爲鏈上合約來設計，稱之爲系統合約。
這些過程是可以被鏈的共識機制所覆蓋的，所以纔有了fabric可以通過定義各種策略，來實現非中心化地干預這些內置處理流程，如可以定義背書策略、智能合約初始化策略等。
不過現在fabric1.3的版本並沒有做到鏈上的邏輯可以被靈活修改甚至是運行時修改，到現在只是開放了開發者可以通過代碼替換來自定義修改escc、vscc。現在的開發者可以通過修改這兩個系統合約，實現很多fabric目前實現不了的功能，比如：基於數據狀態的背書策略、匿名交易場景（公鑰匿名）等。
- fabric模塊化設計之共識引擎的解耦
我們先來回顧一下fabric的共識過程：
其實fabric的共識過程是比較有自己的特點的，跟公鏈的共識過程也有比較大的不同：公鏈的共識者，同時承擔合約預執行、交易排序的職責；fabric中排序節點只做排序，合約預執行由背書節點做。（fabric中背書節點與排序節點的組合=公鏈如以太坊中的共識節點）。
不過，fabric在共識這一塊的解耦是跟智能合約執行引擎比較類似的做法：
1）排序節點代碼側定義了consenter接口，可以通過實現consenter接口拓展共識排序算法.
2）剛講了fabric的共識要算上背書節點背書和交易驗證模塊，對應escc/vscc兩個系統合約，恰好這兩個系統合約是可以修改的。
以下附錄這一點的完整總結。
- fabric模塊化設計之權限控制的解耦
權限控制其實作爲聯盟鏈重要的特徵，在fabric中體現的淋漓盡致，我們來看一下fabric是如何做整個鏈上的權限控制的呢？
在設計常規的多租戶企業級軟件時，我們往往都會先定義軟件的使用企業、企業用戶、系統角色，再定義每個頁面、菜單，然後再將企業、用戶、角色與頁面、菜單結合起來，這樣就可以設置哪個企業、什麼樣的用戶、什麼樣的角色有權限訪問某個頁面、菜單……
其實fabric的設計與這種企業軟件的設計類似，首先fabric中權限的最高級別是msp，msp可以是一個組織，如org1，用來做整個區塊鏈的企業租戶切分，msp之下，fabric又定義了用戶、節點，組成權限體系的角色role層級。如：Org1.admin、Org1.member、Org1.peer。
而組織，包括組織下的用戶、節點等都有一個唯一的ID，這個唯一的ID在區塊鏈中成爲identity（以太坊的identity比較簡單，它是一個公鏈所以identity只代表用戶），每個identity基於非對稱密碼學對應一對公私鑰。
區塊鏈在運行時，全靠這個identity來標識身份。fabric有一個子項目叫fabric-ca，提供這個identity的管理機制，即一套PKI公鑰基礎設施。
fabric將很多鏈上的過程，都定義成了上面所講的企業軟件中的“功能”，而功能與角色或者ID的對應訪問關係，叫做“ACL”。
現在比較好理解了吧，其實ACL就是企業級軟件中的哪個企業、什麼樣的用戶、什麼樣的角色有權限訪問某個功能。以下截圖是部分fabric中現有的ACL，我們可以通過修改這個ACL，達到修改fabric中某個過程中的權限控制。
以下附錄這一點的完整總結。
- Fabric對於同構鏈中多鏈以及多鏈通信的設計
這一點是有別於前面三點的，前面三點都是說明fabric是如何做技術設計的解耦。而這一點我們聊聊fabric對於同構鏈中多鏈以及多鏈通信的設計。
首先解釋一下什麼是多鏈問題，我們知道，其實我們所熟知的以太坊、比特幣主鏈其實都是一條比較大型的公有鏈。而其實除了主鏈外，基於比特幣、以太坊源碼有很多機構自己重新搭建的一條新的鏈。
比如同樣的兩條以太坊搭建的鏈，就說明兩條鏈是同構鏈，而兩條鏈之間如果需要通信，就是同構鏈的通信，也就是多鏈通信。剛剛講的只是多鏈的一部分形態，還有側鏈、子鏈、平行鏈等更多多鍊形態，爲大家容易理解，不做贅述。
對於fabric，首先它定義了通道的概念，即一個fabric聯盟鏈網絡，可以有多個通道，每個通道對應本地一套單獨的賬本，這個通道可以理解爲一個類似於子鏈的概念。
我們可以把每個通道，看成是一個較爲獨立的子鏈，這個子鏈的賬本是物理隔離的，不過每個子鏈需要共享父鏈的排序節點。
目前fabric中跨通道的通信，是通過智能合約間的調用實現的，如同時在channel1/channel2上的節點安裝的合約1/合約2可以互相調用，即兩個通道只有在存在交集節點的情況下，纔可以通信，還未實現完全獨立的通道之間的數據互通。
fabric中通道的設計其實可以做很多遠遠超過你預期的事情，如隱私數據保護、緩解節點數據無法分片問題、實現並行計算支持高併發。
四、fabric在鏈上保存原始數據（非哈希）並可以按需分享的一種解決方案
下面分享我們在fabric應用過程，這個分享標題完整版爲：在保護數據隱私的前提下，如何用fabric在鏈上保存原始數據（非哈希）並可以按需分享的一種解決方案。
首先來看一個區塊鏈應用的場景：
如A與C，B與C分別在發生交易，但是A和B是同業，互相不希望與C發生的交易被彼此知道。所以放到fabric中，大家肯定要分別設計兩個channel，來屏蔽兩個交易方，通過channel可以做一些交易對手間的信息共享。
而這個時候假設存在D，在實際業務中有權利查看AC和BC的全部業務數據，則D可以分別加入到channelA,B中。這個模型是沒問題的，那我們現在把問題變複雜一些。
OrgD假設是沒有權利查看AC、BC所有交易的權限的。但是在實際業務中，他希望可以看到AC、BC的某些交易詳情，且需要經過A/B的授權纔可以查看，該怎麼辦？
這個時候有同學可能會講，A和B分別把他希望的數據給他不就可以了嗎？我們這裏有個前提，就是我們需要藉助區塊鏈這個技術，直接將數據在鏈上給過去，因爲這樣數據可以經過交易對手方C組織的背書，假設D能夠直接從channelA、B上拿到他想要的數據，那麼這個數據是天然經過C組織背書的。
我們來看這樣一個解決方案：
這張圖已經完整的描述了整個方案的詳情，以及這個方案的優點：整個交易過程全部上鍊，不引入鏈下的過程，實現數據、信任完全的鏈上流轉。這個案例經常出現的業務場景想必大家已經猜到了，就是金融領域。
也許真實遇到的業務場景要比我上面舉的例子要複雜的多，也許還有更好的解決方案，如很多人提出一個零知識證明的算法，但是之所以將這個例子拿出來交流，其實是希望每一個從業者能從“哈希上鍊”這樣一個保護傘下中逐漸走出，去嘗試克服真實數據上鍊的各種難題，從而使區塊鏈技術真正地服務於實際業務，讓業務數據能夠真實的在鏈上互轉，真正成爲“信任機器”的主角。
希望在各位同道的一起努力下，區塊鏈技術能夠真正走出實驗室、走出技術極客的圈子，發揮出技術應有的價值。
作者介紹：何鑫銘，攜程技術中心創新研發部區塊鏈技術專家，攜程區塊鏈技術平臺技術負責人，精通當前主流區塊鏈開源技術框架，熱衷於研究區塊鏈底層設計和區塊鏈應用創新。本文來自何鑫銘在“2018攜程技術峯會”上的分享。