Double-layer coupling blockchain processing system and method based on complex network dynamics

Abstract

The application relates to the technical field of blockchains, and discloses a double-layer coupled blockchain processing system and method based on complex network dynamics. Through a double-layer coupled architecture of a global state layer and a control cluster layer, in combination with real-time evaluation of a network dynamics stability model, the module configuration and node fault tolerance design of the control cluster are perfected, the transaction processing flow and the global vector clock management mode are optimized, stable system operation and efficient transaction processing are realized, and thus the throughput of the system is improved, transaction processing delay is reduced, and the fault tolerance and reliability of the system are enhanced.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a two-layer coupled blockchain processing system and method based on complex network dynamics. Background Technology

[0002] With the rapid development of blockchain technology, its application scenarios have expanded to multiple fields, leading to higher demands for core performance indicators such as transaction throughput, processing latency, and system stability. Traditional blockchain systems adopt a single-chain structure, where all transactions are processed serially on the main chain. This inherently results in low throughput and high latency, making it difficult to meet the concurrent demands of large-scale commercial applications.

[0003] To address the aforementioned shortcomings, existing technologies have proposed off-chain parallel processing solutions, such as the Layer 2 scheme. This involves transferring some transactions to an off-chain node cluster for parallel processing, only uploading key transaction data or processing results for on-chain confirmation. While this scheme can improve transaction throughput and reduce latency to some extent, it suffers from drawbacks such as untimely synchronization between the off-chain cluster and the main chain, difficulty in verifying the validity of off-chain processing results, and a lack of effective constraints on system stability. Specifically, existing off-chain parallel processing schemes lack unified standards for node management and lease lifecycle control within the off-chain cluster. When the main node within the cluster fails, network latency is abnormal, or node behavior deviates from the consensus protocol, the fault recovery mechanism cannot be triggered in a timely manner, leading to transaction processing stagnation. Furthermore, existing solutions do not introduce effective stability assessment models, making it impossible to quantify the stability of the system's operating state in real time, hindering the prediction and intervention of anomalies, and further reducing system reliability.

[0004] Furthermore, the typical Optimistic Rollup solution in the existing Layer 2 schemes relies on a 7-day challenge period to verify the validity of off-chain processing results, which cannot achieve real-time detection and processing of anomalies, resulting in high transaction confirmation delays and lagging fault recovery. At the same time, this type of solution lacks an event-based real-time error feedback mechanism, and cannot quickly trigger a switchover when the master node fails, which can easily lead to transaction processing stagnation and make it difficult to meet the real-time requirements of large-scale high-concurrency scenarios. Summary of the Invention

[0005] This application provides a two-layer coupled blockchain processing system, method, and storage medium based on complex network dynamics. Through a two-layer coupled architecture of a global state layer and a control cluster layer, combined with real-time evaluation of the network dynamics stability model, the module configuration and node fault tolerance design of the control cluster are improved, and the transaction processing flow and global vector clock management method are optimized to achieve stable system operation and efficient transaction processing. As a result, the system throughput is improved, the transaction processing latency is reduced, and the fault tolerance and reliability of the system are enhanced.

[0006] In a first aspect, embodiments of this application provide a two-layer coupled blockchain processing system based on complex network dynamics, comprising: The global state layer is configured with an atomic broadcast module, a global vector clock management module, and a system stability lease management module. The control cluster layer contains multiple distributed control clusters, each control cluster including a master node and multiple slave nodes. Each control cluster is configured with a local vector clock, and the control cluster layer is configured with an error signal generation module. The atomic broadcast module is used to generate and broadcast globally consistent sequence numbers; the global vector clock management module is used to allocate initial vector clock values ​​to each control cluster and dynamically synchronize cross-domain timing based on the atomic broadcast results. The system stability lease management module is used to manage the lease life of each control cluster. Based on the cross-layer negative feedback mechanism, it monitors and dynamically adjusts the system operation status in real time. When the monitored system status indicators deviate from the preset dynamic equilibrium range, or when an error signal is received from the error signal generation module, it is determined that the system stability is abnormal. The master node of each control cluster is used to receive transactions, determine the transaction ownership based on the resources involved in the transaction, and coordinate the processing flow within the cluster; each slave node performs transaction conflict detection based on the local vector clock and executes conflict-free transactions in parallel. Specifically, when the evaluation result of the system stability lease management module indicates that the system stability is abnormal, the lease renegotiation mechanism is triggered or the cluster master node switching process is controlled to maintain the continuous and stable operation of the system.

[0007] Optionally, in some embodiments of this application, the network dynamics stability model quantifies the degree to which the system state deviates from the stable equilibrium point by real-time collection of network latency, node response latency and transaction processing rate parameters, and outputs a stability score.

[0008] Optionally, in some embodiments of this application, the network operating parameters include network latency, node response latency, and transaction processing rate. The stability model generates a stability score by weighted summation after standardizing the parameters. When the stability score is lower than a preset threshold, it is used to assist in determining that the system stability is abnormal.

[0009] Optionally, in some embodiments of this application, the conditions for the system stability lease management module to determine stability anomalies include: the master node continuously losing connection for more than the lease threshold, the cross-cluster communication delay exceeding the preset upper limit, or the detection of node behavior deviating from the consensus protocol specification.

[0010] Optionally, in some embodiments of this application, the control cluster layer is further configured with a transaction access and queue module, an evidence aggregation module, a deterministic execution module and an error signal generation module, and each of the distributed control clusters maintains a lease view, a local sequence number, a highest confirmation credential and a local vector clock component.

[0011] Optionally, in some embodiments of this application, the node size of the distributed control cluster satisfies m≥3t+1, where m is the node size and t is the fault tolerance threshold of the distributed control cluster. When the evidence aggregation module generates confirmation credentials or availability evidence, it aggregates at least 2t+1 valid signature receipts.

[0012] Optionally, in some embodiments of this application, the global vector clock is optimized using a hierarchical management architecture or a cryptographic accumulator compression method. The hierarchical management architecture includes a core layer and an edge layer, with the core layer storing the aggregated clock digest of the edge layer.

[0013] Optionally, in some embodiments of this application, the cryptographic accumulator compression method is the Merkle accumulator compression method, wherein the Merkle accumulator controls the cluster clock components to construct the Merkle tree in batches according to the time window, and the global state layer only stores the root hash and the latest batch index.

[0014] Optionally, in some embodiments of this application, the master node switching process includes: The system stability lease management module broadcasts lease update messages. After the distributed control cluster receives a sufficient number of matching lease updates, it pulls the corresponding evidence on the chain, resets the local sequence number and the highest confirmation credential with the highest confirmation credential, and completes the restoration alignment. Then, the new master node initiates a proposal to continue the consensus convergence process.

[0015] Optionally, in some embodiments of this application, the global state layer further includes a cross-committee coupling coordination module, which is used to verify the source-side availability evidence of cross-committee transactions, advance the global vector clock component of the control cluster and generate cross-committee coupling execution instructions, and issue the cross-committee coupling execution instructions to the control cluster.

[0016] Optionally, in some embodiments of this application, the control cluster is configured with a waiting heap, which is used to cache the cross-committee coupled execution instructions when the local vector clock of the control cluster lags behind the global vector clock instruction requirements of the global state layer; the control cluster is configured to process local transactions using a priority-based out-of-order execution strategy, and when the local vector clock is aligned with the global vector clock, the cached cross-committee coupled execution instructions are extracted from the waiting heap and executed in the order of the global vector clock values.

[0017] Optionally, in some embodiments of this application, the distributed control cluster uses a single-phase atomic state coupling protocol when processing cross-committee transactions. After the source control cluster completes the local sorting and delivery of cross-committee transactions, it generates availability evidence and locks the corresponding account and state on the source side. The global state layer verifies the validity of the availability evidence based on the global consistent order of atomic broadcast. When the availability evidence verification passes, it advances the global vector clock components corresponding to the source control cluster and the target control cluster, and issues coupled execution instructions to the source control cluster and the target control cluster. The target control cluster determines that the cross-committee transaction will be executed when the local vector clock satisfies the increment condition.

[0018] Optionally, in some embodiments of this application, the error signal is structured data, which includes timestamp proof, evidence type, and set of observation node signatures.

[0019] Secondly, embodiments of this application provide a two-layer coupled blockchain processing method based on complex network dynamics, applied to the two-layer coupled blockchain processing system described in the first aspect. The two-layer coupled blockchain processing method includes: Initialize the global state layer and control cluster layer architecture, configure local vector clocks for each control cluster, and allocate the initial global clock reference by the global vector clock management module; The cluster master node receives transactions and determines whether a transaction is an intra-cluster transaction or a cross-cluster transaction based on the ownership of the transaction resources. For intra-cluster transactions, the slave node performs conflict detection and parallel processing based on the local vector clock to generate a block draft containing local time sequence markers; The master node requests a globally consistent sequence number from the atomic broadcast module, and the global vector clock management module synchronously updates the global clock. For cross-cluster transactions, the relevant control clusters coordinate timing based on the global vector clock, each cluster processes its own domain in parallel, and the results are used by the atomic broadcast module to achieve global consensus. The system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on the network dynamics stability model. If the assessment results indicate an instability anomaly, a lease renegotiation or master node switch will be triggered. The local block with the embedded globally consistent sequence number is submitted to the global state layer, and the atomic broadcast module generates global blocks in sequence and broadcasts confirmation.

