Block chain-driven accounting data management system and method

Abstract

The invention discloses a blockchain-driven separate account data management system and method, and relates to the technical field of blockchains, and the method comprises the steps: achieving data transparency and safety through a hybrid architecture, and achieving multi-node data synchronization and tamper-proofing through a distributed account book technology. The intelligent contract automatically executes the account division rule, and the problems of low fund distribution efficiency, high second-definition risk and the like in e-commerce, supply chain and other scenes are solved. The performance of the system is improved through load balancing and caching technologies, and the data consistency is ensured in combination with a block chain consensus mechanism. And the dynamic account division and cross-border settlement capabilities are optimized. The technical problems that in a cross-e-commerce platform multi-level account division scene, an existing account division system cannot dynamically recognize rule conflicts and process abnormal transaction chains in real time, and is lack of a cross-chain collaborative error correction mechanism are solved, dynamic aggregation and abnormal self-healing of multi-platform account division rules are achieved, and the user experience is improved. The technical effects of improving the timeliness of account division and the recognition accuracy of abnormal transactions are achieved.

Description

Technical Field

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

[0002] In traditional e-commerce platforms, the heterogeneous and dynamic nature of multi-level account splitting rules leads to inefficient cross-platform collaboration. Existing systems typically rely on centralized databases for account splitting process management, making it difficult to handle account splitting operations across multiple parties and multiple rule levels in real time. This is particularly true when faced with differentiated account splitting strategies across different e-commerce platforms (such as user tiering, dynamic adjustment of account splitting ratios, and varying time trigger conditions). Rule alignment and parameter conversion suffer from a significant lack of standardization. Furthermore, account splitting anomaly detection, primarily based on statistical analysis of offline historical data, cannot effectively capture transient anomalies in dynamic transaction scenarios (such as offsets in account splitting time nodes and user tier mismatches). Furthermore, the recovery mechanism after identifying anomaly nodes lacks cross-chain coordination capabilities, resulting in account splitting interruptions or data inconsistencies requiring manual intervention and correction, severely limiting account splitting reliability in highly concurrent transaction environments. Current technologies struggle to simultaneously address the adaptive integration of multi-level rules, real-time anomaly detection, and cross-chain redundancy recovery, creating a core bottleneck hindering the transparency and automated management of capital flows in distributed e-commerce ecosystems.

[0003] At present, relevant technologies have the technical problem that the account splitting system cannot dynamically identify rule conflicts and handle abnormal transaction chains in real time in the multi-level account splitting scenario across e-commerce platforms, and lacks a cross-chain collaborative error correction mechanism. Summary of the Invention

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

[0005] This application provides a blockchain-driven ledger data management system, including: A multi-level account splitting rule construction module, which is used to parse the hierarchical relationship of account splitting rules and construct multi-level account splitting rules; an anomaly identification module, which is used to identify anomalies based on the historical data of the multi-level account splitting rules and obtain account splitting anomaly features; a multi-block chain segmentation module, which is used to segment multiple block chains according to the multi-level account splitting rules and construct multi-layer block subchains; an activation rule configuration module, which is used to identify abnormal nodes within and between block subchains based on the account splitting anomaly features, and configure block subchain and inter-chain activation rules for related abnormal nodes based on the account splitting anomaly features, and the activation rules include activation time and activation conditions.

[0006] This application provides a blockchain-driven ledger data management method, including: Analyze the hierarchical relationship of the ledger splitting rules and construct multi-level ledger splitting rules; identify anomalies based on the historical data of the multi-level ledger splitting rules to obtain ledger splitting anomaly features; perform multi-block chain segmentation according to the multi-level ledger splitting rules and construct multi-level block sub-chains; identify abnormal nodes within and between block sub-chains based on the ledger splitting anomaly features, and configure block sub-chain and inter-chain activation rules for the relevant abnormal nodes based on the ledger splitting anomaly features, wherein the activation rules include activation time and activation conditions.

[0007] The blockchain-driven account data management system and method proposed in this application will first achieve data transparency and security through a hybrid architecture, use encryption algorithms to protect privacy, and rely on distributed ledger technology to achieve multi-node data synchronization and tamper-proofing. Smart contracts automatically execute account rules to solve problems such as low capital allocation efficiency and high secondary clearing risks in e-commerce, supply chain and other scenarios. The system improves performance through load balancing and caching technology, and combines the blockchain consensus mechanism to ensure data consistency. Future technologies will integrate AI and open banking interfaces to further optimize dynamic account splitting and cross-border settlement capabilities, achieving the technical effect of improving account splitting timeliness and the accuracy of abnormal transaction identification by realizing dynamic aggregation and abnormal self-healing of multi-platform account splitting rules. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] Figure 1 A schematic diagram of the structure of a blockchain-driven ledger data management system provided in an embodiment of the present application; Figure 2 A flowchart of a blockchain-driven ledger data management method provided in an embodiment of the present application.

[0010] Explanation of reference numerals: multi-level account splitting rule construction module 10, anomaly identification module 20, multi-block chain segmentation module 30, activation rule configuration module 40. DETAILED DESCRIPTION

[0011] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below.

[0012] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0013] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict, and the terms “first\second” involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. The terms “including” and “having” and any variations are intended to cover non-exclusive inclusions. 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 that are clearly listed, but may include other steps or modules that are not clearly listed or that are 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 those skilled in the art to which this application belongs. The terms used herein are for the purpose of describing the embodiments of this application only.

