Copyright data security management method and management system based on block chain

Abstract

The invention relates to the technical field of data security, and particularly discloses a copyright data security management method and management system based on a block chain, and the method comprises the following steps: constructing a block chain network comprising a plurality of sub-chains, each sub-chain comprising a plurality of nodes; when it is judged that the proposal i meets the change condition, the management mechanism node submits the proposal i to a public proposal pool, and after the content of the proposal i is subjected to cross validation through the author node and the publisher node, voting weights are distributed to the nodes according to historical behavior data and types of the nodes; and calculating voting scores in real time based on the voting weights and the voting conditions of all the nodes, obtaining a voting result according to the voting scores, and if the voting result is passing, triggering the intelligent contract by the management mechanism node to automatically execute the proposal i. According to the method, copyright confirmation, voting decision making and rule upgrading can be collaboratively completed under rapid and safe conditions.

Description

Technical Field

[0001] The present invention relates to the field of data security technology, and in particular to a copyright data security management method and management system based on blockchain. Background Art

[0002] Blockchain is a decentralized, distributed ledger technology. Its core concept is to package data into chronological "blocks" and, through cryptographic algorithms, link each block to the previous one, forming an immutable chain of records. In the field of copyright data security management, blockchain technology's decentralized, immutable, and traceable characteristics can be leveraged to store, verify, and manage copyright-related information, ensuring the security and credibility of this data throughout its collection, transmission, authorization, and use.

[0003] In blockchains, major upgrades or rule changes often rely on on-chain governance voting. However, in reality, voting thresholds are often set too high, requiring large stakes in governance tokens or high transaction fees. This makes it difficult for small-scale creators, copyright holders, and end users to participate. As a result, governance decisions are often monopolized by token holders. Furthermore, to ensure sufficient node participation, voting cycles and execution processes are deliberately prolonged, 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 process conflicts with the copyright industry's demand for timeliness and agility. Once an emergency copyright incident occurs, the entire network becomes stuck in a stalemate of waiting for votes and chain confirmation, severely delaying the implementation of copyright protection measures and the control of infringement risks. Summary of the Invention

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

[0005] The purpose of the present invention can be achieved through the following technical solutions: A copyright data security management method based on blockchain, comprising the following steps: Constructing a blockchain network consisting of multiple subchains, each of which includes a main chain and sidechains. Each subchain includes multiple nodes, which are divided into author nodes, publisher nodes, and management agency nodes. For a single subchain, when proposal i is determined to meet the change conditions, the management agency 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 weight is assigned to each node based on its historical behavior data and type. The voting score is calculated in real time based on the voting weight 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 agency node triggers the smart contract to automatically execute proposal i.

[0006] As a further solution of the present invention: the blockchain network includes a main chain and multiple side chains; Different side chains are responsible for storing different types of copyright data; The main chain uses cross-chain anchoring to ensure the consistency and non-tamperability of copyright data storage on each side chain.

[0007] As a further solution of the present invention: determining whether the change condition is met includes: Submit proposal i to the preset pre-review buffer; The declaration fields in proposal i are matched with the predefined feature library. If the match is successful, it is determined that the change conditions are met.

[0008] As a further solution of the present invention, allocating voting weights includes: The historical behavior data includes activity and average consistency; Different initial weights are assigned to different types of nodes, with the weights of management agency nodes, publisher nodes, and author nodes decreasing in sequence; The historical behavior data and the initial weight are weighted and summed to obtain a weight value, and the weight value is normalized and mapped to a value interval (0, 1) to obtain a voting weight.

[0009] As a further solution of the present invention: obtaining historical behavior data includes: Obtaining activity includes: Periodically obtain the voting frequency of nodes and calculate the average voting frequency as activity; Obtaining consistency includes: During a single voting process, obtain the voting score D1 and the voting score threshold D2 in the single voting record, and calculate the difference ratio D = |D1-D2| / D2; If the difference ratio D≤0.3, the subsequent steps will not be performed in this voting process; If the difference ratio D is greater than 0.7, and the voting result of node a during this voting process is the same as the final voting result, then the consistency parameter of node a is recorded as 1; Get the total number A of nodes that have the same voting result as the final one, calculate the ratio B of the number of nodes of a single type to the total number A, take the inverse 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 of the nodes in this voting process.

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

