Blockchain-driven revenue share data management system and method

Abstract

The application discloses a blockchain-driven account distribution data management system and method, and relates to the technical field of blockchains.The method comprises the following steps: realizing data transparency and security through a hybrid architecture, realizing multi-node data synchronization and tamper resistance by relying on distributed ledger technology.Intelligent contracts automatically execute account distribution rules, solving problems such as low efficiency of fund distribution, high risk of double clearing and the like in e-commerce, supply chain and other scenarios.The system improves performance through load balancing and caching technology, and ensures data consistency in combination with a blockchain consensus mechanism.The system optimizes dynamic account distribution and cross-border settlement capabilities.The system solves the technical problems that existing account distribution systems cannot dynamically identify rule conflicts, process abnormal transaction chains in real time, and lack cross-chain collaborative error correction mechanisms in the cross-e-commerce platform multi-level account distribution scenario, and achieves the technical effects of improving account distribution timeliness and the accuracy of abnormal transaction identification by realizing dynamic aggregation of multi-platform account distribution rules and abnormal self-healing.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-driven ledger data management system and method. Background Technology

[0002] In traditional e-commerce platform revenue sharing data management, the heterogeneity and dynamism of multi-level revenue sharing rules lead to low efficiency in cross-platform collaboration. Existing systems typically rely on centralized databases for revenue sharing process management, making it difficult to handle revenue sharing operations involving multiple participants and multiple rule levels in real time. This is especially true when facing differentiated revenue sharing strategies across different e-commerce platforms (such as user level classification, dynamic adjustment of revenue sharing ratios, and differences in time-triggered conditions), resulting in a significant lack of standardization in rule alignment and parameter conversion. Furthermore, revenue sharing anomaly detection is mainly based on statistical analysis of offline historical data, which cannot effectively capture instantaneous anomalies in dynamic transaction scenarios (such as revenue sharing time node offsets and user level mismatches). Moreover, the recovery mechanism after anomaly node identification lacks cross-chain collaboration capabilities, requiring manual intervention to correct revenue sharing interruptions or data inconsistencies, severely restricting the reliability of revenue sharing in high-concurrency transaction environments. Current technologies struggle to simultaneously solve the problems of adaptive integration of multi-level rules, real-time anomaly detection, and cross-chain redundancy recovery, becoming a core bottleneck restricting the transparency and automated management of fund flows in distributed e-commerce ecosystems.

[0003] Currently, the relevant technologies have technical problems such as the inability of the revenue sharing system to dynamically identify rule conflicts and handle abnormal transaction chains in real time in multi-level revenue sharing scenarios across e-commerce platforms, and the lack of cross-chain collaborative error correction mechanisms. Summary of the Invention

[0004] This application provides a blockchain-driven revenue-sharing data management system and method, which solves the technical problems of existing revenue-sharing systems in multi-level revenue-sharing scenarios across e-commerce platforms, namely, the inability to dynamically identify rule conflicts, handle abnormal transaction chains in real time, and the lack of cross-chain collaborative error correction mechanisms.

[0005] This application provides a blockchain-driven ledger data management system, including:

[0006] The system includes: a multi-level revenue sharing rule construction module, used to parse the hierarchical relationship of revenue sharing rules and construct multi-level revenue sharing rules; an anomaly identification module, used to identify anomalies based on historical data of the multi-level revenue sharing rules and obtain revenue sharing anomaly characteristics; a multi-blockchain path segmentation module, used to segment multiple blockchain paths according to the multi-level revenue sharing rules and construct multi-level block sub-chains; and an activation rule configuration module, used to identify abnormal nodes within and between the block sub-chains based on the revenue sharing anomaly characteristics, and configure activation rules within and between the relevant abnormal nodes' block sub-chains based on the revenue sharing anomaly characteristics. The activation rules include activation time and activation conditions.

[0007] This application provides a blockchain-driven method for managing distributed ledger data, including:

[0008] The hierarchical relationship of the revenue sharing rules is analyzed to construct a multi-level revenue sharing rule system. Anomalies are identified based on historical data of the multi-level revenue sharing rules to obtain revenue sharing anomaly characteristics. Multi-blockchain path segmentation is performed according to the multi-level revenue sharing rules to construct multi-level block sub-chains. Anomaly nodes within and between the block sub-chains are identified based on the revenue sharing anomaly characteristics. Activation rules for the relevant anomaly nodes within and between the block sub-chains are configured based on the revenue sharing anomaly characteristics. The activation rules include activation time and activation conditions.

[0009] The proposed blockchain-driven revenue-sharing data management system and method, as outlined in this application, firstly achieves data transparency and security through a hybrid architecture, safeguards privacy through encryption algorithms, and leverages distributed ledger technology to achieve multi-node data synchronization and tamper-proofing. Smart contracts automate the execution of revenue-sharing rules, addressing issues such as low efficiency in fund allocation and high risk of secondary clearing in e-commerce and supply chain scenarios. The system improves performance through load balancing and caching technologies, and ensures data consistency through a blockchain consensus mechanism. Future technological integration with AI and open banking interfaces further optimizes dynamic revenue sharing and cross-border settlement capabilities, achieving improved revenue sharing timeliness and accuracy in identifying abnormal transactions through dynamic aggregation and anomaly self-healing of revenue-sharing rules across multiple platforms. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments of this disclosure will be briefly described below. Flowcharts are used in this application to illustrate the operations performed by the system according to the embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from these processes.

[0011] Figure 1A schematic diagram of the structure of a blockchain-driven revenue-sharing data management system provided in an embodiment of this application;

[0012] Figure 2 This is a flowchart illustrating the blockchain-driven ledger data management method provided in an embodiment of this application.

[0013] Figure labeling: Multi-level ledger rule construction module 10, anomaly identification module 20, multi-blockchain road segmentation module 30, activation rule configuration module 40. Detailed Implementation

[0014] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below.

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description of this application will be provided in conjunction with the accompanying drawings. The described embodiments should not be considered as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the following description, references to "some embodiments" describe a subset of all possible embodiments. However, it is understood that "some embodiments" can be the same or different subsets of all possible embodiments and can be combined with each other without conflict. The terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. The terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only.

[0017] This application provides a blockchain-driven ledger data management system, such as... Figure 1 As shown, the method includes:

[0018] A multi-level revenue sharing rule construction module 10 is used to parse the hierarchical relationship of revenue sharing rules and construct multi-level revenue sharing rules. Specifically, when constructing multi-level revenue sharing rules, revenue sharing rules from different e-commerce platforms, including user levels, proportions, and time rules, are first comprehensively collected. A parsing list is generated by decomposing the revenue sharing rule parsing sub-units. Then, based on the revenue sharing proportion and time rules as features, the rules are classified using hierarchical sub-units. Classification attribute tags are formed by combining the correspondence between revenue sharing user levels and revenue sharing proportions and time rules, and added to the rule hierarchy classification to obtain the multi-level revenue sharing rules for each platform. After standardized parameter conversion, parameter alignment, and cross-platform clustering, a general multi-level revenue sharing rule is constructed. The general multi-level revenue sharing rule achieves traceability through the blockchain's chain data structure. Each revenue sharing transaction is recorded in a block, including a timestamp, hash value, and the hash of the previous block, forming an immutable chain ledger. When configuring different block sub-chains, the system verifies the legality of revenue sharing transactions based on a consensus mechanism (such as PoW or PoS). For example, Proof-of-Stake (PoS) allocates verification rights based on the amount of tokens held by users, preventing malicious nodes from manipulating the ledger parameters. Transaction data uses encryption algorithms (such as the SHA-256 hash function) and digital signatures to ensure privacy and integrity. To address potential anomalies in the ledger process, after the anomaly identification module identifies anomalies, the activation rule configuration module uses the ledger anomaly node acquisition unit to determine the abnormal node, extracts the abnormal data, and determines the activation time and conditions through error correction time compensation and ledger parameter compensation, thus forming activation rules. At this point, the smart contract automatically executes error correction logic, such as triggering ledger ratio correction or time compensation rules, and broadcasts the corrected data to all network nodes to re-achieve consensus. Simultaneously, redundant storage blocks are set up and their activation rules with abnormal nodes are established. The redundant blocks synchronously store copies of the ledger data through distributed nodes, ensuring that a single point of failure does not affect the consistency of the global ledger. After the abnormal node is verified to be correct, the data is recorded from the redundant storage block to the ledger blockchain according to the rules. The irreversible nature of the blockchain (modification requires more than 51% of the computing power) ensures the accuracy and reliability of the final on-chain data.

