本文適合於熟悉開源區塊鏈技術Hyperledger Fabric，以及希望更高效地使用華為雲區塊鏈服務的讀者。當然，也歡迎任何對區塊鏈技術有興趣的讀者閱讀本文，相信讀者們都能從中受益。

2018年2月1日 華為雲釋出企業級區塊鏈開放平臺區塊鏈服務BCS（Blockchain Service），是基於開源區塊鏈技術和華為在分散式平行計算、資料管理、安全加密等核心技術領域多年積累基礎上推出的企業級區塊鏈雲服務產品,旨在幫助各行業、企業在華為雲上快速、高效的搭建企業級區塊鏈行業方案和應用。

如前所述，搭建區塊鏈不是目的，關鍵是要方便應用更高效地使用區塊鏈。本文要介紹的RESTFUL鏈碼呼叫API即是華為雲區塊鏈為此目的而開發的，在詳細介紹API之前，先對鏈程式碼做一下簡單介紹，便於沒有Fabric知識背景的讀者理解。

我們知道區塊鏈是一種由區塊串聯而成的鏈式結構，每一個區塊上都記錄著賬戶資料，這些資料一經寫入是不可篡改的。那麼資料是如何寫入的呢？如果讓擁有寫入許可權的使用者都能隨意寫入資料的話，區塊鏈也就失去了存在的意義，因此鏈程式碼概念的引入意義重大。鏈程式碼又被稱之為智慧合約，顧名思義就是向區塊鏈寫入資料的預先約定好的程式碼。它是一段邏輯，這個邏輯可以是簡單的限制和約束，也可以是非常複雜的業務相關的邏輯，根據使用者的輸入，進行邏輯的運算，最終得出向區塊鏈寫入的資料集合，然後將資料寫入到區塊鏈上去。如果這樣描述過於抽象的話，我們以一個賬戶轉賬的例子來進行說明。

如上圖所示，圖中右邊的區塊鏈記錄著原始賬戶的餘額，a為100元，b為200元。圖中左邊客戶端應用程式發起一筆轉賬交易：a向b轉x元。這筆交易不會直接寫入區塊鏈，而是先經過中間的鏈程式碼進行智慧合約的運算，檢查a的賬戶裡是否有足夠的餘額，然後才允許轉賬交易的進行，將最終的a、b賬戶的餘額寫入到最新的區塊鏈中。
整個交易過程以及鏈程式碼的作用其實非常淺顯易懂，但其實我們的應用程式向鏈程式碼發起呼叫的過程還是有些複雜的。因為區塊鏈的呼叫請求不同於普通的RPC遠端呼叫，客戶端需要有如下的事情：

1，將鏈程式碼的呼叫資訊如通道ID、鏈碼ID、呼叫引數、呼叫者資訊等進行打包,
2，將打包好的二進位制內容使用使用者私鑰進行簽名
3，根據鏈碼的背書策略不同，可能需要向多個組織的節點上的鏈碼發起呼叫

由此可見，這個呼叫過程如果讓客戶端自己來實現是不太現實的，因此需要藉助SDK的幫助來實現。目前根據客戶端的語言不同，SDK也有各種不同的語言版本，例如golang語言就有fabric-sdk-go的實現，javascript也有nodejs版本的SDK實現。我們先來看一下使用SDK需要的配置檔案以及使用SDK進行呼叫的示例程式碼片段：

上圖是一個200行的SDK配置檔案片段

這是一個nodejs版本的SDK使用示例。由此我們可以看出客戶端應用直接使用SDK的弊端：
1，配置檔案書寫複雜 雖然華為雲已經提供了SDK配置檔案下載功能，對於首次使用SDK的開發人員來說成本仍然很高。
2，SDK語言相關，並且學習成本高 雖然很多語言都提供了Fabric SDK，但是學習起來仍然有一定學習成本，並且不同語言的類庫名稱，方法名稱呼叫方式都各不相同，切換不同語言時的學習成本成倍增加。
3，SDK過於厚重 應用程式在使用SDK的時候需要將SDK類庫引入，雖然不用開發語言的SDK打包後大小各不相同，但對於一些薄客戶端（比如安卓或者IOS手機應用）來說仍然顯得十分厚重。
華為云為了方便開發者使用區塊鏈服務，在服務端提供了RESTFUL的API以克服上述直接使用SDK方式的不足：

