Knowledge resource reliable protection method based on alliance chain network

Abstract

The application discloses a knowledge resource reliable protection method based on a consortium chain network, and comprises the following steps: an IPFS private network containing seven nodes is built, and an optimal storage node and a backup node are selected; a consortium chain network is established; based on an ERC-1155 standard, a non-fungible token for a knowledge resource file is established and stored in the consortium chain network, and a user is allowed to perform an operation on the non-fungible token, and meanwhile, non-fungible token data and transaction records generated by the operation are stored in nodes of the consortium chain network; all transaction records in the nodes of the consortium chain network are interacted with a public infrastructure network BSN. Therefore, the problem that the rights and interests of a user about a knowledge resource file are infringed is solved.

Description

Technical Field

[0001] This invention belongs to the technical field of knowledge resource storage methods, and relates to a reliable protection method for knowledge resources based on consortium blockchain networks. Background Technology

[0002] With the continuous development of network information technology, more and more knowledge resources are being stored electronically. Due to the massive increase in electronic data, many universities and institutions are hosting their data on third-party cloud servers to save local storage space. Cloud servers provide users with flexible and convenient services. However, cloud servers use a centralized storage method. When a large number of data requests are received concurrently, cloud servers may experience high latency, high error rates, or low-quality responses due to server overload, insufficient memory resources, and insufficient thread resources, leading to a series of cascading failures and impacting user experience. In practical applications, data on cloud servers lacks control; malicious cloud service providers can directly extract data without user detection, resulting in the leakage and loss of user information. Data stored on cloud servers cannot detect redundant information; as data continues to increase, there may be significant redundancy, wasting storage space. Cloud servers can only utilize the computer hardware resources within the cluster and cannot utilize additional computer hardware resources outside the cluster, resulting in a certain waste of hardware resources. Furthermore, the centralized storage of knowledge resource data in cloud services makes operations on the data invisible to users, making it easy for the data to be copied or forwarded multiple times, failing to protect users' rights regarding knowledge resource files. Summary of the Invention

[0003] The purpose of this invention is to provide a reliable method for protecting knowledge resources based on a consortium blockchain network, which solves the problem in the prior art that it is impossible to guarantee that users' rights and interests regarding knowledge resource files are not infringed.

[0004] The technical solution adopted in this invention is a reliable protection method for knowledge resources based on a consortium blockchain network, comprising the following steps:

[0005] Step 1: Build an IPFS private network with 7 nodes. The node with the largest actual storage space in the IPFS private network is used as the storage node. When a file is successfully uploaded to the IPFS network, a hash value based on the unique identifier of the content is returned. The node with the largest actual storage space among the nodes other than the storage node is used as the backup node.

[0006] Step 2: In Hyperledger Fabric, set up 3 Orderer nodes and 2 organizations, configure 2 nodes for each organization, and generate certificate files and genesis blocks for all nodes. Mount the certificate files and genesis block files as data volumes in the corresponding 7 containers to obtain the consortium blockchain network.

[0007] Step 3: Based on the ERC-1155 standard, establish a non-fungible token for knowledge resource files and store it in the consortium blockchain network. Allow users to perform operations on the non-fungible token, and store the non-fungible token data and transaction records generated by the operations in the nodes of the consortium blockchain network.

[0008] Step 4: Interact all transaction records in the nodes of the consortium blockchain network with the public infrastructure network (BSN).

[0009] The invention is further characterized by:

[0010] Step 2 specifically includes the following steps:

[0011] Step 2.1: Download Hyperledger Fabric and modify the crypto-config.yaml configuration file; under the OrdererOrgs option, configure 3 Orderer nodes in Specs, and under the PeerOrgs option, configure two organizations: Org1 and Org2. Org1 is an authoritative organization, and its users have the authority to initialize contracts and add chaincode. Configure 2 nodes in the Template option within each organization, and divide the four nodes into endorsement nodes, master nodes, and slave nodes according to their roles.

[0012] Step 2.2: Use the cryptogen tool to generate certificate files for all nodes in the consortium blockchain network;

