Hyperledger Fabric 構建版權管理系統研究

夏浩飛

（嘉興職業技術學院開放教育學院，浙江嘉興 314000）

0 引言

版權管理的核心內容是版權的確認、轉讓與查詢，即確權、用權與維權。集中式管理是目前版權管理的主要方式，但由于權力的集中，集中式的版權管理存在確權、用權效率低，費用高，舉證維權難度大、收益低等問題［1-2］。同時，在集中式版權管理模式中，版權數據由管理機構獨享，使得版權信息不夠透明，安全性、可靠性也存在一定隱患。另一方面，網絡作品數量呈指數級增長，對版權認定的效率和便捷度提出了更高要求，集中式的版權管理體系很難滿足該要求［3］。

區塊鏈技術依托分布式計算框架、可編程智能合約，具備系統集體維護、數據不可篡改且可追溯等技術特性，為版權管理系統建設提供了一種新的方式。文獻［4］認為區塊鏈技術是開辟版權登記新途徑、建立版權信任新機制、劃清版權利益分配途徑、創新版權商業模式的有效方式；文獻［5］提出可利用區塊鏈技術構建分布式的版權管理系統，以消弭集中式版權管理模式下因權力過度集中而產生的“俘獲”和“尋租”現象，從而有效降低版權登記、交易等環節的費用支出；文獻［6］闡述了借助區塊鏈智能合約技術，可降低當事人履約成本，提高版權交易運作效率與履約率；文獻［7-8］提出區塊鏈的鏈式結構、時間戳及數據不可篡改等技術特性可以簡化舉證程序，為確定版權歸屬提供依據，從而在根源上對版權進行保護，解決集中式版權管理存在的舉證難度大、收益低等問題，維護權益人的利益。

目前，針對區塊鏈技術在版權管理領域應用的研究文獻研究側重點大多集中在理論層面，對于區塊鏈技術在版權管理領域的落地應用研究不多。本文在借鑒上述文獻研究成果的基礎上，以Hyperledger Fabric 為核心技術，架構了基于聯盟區塊鏈的分布式版權管理系統，并進行了系統設計與實現，致力于推進區塊鏈技術在版權管理領域的落地應用。

1 技術框架

1.1 區塊鏈分類及技術特征

區塊鏈按照開放程度不同，分為公有鏈、私有鏈和聯盟鏈。公有鏈是一種完全去中心化的區塊鏈，任何客戶端都可接入公有區塊鏈網絡，其優點是開放程度高、隱私性好，且數據難以篡改，如比特幣［9］和以太坊［10］等。但公有鏈也存在一定問題，如完全的匿名機制必然會導致交易監管的缺失，而高度的開放性使得公有鏈規模高速膨脹，這勢必會降低系統的共識效率，從而限制其應用場景。公有鏈是一種理想的數字貨幣架構技術，但并不適用于版權管理系統建設。私有鏈是一個較為封閉的區塊鏈系統，鏈上數據的更新掌握在某個機構手中，訪問權限嚴格，優點是交易速度快、成本低。但鑒于其開放程度過低，私有鏈的應用場景和應用價值不高，如典型的私有鏈multichain［11］等。聯盟鏈是一種介于公有鏈與私有鏈之間的區塊鏈網絡，也是由多個組織共同建設、維護與使用的區塊鏈網絡，如Hyperledger Fabric［12］和R3 Corda［13］等。聯盟鏈通過內部選舉，預設節點完成區塊數據的共識，大幅提高了系統共識效率，其分布式數據存儲機制和區塊鏈數據庫保證了數據的安全性及可追溯性，并利用權限訪問機制保障了交易監管的有效實施。基于聯盟鏈技術架構的分布式版權管理系統既能保證版權管理系統的確權、用權效率，又能保障版權數據的安全、可信，提升版權信息的透明度，版權數據的舉證維權過程也變得簡單、便捷，且系統運行是可監管的。

1.2 Hyperledger Fabric 概述

