Design of an Intellectual Property Rights Certification System Based on a Consortium Blockchain

Abstract

Under the background of economic globalization and the rapid development of the knowledge economy, a large number of intellectual property achievements in China need to flow efficiently in order to give full play to their value; however, the traditional method of rights confirmation has problems, such as complicated operation, low efficiency, high cost, etc., and its practicability is limited. For this reason, this paper aims to construct an efficient intellectual property rights confirmation system by utilizing the characteristics of non-repudiation, non-tampering, traceability and distribution of the consortium chain. By designing smart contracts for user login and registration, rights confirmation, and transaction; combining with the Chameleon Signature algorithm to guarantee transaction security; and ensuring integration with the IPFS to improve the efficiency of file storage, this research develops an IPR confirmation system based on the consortium chain. This system was ultimately successfully deployed and tested, verifying that it operates with good efficiency and correctly realizes the expected functions. The findings show that the proposed system can effectively simplify the operation, provide reliable credentials, guarantee security and storage efficiency, and provide a feasible solution for intellectual property rights.

1. Introduction

In today’s world, as the tide of economic globalization continues to strengthen, the knowledge economy has also experienced rapid development, with a significant increase in intellectual property (IP) outcomes across all industries. In China, there are numerous research institutions and enterprises, which produce a large volume of IP works annually, including academic papers, software copyrights, research reports, and patents. This not only reflects the innovative capabilities of individuals and teams but also has a positive impact on the scientific and technological development within institutions and enterprises, as well as related fields [1]. However, it also poses challenges to traditional intellectual property rights confirmation methods. For example, the sheer volume of IPs results in high confirmation costs; the absence of fully unified and stringent national standards makes it difficult to assess the value of IPs, define infringement forms, and provide evidence for rights protection; and the lack of a fair and efficient reward mechanisms leads to low participation in confirmation activities [2].

These factors collectively result in insufficient liquidity of intellectual property rights outcomes, leading to the waste of existing intellectual property rights outcomes and the allocation of significant resources to redundant development efforts [3]. Therefore, the establishment of an easy-to-operate, trustworthy intellectual property rights confirmation system is both necessary and urgent [4]. Especially in today’s complex online environment, the efficiency and security of intellectual property rights confirmation and transactions must be emphasized [5]. Only in this way can the sharing and utilization of intellectual property rights outcomes be promoted, enabling such outcomes to be implemented more swiftly.

Blockchain technology, with its immutability and decentralization, has been increasingly explored for IP protection [6]. It ensures authenticity and traceability of data [7], prevents fraud caused by tampering, and guarantees non-repudiation, thereby protecting the legitimate rights of creators [8]. Consortium blockchains, in particular, provide high transaction efficiency and enhanced privacy through access control [9,10], making them suitable for secure and transparent IP management [11].

2. Related Work and Contributions

2.1. Related Work

Given the significant advantages of blockchain in intellectual property rights confirmation and privacy protection [12], numerous studies have explored how emerging technologies can be applied to improve IP management from different perspectives. For example, Zhuang et al. [13] proposed a blockchain-based privacy-preserving and traceability identity management scheme (BCPPT) consisting of four phases—initialization, registration, confirmation, and traceability—and employed an improved Shamir secret sharing method. Yuan et al. [14] introduced a privacy-preserving IP identity confirmation method based on zero-knowledge proofs. Feng et al. [15] designed a blockchain-based confirmation mechanism with global dynamic updates (PBAG) which enhances confirmation efficiency and addresses certificate revocation issues. Zhang et al. [16] proposed an anonymous and traceable IP management framework (ATIPM) that combines non-interactive zero-knowledge proofs with threshold secret sharing. These studies highlight the importance of privacy protection in IP authentication; however, they primarily focus on protocol-level cryptographic improvements while leaving scalability and performance issues insufficiently addressed.

In terms of system performance enhancement, several studies have attempted to combine Hyperledger Fabric with the InterPlanetary File System (IPFS). Li et al. [17] proposed a Fabric-based framework for protecting traditional medicine knowledge, in which the IPFS is used to achieve efficient off-chain storage of prescriptions and clinical trial data. Wang et al. [18] developed a Fabric–IPFS hybrid architecture for managing clothing design copyrights, where the IPFS alleviates Fabric’s storage bottlenecks. In addition, blockchain has also been applied to scenarios such as literary work tokenization [19] and academic achievement authentication [20], demonstrating its versatility in copyright registration, licensing, and enforcement. Nevertheless, these solutions are typically validated only in single-machine or small-scale environments, without evaluating Fabric’s performance under realistic distributed deployments.

It is worth noting that Honar Pajooh et al. [21] emphasized the importance of scalable deployment. They constructed a multi-organization, multi-node Fabric network for a secure digital voting system, and their experiments demonstrated that distributed architectures can significantly enhance the throughput, reliability, and transparency of consortium blockchains. This work provides important insights for building robust IP confirmation platforms.

Despite these advances, three limitations remain in existing studies. First, privacy-preserving schemes lack controllable mechanisms to balance anonymity with traceability, which is critical in practical transactions. Second, although the IPFS has been introduced in some solutions, the joint optimization of Fabric network performance and system storage efficiency has not been adequately considered. Third, large-scale performance evaluations of multi-organization Fabric networks remain scarce, leaving uncertainties regarding throughput and latency in real-world deployments.

2.2. Contributions