[0020] Optionally, in some embodiments of this application, the system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on a network dynamics stability model, including: The network status parameters collected in real time are input into a preset stability evaluation function. When the stability score is lower than the threshold, it is judged as abnormal.

[0021] Optionally, in some embodiments of this application, the method further includes: dynamically adjusting the number of control clusters according to the system load; the system stability lease management module synchronously updating the topology relationship and lease binding to maintain stability constraints throughout the process; and when the transaction access and queue module performs batch processing, the number of transactions taken out from the queue at one time does not exceed the upper limit of the number of transactions in the batch processing.

[0022] Thirdly, embodiments of this application provide a storage medium storing a computer program that can be loaded by a processor and executed as described in the second aspect of the two-layer coupled blockchain processing method.

[0023] This application provides a two-layer coupled blockchain processing system, method, and storage medium based on complex network dynamics. The two-layer coupled blockchain processing system includes a global state layer configured with an atomic broadcast module, a global vector clock management module, and a system stability lease management module; and a control cluster layer containing multiple distributed control clusters, each control cluster including one master node and multiple slave nodes, and each control cluster configured with a local vector clock. The atomic broadcast module is used to generate and broadcast globally consistent sequence numbers; the global vector clock management module is used to allocate initial vector clock values ​​to each control cluster and dynamically synchronize cross-domain timing based on the atomic broadcast results; the system stability lease management module is used to manage the control clusters. The system manages the lease lifecycle of control clusters and evaluates the system's operating status in real time based on a network dynamics stability model. When transaction processing timeouts, discontinuous node states, or error signals from the error signal generation module are detected, the system is deemed to be in an unstable state. The master node of each control cluster receives transactions, determines transaction ownership based on the resources involved, and coordinates the cluster's processing flow. Each slave node performs transaction conflict detection based on a local vector clock and executes conflict-free transactions in parallel. When the evaluation result of the system stability lease management module indicates an unstable system, a lease renegotiation mechanism or a control cluster master node switching process is triggered to maintain continuous and stable system operation. In the dual-layer coupled blockchain processing scheme provided in this application, the dual-layer coupled architecture of the global state layer and the control cluster layer, combined with real-time evaluation using a network dynamics stability model, improves the module configuration and node fault-tolerant design of the control cluster, optimizes the transaction processing flow and global vector clock management method, and achieves stable system operation and efficient transaction processing. This improves system throughput, reduces transaction processing latency, and enhances system fault tolerance and reliability. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This application provides an architecture diagram of a blockchain network. Figure 2 This is a schematic diagram of a blockchain provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the generation of a new block according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of the two-layer coupled blockchain processing system provided in the embodiments of this application; Figure 5 This is a flowchart illustrating the two-layer coupled blockchain processing method provided in the embodiments of this application. Detailed Implementation

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with those detailed in the appended claims or with some aspects of this application.

[0027] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover descriptions such as non-exclusive inclusion, so that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0028] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0029] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0030] To address the aforementioned technical problems and overcome the shortcomings of existing technologies, this application provides a two-layer coupled blockchain processing system, method, and storage medium, which can improve system throughput, reduce transaction processing latency, and enhance system fault tolerance and reliability.

[0031] See Figure 1 As shown, a blockchain network can include multiple blockchain nodes, where a blockchain node refers to a computer device located within the blockchain network. The computer device mentioned here can be a terminal or a server, without limitation. Terminals can be smartphones, computers (such as tablets, laptops, desktop computers, etc.), smart wearable devices (such as smartwatches, smart glasses), smart voice interaction devices, smart home appliances (such as smart TVs), vehicle terminals, or aircraft, etc. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, etc.

[0032] A blockchain node can store both the blockchain itself and a transaction pool. A blockchain is a secure, shared, decentralized ledger of blocks, the core data structure of a blockchain network used to store and manage all confirmed blocks. Blocks are organized in a chain-like structure, each containing a set of transactions, a block header (including metadata such as the hash value and timestamp of the previous block), and other information. Thus, the blockchain provides a public, immutable history of transactions for the blockchain network, ensuring its transparency and consistency. A transaction pool, also known as a mempool, is a data structure in the blockchain network used to store transactions that have not yet been packaged into blocks. When a user submits a transaction (i.e., publishes a transaction) to the blockchain network, the transaction first enters the transaction pool; when a blockchain node prepares to generate a new block, it selects a certain number of transactions from the transaction pool to package.

[0033] As shown above, a blockchain can consist of multiple blocks. See also Figure 2As can be seen, the first block in a blockchain can be called the genesis block. The genesis block includes a block header and a block body. The block header stores input information (such as transaction) feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block in the blockchain is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0034] When generating the individual blocks in the blockchain, see Figure 3 As shown, when a blockchain node receives input information (such as a transaction), it verifies the input information. After verification, it stores the input information in a memory pool and updates the hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula: SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0035] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and block body, resulting in the current block. Subsequently, the blockchain node hosting the blockchain sends the newly generated block to other blockchain nodes based on the node identifiers of other blockchain nodes in the underlying chain. These other blockchain nodes verify the newly generated block and, after verification, reach a consensus on the new block. Once the newly generated block passes consensus, it is added to its stored blockchain. It is evident that each block contains the cryptographic hash of the previous block, the corresponding timestamp, and input information (represented by a hash value calculated using the Merkle tree algorithm). This design makes the block content difficult to tamper with; furthermore, since the block is consensus-driven, it possesses characteristics such as immutability, traceability, and joint maintenance. The distributed ledger connected by blockchain technology allows two parties to effectively record transactions and permanently verify these transactions.

[0036] Based on the aforementioned blockchain network, this application proposes a two-layer coupled blockchain processing system based on complex network dynamics to achieve stable system operation and efficient transaction processing, thereby improving system throughput, reducing transaction processing latency, and enhancing system fault tolerance and reliability. It is understood that the term "transaction" mentioned in this application is a term in the field of blockchain technology and does not necessarily mean the transfer of property; it can be a transaction, a message, or data sent from one object to another, etc. See also... Figure 4 As shown, the two-layer coupled blockchain processing system includes: The global state layer is configured with an atomic broadcast module, a global vector clock management module, and a system stability lease management module. The control cluster layer contains multiple distributed control clusters. Each control cluster includes a master node and multiple slave nodes. Each control cluster is configured with a local vector clock. The atomic broadcast module is used to generate and broadcast globally consistent sequence numbers; the global vector clock management module is used to allocate initial vector clock values ​​to each control cluster and dynamically synchronize cross-domain timing based on the atomic broadcast results; the system stability lease management module is used to manage the lease lifecycle of each control cluster and to evaluate the system operating status in real time based on the network dynamics stability model. When a transaction processing timeout, discontinuous node status, or an error signal sent by the error signal generation module is detected, the system stability is determined to be abnormal. The master node of each control cluster is used to receive transactions, determine the transaction ownership based on the resources involved in the transaction, and coordinate the processing flow within the cluster; each slave node performs transaction conflict detection based on the local vector clock and executes conflict-free transactions in parallel. Specifically, when the evaluation result of the system stability lease management module indicates that the system stability is abnormal, the lease renegotiation mechanism is triggered or the cluster master node switching process is controlled to maintain the continuous and stable operation of the system.

[0037] This embodiment describes a system stability lease management module used to manage the lease lifecycle of each control cluster and to perform real-time evaluation of the system's operating status based on a network dynamics stability model. Furthermore, it stipulates that "when the evaluation result of the system stability lease management module indicates an abnormal system stability, a lease renegotiation mechanism or a control cluster master node switching process is triggered to maintain the continuous stable operation of the system." This directly reflects the application of complex network dynamics in the system, namely, real-time evaluation of the system's operating status through a network dynamics stability model and triggering a stability maintenance mechanism based on the evaluation results.

[0038] One of the core innovations of this invention lies in the deep integration of classical control theory and complex network dynamics, which abstracts the two-layer coupled blockchain system into a distributed coupled control system with dynamic feedback adjustment capability. Through negative feedback / damping injection of error signals, system state reset during lease switching, and dynamic self-tuning of parameter weights, the system achieves stable convergence under complex scenarios such as network disturbances, node failures, and high concurrency loads, which is different from the static threshold determination mechanism of traditional blockchains.