[0011] As a further aspect of the present invention, the automatic execution proposal i includes: Generate rule configuration parameters based on proposal i and split them into multiple data blocks. Each data block is attached with a unique identifier and the hash value of the previous data block, and transmitted to each node in sequence. After receiving the data block, the node verifies the data integrity based on the hash chain. After completing the integrity verification of all data blocks, the node splits the verified rule configuration parameters into global common parameters and role-specific parameters according to the preset logic. The global parameters include the updated content of the network consensus rules, and the role parameters include the permission adjustment details corresponding to the author, publisher, and management agency. Generate a separate distribution queue for each parameter type. Global parameters are pushed synchronously to all nodes through the blockchain broadcast channel, and role parameters are transmitted to the corresponding node group based on the node type. After receiving the rule configuration parameters, the node first simulates the new rules in a local sandbox environment to test their 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 marks the new rule configuration parameters as ready and sends a loading ready signal to the smart contract; When the smart contract counts that more than a set proportion of nodes have sent loading ready signals, a synchronous implementation instruction is sent 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 time, the smart contract activates a delay compensation mechanism and sends differential data patch packages to them until the status is synchronized.

[0012] A copyright data security management system based on blockchain, including: Network construction module: Builds a blockchain network consisting of multiple subchains, including a main chain and side chains. A single subchain includes multiple nodes, which are divided into author nodes, publisher nodes, and management agency nodes. Weight allocation module: For a single subchain, when proposal i is determined to meet the change conditions, the management agency 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 weight is allocated to each node based on its historical behavior data and type. Execution module: The voting score is calculated in real time based on the voting weight 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 agency node triggers the smart contract to automatically execute proposal i.

[0013] The beneficial effects of the present invention are as follows: 1) This invention presets differentiated initial weights for three types of nodes: management agencies, publishers, and authors. It also dynamically incorporates on-chain voting activity and historical performance into the weighting model, completely moving away from the single-dimensional judgment of "those with the most tokens win." Nodes can accumulate governance influence by consistently submitting high-quality votes, without requiring additional financial investment, significantly lowering the barrier to participation for small-scale creators and end users. Dynamic weights are smoothly updated between block heights, preventing sudden changes in power due to single events. This not only curbs capital monopolies but also 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 a node's voting opinions and the final network-wide resolution, positively weighting nodes with accurate long-term judgments and stable positions, encouraging them to maintain professionalism and rational thinking on multiple issues. By eliminating extreme voting rounds and imbalanced voting types, the manipulation space of voting alliances or malicious forks can be effectively weakened. With the average consistency embedded in the weighting model, if nodes want to maintain high influence, they must continuously output objective judgments that are consistent with the public interest. This improves the quality of governance decisions at the mechanism level, reduces network volatility caused by emotional and short-term voting, and ensures that on-chain governance is consistent with the prudent and compliance requirements of the copyright industry. 3) This invention utilizes a "main chain + multiple side chains" architecture, separating and distributing global common parameters from role-specific parameters during rule iterations. This, combined with hash chain integrity verification and readiness signal statistics, enables atomic rule switching at a specified block height. Nodes are marked ready only after the sandbox has completed compatibility verification. Nodes that fail to load on time receive differential patches through a lag compensation mechanism, ensuring network-wide consistency. This process ensures upgrade security while avoiding service interruptions, maintaining the immutability and auditability of copyrighted data, and providing a flexible and robust evolutionary path for subsequent functional expansion. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 This is a flowchart of a copyright data security management method based on blockchain in the present invention. DETAILED DESCRIPTION