Motivated by the above research gaps, this paper proposes a blockchain-based IP confirmation and trading system that integrates Hyperledger Fabric, Chameleon Signatures, and the IPFS. The main contributions are as follows:

(1)

Controllable Anonymity and Traceability: We adopt chameleon signatures to achieve a controllable balance between anonymity and accountability. Users remain anonymous under normal conditions, while authorized entities can trace identities in case of disputes, thereby ensuring both privacy and responsibility.

(2)

Hybrid On-Chain/Off-Chain Storage Architecture: By integrating the IPFS with Fabric, the system supports efficient off-chain storage of large IP files while keeping only hash values and metadata on-chain, which significantly reduces blockchain storage overhead and improves scalability.

(3)

Large-Scale Consortium Blockchain Deployment and Evaluation: Unlike prior works that rely on single-machine or small-scale experiments, we implement and evaluate a multi-organization, multi-node, multi-machine Fabric network. Extensive experiments demonstrate the system’s throughput and latency under realistic deployment conditions, validating its scalability and performance.

(4)

Comprehensive IP Protection Framework: By combining privacy-preserving cryptography, hybrid storage, and distributed performance optimization, the proposed system provides an end-to-end solution for IP confirmation, storage, and transaction, thus addressing key challenges in both security and practicality.

The remainder of the paper is structured as follows: In Section 3, we briefly introduce the Hyperledger Fabric, smart contracts, Chameleon Hash, and IPFS technology used in the construction of the system proposed in this paper and conduct a requirements analysis of the intellectual property rights confirmation system based on a consortium blockchain. In Section 4, we describe the implementation of the system’s functionalities and the process used to construct the frameworks. In Section 5, we deploy the system and test its functionalities and performance. Finally, in Section 6, we summarize the contributions of this paper and explore potential directions for future improvements.

3. Critical Technology and Requirements Analysis

3.1. Critical Technology

3.1.1. Hyperledger Fabric

Fabric is the first open-source project designed for consortium blockchain scenarios and one of the earliest top-level projects to join Hyperledger [22]. It features a highly modular and configurable architecture and supports proof-of-concept testing [23]. Additionally, Fabric is the first blockchain platform to support the use of high-level programming languages, such as Java 1.8 and Go, for implementing smart contracts. This token-less model serves as the foundational framework for many industrial blockchain applications in China, spanning various sectors including but not limited to human resources, supply chain management, financial and insurance services, and digital music distribution.

The consensus protocols used in the Fabric system are derived from classic distributed problems, such as Crash Fault Tolerance (CFT), Byzantine Fault Tolerance (BFT), and Raft consensus protocols [24], which differ from the Proof of Work (PoW) consensus protocols used in public blockchains that involve cryptographic tokens [25]. Additionally, Fabric supports pluggable consensus protocols. Based on this feature, the platform can select appropriate consensus protocols for different business scenarios and customize them accordingly. In addition to the pluggable consensus mechanism, Fabric provides a Certificate Authority (CA) certificate system for access control, which helps defend against potential “Sybil attacks” [26]. Fabric overcomes the shortcomings of public blockchain projects, such as the inability to effectively protect private data due to public transactions, inefficient consensus algorithms, and low throughput [27]. It not only achieves the basic capabilities of recording evidence and tracing transaction origins but also has advantages such as fast transaction speeds, low development and usage costs, and easy scalability. As a result, it is widely applied across various fields. Therefore, this paper selects Fabric to build the blockchain network for the system.

3.1.2. Smart Contracts

Smart contracts are decentralized applications that run automatically on a blockchain network [28] and are trusted by the blockchain network. Users can implement the business logic of blockchain applications by writing smart contracts [29]. When the conditions set in the source code are met, the corresponding functions of the smart contract will be automatically executed [30] to complete the relevant tasks. Smart contracts have four lifecycle stages: negotiation, development, deployment, and execution. The process generally proceeds as follows: organizations participating in the system negotiate the terms of the contract, then develop the relevant code; the contract is deployed to Peer nodes, awaiting consensus, approval, and submission; finally, the contract automatically executes based on external conditions, maintaining and updating the system ledger. The entire process is automatically completed by the system, ensuring transparency, non-repudiation, and immutability.

This paper uses Java to develop smart contracts, which are deployed on Peer nodes running in Docker containers. The network application backend calls the chaincode via Fabric-SDK-Java 2.2.3, enabling CRUD operations on the ledger content and the state database CouchDB. In this system, both rights confirmation and transaction operations are handled by smart contracts, significantly enhancing the security of system transactions.

3.1.3. Chameleon Signature

The primary building block of a Chameleon signature is the Chameleon hash function, which operates under the hash-and-sign paradigm [31]. Specifically, the Chameleon hash function is first applied to compute the message digest, followed by the use of a secure digital signature algorithm to generate the final signature [32]. This approach provides three essential properties: non-transferability, unforgeability, and non-repudiation.

A unique feature of the Chameleon hash function is its built-in trapdoor. For users holding the trapdoor, collisions can be efficiently generated; in contrast, for adversaries without the trapdoor, the function preserves the collision resistance and security level of conventional hash functions [33].

Because the recipient possesses the trapdoor, they are able to arbitrarily modify the signed message while still producing a valid signature. Consequently, third parties cannot distinguish between an authorized signature and a forged one, which prevents the transfer of trust beyond the original two parties—thereby ensuring non-transferability. Moreover, even if the recipient attempts to forge a transaction proof by exploiting the trapdoor, such fabricated data cannot be recorded on the consortium blockchain, since all transactions must be endorsed and validated by multiple peer nodes according to the predefined consensus and endorsement policies. This further strengthens security by ensuring that malicious modifications at the individual level cannot propagate into the system.