[0013] Step 2.3: Use configtxgen-profile SampleMultiNodeEtcdRaft-outputBlock <genesisblock-path>The command generates the genesis block;

[0014] Step 2.4: Mount the certificate file and genesis block file as data volumes in the corresponding 7 containers to obtain the consortium blockchain network. Each container includes one node in the consortium blockchain network and one IPFS node.

[0015] Step 3 involves operations related to non-fungible tokens, including batch generation of different types of non-fungible tokens, destruction of non-fungible tokens, transfer of non-fungible tokens, and return of the number of non-fungible tokens. Before these operations, identity verification and chaincode initialization are performed.

[0016] The process of generating non-fungible tokens in step 3 is as follows:

[0017] Write the main function and import the interface of the ERC-1155 standard;

[0018] Call the GetClientIdentity().GetMSPID() function to obtain the client identity. If the node belongs to a node in Org1, the chaincode initialization operation is allowed; otherwise, the chaincode initialization operation is refused.

[0019] Using the hash value returned in step 1 and the summary information of the knowledge resource to be protected, a non-fungible token for the knowledge resource file is generated; and the user address and the non-fungible token are recorded in the nodes of the consortium blockchain network.

[0020] The process of batch generating different types of non-fungible tokens is as follows: Define two arrays, id and amount, with the same size n. The element k in id represents the type of non-fungible token, and the element v in amount represents the quantity of the corresponding non-fungible token. Call the MintBatch function to generate a list of non-fungible tokens based on the user address, non-fungible tokens, id[i], and amount[i].

[0021] The process of destroying non-fungible tokens is as follows: If a user address holds one type of non-fungible token, then the non-fungible tokens to be destroyed are found based on the user address and reduced to a specified number; if a user address holds at least two types of non-fungible tokens, then the list of non-fungible tokens held by the user is found based on the user address, the entire list is traversed, the type of non-fungible token to be destroyed is found, and the number of non-fungible tokens to be destroyed is reduced to a specified number.

[0022] The process of batch destruction of non-fungible tokens is as follows: If a user address holds at least two types of non-fungible tokens, the list of non-fungible tokens held by the user is found based on the user address. The entire list is traversed, and when k is the type of non-fungible token to be destroyed, the number of v corresponding to k is reduced to the specified number.

[0023] The process of transferring non-fungible tokens is as follows: it is determined whether the sender's user address is the same as the receiver's user address. If they are the same, the operation is not allowed. If they are different, the specified non-fungible token is found based on the sender's user address, and its quantity is reduced by v. Then, the specified type of non-fungible token is found based on the receiver's user address, and its quantity is increased by v.

[0024] The process of batch transferring non-fungible tokens is as follows: Iterate through the sender's id array and amount array, and decrease the quantity of the corresponding type of non-fungible token by v. Then iterate through the receiver's id array and amount array. If the receiver holds non-fungible tokens of that type, increase the quantity of the corresponding non-fungible tokens by v. If the receiver does not hold non-fungible tokens of that type, record the type and quantity of this non-fungible token in the receiver's id array and amount array.

[0025] The interaction includes periodic interaction and quantitative interaction. The method for periodic interaction is as follows: set a timer, and when the timer reaches the specified time, call the Set method to deliver all transaction information in the self-built chain to BSN for storage.

[0026] The quantitative interaction method is as follows: set a constant s, count the total number of transaction information m, and when s equals m and the timer has not reached the specified time, directly deliver the m newly generated transaction information in the self-built chain to BSN for storage through the Set method, and at the same time reset the timer and start counting again.