[0019] In one possible implementation, the multi-level revenue sharing rule construction module 10 further includes a multi-level revenue sharing rule acquisition unit. This unit is used to obtain the multi-level revenue sharing rules of a target e-commerce platform based on the revenue sharing rules of multiple target e-commerce platforms. Specifically, the multi-level revenue sharing rule acquisition unit first determines the scope of the target e-commerce platforms, collects their revenue sharing rule information using technical interface interfaces and data protocol interactions, decomposes the rules using a revenue sharing rule parsing sub-unit, clarifies the revenue sharing user level (e.g., ordinary consumers, different levels of members), revenue sharing ratio (involving platform, merchant, and other parties' revenue sharing), and revenue sharing time rules (real-time, daily, monthly, etc.), and constructs a revenue sharing rule parsing list. Then, a rule hierarchical sub-unit divides the rules into levels based on the revenue sharing ratio and revenue sharing time rules. Finally, the multi-level revenue sharing rule acquisition sub-unit adds the revenue sharing user level as a classification attribute label to the corresponding rule level category based on the correspondence between the revenue sharing user level and the revenue sharing ratio and time rules, thereby generating multi-level revenue sharing rules for each target e-commerce platform that include different levels, corresponding to different revenue sharing user levels, and their corresponding revenue sharing ratios and time rules.

[0020] A standardized parameter conversion unit is used to perform standardized parameter conversion based on the multi-level revenue sharing rules of the target e-commerce platform. Specifically, the standardized parameter conversion unit first comprehensively reviews parameters such as revenue sharing user level, revenue sharing ratio, and revenue sharing time rules in the multi-level revenue sharing rules of each target e-commerce platform. It uses algorithms and tools to identify parameter differences between different platforms, such as differences in user level classification and naming, revenue sharing ratio representation, and revenue sharing time recording format, and establishes a difference matrix. Next, based on these differences, a unified conversion rule is formulated, unifying the revenue sharing user level classification system and determining the mapping relationship; the revenue sharing ratio is unified into a percentage form, and a conversion algorithm is written; the revenue sharing time rules are unified into the format "YYYY-MM-DD_HH:MM:SS", and a conversion function is formulated. Finally, the parameters are converted one by one according to the rules, strictly verified, and a conversion log is established to record the original values, process, and results. A consistency check is performed on the converted rules to ensure the correctness of the parameter logical relationships, thereby unifying parameters with large differences into a standard format, laying the foundation for subsequent operations.

[0021] The parameter alignment unit aligns the standardized multi-level revenue sharing rules and performs cross-platform hierarchical clustering based on the hierarchical relationship of the parameter alignment to obtain the multi-level revenue sharing rules. Specifically, the parameter alignment unit first determines key alignment dimensions such as revenue sharing user level, revenue sharing ratio, and revenue sharing time rules. Based on these dimensions, a framework is constructed, and the standardized revenue sharing rule parameters of each platform are arranged according to the framework. Then, the parameters of each dimension are compared horizontally, such as arranging the revenue sharing ratio of ordinary users on each platform in order to complete the parameter alignment. Next, the hierarchical relationship is analyzed based on the revenue sharing user level, revenue sharing ratio, and urgency of revenue sharing time rules. A cross-platform hierarchical clustering strategy is formulated, and a hierarchical clustering algorithm, such as hierarchical clustering, is used to merge revenue sharing rules with similar levels and characteristics from different platforms into one category. Finally, a multi-level revenue sharing rule with a clear hierarchical structure that integrates the characteristics of multi-platform revenue sharing rules is generated, providing a standardized basis for subsequent revenue sharing data management.

[0022] In one possible implementation, the multi-level revenue sharing rule acquisition unit further includes a revenue sharing rule parsing subunit, which is used to parse the revenue sharing rules of multiple target e-commerce platforms according to the revenue sharing user level, revenue sharing ratio, and revenue sharing time rules, and construct a revenue sharing rule parsing list for each target e-commerce platform. Specifically, the revenue sharing rule parsing subunit first extensively collects revenue sharing rule information from multiple target e-commerce platforms of different sizes, business types, and market positioning. Data is acquired through APIs or web crawlers, and adapted to different formats such as XML, JSON, and CSV. Simultaneously, database transaction locks and Redis queue technology are used to ensure the stability and consistency of high-concurrency data collection. Subsequently, based on the revenue sharing user level, different levels such as ordinary users and bronze members are identified, along with their corresponding rules. The revenue sharing ratio is then clarified, specifying the revenue sharing among the platform, merchants, and suppliers under different business scenarios. For example, in the sale of a certain product, the platform receives 15%, the merchant 70%, and the supplier 15% (the ratio parameters need to be dynamically stored in the revenue sharing rule table and can be adjusted according to multiple dimensions such as orders, products, and activities). Finally, the revenue sharing time rules are determined: whether it is real-time, daily scheduled, or monthly fixed-date revenue sharing (supporting D0 real-time arrival and T+1 flexible settlement modes). Finally, through detailed analysis of these three key elements, a structured list of revenue sharing rules for each platform was constructed (the database design includes four core tables: transaction table, revenue sharing table, account table, and rule table, recording full-link information such as amount, timestamp, and revenue sharing path). Each row represents a revenue sharing rule scenario, and each column records information such as revenue sharing user level, revenue sharing ratio, and revenue sharing time rules (fields must include extended parameters such as revenue sharing party ID, hierarchical relationship, settlement cycle, and revenue sharing failure retry strategy). This provides a clear and orderly data foundation for subsequent processing (the data must be tamper-proofed through MD5+RSA dual signature mechanism and stored in a bank custody account supervised by the central bank to ensure compliance).

[0023] The rule grading subunit is used to categorize rules based on the revenue sharing rule parsing list, using the revenue sharing ratio as the first classification feature and the revenue sharing time rule as the second classification feature, to obtain a rule hierarchy classification. Specifically, after obtaining the revenue sharing rule parsing list, the rule grading subunit first deeply understands the profit distribution weight represented by the revenue sharing ratio and the business timeliness significance reflected by the revenue sharing time rule. Then, using the revenue sharing ratio as the first feature, it sets the ratio greater than 60% as the high-ratio level, covering core business or important cooperative revenue sharing; 30%-60% as the medium-ratio level, corresponding to general business; and less than 30% as the low-ratio level, involving auxiliary or promotional business revenue sharing, completing the initial grading. Next, using the revenue sharing time rule as the second feature, it refines the grading within each revenue sharing ratio level. For example, in the high-ratio level, real-time revenue sharing is set as the highest sub-level, daily scheduled revenue sharing is next, and monthly revenue sharing is relatively low. The medium and low-ratio levels are also divided in a similar way. Ultimately, a clear hierarchical classification of rules is generated, with each level and sub-level corresponding to specific revenue sharing rules, providing an orderly framework for subsequent revenue sharing rule analysis and application.

[0024] The multi-level revenue sharing rule acquisition subunit is used to obtain the multi-level revenue sharing rules of each target e-commerce platform by adding them as category attribute tags to the corresponding rule level categories based on the correspondence between the revenue sharing user level and the revenue sharing ratio and revenue sharing time rules. Specifically, after the rule classification subunit completes the rule level classification, the multi-level revenue sharing rule acquisition subunit performs in-depth analysis of the revenue sharing rule parsing list, sorts out the correspondence between the revenue sharing user level (such as ordinary, bronze, silver, gold members, etc.) and the revenue sharing ratio and revenue sharing time rules, and uses them as category attribute tags. Then, according to the rule level classification system, these tags are accurately added to the corresponding level. For example, in the high ratio-real-time revenue sharing sub-level, if there is a rule that diamond members enjoy a high ratio of real-time revenue sharing on the sale of high-end products, it is labeled "diamond member". This process is followed for each target e-commerce platform, such as Platform A and Platform B, ultimately forming a multi-level revenue sharing rule that includes different levels, corresponding to specific revenue sharing user grades, their revenue sharing ratios, and revenue sharing time rules. This provides a comprehensive and detailed rule basis for the e-commerce platform's subsequent revenue sharing, financial, and business decisions.

[0025] In one possible implementation, the multi-level revenue sharing rule acquisition unit further includes: a new revenue sharing rule acquisition subunit, which is used to acquire new revenue sharing rules, including revenue sharing rules for new e-commerce platforms and new revenue sharing rules for target e-commerce platforms. Specifically, when acquiring new revenue sharing rules for e-commerce platforms, the new revenue sharing rule acquisition subunit communicates with platform operations or technical personnel to obtain rule documents that record detailed revenue sharing ratios, time nodes, and special conditions with various partners under different business scenarios, such as the revenue sharing rules for imported goods sales on a cross-border e-commerce platform; on the other hand, it analyzes the flow of funds by simulating transaction processes and using network packet capture and other technical means to fully understand the details of revenue sharing operations. For new revenue sharing rules for target e-commerce platforms, the subunit pays attention to announcements and policy updates released through the platform's official website, merchant backend, and other channels, such as the new revenue sharing rules formulated by a comprehensive e-commerce platform to encourage live-streaming sales; on the other hand, it establishes a monitoring interface with the platform's internal system to capture changes in revenue sharing rules caused by business module upgrades or adjustments in real time, such as the optimization of revenue sharing rules for the platform's group-buying business.

[0026] The mapping and matching subunit is used to perform mapping and matching between the newly added revenue sharing rules and the multi-level revenue sharing rules to obtain a matching positioning relationship. Specifically, the mapping and matching subunit first extracts elements from the newly added revenue sharing rules and the multi-level revenue sharing rules respectively. For the newly added rules, whether it is a revenue sharing rule for VIP users purchasing specific brand products on a new e-commerce platform, or a revenue sharing rule adjustment for a new promotional activity on a target e-commerce platform, detailed elements such as revenue sharing user level, revenue sharing ratio, revenue sharing time, and special business scenarios are extracted. For the multi-level revenue sharing rules, the data is organized into a dataset according to revenue sharing user level, revenue sharing ratio range, revenue sharing time type, and business scenario category. Then, mapping and matching are performed. First, preliminary matching is performed based on revenue sharing ratio and revenue sharing time rules to filter out candidate rules. Then, comprehensive matching is performed by comprehensively considering elements such as revenue sharing user level and business scenario to find rules with high matching degree. Finally, the matching positioning relationship is determined, the level to which the newly added rule should be positioned is clarified, the differences with other rules in this level are recorded, and its association with other related rules is determined.

[0027] The hierarchical projection subunit is used to project the newly added revenue-sharing rules hierarchically according to the matching and positioning relationship, updating the multi-level revenue-sharing rules of the target e-commerce platform. Specifically, after receiving the matching and positioning relationship provided by the mapping and matching subunit, the hierarchical projection subunit deeply analyzes the corresponding levels and associations between the newly added revenue-sharing rules and the existing multi-level revenue-sharing rule system. For example, it analyzes the differences in revenue-sharing ratios, revenue-sharing times, and other elements of the newly added rule in the "Premium Member - Limited-Time Discount Promotion" level, as well as its association with other rules. Based on the analysis results, the projection level and position are accurately determined, and the elements such as revenue-sharing ratios and revenue-sharing times are reasonably sorted within the level. Subsequently, the hierarchical projection operation is executed to fully insert the new rule into the target level position, ensuring compatibility with other rules, identifying new business scenarios or special conditions, and updating the association relationship records. Finally, the multi-level revenue-sharing rule records are fully updated, recording the detailed content of the new rule, insertion time, source, association relationships, and other metadata in the database, updating the rule version number, and ensuring that the revenue-sharing business can accurately apply the latest rules.

[0028] An anomaly identification module 20 is used to identify anomalies based on historical data of the multi-level revenue sharing rules and obtain anomaly characteristics. Specifically, the anomaly identification module 20 first extensively collects historical data of multi-level revenue sharing rules from various e-commerce platforms, classifying and storing it according to revenue sharing user level, business scenario, and revenue sharing time period. Based on the characteristics of the revenue sharing rules and the patterns of historical data, the revenue sharing rules are divided into different levels according to revenue sharing ratio, time, etc., such as high-ratio real-time revenue sharing as high-level and low-ratio monthly revenue sharing as low-level. Different blockchain sub-chains are configured for different levels, such as high-performance sidechains for high-level and conventional sidechains for low-level. Next, possible anomalies in revenue sharing are analyzed, such as incorrect amounts, time delays, and incorrect subject information, and an algorithm is used to scan historical data to identify anomalies. To prevent problems caused by the immutability of blockchain, activation rules are designed for nodes that may have anomalies. After detecting an abnormal risk node, a verification program is started to re-verify rule execution, data transmission, etc. Only after confirming that there are no problems is the revenue sharing data recorded in the revenue sharing blockchain to ensure the normal operation of the revenue sharing business.

[0029] In one possible implementation, the anomaly identification module 20 further includes an anomaly feedback information extraction unit, which is used to extract anomaly feedback information based on historical data of the multi-level revenue sharing rules. Specifically, the anomaly feedback information extraction unit extensively collects historical data of multi-level revenue sharing rules from multiple channels such as e-commerce platform transaction databases, log files, and business documents, and adapts to different formats such as MySQL, text, and PDF. By clarifying the parameter range and logical relationship of normal revenue sharing rules, such as stipulating revenue sharing within 24 hours for ordinary transactions, setting revenue sharing ratio ranges and execution process standards, and establishing a normal revenue sharing data model in conjunction with statistical analysis, anomaly data screening standards are formulated. Then, the historical data is traversed line by line according to these standards, checking the revenue sharing time, ratio, and rule execution process, marking abnormal records, and finally integrating the key information of the abnormal records and outputting it to a dedicated data structure to provide a foundation for subsequent revenue sharing anomaly feature analysis.

[0030] The revenue sharing anomaly feature acquisition unit is used to extract features based on the anomaly feedback information according to the feedback participants and anomaly revenue sharing parameters to obtain the revenue sharing anomaly features. The anomaly revenue sharing parameters include revenue sharing time nodes, revenue sharing rules, and revenue sharing user levels. Specifically, the revenue sharing anomaly feature acquisition unit first sorts out the feedback participants in the anomaly feedback information, extracting features from aspects such as the e-commerce platform's technical architecture, the merchant's business scale and type, and supplier cooperation relationships. For example, small merchants are prone to errors due to technical integration, and problems may occur after platform system updates. Next, the revenue sharing time nodes are analyzed, statistically analyzing the concentrated periods of anomalies, the degree of deviation, and their correlation with business activities. For example, promotional activities will affect the revenue sharing time. Then, the differences between the actual and preset revenue sharing rules are compared to evaluate the adaptability of the rules under the new business model. Furthermore, the correlation between different revenue sharing user levels and anomalies and the impact on user behavior are studied; for example, VIP users are more prone to anomalies due to complex rights and transaction behavior. Finally, these features extracted from different aspects are fused to construct a multi-dimensional feature vector, which is output to a database table or other storage system for subsequent analysis.

[0031] The multi-blockchain path segmentation module 30 is used to segment multiple blockchain paths according to the multi-level revenue sharing rules and construct multi-level block sub-chains. Specifically, the multi-blockchain path segmentation module 30 first comprehensively organizes the revenue sharing rules under various business scenarios of different e-commerce platforms. Based on factors such as revenue sharing ratio, time, and importance, the revenue sharing rules are divided into high-level (e.g., high-proportion real-time revenue sharing for high-end luxury goods) and low-level (e.g., low-proportion monthly revenue sharing for small merchants) according to complexity and timeliness requirements, forming a general hierarchical system. Then, a segmentation strategy is formulated accordingly, using a high-performance consortium blockchain for the high-level level and a public blockchain sidechain technology for the low-level level, and then constructing adapted multi-level block sub-chains, designing different block structures and consensus mechanisms. At the same time, it deeply analyzes the abnormal problems that may occur in the revenue sharing, such as amount errors, time delays, and errors in subject information. Activation rules are set for blockchain nodes that may be abnormal. After detecting abnormal risk nodes, a verification procedure is initiated. Only after confirming that there are no errors are the revenue sharing data recorded, ensuring the normal operation of the revenue sharing business while utilizing the immutability of blockchain.

[0032] In one possible implementation, the multi-blockchain path segmentation module 30 further includes a link structure definition unit, which defines the structure of the blockchain path based on the revenue sharing rules and transaction processes. Specifically, the link structure definition unit first extensively collects revenue sharing rules from different e-commerce platforms, covering revenue sharing ratios, timeframes, entities, and triggering conditions, such as different revenue sharing rules for daily sales and promotional activities, as well as progressive revenue sharing rules; it also analyzes the transaction process, including user order placement and after-sales service. Next, based on the revenue sharing rules, it analyzes the hierarchical relationships, divides the levels into high and low levels according to ratios and business importance, analyzes the different levels of transaction links for progressive rules, and clarifies the triggering conditions and data flow. Finally, it defines the blockchain path structure, sets up nodes to record information at key transaction stages; adopts encrypted transmission protocols to ensure data transmission security, selects storage methods and capacity based on data characteristics; and designs hierarchical associations through smart contracts to achieve automatic switching of levels and data transmission, laying the foundation for the construction of multi-level blockchain paths.

[0033] A multi-level blockchain path construction unit is used to establish a multi-level blockchain path, including multiple block sub-chains, based on a defined blockchain path structure and according to the multi-level revenue sharing rules. Specifically, the multi-level blockchain path construction unit first studies the blockchain path structure defined by the link structure definition unit, including node settings, data transmission and storage, and analyzes the multi-level revenue sharing rules to clarify the basis and triggering conditions for level division. Then, according to the rules, the revenue sharing business is divided into different levels, such as core business corresponding to higher levels and ordinary small transactions corresponding to lower levels. Different stages of the progressive rules each form a level, and a corresponding block sub-chain is created at each level. Appropriate node devices and consensus algorithms are selected based on the characteristics of each level. Finally, a transaction link between different levels is built for the progressive revenue sharing rules, the data transmission format and content are precisely designed, and a level association mechanism is established through smart contracts to achieve automatic level switching and data transmission, recording the relevant processes. This successfully establishes a multi-level blockchain path containing multiple block sub-chains, providing an effective solution for e-commerce revenue sharing business.

[0034] The revenue sharing connection relationship parsing unit is used to parse the revenue sharing connection relationships of multi-level revenue sharing rules of various target e-commerce platforms. Based on these relationships, it establishes transaction connections for blockchain sub-chains through smart contracts, thereby obtaining the multi-layered blockchain sub-chains. Specifically, the revenue sharing connection relationship parsing unit first collects multi-level revenue sharing rule data from multiple channels of e-commerce platforms and categorizes and organizes it by type and level. Next, it deeply analyzes the rule logic, sorts out the hierarchical relationships, and identifies transaction links, such as clarifying the logic of order quantity triggering changes in revenue sharing ratios and level conversions in progressive revenue sharing rules. Then, based on the parsing results, it formulates smart contract logic, designs data interaction methods, implements the code in a suitable language, and conducts detailed testing. Afterward, it deploys the smart contract to the blockchain network, configures parameters and permissions, establishes blockchain sub-chain transaction connections through the contract, and completes data transfer between levels. Finally, it uses the blockchain consensus mechanism to verify and confirm the validity of the connection, ensuring that the revenue sharing results are officially recorded, thereby obtaining multi-layered blockchain sub-chains and achieving efficient execution and management of multi-level revenue sharing rules on the blockchain.

[0035] In one possible implementation, the revenue sharing connection relationship parsing unit further includes a revenue sharing progressive connection relationship acquisition subunit. This subunit is used to analyze the revenue sharing conditions between different levels based on the multi-level revenue sharing rules of each target e-commerce platform to obtain the revenue sharing progressive connection relationship. Specifically, the revenue sharing progressive connection relationship acquisition subunit first obtains multi-level revenue sharing rule data from official e-commerce platform documents, database records, and business process documents, collecting this data through collaboration with the technical team and communication with business personnel. Next, the data is cleaned, classified, and standardized preprocessed. Then, the logic of each level of revenue sharing rules is thoroughly analyzed, the triggering conditions for level transitions are identified, and the correlation with other business factors is analyzed. Based on the analysis results, a revenue sharing progressive connection relationship model is constructed. After simulation verification and optimization, the results are output in report form and stored in the database, thereby accurately obtaining the revenue sharing progressive connection relationship.

[0036] The user-level revenue sharing connection relationship acquisition subunit is used to analyze the progressive relationship of revenue sharing rules for user levels based on the category attribute tags, and obtain the user-level revenue sharing connection relationship. Specifically, the user-level revenue sharing connection relationship acquisition subunit first clarifies the range of category attribute tags such as consumption amount and consumption frequency, collects relevant data from multiple data sources of the e-commerce platform, and cleans and preprocesses it. Next, it collects and organizes the revenue sharing rules of the e-commerce platform for different user levels, sorts them by level, and analyzes special cases. Then, it analyzes the changes in user level upgrade conditions and revenue sharing rules, and establishes a progressive relationship model of rules. The model is then validated, optimized based on the results, and unreasonable upgrade conditions and revenue sharing rules are adjusted. Finally, reliable user-level revenue sharing connection relationships are determined and saved, and a monitoring mechanism is established for adjustment according to business development.

[0037] The revenue sharing connection relationship acquisition subunit is used to obtain the revenue sharing connection relationship based on the revenue sharing progressive connection relationship and the user-level revenue sharing connection relationship. Specifically, the revenue sharing connection relationship acquisition subunit first receives corresponding data from the revenue sharing progressive connection relationship acquisition subunit and the user-level revenue sharing connection relationship acquisition subunit, and strictly checks its completeness, accuracy, and consistency. Next, the data from the two relationships are merged, and the correlation between them is analyzed. Then, rules are integrated to construct a revenue sharing connection relationship model, and the relationships between various elements are displayed using tools such as flowcharts or decision trees. The model is then validated using historical data, and the rule parameters and modeling methods are optimized based on the results. Finally, the final revenue sharing connection relationship is determined, and the results are output in the form of a document report and stored in the database, providing a basis for integration with the e-commerce platform's revenue sharing system.

[0038] The activation rule configuration module 40 is used to identify abnormal nodes within and between blockchain sub-chains based on the abnormal characteristics of the revenue sharing. It then configures activation rules for these abnormal nodes within and between blockchain sub-chains, including activation time and activation conditions. Specifically, the redundant storage block setting unit of the activation rule configuration module 40 first collects revenue sharing rules from different e-commerce platforms, categorizes them into levels based on complexity and importance, and configures corresponding blockchain sub-chains for each level. Next, it analyzes potential abnormal problems in revenue sharing, such as calculation errors and time delays, and identifies blockchain nodes that may be abnormal. Then, based on the abnormal nodes, it determines the basis for setting redundant storage blocks, creates redundant storage blocks in the corresponding blockchain sub-chain, and establishes a data synchronization mechanism. Finally, it sets activation rules for abnormal risk nodes, clarifies activation conditions and processing procedures, implements the rules, and monitors them in real time. Once the node is confirmed to be problem-free, the data is recorded on the revenue sharing blockchain, and the processing results are fed back for business decision-making reference, thereby ensuring blockchain data security and the normal operation of the revenue sharing business.

[0039] In one possible implementation, the activation rule configuration module 40 further includes a redundant storage block setting unit, which is used to set redundant storage blocks for the sub-chain based on abnormal nodes. Specifically, the redundant storage block setting unit first constructs a monitoring system to collect blockchain node operation data, analyzes and accurately locates abnormal nodes using a preset algorithm, and records detailed information. Next, it evaluates the functionality and structure of the sub-chain containing abnormal nodes and predicts risks. Then, it selects suitable nodes to create redundant storage blocks, initializes them according to the sub-chain format, copies key data, and verifies it. Then, it determines activation conditions based on the anomaly type and risk assessment, formulates activation rules, and monitors them in real time; activation is automatically triggered when the conditions are met. Finally, it rigorously verifies data before importing, imports it according to the rules, updates the sub-chain status, closely monitors the sub-chain operation after importing, and summarizes and analyzes the processing process for subsequent reference to ensure the stable operation of the ledger blockchain.

[0040] An activation rule building unit is used to establish activation rules for the redundant storage blocks and the abnormal nodes. Specifically, the activation rule building unit first collects information such as the historical operation, hardware configuration, and network environment of the abnormal nodes, as well as information such as the storage capacity, synchronization mechanism, and location distribution of the redundant storage blocks. Then, activation conditions are determined based on factors such as the abnormal node's state, data integrity, and network conditions, such as error rate, response time, data loss rate, and network latency reaching certain thresholds to trigger activation. Next, an activation process is designed, including data verification, import, and state update processes, to ensure accurate data import and updating of the blockchain state. The rules are then tested using simulations and historical data to simulate abnormal situations, and the activation conditions and processes are optimized based on the results. Finally, the optimized rules are deployed to the ledger blockchain system, integrated with smart contracts, and a monitoring mechanism is established to monitor rule execution in real time, record information, and handle anomalies to ensure timely system recovery in case of anomalies.

[0041] In one possible implementation, the activation rule configuration module 40 further includes: a revenue sharing anomaly node acquisition unit, which is used to obtain the revenue sharing anomaly characteristics of anomaly nodes. Specifically, the revenue sharing anomaly node acquisition unit first collects data from multiple data sources such as blockchain transaction records, node log files, and the revenue sharing system database, completing the collection through corresponding interfaces, tools, and query statements. Next, it defines anomaly characteristics such as revenue sharing ratio, revenue sharing time, and transaction data, and sets judgment rules, such as setting an error range for the revenue sharing ratio and determining the normal range for revenue sharing time based on historical data. After cleaning, transforming, and normalizing the collected data, it uses rules to identify anomaly characteristics, and then deeply analyzes the causes and impacts of the anomalies, such as determining whether they are caused by rule configuration, network issues, input errors, or attacks. Finally, it compiles the identification results and analysis into a report and outputs it to the business and technical teams to provide a basis for decision-making, while storing the anomaly information for subsequent analysis and prediction, thereby effectively obtaining the revenue sharing anomaly characteristics of anomaly nodes.

[0042] An abnormal data extraction unit is used to extract abnormal time, abnormal revenue sharing ratio, and abnormal user level based on the revenue sharing anomaly characteristics. Specifically, the abnormal data extraction unit first interfaces with the revenue sharing anomaly node acquisition unit to receive and confirm the revenue sharing anomaly characteristic information, stores it in the database, and builds an index. Then, according to the revenue sharing business process and rules, it extracts the abnormal time, abnormal revenue sharing ratio, and abnormal user level respectively. When extracting abnormal time, rules are formulated to filter and verify time data; when extracting abnormal revenue sharing ratio, a standard range needs to be determined, and the abnormal ratio needs to be matched and analyzed; when extracting abnormal user level, rules need to be sorted out, and level information needs to be compared and verified. Finally, the extracted data is organized into a specific format and output to relevant departments, while backing up the data for audit traceability, providing key data support for the handling of revenue sharing business anomalies.

[0043] The error correction time compensation unit is used to compensate for the abnormal time to obtain the activation time. Specifically, the error correction time compensation unit first interfaces with the abnormal data extraction unit to receive and check the integrity of the abnormal time data. Next, it assesses the impact of the abnormal time in conjunction with the revenue sharing business process and analyzes related factors. Then, based on the impact analysis, it determines the compensation principle, selects an appropriate compensation method (such as time extension, priority processing, additional rewards, etc.), and calculates the compensation time. Afterwards, it uses the end time of the abnormal event as a base, adds the compensation time to obtain the activation time, and checks its rationality; if unreasonable, it readjusts it. Finally, it outputs the activation time to the relevant business departments and technical systems, while recording the activation time and related abnormal times, compensation strategies, calculation processes, and other information in detail for subsequent audit analysis to ensure the normal recovery and stable operation of the revenue sharing business.

[0044] The revenue sharing parameter compensation unit is used to compensate for abnormal revenue sharing ratios and abnormal user levels to obtain activation conditions. Specifically, the revenue sharing parameter compensation unit first interfaces with the abnormal data extraction unit to receive and verify the abnormal revenue sharing ratio and abnormal user level information to ensure data accuracy and completeness. Next, it analyzes the impact of the anomaly in conjunction with the revenue sharing business process and assesses the losses of all parties. Based on the assessment results, it determines fair, reasonable, and transparent compensation principles and formulates specific compensation methods for abnormal revenue sharing ratios and user levels, such as recovering and redistributing amounts for abnormal ratios, and restoring levels and adjusting revenue sharing amounts for abnormal levels. Then, it determines the activation conditions based on the compensation strategy, including data correction completion, loss compensation in place, and business process restoration to normal. Finally, it verifies the activation conditions to ensure their reasonableness and feasibility, outputs the verified activation conditions to relevant business and technical systems, and records backups to support the recovery and stable operation of the revenue sharing business.

[0045] An activation rule determination unit is established, which uses the activation time and activation conditions as the activation rules. Specifically, the activation rule determination unit first interfaces with the error correction time compensation unit and the revenue sharing parameter compensation unit to receive and verify the activation time and activation conditions, ensuring data accuracy and reliability. Then, an activation rule framework is constructed around these two units, refining and improving the rule content. Next, the association between abnormal nodes and redundant storage blocks is identified, and the rules are embedded into their interaction mechanism and tested. Based on business characteristics, confirmation periods and connection rules for adding activation rules to the blockchain are formulated, and activation conditions and confirmation periods are monitored in real time. When the conditions are met, the addition operation is triggered and data verification is performed. Finally, the rule formulation and execution process is recorded and audited in detail, and the rules are regularly evaluated and optimized to adapt to business and technological changes, providing assurance for the handling and recovery of revenue sharing anomalies.

[0046] This application's embodiments employ a hybrid architecture to achieve data transparency and security, utilize encryption algorithms to protect privacy, and leverage distributed ledger technology to achieve multi-node data synchronization and tamper-proofing. Smart contracts automatically execute revenue sharing rules, addressing issues such as low fund allocation efficiency and high risk of second-party clearing in e-commerce and supply chain scenarios. The system improves performance through load balancing and caching technologies, and ensures data consistency through blockchain consensus mechanisms. Further optimization of dynamic revenue sharing and cross-border settlement capabilities achieves improved revenue sharing timeliness and accuracy in identifying abnormal transactions by dynamically aggregating revenue sharing rules from multiple platforms and enabling self-healing of anomalies.

[0047] In the above text, refer to Figure 1 A blockchain-driven revenue-sharing data management system according to embodiments of the present invention is described in detail. Next, reference will be made to... Figure 2 A blockchain-driven ledger data management method according to an embodiment of the present invention is described.

[0048] Blockchain-driven revenue-sharing data management methods, such as Figure 2 As shown, the method includes:

[0049] The hierarchical relationship of the revenue sharing rules is analyzed to construct a multi-level revenue sharing rule system. Anomalies are identified based on historical data of the multi-level revenue sharing rules to obtain revenue sharing anomaly characteristics. Multi-blockchain path segmentation is performed according to the multi-level revenue sharing rules to construct multi-level block sub-chains. Anomaly nodes within and between the block sub-chains are identified based on the revenue sharing anomaly characteristics. Activation rules for the relevant anomaly nodes within and between the block sub-chains are configured based on the revenue sharing anomaly characteristics. The activation rules include activation time and activation conditions.

[0050] In one possible implementation, the blockchain-driven revenue sharing data management method further includes: obtaining multi-level revenue sharing rules for multiple target e-commerce platforms based on their revenue sharing rules; performing standardized parameter conversion based on the multi-level revenue sharing rules of the target e-commerce platforms; aligning the parameters of the multi-level revenue sharing rules after standardized parameter conversion; and performing cross-platform hierarchical clustering according to the hierarchical relationship of parameter alignment to obtain the multi-level revenue sharing rules.

[0051] In one possible implementation, the blockchain-driven revenue sharing data management method further includes: parsing the revenue sharing rules of multiple target e-commerce platforms according to revenue sharing user level, revenue sharing ratio, and revenue sharing time rules, and constructing a revenue sharing rule parsing list for each target e-commerce platform; classifying the rules according to the revenue sharing rule parsing list, using the revenue sharing ratio as the first classification feature and the revenue sharing time rule as the second classification feature, to obtain a rule hierarchy classification; and adding the corresponding rule hierarchy classification as a classification attribute tag based on the correspondence between the revenue sharing user level and the revenue sharing ratio and revenue sharing time rules, to obtain multi-level revenue sharing rules for each target e-commerce platform.

[0052] In one possible implementation, the blockchain-driven revenue sharing data management method further includes: obtaining new revenue sharing rules, which include new revenue sharing rules for new e-commerce platforms and new revenue sharing rules for target e-commerce platforms; mapping and matching the new revenue sharing rules with the multi-level revenue sharing rules to obtain a matching positioning relationship; and projecting the new revenue sharing rules hierarchically according to the matching positioning relationship to update the multi-level revenue sharing rules of the target e-commerce platform.

[0053] In one possible implementation, the blockchain-driven revenue sharing data management method further includes: defining the structure of the blockchain path according to the revenue sharing rules and transaction process; establishing a multi-level blockchain path, including multiple block sub-chains, based on the defined blockchain path structure and the multi-level revenue sharing rules; parsing the revenue sharing connection relationship of the multi-level revenue sharing rules of each target e-commerce platform, and establishing a transaction connection of the block sub-chains through smart contracts according to the revenue sharing connection relationship to obtain the multi-level block sub-chains.

[0054] In one possible implementation, the blockchain-driven revenue sharing data management method further includes: performing inter-level revenue sharing condition analysis based on the multi-level revenue sharing rules of each target e-commerce platform to obtain a progressive revenue sharing connection relationship; performing a progressive rule relationship analysis of revenue sharing user levels based on the category attribute tags to obtain a user level revenue sharing connection relationship; and obtaining the revenue sharing connection relationship based on the progressive revenue sharing connection relationship and the user level revenue sharing connection relationship.

[0055] In one possible implementation, the blockchain-driven revenue sharing data management method further includes: extracting abnormal feedback information based on historical data of the multi-level revenue sharing rules; and extracting features based on the abnormal feedback information according to the feedback participants and abnormal revenue sharing parameters to obtain the abnormal revenue sharing features, wherein the abnormal revenue sharing parameters include revenue sharing time nodes, revenue sharing rules, and revenue sharing user levels.

[0056] In one possible implementation, the blockchain-driven ledger data management method further includes: setting redundant storage blocks for the sub-chain based on abnormal nodes; and establishing activation rules for the redundant storage blocks and the abnormal nodes.

[0057] In one possible implementation, the blockchain-driven revenue sharing data management method further includes: obtaining the revenue sharing anomaly characteristics of the abnormal node; extracting the abnormal time, abnormal revenue sharing ratio, and abnormal revenue sharing user level based on the revenue sharing anomaly characteristics; performing error correction time compensation based on the abnormal time to obtain an activation time; performing revenue sharing parameter compensation based on the abnormal revenue sharing ratio and abnormal user level to obtain activation conditions; and using the activation time and the activation conditions as the activation rules.

[0058] The blockchain-driven revenue sharing management system provided in this embodiment of the invention can execute the blockchain-driven revenue sharing management method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0059] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0060] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A blockchain-driven revenue-sharing data management system, characterized in that, include: A multi-level revenue sharing rule construction module is used to parse the hierarchical relationship of revenue sharing rules and construct multi-level revenue sharing rules. An anomaly identification module is used to identify anomalies based on historical data of the multi-level revenue sharing rules and obtain revenue sharing anomaly characteristics. A multi-blockchain path segmentation module is used to segment multiple blockchain paths according to the multi-level accounting rules and construct multi-level block sub-chains. An activation rule configuration module is used to identify abnormal nodes within and between the block sub-chains based on the revenue sharing anomaly characteristics, and to configure activation rules within and between the relevant abnormal nodes in the block sub-chains based on the revenue sharing anomaly characteristics. The activation rules include activation time and activation conditions. The multi-level revenue sharing rule construction module includes: A multi-level revenue sharing rule acquisition unit, wherein the unit is used to obtain the multi-level revenue sharing rules of a target e-commerce platform based on the revenue sharing rules of multiple target e-commerce platforms; Standardized parameter conversion is performed based on the multi-level revenue sharing rules of the target e-commerce platform. The multi-level revenue sharing rules after standardized parameter conversion are aligned with parameters, and cross-platform hierarchical clustering is performed according to the hierarchical relationship of parameter alignment to obtain the multi-level revenue sharing rules. The multi-level revenue sharing rule acquisition unit includes: The revenue sharing rule parsing subunit is used to parse the revenue sharing rules of multiple target e-commerce platforms according to the revenue sharing user level, revenue sharing ratio, and revenue sharing time rules, and construct a revenue sharing rule parsing list for each target e-commerce platform. The rule classification subunit is used to classify the rules according to the revenue sharing rule parsing list, using the revenue sharing ratio as the first classification feature and the revenue sharing time rule as the second classification feature, to obtain the rule hierarchy classification. The multi-level revenue sharing rule acquisition sub-unit is used to add the corresponding rule level category as a classification attribute tag according to the correspondence between the revenue sharing user level and the revenue sharing ratio and the revenue sharing time rule, so as to obtain the multi-level revenue sharing rules of each target e-commerce platform.