[0039] From a control theory perspective, the global state layer of this system is the control layer (referred to as Layer 1), responsible for collecting system states, generating control commands, and executing feedback adjustments. The control cluster layer (referred to as Layer 2) is the controlled object. Each distributed control cluster, as a subsystem in the coupled control system, completes the state evolution of transaction processing through intra-cluster consensus. The subsystems are coupled and coordinated through the global vector clock of Layer 1. The dynamic feedback adjustment logic of the system fully follows the principle of negative feedback control, and its specific implementation is as follows: Error signal (Blame): The core carrier of negative feedback / damping signal The system stability lease management module collects core state parameters such as network latency, node response latency, and transaction processing rate in real time to construct a dynamic equilibrium reference system for system stability. When the Layer2 observation backup node detects anomalies such as master node disconnection, local sequence number gaps, or state vector conflicts, the error signal generation module generates a structured error signal (Blame), which serves as the negative feedback / damping signal in the control system. This signal is not a simple "error log," but a verifiable damping input carrying millisecond-level timestamp proof and 2t+1 valid signatures. Its core function is to inject damping into the coupled control system, suppressing state divergence caused by external disturbances (such as Byzantine behavior or network latency) in the subsystem, preventing the anomalies of a single control cluster from spreading to the entire blockchain network, and achieving disturbance suppression in complex network dynamics.

[0040] Lease switching / renegotiation: Precise reset and adjustment of system status When Layer1 receives an error signal (negative feedback) or detects that the system state parameters deviate from the dynamic equilibrium reference frame, it triggers lease renegotiation or master node switching, corresponding to system state reset / adjustment actions in the control system: Lease renegotiation is a fine-grained adjustment, suitable for scenarios where the system state slightly deviates from equilibrium. By updating the lease renewal threshold and adjusting the state parameter monitoring frequency, the system state returns to equilibrium. Master node switching is a coarse-grained state reset, suitable for scenarios where the system state is severely divergent. Through Layer1 broadcasting lease update messages, the control cluster resets the core states such as the local sequence number and the highest confirmation credential as the recovery anchor point, enabling the controlled object (control cluster) to switch from the divergent state trajectory to a new stable trajectory, achieving state convergence in complex network dynamics.

[0041] Dynamic self-tuning of parameter weights: Adaptive adjustment of PID-like (Proportional-Integral-Derivative) control This system does not use a static weighting method to monitor state parameters. Instead, it borrows the parameter self-tuning concept from PID control to achieve dynamic adaptive adjustment of weighting coefficients. The system stability lease management module continuously records historical operating data, including the correlation between various state parameters (network latency, node response latency, transaction processing rate) and system stability anomalies, the triggering causes of error signals, and the system recovery effect after lease adjustment. Based on the above historical data, the system optimizes the weighting coefficients of each state parameter in real time: for example, when the system triggers anomalies multiple times due to cross-cluster communication latency, it automatically increases the weighting coefficient of the network latency parameter to enhance the monitoring sensitivity of this parameter; when the anomaly trigger rate of node response latency decreases significantly, its weighting coefficient is appropriately reduced to reduce unnecessary monitoring overhead.

[0042] This dynamic self-tuning mechanism enables the system to adapt to different operating loads and network environments, avoiding the monitoring failure problem of static weights in high-concurrency and weak network scenarios, giving the entire coupled control system adaptive capabilities, and ultimately achieving global stability under the coupling of multiple subsystems in complex network dynamics.

[0043] In summary, this system integrates the core ideas of control theory into the two-layer coupled architecture of blockchain through a closed-loop design of "negative feedback signal injection - state reset adjustment - parameter self-tuning optimization". This enables the system to break through the design limitations of traditional blockchain's "static rules + post-error correction" and truly achieve dynamic stability control based on complex network dynamics. This is also an important distinguishing feature of this invention compared to existing Layer2 expansion schemes.

[0044] After receiving local blocks submitted by each control cluster, the global state layer only verifies the signature information and Merkle root hash in the block. It does not need to store the complete transaction data in the local block, nor does it need to re-execute the transactions already processed by the control cluster layer. After the verification is successful, the global block is directly generated by the atomic broadcast module, which greatly reduces the storage and computational overhead of the global state layer and avoids it becoming a bottleneck in system performance.

[0045] Furthermore, the system described in this embodiment comprises two layers: a global state layer and a control cluster layer. The global state layer is configured with an atomic broadcast module, a global vector clock management module, and a system stability lease management module. The control cluster layer contains multiple distributed control clusters, each consisting of a master node and multiple slave nodes. The functional coupling relationship between the two layers is further explained: the global state layer allocates initial vector clock values ​​to each control cluster through the global vector clock management module and dynamically synchronizes cross-domain timing based on the atomic broadcast results; the control cluster layer receives transactions through each master node, determines transaction ownership based on the resources involved in the transaction, and coordinates the intra-cluster processing flow; and the slave nodes perform transaction conflict detection based on local vector clocks and execute conflict-free transactions in parallel. This fully describes the two-layer architecture and its coupling mechanism in terms of timing synchronization, transaction processing, and stability management.

[0046] For example, specifically, the global state layer is responsible for global timing synchronization, lease lifecycle management of each control cluster, stability assessment of system operation status, and global consensus coordination of cross-cluster transactions. It is configured with an atomic broadcast module, a global vector clock management module, and a system stability lease management module.

[0047] The atomic broadcast module generates and broadcasts globally consistent sequence numbers (GS), ensuring that transaction processing information (such as transaction data, lease update messages, and global clock synchronization information) received by all control clusters has a globally consistent order. This provides a foundation for timing coordination of cross-cluster transactions and global data consistency. Specifically, the atomic broadcast module uses a distributed atomic broadcast protocol (such as an improved version of the Paxos or Raft protocol) to receive global sequence number requests and cross-cluster transaction processing results from the master nodes of each control cluster. It sorts this information, generates globally consistent sequence numbers, and broadcasts the sorted information along with the corresponding globally consistent sequence numbers to all distributed control clusters, ensuring that the information received by each control cluster is in the same order.

[0048] During implementation, the atomic broadcast module employs an information cache queue to cache request information from various control clusters, preventing sorting chaos caused by concurrent requests. Simultaneously, the atomic broadcast module utilizes a heartbeat detection mechanism to monitor the communication status with each control cluster in real time. When a control cluster fails to receive the broadcast information in a timely manner, the module rebroadcasts the information, ensuring reliable data transmission. Furthermore, the atomic broadcast module synchronizes the generated globally consistent sequence number and corresponding information to the global state layer's storage unit for subsequent on-chain evidence lookup and state recovery.

[0049] It should be noted that when the atomic broadcast module generates and broadcasts a global block, it only carries the signature and root hash verification information of the local block, without carrying complete transaction data, which further reduces the transmission and storage pressure of the global state layer.

[0050] For example, when a control cluster master node completes the parallel processing of transactions within its cluster, it requests a globally consistent sequence number from the atomic broadcast module to mark the global timing of the transactions within that cluster. After receiving the request, the atomic broadcast module, based on the current information sorting, assigns a unique globally consistent sequence number to the transactions within that cluster, binds the globally consistent sequence number to the processing result of the transactions within that cluster, and broadcasts it to all control clusters. This ensures that all control clusters can obtain the global timing information of the transactions, providing a reference for the timing coordination of cross-cluster transactions.

[0051] The global vector clock management module is used to allocate initial vector clock values ​​to each distributed control cluster and dynamically synchronize the cross-domain timing of each control cluster based on the broadcast results of the atomic broadcast module. This ensures that the local vector clock of each control cluster is consistent with the global vector clock, providing a timing reference system for transaction conflict detection and cross-cluster transaction timing coordination.

[0052] First, during the system initialization phase, the global vector clock management module assigns a unique initial vector clock value to each distributed control cluster. The initial vector clock value is represented by a multi-dimensional vector, where each dimension corresponds to a distributed control cluster, and each component of the vector represents the local timing mark of the corresponding control cluster. In the initial state, the local timing mark of each control cluster is 0, that is, the initial vector clock value is (0,0,...,0) (assuming the system contains n distributed control clusters, then the vector dimension is n).

[0053] During system operation, the global vector clock management module receives the globally consistent sequence number and local timing information of each control cluster broadcast by the atomic broadcast module in real time. Based on this information, it dynamically updates the global vector clock and synchronizes the updated global vector clock to each distributed control cluster, ensuring that the local vector clock of each control cluster remains synchronized with the global vector clock. Specifically, when a control cluster completes the processing of a transaction, it increments the corresponding component of its local vector clock by 1 and submits the updated local vector clock information to the atomic broadcast module. The atomic broadcast module binds this information with the globally consistent sequence number and broadcasts it. After receiving this broadcast information, the global vector clock management module updates the component of the corresponding control cluster in the global vector clock, completing the dynamic synchronization of the global vector clock.

[0054] To adapt to large-scale control clusters and high-concurrency transaction scenarios, and to reduce the management overhead and storage pressure of the global vector clock, this application optimizes the global vector clock using a hierarchical management architecture or a Merkle accumulator compression method. The specific implementations of the two optimization methods are as follows: (1) Optimization of hierarchical management architecture The hierarchical management architecture divides the global vector clock into a core layer and an edge layer. The core layer is directly maintained by the global state layer, while the edge layer is maintained by multiple supernode clusters. Each supernode cluster is responsible for managing the local vector clocks of multiple distributed control clusters. The core layer does not store the local vector clock components of all control clusters; it only stores the aggregated clock summary of each edge layer supernode cluster. The aggregated clock summary is obtained by the supernode cluster aggregating the local vector clocks of all the control clusters it manages (e.g., taking the maximum value, average value, etc. of each component).