Meanwhile, since the Chameleon hash function is collision-resistant to attackers, any modification by the recipient can be challenged: the authorizer can provide evidence to demonstrate the illegitimacy of a forged signature. This property guarantees unforgeability.

Finally, as long as the signed data remains intact, the hash output will not change, preventing the authorizer from later generating an alternative valid hash to repudiate the signature. Thus, non-repudiation is preserved [34].

The Chameleon hash function consists of the following five components [35]:

(1)

Generate system parameters: Input a parameter λ to generate system parameters SP.

(2)

Generate keys: Use system parameters SP to generate user key pairs.

(3)

Generate hash values: Input user public keys, message m, and random values r to output hash values h, where h satisfies the conditions in Equation (1).

(4)

Collision computation: Input the user’s private key, message m, random value r, and another message m′, and output r′, calculated using Equation (2).

(5)

Hash verification: Enter the user’s public key, message m, and random value r to verify whether the hash results match.

$$\mathrm{h}=\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}\left(\mathrm{m}, \mathrm{r}\right).$$

(1)

$$\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}\left(\mathrm{m}, \mathrm{r}\right)=\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}\left({\mathrm{m}}^{\prime }, {\mathrm{r}}^{\prime }\right).$$

(2)

This paper adopts the RSA-based Chameleon hash function method [36], and the key generation process is as follows:

(1)

Choose two large prime numbers p and q, and then, compute the modulus n as shown in the Equation (3).

(2)

Calculate the Euler function; the process is shown in Equation (4).

(3)

Selection of a suitable public key index e needs to fulfill the conditions as in Equation (5).

(4)

Calculate the corresponding private key index d, which needs to satisfy certain conditions, such as Equation (6).

$$n=p\ast q.$$

(3)

$$\varphi \left(n\right)=\left(p-1\right)\left(q-1\right).$$

(4)

$$gcd\left(e,\varphi \left(n\right)\right)=1.$$

(5)

$$ed\equiv 1mod \varphi \left(n\right).$$

(6)

The hash function is defined as shown in the Equation (7), where m represents the message and r represents the random number.

$$H\left(m,r\right)=\left(r^e-m\right)mod n.$$

(7)

The process of collision generation using trapdoors is divided into the following three steps:

(1)

Calculate the difference as shown in Equation (8).

(2)

Construct the intermediate value as shown in the Equation (9).

(3)

Solve using trapdoors, as shown in Equation (10).

$$\Delta m=\left(m^{\prime }-m\right)mod n.$$

(8)

$$C=H\left(m,r\right)+m^{\prime }=\left[\left(r^e-m\right)+m^{\prime }\right]mod n=\left(r^e+\Delta m\right)mod n.$$

(9)

$$r^{\prime }=C^{d}mod n.$$

(10)

The verification of the collision is shown in Equation (11), which proves that the collision is valid.

$$\begin{array}{cc}\hfill H\left(m^{\prime },r^{\prime }\right)& =(r^{\prime e}-m^{\prime })mod n\hfill \\ & =\left(C-m^{\prime }\right)mod n\hfill \\ & =\left(r^e+\Delta m-m^{\prime }\right)mod n\hfill \\ & =\left(r^e-m\right)mod n\hfill \\ & =H\left(m,r\right).\hfill \end{array}$$

(11)

For an attacker who does not know the trapdoor, finding $\left({\mathrm{m}}^{\prime }, {\mathrm{r}}^{\prime }\right)$ that satisfies $\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}\left(\mathrm{m}, \mathrm{r}\right)=\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}\left({\mathrm{m}}^{\prime }, {\mathrm{r}}^{\prime }\right)$ is equivalent to solving a random C = $r^e+\Delta m$. That is, solving the RSA problem, the scheme is secure under the RSA assumption.

3.1.4. Inter Planetary File System

The IPFS is a file storage system based on Merkle trees and hash value calculations. It features decentralization, fast access speeds, no impact from single-node failures, and backup disaster recovery capabilities [37]. Additionally, by utilizing content-addressable technology and distributed storage, the file transfer method has been shifted from traditional P2P, ensuring data security and immutability [38]. When a file is uploaded to the system, it is divided into equal-sized blocks, and the hash values of each block are calculated and compiled into a file index table. A secure and unique HashID is then returned to the file uploader. Files are first stored in a local cache folder. When other network nodes access the data, a copy of the file is generated on that node [39]. When users need to download a file, they simply provide the corresponding HashID, and the system automatically assembles and transfers the file [40].

This system combines the Chameleon Signature Algorithm with the IPFS to provide users with relevant credentials for rights confirmation and protection. It also upholds the decentralized nature of blockchain technology.

3.2. Requirements Analysis

3.2.1. Functional Requirements Analysis

To achieve intellectual property rights (IPR) confirmation and transactions based on a consortium blockchain, it is necessary to organize and analyze the entire process of confirmation and transactions, leverage the technical advantages of the consortium blockchain in the IPR confirmation and transaction process, and achieve the application of the consortium blockchain throughout the entire process. The following is a demand analysis of the system.

(1)

IPR Evidence Storage

