国产日韩欧美一区二区三区三州_亚洲少妇熟女av_久久久久亚洲av国产精品_波多野结衣网站一区二区_亚洲欧美色片在线91_国产亚洲精品精品国产优播av_日本一区二区三区波多野结衣 _久久国产av不卡

?

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

2022-12-03 01:57夏浩飛陳界譽(yù)
關(guān)鍵詞:背書賬本排序

夏浩飛 陳界譽(yù)

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

0 引 言

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

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

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

1 技術(shù)框架

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

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

圖1 Fabric運(yùn)行流程

1.1 應(yīng)用程序

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

1.2 Fabric網(wǎng)絡(luò)

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

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

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

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

1.3 身份管理模塊

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

1.4 鏈 碼

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

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

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

1.5 賬 本

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

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

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

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

2.1 Fabric網(wǎng)絡(luò)設(shè)計(jì)

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

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

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

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

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

2.2 鏈碼設(shè)計(jì)

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

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

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

鏈碼命名cc_copyRight,設(shè)計(jì)register_copyRight()、transaction_copyRight()和query_copyRight()三個(gè)功能函數(shù),分別實(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 返回錯(cuò)誤提示“鏈碼方法不合法”

3. if Parameters is invalid 返回錯(cuò)誤提示“參數(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 返回錯(cuò)誤提示“參數(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 返回錯(cuò)誤提示“參數(shù)不合法”

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

返回record

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

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

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

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

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

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

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

3.1 實(shí)驗(yàn)步驟

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

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

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

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

圖5 鏈碼鏡像截圖

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

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

3) 鏈碼設(shè)計(jì)與調(diào)用。編寫register_copyRight.js實(shí)現(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é)點(diǎn)request.targets=peer0.org1&peer0.org2

4. 發(fā)送交易提案request給peer0.org1&peer0.org2

5. 獲取背書返回值proposalResponses[i]

6. 逐個(gè)驗(yàn)證背書返回值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實(shí)現(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實(shí)現(xiàn)著作權(quán)記錄的查詢,返回符合條件的著作權(quán)記錄給客戶端,交易提案為:

request={…,

fcn: query_copyRight(),

args:[ ‘registerNum’],

}

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

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

3.2 實(shí)驗(yàn)結(jié)果

1) 鏈碼執(zhí)行結(jié)果。docker-compose-copyRight.yaml配置文件中cli連接的默認(rèn)節(jié)點(diǎn)為peer0.org1,以上著作權(quán)登記、交易和查詢操作均在peer0.org1節(jié)點(diǎn)上執(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é)點(diǎn)提交著作權(quán)登記交易提案。

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

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

(5) 交易監(jiān)聽器確認(rè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實(shí)現(xiàn)著作權(quán)變更。

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

2) 賬本分析。(1) 狀態(tài)賬本。圖9為fabric網(wǎng)絡(luò)狀態(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ū)塊文件詳細(xì)記錄了著作權(quán)交易的內(nèi)容,以transaction_copyRight.js執(zhí)行結(jié)果的區(qū)塊文件為例,主要內(nèi)容如下:

data:{

……

“header”:{

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

mspid:“Org1msp”}

“nonce”:“加密隨機(jī)數(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:{簽名信息、交易合法性標(biāo)識等內(nèi)容加密數(shù)據(jù)}

3) 確權(quán)、用權(quán)、維權(quán)過程分析。確權(quán)數(shù)據(jù)流轉(zhuǎn):著作權(quán)登記sdk把帶有著作權(quán)登記憑證的交易提案交付給背書節(jié)點(diǎn),背書節(jié)點(diǎn)把憑證傳入cc_copyRight鏈碼的shim.ChaincodeStubInterface參數(shù)接口,鏈碼處理著作權(quán)登記憑證后,通過PutState方法生成登記憑證記賬寫集Writes[],背書節(jié)點(diǎn)在ProposalResponse中向sdk返回寫集,sdk校驗(yàn)后,經(jīng)排序節(jié)點(diǎn)排序,著作權(quán)登記交易作為區(qū)塊的一部分由記賬節(jié)點(diǎn)寫入?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ū)塊賬本實(shí)現(xiàn),每個(gè)交易提案都帶有交易創(chuàng)建者的簽名,在一個(gè)實(shí)際的著作權(quán)管理生產(chǎn)系統(tǒng)中,每個(gè)網(wǎng)絡(luò)用戶的私鑰應(yīng)在監(jiān)管機(jī)構(gòu)備案,當(dāng)出現(xiàn)某個(gè)交易異常時(shí),監(jiān)管機(jī)構(gòu)檢查區(qū)塊賬本獲取相關(guān)交易的簽名信息,結(jié)合用戶備案私鑰,實(shí)現(xiàn)對交易提案用戶的追溯。

3.3 Fabric的局限性

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

4 結(jié) 語

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

猜你喜歡
背書賬本排序
排序不等式
背書是寫作的基本功
背書
恐怖排序
數(shù)說:重慶70年“賬本”展示
節(jié)日排序
丟失的紅色賬本
大樹爺爺?shù)馁~本
丟失的紅色賬本
背書連續(xù)性若干問題探析
义马市| 南平市| 嫩江县| 西青区| 正安县| 忻州市| 张家港市| 延寿县| 郁南县| 新巴尔虎左旗| 阜阳市| 兴宁市| 裕民县| 天长市| 桐柏县| 长乐市| 庐江县| 佳木斯市| 乳山市| 金寨县| 鹤岗市| 赫章县| 东乡县| 隆尧县| 会理县| 达州市| 宁城县| 普格县| 阳曲县| 松溪县| 黄陵县| 乌拉特前旗| 盐山县| 白城市| 枣庄市| 水富县| 托里县| 平泉县| 定日县| 潮安县| 政和县|