[0055] During implementation, each supernode cluster collects local vector clock information from the control clusters it manages in real time. It periodically aggregates these local vector clocks to generate an aggregated clock summary, which is then submitted to the core layer of the global state layer. The core layer updates the core layer information of the global vector clock based on the aggregated clock summaries from each supernode cluster. When cross-cluster transaction timing coordination is required, if the cross-cluster transaction belongs to the control cluster managed by the same supernode cluster, the supernode cluster performs timing coordination based on the local vector clocks it manages. If the cross-cluster transaction belongs to control clusters managed by different supernode clusters, the core layer of the global state layer coordinates the timing of each supernode cluster based on the aggregated clock summaries, thereby achieving timing synchronization of cross-cluster transactions.

[0056] The advantage of this hierarchical management architecture is that it reduces the storage pressure and clock synchronization overhead of the global state layer. The core layer only needs to maintain the aggregated clock digest of a small number of super node clusters, without having to maintain the local vector clock components of all control clusters. At the same time, the super node cluster is responsible for the clock management of the local control cluster, which improves the efficiency of clock synchronization and is suitable for large-scale control cluster scenarios.

[0057] (2) Optimization of Merkel accumulator compression method The Merkle accumulator compression method constructs a Merkle tree in batches according to time windows for the local vector clock components of each control cluster. The global state layer only stores the root hash of the Merkle tree and the latest batch index, without needing to store the local vector clock components of all control clusters, thereby reducing storage pressure.

[0058] Specifically, the global vector clock management module sets a fixed time window (e.g., 50ms). After each time window ends, it collects the current local vector clock components of all distributed control clusters, uses these local vector clock components as leaf nodes of a Merkle tree, constructs the Merkle tree, calculates the root hash of the Merkle tree, and records the batch index (e.g., an integer incrementing in chronological order) corresponding to that time window. The global state layer only stores the Merkle tree root hash and batch index for each time window, while each control cluster stores its own local vector clock components and the corresponding Merkle tree branch information.

[0059] When it's necessary to verify the validity of a local vector clock component of a control cluster, or to perform cross-cluster transaction timing coordination, the control cluster submits its local vector clock component and corresponding Merkle tree branch information to the global vector clock management module. The global vector clock management module verifies the validity of this local vector clock component based on the stored Merkle tree root hash and batch index. If the verification passes, timing coordination is performed based on this local vector clock component. This compression method not only reduces the storage pressure on the global state layer but also ensures the integrity and authenticity of the local vector clock component through Merkle tree hash verification, preventing malicious nodes from tampering with clock information.

[0060] In addition, the core function of the system stability lease management module is to manage the lease lifecycle of each distributed control cluster and to evaluate the system's operating status in real time based on the network dynamics stability model. When the evaluation results indicate that the system stability is abnormal, the lease renegotiation mechanism or the control cluster master node switching process is triggered to maintain the continuous and stable operation of the system.

[0061] A lease is a management authority credential granted by the global state layer to each distributed control cluster master node. It is used to regulate the management behavior of the master nodes and ensure the orderly operation of each control cluster. The lease lifecycle includes three stages: lease grant, lease renewal, and lease expiration. The system stability lease management module is responsible for the full process management of these three stages.

[0062] During the system initialization phase, the system stability lease management module grants an initial lease to the master node of each distributed control cluster. The initial lease includes a unique lease identifier, control cluster identifier, master node public key, lease validity period, lease thresholds (such as master node disconnection threshold, cross-cluster communication delay threshold, etc.), and lease status. After the initial lease is granted, the system stability lease management module broadcasts the lease information to the corresponding control cluster and other relevant modules, ensuring that all modules can obtain the lease information.

[0063] During the lease term, the control cluster master node needs to periodically (e.g., every minute) submit a lease renewal application to the system stability lease management module, along with the operating status information of the control cluster (e.g., transaction processing rate, node response latency, and duration of operation without abnormalities). After receiving the lease renewal application, the system stability lease management module determines whether the operating status of the control cluster is stable based on the evaluation results of the network dynamics stability model. If the operating status is stable, the lease renewal is approved, the lease term is extended (e.g., extended by 10 minutes), and the lease status is updated to "valid". If the operating status is unstable, the lease renewal is rejected, and the lease automatically expires after the lease term ends.

[0064] When a lease expires, the system stability lease management module immediately broadcasts the lease expiration message, notifying the corresponding control cluster and other relevant modules. Simultaneously, it triggers a lease renegotiation mechanism or a master node switchover process to re-determine the master node of the control cluster or re-grant the lease, ensuring the continued operation of the control cluster. Furthermore, when the control cluster master node voluntarily relinquishes its management authority, it can submit a lease cancellation request to the system stability lease management module. Upon approval by the module, the lease immediately expires, triggering the corresponding subsequent processing procedures.

[0065] The network dynamics stability model quantifies the degree to which the system state deviates from the stable equilibrium point by collecting the system's operating parameters in real time and outputs a stability score. The system stability lease management module evaluates whether the system's operating state is stable based on this stability score.

[0066] First, the network dynamics stability model requires real-time acquisition of operational parameters including network latency, node response latency, and transaction processing rate. Specifically, a network latency detection tool is used to collect real-time communication latency between control clusters and between control clusters and the global state layer, and the average value of each collection is taken as the current network latency parameter. The response latency of each control cluster master node and slave node to transaction requests is collected in real-time, that is, the time interval from when a slave node receives a transaction request to when it returns a transaction processing receipt, and the average value of all node response latencies is taken as the current node response latency parameter. The number of transactions processed by each control cluster per unit time (e.g., 1 second) is counted in real-time, and the average transaction processing rate of all control clusters is taken as the current transaction processing rate parameter.

[0067] After collecting the three operating parameters mentioned above, the network dynamics stability model standardizes these parameters (eliminating the influence of different dimensions of the parameters). After standardization, the network dynamics stability model calculates a weighted sum of the three standardized parameter values ​​based on a preset weight allocation to generate a stability score. The weight allocation can be flexibly adjusted according to the application scenario of the system. For example, in a high-stability scenario, the weight of network latency is 0.4, the weight of node response latency is 0.3, and the weight of transaction processing rate is 0.3; in a high-concurrency scenario, the weight of transaction processing rate is 0.4, the weight of network latency is 0.3, and the weight of node response latency is 0.3.

[0068] Optionally, in some embodiments of this application, the stability score ranges from 0 to 10 points. A higher score indicates a more stable system operation and a closer proximity to the stable equilibrium point; a lower score indicates a more unstable system operation and a greater deviation from the stable equilibrium point. The system presets a stability score threshold (e.g., 6 points). When the stability score is ≥ 6 points, the system stability lease management module determines that the system operation is stable; when the stability score is < 6 points, the system operation is determined to be abnormal, and the corresponding abnormal handling process needs to be triggered.

[0069] During implementation, the network dynamics stability model updates the stability score periodically (e.g., every 100ms) and feeds the updated stability score back to the system stability lease management module in real time. The system stability lease management module combines the stability score with preset anomaly judgment conditions to comprehensively evaluate the system's operating status.

[0070] The system stability lease management module determines stability anomalies based on the following three conditions; meeting any one of these conditions constitutes a stability anomaly: (1) The master node is continuously disconnected for more than the lease threshold: The system stability lease management module adopts a heartbeat detection mechanism to monitor the running status of each control cluster master node in real time. The master node needs to send heartbeat messages to the system stability lease management module regularly. If the system stability lease management module fails to receive the heartbeat message from the master node for more than the lease threshold (e.g., 3 times), it is determined that the master node is disconnected, and the system stability is abnormal.

[0071] (2) Cross-cluster communication delay exceeds the preset limit: The system stability lease management module receives network delay parameters collected by the network dynamics stability model in real time. If the network delay parameters continuously exceed the preset limit, the system stability is determined to be abnormal, because excessive cross-cluster communication delay will lead to difficulties in cross-cluster transaction timing coordination, reduced transaction processing efficiency, and even transaction loss.

[0072] (3) Detection of node behavior deviating from consensus protocol specifications: The system stability lease management module receives error signals fed back by the error signal generation module of each control cluster in real time. If the error signal indicates that the behavior of a node (master node or slave node) deviates from the consensus protocol specifications (such as maliciously tampering with transaction data, forging transaction processing receipts, refusing to execute consensus decisions, etc.), the system stability is determined to be abnormal, because malicious behavior of nodes will destroy the data consistency and stability of the system.