Users can upload IP documents to the system and annotate information such as the author, field of expertise, content description, and keywords. The system then uploads the files to the IPFS and stores the annotated information and ownership relationships on the consortium blockchain.

(2)

Intellectual Property Query

Users can enter their search terms in the system’s interface. The system will search the consortium blockchain for records that match the query and send the relevant information to the front end in the agreed-upon format. The information is rendered and displayed to the user in paginated results. Users can browse the information as needed and apply for a transaction.

(3)

Intellectual Property Transactions

After users query the IP information they need, they can apply for a transaction for that information. The system displays a form for the applicant to note their intended use, compensation, and other information. The system will notify the IP owner of the transaction request. Upon reviewing the record, the owner may choose to approve or reject the transaction. If rejected, the IP owner may send a note to the applicant outlining their transaction requirements. If approved, the system automatically completes the transaction record and Chameleon Signature process and records the transaction proof in the consortium blockchain.

3.2.2. Non-Functional Requirements Analysis

Since this system is designed to provide users with intellectual property rights confirmation and transaction services, it is essential to ensure the security of the proof documents uploaded by users to the system. Additionally, the primary users of the system are researchers, so the system should be as simple and user-friendly as possible, minimizing the time required for operations while maintaining high efficiency to enhance the efficiency of intellectual property rights confirmation and transactions:

(1)

Security

The system should prevent users from arbitrarily modifying uploaded files and block unauthorized users from downloading files. Additionally, the system should record the transaction process to provide evidence for any potential infringement claims in the future.

(2)

Usability

The user interface should be simple and intuitive, with clear and straightforward buttons and input fields. If complex operations are involved, the system should provide prompts to assist users in using the system.

(3)

Efficiency

The time required to complete relevant operations should be minimized. Under the premise of ensuring security, system-internal steps that do not require user intervention should be processed concurrently whenever possible.

4. The Scheme

4.1. System Function Implementation Model

Based on Hyperledger Fabric, Chameleon Signatures, and the IPFS, this paper proposes an intellectual property rights confirmation model, as shown in Figure 1. The model includes intellectual property rights confirmation, intellectual property rights transfer, and intellectual property rights confirmation, all of which can be operated through the user interface provided by the system.

The data rights confirmation process includes the following steps: (1) Users input their personal identity information to register with the system. After successful registration, the system automatically registers the identity information with the CA of Hyperledger Fabric, obtains the relevant certificate files, and stores them in the system for use in subsequent operations to verify the user’s identity; (2) Users log in to the system using the verification code provided in the registration results; (3) Users upload proof information related to intellectual property rights, which is stored in the IPFS and returns a unique HashID address; (4) The system automatically records the ownership relationship between the user ID and the file HashID.

Data transactions consist of two parts: IP authorization and use, and IP ownership transfer.

Intellectual property authorization and use include: (1) After reviewing the relevant information, the buyer sends a request to use the IP, which includes the buyer’s personal identity information and relevant transaction information for the IP owner to verify; (2) After the IP owner reviews the transaction request, they can confirm the transaction. The system first sets the buyer’s private key as the trapdoor for the Chameleon hash function, then performs calculations on the proof information using the Chameleon hash function, and finally signs the document using the IP owner’s key; (3) The system grants the buyer permission to view and download the relevant files from the IPFS.

The transfer of intellectual property rights includes: (1) After reviewing the relevant information, the buyer sends a purchase request containing their own transaction-related information and personal identity information; (2) After review, the seller reaches an agreement with the buyer and confirms the transaction; (3) The system changes the ownership of the IPFS address HashID corresponding to the intellectual property rights to the buyer’s ID and records the transfer in the blockchain ledger.

Given the decentralized nature of the system, it is not well suited for managing disputes or supporting monetary transfers. Accordingly, the current design focuses solely on recording transaction activities.

The data storage solution adopted in this paper combines online and offline methods, which not only saves blockchain space consumption but also reduces code coupling, completely separating functional functions and file processing. The blockchain stores only file HashIDs and user IDs, among other necessary transaction information, while offline storage holds complete proof document information. Additionally, since the blockchain supports multi-institution and multi-node deployment, the IPFS’s distributed storage ensures that the system will not lose data or crash due to the failure of a single node, significantly enhancing system security, transmission speed, and retrieval efficiency.

4.2. System Architecture Design

The complete architecture of this system can be divided into four parts: storage, network, contract, and business. The specific details are shown in Figure 2.

The storage layer structure is relatively simple, utilizing a combination of the IPFS and CouchDB for both on-chain and off-chain storage [41]. The advantages of the IPFS have been discussed in detail earlier and will not be repeated here. CouchDB is a database that supports rich queries and interacts with Peer nodes in the Fabric network. Like Peer nodes, it is also deployed within Docker. This system configures an independently running CouchDB for each Peer node, thereby avoiding system crashes caused by a single node failure and significantly enhancing system stability.

The network layer maintains communication between nodes to ensure data consistency across all CouchDB instances and ledgers. This system is configured with three Order organizations and three Peer organizations. Each Order organization has one Order node, and each Peer organization has three Peer nodes. Three channels are created, with each organization having one node join the channel, and these nodes are configured as anchor nodes for the channel via configuration files. This design separates user confirmation, transactions, and transfer operations, ensuring they do not interfere with each other. The corresponding CouchDB stores data singly, improving query efficiency. Multiple Order organizations reach consensus through the Raft protocol to jointly provide services for Peer nodes and channels, and can also be deployed across multiple machines, significantly increasing the system’s fault tolerance and facilitating maintenance based on system scale. Compared to Fabric’s test network, this system has a higher degree of decentralization and better fault tolerance.