Hyperledger 項目是Linux 基金會主導的開源項目，旨在以分布式記賬和共識機制為核心建立一個跨行業的企業間生態圈［14］。Fabric 是Hyperledger 最早孵化、參與成員最多的子項目，其架構主要包括訪問控制模塊、區塊鏈網絡、鏈上代碼和賬本4 部分，如圖1 所示。

Fig.1 Fabric framework圖1 Fabric 框架

1.2.1 訪問控制模塊

Hyperledger Fabric 采用PKI 體系實現用戶密鑰與證書管理，Fabric-CA［15］是專門的用戶權限訪問控制模塊，也是獨立于Fabric 系統的可插拔模塊。Fabric 系統用戶的注冊過程包括register 和enroll 兩個步驟，如圖2 所示。首先，管理員需要在CA 中登記，登記完成的管理員接收用戶的注冊請求，管理員在獲取到用戶注冊的身份信息后，把新用戶信息register 到CA 中；然后，CA 返回給用戶一個enroll 密碼，用戶使用此密碼進行enroll 操作，CA 給完成enroll 操作的用戶發放簽名秘鑰對和身份證書。秘鑰對和身份證書是用戶登錄Fabric 網絡、發起交易操作的憑證。

Fig.2 User registration process of Fabric圖2 Fabric 用戶注冊過程

1.2.2 區塊鏈網絡

交易［16］是Fabric 運行的核心機制，區塊鏈網絡是處理交易的主體模塊。為保證交易的私密性，Fabric 基于Docker 容器運行，采用通道機制，各通道之間相互隔離，用戶可根據自身需求加入不同的業務通道。每個通道包含若干組織（org），每個組織則由若干節點（peer）組成，并設有各自的CA 服務。排序服務節點（Orderer）負責管理通道中生成的交易。通道結構如圖3 所示。

Fig.3 Channel organization structure of Fabric圖3 Fabric 通道組織架構

背書、排序與記賬是交易的主要過程。背書由組織的背書節點實施，背書策略［17］決定哪些組織的哪些節點參與背書，只有符合背書策略要求并獲得相應背書節點簽名的交易才是有效交易。記賬是交易數據寫入各記賬節點賬本的過程，排序的任務是確保采用異步通訊機制的區塊鏈網絡中各節點記賬數據的一致性。

1.2.3 鏈碼

鏈碼包括系統鏈碼和用戶鏈碼。系統鏈碼是Fabric 的特定功能模塊，負責如鏈碼管理、通道配置、交易背書與驗證等［18］。用戶鏈碼是實現用戶設定功能的程序塊，其基于Docker 容器安裝并需要進行實例化，運行在網絡節點上，支持Golang、Node.js、Python 等多種語言。

1.2.4 賬本

Hyperledger Fabric 賬本由區塊賬本（blockchain）和狀態數據庫（world state）兩部分構成。區塊賬本存儲交易過程產生的區塊信息，且不可修改，保證了交易過程的可追溯性；狀態數據庫以key-value 形式存儲系統數據，可以修改與刪除，狀態數據庫的引入方便了數據處理。

2 版權管理系統架構

基于Hyperledger Fabric 的版權管理系統采用MVC（Model-View-Controller）架構模式。Model 是處理版權交易的區塊鏈網絡，也是實現版權登記、轉讓等交易過程的核心模塊；View 是面向用戶的Web 界面，接收用戶的版權登記、轉讓、查詢申請及注冊登錄請求；控制器Controller 利用Fabric SDK Go 提供的功能接口，實現用戶與區塊鏈網絡的交互，如發起交易、調用鏈碼、驗證交易數據等，同時也負責處理頁面數據和系統運行邏輯。用戶界面和控制器組成了版權管理系統的前端應用程序，Fabric-CA 負責版權系統用戶的身份管理。基于Fabric 的版權管理系統架構如圖4 所示。

Fig.4 Architecture of copyright management system based on Fabric圖4 基于Fabric 的版權管理系統架構