[0014] The present application embodiment provides a blockchain-driven ledger data management system, such as Figure 1 As shown, the method includes: A multi-level account splitting rule construction module 10 is used to analyze the hierarchical relationship of account splitting rules and construct multi-level account splitting rules. Specifically, when constructing multi-level account splitting rules, a comprehensive collection of account splitting rules from different e-commerce platforms, including user levels, ratios, and time rules, is first performed using the account splitting rule parsing sub-unit to generate a parsed list. The rules are then classified using the account splitting ratio and time rules as features using the rule grading sub-unit. Classification attribute labels are formed by combining the correspondence between account splitting user levels, account splitting ratios, and time rules. These labels are then added to the rule hierarchy classification to obtain multi-level account splitting rules for each platform. After standardized parameter conversion, parameter alignment, and cross-platform clustering, a universal multi-level account splitting rule is constructed. The universal multi-level account splitting rule achieves traceability through the blockchain's chained data structure. Each account splitting transaction is recorded in a block, including a timestamp, hash value, and the hash of the previous block, forming an immutable chained ledger. When configuring different block sub-chains, the system verifies the legitimacy of the account splitting transactions based on a consensus mechanism (such as PoW or PoS). For example, Proof of Stake (PoS) assigns verification rights based on the amount of tokens held by users, preventing malicious nodes from manipulating ledger parameters. Transaction data is encrypted using cryptographic algorithms (such as the SHA-256 hash function) and digital signatures to ensure privacy and integrity. To address potential ledger anomalies, after the anomaly identification module identifies the anomaly, the activation rule configuration module uses the ledger abnormal node acquisition unit to identify the anomalous node, extract the abnormal data, and, after correcting errors and compensating for ledger parameters, determine the activation time and conditions, thereby forming the activation rules. The smart contract then automatically executes the error correction logic, such as triggering ledger ratio adjustments or time compensation rules, and broadcasts the corrected data to all nodes in the network to reach a new consensus. A redundant storage block is also established, with activation rules for it and the abnormal node. The redundant block synchronizes copies of the ledger data across distributed nodes, ensuring that a single point of failure does not affect global ledger consistency. Once the abnormal node has been verified, the data is recorded from the redundant storage block to the ledger blockchain according to the rules. Leveraging the blockchain's irreversible nature (modification requires more than 51% of the computing power), the final data uploaded to the blockchain is accurate and reliable.

[0015] In one possible implementation, the multi-level account splitting rule construction module 10 further includes a multi-level account splitting rule acquisition unit, configured to obtain the multi-level account splitting rules of a target e-commerce platform based on the account splitting rules of multiple target e-commerce platforms. Specifically, the multi-level account splitting rule acquisition unit first determines the scope of the target e-commerce platforms, collects their account splitting rule information through methods such as technical interface docking and data protocol interaction, and uses the account splitting rule parsing sub-unit to break down the rules, clarifying the account splitting user levels (e.g., ordinary consumers, different levels of members), account splitting ratios (involving the platform, merchants, and other parties), and account splitting time rules (real-time, daily, monthly, etc.), and constructs an account splitting rule parsing list. The rule grading sub-unit then divides the levels into levels based on the account splitting ratio and account splitting time rules. Finally, the multi-level account splitting rule acquisition sub-unit, based on the correspondence between the account splitting user levels, the account splitting ratios, and the time rules, adds the account splitting user levels as classification attribute labels to the corresponding rule hierarchical classification, thereby generating a multi-level account splitting rule for each target e-commerce platform, including different levels, corresponding to different account splitting user levels, and their corresponding account splitting ratios and time rules.

[0016] A standardized parameter conversion unit is used to perform standardized parameter conversion according to the multi-level account sharing rules of the target e-commerce platform. Specifically, the standardized parameter conversion unit first comprehensively sorts out the parameters such as the account sharing user level, account sharing ratio, and account sharing time rules in the multi-level account sharing rules of each target e-commerce platform, and uses algorithms and tools to identify parameter differences between different platforms, such as user level division and naming, account sharing ratio representation, and account sharing time recording format, and establishes a difference matrix. Then, based on these differences, a unified conversion rule is formulated, the account sharing user level classification system is unified, and the mapping relationship is determined; the account sharing ratio is unified into a percentage form, and a conversion algorithm is written; the account sharing time rules are unified into the "YYYY-MM-DD_HH:MM:SS" format, 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 value, process and results. The converted rules are checked for consistency to ensure that the logical relationship of the parameters is correct, thereby unifying the parameters with large differences into a standard format, laying the foundation for subsequent operations.

[0017] The parameter alignment unit is used to align the parameters of the multi-level account sharing rules after the standardized parameters are converted, and perform cross-platform hierarchical clustering according to the hierarchical relationship of the parameter alignment to obtain the multi-level account sharing rules. Specifically, the parameter alignment unit first determines the key alignment dimensions such as the account sharing user level, account sharing ratio, and account sharing time rules, and builds a framework based on these dimensions. The account sharing rule parameters after standardization of each platform are arranged according to the framework, and then the parameters of each dimension are compared horizontally, such as arranging the account sharing ratio of ordinary users on each platform in order to complete the parameter alignment. Then, the hierarchical relationship is analyzed based on the level of the account sharing user, the size of the account sharing ratio, the urgency of the account sharing time rules, etc., and a cross-platform hierarchical clustering strategy is formulated. For example, a hierarchical clustering algorithm is used to merge the rules according to the similarity of the rules, and the account sharing rules of similar levels and characteristics on different platforms are classified into one category. Finally, a multi-level account sharing rule with a clear hierarchical structure is generated that integrates the characteristics of the account sharing rules of multiple platforms, providing a standardized basis for subsequent account sharing data management.

