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 共识算法等模块至今仍未发布，可借鉴的应用实例也不多。本文设计的版权管理系统还存在不足，特别是在用户身份管理与共识算法实现两方面与实际应用还有一定距离，将在后续研究中不断改进完善。