[0016] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0017] See also Figure 1 As shown, the present invention is a copyright data security management method based on blockchain, comprising the following steps: First, a consortium chain framework is created and a main chain genesis block is generated. Subsequently, several side chains are derived based on the category of works. For example, music works are mapped to the music side chain, and text works are mapped to the book side chain. When each side chain is started, it registers its own chain identifier and consensus configuration with the main chain. When the author completes the fingerprint extraction of the work in the local digital rights management tool, the client will load the work into the end-side TEE secure execution environment, perform irreversible hash operations on the binary content in the hardware isolation area, and call the zero-knowledge proof library to generate a proof file that can be publicly verified without leaking the original text. The hash and proof are then packaged together as a transaction to be uploaded to the chain. Based on the category of the work and the granularity of the file, the client automatically shards the data and selects the corresponding side chain to write. The publisher's node acts as a high-performance verifier in the package area of ​​the side chain. Blocks, execute contracts and save redundant copies. The management agency node loads the audit plug-in to regularly check the block content and generate regulatory reports. The side chain Merkle root hash is regularly synchronized between the side chain and the main chain through the cross-chain gateway. The main chain aggregates the block header hashes of each side chain into its own block to form an anchor. After the side chain receives the anchor point receipt, it records the confirmation information to ensure two-way consistency. The cross-chain gateway also broadcasts the block header to the relay chain. The relay chain performs zero-knowledge verification on the side chain block based on the aggregated hash provided by the main chain and writes the verification result. After the verification is passed, the relay chain returns the joint evidence certificate to the author client and the management agency for storage, eventually forming a complete closed-loop process of "TEE in-house evidence + zero-knowledge proof to ensure privacy, side chain sharding for fast ownership confirmation, main chain aggregation and unified evidence storage, and relay chain receipt joint certificate"; It is important to note that the hierarchical structure of the main chain coordinating the side chains allows different types of copyright data to run independently, avoiding mutual interference and reducing on-chain load. On the other hand, the anchoring of the main chain provides a unified trusted timestamp and tamper-proof protection for all side chains, thus balancing throughput and security. The node design with clear roles allows authors to focus on submitting original content, publishers to undertake block production and distribution, and management agencies to conduct centralized compliance audits. This not only avoids buck-passing caused by unclear responsibilities, but also ensures that all stakeholders in the governance process have a clear entry point. The cross-chain gateway's regular hash synchronization mechanism allows the side chains to quickly consolidate ownership information on the main chain even if blocks are frequently produced, reducing the risk of broken evidence chains in copyright disputes. The overall architecture ultimately serves the goal of rapid, transparent, and traceable copyright ownership and management, providing a stable foundation for subsequent voting governance, rule upgrades, and infringement evidence collection. It is worth noting that the storage scheduler of the side chain will read the work category label and the current access count when the work is first uploaded to the chain, and mark the content with high frequency of real-time on-demand such as short videos and popular music as high-popularity items, split these items into multiple fixed-size data pieces and write them redundantly between multiple verification nodes, while recording the block-level metadata in full to the local state database of the side chain; for medium-popular graphic works, the scheduler only stores the encrypted hash and several summary fields of the entire file, and saves a copy of the original text in the off-chain distributed storage gateway, and only writes the content addressing symbol returned by the gateway into the side chain; For long-tail works that are unpopular and rarely referenced, the system only registers their top-level Merkle root and external archive number. Specific files are transferred to offline archiving nodes, and traceable evidence channels are retained through smart contracts. The verification frequency is also dynamically issued according to the popularity threshold. High-popularity entries are triggered by the scheduled task module to randomly sample blocks every hour for multi-signature verification. Medium-popularity entries switch to automatic verification once a day. Unpopular entries only initiate integrity reviews during the node's weekly routine inspection or when the work is referenced externally. The entire strategy is controlled by on-chain governance parameters. Nodes automatically refresh their local schedules after receiving threshold adjustment events. Flexible adjustment of storage granularity and verification rhythm according to content type and popularity allows the side chain to prioritize valuable on-chain space and node computing power for works with high user attention and high potential for dispute, while not sacrificing the traceability of low-visit works. This reduces the resource waste of duplicate storage and high-frequency verification while ensuring the credibility and verifiability of copyright data, alleviates node load and network congestion, and leaves room for the side chain to process when a work becomes popular or there is a surge in traffic. This on-demand allocation strategy ultimately helps the entire sub-chain maintain efficient, scalable and economically viable operation when dealing with diverse copyright assets.