The contract layer includes smart contracts for user login and registration, rights confirmation, and transactions. The login and registration part is responsible for storing the personal information uploaded by users and applying for certificates from the CA on behalf of users. The rights confirmation part is responsible for managing the ownership relationship between users and the HashID of the proof documents. The transaction component records the information of both parties involved in the transaction and the HashIDs of the relevant proof documents. The smart contracts are written in Java and deployed on Peer nodes running in Docker. The execution process of the code is separated from the consensus mechanism, thereby improving efficiency.

The business layer includes the frontend and APIs accessible by the frontend, which connect to nodes in the consortium blockchain via the gRPC protocol to ensure functional invocation.

4.3. Smart Contract Function Design

The design process of smart contracts involves the design and implementation of functional functions within the chaincode. Users can only perform CRUD operations on data through the chaincode. The design of function interfaces is shown in

Table 1. Smart contract interface.

Contract Name	Interface Name	Function
Sign Up contracts	Register()	User registration, generation of identity documents
	Login()	User login
	Exit()	User logs out
Confirmatory contracts	Add()	User adds a confirmation record
	Delete()	Users delete their own confirmation records
	Query()	Users query their rights records
	Update()	Users modify their own confirmation records
Trading contracts	Apply()	User requests a transaction
	Agree()	User agrees to a transaction
	Query2()	Users check their own transactions
	Query3()	User inquires about intellectual property rights that can be traded

. Through these interfaces, all operations can be automatically executed without any external interference. All transaction records are stored on the blockchain, enabling full traceability to the source. Additionally, the data is tamper-proof and transactions are non-repudiable, ensuring the feasibility and effectiveness of the solution proposed in this paper.

4.3.1. User Registration and Login

User Registration Steps: Users fill out a form with their personal information, then call the Register() interface to submit the information to the system. After recording the relevant information, the system automatically registers the user’s identity with Fabric-CA and returns the user’s password generated by Fabric-CA, which is used as the user’s login password. At the same time, the system generates a key pair for the user, and all this data is recorded in the blockchain.

User Login Steps: The system provides a form for users to enter their account and password, which are then verified.

The complete registration and login process is shown in Figure 3.

4.3.2. Data Rights

The steps for users to claim ownership are as follows: After logging in, users upload files to the IPFS by calling the Add() interface. Once the system obtains the Hash ID returned by the IPFS, it automatically records the ownership relationship between the user ID and the Hash ID on the blockchain and notifies the user that the claim has been successful. Users can then call the Query() interface to view their ownership records. The specific process is shown in Figure 4.

4.3.3. Intellectual Property Licensing

Steps for IP licensing: Users need to obtain relevant IP first query IP information by calling the Query() interface online or learning through offline communication that a certain IP can meet their needs. Then, users find the corresponding IP information in the system, call the Apply() interface, and select the transaction type as “apply for use.” To ensure transaction efficiency, the system directly uses the Chameleon hash function to generate the hash value of the relevant files, employs the applicant’s private key as a trapdoor, and sends the transaction request to the recipient. After the recipient agrees to the authorization by calling the Agree() interface, the system signs the hash result using the recipient’s private key, records it on the blockchain, and grants the applicant access to query the relevant proof documents. This completes the transaction, and both parties can subsequently query the relevant information using the Query2() and Query3() interfaces, respectively. The specific process is illustrated in Figure 5.

4.3.4. Intellectual Property Transfer

Steps for IP transfer: First, consistent with authorized use, applicants also need to obtain the relevant IP information they require through online or offline means. Then, they call the Apply() interface on the system and select the transaction type as “transfer application.” After the recipient calls the Agree() interface to approve the transfer, the system updates the corresponding relationship between identity information and HashID, records it on the blockchain, and notifies the applicant that the transaction is complete. Both parties can also query relevant information by calling the Query2() and Query3() interfaces. The specific process is shown in Figure 6.

5. System Deployment and Testing

5.1. System Development Environment Configuration

This system was developed on the Windows 11 operating system, with the IPFS also running on the local Windows 11 operating system. The local WSL has Ubuntu 22.04.5 installed as the runtime environment for Hyperledger Fabric. By configuring files and setting environment variables, consensus and communication between multiple organizations and nodes within the Hyperledger Fabric network can be achieved, enabling successful installation of smart contracts and the realization of related functionalities.

The remaining software and hardware configurations are shown in

Table 2. System hardware and software configuration.

Hardware Configuration	Software Configuration
CPU: 11th Gen Intel(R) Core(TM) i5-1155G7	Hyperledger Fabric version: 2.4.1
Running memory: 16 GB	Docker version: 26.1.3
	API version: 1.45
	Docker-Compose version: 1.29.2
	Golang: go1.23.6 linux/amd64
	JDK: Oracle OpenJDK18.0.2

.

5.2. System Development

The deployment of the intellectual property rights confirmation system is mainly divided into three parts:

(1)

Packaging and deployment of front-end and back-end application code.

(2)

Installation and deployment of the consortium chain network.

(3)

Deployment of the IPFS.