[0027] The beneficial effects of this invention are as follows: The method for reliable protection of knowledge resources based on a consortium blockchain network establishes an IPFS private network, where only nodes possessing the network key can join, preventing unauthorized users from viewing or leaking private data and achieving reliable storage of knowledge resource files. It utilizes the InterPlanetary File System (IPFS) to achieve distributed storage of knowledge resource files, ensuring their permanence, redundancy removal, and immutability. Through peer-to-peer distributed storage technology, the computer disk resources of all nodes in the IPFS network can provide services, while selecting the optimal node ensures load balancing. The consortium blockchain network allows only authenticated users from universities or institutions to join and enjoy its services, isolating unauthorized users and preventing data theft. Based on the ERC-1155 standard, a non-fungible token for knowledge resource files is established and stored in the blockchain network, allowing users to interact with the non-fungible token. Batch operations ensure ownership of knowledge resource files while reducing direct interaction with the blockchain. All operation records and results are stored in a self-built blockchain network, and decentralized storage of transaction records is achieved through maintenance of all nodes, avoiding single points of failure. User-uploaded knowledge resource files are stored in IPFS (off-chain storage), while their unique IPFS index (hash value) along with non-fungible tokens are stored on the blockchain network (on-chain storage). This dual-storage model reduces data accumulation and maintenance costs. All transaction information in the self-built blockchain network interacts with the Public Infrastructure Network (BSN), allowing all users to view their own status or the status of all transactions in the network at any time, preventing data leaks by malicious users and ensuring the immutability and traceability of data stored on the blockchain. This solves the problem of protecting users' rights to knowledge resource files from infringement. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the structure of the consortium blockchain network in the knowledge resource reliable protection method based on the consortium blockchain network of the present invention;

[0029] Figure 2 This is a flowchart of the method for reliable protection of knowledge resources based on consortium blockchain networks in this invention, which establishes non-fungible tokens;

[0030] Figure 3 This is the initialization flowchart of the knowledge resource reliable protection method based on consortium blockchain network in this invention;

[0031] Figure 4 This is a flowchart of the process for destroying non-fungible tokens in the knowledge resource reliable protection method based on consortium blockchain network of the present invention;

[0032] Figure 5 This is a flowchart of the transfer of non-fungible tokens in the knowledge resource reliable protection method based on consortium blockchain network of the present invention;

[0033] Figure 6 This is a flowchart illustrating the method for reliable protection of knowledge resources based on consortium blockchain networks in this invention, which returns the number of non-fungible tokens. Detailed Implementation

[0034] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0035] A reliable method for protecting knowledge resources based on consortium blockchain networks includes the following steps:

[0036] Step 1: Set up an IPFS private network and select the optimal node for storing and backing up files within the IPFS private network;

[0037] Step 1.1: Download the key creation tool ipfs-swarm-key-gen and generate a key file. Run 7 IPFS nodes in Docker, initialize the IPFS network, and place the key file in the IPFS default configuration folder (~ / .ipfs) for each node. Use the ipfs id command to view the address of the local node, and then use ipfs bootstrap add. <id>The command connects all nodes sequentially to obtain the IPFS private network;

[0038] Step 1.2: When a user uploads a file, the node with the largest actual storage space is designated as the storage node. The file is stored in the local repository of the current node. At the same time, the distributed hash table in the entire network is updated. When the file is successfully uploaded to the IPFS network, a hash value based on the unique identifier of the content is returned. The node with the largest actual storage space among the nodes other than the storage node is designated as the backup node. As long as the storage node or any of the backup nodes is active in the network, the file can be retrieved, avoiding the single point of failure problem.

[0039] Step 2: In Hyperledger Fabric, set up 3 Orderer nodes and 2 organizations, with 2 nodes configured in each organization. Generate certificate files and genesis blocks for all nodes. Mount the certificate files and genesis block files as data volumes in the corresponding 7 containers to obtain the consortium blockchain network, such as... Figure 1 As shown;

