夏浩飛 陳界譽
1(嘉興職業技術學院開放教育學院 浙江 嘉興 314000)2(嘉興職業技術學院科研處 浙江 嘉興 314000)
確權、用權、維權是著作權管理的主要內容,互聯網+時代,數字資源規模迅速膨脹,復制速度快,抄襲方便,由此造成的侵權問題層出不窮,中心化的著作權登記、交易、認證管理模式成本高、效率低,已很難應對數量如此龐大的著作權管理需求,利用分布式存儲框架及計算技術來實現著作權數據的管理,簡化登記、交易等流程,提高管理效率,具有研究價值。
公有鏈和聯盟鏈是兩種重要的分布式存儲技術,文獻[1-3]借助公有鏈的多點共識機制、交易不可篡改、可追溯等特性,提出基于分布式框架技術的著作權管控模型及監督機制,降低數字著作權登記的門檻,增強著作權認證的權威。文獻[4-6]進行了基于公有鏈的數字著作權登記、交互與存儲模型研究,闡述了分布式存儲技術在著作權確權、用權和維權方面的應用構思。基于公有鏈技術架構的著作權管理系統可以較好地解決中心化管理存在的問題,但對系統交易的監管難以實現,而聯盟鏈可以在保留交易不可篡改、可追溯、多點共識機制等特性的基礎上,通過加入用戶認證體系來有效地實現分布式系統的監管難問題。文獻[7]以聯盟鏈形式構建了一種具備安全認證和訪問控制功能的分布式醫療數據存儲和管理系統,既保證患者的數據隱私,又滿足聯盟成員之間醫療數據的共享需求。文獻[8]利用聯盟鏈的分布式存儲、共識機制、智能合約、加密算法等功能,搭建智能電網數據處理平臺,旨在打造一個智能電網數據優化的新型生態模式。另外,聯盟鏈框架技術在教育數據存證、農產品數據分布式存儲體系建設等領域也有應用[9-10]。
本文依托Hyperledger Fabric技術框架,構建了一種具有分布式存儲和計算特征的著作權管理系統,并基于fabric鏡像文件、docker容器、node sdk等技術模擬實現了該系統,實驗結果表明,基于Hyperledger Fabric的分布式著作權管理系統能夠有效地管理著作權數據,記錄數據的流轉過程,在保障著作權人權益同時,簡化著作權的登記確認、交易變更、舉證維權等重要環節。
超級賬本(Hyperledger)項目以聯盟鏈形式構建一個分布式的數據存儲與處理系統,系統數據由聯盟成員通過背書、排序等機制共建共管,是一種全新的數據架構與處理技術[11],其成員管理服務和證書系統[12],在保證交易匿名的同時,實現了交易的可監管性,大幅拓展該技術的應用領域。
Fabric是Hyperledger最重要的子項目之一,以相互隔離的通道方式運行,由此保證聯盟成員數據的安全和隱私,用戶通過應用程序向CA注冊并登記身份,憑借身份證書登錄Fabric網絡,發起交易提案,交易在經過Fabric網絡的模擬執行、背書簽名、排序處理后,打包生成區塊并在網絡節點完成區塊記賬,同時更新狀態賬本[13]。圖1為Fabric運行流程。