如上面架構圖所示，華為雲區塊鏈服務直接暴露RESTFUL形式的API供開發者使用，在服務端封裝了對SDK的呼叫。因為華為雲替使用者管理著區塊鏈的組織結構以及各種證書，所以天然具備了所需要的SDK的配置檔案，不需要使用者自己手動生成。在此給出一個RESTFUL鏈碼呼叫請求的Header和Body的示例供讀者參考：
HEADER:
x-bcs-signature-sign: 1f8b08000000000000ff14cbb11503510c02b081d260c098bfff6279d74bb90a5ca7384e3cae9b5825af7cb076b65e039be41da8e8b1e38700d599fa4aee37d6c159a94355ada783dbb4d66e17e967db39cef36bcd0b5adc8be3e178698ef9070000ffff
BODY:
{
“channelId”: “testchannel”,
“chaincodeId”: “zmmcode”,
“chaincodeVersion”: “1.0”,
“userId”: “User1”,
“orgId”: “7258adda1803f4137eff4813e7aba323018200c5”,
“opmethod”: “invoke”,
“args”: “[“invoke”,“a”,“b”,“1”]”,
“timestamp”: “2018-10-31T17:28:16+08:00”,
“cert”: “-----BEGIN CERTIFICATE-----\nMIIDBzCCAq2gAwIBAgIQEXPZlMsReamxVtVNnKwCCzAKBggqhkjOPQQDAjCCAQQx\nDjAMBgNVBAYTBUNISU5BMRAwDgYDVQQIEwdCRUlKSU5HMRAwMwUQYD14eH+jTTBLMA4GA1Ud\nDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKAIFBXQ5TC4acFeTlT\nJuDZg62XkXCdnOfvbejSeKI2TXoIMAoGCCqGSM49BAMCA0gAMEUCIQCadHIKl0Mk\nYn0WZizyDZYR4rT2q0nzjFaiW+YfV5FBjAIgNalKUe3rIwXJvXORV4ZXurEua2Ag\nQmhcjRnVwPTjpTE=\n-----END CERTIFICATE-----\n”
}
看到這裡，讀者可能會對上面Header中的簽名以及Body中的cert證書資訊有所疑惑。請不要著急，在此先介紹一下華為雲區塊鏈RESTFUL介面的實現原理，讀者自然就能解除心中疑慮。

根據前文我們已經瞭解區塊鏈的呼叫和普通RPC的遠端呼叫最主要的區別在於需要有使用者簽名用於證明交易是指定使用者所發起的，那麼RESTFUL呼叫也不可避免這個問題。因此我們在使用華為雲區塊鏈RESTFUL介面時仍然需要使用使用者私鑰對整個請求訊息體進行簽名如圖中所示，簽名的結果放到HEADER中指定名稱下。這個簽名在服務端會使用使用者的公鑰進行驗證，驗證通過交易才能繼續。

在某些情況下，使用者的公私鑰對並不是華為雲區塊鏈服務管理的，而是使用者使用組織私鑰自行簽發的，這個時候服務端就缺少這個使用者的公私鑰，此時就需要在請求訊息體中使用cert欄位上傳使用者公鑰，服務端使用使用者上傳的公鑰驗證HEADER中的簽名是否是私鑰對訊息體的合法簽名。這時問題就來了，任何一個偽造者都可以自己製作一個非對稱的公私鑰對，然後對一個非法的訊息體進行私鑰簽名，並把公鑰放到訊息體中以通過服務端的驗籤。為了避免這個漏洞，服務端在驗籤之前會對使用者上傳的公鑰進行合法性驗證，如上圖。因為使用者上傳的公鑰實際上是一個證書，該證書包含了使用者公鑰以及組織私鑰對該證書的簽名，而偽造者缺少組織私鑰無法偽造簽名，這樣服務端就能判定使用者上傳證書的合法性。

當服務端使用合法的使用者證書驗證請求HEADER中的簽名是使用者私鑰的簽名後，服務端就可以真正發起區塊鏈鏈碼的呼叫了，這裡服務端使用SDK的方式與客戶端直接使用SDK的方式並無不同，只不過如果客戶端證書是自行簽發的，那麼服務端是沒有使用者私鑰的，這個時候就會使用組織的admin證書發起區塊鏈鏈碼的呼叫。
至此，RESTFUL的呼叫機制讀者也清楚了，那麼RESTFUL呼叫的優點也就很容易理解：

1.使用簡單方便，由華為雲區塊鏈服務封裝SDK的複雜性。

2. 由於絕大多數語言都已經擁有很成熟的RESTFUL呼叫類庫，呼叫RESTFUL基本沒有學習成本。
3. 不用引入SDK類庫，適合更輕量的客戶端。
   以上就是對華為雲區塊鏈RESTFUL鏈程式碼呼叫API的原理的詳細講述，目前RESTFUL介面還處於公測階段，歡迎讀者到華為雲進行免費體驗並提出寶貴意見。

參考資料：API參考

---

來源：CSDN
原文：https://blog.csdn.net/weixin_43682574/article/details/85077234
版權宣告：本文為博主原創文章，轉載請附上博文連結！