A blockchain-based copyright data security management method and management system

Abstract

The application relates to the technical field of data security, and particularly discloses a copyright data security management method and system based on a block chain, which comprises the following steps: a block chain network containing multiple sub-chains is constructed, and a single sub-chain comprises multiple nodes; when a proposal i is determined to meet change conditions, a management agency node submits the proposal i to a public proposal pool; after the content of the proposal i is cross-verified by an author node and a publisher node, voting weights are allocated to the nodes according to historical behavior data and types of the nodes; voting scores are calculated in real time based on voting weights and voting conditions of all the nodes, a voting result is obtained according to the voting scores, and if the voting result is passed, the management agency node triggers an intelligent contract to automatically execute the proposal i. The application can guarantee that copyright confirmation, voting decision and rule upgrading are collaboratively completed under the conditions of rapidness and safety.

Description

Technical Field

[0001] This invention relates to the field of data security technology, specifically to a blockchain-based copyright data security management method and system. Background Technology

[0002] Blockchain is a decentralized distributed ledger technology. Its core idea is to package data into "blocks" in chronological order and use cryptographic algorithms to link each block with the previous one, forming an immutable chain of records. In the field of copyright data security management, the decentralized, immutable, and traceable characteristics of blockchain technology can be used to store, verify, and manage copyright-related information, ensuring the security and trustworthiness of this data throughout the entire process of collection, transmission, authorization, and use.

[0003] In blockchain, major upgrades or rule changes often rely on on-chain governance voting. However, in reality, the voting threshold is usually set too high, requiring the staking of large amounts of governance tokens or the payment of high transaction fees, making it difficult for small creators, copyright holders, and end users to participate. As a result, governance decisions are often monopolized by token-holding giants. At the same time, to ensure enough nodes vote, the voting cycle and execution process are deliberately lengthened, potentially taking days or even weeks, making it difficult to quickly respond to copyright disputes, urgently remove infringing content, or deploy security patches. This inefficient governance pace conflicts with the copyright industry's need for timeliness and agile response. Once an emergency copyright incident occurs, the entire network is stuck in a stalemate of "waiting for votes and on-chain confirmation," severely delaying the implementation of copyright protection measures and the control of infringement risks. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based copyright data security management method and system to solve the above-mentioned technical problems.

[0005] The objective of this invention can be achieved through the following technical solutions: A blockchain-based method for secure copyright data management includes the following steps: Construct a blockchain network containing multiple sub-chains, wherein each sub-chain includes a main chain and side chains, and each sub-chain includes multiple nodes, which are divided into author nodes, publisher nodes, and management organization nodes; For a single subchain, when proposal i is determined to meet the change conditions, the management node submits proposal i to the public proposal pool. After the content of proposal i is cross-verified by the author node and the publisher node, voting weights are assigned to each node based on the historical behavior data and type of each node. The voting score is calculated in real time based on the voting weights and voting status of all nodes. If the voting score is less than the preset voting score threshold, the voting result is not passed; otherwise, the voting result is passed. When the voting result is passed, the management node triggers the smart contract to automatically execute the proposal i.

[0006] As a further aspect of the present invention: the blockchain network includes one main chain and multiple side chains; Different sidechains are responsible for storing different types of copyright data; The main chain uses cross-chain anchoring to ensure consistency and tamper-proof audit of copyright data storage across side chains.

[0007] As a further aspect of the present invention: determining whether the change conditions are met includes: Submit proposal i to the preset pre-screening cache; The declaration fields in proposal i are matched with the predefined feature library. If the match is successful, the change conditions are deemed met.

[0008] As a further aspect of the present invention: the allocation of voting weights includes: The historical behavioral data includes activity level and average consistency. Different initial weights are assigned to different types of nodes, with the weights of management organization nodes, publisher nodes, and author nodes decreasing in that order. The historical behavior data and the initial weights are weighted and summed to obtain the weight value. The weight value is then normalized and mapped to the value range (0, 1] to obtain the voting weight.

[0009] As a further aspect of the present invention: obtaining historical behavior data includes: Gaining activity points includes: The voting frequency of nodes is periodically obtained, and the average voting frequency is calculated as the activity level. Obtaining consistency includes: In a single voting process, the voting score D1 and the voting score threshold D2 in the single voting record are obtained, and the difference ratio D = |D1-D2| / D2 is calculated. If the difference ratio D ≤ 0.3, then the subsequent steps will not be executed in this voting process; If the difference ratio D > 0.7, and the voting result of node a is the same as the final voting result during this voting process, then the consistency parameter of node a is recorded as 1. Get the total number A of nodes that are the same as the final voting result, count the proportion B of the number of nodes of a single type in the total number A, take the reciprocal of B and map it to the value range (0, 1], and multiply it by the consistency parameter in this voting process to get the consistency degree of the node in this voting process.