圖1 Fabric運行流程
應用程序是用戶訪問Fabric網絡的接口,用戶把交易提案及相關參數輸入至應用程序,應用程序在收到交易提案及相關參數后,根據鏈碼實例化過程中指定的背書策略,將其發送至Fabric網絡的相關背書節點,背書節點模擬執行交易,執行結果發回給應用程序。應用程序檢驗各背書節點的背書結果是否一致,背書簽名是否符合背書策略,若符合條件,則打包執行結果,包括讀寫集、簽名、通道號等信息,形成正式交易,發送至排序節點,否則標記交易為無效交易。
Fabric網絡的主體為背書節點、記賬節點和排序節點,主要任務是完成交易的模擬執行、背書簽名、排序和數據存儲。
背書節點在接收到應用程序發送的交易提案后,檢查交易是否完好,是否已提交過,驗證交易簽名和用戶權限。交易提案通過,則根據提案調用的鏈碼名稱、鏈碼方法及傳入的參數模擬執行提案并簽名,把讀寫集等執行結果和背書簽名數據一起發回給應用程序;若交易提案未通過檢驗,則標記交易不合法,拒絕背書。
排序模塊接收某一時間段內應用程序發送過來的所有交易,采用設定的排序算法對交易進行排序,并依據區塊生成規則,把這一時間段內生成并排序完成的交易打包成區塊,交付給記賬節點。
記賬節點負責賬本數據的存儲,網絡中的節點一般都是記賬節點。區塊數據由排序節點交付給記賬節點,記賬節點校驗每筆交易的合法性,包括背書簽名是否正確、背書策略是否滿足、讀寫集是否有效等。記賬節點校驗通過,更新區塊文件和狀態賬本,并將記賬結果告知應用程序;否則,標記交易無效,不更新狀態賬本。
身份管理模塊由Fabric-CA負責,應用程序用enroll命令登記CA配置文件中的admin身份,其他用戶身份經由admin進行注冊、登記,CA向登記成功的用戶頒發身份證書、簽名密鑰。身份證書是用戶登錄Fabric網絡的憑證,私鑰用于交易簽名,以此確保交易的可追溯和可監管。
鏈碼是組成交易的一組功能代碼,Fabric提供go和node兩種鏈碼設計語言,鏈碼在Fabric網絡完成安裝和實例化之后,由應用程序根據用戶需求調用鏈碼功能函數,調用接口有query()和invoke(),query方法僅僅是對狀態數據的一次讀取,不產生交易和區塊,invoke方法根據交易流程實現功能。
鏈碼調用除在應用程序端以命令行方式實現外,更多是采用sdk方式,fabric-node-sdk是Hyperledger項目較為成熟的生態之一,用于提供客戶端與Fabric網絡交互的功能模塊框架。
鏈碼經過安裝和實例化兩個環節,部署在指定的peer節點上,在鏈碼實例化過程中指定Fabric網絡的背書策略,背書策略用于確定有效的鏈碼執行必須得到的背書簽名組合,由Fabric系統鏈碼VSCC(Validation System Chaincode)進行驗證[14],參與背書策略的角色可以是組織內的admin、client用戶或者peer節點。
賬本是Fabric網絡的數據存儲媒介,主要由區塊賬本和狀態賬本組成,前者用于存儲交易區塊,后者負責記錄交易數據的最終狀態。
區塊賬本采用aufs文件系統,文件格式為pb(Protocol Buffer),區塊文件由header、data和metadata三部分組成,header由當前區塊交易的hash值data_hash、當前區塊編號number和前一區塊hash值previous_hash組成,data包含當前區塊的交易內容,metadata為一組加密的數據,主要記錄交易的簽名、合法性、有效性等標簽。
狀態賬本存儲著系統業務數據的最新狀態,數據的讀取與更新依托讀寫集完成,讀寫集主要數據結構為Reads[]*KVRead和Writes[]*KVWrite,Reads[]字段包括鍵值和版本號[Key:string,Version:*Version],Writes[]字段包括鍵值、數據值和刪除標記[Key:string,Value:string,IsDelete:bool]。在fabric1.0中,取當前區塊的高度作為版本號version的值。除此之外,狀態賬本還存儲著通道、鏈碼及其生命周期管理方法LSCC(Lifecycle System Chaincode)創建及更新的數據信息。
著作權管理系統設兩個組織org1和org2,其下各設兩個peer節點,分配ubuntu虛擬機的7051、8051、9051、10051端口,節點名稱為:peer0.org1、peer1.org1、peer0.org2和peer1.org2,其中peer0.org1和peer0.org2為各自組織的主節點和錨節點,主節點負責與排序服務通信,錨節點負責組織之間的通信與同步信息,通信使用的TLS證書利用Fabric的cryptogen工具生成,4個peer節點均為記賬節點。
org1、org2模擬兩個著作權管理機構,其下的兩個peer節點模擬著作權管理機構的成員,各成員通過自己維護的peer節點連入著作權管理Fabric網絡,實現客戶端與Fabric網絡的交互。
排序模塊選擇Fabric的主流排序算法kafka,設置兩個排序節點orderer0和orderer1,每個排序節點設置4個kafka服務,kafka0-kafka3,每個kafka設置3個zookeeper服務,zookeeper0-zookeeper2。圖2為著作權管理系統Fabric網絡架構。

