基于Hyperledger Fabric構(gòu)建一種著作權(quán)應用管理的研究與模擬實驗

夏浩飛 陳界譽

1(嘉興職業(yè)技術(shù)學院開放教育學院 浙江 嘉興 314000)2(嘉興職業(yè)技術(shù)學院科研處 浙江 嘉興 314000)

0 引 言

確權(quán)、用權(quán)、維權(quán)是著作權(quán)管理的主要內(nèi)容，互聯(lián)網(wǎng)+時代，數(shù)字資源規(guī)模迅速膨脹，復制速度快，抄襲方便，由此造成的侵權(quán)問題層出不窮，中心化的著作權(quán)登記、交易、認證管理模式成本高、效率低，已很難應對數(shù)量如此龐大的著作權(quán)管理需求，利用分布式存儲框架及計算技術(shù)來實現(xiàn)著作權(quán)數(shù)據(jù)的管理，簡化登記、交易等流程，提高管理效率，具有研究價值。

公有鏈和聯(lián)盟鏈是兩種重要的分布式存儲技術(shù)，文獻[1-3]借助公有鏈的多點共識機制、交易不可篡改、可追溯等特性，提出基于分布式框架技術(shù)的著作權(quán)管控模型及監(jiān)督機制，降低數(shù)字著作權(quán)登記的門檻，增強著作權(quán)認證的權(quán)威。文獻[4-6]進行了基于公有鏈的數(shù)字著作權(quán)登記、交互與存儲模型研究，闡述了分布式存儲技術(shù)在著作權(quán)確權(quán)、用權(quán)和維權(quán)方面的應用構(gòu)思?；诠墟溂夹g(shù)架構(gòu)的著作權(quán)管理系統(tǒng)可以較好地解決中心化管理存在的問題，但對系統(tǒng)交易的監(jiān)管難以實現(xiàn)，而聯(lián)盟鏈可以在保留交易不可篡改、可追溯、多點共識機制等特性的基礎(chǔ)上，通過加入用戶認證體系來有效地實現(xiàn)分布式系統(tǒng)的監(jiān)管難問題。文獻[7]以聯(lián)盟鏈形式構(gòu)建了一種具備安全認證和訪問控制功能的分布式醫(yī)療數(shù)據(jù)存儲和管理系統(tǒng)，既保證患者的數(shù)據(jù)隱私，又滿足聯(lián)盟成員之間醫(yī)療數(shù)據(jù)的共享需求。文獻[8]利用聯(lián)盟鏈的分布式存儲、共識機制、智能合約、加密算法等功能，搭建智能電網(wǎng)數(shù)據(jù)處理平臺，旨在打造一個智能電網(wǎng)數(shù)據(jù)優(yōu)化的新型生態(tài)模式。另外，聯(lián)盟鏈框架技術(shù)在教育數(shù)據(jù)存證、農(nóng)產(chǎn)品數(shù)據(jù)分布式存儲體系建設(shè)等領(lǐng)域也有應用[9-10]。

本文依托Hyperledger Fabric技術(shù)框架，構(gòu)建了一種具有分布式存儲和計算特征的著作權(quán)管理系統(tǒng)，并基于fabric鏡像文件、docker容器、node sdk等技術(shù)模擬實現(xiàn)了該系統(tǒng)，實驗結(jié)果表明，基于Hyperledger Fabric的分布式著作權(quán)管理系統(tǒng)能夠有效地管理著作權(quán)數(shù)據(jù)，記錄數(shù)據(jù)的流轉(zhuǎn)過程，在保障著作權(quán)人權(quán)益同時，簡化著作權(quán)的登記確認、交易變更、舉證維權(quán)等重要環(huán)節(jié)。

1 技術(shù)框架

超級賬本(Hyperledger)項目以聯(lián)盟鏈形式構(gòu)建一個分布式的數(shù)據(jù)存儲與處理系統(tǒng)，系統(tǒng)數(shù)據(jù)由聯(lián)盟成員通過背書、排序等機制共建共管，是一種全新的數(shù)據(jù)架構(gòu)與處理技術(shù)[11]，其成員管理服務和證書系統(tǒng)[12]，在保證交易匿名的同時，實現(xiàn)了交易的可監(jiān)管性，大幅拓展該技術(shù)的應用領(lǐng)域。

