區塊鏈中的RESTFUL鏈碼調用API原理詳解

本文適合于熟悉開源區塊鏈技術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
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！