[0018] In one possible implementation, the multi-level account splitting rule acquisition unit further includes: an account splitting rule parsing sub-unit, which is used to parse the account splitting rules of multiple target e-commerce platforms according to the account splitting user level, account splitting ratio, and account splitting time rules, and construct an account splitting rule parsing list for each target e-commerce platform. Specifically, the account splitting rule parsing sub-unit will first widely collect account splitting rule information of multiple target e-commerce platforms of different scales, business types and market positioning, obtain data through APIs or web crawlers, and adapt to different formats such as XML, JSON, CSV, etc., and combine database transaction locks and Redis queue technology to achieve stability and consistency of high-concurrency data collection. Subsequently, for the account splitting user level, different levels such as ordinary users and bronze members and corresponding rules will be identified; the account splitting ratio will be clarified, that is, the share of the platform, merchants, suppliers and other parties in different business scenarios, such as 15% for the platform, 70% for the merchant, and 15% for the supplier in the sale of a certain product (the ratio parameters need to be dynamically stored in the account splitting rule table, and support multi-dimensional adjustments based on orders, products, activities, etc.); determine the account splitting time rules, whether it is real-time, daily or fixed-date account splitting per month (supporting D0 real-time arrival and T+1 flexible settlement mode). Finally, through a detailed breakdown and analysis of these three key elements, a list of account splitting rule parsing for each platform is constructed in a structured form (the database design includes four core tables: transaction table, account splitting table, account table, and rule table, which record full-link information such as amount, timestamp, and account splitting path). Each row represents an account splitting rule scenario, and each column records information such as the account splitting user level, account splitting ratio, and account splitting time rules (fields must include extended parameters such as the account splitting party ID, hierarchical relationship, settlement cycle, and account splitting failure retry strategy), providing a clear and orderly data foundation for subsequent processing (data must be tamper-proofed through the MD5+RSA double signature mechanism and stored in a bank custody account supervised by the central bank to ensure compliance).

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

[0020] The multi-level account splitting rule acquisition sub-unit is used to add the corresponding relationship between the account splitting user level and the account splitting ratio and account splitting time rules as a classification attribute label to the corresponding rule hierarchy classification, so as to obtain the multi-level account splitting rules of each target e-commerce platform. Specifically, after the rule classification sub-unit completes the rule hierarchy classification, the multi-level account splitting rule acquisition sub-unit conducts an in-depth analysis of the account splitting rule parsing list, sorts out the corresponding relationship between the account splitting user level (such as ordinary, bronze, silver, gold members, etc.) and the account splitting ratio and account splitting time rules, and uses it as a classification attribute label. Then, based on the rule hierarchy classification system, these labels are accurately added to the corresponding level. For example, in the high-ratio-real-time account splitting sub-level, if there is a diamond member who enjoys a high-ratio real-time account splitting rule in the sale of high-end goods, it is marked as "Diamond Member". This process is followed for each target e-commerce platform, such as Platform A, Platform B, etc., and ultimately forms a multi-level account sharing rule that includes different levels, corresponding to specific account sharing user levels, their account sharing ratios, and account sharing time rules, providing a comprehensive and detailed rule basis for the e-commerce platform's subsequent account sharing, financial, and business decisions.

[0021] In one possible implementation, the multi-level account splitting rule acquisition unit further includes: a new account splitting rule acquisition sub-unit, the new account splitting rule acquisition sub-unit is used to obtain the new account splitting rules, the new account splitting rules include the account splitting rules of the new e-commerce platform and the new account splitting rules of the target e-commerce platform. Specifically, when the new account splitting rule acquisition sub-unit obtains the account splitting rules of the new e-commerce platform, on the one hand, it communicates with the platform operation or technical liaison person to obtain a rule document that records in detail the account splitting ratios, time nodes and special conditions with each partner in different business scenarios, such as the account splitting rules of a cross-border e-commerce platform for the sale of imported goods; on the other hand, by simulating the transaction process and using technical means such as network packet capture to analyze the flow of funds, the details of the account splitting operation are fully understood. For the new account splitting rules of the target e-commerce platform, the sub-unit pays attention to the announcements and policy updates released by channels such as the platform's official website and the merchant backend, such as the new account splitting rules formulated by a comprehensive e-commerce platform to encourage live streaming; on the other hand, it establishes a monitoring interface with the platform's internal system to capture in real time the changes in account splitting rules caused by business module upgrades or adjustments, such as the optimization of the platform's group buying business account splitting rules.

[0022] The mapping and matching subunit is configured to map and match the newly added account splitting rules with the multi-level account splitting rules to obtain a matching positioning relationship. Specifically, the mapping and matching subunit first extracts elements from both the newly added account splitting rules and the multi-level account splitting rules. For newly added rules, whether they are newly added to an e-commerce platform, such as account splitting rules for VIP users purchasing specific brand products, or account splitting rule adjustments for new promotional activities on the target e-commerce platform, detailed elements such as account splitting user level, account splitting ratio, account splitting time, and special business scenarios are extracted. For multi-level account splitting rules, a dataset is organized based on account splitting user level, account splitting ratio range, account splitting time type, and business scenario category. Next, mapping and matching is performed, with a preliminary match performed based on account splitting ratio and account splitting time rules to select candidate rules. A comprehensive match is then performed, taking into account factors such as account splitting user level and business scenario, to identify rules with a high degree of matching. Finally, the matching positioning relationship is determined, clarifying the level at which the newly added rule should be positioned, recording the differences with other rules within that level, and determining its association with other related rules.

[0023] The hierarchical projection subunit is used to hierarchically project the newly added account sharing rules according to the matching positioning relationship, and update the multi-level account sharing rules of the target e-commerce platform. Specifically, after receiving the matching positioning relationship provided by the mapping matching subunit, the hierarchical projection subunit deeply interprets the corresponding levels and associations between the newly added account sharing rules and the existing multi-level account sharing rule system, such as analyzing the differences in the account sharing ratio, account sharing time and other factors of the newly added rules in the "Premium Member-Limited Time Discount Promotion" level and the association with other rules. Based on the interpretation results, the projection level and position are accurately determined, and the comprehensive account sharing ratio, account sharing time and other factors are reasonably sorted within the level. Subsequently, the hierarchical projection operation is performed to completely insert the newly added rules into the target level position to ensure compatibility with other rules, clarify new business scenarios or special conditions, and update the association relationship records. Finally, the multi-level account sharing rule records are comprehensively updated, and metadata such as the detailed content, insertion time, source, and association relationship of the newly added rules are recorded in the database. The rule version number is updated to ensure that the account sharing business can accurately apply the latest rules.