[0040] Step 2.1: Download Hyperledger Fabric and modify the `crypto-config.yaml` configuration file. This file includes the certificates, identities, and TLS certificate generation paths for each node. Under the `OrdererOrgs` option, configure three `Orderer` nodes in the `Specs` section. These nodes are used to sort all transactions and generate new blocks. Under the `PeerOrgs` option, configure two organizations: `Org1` and `Org2`. `Org1` is an authoritative organization with users having the authority to initialize contracts and add chaincode, while `Org2` is a general organization with lower user privileges. Within each organization, configure two nodes in the `Template` option. Divide these four nodes into endorser nodes, master nodes, and slave nodes according to their roles. Endorser nodes are responsible for endorsing transactions and simulating transaction results. Master nodes are responsible for broadcasting the latest block information to other nodes within the organization and interacting with `Orderer` nodes. Slave nodes are responsible for receiving transaction information from clients. The peer0 node in both the Org1 and Org2 organizations is designated as the master node to communicate with the Orderer node. This master node is also the endorser node within the organization. The other peer node is designated as the slave node.

[0041] Step 2.2: Use the cryptogen tool to generate certificate files for all nodes in the consortium blockchain network;

[0042] Step 2.3: Use configtxgen-profile SampleMultiNodeEtcdRaft-outputBlock <genesisblock-path>The command generates a genesis block;

[0043] Step 2.4, the certificate file and the genesis block file are mounted as data volumes in the corresponding 7 containers respectively, and the consortium chain network is obtained; the 7 containers correspond to 7 nodes and 7 IPFS nodes in the consortium chain network.

[0044] In step 2, the 3 nodes in the Orderer organization are Orderer1 node, Orderer2 node and Orderer3 node respectively. The 3 Orderer nodes adopt the raft consensus protocol, specifically: in a term, there will be only one leader node, and the rest are follower nodes. When the leader node receives a message from the master node, it first sends the message to all follower nodes, and the follower nodes receive the message and perform log replication, and then respond to the message from the leader node, indicating that the message is received correctly and log replication is performed. The leader node accepts more than half of the confirmation information from the follower nodes, randomly records the client's message in the ledger, updates the network state, and sends it to all follower nodes again to indicate that the ledger state has been updated. The follower nodes update their ledger state immediately after receiving the information, at which time the master node message is recorded in the blockchain network, and this record cannot be tampered with. When the follower node does not receive the heartbeat message from the leader node within the specified time, it will automatically become a candidate node, and then send voting information to all nodes. The candidate node with the highest number of votes will be elected as the leader node in the next term.

[0045] The interaction protocol of Org1 organization and Org2 organization is: when the follower node receives a message from the client, it first sends the message to the endorser node for endorsement, and the endorser node returns the endorsed message to the follower node together with the result of the simulated transaction. The follower node then sends the endorsed message together with the result of the simulated transaction to the master node, which interacts with the Orderer node. The specific process is as described above for the interaction protocol between the 3 Orderer nodes. When the new record has been recorded in the blockchain network, the Orderer node will send the new ledger state to the master node, which will broadcast it to the rest of the nodes in the organization through the Gossip protocol. At this point, the ledger state of all nodes in the organization is updated to the latest state.

[0046] Step 3: Based on the ERC-1155 standard, establish a non-fungible token (NFT) for knowledge resource files and store it in the consortium blockchain network. Allow users to perform operations on the NFT, storing the NFT data and transaction records generated by the operations in the nodes of the consortium blockchain network. Before any operation on the NFT, identity verification and initialization are performed. Operations on the NFT include batch generation of different types of NFTs, destruction of NFTs, transfer of NFTs, and return of the number of NFTs.

[0047] The process of establishing a non-fungible token for knowledge resource documents is as follows: Figure 2 As shown:

[0048] a. Write the main function and import the interface of the ERC-1155 standard;

[0049] b. Figure 3 As shown, the GetClientIdentity().GetMSPID() function is called to obtain the client identity. If the node belongs to a node in Org1, the initialization operation is allowed; otherwise, the initialization operation is refused. The value of the key namekey is obtained from the world state. If the value exists, it means that the chaincode initialization operation has been executed and is not allowed to be executed again. If it does not exist, the key-value pair with the key namekey and the value name is stored in the consortium blockchain network.

