Hyperledger Fabric on SAP Cloud Platform

今天的文章來自Wen Aviva, 坐Jerry面對面的程式媛。

Jerry在之前的公眾號文章《 在SAP UI中使用純JavaScript顯示產品主資料的3D模型檢視 》已經介紹過Aviva了，SAP成都C4C開發團隊中其他同事評價她為：“ 美膩與智慧的化身 ”，“ 雲時代女王 ”，“ 是大家前沿技術的引路人 ”。因為Jerry和Aviva就在一個組，所以我的看法是，這些評價都實至名歸。

比如Jerry瞭解到的Javascript 3D渲染，擴增實境( A rgument  R eality)和這篇文章談到的Hyperledger Fabric， 全部都是從Aviva那裡學到的。

SAP成都研究院的每位同事，只要是參加了2017年歲末年會掃福字領紅包的活動，則理論上都使用了Aviva和成都另一位程式媛Zhao Rina開發的基於AR的小應用。

2017年7月初成都C4C開發團隊剛剛建立，除了老大Max之外，只有5位組員： 哈公子，大衛哥，象老師，勇哥和阿爽 。當時這支新的開發團隊面臨的最緊迫問題，就是贏得C4C美國開發總部的信任，從而從總部攬活到成都本地來做。用什麼獲得信任呢？對程式猿來說，當然是talk is cheap, show me the code。當時這支剛剛組建起來的五人小團隊對C4C毫不瞭解，但是卻選擇了一箇中國客戶呼聲非常高，非常希望能夠新增到C4C標準產品去的backlog。短短一個月時間，這個五人小團隊完成了從現學C4C產品知識和前後臺開發知識，到將backlog實現成一個原型的全過程。當原型錄成的視訊給美國開發老大過目之後，得到了極高的評價，驚歎這隻團隊從建立到productive只花了短短一個月的時間。這個原型的順利完成，為成都C4C團隊後續的發展壯大打下了一個堅實的基礎。

這個原型最後的交付形式是iOS應用。當時五位同事都沒有做過iOS平臺上的開發，不過幸好我們有Aviva。Max從SAP成都數字創新空間租借了Aviva。在她的幫助下，原型釋出順利完成。更令人敬佩的是，Aviva將她的iOS開發經驗無私地分享給了團隊其他同事，現在C4C團隊已經有多位同事能夠在iOS平臺上進行工作。我想，今年三月成都C4C團隊參加程式設計馬拉松時，在組隊階段給隊伍取名為“ Hi Aviva! ”, 或許是想通過這種方式感謝Aviva對C4C團隊做出的貢獻。

Jerry很慶幸每天可以和這樣的同事一起工作。

下面是Aviva的正文。

---

什麼是區塊鏈？簡單來說區塊鏈就是一個分散式的記賬本，或者分散式的資料庫。

區塊鏈的資料結構是一個連結串列，交易資料被儲存到連結串列的區塊中，區塊鏈的第一個區塊叫創世區塊，除了創世塊以外，每個區塊還包含前一個區塊的雜湊指標，這個雜湊指標的值是根據前一個區塊的實際資料計算出來的。雜湊指標指向前一個區塊，後面的區塊可以查詢前面所有區塊的資訊。

賬本的資料結構就是這樣的一個連結串列，那麼分散式的含義是什麼呢？

區塊鏈的眾多參與者組成了一個鬆散自治的P2P網路，我們把區塊鏈網路的參與者叫做節點，每個節點都擁有一個賬本拷貝，所有賬本的資訊都是一致的，在區塊鏈裡沒有中心節點。每當有新的交易進來，所有節點的賬本都會更新，並且最終保持一致。更新的方式不是去修改某個區塊的值，而是儲存交易記錄。比如在比特幣系統中，它沒有使用者資產記錄這樣的概念，不像普通資料庫那樣用一條資料儲存資產，比特幣使用者資產的值是通過把所有的交易記錄串聯聚合後得到的，賬戶裡資產的來源可以一直向上追溯，直到創世塊為止。區塊鏈裡的交易資料根據具體場景，可以是任何需要記錄的資訊。

智慧合約

為了支援資訊的持續更新，以及對賬本進行管理（寫入交易，進行查詢等），區塊鏈網路引入了 智慧合約 來實現對賬本的訪問和控制。智慧合約不僅僅可用於在區塊鏈網路中打包資訊，它們也可以被用於自動的執行由參與者定義的特定交易操作。