[0024] Anomaly Identification Module 20 is used to identify anomalies based on historical data from the multi-level account splitting rules and obtain anomaly characteristics. Specifically, Anomaly Identification Module 20 first collects historical data from various e-commerce platforms' multi-level account splitting rules and stores them categorized by account splitting user level, business scenario, and account splitting time period. Based on the characteristics of the account splitting rules and the patterns in historical data, the account splitting rules are divided into different tiers based on account splitting ratio and time period, such as a high-level tier for high-ratio real-time account splitting and a low-level tier for low-ratio monthly account splitting. Different blockchain subchains are then assigned to different tiers, such as high-performance sidechains for high-level tiers and conventional sidechains for low-level tiers. Possible anomalies in the account splitting process are then analyzed, such as incorrect amounts, time delays, and incorrect subject information. An algorithm is then used to scan historical data to identify anomalies. To mitigate issues arising from the blockchain's immutability, activation rules are designed for nodes where anomalies are likely to occur. Upon detecting anomaly risk nodes, a verification process is initiated to recheck rule execution and data transmission. Only after verification is the account splitting data recorded in the account splitting blockchain, ensuring the normal operation of the account splitting business.

[0025] In a 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 the historical data of the multi-level account splitting rules. Specifically, the anomaly feedback information extraction unit widely collects the historical data of the multi-level account splitting rules from multiple channels such as the e-commerce platform transaction database, log files and business documents, and adapts to different formats such as MySQL, text, PDF, etc. By clarifying the parameter range and logical relationship of the normal account splitting rules, such as stipulating that ordinary transactions are split within 24 hours, setting the account splitting ratio interval and execution process standards, combining statistical analysis to establish a normal account splitting data model, and formulate abnormal data screening standards. Then, according to this standard, the historical data is traversed line by line, the account splitting time, ratio and rule execution process are checked, abnormal records are marked, and finally the key information of the abnormal records is integrated and output to a special data structure to provide a basis for subsequent analysis of abnormal characteristics of account splitting.

[0026] The account-split anomaly feature acquisition unit is configured to extract features based on the abnormal feedback information according to the feedback participants and abnormal account-split parameters to obtain the account-split anomaly features. The abnormal account-split parameters include the account-split time node, account-split rules, and account-split user level. Specifically, the account-split anomaly feature acquisition unit first sorts out the feedback participants in the abnormal feedback information and extracts features from aspects such as the e-commerce platform's technical architecture, the merchant's business scale and type, and supplier partnerships. For example, small merchants are prone to errors due to technical integration, and problems may occur after platform system updates. Next, the account-split time node is analyzed to calculate the abnormal concentration period, degree of deviation, and correlation with business activities. For example, promotional activities can affect account-split time. The actual account-split rules are then compared with the preset differences to evaluate the adaptability of the rules under the new business model. The correlation between different account-split user levels and anomalies and the impact of user behavior are then studied. For example, VIP users have more abnormalities due to complex rights and transaction behaviors. Finally, these features extracted based on different aspects are integrated to construct a multidimensional feature vector, which is output to a storage system such as a database table for subsequent analysis.

[0027] The multi-blockchain segmentation module 30 is used to segment multiple blockchains based on the multi-level ledger splitting rules, constructing multi-layered blockchain sub-chains. Specifically, the module first comprehensively organizes the ledger splitting rules for various business scenarios on different e-commerce platforms. Based on factors such as ledger splitting ratios, timing, and importance, the module categorizes the ledger splitting rules into high-level (e.g., real-time, high-ratio ledger splitting for high-end luxury goods) and low-level (e.g., low-ratio, monthly ledger splitting for small businesses) rules based on complexity and timeliness requirements, forming a universal hierarchical system. A segmentation strategy is then formulated based on this, with a high-performance consortium chain allocated to the high-level tier and public chain sidechain technology used for the low-level tier. Appropriate multi-layered blockchain sub-chains are then constructed for each tier, with different block structures and consensus mechanisms designed. Furthermore, the module conducts in-depth analysis of potential anomalies in ledger splitting, such as incorrect amounts, time delays, and incorrect subject information. Activation rules are then set for potentially anomaly-prone blockchain nodes. Upon detecting anomaly-risk nodes, a verification process is initiated, and ledger data is recorded only after verification is confirmed. This ensures the normal operation of ledger splitting services while leveraging the blockchain's immutable nature.

[0028] In one possible implementation, the multi-blockchain segmentation module 30 further includes a link structure definition unit, which is used to define the blockchain structure based on the account splitting rules and transaction process. Specifically, the link structure definition unit first collects account splitting rules from various e-commerce platforms, covering account splitting ratios, timeframes, entities, and triggering conditions. For example, account splitting rules for daily sales and promotional activities vary, as do progressive account splitting rules. The unit also analyzes the transaction process, from user order placement to after-sales service. Next, based on the account splitting rules, the module analyzes hierarchical relationships, categorizing them by ratio and business importance. It then organizes transaction links at different levels of progressive rules, clarifying triggering conditions and data flows. Finally, the blockchain structure is defined, with nodes set up to record information at key transaction stages. An encrypted transmission protocol is used to ensure data security, and storage methods and capacity are selected based on data characteristics. Through smart contracts and other design methods, hierarchical associations are implemented to achieve automatic level switching and data transfer, laying the foundation for the construction of a multi-level blockchain.