圖2 著作權管理系統Fabric網絡
系統利用fabric-tools鏡像創建cli服務模擬應用程序,通過cli結合shell腳本方式實現系統通道的創建,節點的加入,鏈碼的安裝、實例化及背書策略配置。系統的背書策略設置為“AND(Org1MSP.member,Org2MSP.member)”,即有效的鏈碼執行必須同時得到兩個組織中至少一名成員的簽名。
鏈碼實現著作權的登記、交易和查詢功能。著作權數據結構采用.json格式,簡要設計如表1所示。

表1 著作權數據結構表
記錄格式為[{“Key”:“*”,“value”:{“registerNum”:“*”,“Author”:“*”,“copyrightOwner”:“*”,…}}],以couchDb作為數據記錄存儲媒介。
鏈碼命名cc_copyRight,設計register_copyRight()、transaction_copyRight()和query_copyRight()三個功能函數,分別實現著作權的登記、交易和查詢,算法1為鏈碼主要流程。
算法1cc_copyRight鏈碼主要流程
2. if Function=register_copyRight() 跳轉至3
else If Function=transaction_copyRight() 跳轉至4
else If Function=query_copyRight() 跳轉至5
else 返回錯誤提示“鏈碼方法不合法”
3. if Parameters is invalid 返回錯誤提示“參數不合法”
else 著作權記錄record=json.Marshal (Parameters)
where τ is the scattering time, e is the electron charge, μ is the electron mobility, ε0 is the vacuum permittivity, m* is the effective electron mass, and N is the carrier (electron/hole) concentration. The real and imaginary parts of the permittivity are given by:
APIstub.PutState方法生成record的key-value讀寫集
返回成功執行提示
4. if Parameters is invalid 返回錯誤提示“參數不合法”
else APIstub.GetState(key:Parameters.registerNum)讀取交易的著作權記錄record
重寫record.copyrightOwner=Parameters. copyrightOwner
APIstub.PutState方法生成修改后著作權記錄record的key-value寫集
返回成功執行提示
5. if Parameters is invalid 返回錯誤提示“參數不合法”
else record=APIstub.GetState(key:Parameters.registerNum)讀取符合條件的著作權記錄
返回record
身份注冊登記功能主要依賴CA服務端的fabric-ca-server和客戶端的fabric-ca-client模塊,在CA服務配置文件中設置引導身份admin,利用sdk登記CA配置文件中設定的admin用戶,其他普通用戶通過激活的admin用戶實現注冊和登記,圖3為普通用戶注冊登記過程。

圖3 普通用戶注冊登記過程
系統同樣以sdk方式實現交易流程,用戶登錄系統提交著作權數據憑證,包括處理方法和著作權數據,客戶端sdk根據憑證創建交易提案并用提交交易用戶的私鑰完成交易提案簽名后,發送至背書策略指定的背書節點處理,背書節點的處理過程不僅是對著作權憑證的處理和簽名過程,也是鏈上著作權管理聯盟各組織成員對著作權憑證的認可,sdk對著作權憑證處理結果返回值進行一致性檢驗和背書策略驗證,是著作權管理組織成員對著作權憑證處理的意見是否一致,是否符合預先設定的著作權處理規則的確認過程。通過驗證的著作權處理結果由sdk形成正式交易并提交給排序節點orderer,同時,在peer節點注冊交易監聽事件,監聽交易完成情況,交易經過排序處理和記賬節點的再次檢驗無誤后,被寫入到聯盟組織成員各自的賬本中,sdk在接收到排序服務所提交的交易成功返回值和監聽事件鏈碼調用成功的回調函數后,確認交易成功。排序機制和交易監聽事件確保了各組織成員賬本的同步。圖4為著作權管理交易流程。