After the consortium blockchain network was deployed and the nodes started normally, the configuration results could be verified through Hyperledger Explorer [42]. Figure 7, Figure 8 and Figure 9 present the corresponding views: Figure 7 shows the creation of three channels (userchannel, dealchannel, and certificatechannel), Figure 8 displays the peer nodes of the three user organizations, and Figure 9 shows the ordering nodes running Raft consensus. These results confirm that the proposed Fabric network has been successfully implemented.

The consortium blockchain network comprises three user organizations: Org1MSP, Org2MSP, and Org3MSP. Each user organization has three peer nodes named peer0, peer1, and peer2, as shown in Figure 8. The peer0 nodes of each organization join the userchannel and install smart contracts that implement user login and registration operations. The peer1 nodes of each organization join the dealchannel and install smart contracts related to transaction functions. The peer2 nodes of each organization join the certificatechannel and install smart contracts that implement rights confirmation functions. This design allows for parallel processing of transaction requests, avoiding performance bottlenecks caused by a single node failing to process requests in a timely manner. Multiple peer nodes also enhance system stability and efficiency. If a peer node fails to respond due to a fault or high load, other nodes can continue to provide services, thereby enhancing the system’s fault tolerance and response efficiency. Additionally, multiple nodes can support endorsement strategies and complex policy settings. A single channel with a single processing strategy can also achieve business data isolation, ensuring security and confidentiality.

In addition to the three user organizations, the network also has three ordering organizations: Org1OrdererMSP, Org2OrdererMSP, and Org3OrdererMSP. Each ordering organization has an ordering node, as shown in Figure 9. The three ordering nodes reach a Raft consensus agreement and jointly provide services to the network.

This multi-organization design offers the following advantages over traditional single-organization or even single-node approaches:

(1)

Higher degree of decentralization

Multiple organizations can check and balance each other, making the trust foundation of the entire system more robust. A single organization owning one or more ordering nodes is essentially a centralized control model, and the failure, attack, or internal issues of that organization could cause the entire ordering service to collapse.

(2)

Improved system fault tolerance

In a multi-organization setup, even if an organization experiences downtime due to abnormal conditions, the sorting nodes of other organizations can continue to operate. Transaction traffic can automatically be redirected to other functioning nodes, ensuring normal transaction sorting and stable network operation. Assuming the number of nodes is n = 2f + 1, the system’s fault tolerance value is f. Additionally, multiple organizations can be deployed across different network environments and hardware infrastructures, further reducing the likelihood of simultaneous failures. Furthermore, the system’s ability to counter malicious nodes is enhanced. If a malicious node attempts to disrupt transaction order—such as by intentionally delaying or tampering with transaction information—in a multi-organization environment, normal nodes from other organizations can detect such abnormal behavior and take corresponding actions, such as rejecting the malicious node’s transaction proposals and isolating it, thereby enhancing the system’s fault tolerance and security.

(3)

Enhancing system scalability

As business grows and the number of network participants increases, the multi-organization approach is more conducive to adding new organizations to share the load. Since different organizations may have different resource conditions and business requirements, they can contribute corresponding node resources based on their own circumstances.

After the IPFS is installed and started, its built-in user interface can be accessed via the pre-configured port, as shown in Figure 10. Through this interface, users can manage file uploads and downloads, analyze network traffic and real-time bandwidth, view uploaded file information, and monitor other data nodes in the system used for backup, ensuring system security and file integrity.

5.3. System Function Demonstration

After the system deployment is complete, users can access the system’s front-end interface via a web browser. Users can first access the registration and login interface, as shown in Figure A1 and Figure A2. When logging in, users must provide the account and password generated by the system after successful registration. After the system verifies that the format is correct and the account and password match, it automatically switches to the user operation interface. When registering, users must provide their name and ID number. After verifying that the input data format is correct, the information matches, and the account has not been registered, the system automatically generates the user’s account, password, and key pair and displays a pop-up notification, as shown in Appendix A, Figure A3. To enhance data security, the relevant information is presented only once and cannot be retrieved later. After memorizing it, users may click the “OK” button to proceed to the user interface.

The user interface, as shown in Figure A4, displays the user’s verified records by default. For each record, the system provides a download button and a delete button. When the user clicks the button, the system will complete the appropriate action. If a user wishes to add a new intellectual property rights record, they can click the “Add New Record” button. Upon clicking, the user is redirected to the new record creation page, as shown in Figure A5. The page provides a form for the user to input descriptive information related to the IP, including the author of the IP and the field to which it belongs. The user must also upload supporting documentation. After verification, the system writes a new record to the blockchain and sends the uploaded file to the IPFS.

Users can also switch between related display interfaces via the sidebar to view IP information available for trading, check the status of transactions they have initiated, and review transaction information submitted to them.

When users click on “Search” in the sidebar, they can view IP description information uploaded by other users. The system defaults to searching all IP information, as shown in Figure A6. Buyers can enter IP classification information and IP description information to select IP information they are interested in trading. If they wish to proceed with a transaction, buyers can click the “apply for use” button. Upon clicking the button, a transaction initiation dialog box will appear, where buyers can enter transaction notes and intended amount information, as shown in Figure A7, for the IP owner to review. After entering their intended amount and notes, users can click the “Confirm” button to formally submit the transaction application.

If users wish to check whether the transactions they have initiated have been approved by the intellectual property rights owner, they can click on the “Transaction (Apply)” in the sidebar. The system will display the records of transactions initiated by the user, with pending approval requests displayed by default. Users can enter notes to search for relevant transaction records, or switch between transaction types and statuses to query different transactions, as shown in Figure A8.