[0010] As a further aspect of the present invention: if the ratio B is 0 and / or the ratio B is 1, the subsequent steps are not performed in this voting process.

[0011] As a further aspect of the present invention: automatic execution of proposal i includes: Based on proposal i, generate rule configuration parameters and split them into multiple data blocks. Each data block is appended with a unique identifier and the hash value of the preceding data block, and then transmitted to each node in sequence. After receiving a data block, the node verifies the data integrity based on the hash chain. After the node completes the integrity verification of all data blocks, the verified rule configuration parameters are split into global general parameters and role-specific parameters according to preset logic. The global parameters include the network consensus rule update content, and the role parameters include the permission adjustment details corresponding to the author, publisher, and management organization. An independent distribution queue is generated for each type of parameter. Global parameters are pushed synchronously to all nodes through the blockchain broadcast channel, while role parameters are transmitted to the corresponding category of node group according to the node type. After receiving the rule configuration parameters, the node first simulates the new rule in the local sandbox environment to test its compatibility with existing copyright data. The virtual operation records generated during the simulation are isolated from the real chain. If the simulation runs without errors, the node will mark the new rule configuration parameters as ready and send a load ready signal to the smart contract. When the smart contract detects that more than a set proportion of nodes have sent load ready signals, it sends a synchronization activation command to the entire network, and all nodes atomically switch to the new rules at the specified block height; For nodes that fail to complete loading in a timely manner, the smart contract initiates a delay compensation mechanism, sending them a difference data patch package until the state is synchronized.

[0012] A blockchain-based copyright data security management system includes: Network construction module: Constructs a blockchain network containing multiple sub-chains, including the main chain and side chains. Each sub-chain includes multiple nodes, which are divided into author nodes, publisher nodes, and management organization nodes. Weight allocation module: For a single subchain, when proposal i is determined to meet the change conditions, the management node submits proposal i to the public proposal pool. After the content of proposal i is cross-verified by the author node and the publisher node, voting weights are allocated to each node based on the historical behavior data and type of each node. Execution module: Calculates the voting score in real time based on the voting weights and voting status of all nodes. If the voting score is less than the preset voting score threshold, the voting result is not passed; otherwise, the voting result is passed. When the voting result is passed, the management node triggers the smart contract to automatically execute the proposal i.

[0013] The beneficial effects of this invention compared to the prior art are as follows: 1) This invention pre-sets differentiated initial weights for three types of nodes: management institutions, publishers, and authors. It dynamically integrates on-chain voting activity and historical performance into the weight model, completely eliminating the single-dimensional judgment of "those with more tokens gain power." Nodes can accumulate governance influence simply by continuously submitting high-quality votes, without additional economic investment, significantly lowering the participation threshold for small-scale creators and end-users. The dynamic weights are smoothly updated across block heights, preventing sudden power shifts due to single events. This both suppresses capital monopolies and maintains the stability and predictability of the governance structure, laying a foundation of trust for long-term collaboration within the copyright ecosystem. 2) The consistency parameter compares the degree of convergence between each node's voting opinion and the final network-wide resolution. Nodes with consistently accurate judgments and stable positions are positively weighted, encouraging them to maintain professionalism and rational thinking on multiple issues. By eliminating extreme scenarios with unbalanced voting rounds and types, the manipulation space of voting alliances or malicious forks can be effectively reduced. As the average consistency is embedded in the weight model, nodes must continuously output objective judgments that align with the public interest in order to maintain high influence. This improves the quality of governance decisions from a mechanism perspective, reduces network turbulence caused by emotional or short-sighted voting, and aligns on-chain governance with the prudent compliance requirements of the copyright industry. 3) This invention adopts a "main chain + multiple side chains" architecture, and separates and distributes globally common parameters and role-specific parameters during the rule iteration phase. Combined with hash chain integrity verification and ready signal statistics, it achieves atomic rule switching at a specified block height. Nodes can only be marked as ready after completing compatibility verification in the sandbox. Nodes that fail to load on time obtain difference patches through a delayed compensation mechanism to ensure network-wide consistency. This process ensures upgrade security while avoiding business interruption, maintaining the immutability and auditability requirements of copyright data, and providing a flexible and robust evolutionary path for subsequent functional expansion. Attached Figure Description