2.1 版權登記

版權登記是指向Fabric 賬本中寫入數據的過程，控制器在獲取到用戶層提交的版權登記請求與登記數據后，構造交易提案并向區塊鏈網絡發起版權登記交易，區塊鏈網絡經過背書、排序、記賬幾個重要環節，將符合條件的版權登記數據寫入系統賬本，登記結果由控制層返回給用戶。系統版權登記流程如圖5 所示。

Fig.5 Flow of copyright registration圖5 版權登記流程

2.1.1 構造版權登記交易提案

登錄版權管理系統的用戶在版權登記頁面輸入需要登記版權作品的相關信息，包括作品名稱、類別、作者、著作權人等，同時提交作品文件，發起登記請求。控制器在接收到用戶提交的版權登記請求后，根據當前日期結合計數器生成版權編號，將當前日期設為版權登記時間。控制器使用用戶私鑰對版權登記信息進行簽名，同時附上用戶身份證書，確定交易調用的鏈碼號、交易提案參數以及使用的通道ID 等信息，并生成交易編號，打包形成版權登記交易提案，按照制定的背書策略向區塊鏈網絡中指定的背書節點提交版權登記提案。版權登記交易提案數據結構如圖6 所示。

2.1.2 版權登記交易處理

相關背書節點在收到版權登記交易提案后，驗證提案的簽名是否有效、調用者是否有寫賬本權限，并檢驗交易格式以及交易是否提交過。驗證通過后，背書節點根據交易提案中的鏈碼號及提案參數指定的鏈碼方法，模擬執行版權登記交易提案，生成版權登記結果的讀寫集，并對讀寫集進行背書簽名。模擬執行結果形成提案響應proposal-Response，發回給控制器。proposalResponse 的主要內容包括返回狀態值status、返回消息message、相應讀寫集與節點背書簽名等。

Fig.6 Data structure of copyright registration transaction proposal圖6 版權登記交易提案數據結構

控制器在接收到發回的交易提案模擬執行結果后，根據背書策略，驗證是否收到滿足條件的背書數量和背書簽名，以及背書結果是否一致。若檢驗通過，則生成正式交易。正式交易的內容包括交易提案、提案響應值、背書結果及簽名等，由控制器提交至排序節點。

2.1.3 排序與記賬

排序服務節點按照收到交易的時間順序完成交易排序，并將這一時間段內收到的交易生成一個區塊，交付至記賬節點。記賬節點在記賬前，首先驗證區塊內交易的有效性，包括交易格式、簽名有效性等，接著記賬節點會調用VSCC（Validator System ChainCode）鏈碼驗證版權登記交易的合法性和背書的有效性，最后對讀寫集數據進行多版本并發控制MVCC（Multi-Version Concurrency Control）檢查，以避免寫入臟數據。記賬節點將通過驗證的區塊作為新區塊寫入區塊賬本，同時更新狀態數據庫，實現版權信息登記，并以消息廣播的方式確保各節點賬本數據的同步。

2.2 版權轉讓

現版權所有者在版權轉讓界面輸入版權轉讓相關信息，包括版權編號、版權受讓人，提交版權轉讓請求。控制器接收到版權轉讓請求和相關參數后，發起版權轉讓交易。版權轉讓與版權登記流程基本相同，區別在于版權登記是一個數據寫入過程，而版權轉讓則是數據更新過程。背書節點在收到版權轉讓背書請求后，依照提案參數中的版權編號從狀態數據庫中讀取指定的版權記錄數據，更改版權記錄中的版權人字段信息，把更新后的版權記錄數據寫回狀態數據庫，并更新狀態數據庫中版權數據的版本號。如ZShan 的某項版權記錄數據為［key：001，value：［cprID：001，cprOwner：ZShan，……］，version：0］，版權轉讓給LSi后，版權記錄的版權人字段信息由ZShan 變更為LSi，同時版權記錄的版本號也會更新，更新后的版權記錄數據為［key：001，value：［cprID：001，cprOwner：LSi，……］，version：1］。