Fabric是Hyperledger最重要的子項目之一，以相互隔離的通道方式運行，由此保證聯(lián)盟成員數(shù)據(jù)的安全和隱私，用戶通過應用程序向CA注冊并登記身份，憑借身份證書登錄Fabric網(wǎng)絡，發(fā)起交易提案，交易在經(jīng)過Fabric網(wǎng)絡的模擬執(zhí)行、背書簽名、排序處理后，打包生成區(qū)塊并在網(wǎng)絡節(jié)點完成區(qū)塊記賬，同時更新狀態(tài)賬本[13]。圖1為Fabric運行流程。

圖1 Fabric運行流程

1.1 應用程序

應用程序是用戶訪問Fabric網(wǎng)絡的接口，用戶把交易提案及相關(guān)參數(shù)輸入至應用程序，應用程序在收到交易提案及相關(guān)參數(shù)后，根據(jù)鏈碼實例化過程中指定的背書策略，將其發(fā)送至Fabric網(wǎng)絡的相關(guān)背書節(jié)點，背書節(jié)點模擬執(zhí)行交易，執(zhí)行結(jié)果發(fā)回給應用程序。應用程序檢驗各背書節(jié)點的背書結(jié)果是否一致，背書簽名是否符合背書策略，若符合條件，則打包執(zhí)行結(jié)果，包括讀寫集、簽名、通道號等信息，形成正式交易，發(fā)送至排序節(jié)點，否則標記交易為無效交易。

1.2 Fabric網(wǎng)絡

Fabric網(wǎng)絡的主體為背書節(jié)點、記賬節(jié)點和排序節(jié)點，主要任務是完成交易的模擬執(zhí)行、背書簽名、排序和數(shù)據(jù)存儲。

背書節(jié)點在接收到應用程序發(fā)送的交易提案后，檢查交易是否完好，是否已提交過，驗證交易簽名和用戶權(quán)限。交易提案通過，則根據(jù)提案調(diào)用的鏈碼名稱、鏈碼方法及傳入的參數(shù)模擬執(zhí)行提案并簽名，把讀寫集等執(zhí)行結(jié)果和背書簽名數(shù)據(jù)一起發(fā)回給應用程序；若交易提案未通過檢驗，則標記交易不合法，拒絕背書。

排序模塊接收某一時間段內(nèi)應用程序發(fā)送過來的所有交易，采用設(shè)定的排序算法對交易進行排序，并依據(jù)區(qū)塊生成規(guī)則，把這一時間段內(nèi)生成并排序完成的交易打包成區(qū)塊，交付給記賬節(jié)點。

記賬節(jié)點負責賬本數(shù)據(jù)的存儲，網(wǎng)絡中的節(jié)點一般都是記賬節(jié)點。區(qū)塊數(shù)據(jù)由排序節(jié)點交付給記賬節(jié)點，記賬節(jié)點校驗每筆交易的合法性，包括背書簽名是否正確、背書策略是否滿足、讀寫集是否有效等。記賬節(jié)點校驗通過，更新區(qū)塊文件和狀態(tài)賬本，并將記賬結(jié)果告知應用程序；否則，標記交易無效，不更新狀態(tài)賬本。

1.3 身份管理模塊

身份管理模塊由Fabric-CA負責，應用程序用enroll命令登記CA配置文件中的admin身份，其他用戶身份經(jīng)由admin進行注冊、登記，CA向登記成功的用戶頒發(fā)身份證書、簽名密鑰。身份證書是用戶登錄Fabric網(wǎng)絡的憑證，私鑰用于交易簽名，以此確保交易的可追溯和可監(jiān)管。

1.4 鏈 碼

鏈碼是組成交易的一組功能代碼，F(xiàn)abric提供go和node兩種鏈碼設(shè)計語言，鏈碼在Fabric網(wǎng)絡完成安裝和實例化之后，由應用程序根據(jù)用戶需求調(diào)用鏈碼功能函數(shù)，調(diào)用接口有query()和invoke()，query方法僅僅是對狀態(tài)數(shù)據(jù)的一次讀取，不產(chǎn)生交易和區(qū)塊，invoke方法根據(jù)交易流程實現(xiàn)功能。