[0014] The invention will now be further described with reference to the accompanying drawings.

[0015] Figure 1 This is a flowchart illustrating a blockchain-based copyright data security management method according to the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Please see Figure 1 As shown, this invention is a blockchain-based copyright data security management method, comprising the following steps: First, a consortium blockchain framework is created and a genesis block is generated for the main chain. Then, several sidechains are derived based on the type of work; for example, musical works are mapped to a music sidechain, and written works to a book sidechain. Each sidechain registers its chain identifier and consensus configuration with the main chain upon startup. When the author completes fingerprint extraction of their work within a local digital rights management tool, the client loads the work into the client-side TEE secure execution environment. Within a hardware-isolated area, irreversible hash operations are performed on the binary content, and a zero-knowledge proof library is called to generate a publicly verifiable proof file without revealing the original text. The hash and proof are then packaged together as a transaction to be added to the blockchain. Based on the work category and file granularity, the client automatically shards the data and selects the corresponding sidechain for writing. The publisher node, acting as a high-performance validator, packages the data within that sidechain. The system involves creating blocks, executing contracts, and storing redundant copies. Management nodes load audit plugins to periodically sample block content and generate regulatory reports. Sidechains and the main chain periodically synchronize Merkle root hashes via a cross-chain gateway. The main chain aggregates the block header hashes of each sidechain and writes them into its own block to form an anchor. Upon receiving the anchor receipt, the sidechain records confirmation information to ensure bidirectional consistency. Simultaneously, the cross-chain gateway broadcasts the block headers to the relay chain. The relay chain performs zero-knowledge verification on the sidechain blocks based on the aggregated hashes provided by the main chain and writes the verification results. Once verified, the relay chain returns a joint certificate of evidence to the author client and the management organization for storage. This ultimately forms a complete closed-loop process: "TEE-based evidence collection + zero-knowledge proof for privacy protection, sidechain sharding for rapid rights confirmation, main chain aggregation for unified evidence storage, and relay chain receipt of joint certificate." It is important to note that the layered structure of the main chain coordinating with the side chains allows different types of copyright data to operate independently, avoiding mutual interference and reducing on-chain load. Furthermore, the main chain's anchoring provides all side chains with a unified, trusted timestamp and tamper-proof guarantee, thus balancing throughput and security. The clearly defined node design allows authors to focus on submitting original content, publishers to handle block production and distribution, and management agencies to conduct centralized compliance audits. This avoids shirking responsibility due to unclear division of powers and ensures that all stakeholders have a clear entry point during the governance process. The cross-chain gateway's periodic hash synchronization mechanism allows side chains to quickly solidify ownership information onto the main chain even with frequent block production, reducing the risk of broken evidence chains in copyright disputes. Ultimately, the overall architecture serves the goal of rapid, transparent, and traceable copyright ownership confirmation and management, providing a stable foundation for subsequent voting governance, rule upgrades, and infringement evidence collection. It's worth noting that when a work is first uploaded to the blockchain, the sidechain's storage scheduler reads the work's category tag and current access count. Content with high real-time playback frequency, such as short videos and popular music, is marked as high-popularity items. These items are then split into multiple fixed-size data chunks and redundantly written across multiple verification nodes. Simultaneously, the block-level metadata is fully recorded in the sidechain's local state database. For moderately popular text and image works, the scheduler only stores the encrypted hash of the entire file and several digest fields, and saves a copy of the original text on an off-chain distributed storage gateway. The sidechain only writes the content address returned by the gateway. For niche and rarely used long-tail works, the system only registers their top-level Merklegen and external archive number, while the specific files are transferred to offline archive nodes. A traceable evidence collection channel is retained through smart contracts. The verification frequency is also dynamically issued according to the popularity threshold. High-popularity items are triggered by the scheduled task module to randomly sample blocks every hour for multi-signature verification. Medium-popularity items are switched to automatic verification once a day. Niche items are only initiated for integrity review when nodes conduct weekly routine inspections or when the work is cited externally. The entire strategy is controlled by on-chain governance parameters. After receiving a threshold adjustment event, the node automatically refreshes its local schedule. By flexibly adjusting storage granularity and verification rhythm based on content type and popularity, sidechains can prioritize valuable on-chain space and node computing power for works with high user attention and a high probability of potential disputes, without sacrificing the ability to trace low-traffic works. This reduces the waste of resources from redundant storage and high-frequency verification while ensuring the credibility and verifiability of copyright data, alleviating node load and network congestion, and leaving room for the sidechain to handle situations when a work becomes popular or experiences a surge in access. This on-demand allocation strategy ultimately helps the entire subchain maintain an efficient, scalable, and economically viable operating state when facing diverse copyright assets.