[0073] When the system stability lease management module determines that the system stability is abnormal, it will trigger the lease renegotiation mechanism or control the cluster master node switchover process, depending on the severity of the abnormality, as follows: (1) Lease renegotiation mechanism: When the anomaly is minor (e.g., the cross-cluster communication delay slightly exceeds the preset limit, but does not cause transaction processing to stop; the master node is not lost, but the heartbeat message is delayed), the lease renegotiation mechanism is triggered. The specific process of the lease renegotiation mechanism is as follows: The system stability lease management module broadcasts the lease renegotiation message to notify the corresponding control cluster and other related modules; after receiving the lease renegotiation message, the control cluster master node convenes all slave nodes in the cluster to negotiate and adjust the lease parameters (e.g., shorten the lease validity period, adjust the lease threshold, etc.), and submits the negotiated lease parameters to the system stability lease management module; the system stability lease management module reviews the negotiated lease parameters based on the evaluation results of the network dynamics stability model. If the review is passed, the lease information is updated and the lease renegotiation is completed. At the same time, corresponding optimization measures are taken (e.g., adjust network routing, optimize node load, etc.) to improve the system operation status; if the review is not passed, the control cluster is required to renegotiation until the review is passed.

[0074] When the anomaly is severe (such as the master node being continuously disconnected for more than the lease threshold, or malicious behavior of the master node being detected), the control cluster master node switchover process is triggered, and the specific process is as follows: The system stability lease management module broadcasts lease update messages. These messages include the control cluster identifier, the old master node's public key, the lease expiration time, and the new master node election rules. The broadcast is sent to the corresponding distributed control cluster and other relevant modules. Upon receiving the lease update message, all slave nodes within the cluster elect a new master node based on the election rules in the message. These rules can employ methods such as round-robin, random seeding, or reputation scoring. For example, when using reputation scoring, slave nodes calculate their reputation scores based on historical transaction processing accuracy and abnormal runtime, electing the slave node with the highest reputation score as the new master node. After the new master node is elected, the distributed control cluster receives a sufficient number of matching lease update messages (at least 2t+1, where t is the fault tolerance threshold of the distributed control cluster) to ensure the validity and consistency of the lease update messages. The new master node pulls the corresponding evidence from the chain to the global state layer. The corresponding evidence on the chain includes the historical transaction processing records of the control cluster, the highest confirmation certificate, global vector clock information, etc. The new master node uses the highest confirmation certificate as a benchmark to reset the local sequence number and the highest confirmation certificate of the control cluster, ensuring that the state of the control cluster is consistent with the global state layer, and completing the restoration alignment.

[0075] After the alignment is restored, the new master node initiates a transaction processing proposal, summons the slave nodes within the cluster to continue the consensus convergence process, restores the transaction processing function of the control cluster, the system stability lease management module updates the lease information of the control cluster, writes the new master node's public key into the lease, updates the lease status to "valid", and completes the master node switch.

[0076] The control cluster layer is responsible for receiving transactions submitted by clients, classifying and processing transactions (intra-cluster transactions, cross-cluster transactions), and realizing parallel processing of transactions. It contains multiple distributed control clusters, each of which includes a master node and multiple slave nodes. Each distributed control cluster is configured with a local vector clock. In addition, the control cluster layer is also configured with a transaction access and queuing module, an evidence aggregation module, a deterministic execution module, and an error signal generation module.

[0077] A distributed control cluster is the basic processing unit of the control cluster layer. Each distributed control cluster is responsible for transaction processing within a certain range. Multiple distributed control clusters work in parallel to improve the overall transaction processing throughput of the system. Each distributed control cluster includes one master node and multiple slave nodes. The node size satisfies m ≥ 3t + 1, where m is the total number of nodes in the distributed control cluster and t is the fault tolerance threshold of the distributed control cluster. This node size design ensures that even if up to t slave nodes fail or are maliciously attacked, the accuracy and consistency of transaction processing results can still be guaranteed, thus improving the fault tolerance of the system.

[0078] For example, when t=1, the node size m of the distributed control cluster is greater than or equal to 4, meaning that each control cluster contains at least 1 master node and 3 slave nodes. When 1 slave node fails, the remaining 3 nodes (1 master node + 2 slave nodes) can still work normally, ensuring the continuity of transaction processing. When t=2, the node size m is greater than or equal to 7, meaning 1 master node + 6 slave nodes. When 2 slave nodes fail, the remaining 5 nodes can still work normally, and so on.

[0079] Each distributed control cluster is configured with a local vector clock, which is synchronized with the global vector clock for conflict detection in intra-cluster transactions and timing coordination of cross-cluster transactions. The local vector clock uses a multi-dimensional vector representation, with the same dimensions as the global vector clock. Each component corresponds to a distributed control cluster, and the component value of the local vector clock is determined by the transaction processing progress of that control cluster. After each transaction is completed, the component value of the local vector clock corresponding to that control cluster is incremented by 1.

[0080] In addition, each distributed control cluster maintains a lease view, local sequence number, highest confirmation credential, and local vector clock component. The lease view stores lease information for the control cluster (such as lease unique identifier, master node public key, lease validity period, etc.) and is synchronized in real time with the system stability lease management module. The local sequence number marks the local processing order of transactions within the control cluster, incrementing by 1 for each transaction processed. The highest confirmation credential records the highest credential of transactions that have been processed and verified by evidence aggregation in the control cluster, used for state recovery alignment after master node switching. The local vector clock component stores the global vector clock component corresponding to the control cluster, ensuring synchronization with the global vector clock.

[0081] The master node is responsible for receiving transactions, determining transaction ownership based on the resources involved, and coordinating intra-cluster processing. Specifically, the master node receives transactions submitted by clients or cross-cluster transactions forwarded by other control clusters, parses the resources involved in the transaction, and determines transaction ownership, i.e., whether the transaction is intra-cluster or cross-cluster. An intra-cluster transaction refers to a transaction in which all resources involved fall within the management scope of that distributed control cluster, while a cross-cluster transaction refers to a transaction in which resources involved fall within the management scope of two or more distributed control clusters.

[0082] For example, if both accounts involved in a transaction belong to the same control cluster, it is considered an intra-cluster transaction; if the two accounts involved in a transaction belong to one control cluster and another control cluster respectively, it is considered a cross-cluster transaction. The master node determines the transaction's ownership by parsing the transaction's resource identifier (such as account address, resource ID, etc.) and querying the control cluster identifier corresponding to that resource.

[0083] In addition, for intra-cluster transactions, the master node coordinates the modules and slave nodes within the cluster to complete processes such as parallel processing of transactions, evidence aggregation, and deterministic execution; for cross-cluster transactions, the master node coordinates the control cluster with other relevant control clusters to complete processes such as timing coordination of cross-cluster transactions, parallel processing of the transaction portion within the local domain, and feedback of processing results.

[0084] For cross-cluster transactions, the master node parses the relevant control cluster identifiers involved in the transaction, forwards the transaction to the master node of the relevant control cluster, coordinates the timing with the master node of the relevant control cluster based on the global vector clock, allocates transaction processing tasks to each control cluster, receives transaction processing acknowledgments from the slave nodes of its own cluster, aggregates and generates the processing results of the transaction part in its own domain, submits the processing results to the atomic broadcast module to participate in global consensus, and finally receives the global consensus results from the atomic broadcast module, notifies the deterministic execution module to execute the transaction, and completes the local domain processing part of the cross-cluster transaction.

[0085] It should be noted that the master node periodically submits lease renewal applications to the system stability lease management module, and provides feedback on the operational status information of the control cluster (such as transaction processing rate, node response latency, and abnormal runtime). It also receives lease update messages and lease renegotiation messages broadcast by the system stability lease management module, and coordinates the nodes within the cluster to complete the lease renegotiation or master node switching process. In real time, it provides feedback to the global state layer on the local sequence number, highest confirmation credential, local vector clock, and other status information of the control cluster, ensuring that the global state layer can grasp the operational status of the control cluster in real time.

[0086] The slave node is responsible for performing transaction conflict detection based on the local vector clock. Conflict-free transactions are executed in parallel. Specifically, the slave node receives the local processing portion of intra-cluster or cross-cluster transactions forwarded by the master node and performs transaction conflict detection based on the local vector clock. A transaction conflict refers to two or more transactions involving the same resource (such as the same account or the same asset) and whose transaction operations contradict each other (such as simultaneously transferring and freezing funds in the same account). Without conflict detection, inconsistent transaction processing results will occur.

[0087] It should be noted that for cross-cluster transactions, the master node parses the relevant control cluster identifiers involved in the transaction, forwards the transaction to the master node of the relevant control cluster, and coordinates the timing with the master node of the relevant control cluster based on the global vector clock. For cross-cluster transactions with misaligned clocks, they are temporarily stored in a waiting heap. Once the local vector clocks of each relevant control cluster are synchronized with the global vector clock, the transaction is retrieved from the waiting heap for processing. For cross-cluster transactions with aligned clocks, an out-of-order execution strategy is adopted. Each control cluster does not need to execute according to the transaction submission order and can independently process the transactions in its own domain in parallel, which greatly improves the processing efficiency of cross-cluster transactions and solves the processing blocking problem caused by clock misalignment in traditional cross-cluster transactions, making it suitable for high-concurrency transaction scenarios.