2.3 版權查詢

用戶在查詢頁面輸入版權編號，控制器構造版權查詢交易提案，提案經過背書節點執行后，模擬執行結果返回給控制器。因為不涉及數據寫入或更新，區塊鏈網絡不會生成交易，控制器把模擬執行結果返回客戶端，即完成版權查詢操作。

2.4 版權交易追溯

版權交易追溯是版權認定的關鍵。版權追溯與版權查詢的區別在于：版權查詢讀取的是狀態數據庫的數據，鑒于狀態數據庫的易修改性，其舉證效力一般；版權追溯則讀取區塊賬本數據，區塊賬本的不可修改特性使得追溯得到的版權交易數據更具舉證效力。Fabric 提供了兩種查詢歷史交易的方法：一是通過系統鏈碼QSCC，QSCC 提供了按區塊號獲取區塊數據、按交易號獲取交易數據或區塊數據等交易內容查詢方式；二是通過Fabric 提供的GetHistoryForKey（）方法查詢指定鍵的歷史交易。版權管理系統采用GetHistoryForKey（）方法實現版權追溯。

3 模擬實驗

3.1 實驗環境

在ubuntu16.04 系統上搭建實驗環境，Fabric 采用1.0版本，其他的主要軟件及版本為：Docker version 19.03.12，Docker-compose version 1.24.1，Go version 1.13.4。

3.2 版權管理區塊鏈網絡架構

架構2 個背書節點、1 個排序服務節點與1 個CA 服務節點組成的區塊鏈網絡，2 個背書節點模擬版權管理組織的2 個成員，版權登記、轉讓交易可在任意一個節點提交，背書節點兼記賬節點。背書策略設計為版權處理交易至少需得到除發起交易節點成員外另一個節點成員的背書簽名。排序算法使用solo，狀態數據庫使用couchDB。Fabric 各網絡服務對應的模擬對象如表1 所示。

Table 1 Simulation object corresponding to Fabric network service表1 Fabric 網絡服務對應的模擬對象

3.3 身份管理

實驗采用cryptogen 工具模擬CA 生成管理員用戶和普通用戶的身份證書、簽名秘鑰對及通訊證書，系統模擬用戶user1 的證書及秘鑰截圖如圖7 所示。系統模擬用戶user1 直接寫入main.go 文件，作為版權管理系統的測試用戶，并在應用程序客戶端創建過程中指定user1 用戶，以簡化用戶注冊登錄過程。

Fig.7 Certificate and secret key of user1圖7 user1 證書及秘鑰

3.4 版權數據結構設計

版權記錄設計為結構體類型，名稱為cprRecord，數據格式如下：

版權數據寫入過程以版權編號CprID 為key 值，版權記錄cprRecord 的前7 個字段內容為value 值，調用系統函數PutState（key，value）實現。版權數據讀取過程以CprID 為key 值，調用系統函數GetState（key）實現。Historys 用于版權數據追溯，Historys 的每條記錄由TxId 和cprRecord 構成。

3.5 版權管理鏈碼

版權管理鏈碼文件命名為bqglcc.go，主要功能函數為createCpr（）、transferCpr（）、readCpr（）和traceCpr（），分別實現版權數據的登記、轉讓、查詢與追溯。4 個函數算法的主要部分如下：

3.6 實驗結果

版權管理系統啟動過程主要包括以下步驟：①編譯版權管理系統項目，生成可執行的版權管理系統文件；②啟動版權管理系統運行依賴的Fabric 區塊鏈網絡；③初始化Fabric SDK Go；④創建通道，將版權管理節點加入通道；⑤完成版權管理鏈碼的安裝與實例化；⑥創建通道客戶端；⑦啟動Web 服務。版權管理系統啟動過程如圖8 所示。

Fig.8 Startup process of copyright management system圖8 版權管理系統啟動過程

版權管理系統啟動完成后，用戶便可通過瀏覽器實現版權的登記、轉讓等操作。