[0018] When proposal i is detected to have passed the feature matching of the pre-screener, a JSON description file containing the proposal hash, proposal digest, and submitter's public key is generated locally and signed. Then, the addProposal interface of the public proposal pool contract is called to write the file to the on-chain list. After receiving the transaction, the public proposal pool contract immediately broadcasts a "new proposal event" to the entire sidechain network. The author node's client, upon listening to the event, will automatically download the decentralized storage path referenced in the proposal file and perform field-by-field verification of the work's metadata or license modification terms. For example, author nodes can compare the work's fingerprint, while publisher nodes can verify the distribution channel and version number. After verification, each author node and publisher node will... The submitReview interface is called to upload the verification results and reasons, and the node ID is written to the reviewMerkle field for subsequent traceability. During the summary phase, the management node calls the calculateWeight script. This script first reads the on-chain nodeProfile table to obtain the node type, and then queries the behaviorStats contract to obtain indicators such as activity and consistency. The three types of data are input into the weight factor matrix and normalized. Finally, a floating-point weight is generated for each node that uploads review opinions and written to voteLedger. Subsequent vote counting directly reads this weight and multiplies it by the node's voting option to obtain the weighted score. Understandably, adopting a centralized public proposal pool with cross-verification by both authors and publishers allows the original content and distribution information to be reviewed by the party most familiar with their own interests, reducing the risk of omissions in single-point review. Incorporating historical activity and consistency into the weighting calculation, rather than solely relying on node type, encourages continuous participation from all parties and maintains judgments consistent with network consensus, thereby guiding governance voting to focus on genuine contributions without increasing economic barriers. Recording weighting results uniformly in the voteLedger facilitates subsequent automatic vote counting by smart contracts and preserves a transparent audit trail, helping to quickly trace the decision-making process in cases of copyright disputes or rule controversies. The overall process lays a credible foundation for the rapid and fair upgrading of subsequent rules. In a preferred embodiment of the present invention, determining whether the change conditions are met includes: When proposal i is submitted, the sidechain gateway first calls the pre-review cache contract to generate a temporary record. This record contains the proposal hash, submitter address, timestamp, and the IPFS path stored on-chain. Then, the complete proposal JSON is split into a declaration area, body area, and attachment area according to field categories and written to three column families cached in the local database for parallel parsing. The pre-review service starts multi-threaded reading of declaration area fields, such as key keys like "copyright type," "urgency level," "work ID involved," and "proposed rule modification ID," and maps them to feature vectors using a Bloom filter. These vectors are then compared with a predefined feature library maintained off-chain by the sidechain nodes. The feature library stores common emergency scenario patterns such as "removal request for infringement", "patching of serious vulnerabilities", and "forced revocation of permissions" string templates. The matching algorithm uses the longest common substring combined with cosine similarity. When the matching degree exceeds the threshold, the onMatch hook is triggered, the proposal status is updated to waitingForGovernance and written to the on-chain event log. If the match fails, the rejectProposal process is called to return the reason code. Proposal i stays in the cache waiting for the initiator to provide supplementary explanation or is cleaned up by the system periodically. The entire judgment process is completed in the sandbox network and does not occupy on-chain gas. It is important to note that sending proposals to a pre-review cache and quickly comparing them with a feature library can filter out urgent or high-value change tasks from a large number of ordinary proposals without interfering with the main chain consensus. This avoids irrelevant or malicious proposals crowding out governance bandwidth and allows copyright disputes and security patches that truly require rapid response to be prioritized. The strategy of matching declared fields with the feature library is more accurate than simple keyword filtering, which can reduce the false positive rate while maintaining the flexibility to upgrade the rules. When the business scenario changes, only the addition or deletion of feature templates can take effect immediately without modifying the smart contract. The entire process pushes the judgment logic to be executed off-chain in the sandbox, reducing on-chain computational overhead and voting waiting time. This lays a reliable entry point for the efficient governance of the subsequent public proposal pool and ensures that the sidechain can still respond quickly and accurately to sudden copyright events while maintaining open participation. In another preferred embodiment of the present invention, the allocation of voting weights includes: In the sidechain's weighting process, the voting script first iterates through the nodeProfile table to read the node type and writes an initial weight for each node, such as 0.5 for management node, 0.3 for publisher node, and 0.2 for author node (other values ​​can be used, and the specific values ​​can be set based on experience). Then, the three indicators are weighted and summed (the coefficient ratio can also be recalibrated according to the characteristics of the sidechain ecosystem) to obtain the weight value. After all node weight values ​​have been calculated, min-max normalization is performed to make the result fall within the (0, 1] interval. In extreme cases, if max = min, a uniform value of 1 is assigned, or the result is reported. After normalization, the voting weight is obtained. It should be noted that by assigning initial weights based on node type and then dynamically adjusting them based on activity and average consistency, a clear governance structure can be maintained while giving greater say to nodes that are consistently active and make accurate judgments. This encourages continued participation from the author community and prevents publishers or management institutions from having idle weights due to a lack of activity. Normalizing weights to a unified range facilitates comparable calculations across nodes and time periods in smart contracts, avoiding precision errors caused by differences in numerical units. The overall mechanism allows sidechain governance to break free from the limitations of being determined solely by capital or static roles, forming an incentive loop that measures both "role responsibilities" and "historical contributions." This provides a data foundation for subsequent rapid and high-quality copyright rule voting, thereby helping the entire solution achieve fair and efficient decision-making in the event of sudden copyright incidents. In a preferred embodiment of this invention, obtaining historical behavior data includes: In the sidechain's statistics engine, the scheduler triggers a scanning script every fixed number of blocks. The script first queries the voteLedger table for the most recent 100 rounds of voting records and aggregates them by node address. It calculates the ratio of the theoretical number of votes each node should have cast to the number of votes already cast, and averages this ratio as its activity level, writing it into the behaviorCache. Then, the script iterates through the same batch of records, extracting the voting score D1 and threshold D2 for each record and calculating the difference ratio D. If D is less than or equal to 0.3, the record is skipped immediately to avoid including low-controversy votes in the consistency statistics. If D is greater than 0.7 and node a's current choice matches the final result... If the consistency parameter is generated for the node, the script will proceed to the next step. The script will continue to count the total number of nodes A that are the same as the final result in this vote, and then further subdivide the number of nodes of the same type as node a into B. After performing a reciprocal operation and mapping it to the 0-1 range, the script will multiply it by the consistency parameter to obtain the instantaneous consistency of node a in this vote. The script will accumulate all instantaneous consistency and divide it by the number of times it participated to obtain the average consistency field, which will be written back to behaviorCache. The entire collection and calculation process is completed in the off-chain sandbox. Finally, the on-chain behavior data contract will provide read-only interfaces for activity and average consistency for the weighting script to call. It's important to note that this design allows activity levels to fully reflect the continuity of node participation in governance, naturally distinguishing nodes that are frequently absent or only appear on a few issues. The consensus metric rewards those who consistently make judgments that align with group consensus but don't represent an overwhelming majority in the opinion distribution, thus curbing vote-rigging and the scramble for majority seats. By setting a threshold for the difference ratio to exclude low-controversy events, it prevents some nodes from artificially inflating their consensus by following "low-risk votes," maintaining the metric's scarcity and value. The overall mechanism ensures that weight calculations not only rely on node identity but also incorporate the dynamic dimension of historical performance, providing a more nuanced and reliable basis for subsequent voting phases. Ultimately, this helps sidechains quickly gather truly active and accurate nodes to form high-quality decisions when facing urgent copyright disputes. Taking the reciprocal of B is to represent the "percentage of similar nodes in the 'yes' camp." This can be transformed into a "scarcity" index. When the proportion of nodes of the same type in the affirmative votes is very high (e.g., B is close to 1), it indicates that the issue is most favorable to this type, and there may be a risk of "grouping" or biased interests. The value obtained by taking the reciprocal is close to the lower limit of 1, thus compressing the bonus of this type of node in terms of consistency, so as not to push the weight too high by the advantage of numbers. When the proportion of nodes of the same type in the affirmative votes is low (e.g., B is close to 0), it indicates that this type of position is more inclined to neutrality or minority perspective. The reciprocal operation will amplify its contribution coefficient, so that a minority of nodes that are consistent with the majority of the final decision will receive additional incentives. This not only inhibits a certain group from "showing off" when it is in a proposal that is favorable to itself, but also encourages nodes of all types to make rational judgments on issues that cross the boundaries of interests, thereby improving the fairness and representativeness of the governance results to all participants from a mechanism perspective. It is worth noting that if proportion B is 0 and / or proportion B is 1, the subsequent steps will not be performed in this voting process; The vote counting contract subscribes to the `voteCast` event immediately after the sidechain enters the voting phase. Whenever a node submits a vote, its address, option, and signature are written to the `voteLedger`. Simultaneously, the contract's internal function `fetchWeight` retrieves the node's voting weight `w` from the weight mapping table, and the contract accumulates `w` in real-time into the corresponding option's score cache. To avoid duplicate counting, the contract hashes the node address to remove duplicates and marks it as voted when writing. If duplicate voting is detected, the transaction is rolled back. During the vote counting process, whenever a new block is packaged, the governance script calls `getCurrentScore` to read the scores of both sides and calculates the support ratio `P = support score / (support score + opposition score)`, then compares it with a preset threshold. When comparing P (e.g., 0.55, which can be calibrated experimentally), if P is less than T, write NotPassed to the on-chain event log and keep the proposal status pending; if P is equal to or greater than T, write Passed and update the proposal status to readyForExecution. When the status changes to readyForExecution, the governing node automatically calls the executeProposal method of the execution contract after hearing the status change. This method first verifies the proposal hash and signature integrity again, then unpacks the rule configuration data block, calls the cross-chain gateway to broadcast the new consensus parameters, and finally records the proposal execution result in the governanceHistory table for auditing. Understandably, the design of real-time weight accumulation allows the sidechain to see the current support trend immediately during the voting period without waiting for all nodes to finish voting, providing technical conditions for accelerating decision-making in the event of an emergency copyright incident; binding weights to node signatures and performing duplicate checks can prevent malicious nodes from using replay or multiple transactions to inflate scores, while maintaining the openness and transparency of the governance process; the threshold judgment logic makes the standard for passing or failing explicit, avoiding human intervention offline; the hash and signature are verified again during the execution phase to ensure that the proposal content has not been tampered with, and the smart contract is uniformly triggered by the management node for atomic deployment, which not only ensures the non-repudiation of the on-chain results, but also allows the governance resolution to be implemented at the rule level in the shortest path. The overall process provides a key closed loop for the sidechain's fast, reliable and traceable copyright governance; If proposal i fails to pass within the preset time limit, it will be automatically reported. In another preferred embodiment, automatic execution of proposal i includes: After proposal i is marked as passed by the vote counting contract, the management node calls the rule generator to parse the proposal content into a JSON configuration containing consensus modifications, permission adjustments, and version numbers. This configuration is then split into several data blocks of approximately 4KB each. Each block is appended with a sequence number, the hash value of the previous block, and the hash value of the current block before being broadcast sequentially via the sidechain peer-to-peer network. When author nodes, publisher nodes, and other management nodes receive data blocks, they first read the sequence number and the preceding hash for integrity verification until all blocks are downloaded and verified through the hash chain. Then, they reassemble the complete configuration file, writing global common parameters such as "block time, threshold parameters, and state machine version" according to a preset mapping table, and role-specific parameters such as "author upload quota, publisher distribution scope, and management agency penalty process." Separate queues are established for each type of parameter in the node's local message queue. Globally common parameters are broadcast to all nodes via the gossip protocol, while role-specific parameters are sent only to the corresponding node group via a targeted channel based on the node's role tag in its nodeProfile. After receiving their parameters, nodes create a snapshot of their current height in the isolation sandbox, simulate the new rules, and if no compatibility errors are found, mark the configuration as "ready" and execute sendReadySignal to submit a loading readiness event to the governance contract. The smart contract counts the received readiness events in real time, and when the number exceeds a set threshold, it generates an "activateAtHeight" field and broadcasts a synchronization activation command, automatically switching all nodes to the new rules at that height. Nodes that are not yet ready will receive a list of difference patch packages, and will verify and write back each package until their state is synchronized and a "ready" confirmation is reissued. It's worth noting that splitting rules into hashed data blocks avoids transmission failures of large files during network outages, and chained hashing ensures that each block's content remains tamper-proof. Separating global and role parameters and using dual-channel push reduces the burden on nodes to process irrelevant data, while also balancing privacy and bandwidth efficiency. Nodes pre-rehearsing rules in a local sandbox exposes potential compatibility conflicts early, preventing business disruptions caused by direct deployment. The readiness signal threshold mechanism ensures activation only after the vast majority of nodes are ready, while atomic height switching guarantees synchronized transitions for all nodes under the same block view, thus avoiding chain forks. The lag compensation process provides a fallback synchronization method for nodes with poor network conditions or weak processing capabilities, preventing them from being permanently evicted. The overall design completes rule updates in a way that minimizes resistance and ensures security and traceability, providing a fast, stable, and consistent execution channel for sidechains in emergency copyright governance scenarios.