[0029] A multi-level blockchain construction unit is configured to establish a multi-level blockchain, including multiple sub-chains, based on the defined blockchain structure and in accordance with the multi-level ledger splitting rules. Specifically, the multi-level blockchain construction unit first thoroughly studies the blockchain structure defined by the link structure definition unit, including node configuration, data transmission and storage, and analyzes the multi-level ledger splitting rules to clarify the basis for the hierarchical division and triggering conditions. It then divides the ledger business into different tiers based on the rules, such as a high-level tier for core business and a low-level tier for ordinary small transactions. Each stage of the progressive rules constitutes a tier, and a corresponding sub-chain is created at each tier. Appropriate node equipment and consensus algorithms are selected based on the characteristics of each tier. Finally, transaction links between different tiers are constructed based on the progressive ledger splitting rules. The data transfer format and content are precisely designed. A hierarchical association mechanism is established through smart contracts to achieve automatic tier switching and data transfer, and the relevant processes are recorded. This successfully establishes a multi-level blockchain containing multiple sub-chains, providing an effective solution for e-commerce ledger splitting services.

[0030] The ledger connection relationship parsing unit is used to parse the ledger connection relationships within the multi-level ledger splitting rules of each target e-commerce platform. Based on these ledger connection relationships, the unit establishes a transaction connection between the blockchain subchains via a smart contract, thereby obtaining the multi-layered blockchain subchain. Specifically, the unit first collects multi-level ledger splitting rule data from multiple channels on the e-commerce platform and organizes it by type and level. It then conducts an in-depth analysis of the rule logic, sorts out the hierarchical relationships, and identifies transaction links. For example, it identifies the logic for triggering changes in ledger splitting ratios and level transitions in progressive ledger splitting rules based on order quantity. Based on the parsed results, the smart contract logic is then developed, data interaction methods are designed, and the code is implemented in a suitable language and thoroughly tested. The smart contract is then deployed to the blockchain network, parameters and permissions are configured, and transaction connections between the blockchain subchains are established via the contract, completing data transfer between the levels. Finally, the blockchain consensus mechanism is used to verify the validity of the connection, ensuring that the ledger splitting results are formally recorded. This results in a multi-layered blockchain subchain, enabling efficient execution and management of multi-level ledger splitting rules on the blockchain.

[0031] In one possible implementation, the account connection relationship parsing unit further includes: an account progressive connection relationship acquisition subunit, and the account progressive connection relationship acquisition subunit is used to analyze the inter-level account conditions according to the multi-level account rules of each target e-commerce platform to obtain the account progressive connection relationship. Specifically, the account progressive connection relationship acquisition subunit first clearly obtains the multi-level account rule data from the official documents, database records and business process documents of the e-commerce platform, and collects it through cooperation with the technical team and communication with business personnel. Then the data is cleaned, classified and standardized. Then the logic of the account rules at each level is thoroughly sorted out, the trigger conditions for the hierarchical conversion are identified, and the correlation with other business factors is analyzed. Then, based on the analysis results, an account progressive connection relationship model is constructed. After simulation verification and optimization, the results are output in the form of a report and stored in the database, so as to accurately obtain the account progressive connection relationship.

[0032] The user-level account split connection relationship acquisition subunit is used to perform rule-based progressive relationship analysis of the account split user level based on the classification attribute labels to obtain the user-level account split connection relationship. Specifically, the user-level account split connection relationship acquisition subunit first clarifies the scope of classification attribute labels such as consumption amount and consumption frequency, collects relevant data from multiple data sources of the e-commerce platform, and cleans and pre-processes it. Then, the e-commerce platform's account split rules for different user levels are collected and sorted, sorted by level, and special cases are analyzed. Afterwards, the user level upgrade conditions and account split rule changes are analyzed to establish a rule-based progressive relationship model. The model is then verified, optimized based on the results, and unreasonable upgrade conditions and account split rules are adjusted. Finally, a reliable user-level account split connection relationship is determined and saved, and a monitoring mechanism is established to adjust according to business development.

[0033] The sub-unit for acquiring the split-account connection relationship is used to obtain the split-account connection relationship based on the split-account progressive connection relationship and the user-level split-account connection relationship. Specifically, the sub-unit for acquiring the split-account connection relationship first receives the corresponding data from the split-account progressive connection relationship acquisition sub-unit and the user-level split-account connection relationship acquisition sub-unit, and strictly checks its completeness, accuracy and consistency. Then, the data of the two relationships are merged and the association between them is analyzed. After that, the rules are integrated and the split-account connection relationship model is constructed. The relationship between each element is displayed using tools such as flowcharts or decision trees. The model is then verified with historical data, and the rule parameters and modeling methods are optimized based on the results. Finally, the final split-account connection relationship is determined, the results are output in the form of a document report and stored in the database, providing a docking basis for the e-commerce platform split-account system.

[0034] Activation rule configuration module 40 is used to identify abnormal nodes within and between blockchain subchains based on the anomaly characteristics of the ledger splitting. It then configures activation rules within and between blockchain subchains for the abnormal nodes based on the anomaly characteristics. These activation rules include activation time and activation conditions. Specifically, the redundant storage block configuration unit of activation rule configuration module 40 first collects the ledger splitting rules of different e-commerce platforms, categorizes them into levels based on factors such as complexity and importance, and configures corresponding blockchain subchains for each level. It then analyzes potential anomalies in the ledger splitting, such as amount calculation errors and time delays, to identify potentially abnormal blockchain nodes. Based on the abnormal nodes, it then determines the basis for configuring redundant storage blocks, creates redundant storage blocks in the corresponding blockchain subchains, and establishes a data synchronization mechanism. Finally, it sets activation rules for abnormal risk nodes, clearly defining activation conditions and processing procedures, implements the rules, and monitors them in real time. Once the nodes are confirmed to be problem-free, the data is recorded in the ledger blockchain. The processing results are also fed back for reference in business decision-making, thereby ensuring blockchain data security and the normal operation of the ledger splitting business.