[0018] When it is detected that proposal i has passed the feature matching of the pre-qualifier, a JSON description file containing the proposal hash, proposal summary and submitter's public key will be generated locally and signed, and then the addProposal interface of the public proposal pool contract will be called to write the file into the on-chain list; after receiving the transaction, the public proposal pool contract will immediately broadcast the "new proposal event" to the entire side chain network. When the author node client listens to the event, it will automatically download the decentralized storage path referenced in the proposal file and perform field-by-field verification on the metadata of the work or the license modification terms. For example, the author node can compare the fingerprint of the work, and the publisher node will verify the distribution channel and version number. After the verification is completed, each author node and publisher node will respectively Call the submitReview interface to upload the verification results and reasons, and write its own node ID into the reviewMerkle field for subsequent traceability. The management agency node calls the calculateWeight script in the aggregation phase. This script first reads the nodeProfile table on the chain to obtain the node type, 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 the review opinion and written into the voteLedger. Subsequent vote counting directly reads this weight and multiplies it by the node's voting option to obtain the weighted score. Understandably, the centralized storage of proposals in a public pool, coupled with cross-validation between authors and publishers, allows original content and publication information to be reviewed by the parties most knowledgeable about their own rights and interests, reducing the risk of omissions in single-point audits. Incorporating historical activity and consistency into weight calculations, rather than relying solely on node type, encourages continued participation and alignment with network consensus, thereby guiding governance voting to focus on real contributions without raising economic barriers. Recording weight results uniformly in the voteLedger facilitates subsequent automatic vote counting by smart contracts while maintaining a transparent audit trail, helping to quickly trace the decision-making process in the event of copyright or rule disputes. 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 condition is met includes: When submitting proposal i, the side chain gateway first calls the pre-review cache contract to generate a temporary record, which contains the proposal hash, submitter address, timestamp and IPFS path stored on the chain. Then, the complete proposal JSON is split into the declaration area, the body area and the attachment area according to the field category and written into three column families cached in the local database for parallel parsing; the pre-review service starts multi-threaded reading of the declaration area fields, such as "copyright type", "urgency", "involved work ID", "proposed modification rule ID" and other key values, and uses Bloom filter to map them into feature vectors, which are then compared with the predefined feature library maintained by the side chain node off-chain. For comparison, the feature library stores string templates for common emergency scenarios, such as "infringement removal request," "serious vulnerability patch," and "forced permission revocation." The matching algorithm uses the longest common substring combined with cosine similarity. When the match exceeds the threshold, the onMatch hook is triggered, and 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 a reason code. Proposal i remains in the cache waiting for the initiator to provide additional explanation or for the system to periodically clear it. The entire judgment process is completed in the sandbox network and does not consume on-chain gas. It is important to note that submitting proposals to the pre-screening cache and quickly comparing them with the 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 not only prevents irrelevant or malicious proposals from crowding out governance bandwidth, but also gives priority to copyright disputes and security patches that truly require a quick response. The strategy of matching declaration fields with the feature library is more accurate than simple keyword filtering, which can reduce the false positive rate while maintaining flexible rule upgrades. When the business scenario changes, only feature templates need to be added or deleted for immediate effect, without the need to modify the smart contract. The overall process sinks the judgment logic to the off-chain sandbox for execution, reducing on-chain computing overhead and voting wait time, laying a reliable entry point for the efficient governance of the subsequent public proposal pool, and ensuring that the side chain can respond quickly and accurately to sudden copyright incidents while maintaining open participation. In another preferred embodiment of the present invention, allocating voting weights includes: In the sidechain's weighting process, the voting script first traverses the nodeProfile table to read the node type and writes an initial weight for each node, such as 0.5 for management agency nodes, 0.3 for publisher nodes, and 0.2 for author nodes (other values ​​can be set based on experience). The three indicators are then weighted and summed (the coefficient ratio can also be recalibrated according to the sidechain's ecological characteristics) to obtain the weight value. After all node weights are calculated, min-max normalization is performed to ensure that the result falls 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 is completed, 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, we can maintain a clear hierarchy in the governance structure while giving long-term active and accurate nodes greater say. This not only encourages continued participation from the author community but also prevents publishers or management agencies from leaving weights unused due to lack of activity. Normalizing weights to a unified range facilitates cross-node and cross-period comparable calculations for smart contracts, avoiding precision errors caused by differences in numerical dimensions. The overall mechanism frees sidechain governance from the limitations of pure capital or static role determination, forming an incentive closed loop of "role responsibility + historical contribution" dual measurement, providing a data foundation for subsequent rapid and high-quality voting on copyright rules, thereby helping the entire plan 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 statistical engine of the side chain, the scheduler triggers a scanning script every fixed number of blocks. The script first queries the voteLedger table for the latest 100 rounds of voting records and aggregates them by node address, calculates the ratio of the theoretical number of votes each node should vote for and the number of votes actually voted, and writes the average of this ratio as activity into behaviorCache; then the script traverses the same batch of records, extracts the voting score D1 and the threshold D2 one by one, and calculates the difference ratio D. If D is less than or equal to 0.3, this item is skipped immediately to avoid including votes with low controversy in the consistency statistics; if D is greater than 0.7 and node a's choice is consistent with the final result, , a consistency parameter of 1 is generated for the node and the next step is entered. The script continues to count the total number of nodes A with the same final result in this vote, and then breaks down the percentage of nodes of the same type as node a (B). The script calculates the instantaneous consistency of node a in this vote by performing a reciprocal operation and mapping it to the 0-1 interval, then multiplies it by the consistency parameter. The script accumulates all instantaneous consistency values ​​and divides them by the number of participations to obtain the average consistency value field, which is then written back to the behaviorCache. The entire collection and calculation process is completed in the off-chain sandbox. Ultimately, the on-chain behavior data contract provides a read-only interface for activity and average consistency for the weight script to call. It should be noted that such a design allows the activity to fully reflect the continuity of node participation in governance, and naturally distinguishes nodes that are often absent or only appear on individual topics; the consistency indicator rewards those who make judgments that converge with the group consensus for a long time and do not occupy an overwhelming majority in the distribution of opinions, which can inhibit group voting and the behavior of grabbing the majority of seats; by setting a threshold for the difference ratio to exclude low-contention events, it can avoid some nodes relying on following "low-risk voting" to brush consistency, and maintain the scarcity and value of the indicator; the overall mechanism makes the weight calculation not only rely on the node identity, but also incorporates the dynamic dimension of historical performance, providing a more delicate and reliable measurement basis for the subsequent voting stage, and ultimately helping the side chain to quickly gather truly active and accurate nodes to form high-quality decisions when facing urgent copyright disputes; the reciprocal of B is taken to "the proportion of nodes of the same type in the favor camp" ” is converted into a “scarcity” indicator. When the proportion of nodes of the same type in the affirmative votes is very high (for example, B is close to 1), it means that the issue is most beneficial to this type, and there may be a risk of “grouping” or interest bias; the value obtained after taking the reciprocal approaches the lower limit of 1, so that the bonus of this type of node in the consistency is compressed, and the weight is not pushed too high by the advantage of numbers; when the proportion of nodes of the same type in the affirmative votes is low (for example, B is close to 0), it means that this type of node’s position is more neutral or a minority perspective; the reciprocal operation will amplify its contribution coefficient, so that the minority of nodes that are consistent with the final resolution of the majority will receive additional incentives; this will not only inhibit a certain group from “showing off” when proposing proposals that are beneficial to themselves, but also encourage all types of nodes to make rational judgments on issues that cross interest boundaries, thereby improving the fairness and representativeness of governance results for all participants from a mechanism perspective; It is worth noting that if the ratio B is 0 and / or the ratio B is 1, the subsequent steps of this voting process will not be executed; The vote counting contract subscribes to the voteCast event immediately after the side chain enters the voting phase. Once any node submits a vote, its address, options, and signature are written to voteLedger. At the same time, the contract's internal function fetchWeight pulls the node's voting weight w from the weight mapping table, and the contract accumulates w to the score cache of the corresponding option in real time. To avoid duplicate statistics, the contract performs hash deduplication on the node address and marks the voted flag when writing. If duplicate votes are found, the transaction is rolled back directly. During the vote counting process, whenever a new block is packaged, the governance script calls getCurrentScore to read the pros and cons score fields and calculates the support ratio P = support score / (support score + opposition score), and then compares it with the preset threshold. 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 management agency node automatically calls the executeProposal method of the execution contract after monitoring the status change. This method first verifies the integrity of the proposal hash and signature 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 cumulative weights allows the side chain to instantly see the current support trend during voting without having to wait for all nodes to vote, providing technical conditions for accelerated decision-making in the event of urgent copyright incidents; binding weights to node signatures and performing duplicate detection can prevent malicious nodes from using replay or multiple transactions to cheat, while keeping the governance process open and transparent; the threshold judgment logic makes the pass / fail criteria explicit to avoid offline human intervention; the execution phase re-verifies the hash and signature to ensure that the proposal content has not been tampered with, and the management agency node uniformly triggers the smart contract for atomic deployment, which not only ensures the non-repudiation of on-chain results, but also allows governance resolutions to be implemented at the rule level in the shortest possible path. The overall process provides a key closed loop for fast, reliable, and traceable copyright governance on the side chain. If proposal i is not passed after the preset time, it will be automatically reported; In another preferred embodiment of this invention, the automatic execution of proposal i includes: After proposal i is marked as passed by the vote counting contract, the management agency node calls the rule generator to parse the proposal content into a JSON configuration containing consensus modifications, permission adjustments and version numbers, and then splits it into several data blocks of about 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, and then broadcasted sequentially through the side chain point-to-point network; when the author node, publisher node and other management agency nodes receive the data block, they first read the sequence number and the previous hash for integrity verification until all blocks are downloaded and verified by the hash chain, and then reconstruct the complete configuration file, write the "block time, threshold parameters, state machine version" and other parameters into the global general parameters according to the preset mapping table, and write the "author upload quota, publisher distribution range, management agency punishment process" and other parameters into the role-specific parameters; the node local message queue establishes queues for the two types of parameters , global common parameters enter the broadcast channel and are pushed to all nodes via the gossip protocol, while role-specific parameters are sent only to the corresponding node group via the targeted channel based on the role tag of the node in the nodeProfile; after receiving their respective parameters, the nodes pull up the current height status snapshot in the isolated sandbox, simulate the new rules and if there are no compatibility errors, they mark the configuration as "ready" and execute sendReadySignal to submit the loading ready event to the governance contract; the smart contract counts the received ready events in real time, and when the number crosses the set ratio threshold, it generates an "activateAtHeight" field and broadcasts the synchronization effective instruction, and all nodes automatically switch to the new rules at this height; nodes that are still not ready will receive a list of difference patch packages, and will be verified and written back package by package until the status is synchronized and the "ready" confirmation is reissued; It should be noted that splitting the rules into data blocks with hash chains can avoid the failure of one-time large file transmission when the network is interrupted, and using chain hashing to ensure that each block of content has not been tampered with; separating global parameters from role parameters and adopting dual-channel push can reduce the burden on nodes to process irrelevant data, while also taking into account privacy and bandwidth efficiency; nodes rehearse rules in the local sandbox to expose potential compatibility conflicts in advance, preventing direct online operations from causing business shutdowns; the ready signal threshold mechanism ensures that the vast majority of nodes are activated only after they are ready, and the atomic switching height ensures that all nodes transition synchronously under the same block view to avoid chain forks; the lag compensation process provides a backup synchronization method for nodes with poor network conditions or weak processing capabilities, so that they will not be permanently expelled; the overall design completes rule updates in a safe and traceable manner with minimal resistance, providing side chains with a fast, stable and consistent execution channel when facing emergency copyright governance scenarios.