2. The blockchain-driven revenue-sharing data management system according to claim 1, characterized in that, The multi-level revenue sharing rule acquisition unit also includes: A new revenue sharing rule acquisition sub-unit is added, which is used to obtain new revenue sharing rules, including revenue sharing rules for new e-commerce platforms and new revenue sharing rules for target e-commerce platforms. A mapping and matching subunit is used to perform mapping and matching between the newly added revenue sharing rule and the multi-level revenue sharing rule to obtain a matching and positioning relationship. A hierarchical projection subunit is used to project the newly added revenue sharing rules in a hierarchical manner according to the matching and positioning relationship, and update the multi-level revenue sharing rules of the target e-commerce platform.

3. The blockchain-driven revenue-sharing data management system according to claim 1, characterized in that, The multi-blockchain path splitting module includes: Link structure definition unit, which is used to define the structure of the blockchain path according to the accounting rules and transaction process; A multi-level blockchain road construction unit is used to establish a multi-level blockchain road, including multiple block sub-chains, based on the defined blockchain road structure and according to the multi-level ledger rules. The revenue sharing connection relationship parsing unit is used to parse the revenue sharing connection relationship of the multi-level revenue sharing rules of each target e-commerce platform, and establish a transaction connection of the blockchain sub-chain through a smart contract based on the revenue sharing connection relationship to obtain the multi-level blockchain sub-chain.

