摘要：在她的幫助下，原型發布順利完成。節點收到一個交易后，會根據判斷標準對該交易進行有效性校驗，無效的交易會被廢棄。負責權限管理，成員身份相關證書管理和維護交易相關證書管理等等。

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

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

比如Jerry了解到的Javascript 3D渲染，增強現實(Argument?Reality)和這篇文章談到的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 是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兩個角色。

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

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

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

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

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

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

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

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

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

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

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

主要參考文獻

Hyperledger Fabric官網

https://hyperledger-fabric.re...

Hyperledger Fabric Service on SCP

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

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