比如智慧合約可以規定物流中的運輸費用，根據物流的快慢收取不同的費用，根據貨物的到達時間進行自動轉賬等。上傳到區塊鏈網路中的的智慧合約會被打包到某一個區塊中，因此智慧合約一旦寫入區塊鏈，也是不可更改的。

共識機制

區塊鏈網路中交易資訊同步的過程，確保交易只有獲得適當參與者批准後才更新，所有的參與者都會將同樣的資訊按照同樣的順序更新，這樣的過程叫做共識。共識機制是區塊鏈的核心之一。

區塊鏈的第一個應用 比特幣 ，採用的是Proof of Work（工作量證明）的共識機制。簡單介紹一下比特幣的共識機制，演算法的具體細節大家可以去查白皮書。節點收到一個交易後，會根據判斷標準對該交易進行有效性校驗，無效的交易會被廢棄。通過有效性驗證之後的交易將會被廣播給其他節點。其他節點會做同樣的獨立校驗，當有效的交易達到整個網路所有節點時，即全網達成了“ 該交易有效 ”的共識。每個節點都會收到很多有效但是還未被打包到區塊中的交易，這些交易被組裝成Merkle Tree，Merkle Tree的第一個交易比較特殊，叫做coinbase，由節點自己建立，將挖礦獎勵支付到礦工自己的地址。挖礦獎勵包括新建立的比特幣和打包進該區塊所有交易的手續費總額。然後節點計算一個符合難度的雜湊值，挖礦就是通過修改引數不斷計算區塊雜湊值，直至達到難度要求，也就間接證明了該節點付出了對應的工作量，這就是工作量證明。Jerry的公眾號文章《 300行ABAP程式碼實現一個最簡單的區塊鏈原型 》裡用了一個ABAP方法CL_ABAP_MESSAGE_DIGEST=>CALCULATE_HASH_FOR_CHAR來計算區塊的雜湊值。

當節點計算出一個符合難度的區塊雜湊時，即說明該礦工挖礦成功了，該節點將該區塊組裝到本地的區塊鏈，同時也將此區塊廣播給其他節點。其他節點接收到該區塊後會驗證該區塊是否有效，有可能有兩個節點同時挖出了新的區塊B1和B2，它們的上一個區塊都是同一個區塊P。有的節點可能會先收到B1，有的會先收到B2，這時區塊鏈出現了暫時性的兩個分叉。要打破這種局面，要看下一個區塊是基於B1生成還是基於B2生成。如果基於B1，B1這條鏈就變成了最長鏈，其他包含B2的節點會重新選擇最長鏈，而B2作為孤塊被丟棄掉。

到目前為止，我們可以將區塊鏈看做是一個共享的，去中心化的多備份系統，通過智慧合約更新交易資料，同時藉助共識的協作流程使網路中所有的節點保持一致。

這裡的交易可以指代任何資料，例如：數字貨幣，合同，記錄或者其它任何資訊。

區塊鏈的型別

• 公有鏈：網路中的節點可以任意接入，網路中資料讀寫許可權不受限制，所有節點都參與共識過程。比特幣，以太坊等數字貨幣都屬於公有鏈。

• 私有鏈：網路中的節點被一個組織控制，由其獨享該區塊鏈的寫入許可權，私有鏈和其他的分散式儲存沒有太大區別。

• 聯盟鏈：多個公司或組織通過授權接入，由某些節點參與共識過程。Hyperledger Fabric屬於聯盟鏈。

什麼是Hyperledger Fabric？

Hyperledger Fabric 是Linux基金會發起的Hyperledger專案之一。Hyperledger Fabric 專為在企業環境中使用而設計的開源的基於區塊鏈的分散式賬本。Hyperledger Fabric可用於全球供應鏈管理、金融交易、資產記賬、人力資源、保險、健康和數字音樂等領域。

Hyperledger Fabric中的賬本子系統(ledger)包括兩個元件： 世界觀( world state)和 事務日誌( transaction log)。世界觀記錄了賬本在特定時間點的現狀，是一個鍵值資料庫。交易日誌記錄產生世界狀態當前值的所有交易，是世界觀的更新歷史。賬本的世界觀的底層資料庫可以更換，可以選擇使用levelDB或couchDB。