[0019] A blockchain-based copyright data security management system includes: Network construction module: Constructs a blockchain network containing multiple sub-chains, including the main chain and side chains. Each sub-chain includes multiple nodes, which are divided into author nodes, publisher nodes, and management organization nodes. Weight allocation module: For a single subchain, when proposal i is determined to meet the change conditions, the management node submits proposal i to the public proposal pool. After the content of proposal i is cross-verified by the author node and the publisher node, voting weights are allocated to each node based on the historical behavior data and type of each node. Execution module: Calculates the voting score in real time based on the voting weights and voting status of all nodes. If the voting score is less than the preset voting score threshold, the voting result is not passed; otherwise, the voting result is passed. When the voting result is passed, the management node triggers the smart contract to automatically execute the proposal i.

[0020] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the present invention should still fall within the scope of the present invention.

Claims

1. A blockchain-based copyright data security management method, characterized in that, Includes the following steps: Construct a blockchain network containing multiple sub-chains, wherein each sub-chain includes a main chain and side chains, and each sub-chain includes multiple nodes, which are divided into author nodes, publisher nodes, and management institution nodes; For a single subchain, when proposal i is determined to meet the change conditions, the management node submits proposal i to the public proposal pool. After the content of proposal i is cross-verified by the author node and the publisher node, voting weights are assigned to each node based on the historical behavior data and type of each node. The voting score is calculated in real time based on the voting weights and voting status of all nodes. If the voting score is less than the preset voting score threshold, the voting result is disqualified; otherwise, the voting result is passed. When the voting result is passed, the management node triggers the smart contract to automatically execute proposal i. The allocation of voting weights includes: The historical behavioral data includes activity level and average consistency. Different initial weights are assigned to different types of nodes, with the weights of management organization nodes, publisher nodes, and author nodes decreasing in that order. The historical behavior data and the initial weights are weighted and summed to obtain the weight values. The weight values ​​are then normalized and mapped to the value range (0, 1] to obtain the voting weights. Obtaining historical behavioral data includes: Gaining activity points includes: The voting frequency of nodes is periodically obtained, and the average voting frequency is calculated as the activity level. Obtaining consistency includes: In a single voting process, the voting score D1 and the voting score threshold D2 in the single voting record are obtained, and the difference ratio D = |D1-D2| / D2 is calculated. If the difference ratio D ≤ 0.3, then the subsequent steps will not be executed in this voting process; If the difference ratio D > 0.7, and the voting result of node a is the same as the final voting result during this voting process, then the consistency parameter of node a is recorded as 1. Get the total number A of nodes that are the same as the final voting result, count the proportion B of the number of nodes of a single type in the total number A, take the reciprocal of B and map it to the value range (0, 1], and multiply it by the consistency parameter in this voting process to get the consistency degree of the node in this voting process. Automatic execution of proposal i includes: Based on proposal i, generate rule configuration parameters and split them into multiple data blocks. Each data block is appended with a unique identifier and the hash value of the preceding data block, and then transmitted to each node in sequence. After receiving a data block, the node verifies the data integrity based on the hash chain. After the node completes the integrity verification of all data blocks, the verified rule configuration parameters are split into global general parameters and role-specific parameters according to preset logic. The global parameters include the network consensus rule update content, and the role parameters include the permission adjustment details corresponding to the author, publisher, and management organization. An independent distribution queue is generated for each type of parameter. Global parameters are pushed synchronously to all nodes through the blockchain broadcast channel, while role parameters are transmitted to the corresponding category of node group according to the node type. After receiving the rule configuration parameters, the node first simulates the new rule in the local sandbox environment to test its compatibility with existing copyright data. The virtual operation records generated during the simulation are isolated from the real chain. If the simulation runs without errors, the node will mark the new rule configuration parameters as ready and send a load ready signal to the smart contract. When the smart contract detects that more than a set proportion of nodes have sent load ready signals, it sends a synchronization activation command to the entire network, and all nodes atomically switch to the new rules at the specified block height; For nodes that fail to complete loading in a timely manner, the smart contract initiates a delay compensation mechanism, sending them a difference data patch package until the state is synchronized.