[0019] A copyright data security management system based on blockchain, including: Network construction module: Builds a blockchain network consisting of multiple subchains, including a main chain and side chains. A single subchain includes multiple nodes, which are divided into author nodes, publisher nodes, and management agency nodes. Weight allocation module: For a single subchain, when proposal i is determined to meet the change conditions, the management agency 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 weight is allocated to each node based on its historical behavior data and type. Execution module: The voting score is calculated in real time based on the voting weight 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 agency node triggers the smart contract to automatically execute proposal i.

[0020] The above is a detailed description of an embodiment of the present invention. However, the content is only a preferred embodiment of the present invention and should not be considered to limit the scope of the present invention. All equivalent changes and improvements made within the scope of the present invention should still fall within the scope of the present invention.

Claims

1. A copyright data security management method based on blockchain, characterized in that: The following steps are involved: Constructing a blockchain network consisting of multiple subchains, each of which includes a main chain and sidechains. Each subchain includes multiple nodes, which are divided into author nodes, publisher nodes, and management agency nodes. For a single subchain, when proposal i is determined to meet the change conditions, the management agency 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 weight is assigned to each node based on its historical behavior data and type. The voting score is calculated in real time based on the voting weight 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 agency node triggers the smart contract to automatically execute proposal i.

2. A copyright data security management method based on blockchain according to claim 1, characterized in that: The blockchain network includes a main chain and multiple side chains; Different side chains are responsible for storing different types of copyright data; The main chain uses cross-chain anchoring to ensure the consistency and non-tamperability of copyright data storage on each side chain.

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