圖4 著作權管理交易流程
著作權管理系統選擇ubuntu平臺,基于docker容器和docker-compose工具部署Fabric網絡,使用shell腳本管理Fabric網絡,安裝、實例化cc_copyRight鏈碼,系統使用Fabric1.0版本鏡像文件。
1) Fabric網絡部署。應用Fabric包提供的通道配置程序configtxgen和通道配置文件configtx.yaml生成創世區塊genesis.block和創建通道依賴的文件channel.tx,生成組織的錨節點更新依賴的文件Org1MSPanchors.tx和Org2MSPanchors.tx。
編寫docker-compose-copyRight.yaml配置Fabric網絡,編寫shell腳本start_copyRight_fabric.sh啟動Fabric網絡和安裝鏈碼。
(1) 啟動Fabric網絡。使用docker-compose up命令執行Fabric網絡配置文件docker-compose-copyRight.yaml,生成對應的docker容器,啟動Fabric網絡的各項服務和4個節點。Fabric網絡啟動后,使用channel create命令在peer0.org1節點創建通道mychannel,其他三個peer節點依次加入mychannel通道,并更新組織的錨節點。
(2) 安裝鏈碼。使用peer chaincode install命令把著作權管理鏈碼cc_copyRight安裝至peer0.org1和peer0.org2節點,使用peer chaincode instantiate命令實例化鏈碼,鏈碼實例化成功后,安裝鏈碼的節點會生成相應的鏈碼鏡像文件,如圖5所示,在鏈碼實例化過程中指定系統的背書策略。完成鏈碼實例化的各peer節點處于消息偵聽狀態,等待應用程序的交易提案。

圖5 鏈碼鏡像截圖
2) 身份注冊登記。利用npm install下載fabric-ca-client 的node sdk包,編寫并運行admin.js文件,完成CA服務上配置的admin用戶的登記(enroll),編寫并運行User.js完成普通用戶xiahaofei的注冊和登記,圖6為用戶注冊登記成功截圖。

圖6 用戶注冊登記成功截圖
3) 鏈碼設計與調用。編寫register_copyRight.js實現著作權登記功能,算法2為其主要流程。
算法2register_copyRight.js主要流程
1. getRegisteredUsers獲取xiahaofei的證書和密鑰
2. 創建xiahaofei簽名的交易提案request={
chaincodeId:‘cc_copyRight’,
fcn:‘register_copyRight()’,
args:[‘registerNum’,‘Author’,‘copyrightOwner’,…],
ChainId:‘channelID’,
txId:‘transactionID’}
3. 選擇背書節點request.targets=peer0.org1&peer0.org2
4. 發送交易提案request給peer0.org1&peer0.org2
5. 獲取背書返回值proposalResponses[i]
6. 逐個驗證背書返回值proposalResponses[i]的有效性
7. if (proposalResponses[i] is all good)封裝正式交易請求
request={proposalResponses: proposalResponses,
proposal: proposal}
8. eventhub.registerTxEvent (txId) 注冊交易監聽事件
9. 發送正式交易request to orderer
10. 獲取orderer返回值txPromise
獲取監聽事件返回值eventPromise
11. if (txPromise&eventPromise) 提示客戶端交易成功
編寫transaction_copyRight.js實現著作權交易功能,執行流程與register_copyRight.js基本一致,區別為交易提案request中的fcn、args不同。
request={
fcn: transaction_copyRight(),
args:[ ‘registerNum’, ‘copyrightOwner’],
…
}
registerNum識別交易著作權記錄,copyrightOwner用于重寫著作權人。
編寫query_copyRight.js實現著作權記錄的查詢,返回符合條件的著作權記錄給客戶端,交易提案為:
request={…,
fcn: query_copyRight(),
args:[ ‘registerNum’],
…
}
查詢sdk和注冊、登記sdk一樣,統一使用fabric的invoke()接口,由于是查詢交易,不需要更新狀態賬本,所以sdk在收到模擬執行的交易提案返回值后,僅向客戶端反饋查詢結果,同時標記交易為無效交易,不提交給排序節點,但寫入區塊文件。
鏈碼在ubuntu命令行下使用node調用,如調用著作權登記sdk命令為:node register_copyRight.js。
1) 鏈碼執行結果。docker-compose-copyRight.yaml配置文件中cli連接的默認節點為peer0.org1,以上著作權登記、交易和查詢操作均在peer0.org1節點上執行,圖7為register_copyRight.js執行結果。