[0035] In one possible implementation, the activation rule configuration module 40 further includes a redundant storage block configuration unit, configured to configure redundant storage blocks for the blockchain subchain based on abnormal nodes. Specifically, the redundant storage block configuration unit first establishes a monitoring system to collect blockchain node operation data, uses a preset algorithm to analyze and accurately locate abnormal nodes, and records detailed information. It then evaluates the functionality and structure of the blockchain subchain containing the abnormal node and predicts risk. It then selects appropriate nodes to create redundant storage blocks, initializes them according to the subchain format, copies key data, and verifies them. Activation conditions are then determined based on the anomaly type and risk assessment, and activation rules are formulated and monitored in real time. Activation is automatically triggered when conditions are met. Finally, data is rigorously verified before import, imported according to rules, and the subchain status is updated. After import, subchain operation is closely monitored, and the processing process is summarized and analyzed for subsequent reference to ensure the stable operation of the distributed ledger blockchain.

[0036] An activation rule construction unit is used to establish activation rules for the redundant storage blocks and abnormal nodes. Specifically, the activation rule construction unit first collects information such as the abnormal node's historical operation, hardware configuration, and network environment, as well as information such as the redundant storage block's storage capacity, synchronization mechanism, and location distribution. It then determines activation conditions based on the abnormal node's status, data integrity, and network conditions, such as error rate, response time, data loss rate, and network latency, triggering the activation when certain thresholds are reached. An activation process is then designed, including data verification, import, and status update processes, to ensure accurate data import and update of the blockchain status. 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 distributed ledger blockchain system and integrated with smart contracts. A monitoring mechanism is established to monitor rule execution in real time, record information, and handle exceptions, ensuring timely recovery in the event of system anomalies.

[0037] In one possible implementation, the activation rule configuration module 40 further includes: an abnormal account node acquisition unit, which is used to obtain the abnormal account characteristics of the abnormal node. Specifically, the abnormal account node acquisition unit first collects data from multiple data sources such as blockchain transaction records, node log files, and account system databases, and completes the collection through corresponding interfaces, tools, and query statements. Then, it defines abnormal characteristics such as account ratio, account time, and transaction data, and sets judgment rules, such as setting an error range for the account ratio, determining the normal range of account time based on historical data, etc. After the collected data is cleaned, converted, and normalized, the rules are used to identify abnormal characteristics, and then the causes and effects of the abnormalities are deeply analyzed, such as determining whether it is caused by rule configuration, network, input errors, or attacks. Finally, the identification results and analysis are organized into a report and output to the business and technical teams to provide a basis for decision-making. At the same time, the abnormal information is stored for subsequent analysis and prediction, so as to effectively obtain the abnormal account characteristics of the abnormal node.

[0038] The abnormal data extraction unit is used to extract the abnormal time, abnormal account splitting ratio, and abnormal account splitting user level based on the abnormal account splitting characteristics. Specifically, the abnormal data extraction unit first connects with the account splitting abnormal node acquisition unit, receives and confirms the account splitting abnormal feature information, stores it in the database and builds an index. Then, according to the account splitting business process and rules, the abnormal time, abnormal account splitting ratio and abnormal account splitting user level are extracted respectively. When extracting abnormal time, rules are formulated to filter and verify time data; when extracting abnormal account splitting ratio, the standard range needs to be determined, and the abnormal ratio needs to be matched and analyzed; when extracting abnormal account splitting user level, the rules need to be sorted out, and the level information needs to be compared and verified. Finally, the extracted data is organized into a specific format and output to the relevant departments, and the data is backed up for audit tracing, providing key data support for abnormal handling of account splitting business.

[0039] The error correction time compensation unit is used to compensate for the error correction time according to the abnormal time and obtain the activation time. Specifically, the error correction time compensation unit first connects with the abnormal data extraction unit to receive and check the integrity of the abnormal time data. Then, the impact of the abnormal time is evaluated in combination with the account splitting business process, and the related factors are analyzed. Then, based on the impact analysis, the compensation principle is determined, and the appropriate compensation method (such as time extension, priority processing, additional rewards, etc.) is selected and the compensation time is calculated. After that, based on the end time of the abnormal event, the compensation time is added to obtain the activation time, and its rationality is checked. If it is unreasonable, it is readjusted. Finally, the activation time is output to the relevant business departments and technical systems, and the activation time and related abnormal time, compensation strategy, calculation process and other information are recorded in detail for subsequent audit analysis to ensure the normal recovery and stable operation of the account splitting business.

[0040] The account splitting parameter compensation unit is used to compensate the account splitting parameters according to the abnormal account splitting ratio and the abnormal account splitting user level, and obtain activation conditions. Specifically, the account splitting parameter compensation unit first connects with the abnormal data extraction unit, receives and reviews the abnormal account splitting ratio and abnormal account splitting user level information, and ensures that the data is accurate and complete. Then, the abnormal impact is analyzed in combination with the account splitting business process, and the losses of all parties are evaluated. Based on the evaluation results, the fair, reasonable and transparent compensation principles are determined, and specific compensation methods are formulated for abnormal account splitting ratios and user levels, such as recovering and redistributing amounts for abnormal ratios, restoring levels for abnormal levels and adjusting account split amounts. Then, the activation conditions are determined according to the compensation strategy, including completion of data correction, loss compensation in place, and restoration of normal business processes. Finally, the activation conditions are verified to ensure that they are reasonable and feasible, and the verified activation conditions are output to relevant business and technical systems, and recorded and backed up to provide support for the recovery and stable operation of the account splitting business.

