夏浩飛 陳界譽

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

0 引 言

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

公有鏈和聯(lián)盟鏈是兩種重要的分布式存儲技術，文獻[1-3]借助公有鏈的多點共識機制、交易不可篡改、可追溯等特性，提出基于分布式框架技術的著作權管控模型及監(jiān)督機制，降低數(shù)字著作權登記的門檻，增強著作權認證的權威。文獻[4-6]進行了基于公有鏈的數(shù)字著作權登記、交互與存儲模型研究，闡述了分布式存儲技術在著作權確權、用權和維權方面的應用構思?；诠墟溂夹g架構的著作權管理系統(tǒng)可以較好地解決中心化管理存在的問題，但對系統(tǒng)交易的監(jiān)管難以實現(xiàn)，而聯(lián)盟鏈可以在保留交易不可篡改、可追溯、多點共識機制等特性的基礎上，通過加入用戶認證體系來有效地實現(xiàn)分布式系統(tǒng)的監(jiān)管難問題。文獻[7]以聯(lián)盟鏈形式構建了一種具備安全認證和訪問控制功能的分布式醫(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ù)據(jù)存證、農(nóng)產(chǎn)品數(shù)據(jù)分布式存儲體系建設等領域也有應用[9-10]。

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

1 技術框架

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

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

1.2 Fabric網(wǎng)絡

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

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

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

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

2.1 Fabric網(wǎng)絡設計

著作權管理系統(tǒng)設兩個組織org1和org2，其下各設兩個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模擬兩個著作權管理機構，其下的兩個peer節(jié)點模擬著作權管理機構的成員，各成員通過自己維護的peer節(jié)點連入著作權管理Fabric網(wǎng)絡，實現(xiàn)客戶端與Fabric網(wǎng)絡的交互。

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

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

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

2.2 鏈碼設計

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

表1 著作權數(shù)據(jù)結構表

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

鏈碼命名cc_copyRight，設計register_copyRight()、transaction_copyRight()和query_copyRight()三個功能函數(shù)，分別實現(xiàn)著作權的登記、交易和查詢，算法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 返回錯誤提示“參數(shù)不合法”

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讀寫集

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

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

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

重寫record.copyrightOwner=Parameters. copyrightOwner

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

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

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

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

返回record

2.3 用戶注冊及交易流程設計

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

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

系統(tǒng)同樣以sdk方式實現(xiàn)交易流程，用戶登錄系統(tǒng)提交著作權數(shù)據(jù)憑證，包括處理方法和著作權數(shù)據(jù)，客戶端sdk根據(jù)憑證創(chuàng)建交易提案并用提交交易用戶的私鑰完成交易提案簽名后，發(fā)送至背書策略指定的背書節(jié)點處理，背書節(jié)點的處理過程不僅是對著作權憑證的處理和簽名過程，也是鏈上著作權管理聯(lián)盟各組織成員對著作權憑證的認可，sdk對著作權憑證處理結果返回值進行一致性檢驗和背書策略驗證，是著作權管理組織成員對著作權憑證處理的意見是否一致，是否符合預先設定的著作權處理規(guī)則的確認過程。通過驗證的著作權處理結果由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為著作權管理交易流程。

圖4 著作權管理交易流程

3 系統(tǒng)實現(xià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命令把著作權管理鏈碼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) 鏈碼設計與調(diào)用。編寫register_copyRight.js實現(xià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)著作權交易功能，執(zhí)行流程與register_copyRight.js基本一致，區(qū)別為交易提案request中的fcn、args不同。

request={

fcn: transaction_copyRight(),

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

…

}

registerNum識別交易著作權記錄，copyrightOwner用于重寫著作權人。

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

request={…,

fcn: query_copyRight(),

args:[ ‘registerNum’],

…

}

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

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

3.2 實驗結果

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

圖7 著作權登記執(zhí)行結果截圖

分析執(zhí)行過程：

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

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

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

(4) 全部背書結果有效性、一致性檢驗和背書策略驗證通過，顯示信息“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)賬本中符合查詢條件的著作權記錄，把其value值返回給客戶端，圖8為query_copyRight.js執(zhí)行結果(參數(shù)registerNum: “copyRight-2020-0001”)。

圖8 著作權查詢結果截圖

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

切換至peer0.org2節(jié)點，以query_copyRight()和[registerNum:“copyRight-2020-0001”]參數(shù)執(zhí)行查詢操作，返回著作權記錄的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文檔記錄所有著作權記錄數(shù)據(jù)的最新json值，是狀態(tài)賬本的核心內(nèi)容，mychannel_lscc存儲通道鏈碼生命周期管理模塊的相關數(shù)據(jù)文檔，在后續(xù)鏈碼的調(diào)用過程中，根據(jù)鏈碼執(zhí)行對狀態(tài)賬本的影響更新各文檔的value值。

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

(2) 區(qū)塊賬本。通過peer channel fetch命令獲取交易區(qū)塊，使用configtxlator工具把區(qū)塊文件轉換為可讀的.json文件，可以看到區(qū)塊文件詳細記錄了著作權交易的內(nèi)容，以transaction_copyRight.js執(zhí)行結果的區(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) 確權、用權、維權過程分析。確權數(shù)據(jù)流轉：著作權登記sdk把帶有著作權登記憑證的交易提案交付給背書節(jié)點，背書節(jié)點把憑證傳入cc_copyRight鏈碼的shim.ChaincodeStubInterface參數(shù)接口，鏈碼處理著作權登記憑證后，通過PutState方法生成登記憑證記賬寫集Writes[]，背書節(jié)點在ProposalResponse中向sdk返回寫集，sdk校驗后，經(jīng)排序節(jié)點排序，著作權登記交易作為區(qū)塊的一部分由記賬節(jié)點寫入?yún)^(qū)塊賬本，狀態(tài)賬本增加著作權記錄，著作權登記寫集增加的世界狀態(tài)內(nèi)容為[“key”:“copyRight-2020-0001”,“～version”:“2”,value:{…,“copyrightOwner”:“xiahaofei”,…}] 。

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

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

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

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

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

3.3 Fabric的局限性

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

4 結 語

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