Hyperledger Fabric是第一個支援以通用語言編寫智慧合約的區塊鏈平臺，可以使用java，nodejs和go語言來編寫智慧合約。Hyperledger Fabric中的智慧合約也叫鏈碼(chain code)。

和其他公有區塊鏈平臺最大的不同，Hyperledger Fabric 是私有的並且需要授權才能接入，它擁有一個 MSP( Membership Service Provider)模組專門提供成員管理服務。

CA(Certificate Authority)負責許可權管理，成員身份相關證照管理(Enrollment CertificateAuthority)和維護交易相關證照管理(Transaction Certificate Authority)等等。

Hyperledger Fabric提供了建立channel的功能，這允許參與者為交易新建一個單獨的賬本。當網路中的一些參與者是競爭對手時，這個功能變得尤為重要。因為這些參與者並不希望所有的交易資訊——比如提供給部分客戶的特定價格資訊——都對網路中所有參與者公開。只有在同一個channel中的參與者，才會擁有該channel中的賬本，而其他不在此channel中的參與者則看不到這個賬本。

Hyperledger Fabric使用獨立的排序節點(order)來提供共識服務，負責排序交易，提供全域性確認的交易順序。

應用程式通過SDK訪問Hyperledger Fabric。

最新版Hyperledger Fabric的設計中，根據功能將節點角色解耦開，讓不同節點處理不同型別的工作負載。從業務邏輯上又將節點分為背書節點(Endorser)和提交節點(Committer)。

• Endorser peer：負責對來自客戶端的交易進行合法性和許可權檢查（模擬交易），通 過檢查則簽名並返回結果給客戶端。

• Committer peer：負責維護賬本，將達成一致順序的批量交易結果進行狀態檢查，生成區塊，執行合法的交易，並寫入賬本，同一個物理節點可以同時擔任endorser和committer兩個角色。

Hyperledger Fabric 交易流程:共識

共識流程主要分Proposal，Packaging和Validation三個階段。

Proposal

應用提交一個交易proposal，然後將其提交給所有的背書節點，後者接到後，將其作為輸入執行鏈碼生成相應的交易proposal響應。此時並不會更新Ledger，而是對交易proposal 響應簽名，並將其返回給應用。應用收到簽名後的響應，共識流程的第一階段就完成了。

Packaging

這個階段是order節點對交易進行排序打包。Order節點從各個應用接收交易proposal響應，然後對這些交易進行排序，排序之後打包成區塊。

Validation

共識流程的最後一個階段，由order節點將區塊分發給所有和它連線的節點，這些節點將確認區塊中的交易都經過背書節點簽名，然後將確認後的區塊更新到ledger中。

整個流程稱為共識，所有節點都已對交易內容和順序達成一致，這一過程由order節點控制。 共識是一個多步驟的過程，只有在整個流程完成時才會更新賬本 ，可能每個節點的更新時間稍有不同。

Hyperledger Fabric Service on SAP Cloud Platform（一）

構建一個Hyperledger Fabric平臺絕非易事，既需要硬體基礎設施的投入，也需要全方位的開發和運營管理(DevOps)。除了平臺本身，一套完整的解決方案，還包括裝置接入，訪問控制，服務監控等管理功能。

SAP Cloud Platform(下文簡稱SCP)提供了開箱即用的Hyperledger Fabric Service，為開發者提供了強大的服務支援：

• 直觀友好的視覺化監控與操作介面，幫助開發者按需申請區塊鏈網路，建立管理節點、渠道，而無需考慮底層硬體資源。

• 簡單易用的智慧合約開發與測試環境，方便開發者對應用程式碼進行管理。

• 安全，隱私性方面的保障，並對相關資源進行了效能優化。

以上是我對Hyperledger Fabric的一些理解，接觸和了解區塊鏈的時間有限，難免存在一些錯誤，歡迎大家指正。後續會給大家帶來SAP雲平臺上Hyperledger Fabric開發的一些細節介紹。

主要參考文獻

• Hyperledger Fabric官網

  https://hyperledger-fabric.readthedocs.io/en/latest/whatis.html

• Hyperledger Fabric Service on SCP

  https://help.sap.com/viewer/p/HYPERLEDGER_FABRIC

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2215015/，如需轉載，請註明出處，否則將追究法律責任。