[0041] An activation rule determination unit is used to use the activation time and the activation conditions as the activation rules. Specifically, the activation rule determination unit first connects with the error correction time compensation unit and the account sub-parameter compensation unit to receive and review the activation time and activation conditions to ensure that the data is accurate and reliable. Then, the activation rule framework is constructed with the two as the core, and the rule content is refined and improved. After that, the association between abnormal nodes and redundant storage blocks is identified, and the rules are embedded into their interaction mechanism and tested. According to the business characteristics, the confirmation period and connection rules for the activation rules to join the blockchain are formulated, the activation conditions and confirmation period are monitored in real time, and the joining operation is triggered and data verification is performed when the conditions are met. Finally, the rule formulation and execution process are recorded and audited in detail, and the rules are evaluated and optimized regularly to adapt to business and technical changes, providing guarantees for abnormal handling and recovery of account sub-account business.

[0042] The embodiment of the present application uses a hybrid architecture to achieve data transparency and security, adopts encryption algorithms to protect privacy, and relies on distributed ledger technology to achieve multi-node data synchronization and tamper-proofing. Smart contracts automatically execute account splitting rules to solve problems such as low capital allocation efficiency and high risk of secondary clearing in e-commerce, supply chain and other scenarios. The system improves performance through load balancing and caching technology, and combines the blockchain consensus mechanism to ensure data consistency. Further optimizing dynamic account splitting and cross-border settlement capabilities, it achieves the technical effect of improving the timeliness of account splitting and the accuracy of abnormal transaction identification by realizing dynamic aggregation and abnormal self-healing of multi-platform account splitting rules.

[0043] In the above, refer to Figure 1 The blockchain-driven ledger data management system according to an embodiment of the present invention is described in detail. Figure 2 The present invention describes a blockchain-driven ledger data management method according to an embodiment of the present invention.

[0044] Blockchain-driven ledger data management methods, such as Figure 2 As shown, the method includes: Analyze the hierarchical relationship of the ledger splitting rules and construct multi-level ledger splitting rules; identify anomalies based on the historical data of the multi-level ledger splitting rules to obtain ledger splitting anomaly features; perform multi-block chain segmentation according to the multi-level ledger splitting rules and construct multi-level block sub-chains; identify abnormal nodes within and between block sub-chains based on the ledger splitting anomaly features, and configure block sub-chain and inter-chain activation rules for the relevant abnormal nodes based on the ledger splitting anomaly features, wherein the activation rules include activation time and activation conditions.

[0045] In one possible implementation, the blockchain-driven account splitting data management method further includes: obtaining a multi-level account splitting rule of a target e-commerce platform based on the account splitting rules of multiple target e-commerce platforms; performing standardized parameter conversion according to the multi-level account splitting rule of the target e-commerce platform; performing parameter alignment on the multi-level account splitting rule after the standardized parameter conversion, and performing cross-platform hierarchical clustering according to the hierarchical relationship of the parameter alignment to obtain the multi-level account splitting rule.

[0046] In one possible implementation, the blockchain-driven account splitting data management method further includes: parsing the account splitting rules of multiple target e-commerce platforms according to the account splitting user level, account splitting ratio, and account splitting time rules, and constructing an account splitting rule parsing list for each target e-commerce platform; according to the account splitting rule parsing list, classifying the rules with the account splitting ratio as the first classification feature and the account splitting time rule as the second classification feature to obtain a rule hierarchical classification; according to the correspondence between the account splitting user level and the account splitting ratio and account splitting time rule, adding them as classification attribute labels to the corresponding rule hierarchical classification to obtain multi-level account splitting rules for each target e-commerce platform.

[0047] In one possible implementation, the blockchain-driven account splitting data management method further includes: obtaining newly added account splitting rules, the newly added account splitting rules including the account splitting rules of the newly added e-commerce platform and the newly added account splitting rules of the target e-commerce platform; using the newly added account splitting rules to map and match with the multi-level account splitting rules to obtain a matching positioning relationship; hierarchically projecting the newly added account splitting rules according to the matching positioning relationship, and updating the multi-level account splitting rules of the target e-commerce platform.

[0048] In one possible implementation, the blockchain-driven account data management method further includes: defining a blockchain structure based on account splitting rules and transaction processes; establishing a multi-level blockchain structure based on the defined blockchain structure and in accordance with the multi-level account splitting rules, including multiple block sub-chains; parsing the account connection relationship of the multi-level account splitting rules of each target e-commerce platform, and establishing a transaction connection of the block sub-chain through a smart contract based on the account splitting connection relationship to obtain the multi-level block sub-chain.

[0049] In one possible implementation, the blockchain-driven account splitting data management method further includes: analyzing the account splitting conditions between levels according to the multi-level account splitting rules of each target e-commerce platform to obtain a progressive account splitting connection relationship; analyzing the rule progressive relationship of the account splitting user level according to the classification attribute label to obtain a user level account splitting connection relationship; and obtaining the account splitting connection relationship based on the account splitting progressive connection relationship and the user level account splitting connection relationship.

[0050] In one possible implementation, the blockchain-driven account splitting data management method further includes: extracting abnormal feedback information based on historical data of the multi-level account splitting rules; performing feature extraction according to the abnormal feedback information and the feedback participants and abnormal account splitting parameters to obtain the abnormal account splitting features, wherein the abnormal account splitting parameters include the account splitting time node, account splitting rules, and account splitting user level.

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

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

[0053] The blockchain-driven sub-account data management system provided in the embodiment of the present invention can execute the blockchain-driven sub-account data management method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0054] Although the present application makes various references to certain modules in the system according to the embodiments of the present application, any number of different modules may be used and run on the user terminal and / or server, and 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 the functional units are only for the convenience of distinguishing each other and are not used to limit the scope of protection of the present invention.