For users who have received a transaction request, they can click on “Transaction (Receive)” in the sidebar to view transaction requests sent to them by other users. Users can enter notes to search for related transaction records, or switch between transaction types and statuses to query different transactions, as shown in Figure A9. The system also provides “agree” and “refuse” buttons for users to change the status of the transaction. When a user clicks either button, a dialog box will appear, allowing the user to enter notes for the transaction, which will be returned to the transaction initiator for review.

5.4. System Performance Evaluation

Based on the characteristics of the system designed in this paper, the primary factors users perceive when using the system are the response speeds during queries and rights confirmation. Since transactions involve waiting for the applicant’s review, users have psychological expectations regarding the time required for such operations. Therefore, in terms of performance testing, this paper focuses on testing the average latency for data uploads and information queries. Data upload latency refers to the time required for code execution from the moment the user clicks to confirm the call to the Add () interface until the system responds with a successful completion. Information query latency refers to the time required for code execution from the moment the user clicks to query until the results are displayed.

The data upload latency was tested by uploading an 8MB file multiple times, recording the time taken for code execution, calculating the average time every five tests, and conducting a total of 50 tests. The relevant test results are shown in Figure 11 and Figure 12.

The test results show that even though the first file upload involves establishing a connection with the IPFS and initializing system-related configurations, resulting in additional latency due to node initialization and connection overhead, the upload of an 8 MB file can still be completed in just 176 milliseconds. Once the node is initialized, subsequent uploads avoid this overhead and therefore complete significantly faster. Subsequent uploads all take less than 80 milliseconds. The average latency for system data uploads shows a gradual decrease and stabilization trend as the number of tests increases, ultimately approaching 45 milliseconds.

The latency of rights confirmation information queries was tested by adding 5,000 test records and then conducting query efficiency tests using three different search methods: direct query of all records, fuzzy search using IP description terms, and fuzzy search using IP domain information. The time consumed by code execution was recorded for each query, and the average time was calculated every five queries, with a total of 50 tests conducted. The relevant test data results are shown in Figure 13 and Figure 14.

From the test results, it can be seen that in multiple tests of the three query methods, the longest latency was less than 800 milliseconds. For all recorded queries, the average latency fluctuated around 450 milliseconds; the average latency for fuzzy searches based on IP description information fluctuated around 300 milliseconds; and the average latency for fuzzy searches based on IP fields fluctuated around 260 milliseconds.

5.5. Comparative Experiments

To evaluate the performance of our scheme, we conducted comparison experiments using Hyperledger Caliper on the Fabric network [43]. The benchmark was executed with three workers, each representing a concurrent client. In each round, 1000 transactions were submitted at a fixed rate of 200 TPS, thereby evaluating the network under concurrent transaction load and enabling the measurement of throughput and latency in a multi-client environment.

Table 3. Comparison of Fabric network configurations.

Scheme	Orderer Organization	Nodes per Orderer Organization	Peer Organization	Nodes per Peer Organization	Channel	Note
Ours	3	1	3	3	3	Three nodes from each peer organization join different channels
[44]	1	1	2	2	1
[45]	1	1	2	1	1

summarizes the differences among the three network configurations, including the number of orderer and peer organizations, the number of nodes per organization, and the channel design.

As illustrated in Figure 15, our scheme achieves the lowest latency compared with the reference configurations [44,45]. The detailed numerical results are provided in Appendix B,

Table A1. Latency data collected from three Fabric network configurations.

Operation	Scheme	Max Latency (s)	Min Latency (s)
Create Deal	Ours	0.22	0.04
	[44]	0.65	0.11
	[45]	9.33	0.22
Query Deals	Ours	1.97	0.04
	[44]	52.13	0.26
	[45]	48.83	0.26
Agree Deals	Ours	0.18	0.03
	[44]	0.54	0.09
	[45]	14.59	0.5
Refuse Deals	Ours	0.14	0.03
	[44]	1.01	0.1
	[45]	14.78	0.2
Add Certificates	Ours	0.14	0.03
	[44]	4.29	1.16
	[45]	13.46	1.71
Query Certificates	Ours	0.11	0.02
	[44]	43.01	0.34
	[45]	51.44	0.31
Transfer Certificates	Ours	2.05	0.04
	[44]	3.28	0.22
	[45]	12.02	0.22
Delete Certificates	Ours	0.15	0.04
	[44]	9.16	0.16
	[45]	32.5	0.27
Add Users	Ours	0.96	0.04
	[44]	4.3	1.21
	[45]	13.43	1.77
Query Users	Ours	0.02	0
	[44]	0.04	0
	[45]	0.02	0

, which show that our scheme consistently outperforms the baselines. For example, in the Query Deals operation, our scheme records a maximum latency of only 1.97 s, whereas [44,45] show much higher values of 52.13 s and 48.83 s, respectively. Similarly, in Add Certificates, our scheme reduces the maximum latency to 0.14s compared with 4.29 s in [44] and 13.46 s in [45]. These results confirm that our architecture ensures stable and efficient transaction processing under concurrent workloads.

The throughput results in Figure 16 further demonstrate that our architecture provides superior scalability and performance. The corresponding values are listed in

Table A2. Throughput data collected from three Fabric network configurations.

Operation	Scheme	Send Rate (TPS)	Throughput (TPS)	Success Rate (%)
Create Deal	Ours	130.3	129.7	99.53952417
	[44]	111.9	108.7	97.14030384
	[45]	108.7	59.5	54.73781049