圖7 著作權登記執行結果截圖
分析執行過程:
(1) 客戶端sdk(register_copyRight.js)獲取著作權登記用戶的私鑰和簽名證書,成功,顯示信息“Load privateKey and signedCert”。
(2) sdk給創建的交易提案(proposal)簽名,為其分配交易編號transaction_id,然后根據設定的背書策略,向背書節點提交著作權登記交易提案。
(3) sdk逐個檢驗背書節點處理交易的返回值ProposalResponse,通過,顯示信息“Transaciton proposal was good”。
(4) 全部背書結果有效性、一致性檢驗和背書策略驗證通過,顯示信息“Successfully send Proposal and received ProposalResponse:state-200,message-“””。
(5) 交易監聽器確認交易提交完成,顯示信息“The transaction has been committed on peer localhost:7053”,7053為監聽器所使用的端口。
(6) sdk收到交易提交成功和監聽事件成功反饋,顯示信息“Send transaction promise and event listner promise have completed”。
(7) sdk通知客戶端交易成功,記賬完成。
query_copyRight.js的執行,不改變賬本狀態,僅調用鏈碼的query_copyRight()方法獲取狀態賬本中符合查詢條件的著作權記錄,把其value值返回給客戶端,圖8為query_copyRight.js執行結果(參數registerNum: “copyRight-2020-0001”)。

圖8 著作權查詢結果截圖
transaction_copyRight_js參數設置[registerNum:“copyRight-2020-0001”,copyrightOwner:“lingdanyin”],鏈碼方法transaction_copyRight(),依據registerNum和copyrightOwner實現著作權變更。
切換至peer0.org2節點,以query_copyRight()和[registerNum:“copyRight-2020-0001”]參數執行查詢操作,返回著作權記錄的copyrightOwner為“lingdanyin”,由此可以看到賬本在每個peer節點是同步的。
2) 賬本分析。(1) 狀態賬本。圖9為fabric網絡狀態賬本的主要數據文檔,mychannel_文檔記錄了通道的配置信息、區塊高度等數據,mychannel_cc_copyRight文檔記錄所有著作權記錄數據的最新json值,是狀態賬本的核心內容,mychannel_lscc存儲通道鏈碼生命周期管理模塊的相關數據文檔,在后續鏈碼的調用過程中,根據鏈碼執行對狀態賬本的影響更新各文檔的value值。