2. The copyright data security management method based on blockchain according to claim 1, characterized in that, The blockchain network includes one main chain and multiple side chains; Different sidechains are responsible for storing different types of copyright data; The main chain uses cross-chain anchoring to ensure consistency and tamper-proof audit of copyright data storage across side chains.

3. The copyright data security management method based on blockchain according to claim 1, characterized in that, Determining whether the change conditions are met includes: Submit proposal i to the preset pre-screening cache; The declaration fields in proposal i are matched with the predefined feature library. If the match is successful, the change conditions are deemed met.

4. The copyright data security management method based on blockchain according to claim 1, characterized in that, If proportion B is 0 and / or proportion B is 1, no further steps will be performed in this voting process.

5. A blockchain-based copyright data security management system, characterized in that, include: Network construction module: Constructs a blockchain network containing multiple sub-chains, including the main chain and side chains. Each sub-chain includes multiple nodes, which are divided into author nodes, publisher nodes, and management organization nodes. Weight allocation module: For a single subchain, when proposal i is determined to meet the change conditions, the management node submits proposal i to the public proposal pool. After the content of proposal i is cross-verified by the author node and the publisher node, voting weights are allocated to each node based on the historical behavior data and type of each node. Execution module: Calculates the voting score in real time based on the voting weights and voting status of all nodes. If the voting score is less than the preset voting score threshold, the voting result is "not passed"; otherwise, the voting result is "passed". When the voting result is "passed", the management node triggers the smart contract to automatically execute proposal i. The allocation of voting weights includes: The historical behavioral data includes activity level and average consistency. Different initial weights are assigned to different types of nodes, with the weights of management organization nodes, publisher nodes, and author nodes decreasing in that order. The historical behavior data and the initial weights are weighted and summed to obtain the weight values. The weight values ​​are then normalized and mapped to the value range (0, 1] to obtain the voting weights. Obtaining historical behavioral data includes: Gaining activity points includes: The voting frequency of nodes is periodically obtained, and the average voting frequency is calculated as the activity level. Obtaining consistency includes: In a single voting process, the voting score D1 and the voting score threshold D2 in the single voting record are obtained, and the difference ratio D = |D1-D2| / D2 is calculated. If the difference ratio D ≤ 0.3, then the subsequent steps will not be executed in this voting process; If the difference ratio D > 0.7, and the voting result of node a is the same as the final voting result during this voting process, then the consistency parameter of node a is recorded as 1. Get the total number A of nodes that are the same as the final voting result, count the proportion B of the number of nodes of a single type in the total number A, take the reciprocal of B and map it to the value range (0, 1], and multiply it by the consistency parameter in this voting process to get the consistency degree of the node in this voting process. Automatic execution of proposal i includes: Based on proposal i, generate rule configuration parameters and split them into multiple data blocks. Each data block is appended with a unique identifier and the hash value of the preceding data block, and then transmitted to each node in sequence. After receiving a data block, the node verifies the data integrity based on the hash chain. After the node completes the integrity verification of all data blocks, the verified rule configuration parameters are split into global general parameters and role-specific parameters according to preset logic. The global parameters include the network consensus rule update content, and the role parameters include the permission adjustment details corresponding to the author, publisher, and management organization. An independent distribution queue is generated for each type of parameter. Global parameters are pushed synchronously to all nodes through the blockchain broadcast channel, while role parameters are transmitted to the corresponding category of node group according to the node type. After receiving the rule configuration parameters, the node first simulates the new rule in the local sandbox environment to test its compatibility with existing copyright data. The virtual operation records generated during the simulation are isolated from the real chain. If the simulation runs without errors, the node will mark the new rule configuration parameters as ready and send a load ready signal to the smart contract. When the smart contract detects that more than a set proportion of nodes have sent load ready signals, it sends a synchronization activation command to the entire network, and all nodes atomically switch to the new rules at the specified block height; For nodes that fail to complete loading in a timely manner, the smart contract initiates a delay compensation mechanism, sending them a difference data patch package until the state is synchronized.

Images