[0050] c. Call the Mint function to generate a random 256-bit private key, and then use the Elliptic Curve Digital Signature Algorithm ECDSA-secp256k1 to map the private key (32 bytes) into a public key (65 bytes); use the returned hash value and the summary information of the knowledge resource to be protected to generate a non-fungible token for the knowledge resource file; record the user address wallet (public key) and the non-fungible token in the nodes of the consortium blockchain network;

[0051] The method for batch generating different types of non-fungible tokens is as follows: First, perform identity verification and initialization according to the method in step b. Then, define two arrays id and amount with the same size n. The element k in id represents the type of non-fungible token, and the element v in amount represents the quantity of the corresponding non-fungible token. Call the MintBatch function to generate a list of non-fungible tokens based on wallet, NFT, id[i], and amount[i], and store it in the nodes of the consortium blockchain network, where 0≤i<n.

[0052] The process of destroying nonfungible tokens is as follows: Figure 4 As shown, the process begins with identity verification and initialization as described in step b. If the user address holds one type of non-fungible token, the Burn function is called to find the non-fungible tokens based on the user address and reduce them to a specified quantity, while simultaneously recording them in the nodes of the consortium blockchain network. If the user address holds at least two types of non-fungible tokens, the BurnBatch function is called to find the list of non-fungible tokens held by the user based on the user address, traverse the entire list, find the type of non-fungible token to be destroyed, reduce it to a specified quantity, and simultaneously store it in the nodes of the consortium blockchain network.

[0053] The process of batch destruction of non-fungible tokens is as follows: First, the identity is confirmed and initialized according to the method in step b. Then, the BurnBatch function is called to find the list of non-fungible tokens held by the user based on the user address. The entire list is traversed. When k is the type of non-fungible token to be destroyed, the number of v corresponding to k is reduced to the specified number, and it is stored in the node of the consortium blockchain network.

[0054] The process of transferring non-fungible tokens is as follows: Figure 5 As shown, first, identity verification and initialization are performed according to the method in step b. It is determined whether the sender's address is the same as the receiver's address. If they are the same, the operation is not allowed. If they are different, the TransferFrom function is called. If it is determined that the chaincode has been initialized and the operator is authorized to perform the operation, the specified non-fungible token is found according to the sender's address, and its quantity is reduced by v, where k ≤ the total number of non-fungible tokens n. Then, the specified type of non-fungible token is found according to the receiver's address, and its quantity is increased by v. At the same time, it is stored in the node of the consortium blockchain network.

[0055] The process of batch transferring non-fungible tokens is as follows: First, identity verification and initialization are performed according to the method in step b. Then, the TransferFromBatch function is called to iterate through the sender's id array and amount array, reducing the quantity of the corresponding type of non-fungible token by v. Then, the receiver's id array and amount array are iterated through. If the receiver holds non-fungible tokens of this type, the quantity of the corresponding non-fungible tokens is increased by v. If the receiver does not hold non-fungible tokens of this type, the type and quantity of this non-fungible token are recorded in the receiver's id array and amount array, and stored in the nodes of the consortium blockchain network.

[0056] The process of returning the number of non-fungible tokens is as follows: Figure 6 As shown, first, perform identity verification and initialization according to the method in step b, call the BalanceOf or BalanceOfBatch function, and return the number of non-fungible tokens of a specified type or different types according to the user address, and store them in the nodes of the consortium blockchain network.

[0057] The specific storage method for non-fungible token data and transaction records generated by operations is as follows: Define a TransferSingle structure. When calling the Mint, MintBatch, Burn, BurnBatch, TransferForm, and TransferFormBatch operations in step 3, the SetEvent function first stores each non-fungible token data and its transaction records generated by operations in the TransferSingle structure in the form of key-value pairs. Then, the TransferSingle structure is stored in the nodes of the consortium blockchain network. The key is a string constant used to retrieve NFT data and transaction records stored in the self-built chain, and the value is a structure.