4. The blockchain-driven revenue-sharing data management system according to claim 3, characterized in that, The revenue sharing connection parsing unit includes: The revenue sharing progressive connection relationship acquisition sub-unit is used to perform inter-level revenue sharing condition analysis based on the multi-level revenue sharing rules of each target e-commerce platform to obtain the revenue sharing progressive connection relationship. The user level revenue sharing connection relationship acquisition sub-unit is used to perform rule progression relationship analysis of revenue sharing user levels based on the category attribute tags to obtain user level revenue sharing connection relationships. The revenue sharing connection relationship acquisition sub-unit is used to obtain the revenue sharing connection relationship based on the revenue sharing progressive connection relationship and the user level revenue sharing connection relationship.

5. The blockchain-driven revenue-sharing data management system according to claim 1, characterized in that, The anomaly detection module includes: An anomaly feedback information extraction unit is used to extract anomaly feedback information based on historical data of the multi-level revenue sharing rules. The revenue sharing anomaly feature acquisition unit is used to extract features based on the anomaly feedback information according to the feedback participants and anomaly revenue sharing parameters to obtain the revenue sharing anomaly features. The anomaly revenue sharing parameters include revenue sharing time nodes, revenue sharing rules, and revenue sharing user levels.

6. The blockchain-driven revenue-sharing data management system according to claim 5, characterized in that, The activation rule configuration module also includes: A redundant storage block setting unit is used to set redundant storage blocks for the block sub-chain according to abnormal nodes. An activation rule building unit is used to establish activation rules for the redundant storage blocks and the abnormal nodes.