圖9 狀態賬本主要文檔截圖
(2) 區塊賬本。通過peer channel fetch命令獲取交易區塊,使用configtxlator工具把區塊文件轉換為可讀的.json文件,可以看到區塊文件詳細記錄了著作權交易的內容,以transaction_copyRight.js執行結果的區塊文件為例,主要內容如下:
data:{
……
“header”:{
“creator”:{“id_bytes”:交易創建者加密數據,
mspid:“Org1msp”}
“nonce”:“加密隨機數”}
“payload”:{
……
“chaincode_proposal_payload”:{
…,“chaincode_id”:“cc_copyRight”,
“args”:調用方法及參數加密數據,…}
“action”:{
“endorsements”:{“endorser”:背書加密數據,
“signature”:簽名加密數據}
“proposal_response_payload”:{
…,“chaincode_id”:“cc_copyRight”,
“results”:加密數據,“response”:返回值,…}}}
……
header:{
“data_hash”:“區塊加密交易數據”,
“number”:“3”,
“previous_hash”:“上一區塊hash值加密數據”}
metadata:{簽名信息、交易合法性標識等內容加密數據}
3) 確權、用權、維權過程分析。確權數據流轉:著作權登記sdk把帶有著作權登記憑證的交易提案交付給背書節點,背書節點把憑證傳入cc_copyRight鏈碼的shim.ChaincodeStubInterface參數接口,鏈碼處理著作權登記憑證后,通過PutState方法生成登記憑證記賬寫集Writes[],背書節點在ProposalResponse中向sdk返回寫集,sdk校驗后,經排序節點排序,著作權登記交易作為區塊的一部分由記賬節點寫入區塊賬本,狀態賬本增加著作權記錄,著作權登記寫集增加的世界狀態內容為[“key”:“copyRight-2020-0001”,“~version”:“2”,value:{…,“copyrightOwner”:“xiahaofei”,…}] 。
用權數據流轉:著作權交易sdk在交易提案的憑證中攜帶交易方法transaction_copyRight()和交易著作權編號registerNum與交易相對人copyrightOwner信息,背書過程利用GetState方法生成讀集,讀取狀態賬本符合交易條件的記錄,修改記錄的所有權人copyrightOwner,生成寫集更新狀態賬本,著作權利人變更完成,讀寫集內容為:
Reads[]:[“key”:“copyRight-2020-0001”,“~version”:“2”]
Writes[]:[“key”:“copyRight-2020-0001”, IsDelete:false, value: {…, “copyrightOwner”: “lingdanyin”,…} ]
狀態賬本更新此條著作權記錄的version=3。
維權:交易追溯通過區塊賬本實現,每個交易提案都帶有交易創建者的簽名,在一個實際的著作權管理生產系統中,每個網絡用戶的私鑰應在監管機構備案,當出現某個交易異常時,監管機構檢查區塊賬本獲取相關交易的簽名信息,結合用戶備案私鑰,實現對交易提案用戶的追溯。
通過實驗了解到Fabric技術方案在應用中存在局限性。一個實際的分布式著作權管理生產系統需要備案不同類型的著作權作品內容,目前Fabric技術提供的分布式賬本存儲系統只能夠支持以文本為主要內容的作品存儲,如文字作品、部分以代碼為主的計算機軟件作品等,對于美術、影視等作品內容的存儲有待通過進一步的探索來完善。后續研究將利用Fabric技術框架的周邊生態來改進用戶接口的友好性,如:利用Hyperledger explorer的可視化環境來查看系統的網絡拓撲結構、鏈碼、交易等信息,實現網絡的配置與管理,知悉交易狀況;利用composer框架來定義網絡上的資產、參與者和交易過程,創建具體的應用程序,提供便捷的用戶接口。另外,研究將使用實體服務器來代替虛擬機,以提升分布式網絡硬件性能,推進系統生產部署。
本文依托Hyperledger Fabric技術框架,設計一種基于分布式存儲技術的著作權管理系統。著作權證書主要包括登記編號、權利人、作品類別、作品名稱、登記時間等信息,數據結構相對簡單且相似度高。模擬系統很好地實現了分布式系統中著作權證書的登記、交易及訪問應用等管理功能。在系統中,用戶能夠方便地擁有和支配自己的著作權。同時,系統支持著作權的登記和交易經相關機構認可,支持監管機構對交易過程和交易數據的追溯與監管。模擬實驗為解決中心化著作權管理存在的成本高、交易過程和著作權制品使用追溯效率低等問題提供了一種技術思路和解決方案。