[0058] Step 5: Interact all transaction information in the consortium blockchain network with the public infrastructure network (BSN). Specifically, the interaction includes periodic interaction and quantitative interaction. The periodic interaction method is as follows: set a timer, and when the timer reaches the specified time, deliver all transaction information in the self-built chain to the BSN for storage by calling the Set method. The quantitative interaction method is as follows: set a constant k, count the number of all transaction information n, and when n equals k and the timer has not reached the specified time, directly deliver the n newly generated transaction information in the self-built chain to the BSN for storage by calling the Set method, and at the same time reset the timer and start counting again.

[0059] Through the above methods, the knowledge resource reliable protection method based on a consortium blockchain network of the present invention establishes an IPFS private network, where only nodes with network keys can join the IPFS network, preventing unauthorized users from viewing or leaking private data on the network and achieving reliable storage of knowledge resource files; it achieves distributed storage of knowledge resource files through the InterPlanetary File System (IPFS), realizing permanent, redundancy-free, and tamper-proof storage of knowledge resource files; through peer-to-peer distributed storage technology, all computer disk resources of all nodes in the IPFS network can provide services to the network, while selecting the optimal node ensures load balancing among nodes in the network; it establishes a consortium blockchain network, where only users whose identities have been verified and who belong to universities or institutions can join the blockchain network and enjoy the services provided by the network, isolating unauthorized users outside the blockchain network and preventing unauthorized users from stealing data; based on the ERC-1155 standard, it establishes a non-fungible token for knowledge resource files and stores it in the blockchain network, while allowing... Users can perform batch operations on non-fungible tokens (NFGs) to ensure ownership of knowledge resource files while reducing direct interaction with the blockchain. All operation records and results are stored in a self-built blockchain network, and decentralized storage of transaction records is achieved through maintenance of all nodes in the blockchain network, avoiding single points of failure. User-uploaded knowledge resource files are stored in IPFS (off-chain storage), while their unique IPFS index (hash value) along with the NFGs are stored on the blockchain network (on-chain storage). This dual-storage model (on-chain + off-chain) reduces data accumulation in the blockchain network and lowers maintenance costs. All transaction information in the self-built blockchain network interacts with the Public Infrastructure Network (BSN), allowing all users in the blockchain network to view their own status or the status of all transactions in the current network at any time, preventing data leakage by malicious users and ensuring that the data stored in the blockchain network is immutable and traceable. < / id>

Claims

1. A method for reliable protection of knowledge resources based on consortium blockchain networks, characterized in that, Includes the following steps: Step 1: Build an IPFS private network with 7 nodes. The node with the largest actual storage space in the IPFS private network is used as the storage node. When a file is successfully uploaded to the IPFS network, a hash value based on the unique identifier of the content is returned. The node with the largest actual storage space among the nodes other than the storage node is used as the backup node. Step 2: In Hyperledger Fabric, set up 3 Orderer nodes and 2 organizations, configure 2 nodes for each organization, and generate certificate files and genesis blocks for all nodes. Mount the certificate files and genesis block files as data volumes in the corresponding 7 containers to obtain the consortium blockchain network. Step 2 specifically includes the following steps: Step 2.1: Download Hyperledger Fabric and modify the crypto-config.yaml configuration file; under the OrdererOrgs option, configure 3 Orderer nodes in Specs, and under the PeerOrgs option, configure two organizations: Org1 and Org2. Org1 is an authoritative organization, and its users have the authority to initialize contracts and add chaincode. Configure 2 nodes in the Template option within each organization, and divide the four nodes into endorsement nodes, master nodes, and slave nodes according to their roles. Step 2.2: Use the cryptogen tool to generate certificate files for all nodes in the consortium blockchain network; Step 2.3: Use configtxgen -profile SampleMultiNodeEtcdRaft -outputBlock <genesisblock-path> The command generates the genesis block; Step 2.4: Mount the certificate file and genesis block file as data volumes in the corresponding 7 containers to obtain the consortium blockchain network. Each container includes 1 node in the consortium blockchain network and 1 IPFS node. Step 3: Based on the ERC-1155 standard, establish a non-fungible token for knowledge resource files and store it in the consortium blockchain network. Allow users to perform operations on the non-fungible token, and store the non-fungible token data and transaction records generated by the operations in the nodes of the consortium blockchain network. Step 4: Interact all transaction records in the nodes of the consortium blockchain network with the public infrastructure network (BSN).