Query Deals	Ours	200.2	190.7	95.25474525
	[44]	200.1	17.5	8.745627186
	[45]	200.2	18.6	9.290709291
Agree Deals	Ours	163	162.3	99.57055215
	[44]	116.6	115.3	98.88507719
	[45]	134	55.9	41.71641791
Refuse Deals	Ours	160.7	159.4	99.1910392
	[44]	113.8	109.6	96.30931459
	[45]	139.7	52.3	37.43736578
Add Certificates	Ours	153.7	152.6	99.2843201
	[44]	116.7	79.9	68.46615253
	[45]	135.4	56.2	41.50664697
Query Certificates	Ours	200.3	199.5	99.6005991
	[44]	200.2	20.8	10.38961039
	[45]	200.2	17.7	8.841158841
Transfer Certificates	Ours	145.6	113	77.60989011
	[44]	117	88.7	75.81196581
	[45]	162.8	71.5	43.91891892
Delete Certificates	Ours	150.2	149.3	99.40079893
	[44]	127.5	59.9	46.98039216
	[45]	85.5	24.1	28.1871345
Add Users	Ours	131.8	131.2	99.5447648
	[44]	115.4	78.9	68.37088388
	[45]	118	50.1	42.45762712
Query Users	Ours	200.2	200.1	99.95004995
	[44]	200.3	200	99.85022466
	[45]	200.2	199.8	99.8001998

. For instance, in Query Certificates, our scheme achieves a throughput of 199.5 TPS with a success rate of 99.6%, while [44,45] reach only 20.8 TPS (10.39% success) and 17.7 TPS (8.84% success), respectively. Similarly, for Delete Certificates, our scheme sustains 149.3 TPS throughput with 99.4% success, significantly outperforming the 59.9 TPS (46.98% success) of [44] and the 24.1 TPS (28.19% success) of [45].

Overall, the experimental results indicate that the proposed scheme not only reduces latency but also sustains higher throughput under concurrent workloads. By leveraging a multi-channel and multi-organization design, our architecture improves resource utilization and ensures stable performance, thereby demonstrating better scalability and robustness compared to the reference configurations.

6. Conclusions and Future Work

In today’s world, the knowledge economy is developing rapidly, and all industries are producing a large number of IP achievements. To ensure that IP achievements are applied more widely and implemented more quickly, and to avoid resource waste caused by duplicate development, it is necessary to develop an efficient and secure intellectual property rights confirmation system to protect the legitimate rights and interests of IP owners.

Intellectual property rights confirmation is a crucial foundation for enhancing the innovative enthusiasm of researchers and facilitating the implementation of IP achievements. However, traditional methods often face issues such as high enforcement costs, time-consuming operations, and limited credibility of third parties. This paper is based on the application of blockchain technology in the field of intellectual property rights confirmation. We conducted research on intellectual property rights confirmation technology based on blockchain, designing a system model that combines the RSA Chameleon Signature Algorithm with a blockchain-based intellectual property rights confirmation system supporting distributed storage, and we implemented the designed system through code. This research provides technical and engineering support for the application of blockchain technology in the field of intellectual property rights confirmation. The main contributions of this research work include the following:

(1)

We organized the processes of intellectual property rights confirmation and transactions, analyzed the application of blockchain in the intellectual property rights confirmation and transaction process, designed the required blockchain network structure for the system, and wrote related strategy configuration files. We also mapped out the functional processes for users to perform confirmation and transactions and constructed a complete confirmation system model based on the basic functional requirements of users.

(2)

We conducted requirement analysis and detailed design for the blockchain-based intellectual property rights confirmation system, establishing an overall architecture composed of Java 1.8 + Vue 2.6.12 + Hyperledger Fabric 2.4.1 + IPFS 0.34.1. We designed user interfaces for login, registration, and operations, ensuring a clean interface with simple and clear user steps. Except for necessary data information, all other operations are automatically completed by the system. For operations that support parallel processing, parallel operations are utilized to enhance system efficiency.

(3)

By integration with the IPFS, we achieved combined on-chain and off-chain data storage, thereby improving the efficiency of data operations while saving on-chain space. Additionally, the stability and security of file downloads and uploads are ensured. By introducing the Chameleon Signature Algorithm, transaction security is guaranteed, and both parties involved in the transaction cannot repudiate the actual authorization actions.

(4)

We developed, deployed, and tested an intellectual property rights confirmation system based on a consortium blockchain. As observed through the blockchain browser and IPFS front-end interfaces, both the blockchain network and IPFS are operating normally. Test results indicate that the system performs well and functions as intended, fully meeting user requirements for file uploads and queries. All relevant technologies have been correctly implemented, and the rights confirmation and transaction functionalities have been properly developed, fulfilling the requirements outlined in the requirements analysis.

In future work, we will focus on two main directions. First, we plan to design incentive mechanisms for rights confirmation, encouraging broader participation and promoting the sharing of intellectual property under secure conditions. Second, we will explore the integration of arbitration and digital watermarking into proof materials, enabling more effective resolution of infringement disputes while maintaining decentralization. With arbitration introduced, the system can also support handling transaction amounts and related disputes, thereby enhancing its practical applicability. With further research and the incorporation of advanced technologies, blockchain’s potential in intellectual property protection can be more fully realized to safeguard innovation and scientific progress.