鏈碼調(diào)用除在應用程序端以命令行方式實現(xiàn)外，更多是采用sdk方式，fabric-node-sdk是Hyperledger項目較為成熟的生態(tài)之一，用于提供客戶端與Fabric網(wǎng)絡交互的功能模塊框架。

鏈碼經(jīng)過安裝和實例化兩個環(huán)節(jié)，部署在指定的peer節(jié)點上，在鏈碼實例化過程中指定Fabric網(wǎng)絡的背書策略，背書策略用于確定有效的鏈碼執(zhí)行必須得到的背書簽名組合，由Fabric系統(tǒng)鏈碼VSCC(Validation System Chaincode)進行驗證[14]，參與背書策略的角色可以是組織內(nèi)的admin、client用戶或者peer節(jié)點。

1.5 賬 本

賬本是Fabric網(wǎng)絡的數(shù)據(jù)存儲媒介，主要由區(qū)塊賬本和狀態(tài)賬本組成，前者用于存儲交易區(qū)塊，后者負責記錄交易數(shù)據(jù)的最終狀態(tài)。

區(qū)塊賬本采用aufs文件系統(tǒng)，文件格式為pb(Protocol Buffer)，區(qū)塊文件由header、data和metadata三部分組成，header由當前區(qū)塊交易的hash值data_hash、當前區(qū)塊編號number和前一區(qū)塊hash值previous_hash組成，data包含當前區(qū)塊的交易內(nèi)容，metadata為一組加密的數(shù)據(jù)，主要記錄交易的簽名、合法性、有效性等標簽。

狀態(tài)賬本存儲著系統(tǒng)業(yè)務數(shù)據(jù)的最新狀態(tài)，數(shù)據(jù)的讀取與更新依托讀寫集完成，讀寫集主要數(shù)據(jù)結(jié)構(gòu)為Reads[]*KVRead和Writes[]*KVWrite，Reads[]字段包括鍵值和版本號[Key:string,Version:*Version]，Writes[]字段包括鍵值、數(shù)據(jù)值和刪除標記[Key:string,Value:string,IsDelete:bool]。在fabric1.0中，取當前區(qū)塊的高度作為版本號version的值。除此之外，狀態(tài)賬本還存儲著通道、鏈碼及其生命周期管理方法LSCC(Lifecycle System Chaincode)創(chuàng)建及更新的數(shù)據(jù)信息。

2 系統(tǒng)設(shè)計

2.1 Fabric網(wǎng)絡設(shè)計

著作權(quán)管理系統(tǒng)設(shè)兩個組織org1和org2，其下各設(shè)兩個peer節(jié)點，分配ubuntu虛擬機的7051、8051、9051、10051端口，節(jié)點名稱為：peer0.org1、peer1.org1、peer0.org2和peer1.org2，其中peer0.org1和peer0.org2為各自組織的主節(jié)點和錨節(jié)點，主節(jié)點負責與排序服務通信，錨節(jié)點負責組織之間的通信與同步信息，通信使用的TLS證書利用Fabric的cryptogen工具生成，4個peer節(jié)點均為記賬節(jié)點。

org1、org2模擬兩個著作權(quán)管理機構(gòu)，其下的兩個peer節(jié)點模擬著作權(quán)管理機構(gòu)的成員，各成員通過自己維護的peer節(jié)點連入著作權(quán)管理Fabric網(wǎng)絡，實現(xiàn)客戶端與Fabric網(wǎng)絡的交互。

排序模塊選擇Fabric的主流排序算法kafka，設(shè)置兩個排序節(jié)點orderer0和orderer1，每個排序節(jié)點設(shè)置4個kafka服務，kafka0-kafka3，每個kafka設(shè)置3個zookeeper服務，zookeeper0-zookeeper2。圖2為著作權(quán)管理系統(tǒng)Fabric網(wǎng)絡架構(gòu)。

圖2 著作權(quán)管理系統(tǒng)Fabric網(wǎng)絡