[0088] Specifically, the process involves parsing the resource identifier and transaction operation of a transaction from the node, querying the historical transaction records and corresponding local vector clock components of the resource, and determining that the transaction is conflict-free if the local vector clock component of the current transaction is greater than that of the historical transactions of the resource and the transaction operation does not contradict the historical transaction operation. If the local vector clock component of the current transaction is less than or equal to that of the historical transactions of the resource, or if the transaction operation contradicts the historical transaction operation, then the transaction is determined to be conflict-free.

[0089] For transactions without conflicts, the slave node immediately performs parallel processing; for transactions with conflicts, the slave node marks the transaction as a conflicting transaction and reports it to the master node, which then re-coordinates the processing (such as adjusting the transaction processing order or rejecting conflicting transactions).

[0090] Furthermore, slave nodes execute conflict-free transactions in parallel, with each slave node independently processing its assigned transactions without waiting for other slave nodes to complete their processing, thus improving transaction processing efficiency. After executing a transaction, a slave node generates a transaction processing receipt, which includes the transaction identifier, transaction processing result, slave node signature, local vector clock information, etc. The transaction processing receipt is fed back to the master node and simultaneously synchronized to the evidence aggregation module for generating confirmation credentials.

[0091] It should also be noted that the slave node monitors its own operating status in real time, as well as its communication status with the master node and other slave nodes. If it detects an abnormality in its own operation (such as hardware failure, software error, etc.), or if it detects that the behavior of the master node or other slave nodes deviates from the consensus protocol specifications (such as maliciously tampering with transaction data, forging transaction processing receipts, etc.), it generates abnormal information and feeds it back to the error signal generation module. The error signal generation module generates an error signal and reports it to the system stability lease management module of the global state layer, triggering the abnormal handling process.

[0092] The transaction access and queue module is configured at the control cluster layer to assist the master node in receiving transactions and performing cache sorting, ensuring the orderly processing of transactions and avoiding processing chaos caused by transaction concurrency. Specifically, the transaction access and queue module receives transactions forwarded by the master node (the local processing portion of intra-cluster transactions and cross-cluster transactions), parses the transactions, extracts key information (such as transaction identifier, transaction amount, resource identifier, submission time, etc.), and sorts the transactions.

[0093] The transaction sorting uses a combination of priority sorting and time-series sorting. Priority sorting assigns transaction priority based on the importance of the transaction (e.g., VIP user transactions, large transactions have higher priority than ordinary user transactions, and small transactions have lower priority). Time-series sorting assigns transaction processing order based on the transaction submission time (or local vector clock information). Transactions with higher priority are processed first, and transactions with the same priority are processed in the order of submission time.

[0094] The transaction access and queue module is equipped with a transaction cache queue to cache sorted transactions. The capacity of the cache queue can be dynamically adjusted according to the system load (e.g., increasing the cache queue capacity when the system load is high and decreasing the cache queue capacity when the system load is low) to prevent transaction loss. At the same time, the transaction access and queue module monitors the number of transactions in the cache queue in real time. When the number of transactions in the cache queue exceeds a preset threshold, it sends a load warning message to the master node. Based on the warning message, the master node adjusts the transaction processing strategy (e.g., increasing the number of transactions processed by slave nodes, triggering the control cluster number adjustment mechanism, etc.).

[0095] After sorting, the transaction access and queue module forwards the transactions to each slave node in sequence, notifying the slave nodes to perform transaction conflict detection and parallel processing. At the same time, it feeds back the transaction sorting information to the master node for the master node to coordinate the cluster processing flow.

[0096] The evidence aggregation module is configured in the control cluster layer to aggregate transaction processing receipts from slave nodes to generate confirmation credentials or availability evidence, ensuring the validity and consistency of transaction processing results and providing support for global consensus on transaction processing results.

[0097] After successful verification, the evidence aggregation module aggregates the transaction processing receipts. The aggregation rule is as follows: for the same transaction, at least 2t+1 valid signature transaction processing receipts are aggregated (t is the fault tolerance threshold of the distributed control cluster). When the number of aggregated valid receipts reaches 2t+1, a confirmation certificate for the transaction is generated. For cross-cluster transactions, in addition to generating a confirmation certificate, availability evidence is also generated. The availability evidence is used to prove the validity of the local processing part of the cross-cluster transaction in the control cluster and is submitted to the cross-cluster coordination module of the global state layer for global consensus on cross-cluster transactions.

[0098] The confirmation credential includes the transaction identifier, transaction processing result, aggregated valid receipt summary, evidence aggregation module signature, local vector clock information, and globally consistent sequence number (if already obtained). The availability evidence includes the cross-cluster transaction identifier, local domain processing result, confirmation credential summary, and evidence aggregation module signature. The evidence aggregation module feeds back the generated confirmation credential and availability evidence to the master node, synchronizing them to the global state layer's storage unit for subsequent state recovery, evidence retrieval, and other operations.

[0099] For example, when t=1, the number of slave nodes in the distributed control cluster is 3. The evidence aggregation module needs to aggregate at least 3 valid signed transaction processing receipts (2×1+1=3) to generate the confirmation certificate for the transaction and ensure the accuracy of the transaction processing result. If only 2 or 1 valid receipts are aggregated, the confirmation certificate cannot be generated. The evidence aggregation module reports this situation to the master node, and the master node notifies the slave node to resubmit the transaction processing receipt or re-execute the transaction processing process.

[0100] The deterministic execution module is configured in the control cluster layer and is used to execute the final transaction after aggregation and confirmation, ensuring the consistency and immutability of the transaction processing results. Its specific functions are as follows: The deterministic execution module receives the confirmation credential (or global consensus result) forwarded by the master node, verifies the validity of the confirmation credential (such as the validity of the signature of the evidence aggregation module, the completeness of the aggregation receipt, etc.), and if the verification is successful, it executes the final landing operation of the transaction based on the transaction processing result in the confirmation credential, that is, updates the status of the resources involved in the transaction (and writes the transaction processing result to the local ledger of the control cluster).

[0101] If the verification fails (e.g., the confirmation voucher has been tampered with, or the number of aggregated receipts is insufficient), the deterministic execution module refuses to execute the transaction landing operation and sends the verification failure information back to the master node. The master node then coordinates with the evidence aggregation module to re-aggregate receipts to generate confirmation vouchers, or to re-execute the transaction processing flow.

[0102] In addition, the deterministic execution module is responsible for maintaining the integrity and consistency of the local ledger. The local ledger stores detailed information about all transactions processed by the control cluster (such as transaction identifiers, transaction results, confirmation credentials, processing times, etc.). The local ledger uses encrypted storage methods (such as a combination of symmetric and asymmetric encryption) to ensure the security and immutability of transaction data. Simultaneously, the deterministic execution module periodically submits a summary of the local ledger to the global state layer for synchronization and verification of the global ledger.

[0103] The master node switching process of this solution is triggered by an error signal and is executed in real time throughout. There is no need to wait for an additional challenge period. This is fundamentally different from the existing Optimistic Rollup solution, which requires waiting for a 7-day challenge period before fault handling can be carried out. This solves the problems of poor real-time performance and delayed fault recovery in existing technologies, and ensures the continuity of transaction processing.

[0104] As described above, the dual-layer coupled blockchain processing system provided in this application, through a dual-layer coupled architecture of a global state layer and a control cluster layer, combined with real-time evaluation of the network dynamics stability model, improves the module configuration and node fault tolerance design of the control cluster, optimizes the transaction processing flow and global vector clock management method, and achieves stable system operation and efficient transaction processing. As a result, it improves the system throughput, reduces transaction processing latency, and enhances the system's fault tolerance and reliability.

[0105] Please continue reading. Figure 4 and in conjunction with reference Figure 5 , Figure 5 This is a flowchart illustrating a two-layer coupled blockchain processing method based on complex network dynamics according to an embodiment of this application. This embodiment primarily uses the application of this two-layer coupled blockchain processing method based on complex network dynamics to a two-layer coupled blockchain processing system as an example for illustration. Specifically, the two-layer coupled blockchain processing method provided in this embodiment may include the following steps: S101. Initialize the global state layer and control cluster layer architecture, configure local vector clocks for each control cluster, and allocate the initial global clock reference by the global vector clock management module; S102. Control the cluster master node to receive transactions and determine whether the transaction is an intra-cluster transaction or a cross-cluster transaction based on the ownership of the transaction resources. S103. For intra-cluster transactions, the slave node performs conflict detection and parallel processing based on the local vector clock to generate a block draft containing local time sequence markers. S104. The master node requests a globally consistent sequence number from the atomic broadcast module, and the global vector clock management module updates the global clock synchronously. S105. For cross-cluster transactions, the relevant control cluster coordinates the timing based on the global vector clock, each cluster processes its own domain in parallel, and the results are used by the atomic broadcast module to achieve global consensus. The relevant control clusters mentioned in this application refer to all participating control clusters that process cross-cluster transactions. Specifically, they are the source control cluster that initiates the transaction and the target control cluster that carries the target resources of the transaction. The two complete cross-cluster timing coordination based on the global vector clock and process the sub-transaction processes of the cross-cluster transaction in their respective control clusters in parallel.