（1）版權登記。由于用戶信息user1 已在客戶端創建過程中指定，user1 用戶可直接在版權登記界面輸入需要登記的版權信息，提交版權登記請求，如圖9 所示。登記交易提案由版權管理系統的peer0.org1.bqgl 節點發送至區塊鏈網絡，區塊鏈網絡的peer1.org1.bqgl 節點進行背書，然后經過排序、記賬后，登記結果信息通過瀏覽器頁面返回給用戶。版權登記交易成功反饋界面如圖10 所示。

Fig.9 Interface of copyright registration information input圖9 版權登記信息輸入界面

Fig.10 Feedback interface of successful copyright registration transaction圖10 版權登記交易成功反饋界面

（2）版權查詢。用戶在查詢界面輸入版權編號信息，提交即可。登記成功后版權編號為202102100001 的版權信息查詢結果如圖11 所示。

Fig.11 Feedback interface of copyright information query圖11 版權信息查詢結果

（3）版權轉讓。用戶在版權轉讓界面輸入版權編號202102100001 和轉讓相對人user2，提交版權轉讓請求。系統提示交易成功后，再次以版權編號202102100001 為參數進行版權查詢，編號為202102100001 的版權記錄的版權人變更為user2。

（4）版權追溯。用戶在版權追溯界面輸入版權編號202102100001，提交追溯請求。系統通過查找鍵值為版權編號202102100001 的歷史交易記錄，實現追溯并返回結果，如圖12 所示。

Fig.12 Results of transaction trace圖12 交易記錄追溯結果

由圖12 可以看出，編號為202102100001 的版權記錄經歷過兩次交易：第一次交易即版權登記交易，其交易編號與圖10 中版權登記交易成功的交易編號一致；第二次交易是版權轉讓交易，從第二次交易的版權數據記錄中可看到版權人已從user1 變更為user2。

3.7 性能測試

系統性能測試通過設置多用戶并發條件模擬生產環境，檢驗系統在實際應用中的運行穩定性和運行效率。測試利用loadrunner11 負載測試工具獲取系統版權數據登記、查詢、轉讓與追溯4 個主要事務的用戶響應率和響應時間。測試客戶端的軟硬件配置如下：CPU 為Inte（lR）core（TM）i3-4130，3.40GHz；RAM 為4.00GB；OS 為Windows7，32 位；瀏覽器為IE8。

測試采用錄制方式抓取版權登記、查詢、轉讓、追溯4個事務的執行腳本，對各腳本分別進行并發測試，設置迭代次數為1 次，并發用戶數為30，忽略用戶思考時間。測試結果如表2 所示。由測試結果可以看出，在多用戶環境下系統能夠保持穩定運行，4 個主要事務中，版權查詢效率表現良好，登記、轉讓、追溯事務響應速度較查詢事務偏慢，但總體仍在可接受范圍內。

Table 2 Test results of system’s main transactions表2 系統主要事務性能測試結果

4 結語

本文以Hyperledger Fabric 技術框架為核心，架構并模擬實現了一個簡單的基于區塊鏈網絡的版權管理系統，實現了區塊鏈上版權信息的登記、轉讓、查詢與追溯管理。分布式的版權數據存儲模式不僅保障了版權數據的可靠性，而且提高了版權數據的透明度，使權力人能夠更好地擁有自己的版權數據。同時，借助區塊賬本不可修改的特性，版權數據的追溯取證更具效力。基于區塊鏈的版權管理系統為“互聯網+”時代的版權管理提供了一種新思路。Hyperledger Fabric 項目較為復雜，且孵化時間較短，項目成熟度不夠，項目的登記、交易兩級證書系統［19］與PBFT 共識算法等模塊至今仍未發布，可借鑒的應用實例也不多。本文設計的版權管理系統還存在不足，特別是在用戶身份管理與共識算法實現兩方面與實際應用還有一定距離，將在后續研究中不斷改進完善。