4. The copyright data security management method based on blockchain according to claim 1 is characterized in that: Assigning voting weights includes: The historical behavior data includes activity and average consistency; Different initial weights are assigned to different types of nodes, with the weights of management agency nodes, publisher nodes, and author nodes decreasing in sequence; The historical behavior data and the initial weight are weighted and summed to obtain a weight value, and the weight value is normalized and mapped to a value interval (0, 1) to obtain a voting weight.

5. A copyright data security management method based on blockchain according to claim 4, characterized in that: Obtaining historical behavior data includes: Obtaining activity includes: Periodically obtain the voting frequency of nodes and calculate the average voting frequency as activity; Obtaining consistency includes: During a single voting process, obtain the voting score D1 and the voting score threshold D2 in the single voting record, and calculate the difference ratio D = |D1-D2| / D2; If the difference ratio D≤0.3, the subsequent steps will not be performed in this voting process; If the difference ratio D is greater than 0.7, and the voting result of node a during this voting process is the same as the final voting result, then the consistency parameter of node a is recorded as 1; Get the total number A of nodes that have the same voting result as the final one, calculate the ratio B of the number of nodes of a single type to the total number A, take the inverse 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 of the nodes in this voting process.

6. A copyright data security management method based on blockchain according to claim 5, characterized in that: If the ratio B is 0 and / or the ratio B is 1, the subsequent steps of this voting process will not be executed.