[0106] When processing cross-committee transactions, the distributed control cluster employs a single-phase atomic state coupling protocol. After the source control cluster completes the local sorting and delivery of cross-committee transactions, it generates availability evidence and locks the corresponding account and state on the source side. The global state layer verifies the validity of the availability evidence based on the global consistent order of atomic broadcast. When the availability evidence verification passes, it advances the global vector clock components corresponding to the source control cluster and the target control cluster and issues coupled execution instructions to the source control cluster and the target control cluster. When the target control cluster satisfies the gapless increment condition of its local vector clock, it deterministically executes the sub-transaction corresponding to the cross-committee transaction.

[0107] In cross-cluster transactions, the target control cluster triggers asynchronous caching and out-of-order execution during the execution phase, specifically as follows: If the target control cluster's local vector clock component does not yet meet the Layer 1 instruction issuance requirements due to network latency or load peaks, the target control cluster temporarily caches the coupled execution instruction through a waiting heap, while simultaneously employing a priority-based out-of-order execution strategy to process the local transaction. The waiting heap stores the coupled execution instructions to be executed in order of global vector clock values. When the target control cluster's local vector clock component is updated to meet the execution conditions, the instructions are retrieved from the waiting heap in order for execution. This mechanism avoids transaction blocking caused by cross-cluster clock alignment, significantly improving the overall throughput and response speed of the system in high-concurrency scenarios.

[0108] S106. The system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on the network dynamics stability model. S107. If the assessment results indicate an abnormal stability, then trigger lease renegotiation or master node switching. S108. Submit the local block with the embedded global consistent sequence number to the global state layer, and the atomic broadcast module generates global blocks in sequence and broadcasts confirmation.

[0109] Optionally, in some embodiments of this application, the system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on a network dynamics stability model, including: The network status parameters collected in real time are input into a preset stability evaluation function. When the stability score is lower than the threshold, it is judged as abnormal.

[0110] Because the three types of parameters have different dimensions and numerical ranges, in order to avoid the weight failure caused by direct calculation, all collected parameters need to be standardized and uniformly mapped to a reasonable numerical range. The processing rules are as follows: the system presets a reasonable value range for each parameter. If the collected parameter value is within this range, it is standardized according to the normalization logic. If the collected parameter value exceeds the reasonable range, it is directly processed according to the minimum or maximum value of the reasonable range to avoid extreme values ​​interfering with subsequent scoring results. This eliminates the influence of different parameters' dimensions and ensures the fairness and accuracy of the evaluation.

[0111] After standardization, the three types of parameter values ​​are weighted and summed to obtain the final system stability score. The score quantifies the degree to which the system state deviates from the stable equilibrium point. The specific calculation rules are as follows: The total weight is 1, and can be flexibly adjusted according to the actual application scenario of the system. The document specifies two typical weight configuration methods: for high stability demand scenarios (such as financial payment), the network latency weight is 0.4, the node response latency weight is 0.3, and the transaction processing rate weight is 0.3; for high concurrency demand scenarios (such as e-commerce flash sales), the transaction processing rate weight is 0.4, the network latency weight is 0.3, and the node response latency weight is 0.3. Calculation logic: Stability score = Network latency standardized value × corresponding weight + Node response latency standardized value × corresponding weight + Transaction processing rate standardized value × corresponding weight; The stability score ranges from 0 to 10. A higher score indicates a more stable system operation and a closer relationship to the stable equilibrium point; a lower score indicates a more unstable system operation and a greater deviation from the stable equilibrium point.

[0112] Furthermore, the calculated real-time stability score is compared with the threshold to complete the anomaly determination: if the stability score is ≥ the preset threshold, the system is determined to be in stable operation, and there is no need to trigger the anomaly handling process, and the current lease configuration and node architecture are maintained; if the stability score is < the preset threshold, the system is determined to have a stability anomaly, and the stability lease management module will trigger the lease renegotiation mechanism or control the cluster master node switching process according to the severity of the anomaly. For details, please refer to the previous embodiment, which will not be repeated here.

[0113] Optionally, in some embodiments of this application, the method further includes: dynamically adjusting the number of control clusters according to the system load, and the system stability lease management module synchronously updating the topology relationship and lease binding to maintain stability constraints throughout the process.

[0114] For example, within a distributed control cluster, after a client submits a transaction, it is enqueued by the transaction access and queue module. The master node periodically triggers batch processing or when the queue length reaches a threshold, retrieving a set of transactions not exceeding batch size B from the queue and constructing a local proposal message. Its fields include at least: committee identifier, view number, local sequence number, batch digest, parent confirmation credential (or highest confirmation credential), and an optional global sequence number reference value. Slave nodes return receipts after verifying that the view number is consistent and the local sequence number is continuous. The evidence aggregation module aggregates receipts reaching a threshold q to form confirmation credentials and delivers the previous batch of transactions according to the "parent-child dependency / continuity" rule. The deterministic execution module executes and updates the local state (i.e., updates the local sequence number, highest confirmation credential, and state digest components in the state vector xi, making it converge towards the master node's state).

[0115] For example, when node (213) detects that the queue head transaction failed to be delivered within the timeout threshold Δ, or detects a local sequence number gap / conflict sign (i.e., detects that the deviation of the state vector xi from the expected trajectory through xleader exceeds the tolerance limit), an error signal is generated by the error signal generation module and uploaded to the chain. After the atomic broadcast delivery, the Layer 1 system stability lease management module determines the lease invalidation based on the accumulated evidence on the chain (e.g., the matching error signal reaching the threshold q), adds a lease view, and broadcasts the lease update. After the control cluster receives a sufficient number of matching lease updates, it pulls the corresponding on-chain evidence, uses the highest confirmation credential as the recovery anchor point (i.e., the globally consistent reset point of the state vector) for recovery alignment, and completes the state reset of the local sequence number and the highest confirmation credential, etc., the new master node continues to execute the process of Example 1 under the new view.

[0116] When a transaction is a cross-committee transaction, the distributed control cluster, acting as the source sender, first prioritizes and delivers the transaction based on completion. Subsequently, the evidence aggregation module generates availability evidence and locks the relevant accounts / states on the source side. The source control cluster submits a cross-committee coupling request to the global state layer. The cross-committee coupling coordination module in the global state layer verifies the availability evidence after atomic broadcast delivery. If valid, it advances the vector clock and issues a coupling execution command to the source / target control cluster. Once the local vector clock satisfies the "gap-free increment condition," the source / target control cluster deterministically executes the corresponding sub-transaction. The lock is released after the source side execution is complete.

[0117] In addition, when the local clock sequence number is continuously and without omission (e.g., the local vector clock component ge[t] is incremented to the clock value carried by the instruction), the source control cluster and the target control cluster execute the corresponding sub-transaction; the lock is released after the source side completes the execution.

[0118] It should be noted that the source control cluster, as the initiator of cross-committee transactions, has its local vector clock synchronized to the global vector clock threshold in advance due to the triggering of the on-chain request. It can directly meet the gapless increment condition and execute the corresponding sub-transaction. However, if the target control cluster's local vector clock component ge[t] does not reach the global vector clock threshold G[t] due to network latency, it will no longer directly block transaction execution. Instead, it will complete the ordered caching of coupled execution instructions through the aforementioned waiting heap, and at the same time, it will continue to process transactions within the local cluster using a priority-based out-of-order execution strategy until the local vector clock component ge[t] ≥ G[t]. Then, it will retrieve the cached coupled execution instructions from the waiting heap in ascending order of G[t] and deterministically execute the corresponding sub-transaction.

[0119] In summary, the dual-layer coupled blockchain processing method provided in this embodiment includes: initializing the global state layer and control cluster layer architecture, configuring local vector clocks for each control cluster, and allocating an initial global clock reference by the global vector clock management module; the control cluster master node receives transactions and determines whether they are intra-cluster or cross-cluster transactions based on the ownership of transaction resources; for intra-cluster transactions, slave nodes perform conflict detection and parallel processing based on the local vector clock to generate a block draft containing local timing markers; the master node requests a globally consistent sequence number from the atomic broadcast module, and the global vector clock management module synchronously updates the global clock; for cross-cluster transactions, the relevant control clusters coordinate timing based on the global vector clock, each cluster processes its own domain in parallel, and the result is used by the atomic broadcast module to achieve global consensus; the system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on the network dynamics stability model; if the evaluation result indicates an abnormal stability, lease renegotiation or master node switching is triggered; the local block with the embedded globally consistent sequence number is submitted to the global state layer, and the atomic broadcast module generates global blocks in sequence and broadcasts confirmation. In the dual-layer coupled blockchain processing scheme provided in this application, the dual-layer coupled architecture of the global state layer and the control cluster layer, combined with the real-time evaluation of the network dynamics stability model, improves the module configuration and node fault tolerance design of the control cluster, optimizes the transaction processing flow and global vector clock management method, and realizes stable system operation and efficient transaction processing. As a result, the system throughput is improved, the transaction processing latency is reduced, and the fault tolerance and reliability of the system are enhanced.

[0120] It should be understood that, although Figure 5 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 5At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0121] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0122] Therefore, embodiments of this application provide a storage medium storing multiple instructions that can be loaded by a processor to execute steps in any of the two-layer coupled blockchain processing methods provided in this application. For example, the instructions can execute the following steps: The system initializes the global state layer and control cluster layer architecture, configures local vector clocks for each control cluster, and allocates an initial global clock reference by the global vector clock management module. The control cluster master node receives transactions and determines whether they are intra-cluster or inter-cluster transactions based on resource ownership. For intra-cluster transactions, slave nodes perform conflict detection and parallel processing based on the local vector clock, generating a block draft with local timing tags. The master node requests a globally consistent sequence number from the atomic broadcast module, and the global vector clock management module updates the global clock synchronously. For inter-cluster transactions, relevant control clusters coordinate timing based on the global vector clock, each cluster processes its local portion in parallel, and the result is used by the atomic broadcast module to achieve global consensus. The system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on the network dynamics stability model. If the evaluation result indicates an anomaly in stability, lease renegotiation or master node switching is triggered. The local block with the embedded globally consistent sequence number is submitted to the global state layer, where the atomic broadcast module generates global blocks in sequence and broadcasts confirmation.