7. The blockchain-driven revenue-sharing data management system according to claim 6, characterized in that, The activation rule configuration module includes: The abnormal revenue sharing node acquisition unit is used to obtain the abnormal revenue sharing characteristics of the abnormal node. An abnormal data extraction unit is used to extract abnormal time, abnormal revenue sharing ratio, and abnormal revenue sharing user level based on the abnormal revenue sharing characteristics. An error correction time compensation unit is used to perform error correction time compensation based on the abnormal time to obtain the activation time. The revenue sharing parameter compensation unit is used to compensate revenue sharing parameters based on the abnormal revenue sharing ratio and the abnormal revenue sharing user level to obtain activation conditions. An activation rule determination unit is used to determine the activation time and the activation conditions as the activation rules.

8. A blockchain-driven method for managing distributed ledger data, characterized in that, The method is applied to the blockchain-driven ledger data management system according to any one of claims 1-7, the method comprising: Analyze the hierarchical relationship of the revenue sharing rules and construct a multi-level revenue sharing rule system; Anomalies are identified based on historical data from the aforementioned multi-level revenue sharing rules to obtain anomaly characteristics. Based on the aforementioned multi-level revenue sharing rules, multiple blockchain paths are segmented to construct multi-level sub-chains. Based on the aforementioned revenue sharing anomaly characteristics, abnormal nodes within and between the block sub-chains are identified. Based on the aforementioned revenue sharing anomaly characteristics, activation rules are configured for the relevant abnormal nodes within and between the block sub-chains. The activation rules include activation time and activation conditions.

Images