2. The method for reliable protection of knowledge resources based on consortium blockchain networks according to claim 1, characterized in that, The operations related to non-fungible tokens described in step 3 include batch generation of different types of non-fungible tokens, destruction of non-fungible tokens, transfer of non-fungible tokens, and return of the number of non-fungible tokens; and identity verification and chaincode initialization are performed before the operations on non-fungible tokens.

3. The method for reliable protection of knowledge resources based on consortium blockchain networks according to claim 2, characterized in that, The process of generating the non-fungible token in step 3 is as follows: Write the main function and import the interface of the ERC-1155 standard; Call the GetClientIdentity().GetMSPID() function to obtain the client identity. If the node belongs to a node in Org1, the chaincode initialization operation is allowed; otherwise, the chaincode initialization operation is refused. Using the hash value returned in step 1 and the summary information of the knowledge resource to be protected, a non-fungible token for the knowledge resource file is generated; and the user address and the non-fungible token are recorded in the nodes of the consortium blockchain network.

4. The method for reliable protection of knowledge resources based on a consortium blockchain network according to claim 3, characterized in that, The process of batch generating different types of non-fungible tokens is as follows: Define two arrays, id and amount, with the same size n. The element k in id represents the type of non-fungible token, and the element v in amount represents the quantity of the corresponding non-fungible token. Call the MintBatch function to generate a list of non-fungible tokens based on the user address, non-fungible tokens, id[i], and amount[i].

5. The method for reliable protection of knowledge resources based on consortium blockchain networks according to claim 3, characterized in that, The process of destroying non-fungible tokens is as follows: if a user address holds one type of non-fungible token, then the non-fungible tokens are found based on the user address and reduced to a specified number; if a user address holds at least two types of non-fungible tokens, the list of non-fungible tokens held by the user is found based on the user address, the entire list is traversed, the type of non-fungible token to be destroyed is found, and the number is reduced to a specified number.

6. The method for reliable protection of knowledge resources based on consortium blockchain networks according to claim 3, characterized in that, The process of batch destruction of non-fungible tokens is as follows: If a user address holds at least two types of non-fungible tokens, the list of non-fungible tokens held by the user is found based on the user address. The entire list is traversed, and when k is the type of non-fungible token to be destroyed, the number of v corresponding to k is reduced to the specified number.

7. The method for reliable protection of knowledge resources based on consortium blockchain networks according to claim 3, characterized in that, The process of transferring the non-fungible token is as follows: it is determined whether the user address of the sender is the same as that of the receiver. If they are the same, the operation is not allowed. If they are different, the specified non-fungible token is found according to the user address of the sender, and its quantity is reduced by v. Then, the specified type of non-fungible token is found according to the user address of the receiver, and its quantity is increased by v.

8. The method for reliable protection of knowledge resources based on consortium blockchain networks according to claim 3, characterized in that, The process of batch transferring non-fungible tokens is as follows: Iterate through the sender's id array and amount array, reduce the quantity of non-fungible tokens of the corresponding type by v, and then iterate through the receiver's id array and amount array. If the receiver holds non-fungible tokens of the same type, increase the quantity of non-fungible tokens of the same type by v. If the receiver does not hold non-fungible tokens of the same type, record the type and quantity of this non-fungible token in the receiver's id array and amount array.

9. The method for reliable protection of knowledge resources based on a consortium blockchain network according to claim 1, characterized in that, The interaction includes periodic interaction and quantitative interaction. The method of periodic interaction is as follows: set a timer, and when the timer reaches the specified time, call the Set method to deliver all transaction information in the self-built chain to BSN for storage. The quantitative interaction method is as follows: set a constant s, count the number of all transaction information m, and when s equals m and the timer has not reached the specified time, directly deliver the m newly generated transaction information in the self-built chain to BSN for storage through the Set method, and at the same time reset the timer and start counting again.

Images