系統(tǒng)利用fabric-tools鏡像創(chuàng)建cli服務模擬應用程序，通過cli結(jié)合shell腳本方式實現(xiàn)系統(tǒng)通道的創(chuàng)建，節(jié)點的加入，鏈碼的安裝、實例化及背書策略配置。系統(tǒng)的背書策略設(shè)置為“AND(Org1MSP.member,Org2MSP.member)”，即有效的鏈碼執(zhí)行必須同時得到兩個組織中至少一名成員的簽名。

2.2 鏈碼設(shè)計

鏈碼實現(xiàn)著作權(quán)的登記、交易和查詢功能。著作權(quán)數(shù)據(jù)結(jié)構(gòu)采用.json格式，簡要設(shè)計如表1所示。

表1 著作權(quán)數(shù)據(jù)結(jié)構(gòu)表

記錄格式為[{“Key”:“*”,“value”:{“registerNum”:“*”,“Author”:“*”,“copyrightOwner”:“*”,…}}]，以couchDb作為數(shù)據(jù)記錄存儲媒介。

鏈碼命名cc_copyRight，設(shè)計register_copyRight()、transaction_copyRight()和query_copyRight()三個功能函數(shù)，分別實現(xiàn)著作權(quán)的登記、交易和查詢，算法1為鏈碼主要流程。

算法1cc_copyRight鏈碼主要流程

2. if Function=register_copyRight() 跳轉(zhuǎn)至3

else If Function=transaction_copyRight() 跳轉(zhuǎn)至4

else If Function=query_copyRight() 跳轉(zhuǎn)至5

else 返回錯誤提示“鏈碼方法不合法”

3. if Parameters is invalid 返回錯誤提示“參數(shù)不合法”

else 著作權(quán)記錄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讀寫集

返回成功執(zhí)行提示

4. if Parameters is invalid 返回錯誤提示“參數(shù)不合法”

else APIstub.GetState(key:Parameters.registerNum)讀取交易的著作權(quán)記錄record

重寫record.copyrightOwner=Parameters. copyrightOwner

APIstub.PutState方法生成修改后著作權(quán)記錄record的key-value寫集

返回成功執(zhí)行提示

5. if Parameters is invalid 返回錯誤提示“參數(shù)不合法”

else record=APIstub.GetState(key:Parameters.registerNum)讀取符合條件的著作權(quán)記錄

返回record

2.3 用戶注冊及交易流程設(shè)計

身份注冊登記功能主要依賴CA服務端的fabric-ca-server和客戶端的fabric-ca-client模塊，在CA服務配置文件中設(shè)置引導身份admin，利用sdk登記CA配置文件中設(shè)定的admin用戶，其他普通用戶通過激活的admin用戶實現(xiàn)注冊和登記，圖3為普通用戶注冊登記過程。

圖3 普通用戶注冊登記過程

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

圖4 著作權(quán)管理交易流程

3 系統(tǒng)實現(xiàn)

著作權(quán)管理系統(tǒng)選擇ubuntu平臺，基于docker容器和docker-compose工具部署Fabric網(wǎng)絡，使用shell腳本管理Fabric網(wǎng)絡，安裝、實例化cc_copyRight鏈碼，系統(tǒng)使用Fabric1.0版本鏡像文件。

3.1 實驗步驟

1) Fabric網(wǎng)絡部署。應用Fabric包提供的通道配置程序configtxgen和通道配置文件configtx.yaml生成創(chuàng)世區(qū)塊genesis.block和創(chuàng)建通道依賴的文件channel.tx，生成組織的錨節(jié)點更新依賴的文件Org1MSPanchors.tx和Org2MSPanchors.tx。

編寫docker-compose-copyRight.yaml配置Fabric網(wǎng)絡，編寫shell腳本start_copyRight_fabric.sh啟動Fabric網(wǎng)絡和安裝鏈碼。

(1) 啟動Fabric網(wǎng)絡。使用docker-compose up命令執(zhí)行Fabric網(wǎng)絡配置文件docker-compose-copyRight.yaml，生成對應的docker容器，啟動Fabric網(wǎng)絡的各項服務和4個節(jié)點。Fabric網(wǎng)絡啟動后，使用channel create命令在peer0.org1節(jié)點創(chuàng)建通道m(xù)ychannel，其他三個peer節(jié)點依次加入mychannel通道，并更新組織的錨節(jié)點。