7. The copyright data security management method based on blockchain according to claim 1 is characterized in that: Automated execution proposals include: Generate rule configuration parameters based on proposal i and split them into multiple data blocks. Each data block is attached with a unique identifier and the hash value of the previous data block, and transmitted to each node in sequence. After receiving the data block, the node verifies the data integrity based on the hash chain. After completing the integrity verification of all data blocks, the node splits the verified rule configuration parameters into global common parameters and role-specific parameters according to the preset logic. The global parameters include the updated content of the network consensus rules, and the role parameters include the permission adjustment details corresponding to the author, publisher, and management agency. Generate a separate distribution queue for each parameter type. Global parameters are pushed synchronously to all nodes through the blockchain broadcast channel, and role parameters are transmitted to the corresponding node group based on the node type. After receiving the rule configuration parameters, the node first simulates the new rules in a local sandbox environment to test their 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 marks the new rule configuration parameters as ready and sends a loading ready signal to the smart contract; When the smart contract counts that more than a set proportion of nodes have sent loading ready signals, a synchronous implementation instruction is sent 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 time, the smart contract activates a delay compensation mechanism and sends differential data patch packages to them until the status is synchronized.

8. A copyright data security management system based on blockchain, characterized in that: include: Network construction module: Builds a blockchain network consisting of multiple subchains, including a main chain and side chains. A single subchain includes multiple nodes, which are divided into author nodes, publisher nodes, and management agency nodes. Weight allocation module: For a single subchain, when proposal i is determined to meet the change conditions, the management agency 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 weight is allocated to each node based on its historical behavior data and type. Execution module: The voting score is calculated in real time based on the voting weight 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 agency node triggers the smart contract to automatically execute proposal i.

Images