[0123] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0124] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0125] Since the instructions stored in the storage medium can execute the steps in any of the two-layer coupled blockchain processing methods provided in the embodiments of this application, the beneficial effects that any of the two-layer coupled blockchain processing methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0126] The foregoing has provided a detailed description of a two-layer coupled blockchain processing system, method, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A two-layer coupled blockchain processing system based on complex network dynamics, characterized in that, include: The global state layer is configured with an atomic broadcast module, a global vector clock management module, and a system stability lease management module. The control cluster layer contains multiple distributed control clusters, each control cluster including a master node and multiple slave nodes. Each control cluster is configured with a local vector clock, and the control cluster layer is configured with an error signal generation module. The atomic broadcast module is used to generate and broadcast globally consistent sequence numbers; the global vector clock management module is used to allocate initial vector clock values ​​to each control cluster and dynamically synchronize cross-domain timing based on the atomic broadcast results. The system stability lease management module is used to manage the lease life of each control cluster. Based on the cross-layer negative feedback mechanism, it monitors and dynamically adjusts the system operation status in real time. When the monitored system status indicators deviate from the preset dynamic equilibrium range, or when an error signal is received from the error signal generation module, it is determined that the system stability is abnormal. The master node corresponding to each control cluster is used to receive transactions, determine the ownership of transactions based on the resources involved in the transactions, and coordinate the processing flow within the cluster; Each slave node performs transaction conflict detection based on a local vector clock and executes conflict-free transactions in parallel. Specifically, when the evaluation result of the system stability lease management module indicates that the system stability is abnormal, the lease renegotiation mechanism is triggered or the cluster master node switching process is controlled to maintain the continuous and stable operation of the system.

2. The dual-layer coupled blockchain processing system according to claim 1, characterized in that, The network dynamics stability model quantifies the degree to which the system state deviates from the stable equilibrium point by collecting network latency, node response latency, and transaction processing rate parameters in real time, and outputs a stability score.

3. The dual-layer coupled blockchain processing system according to claim 2, characterized in that, The network operating parameters include network latency, node response latency, and transaction processing rate. The stability model generates a stability score by weighted summation after standardizing the parameters. When the stability score is lower than a preset threshold, it is used to help determine that the system stability is abnormal.

4. The dual-layer coupled blockchain processing system according to claim 1, characterized in that, The system stability lease management module determines stability anomalies under the following conditions: the master node continuously loses connection for more than the lease threshold, the cross-cluster communication delay exceeds the preset upper limit, or the node behavior is detected to deviate from the consensus protocol specification.

5. The dual-layer coupled blockchain processing system according to claim 1, characterized in that, The control cluster layer is also configured with a transaction access and queue module, an evidence aggregation module, and a deterministic execution module, and each of the distributed control clusters maintains a lease view, a local sequence number, a highest confirmation credential, and a local vector clock component.

6. The dual-layer coupled blockchain processing system according to claim 5, characterized in that, The node size of the distributed control cluster satisfies m≥3t+1, where m is the node size and t is the fault tolerance threshold of the distributed control cluster. When the evidence aggregation module generates confirmation credentials or availability evidence, it aggregates at least 2t+1 valid signature receipts.

7. The dual-layer coupled blockchain processing system according to claim 1, characterized in that, The global vector clock is optimized using a hierarchical management architecture or a cryptographic accumulator compression method. The hierarchical management architecture includes a core layer and an edge layer, with the core layer storing the aggregated clock digest of the edge layer.

8. The dual-layer coupled blockchain processing system according to claim 7, characterized in that, The cryptographic accumulator compression method is the Merkle accumulator compression method. The Merkle accumulator controls the cluster clock components to build the Merkle tree in batches according to the time window. The global state layer only stores the root hash and the latest batch index.

9. The dual-layer coupled blockchain processing system according to claim 1, characterized in that, The master node switching process includes: The system stability lease management module broadcasts lease update messages. After the distributed control cluster receives a sufficient number of matching lease updates, it pulls the corresponding evidence on the chain, resets the local sequence number and the highest confirmation credential with the highest confirmation credential, and completes the restoration alignment. Then, the new master node initiates a proposal to continue the consensus convergence process.

10. The two-layer coupled blockchain processing system based on complex network dynamics according to claim 1, characterized in that, The global state layer also includes a cross-committee coupling coordination module, which is used to verify the source-side availability evidence of cross-committee transactions, advance the global vector clock component of the control cluster and generate cross-committee coupling execution instructions, and issue the cross-committee coupling execution instructions to the control cluster.

11. The two-layer coupled blockchain processing system based on complex network dynamics according to claim 10, characterized in that, The control cluster is configured with a waiting heap, which is used to cache the cross-committee coupled execution instructions when the local vector clock of the control cluster lags behind the global vector clock instruction requirements of the global state layer. The control cluster is configured to process local transactions using a priority-based out-of-order execution strategy. When the local vector clock is aligned with the global vector clock, the cached cross-committee coupled execution instructions are extracted from the waiting heap and executed in the order of the global vector clock values.

12. The two-layer coupled blockchain processing system based on complex network dynamics according to claim 11, characterized in that, When the distributed control cluster processes cross-committee transactions, it adopts a single-phase atomic state coupling protocol. After the source control cluster completes the local sorting and delivery of cross-committee transactions, it generates availability evidence and locks the corresponding account and state on the source side. The global state layer verifies the validity of availability evidence based on the global consistent order of atomic broadcast. When the availability evidence verification passes, it advances the global vector clock components corresponding to the source control cluster and the target control cluster, and issues coupled execution instructions to the source control cluster and the target control cluster. The target control cluster determines the execution of the cross-committee transaction when the local vector clock meets the increment condition.

13. The two-layer coupled blockchain processing system based on complex network dynamics according to claim 1, characterized in that, The error signal is structured data, which includes timestamp proof, evidence type, and set of observation node signatures.

14. A two-layer coupled blockchain processing method based on complex network dynamics, characterized in that, The two-layer coupled blockchain processing method, applied to any one of claims 1 to 13, comprises: Initialize the global state layer and control cluster layer architecture, configure local vector clocks for each control cluster, and allocate the initial global clock reference by the global vector clock management module; The cluster master node receives transactions and determines whether a transaction is an intra-cluster transaction or a cross-cluster transaction based on the ownership of the transaction resources. For intra-cluster transactions, the slave node performs conflict detection and parallel processing based on the local vector clock to generate a block draft containing local time sequence markers; The master node requests a globally consistent sequence number from the atomic broadcast module, and the global vector clock management module synchronously updates the global clock. For cross-cluster transactions, the relevant control clusters coordinate timing based on the global vector clock, each cluster processes its own domain in parallel, and the results are used by the atomic broadcast module to achieve global consensus. The system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on the network dynamics stability model. If the assessment results indicate an instability anomaly, a lease renegotiation or master node switch will be triggered. The local block with the embedded globally consistent sequence number is submitted to the global state layer, and the atomic broadcast module generates global blocks in sequence and broadcasts confirmation.

15. The two-layer coupled blockchain processing method based on complex network dynamics according to claim 14, characterized in that, The system stability lease management module continuously monitors operating parameters and performs dynamic evaluation based on the network dynamics stability model, including: The network status parameters collected in real time are input into a preset stability evaluation function. When the stability score is lower than the threshold, it is judged as abnormal.

16. The two-layer coupled blockchain processing method according to claim 14, characterized in that, Also includes: The number of control clusters is dynamically adjusted according to the system load, and the system stability lease management module updates the topology relationship and lease binding synchronously to maintain stability constraints throughout the process.

17. A storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as described in any one of claims 14-16, which is a two-layer coupled blockchain processing method based on complex network dynamics.

Images