(2) 安裝鏈碼。使用peer chaincode install命令把著作權(quán)管理鏈碼cc_copyRight安裝至peer0.org1和peer0.org2節(jié)點，使用peer chaincode instantiate命令實例化鏈碼，鏈碼實例化成功后，安裝鏈碼的節(jié)點會生成相應的鏈碼鏡像文件，如圖5所示，在鏈碼實例化過程中指定系統(tǒng)的背書策略。完成鏈碼實例化的各peer節(jié)點處于消息偵聽狀態(tài)，等待應用程序的交易提案。

圖5 鏈碼鏡像截圖

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

圖6 用戶注冊登記成功截圖

3) 鏈碼設(shè)計與調(diào)用。編寫register_copyRight.js實現(xiàn)著作權(quán)登記功能，算法2為其主要流程。

算法2register_copyRight.js主要流程

1. getRegisteredUsers獲取xiahaofei的證書和密鑰

2. 創(chuàng)建xiahaofei簽名的交易提案request={

chaincodeId:‘cc_copyRight’,

fcn:‘register_copyRight()’,

args:[‘registerNum’,‘Author’,‘copyrightOwner’,…],

ChainId:‘channelID’,

txId:‘transactionID’}

3. 選擇背書節(jié)點request.targets=peer0.org1&peer0.org2

4. 發(fā)送交易提案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) 注冊交易監(jiān)聽事件

9. 發(fā)送正式交易request to orderer

10. 獲取orderer返回值txPromise

獲取監(jiān)聽事件返回值eventPromise

11. if (txPromise&eventPromise) 提示客戶端交易成功

編寫transaction_copyRight.js實現(xiàn)著作權(quán)交易功能，執(zhí)行流程與register_copyRight.js基本一致，區(qū)別為交易提案request中的fcn、args不同。

request={

fcn: transaction_copyRight(),

args:[ ‘registerNum’, ‘copyrightOwner’],

…

}

registerNum識別交易著作權(quán)記錄，copyrightOwner用于重寫著作權(quán)人。

編寫query_copyRight.js實現(xiàn)著作權(quán)記錄的查詢，返回符合條件的著作權(quán)記錄給客戶端，交易提案為：

request={…,

fcn: query_copyRight(),

args:[ ‘registerNum’],

…

}

查詢sdk和注冊、登記sdk一樣，統(tǒng)一使用fabric的invoke()接口，由于是查詢交易，不需要更新狀態(tài)賬本，所以sdk在收到模擬執(zhí)行的交易提案返回值后，僅向客戶端反饋查詢結(jié)果，同時標記交易為無效交易，不提交給排序節(jié)點，但寫入?yún)^(qū)塊文件。

鏈碼在ubuntu命令行下使用node調(diào)用，如調(diào)用著作權(quán)登記sdk命令為：node register_copyRight.js。

3.2 實驗結(jié)果

1) 鏈碼執(zhí)行結(jié)果。docker-compose-copyRight.yaml配置文件中cli連接的默認節(jié)點為peer0.org1，以上著作權(quán)登記、交易和查詢操作均在peer0.org1節(jié)點上執(zhí)行，圖7為register_copyRight.js執(zhí)行結(jié)果。

圖7 著作權(quán)登記執(zhí)行結(jié)果截圖

分析執(zhí)行過程：

(1) 客戶端sdk(register_copyRight.js)獲取著作權(quán)登記用戶的私鑰和簽名證書，成功，顯示信息“Load privateKey and signedCert”。

(2) sdk給創(chuàng)建的交易提案(proposal)簽名，為其分配交易編號transaction_id，然后根據(jù)設(shè)定的背書策略，向背書節(jié)點提交著作權(quán)登記交易提案。

(3) sdk逐個檢驗背書節(jié)點處理交易的返回值ProposalResponse，通過，顯示信息“Transaciton proposal was good”。

(4) 全部背書結(jié)果有效性、一致性檢驗和背書策略驗證通過，顯示信息“Successfully send Proposal and received ProposalResponse:state-200,message-“””。

(5) 交易監(jiān)聽器確認交易提交完成，顯示信息“The transaction has been committed on peer localhost:7053”，7053為監(jiān)聽器所使用的端口。