[0055] The above specific embodiments 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 may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. Blockchain-driven ledger data management system, characterized by: include: A multi-level account splitting rule construction module, which is used to analyze the hierarchical relationship of account splitting rules and construct multi-level account splitting rules; An anomaly identification module, which is used to identify anomalies based on the historical data of the multi-level account splitting rules and obtain account splitting anomaly features; A multi-blockchain road segmentation module, which is used to segment multiple blockchain roads according to the multi-level account splitting rules to construct multi-layer block sub-chains; An activation rule configuration module is used to identify abnormal nodes within and between sub-chains based on the abnormal ledger-splitting characteristics, and configure activation rules within and between sub-chains for the relevant abnormal nodes based on the abnormal ledger-splitting characteristics. The activation rules include activation time and activation conditions.

2. The blockchain-driven account data management system according to claim 1, characterized in that: The multi-level account splitting rule construction module includes: A multi-level account splitting rule acquisition unit, configured to acquire the multi-level account splitting rule of a target e-commerce platform based on the account splitting rules of multiple target e-commerce platforms; Perform standardized parameter conversion according to the multi-level account splitting rules of the target e-commerce platform; The multi-level account splitting rules after the standardized parameters are converted are parameter-aligned, and cross-platform hierarchical clustering is performed according to the hierarchical relationship of the parameter alignment to obtain the multi-level account splitting rules.

3. The blockchain-driven account data management system according to claim 2, characterized in that: The multi-level account splitting rule acquisition unit includes: An account splitting rule parsing subunit, which is used to parse the account splitting rules of multiple target e-commerce platforms according to account splitting user levels, account splitting ratios, and account splitting time rules, and to construct an account splitting rule parsing list for each target e-commerce platform; A rule classification subunit is configured to parse the account splitting rule list, classify the rules using the account splitting ratio as a first classification feature and the account splitting time rule as a second classification feature, and obtain a rule hierarchical classification; A multi-level account splitting rule acquisition sub-unit is used to add the corresponding relationship between the account splitting user level and the account splitting ratio and account splitting time rules as a classification attribute label to the corresponding rule hierarchy classification to obtain the multi-level account splitting rules of each target e-commerce platform.

4. The blockchain-driven account data management system according to claim 2, characterized in that: The multi-level account splitting rule acquisition unit further includes: A new account splitting rule acquisition subunit is used to obtain new account splitting rules, including account splitting rules for the new e-commerce platform and new account splitting rules for the target e-commerce platform; A mapping and matching subunit, configured to perform mapping and matching using the newly added account splitting rule and the multi-level account splitting rule to obtain a matching positioning relationship; A hierarchical projection subunit is used to hierarchically project the newly added account sharing rules according to the matching positioning relationship, and update the multi-level account sharing rules of the target e-commerce platform.

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

6. The blockchain-driven account data management system according to claim 5, characterized in that: The account connection relationship parsing unit includes: An account-split progressive connection relationship acquisition subunit, which is used to analyze inter-level account split conditions based on the multi-level account split rules of each target e-commerce platform to obtain an account-split progressive connection relationship; A user-level split-account connection relationship acquisition subunit, configured to perform a rule-based progressive relationship analysis of split-account user levels based on the classification attribute tags to obtain a user-level split-account connection relationship; The sub-account connection relationship acquisition sub-unit is used to obtain the sub-account connection relationship according to the sub-account progressive connection relationship and the user-level sub-account connection relationship.

7. The blockchain-driven ledger data management system according to claim 1, characterized in that: The abnormality identification module includes: an abnormal feedback information extraction unit, configured to extract abnormal feedback information based on historical data of the multi-level account splitting rule; An abnormal account splitting feature acquisition unit is used to extract features according to the abnormal feedback information, the feedback participants, and abnormal account splitting parameters to obtain the abnormal account splitting features. The abnormal account splitting parameters include the account splitting time node, the account splitting rules, and the account splitting user level.

8. The blockchain-driven ledger data management system according to claim 7, characterized in that: The activation rule configuration module also includes: A redundant storage block setting unit, configured to set redundant storage blocks of a block subchain according to abnormal nodes; An activation rule construction unit is configured to establish activation rules for the redundant storage block and the abnormal node.

9. The blockchain-driven ledger data management system according to claim 8, characterized in that: The activation rule configuration module includes: An abnormal account splitting node acquisition unit is used to obtain the abnormal account splitting feature of the abnormal node; An abnormal data extraction unit, configured to extract the abnormal time, abnormal account splitting ratio, and abnormal account splitting user level based on the abnormal account splitting characteristics; an error correction time compensation unit, configured to perform error correction time compensation according to the abnormal time to obtain an activation time; An account splitting parameter compensation unit, configured to compensate the account splitting parameters according to the abnormal account splitting ratio and the abnormal account splitting user level to obtain activation conditions; An activation rule determination unit is configured to use the activation time and the activation condition as the activation rule.

10. A blockchain-driven ledger data management method, characterized in that: The method is applied to the blockchain-driven ledger data management system according to any one of claims 1 to 9, and the method includes: Analyze the hierarchical relationship of account splitting rules and build multi-level account splitting rules; Anomaly identification is performed based on the historical data of the multi-level account splitting rules to obtain account splitting anomaly features; Perform multi-blockchain segmentation according to the multi-level ledger rules to build multi-layered block sub-chains; Based on the abnormal characteristics of the ledger splitting, abnormal nodes within and between sub-chains of the block chain are identified, and based on the abnormal characteristics of the ledger splitting, activation rules within and between sub-chains of the block chain of the relevant abnormal nodes are configured. The activation rules include activation time and activation conditions.

Images