(6) sdk收到交易提交成功和監(jiān)聽事件成功反饋，顯示信息“Send transaction promise and event listner promise have completed”。

(7) sdk通知客戶端交易成功，記賬完成。

query_copyRight.js的執(zhí)行，不改變賬本狀態(tài)，僅調(diào)用鏈碼的query_copyRight()方法獲取狀態(tài)賬本中符合查詢條件的著作權(quán)記錄，把其value值返回給客戶端，圖8為query_copyRight.js執(zhí)行結(jié)果(參數(shù)registerNum: “copyRight-2020-0001”)。

圖8 著作權(quán)查詢結(jié)果截圖

transaction_copyRight_js參數(shù)設(shè)置[registerNum:“copyRight-2020-0001”,copyrightOwner:“l(fā)ingdanyin”]，鏈碼方法transaction_copyRight()，依據(jù)registerNum和copyrightOwner實現(xiàn)著作權(quán)變更。

切換至peer0.org2節(jié)點，以query_copyRight()和[registerNum:“copyRight-2020-0001”]參數(shù)執(zhí)行查詢操作，返回著作權(quán)記錄的copyrightOwner為“l(fā)ingdanyin”，由此可以看到賬本在每個peer節(jié)點是同步的。

2) 賬本分析。(1) 狀態(tài)賬本。圖9為fabric網(wǎng)絡狀態(tài)賬本的主要數(shù)據(jù)文檔，mychannel_文檔記錄了通道的配置信息、區(qū)塊高度等數(shù)據(jù)，mychannel_cc_copyRight文檔記錄所有著作權(quán)記錄數(shù)據(jù)的最新json值，是狀態(tài)賬本的核心內(nèi)容，mychannel_lscc存儲通道鏈碼生命周期管理模塊的相關(guān)數(shù)據(jù)文檔，在后續(xù)鏈碼的調(diào)用過程中，根據(jù)鏈碼執(zhí)行對狀態(tài)賬本的影響更新各文檔的value值。

圖9 狀態(tài)賬本主要文檔截圖

(2) 區(qū)塊賬本。通過peer channel fetch命令獲取交易區(qū)塊，使用configtxlator工具把區(qū)塊文件轉(zhuǎn)換為可讀的.json文件，可以看到區(qū)塊文件詳細記錄了著作權(quán)交易的內(nèi)容，以transaction_copyRight.js執(zhí)行結(jié)果的區(qū)塊文件為例，主要內(nèi)容如下：

data:{

……

“header”:{

“creator”:{“id_bytes”:交易創(chuàng)建者加密數(shù)據(jù),

mspid:“Org1msp”}

“nonce”:“加密隨機數(shù)”}

“payload”:{

……

“chaincode_proposal_payload”:{

…,“chaincode_id”:“cc_copyRight”,

“args”:調(diào)用方法及參數(shù)加密數(shù)據(jù),…}

“action”:{

“endorsements”:{“endorser”:背書加密數(shù)據(jù),

“signature”:簽名加密數(shù)據(jù)}

“proposal_response_payload”:{

…,“chaincode_id”:“cc_copyRight”,

“results”:加密數(shù)據(jù),“response”:返回值,…}}}

……

header:{

“data_hash”:“區(qū)塊加密交易數(shù)據(jù)”,

“number”:“3”,

“previous_hash”:“上一區(qū)塊hash值加密數(shù)據(jù)”}

metadata:{簽名信息、交易合法性標識等內(nèi)容加密數(shù)據(jù)}

3) 確權(quán)、用權(quán)、維權(quán)過程分析。確權(quán)數(shù)據(jù)流轉(zhuǎn)：著作權(quán)登記sdk把帶有著作權(quán)登記憑證的交易提案交付給背書節(jié)點，背書節(jié)點把憑證傳入cc_copyRight鏈碼的shim.ChaincodeStubInterface參數(shù)接口，鏈碼處理著作權(quán)登記憑證后，通過PutState方法生成登記憑證記賬寫集Writes[]，背書節(jié)點在ProposalResponse中向sdk返回寫集，sdk校驗后，經(jīng)排序節(jié)點排序，著作權(quán)登記交易作為區(qū)塊的一部分由記賬節(jié)點寫入?yún)^(qū)塊賬本，狀態(tài)賬本增加著作權(quán)記錄，著作權(quán)登記寫集增加的世界狀態(tài)內(nèi)容為[“key”:“copyRight-2020-0001”,“～version”:“2”,value:{…,“copyrightOwner”:“xiahaofei”,…}] 。

用權(quán)數(shù)據(jù)流轉(zhuǎn)：著作權(quán)交易sdk在交易提案的憑證中攜帶交易方法transaction_copyRight()和交易著作權(quán)編號registerNum與交易相對人copyrightOwner信息，背書過程利用GetState方法生成讀集，讀取狀態(tài)賬本符合交易條件的記錄，修改記錄的所有權(quán)人copyrightOwner，生成寫集更新狀態(tài)賬本，著作權(quán)利人變更完成，讀寫集內(nèi)容為：

Reads[]:[“key”:“copyRight-2020-0001”,“～version”:“2”]

Writes[]:[“key”:“copyRight-2020-0001”, IsDelete:false, value: {…, “copyrightOwner”: “l(fā)ingdanyin”,…} ]

狀態(tài)賬本更新此條著作權(quán)記錄的version=3。

維權(quán)：交易追溯通過區(qū)塊賬本實現(xiàn)，每個交易提案都帶有交易創(chuàng)建者的簽名，在一個實際的著作權(quán)管理生產(chǎn)系統(tǒng)中，每個網(wǎng)絡用戶的私鑰應在監(jiān)管機構(gòu)備案，當出現(xiàn)某個交易異常時，監(jiān)管機構(gòu)檢查區(qū)塊賬本獲取相關(guān)交易的簽名信息，結(jié)合用戶備案私鑰，實現(xiàn)對交易提案用戶的追溯。

3.3 Fabric的局限性

通過實驗了解到Fabric技術(shù)方案在應用中存在局限性。一個實際的分布式著作權(quán)管理生產(chǎn)系統(tǒng)需要備案不同類型的著作權(quán)作品內(nèi)容，目前Fabric技術(shù)提供的分布式賬本存儲系統(tǒng)只能夠支持以文本為主要內(nèi)容的作品存儲，如文字作品、部分以代碼為主的計算機軟件作品等，對于美術(shù)、影視等作品內(nèi)容的存儲有待通過進一步的探索來完善。后續(xù)研究將利用Fabric技術(shù)框架的周邊生態(tài)來改進用戶接口的友好性，如：利用Hyperledger explorer的可視化環(huán)境來查看系統(tǒng)的網(wǎng)絡拓撲結(jié)構(gòu)、鏈碼、交易等信息，實現(xiàn)網(wǎng)絡的配置與管理，知悉交易狀況；利用composer框架來定義網(wǎng)絡上的資產(chǎn)、參與者和交易過程，創(chuàng)建具體的應用程序，提供便捷的用戶接口。另外，研究將使用實體服務器來代替虛擬機，以提升分布式網(wǎng)絡硬件性能，推進系統(tǒng)生產(chǎn)部署。

4 結(jié) 語

本文依托Hyperledger Fabric技術(shù)框架，設(shè)計一種基于分布式存儲技術(shù)的著作權(quán)管理系統(tǒng)。著作權(quán)證書主要包括登記編號、權(quán)利人、作品類別、作品名稱、登記時間等信息，數(shù)據(jù)結(jié)構(gòu)相對簡單且相似度高。模擬系統(tǒng)很好地實現(xiàn)了分布式系統(tǒng)中著作權(quán)證書的登記、交易及訪問應用等管理功能。在系統(tǒng)中，用戶能夠方便地擁有和支配自己的著作權(quán)。同時，系統(tǒng)支持著作權(quán)的登記和交易經(jīng)相關(guān)機構(gòu)認可，支持監(jiān)管機構(gòu)對交易過程和交易數(shù)據(jù)的追溯與監(jiān)管。模擬實驗為解決中心化著作權(quán)管理存在的成本高、交易過程和著作權(quán)制品使用追溯效率低等問題提供了一種技術(shù)思路和解決方案。